2.4.0-test1
RedHat 6.2 with nearly all updates
iptables 1.1.0
Athlon 800Mhz
128 Meg of RAM
Entire network uses NetGear FA310TX (Tulip versions)
Whenever anyone tries to download or retrieve anything that is over about 23k,
it stalls out completely on that transfer. There are a few exceptions to this.
Email and RPM (redhat packages) always stall out.
If connection is done direct PPP with same stuff above, nothing goes wrong. It
is in the nat code somewhere apparently.
I allow the following rules (for ICMP):
#Accept cool icmp's
$IPT -A INPUT -i $extint -p ICMP --icmp-type destination-unreachable -j
LOGACCEPT
$IPT -A INPUT -i $extint -p ICMP --icmp-type echo-reply -j LOGACCEPT
$IPT -A INPUT -i $extint -p ICMP --icmp-type source-quench -j LOGACCEPT
$IPT -A INPUT -i $extint -p ICMP --icmp-type time-exceeded -j LOGACCEPT
$IPT -A INPUT -i $extint -p ICMP --icmp-type destination-unreachable -j
LOGACCEPT
$IPT -A INPUT -i $extint -p ICMP --icmp-type parameter-problem -j LOGACCEPT
$IPT -A INPUT -i $extint -p ICMP --icmp-type timestamp-request -j LOGACCEPT
$IPT -A INPUT -i $extint -p ICMP --icmp-type timestamp-reply -j LOGACCEPT
With the modification below.
#Send everything else to the firewall.
$IPT -A INPUT -p icmp -j firewall
$IPT -A INPUT -p tcp --syn -j firewall
$IPT -A INPUT -p udp -j firewall
Below is a session of helix-update with a system. It shows the last few packets
before the stall.
18:01:43.438454 < teton.dulug.duke.edu.www > aurora.1571: P 14481:15929(1448)
ack 123 win 32120 <nop,nop,timestamp 434930933 2505116> (DF)
18:01:43.439009 > kenn002a-p4-010.cybertours.com.1571 >
teton.dulug.duke.edu.www: . 122:122(0) ack 15929 win 28960 <nop,nop,timestamp
2505911 434930933,nop,nop, sack 1 {18825:21721} > (DF)
18:01:43.918444 < teton.dulug.duke.edu.www > aurora.1571: P 15929:17377(1448)
ack 123 win 32120 <nop,nop,timestamp 434930961 2505911> (DF)
18:01:43.919040 > kenn002a-p4-010.cybertours.com.1571 >
teton.dulug.duke.edu.www: . 122:122(0) ack 17377 win 28960 <nop,nop,timestamp
2505959 434930961,nop,nop, sack 1 {18825:21721} > (DF)
18:01:44.128518 < teton.dulug.duke.edu.www > aurora.1571: P 17377:18825(1448)
ack 123 win 32120 <nop,nop,timestamp 434930961 2505911> (DF)
18:01:44.129047 > kenn002a-p4-010.cybertours.com.1571 >
teton.dulug.duke.edu.www: . 122:122(0) ack 21721 win 28960 <nop,nop,timestamp
2505980 434930961> (DF)
18:01:44.398440 < teton.dulug.duke.edu.www > aurora.1571: P 21721:23169(1448)
ack 123 win 32120 <nop,nop,timestamp 434931009 2505959> (DF)
18:01:44.399019 > kenn002a-p4-010.cybertours.com.1571 >
teton.dulug.duke.edu.www: . 122:122(0) ack 23169 win 31856 <nop,nop,timestamp
2506007 434931009> (DF)
18:01:44.528521 < teton.dulug.duke.edu.www > aurora.1571: P 23169:24617(1448)
ack 123 win 32120 <nop,nop,timestamp 434931009 2505959> (DF)
18:01:44.529091 > kenn002a-p4-010.cybertours.com.1571 >
teton.dulug.duke.edu.www: . 122:122(0) ack 24617 win 31856 <nop,nop,timestamp
2506020 434931009> (DF)
I will be running some tests to see if I have no firewall rules, if that will
work.
Trever
-- For the finest in family and value oriented products: http://www.daysofyore.com For owner friendly domain names: http://domains.daysofyore.com- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Jun 07 2000 - 21:00:17 EST