Networking help

[bscott at ntisys.com]

On Tue, 26 Nov 2002, at 8:23am, pll at lanminds.com wrote:
>> Is the system multi-homed?  If so, is there any chance it is sending the
>> packets out the wrong interface?
> 
> Yes it is multi-homed, that's how I ssh to it.  I ssh to systemB on 
> it's external interface, then to C on the internal interface.

  I meant: Is systemC multi-homed?  I was wondering if systemC is sending an
ICMP echo reply on an interface you're not paying attention to.

  In general, I would recommend ignoring everything besides systemC (or, in
this case, the class of systems which systemC belongs to).  That is what I
was doing -- I don't even recall what systems A and B were doing in your
description.  I was focusing on the single fact that systemC is apparently
receiving ICMP echo requests without responding with an echo reply.  That is
a well-delineated problem.

> The third interface is not currently configured, so it's rather tough to
> tcpdump an interface which is down ;)

wildfire# ifconfig eth0
eth0      Link encap:Ethernet  HWaddr 00:10:5A:20:55:F1  
          BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100 
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
          Interrupt:10 Base address:0xc800 

wildfire# tcpdump -i eth0
tcpdump: WARNING: eth0: no IPv4 address assigned
tcpdump: listening on eth0

  (I am not sure that is useful, but I find the fact that it works
interesting.  :)

>> Firewall rules could do this, but you've already checked that.  What about
>> ICMP rate limiting?  Does the kernel do anything like that outside of
>> IPTABLES?  I don't think it does, but maybe?
> 
> It's a pretty generic kernel, and unless icmp rate limiting is turned on
> by default, I don't believe I'm using it.

  I would not think so, either, but since I know nothing about ICMP rate
limiting (other than the fact that it exists and is available in 2.4), I
figured I would mention it.  :-)

>> Look for any reason the packet might be considered invalid.
> 
> Good idea.  Of course, I don't know what a corrupt packet looks like, but
> I assume if I see one, I'll know it :)

	tethereal -i eth0 -n -V -f icmp

  The "-V" switch gives you about as detailed an analysis as you can get.  
Of particular note, it prints checksums, and whether they match or not.  If
you're not sure how to interpret it, post the output for *one* frame, and
I/others can take a look.

  ObDisclaimer: The output of 'tethereal -V ...' includes the complete
contents of data frames from your network.  Posting such may constitute a
security risk, and/or be interpreted as a Problem by your local Network
Nazis or Corporate Gestapo.

>> If the system thinks the packet is part of an incomplete fragment, it
>> will hold it in memory for reassembly.  According to your tcpdump output,
>> the DF (Don't Fragment) bit is set... is a router somewhere ignoring that
>> bit?
> 
> Entirely possible, it's a Cisco, and we all know how they feel about
> standard protocols ;)

  Given your description of variances between nearly-identical systems, you
might also consider the possibility that the OEM of your systems had a bad
run of network interface controllers.  A marginal IC might induce
intermittent, single-bit errors that would be very hard to track down.

-- 
Ben Scott <bscott at ntisys.com>
| The opinions expressed in this message are those of the author and do not |
| necessarily represent the views or policy of any other person, entity or  |
| organization.  All information is provided without warranty of any kind.  |