der Mouse wrote:
# tcpdump -n -p -vvv tcp port 18000 tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes 14:05:19.645888 IP (tos 0x0, ttl 46, id 0, offset 0, flags [DF], proto TCP (6), length 64) IP0.65351 > IP1.18000: S, cksum 0x8a20 (correct), 3076040396:3076040396(0) win 32768 <mss 1380,nop,wscale 3,sackOK,nop,nop,nop,nop,timestamp 1 0> 14:05:19.646079 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40) IP1.18000 > IP0.65351: R, cksum 0x83a3 (correct), 0:0(0) ack 3076040397 win 0# tcpdump -n -p -vvv tcp port 18000 tcpdump: listening on rtk0, link-type EN10MB (Ethernet), capture size 96 bytes 20:09:20.158824 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 64) IP0.65351 > IP1.18000: S, cksum 0xbda7 (correct), 2102555286:2102555286(0) win 32768 <mss 1460,nop,wscale 3,sackOK,nop,nop,nop,nop,timestamp 1 0> 20:09:20.451227 IP (tos 0x0, ttl 55, id 0, offset 0, flags [DF], proto TCP (6), length 40) IP1.18000 > IP0.65351: R, cksum 0xa7f2 (correct), 810606391:810606391(0) ack 2102555287 win 0Although the other_comp is sending the RST packet with sequence number 0 [...]It probably is not. tcpdump normally silently converts TCP sequence numbers to relative numbers, ie it subtracts the base sequence number for the connection as learned from the first packet seen on the connection. This is not, however, done for the initial packet, ie, the one from which tcpdump learns the base sequence number Try tcpdumping a successful connection and looking at the sequence numbers.
[...]Ok, thanks, here are the tcpdump sessions with the "-S" ("Print absolute, rather than relative, TCP sequence numbers.") option turned on:
1) Here is a session with expected result (the application receives correctly ECONNREFUSED), ipf rules applied:
my_comp ---- Internet ---- other_comp_correct my_comp: ========== tcpdump version 3.9.7 libpcap version 0.9.4 # tcpdump -n -S -p -vvv tcp port 17000tcpdump: listening on rtk0, link-type EN10MB (Ethernet), capture size 96 bytes 00:43:36.092862 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 64) IP0.65530 > IP1.17000: S, cksum 0x340a (correct), 1925369280:1925369280(0) win 32768 <mss 1460,nop,wscale 3,sackOK,nop,nop,nop,nop,timestamp 1 0> 00:43:36.139869 IP (tos 0x0, ttl 55, id 0, offset 0, flags [DF], proto TCP (6), length 40) IP1.17000 > IP0.65530: R, cksum 0x2ddd (correct), 0:0(0) ack 1925369281 win 0
other_comp_correct: ===================== tcpdump version 3.9.5 libpcap version 0.9.5 # tcpdump -n -p -S -vvv tcp port 17000tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes 00:39:42.934107 IP (tos 0x0, ttl 56, id 0, offset 0, flags [DF], proto: TCP (6), length: 64) IP0.65530 > IP1.17000: S, cksum 0x6e6f (correct), 1925369280:1925369280(0) win 32768 <mss 1460,nop,wscale 3,sackOK,nop,nop,nop,nop,timestamp 1 0> 00:39:42.934155 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: TCP (6), length: 40) IP1.17000 > IP0.65530: R, cksum 0x6842 (correct), 0:0(0) ack 1925369281 win 0
2) Here is a session, where the application waits for a timeout, ipf rules applied:
my_comp ---- Internet ---- other_comp_incorrect my_comp: ========== tcpdump version 3.9.7 libpcap version 0.9.4 # tcpdump -n -p -S -vvv tcp port 18000tcpdump: listening on rtk0, link-type EN10MB (Ethernet), capture size 96 bytes 01:01:00.704813 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 64) IP0.65522 > IP2.18000: S, cksum 0xbef6 (correct), 2749057555:2749057555(0) win 32768 <mss 1460,nop,wscale 3,sackOK,nop,nop,nop,nop,timestamp 1 0> 01:01:00.844241 IP (tos 0x0, ttl 55, id 0, offset 0, flags [DF], proto TCP (6), length 40) IP2.18000 > IP0.65522: R, cksum 0x7756 (correct), 2013055350:2013055350(0) ack 2749057556 win 0
other_comp_incorrect: ===================== tcpdump version 3.9.8 libpcap version 0.9.8 # tcpdump -n -p -S -vvv tcp port 18000tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes 18:57:00.588170 IP (tos 0x0, ttl 46, id 0, offset 0, flags [DF], proto TCP (6), length 64) IP0.65522 > IP2.18000: S, cksum 0x5b32 (correct), 3460546084:3460546084(0) win 32768 <mss 1380,nop,wscale 3,sackOK,nop,nop,nop,nop,timestamp 1 0> 18:57:00.588369 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40) IP2.18000 > IP0.65522: R, cksum 0x54b5 (correct), 0:0(0) ack 3460546085 win 0
The tcpdump I have here has an option, -S, which disables this. Given the difference in output format, yours is clearly a different version, but you might look for an option with similar semantics in yours.
So even with the absolute sequence numbers is the presence of sequence number in the RST packet the only significant difference i can recognize. As i wrote in previous email, i think it is probably caused by some appliance between the my_comp and other_comp_incorrect machines, probably some Cisco ASA. Now: is this a correct packet? If so, why does the ipf not recognize it as being correct part of the session and our tcp stack does?
Thanks, r.