Hi folks,
I have the following in my firewall (condensed version)
[CentOS 4.2: 2.6.9-11.EL.i686 kernel]:
INPUT:
--state ESTABLISHED,RELATED -j ACCEPT
-p tcp -j REJECT --reject-with tcp-reset
-j REJECT
OUTPUT: ACCEPT
The connection is over a wireless link so packets _do_ get dropped even
though throughput is around 100-400 kB/s (depending on
atmospheric conditions, etc.)
Now I've noticed that sometimes connections are broken, I've narrowed the
problem down to _this_ firewall (as in it's not the only one, but I'm
pretty sure that it's at fault here...)
Tcpdumping a "ssh somewhere cat /dev/zero > /dev/null" session on the
firewall to an external host (a few hops away, reliable links, except for
the single wireless link) on a prematurely terminated connection reveals
the following (near the very end):
# tcpdump -i eth1 host $TARGET -n -nn
SRC=$FIREWALL:38945
DST=$TARGET:22
(all stream counts (acks) where 1728xxxxx so 1728 has been replaced with
nil to gain on readability...)
034006 IP SRC > DST: . ack 05611 win 23688 <nop,nop,timestamp 603026606
838569311,nop,nop,sack sack 3 {11403:12851}{07059:09955}
068320 IP DST > SRC: . 12851:14299(1448) ack 85975 win 8576
<nop,nop,timestamp 838569322 603026606>
068421 IP SRC > DST: . ack 05611 win 23688 <nop,nop,timestamp 603026641
838569311,nop,nop,sack sack 3 {11403:14299}{07059:09955}
101781 IP DST > SRC: P 14299:15747(1448) ack 85975 win 8576
<nop,nop,timestamp 838569325 603026641>
101879 IP SRC > DST: . ack 05611 win 23688 <nop,nop,timestamp 603026674
838569311,nop,nop,sack sack 2 {11403:18643}{07059:09955}
133870 IP DST > SRC: . 18643:20091(1448) ack 85975 win 8576
<nop,nop,timestamp 838569328 603026674>
133969 IP SRC > DST: . ack 05611 win 23688 <nop,nop,timestamp 603026706
838569311,nop,nop,sack sack 2 {11403:20091}{07059:09955}
164262 IP DST > SRC: . 20091:21539(1448) ack 85975 win 8576
<nop,nop,timestamp 838569332 603026706>
164358 IP SRC > DST: . ack 05611 win 23688 <nop,nop,timestamp 603026737
838569311,nop,nop,sack sack 2 {11403:21539}{07059:09955}
198287 IP DST > SRC: . 21539:22987(1448) ack 85975 win 8576
<nop,nop,timestamp 838569335 603026737>
198386 IP SRC > DST: . ack 05611 win 23688 <nop,nop,timestamp 603026771
838569311,nop,nop,sack sack 2 {11403:22987}{07059:09955}
230168 IP DST > SRC: . 22987:24435(1448) ack 85975 win 8576
<nop,nop,timestamp 838569338 603026771>
230285 IP SRC > DST: . ack 05611 win 23688 <nop,nop,timestamp 603026803
838569311,nop,nop,sack sack 2 {11403:24435}{07059:09955}
252786 IP DST > SRC: . 05611:07059(1448) ack 85975 win 8576
<nop,nop,timestamp 838569340 603026771>
252857 IP SRC > DST: R 1475625677:1475625677(0) win 0
As far as I can tell, the second to last packet is perfectly valid - it is
a valid retransmit of a missing/dropped piece. For some reason it results
in a reset being sent from the tcp-reset rule (counter increases). Thus
it would seem the packet is not matching the ESTABLISHED rule. Any ideas?
Is this a bug? Has this been fixed in a/the newer kernel (I've got 156
days of uptime and a lot of junk on the box so I don't really want to
reset it... :( )
Is the firewall configuration above correct - ie. is that a valid spot to
generate TCP Resets? I doubt DROP'ing the packets will help since it'll
just cause a stall, with future retransmits not getting through due to not
matching as ESTABLISHED anyway...
Cheers,
MaZe.
