On 2010/10/29 20:48, Sean P. DeNigris wrote:
>
>
> Frank Shearar wrote:
>>
>> Start tcpdump with something like: sudo tcpdump -i fw0 -v port 8090 and
>> then trying to access the site through Safari.
>>
>
> Exciting!  WebClient is communicating, just not successfully.
>
> After a little playing around, running "sudo tcpdump -i lo0 -vnS port 2002"
> (I keep changing the port) produced the following packet info:
>    Safari's first packet:
>      08:44:10.841003 IP6 (hlim 64, next-header TCP (6) payload length: 44)
> ::1.54889>  ::1.2002: Flags [S], cksum 0x9345 (correct), seq 2994624526, win
> 65535, options [mss 16324,nop,wscale 2,nop,nop,TS val 1034896177 ecr
> 0,sackOK,eol], length 0
>    WebClient's first packet:
>      08:39:48.796371 IP (tos 0x0, ttl 64, id 52777, offset 0, flags [DF],
> proto TCP (6), length 52, bad cksum 0 (->6e98)!)
>      127.0.0.1.54859>  127.0.0.1.2002: Flags [F.], cksum 0xfe28 (incorrect ->
> 0xa0fd), seq 964011037, ack 1862845032, win 65535, options [nop,nop,TS val
> 1034893560 ecr 1034892868], length 0
>
> Any packet guru know what this means?
>
> Thanks for the support so far - I'm really wanting to get this project up
> and this seems like progress!!!
> Sean

It looks like Safari's resolving "localhost" to ::1, IPv6's loopback, 
and the address on which your server's running, while WebClient isn't.

WebClient, instead, is resolving "localhost" to 127.0.0.1, IPv4's 
loopback. There's nothing running there, so the connection fails.

Both behaviours are correct, or at least partially so. It's a policy 
decision whether to try IPv4 addresses or IPv6 addresses first. After 
that, it makes sense to try all the addresses (switching from 4 to 6 or 
vice versa) before failing. I don't know how WebClient's name resolution 
works, so we'll have to wait for Andreas, I think.

frank