Board index Solaris

Bizarre packet drops under Solaris 2.4

Bizarre packet drops under Solaris 2.4

Post by Jack Val » Fri, 12 Apr 1996 04:00:00



I am noticing a network oddity with S10s running Solaris 2.4.  This problem
may also plague 2.5.  When doing a traceroute, the second ICMP packet
will timeout.  It doesn't matter if you send the traceroute from that host,
then end result is:

bogus% traceroute bogus
traceroute to bogus (192.0.0.1), 30 hops max, 40 byte packets
 1     bogus (192.0.0.1)        2ms     *       1ms

[NOTE: IP addresses have been changed]

It's not a bug in traceroute because all of my NT machines are fine.  I'm
even noticing this problem on a Solaris 2.4 machine on the Internet.  
SunOS 4.1.4 seems to be ok.

Has anyone seen this before?  Is there a patch?  I'm concerned that this is
a symptom (sp) of a network problem on my website.

Jack
Asymetrix Corporation

 
 
 
Top

Bizarre packet drops under Solaris 2.4

Post by Juergen Ke » Sat, 13 Apr 1996 04:00:00



> I am noticing a network oddity with S10s running Solaris 2.4.  This problem
> may also plague 2.5.  When doing a traceroute, the second ICMP packet
> will timeout.  It doesn't matter if you send the traceroute from that host,
> then end result is:

> bogus% traceroute bogus
> traceroute to bogus (192.0.0.1), 30 hops max, 40 byte packets
>  1     bogus (192.0.0.1)   2ms     *       1ms

From Caspar's FAQ:

6.23) Traceroute to Solaris 2.x machines gives many timeouts.

    Solaris 2.4 and later (and Solaris 2.3 w/ high rev kernel jumbo
    patches) limit the number of ICMP error message to one
    per 500 milliseconds.  To switch off this feature, use:

        /usr/sbin/ndd -set /dev/ip ip_icmp_err_interval 0
--


 
 
 
Top

Bizarre packet drops under Solaris 2.4

Post by Casper H.S. Dik - Network Security Engine » Sun, 14 Apr 1996 04:00:00



>I am noticing a network oddity with S10s running Solaris 2.4.  This problem
>may also plague 2.5.  When doing a traceroute, the second ICMP packet
>will timeout.  It doesn't matter if you send the traceroute from that host,
>then end result is:
>bogus% traceroute bogus
>traceroute to bogus (192.0.0.1), 30 hops max, 40 byte packets
> 1     bogus (192.0.0.1)    2ms     *       1ms

The solaris FAQ says:

6.23) Traceroute to Solaris 2.x machines gives many timeouts.

    Solaris 2.4 and later (and Solaris 2.3 w/ high rev kernel jumbo
    patches) limit the number of ICMP error message to one
    per 500 milliseconds.  To switch off this feature, use:

        /usr/sbin/ndd -set /dev/ip ip_icmp_err_interval 0

    --- end of excerpt from the FAQ

Questions marked with a * or + have been changed or added since
the FAQ was last posted

The most recently posted version of the FAQ is available from
<http://www.fwi.uva.nl/pub/solaris/solaris2/>
--
Expressed in this posting are my opinions.  They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.

 
 
 
Top

1. iptables v1.2.4 logs dropped packets that should have been allowed ???

Hi,

I hope someone can shed some light on a mistery i have:

our firewall  (also squid proxy) serves some 50 desktops for web browsing.

Everything works fine, noone complains about sites not being accessible or
sth, but in the firewall logs, i see very regularly 2 types of blocked
packets:

Jul 16 16:49:11 dobermann kernel: -drop_the_rest-IN=eth0 OUT=
MAC=00:06:5b:f7:66:96:00:00:d1:ec:fa:3b:08:00 SRC=213.199.148.12
DST=172.17.2.1 LEN=64 TOS=0x00 PREC=0x00 TTL=54 ID=11706 PROTO=TCP SPT=80
DPT=55475 WINDOW=17125 RES=0x00 ACK URGP=0

DST ip is the external interface of the proxy server. to me, this appears to
be the reply from an attempt of the squid proxy to initiate a connection
with a remote website (because of the ACK).
i see no reason why this packet would be blocked, because i can't find  the
corresponding SYN packet in my logs.
anyway, The connection between these hosts and ports in this example are
configured to be permitted.

second type of blocked packets:

Jul 16 11:57:47 dobermann kernel: -drop_the_rest-IN= OUT=eth1 SRC=172.21.3.1
DST=172.21.3.209 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=6144 PROTO=TCP SPT=3128
DPT=2408 WINDOW=16056 RES=0x00 ACK PSH FIN URGP=0
Jul 16 13:16:19 dobermann kernel: -drop_the_rest-IN= OUT=eth1 SRC=172.21.3.1
DST=172.21.3.209 LEN=1102 TOS=0x00 PREC=0x00 TTL=64 ID=25203 PROTO=TCP
SPT=3128 DPT=3384 WINDOW=6468 RES=0x00 ACK PSH URGP=0

SRC is the internal ip of the firewall / squid proxy; DST is one of the
desktop pc's used to surf the web.

this packet looks like it's the squid that is forwarding the received web
page back to the requesting client (because of the ACK and PSH bits set).
the source port is 3128, where we have configured our proxy to listen to.

to me this doesn't make sence: it seems almost like iptables has forgotten
about the already established connection and seems to drop the packet
because it can't find it in the connection tracking table.

our firewall is iptables v1.2.4 running on redhat advanced server 2.1.
the firewall was setup via fwbuilder, with connection tracking enabled for
most of the rules (and definitely for the 'allow squid traffic' rule).
cat /proc/sys/net/ipv4/conntrack_max is 32760
cat /proc/net/ip_conntrack | wc -l is 172 (i assume these 2 variables are
related ?).

thx,

Tom.

2. Complete newbie-ness questions (I think)

3. PPP dropped packets and kernel 2.4.x

4. Blocking Pipes unblocking themselves...

5. Dropped packets with 3Com cards and 2.4 kernel

6. micro-soft gets award for thinking up meaningless marketing slogans

7. Bizarre poll() problem under Solaris 2.4

8. Sun ONE Starter Kit

9. Bizarre Disk Problem When Moving From SunOS to Solaris 2.4

10. help solaris 2.4 drops daemon's

11. Dropped packets, bogus packets and errors with SMC Elite 16 Plus

12. Packet sniffing with Solaris 2.4


All times are UTC
Board index