From: Jason Opperisano (opie817west.com)
Date: Tue Aug 03 2004 - 08:16:41 CDT

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

On Mon, 2004-08-02 at 17:18, Todd Pytel wrote:
> Two more bits of information I realized are probably relevant:
>
> 1) While the router NAT's the workstations for Internet access, it does
> not do so for local client-server interactions. The server talks to the
> workstations via the 192.168.0.x addresses. So it does not appear that
> NAT has anything to do with my problems.
>
> 2) The captures I posted were done on the interface of the router facing
> the workstations. A simultaneous capture on the server-facing interface
> shows that no traffic passes through for the denied SMB and IPP
> connections. That is, the capture on the server-facing interface shows
> the successful NetBIOS name query and then a successful DNS query a few
> seconds later, but nothing in between. From this, I infer that the
> router is not "reacting" to anything on the server-side of the network.
> Whatever is causing the ICMP messages comes from the router itself.
>
> On Mon, 2 Aug 2004 15:47:03 -0500
> Todd Pytel <tppytelsophrosune.org> wrote:
>
> > What originally looked like a Samba problem has led back to my router
> > running 3.4. The crux of the problem is that, shortly after my
> > workstations mount an NFS share from a server, other IP traffic to
> > that same server is briefly denied with an ICMP "Host unreachable"
> > message.
> >
> > (Details snipped)

ICMP Host Unreachables from a router mean that the router did not get a
reply to it's ARP request on the segment attached to the server for the
server's MAC address.

Verify this on the router with:

        tcpdump -n -nn -p -i <SERVER SEGMENT IF> arp
        
My guess is that you'll see a bunch of:

        arp who-has <SERVER IP> tell <ROUTER IP>
        
Without seeing:

        arp reply <SERVER IP> is-at <SERVER MAC>
        
As to *why* this is happening--i dunno. Could be related to load on
that network segment--maybe high rate of collisions or packet loss?

You could simultaneously on the server:

        tcpdump -n -nn -p -i <SERVER SEGMENT IF> arp
        
And see if the server is even seeing the ARP requests. If not--i'd
point the finger at the layer 2 device connecting the router and
server. If it is seeing the ARP request and just not responding (or if
something else is responding first; i.e. duplicate IP's)...maybe there's
a buggy NIC driver involved...

-j

=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~
I base my fashion taste on what doesn't itch. -- Gilda Radner
=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]