[afnog] connection to www.cnn.com
Brian Candler
B.Candler at pobox.com
Tue Jun 6 10:39:46 EAT 2006
On Tue, Jun 06, 2006 at 07:54:32AM +0300, Mikisa Richard wrote:
> >Next try a tcpdump: in one window do
> >
> > tcpdump -i eth0 -n -s1500 -vX host 64.236.29.120
> >
> >and in another do
> >
> > telnet 64.236.29.120 80
> > asdfasdf
> >
> >Does the packet containing 'asdfasdf' get sent and acknowledged, or does it
> >get re-sent at increasing intervals?
> >
> >
> Gets re-sent
Then that's very strange. From here:
# tcpdump -i rl0 -n -s1500 -vX host 64.236.29.120
tcpdump: listening on rl0, link-type EN10MB (Ethernet), capture size 1500 bytes
08:31:22.685655 IP (tos 0x10, ttl 64, id 9076, offset 0, flags [DF], proto: TCP (6), length: 64) 172.17.0.145.56724 > 64.236.29.120.80: S, cksum 0xa084 (correct), 667153185:667153185(0) win 65535 <mss 1460,nop,wscale 1,nop,nop,timestamp 3627334263 0,sackOK,eol>
0x0000: 4510 0040 2374 4000 4006 0c2e ac11 0091 E..@#t at .@.......
0x0010: 40ec 1d78 dd94 0050 27c3 f321 0000 0000 @..x...P'..!....
0x0020: b002 ffff a084 0000 0204 05b4 0103 0301 ................
0x0030: 0101 080a d834 ba77 0000 0000 0402 0000 .....4.w........
08:31:22.773900 IP (tos 0x0, ttl 44, id 27925, offset 0, flags [none], proto: TCP (6), length: 44) 64.236.29.120.80 > 172.17.0.145.56724: S, cksum 0xd1ba (correct), 2576618102:2576618102(0) ack 667153186 win 5840 <mss 1380>
0x0000: 4500 002c 6d15 0000 2c06 16b1 40ec 1d78 E..,m...,... at ..x
0x0010: ac11 0091 0050 dd94 9994 1276 27c3 f322 .....P.....v'.."
0x0020: 6012 16d0 d1ba 0000 0204 0564 6ea5 `..........dn.
08:31:22.774041 IP (tos 0x10, ttl 64, id 9077, offset 0, flags [DF], proto: TCP (6), length: 40) 172.17.0.145.56724 > 64.236.29.120.80: ., cksum 0xfff7 (correct), ack 1 win 65535
0x0000: 4510 0028 2375 4000 4006 0c45 ac11 0091 E..(#u at .@..E....
0x0010: 40ec 1d78 dd94 0050 27c3 f322 9994 1277 @..x...P'.."...w
0x0020: 5010 ffff fff7 0000 0000 0000 0000 P.............
08:31:26.506344 IP (tos 0x10, ttl 64, id 9078, offset 0, flags [DF], proto: TCP (6), length: 50) 172.17.0.145.56724 > 64.236.29.120.80: P, cksum 0x6728 (correct), 1:11(10) ack 1 win 65535
0x0000: 4510 0032 2376 4000 4006 0c3a ac11 0091 E..2#v at .@..:....
0x0010: 40ec 1d78 dd94 0050 27c3 f322 9994 1277 @..x...P'.."...w
0x0020: 5018 ffff 6728 0000 6173 6466 6173 6466 P...g(..asdfasdf
0x0030: 0d0a ..
08:31:26.593700 IP (tos 0x0, ttl 44, id 27926, offset 0, flags [none], proto: TCP (6), length: 40) 64.236.29.120.80 > 172.17.0.145.56724: ., cksum 0xe91d (correct), ack 11 win 5840
0x0000: 4500 0028 6d16 0000 2c06 16b4 40ec 1d78 E..(m...,... at ..x
0x0010: ac11 0091 0050 dd94 9994 1277 27c3 f32c .....P.....w'..,
0x0020: 5010 16d0 e91d 0000 0000 11dc f157 P............W
08:31:26.594690 IP (tos 0x0, ttl 44, id 27927, offset 0, flags [none], proto: TCP (6), length: 311) 64.236.29.120.80 > 172.17.0.145.56724: P, cksum 0xe63f (correct), 1:272(271) ack 11 win 5840
0x0000: 4500 0137 6d17 0000 2c06 15a4 40ec 1d78 E..7m...,... at ..x
0x0010: ac11 0091 0050 dd94 9994 1277 27c3 f32c .....P.....w'..,
0x0020: 5018 16d0 e63f 0000 3c21 444f 4354 5950 P....?..<!DOCTYP
0x0030: 4520 4854 4d4c 2050 5542 4c49 4320 222d E.HTML.PUBLIC."-
0x0040: 2f2f 4945 5446 2f2f 4454 4420 4854 4d4c //IETF//DTD.HTML
0x0050: 2032 2e30 2f2f 454e 223e 0a3c 6874 6d6c .2.0//EN">.<html
0x0060: 3e3c 6865 6164 3e0a 3c74 6974 6c65 3e35 ><head>.<title>5
0x0070: 3031 204d 6574 686f 6420 4e6f 7420 496d 01.Method.Not.Im
0x0080: 706c 656d 656e 7465 643c 2f74 6974 6c65 plemented</title
0x0090: 3e0a 3c2f 6865 6164 3e3c 626f 6479 3e0a >.</head><body>.
0x00a0: 3c68 313e 4d65 7468 6f64 204e 6f74 2049 <h1>Method.Not.I
0x00b0: 6d70 6c65 6d65 6e74 6564 3c2f 6831 3e0a mplemented</h1>.
0x00c0: 3c70 3e61 7364 6661 7364 6620 746f 202f <p>asdfasdf.to./
0x00d0: 206e 6f74 2073 7570 706f 7274 6564 2e3c .not.supported.<
0x00e0: 6272 202f 3e0a 3c2f 703e 0a3c 6872 3e0a br./>.</p>.<hr>.
0x00f0: 3c61 6464 7265 7373 3e41 7061 6368 6520 <address>Apache.
0x0100: 5365 7276 6572 2061 7420 7777 772e 636e Server.at.www.cn
0x0110: 6e2e 636f 6d20 506f 7274 2038 303c 2f61 n.com.Port.80</a
0x0120: 6464 7265 7373 3e0a 3c2f 626f 6479 3e3c ddress>.</body><
0x0130: 2f68 746d 6c3e 0a /html>.
08:31:26.597487 IP (tos 0x0, ttl 44, id 27928, offset 0, flags [none], proto: TCP (6), length: 40) 64.236.29.120.80 > 172.17.0.145.56724: F, cksum 0xe80d (correct), 272:272(0) ack 11 win 5840
0x0000: 4500 0028 6d18 0000 2c06 16b2 40ec 1d78 E..(m...,... at ..x
0x0010: ac11 0091 0050 dd94 9994 1386 27c3 f32c .....P......'..,
0x0020: 5011 16d0 e80d 0000 0000 434d 4afa P.........CMJ.
08:31:26.597622 IP (tos 0x10, ttl 64, id 9079, offset 0, flags [DF], proto: TCP (6), length: 40) 172.17.0.145.56724 > 64.236.29.120.80: ., cksum 0xfedd (correct), ack 273 win 65535
0x0000: 4510 0028 2377 4000 4006 0c43 ac11 0091 E..(#w at .@..C....
0x0010: 40ec 1d78 dd94 0050 27c3 f32c 9994 1387 @..x...P'..,....
0x0020: 5010 ffff fedd 0000 0000
You can see that the biggest response packet is only 0x137 = 311 bytes.
It would be interesting to compare this with what you see. From what you
say, it sounds like the SYN ACK is getting back from www.cnn.com, but not
any subsequent ACK packets. That sounds like some very strange filtering.
If .254 is a test machine that you can play with without breaking anything,
try changing your interface MTU:
ifconfig eth0 mtu 576
and then try connecting again (also with tcpdump). Once you've finished
testing, put it back:
ifconfig eth0 mtu 1500
However, I don't think MTU explains what you're seeing.
Regards,
Brian,
More information about the afnog
mailing list