Date: Thu, 30 Dec 2004 18:12:14 +0000 (GMT) From: Robert Watson <rwatson@freebsd.org> To: Gerrit =?ISO-8859-1?Q?K=FChn?= <gerrit@pmp.uni-hannover.de> Cc: freebsd-stable@freebsd.org Subject: Re: Strange networking problems after update 5.2.1->5.3 Message-ID: <Pine.NEB.3.96L.1041230180625.71776H-100000@fledge.watson.org> In-Reply-To: <20041230135235.060bcd83@arc.pmp.uni-hannover.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 30 Dec 2004, Gerrit K=FChn wrote:
> I recently updated my old Compaq Armada 1500c from 5.2.1 to 5-stable. 5.2=
=2E1
> worked fine, the update went without any noticable problem according to t=
he
> docs. 5.3 behaves well apart from a strange networking problem.
> The notebook lives in a /16 subnet with a /16 netmask and has a 16bit
> NE2000 PCMCIA-card (Longshine).
>=20
> Things that do work:
> - ping to hosts in /24
> - ssh to hosts in /24
> - nis with a server in /24
>=20
> Things that don't work:
> - ping from any host
> - ping to hosts outside /24
> - nfs
> - query dns in /16
> - connecting ntp server in /16
The summary appears to be "known local things work, less local things
don't", although for the NFS instance it's unclear if that's local or not.=
=20
This suggests a routing or ARP problem.
I think I'd begin diagnosing the problem by checking the routing and arp
configurations to make sure that the configuration seems alright (or at
least, to see if any symptoms are visible). This would mean doing things
like:
route -n get default
route -n get {host in /24}
route -n get {host in /16}
Check "arp -a" and make sure that the default gateway is what you expect,
and check to make sure it's hardware address is right. You may want to
compare against what you see on another machine on the segment. Make sure
you can ping the default gateway.
Next, I'd get out a packet sniffer and look for on-the-wire problems -- in
particular, to make sure that packets destined for non-local destinations
are getting stamped with the right destination hardware address (that of
the right default gateway). I'd load up a sniffer on the remote system
and see if the problem is that your outgoing traffic doesn't get there, or
if it's the return traffic that's failing to be properly received. I'd
use the sniffer also to inspect the return traffic and make sure it's what
is expected.
Somewhere during all of this, you will probably find the broken bit --
packets missing at some step, the wrong address, or the like. If you find
anything that isn't fixed via a configuration change (i.e., failed
checksums, no way to explain the address being put in the packet, etc),
let us know.
Robert N M Watson
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1041230180625.71776H-100000>