[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: TCP (over ppp) problem with kernel 2.2.x



aphro <nate@firetrail.com> writes:
> check the routing table?  2.2.x handles initialization of routes slightly
> differently, although ive never had any probs going from 2.0 to 2.2 (just
> upgraded 2 machines yesterday.
> 
> and what kernel are you using? exactly ? check your firewall rules
> too.. that ipmasq package has been nothin but trouble for me, pisses me
> off :)

I'm currently using 2.2.13, but I had the same problems with 2.2.10.
I don't *have* any firewall rules, that I'm aware of -- at least, I
didn't set anything up; however, I'll read the documentation for
`ipmasq' and see if that tells me anything.

If it makes the problem any more clear, here are some traces I did last night
with `tcpdump -vv -a tcp' (I've stuck in newlines to make it easier to read),
during the excution of the command `telnet smtp03.mail.gol.com smtp' (to my
ISP's mail machine).  The IP address of my computer is dynamic, thus the
different names for the local half of the connection.

******* Using the 2.0.36 kernel:

  22:10:24.649284 tc-1-106.kawasaki.gol.ne.jp.2623
		> smtp03.mail.gol.com.smtp: 
		S 2343209862:2343209862(0) win 512 <mss 1474> [tos 0x10] (ttl 64, id 6578)
  22:10:24.789284 smtp03.mail.gol.com.smtp
		> tc-1-106.kawasaki.gol.ne.jp.2623: 
		S 3522288465:3522288465(0) ack 2343209863 win 8760 <mss 1460> (DF) (ttl 250, id 38485)
  22:10:24.789284 tc-1-106.kawasaki.gol.ne.jp.2623
		> smtp03.mail.gol.com.smtp: 
		. ack 1 win 16214 (DF) [tos 0x10] (ttl 64, id 6580)
  22:10:24.919284 smtp03.mail.gol.com.smtp
		> tc-1-106.kawasaki.gol.ne.jp.2623: 
		P 1:40(39) ack 1 win 8760 (DF) (ttl 250, id 38486)
  22:10:24.939284 tc-1-106.kawasaki.gol.ne.jp.2623
		> smtp03.mail.gol.com.smtp: 
		. ack 40 win 16214 (DF) [tos 0x10] (ttl 64, id 6582)
  22:10:26.819284 tc-1-106.kawasaki.gol.ne.jp.2623
		> smtp03.mail.gol.com.smtp: 
		P 1:7(6) ack 40 win 16214 (DF) [tos 0x10] (ttl 64, id 6583)
  22:10:26.949284 smtp03.mail.gol.com.smtp
		> tc-1-106.kawasaki.gol.ne.jp.2623: 
		. ack 7 win 8760 (DF) (ttl 250, id 38487)
  22:10:26.959284 smtp03.mail.gol.com.smtp
		> tc-1-106.kawasaki.gol.ne.jp.2623: 
		P 40:49(9) ack 7 win 8760 (DF) (ttl 250, id 38488)
  22:10:26.959284 smtp03.mail.gol.com.smtp
		> tc-1-106.kawasaki.gol.ne.jp.2623: 
		F 49:49(0) ack 7 win 8760 (DF) (ttl 250, id 38489)
  22:10:26.959284 tc-1-106.kawasaki.gol.ne.jp.2623
		> smtp03.mail.gol.com.smtp: 
		. ack 50 win 16204 (DF) [tos 0x10] (ttl 64, id 6584)
  22:10:26.959284 tc-1-106.kawasaki.gol.ne.jp.2623
		> smtp03.mail.gol.com.smtp: 
		F 7:7(0) ack 50 win 16214 [tos 0x10] (ttl 64, id 6585)
  22:10:27.089284 smtp03.mail.gol.com.smtp
		> tc-1-106.kawasaki.gol.ne.jp.2623: 
		. ack 8 win 8760 (DF) (ttl 250, id 38490)

[At this point, it's connected successfully, and I can see the smtp
server's welcome message.]

******* Using the 2.2.13 kernel (I've turned of most of the extra tcp features
that the newer kernel uses, using /proc/sys/net/ipv4/tcp_*, so the packet
options list is the same as 2.0.36; I was very careful to try toggling each
option in isolation, but nothing really seems to make a difference):

  00:37:03.748503 tc-1-199.kawasaki.gol.ne.jp.1053
		> smtp03.mail.gol.com.smtp: 
		S 220386298:220386298(0) win 16214 <mss 1474> (DF) [tos 0x10] (ttl 64, id 217)
  00:37:03.874121 smtp03.mail.gol.com.smtp
		> tc-1-199.kawasaki.gol.ne.jp.1053: 
		S 1801353179:1801353179(0) ack 220386299 win 8760 <mss 1460> (DF) (ttl 250, id 18656)
  00:37:03.874306 tc-1-199.kawasaki.gol.ne.jp.1053
		> smtp03.mail.gol.com.smtp: 
		. ack 1 win 16214 (DF) [tos 0x10] (ttl 64, id 218)

[The telnet windows says `connected', but the smtp server's banner never
appears.  The last packet you see gets retried indefinitely, but no response
is ever received, and the connection never actually goes through; this is the
same behavior I get with any tcp connection.]

The only real difference *I* can see is that the DF (don't fragment)
flag is turned on for the initial packet using the newer kernel;
however, since the first packet *is* acked, that doesn't seem like it
should be the problem.  The local port number is also different, but this
shouldn't matter, since neither is a reserved port (right?).

Thanks for any info,

-Miles
-- 
Love is a snowmobile racing across the tundra.  Suddenly it flips over,
pinning you underneath.  At night the ice weasels come.  --Nietzsche


Reply to: