Paul Ripke wrote:
> My general firewall/router/gateway box running NetBSD current from
> around 2003-01-01 runs a transparent web proxy using NAT to redirect
> outbound port 80 connections through to squid on port 3128. After
> upgrading from an October(ish) kernel to current, I've started seeing
> TCP connections hanging between squid and a MacOSX laptop on my
> internal wireless network. This doesn't happen when my laptop is on
> my internal ethernet network (using the same transparent proxy).
> Nor does it happen when I manually configure the proxy - indicating
> a possible problem in the ipf/NAT code?
> 
> Here's a trace from the laptop. I'm no good reading traces at this
> level of detail, but it looks like something is breaking with the
> FIN handling. Someone want to tell me what's going on here?
>
> 12:18:00.498254 192.168.254.130.49753 > 203.63.53.112.80: . ack 19649
> win 33304 <nop,nop,timestamp 204410 3> (DF)

3 data packets from server, laptop acknowledges all:

> 12:18:00.529706 203.63.53.112.80 > 192.168.254.130.49753: P
> 19649:20745(1096) ack 1518 win 32850 <nop,nop,timestamp 3 204409> (DF)
> 12:18:00.563885 203.63.53.112.80 > 192.168.254.130.49753: .
> 20745:22193(1448) ack 1518 win 32850 <nop,nop,timestamp 3 204409> (DF)
> 12:18:00.593888 203.63.53.112.80 > 192.168.254.130.49753: .
> 22193:23641(1448) ack 1518 win 32850 <nop,nop,timestamp 3 204409> (DF)
> 12:18:00.594436 192.168.254.130.49753 > 203.63.53.112.80: . ack 23641
> win 33304 <nop,nop,timestamp 204410 3> (DF)

3 data, and ack:

> 12:18:00.629632 203.63.53.112.80 > 192.168.254.130.49753: P
> 23641:24841(1200) ack 1518 win 32850 <nop,nop,timestamp 3 204409> (DF)
> 12:18:00.663462 203.63.53.112.80 > 192.168.254.130.49753: .
> 24841:26289(1448) ack 1518 win 32850 <nop,nop,timestamp 3 204409> (DF)
> 12:18:00.703491 203.63.53.112.80 > 192.168.254.130.49753: .
> 26289:27737(1448) ack 1518 win 32850 <nop,nop,timestamp 3 204409> (DF)
> 12:18:00.703899 192.168.254.130.49753 > 203.63.53.112.80: . ack 27737
> win 33304 <nop,nop,timestamp 204410 3> (DF)

3 data, and ack:

> 12:18:00.739563 203.63.53.112.80 > 192.168.254.130.49753: P
> 27737:28937(1200) ack 1518 win 32850 <nop,nop,timestamp 3 204409> (DF)
> 12:18:00.777821 203.63.53.112.80 > 192.168.254.130.49753: .
> 28937:30385(1448) ack 1518 win 32850 <nop,nop,timestamp 3 204409> (DF)
> 12:18:00.807660 203.63.53.112.80 > 192.168.254.130.49753: P
> 30385:31437(1052) ack 1518 win 32850 <nop,nop,timestamp 3 204409> (DF)
> 12:18:00.808042 192.168.254.130.49753 > 203.63.53.112.80: . ack 31437
> win 33304 <nop,nop,timestamp 204410 3> (DF)

-- 2 minute delay --

Server sends Fin (closes connection), client acks:

> 12:20:01.188054 203.63.53.112.80 > 192.168.254.130.49753: F
> 31437:31437(0) ack 1518 win 32850 <nop,nop,timestamp 244 204409> (DF)
> 12:20:01.188276 192.168.254.130.49753 > 203.63.53.112.80: . ack 31438
> win 33304 <nop,nop,timestamp 204651 244> (DF)

-- 12 second delay --

Client sends Fin, server acks (client has sent ack of fin, so the
server need not send Fin again):

> 12:20:12.903176 192.168.254.130.49753 > 203.63.53.112.80: F
> 1518:1518(0) ack 31438 win 33304 <nop,nop,timestamp 204674 244> (DF)
> 12:20:12.906652 203.63.53.112.80 > 192.168.254.130.49753: . ack 1519
> win 32850 <nop,nop,timestamp 268 204674> (DF)

Everything is in order, no retransmits - just two delays, which appear
to be in the applications.  Does a packet capture on the NetBSD side
look similar?

If the ethernet connection works, is that on a different subnet?
Could be something different or missing in the network configuration,
a delay in DNS lookup for a log message isn't uncommon.

-Neil