Date: Tue, 4 Jan 2005 22:26:44 +1100 From: Peter Jeremy <PeterJeremy@optushome.com.au> 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: <20050104112644.GF34222@cirb503493.alcatel.com.au> In-Reply-To: <20050104101701.3a08b138.gerrit@pmp.uni-hannover.de> References: <20050103101654.GA51270@pmp.uni-hannover.de> <Pine.NEB.3.96L.1050103131332.46177F-100000@fledge.watson.org> <20050103155826.0fed63ea@arc.pmp.uni-hannover.de> <20050103193026.GB34222@cirb503493.alcatel.com.au> <20050104101701.3a08b138.gerrit@pmp.uni-hannover.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 2005-Jan-04 10:17:01 +0100, Gerrit Kühn wrote: >PJ> >ed0: flags=108843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 >PJ> > inet 130.75.117.37 netmask 0xffff0000 broadcast 130.75.255.255 >PJ> > ether 01:d4:ff:03:00:20 > >PJ> That's a multicast MAC address (the LSB of the first byte is 1). More > >Ok, I didn't know about this. Can you recommend any online resource where >those special things are documented? The definitive source is the IEEE 802.3 specifications which are available (free) from http://standards.ieee.org/getieee802/802.3.html If you're not trying to cure a bad case of insomnia, there are probably better overviews on the WEB but I can't quickly find them. >PJ> intelligent NICs will have an internal list of multicast MAC addresses >PJ> that they have been programmed to respond to and will ignore all other >PJ> multicast addresses (for dumber NICs, this checking should be in the >PJ> driver). This would explain the peculiar behaviour you are seeing. Upon reflection, my comments are wrong - the receiving NICs will be looking for (and typically ignoring) destination multicast frames. In your case, the source may[*] be multicast (though the response frames would be multicast). A more likely problem is that ARP packets generated by your system have the MAC address seen by the driver (as above) whereas the card is physically using it's correct address (as reported by 5.2.1) - and therefore remote systems will normally see the wrong address. You could confirm this by checking the ARP tables on some remote hosts within the same LAN and/or looking at "tcpdump -es" of some ARP packets. >Ok, 5.2.1 reported the following >Dec 28 10:15:05 lonestar kernel: ed1: address 00:e0:98:a2:a7:33, type >Linksys (16 bit) This address looks sane. >Dec 29 15:48:15 lonestar kernel: ed1: Ethernet address: 01:d4:ff:03:00:20 This address doesn't. Something in the driver is reading the wrong address. Off hand, I can't narrow it down right now. Unless someone recognizes the symptoms, you might need to look at the commits to the pccard and/or ed drivers between 5.2.1 and 5.3. [*] It's not clear whether the MAC address reported by ifconfig is actually the transmitted source MAC address. -- Peter Jeremy
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050104112644.GF34222>