Re: Strange networking problems after update 5.2.1-5.3
On Tue, 4 Jan 2005 06:30:26 +1100 Peter Jeremy [EMAIL PROTECTED] wrote about Re: Strange networking problems after update 5.2.1-5.3: PJ ed0: flags=108843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 PJinet 130.75.117.37 netmask 0x broadcast 130.75.255.255 PJether 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? 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. For sure. PJ Firstly, I presume you're not attempting to change the MAC address. Correct, I even don't know how to do this. ;-) PJ Secondly, the MAC address should be reported as part of the ed0 probe PJ message - can you have a look back through your messages file and PJ report the ed0 probe messages for both 5.2.1 and 5.3. Ok, 5.2.1 reported the following Dec 28 10:15:05 lonestar kernel: ed1: Dual Speed 10/100 Port Attached PC Card at port 0x100-0x11f irq 11 function 0 config 16 on pccard1 Dec 28 10:15:05 lonestar kernel: ed1: address 00:e0:98:a2:a7:33, type Linksys (16 bit) Dec 28 10:15:05 lonestar kernel: miibus0: MII bus on ed1 With 5.3 it says Dec 29 15:48:15 lonestar kernel: ed1: Dual Speed 10/100 Port Attached PC Card at port 0x100-0x11f irq 11 function 0 config 16 on pccard1 Dec 29 15:48:15 lonestar kernel: ed1: [GIANT-LOCKED] Dec 29 15:48:15 lonestar kernel: ed1: Ethernet address: 01:d4:ff:03:00:20 Dec 29 15:48:15 lonestar kernel: ed1: if_start running deferred for Giant Dec 29 15:48:15 lonestar kernel: type NE2000 (16 bit) I admit that I've got no clue where this new MAC is coming from. :) cu Gerrit ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Strange networking problems after update 5.2.1-5.3
In message: [EMAIL PROTECTED] Robert Watson [EMAIL PROTECTED] writes: : I've CC'd Warner Losh on the general principle that if it's a problem with : a PCCARD ethernet adapter, he might be able to help (perhaps especially if : it's possible to ship him one of the cards). I think that I have one of the cards locally... Warner ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Strange networking problems after update 5.2.1-5.3
In message: [EMAIL PROTECTED] Gerrit Kühn [EMAIL PROTECTED] writes: : Meanwhile I tried two further pcmcia cards which are 32bit (cardbus). Both : (Xircom CBE2-100 and D-Link DFE-690-TXD) result in : : cbb0: CardBus card activation failed : : It seems it's rather the pcmcia bridge that's broken than the driver for : the card itself. The notebook has a TI 1225 chip. The ed card issue is an ed driver. The TI 1225 chipset works fine in other systems, so it must be a resource issue with that specific machine. The 1225 is found typically in non-acpi machines, which have some known issues wrt memory allocation. Warner ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Strange networking problems after update 5.2.1-5.3
In message: [EMAIL PROTECTED] Gerrit Kühn [EMAIL PROTECTED] writes: : I will do so if it's the support for the cards that is broken. However, I : have tried 4 different cards now, and only one of them worked. So I'm : tending to put the blame on the pcmcia bridge and it's driver. Blame doesn't belong there, but elsewhere in the system. The second ed card is broken in the ed driver (people with other bridges have reported problems), while the cardbus activation issue almost certainly is a resource issue (because other people with TI-1225 bridge work). I'll be happy to help you track down that issue, however. Warner ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Strange networking problems after update 5.2.1-5.3
On Tue, 04 Jan 2005 03:36:53 -0700 (MST) M. Warner Losh [EMAIL PROTECTED] wrote about Re: Strange networking problems after update 5.2.1-5.3: MWL : I will do so if it's the support for the cards that is broken. MWL However, I : have tried 4 different cards now, and only one of them MWL worked. So I'm : tending to put the blame on the pcmcia bridge and MWL it's driver. MWL Blame doesn't belong there, but elsewhere in the system. The second MWL ed card is broken in the ed driver (people with other bridges have MWL reported problems), while the cardbus activation issue almost MWL certainly is a resource issue (because other people with TI-1225 MWL bridge work). I'll be happy to help you track down that issue, MWL however. Thank you very much in advance. Please tell me which information you need. cu Gerrit ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Strange networking problems after update 5.2.1-5.3
On Tue, 2005-Jan-04 10:17:01 +0100, Gerrit Kühn wrote: PJ ed0: flags=108843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 PJ inet 130.75.117.37 netmask 0x 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 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Strange networking problems after update 5.2.1-5.3
In message: [EMAIL PROTECTED] Gerrit Kühn [EMAIL PROTECTED] writes: : On Tue, 04 Jan 2005 03:36:53 -0700 (MST) M. Warner Losh [EMAIL PROTECTED] : wrote about Re: Strange networking problems after update 5.2.1-5.3: : : : MWL : I will do so if it's the support for the cards that is broken. : MWL However, I : have tried 4 different cards now, and only one of them : MWL worked. So I'm : tending to put the blame on the pcmcia bridge and : MWL it's driver. : : MWL Blame doesn't belong there, but elsewhere in the system. The second : MWL ed card is broken in the ed driver (people with other bridges have : MWL reported problems), while the cardbus activation issue almost : MWL certainly is a resource issue (because other people with TI-1225 : MWL bridge work). I'll be happy to help you track down that issue, : MWL however. : : Thank you very much in advance. : Please tell me which information you need. You've likely already sent this before... But can you send a full dmesg with hw.cbb.debug=1 and hw.cardbus.debug=1 (these are set in /boot/loader.conf) and a devinfo -r. I have a handle on the ed card showing up as NE-1000. Warner ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Strange networking problems after update 5.2.1-5.3
On Tue, 04 Jan 2005 09:27:34 -0700 (MST) M. Warner Losh [EMAIL PROTECTED] wrote about Re: Strange networking problems after update 5.2.1-5.3: MWL : Please tell me which information you need. MWL You've likely already sent this before... But can you send a full MWL dmesg with hw.cbb.debug=1 and hw.cardbus.debug=1 (these are set in MWL /boot/loader.conf) and a devinfo -r. I'm taking this into private mail, or are there others being interested in this information? cu Gerrit ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Strange networking problems after update 5.2.1-5.3
I recently updated my old Compaq Armada 1500c from 5.2.1 to 5-stable. 5.2
worked fine, the update went without any noticable problem according to the
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).
Things that do work:
- ping to hosts in /24
- ssh to hosts in /24
- nis with a server in /24
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.
Well, what surprised me most was the fact that nothing gets to this notebook
from the outside. I cannot ping it even from a host connected to the same
switch being in the same /24 subnet.
The nfs server was in /24, too.
This suggests a routing or ARP problem.
I think if there are such problems, they're the result of something else
that is broken with the pcmcia card itself (wrong initialization or
whatever).
I took the notebook home via New Year's and tried to hunt the problem down.
My network at home is somewhat simpler (192.168.1.0/24 is local,
192.168.1.253 is another notebook that is acting as NAT and default router).
route -n get default
route -n get {host in /24}
route -n get {host in /16}
Looks ok for me. netstat doesn't show any problems either.
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.
arp things look ok, but I cannot ping the router, though I can ping any
other host (the same thing I already noticed here at work). But my router at
home complains about this:
arp: ether address is multicast for IP address 192.168.1.4!
.4 is the IP of my notebook. Obviously the ping packets reach the router,
but I don't know what should be wrong with the MAC. The output of ifconfig
looks ok.
I tried diagnosing via tcpdump and noticed a rather strange behaviour on the
notebook (the host with the problem, not the router): Quite often tcpdumps
sees nothing at all, not even the obviously outgoing ping packets. In this
state I cannot interrupt it with CTRL-C. Waiting some time (minutes) lets it
suddenly see the packets, but they still don't get through to ping as
desired.
At home I was able to use nfs with .5 as server. However, I noticed that the
packets are broad-(or multi-?)casted to each and every host in my subnet. I
guess this is closely related to the arp-message above from my router.
I have two further pcmcia-cards in the router (dlink de-660 and dlink
dfe-650) which I took out to try them in the Compaq. The dfe-650 was
recognized as 8 bit ne1000 card and didn't work at all. The de-660 was
recognized correctly and worked fine.
I built an OLDCARD kernel, which was complaining about an interrupt storm on
irq 11 (this is the one all the network cards attached to). It found the
pcmcia-bridge, but didn't find any cards, so there was no network device.
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.
The best thing I can guess here is that 5.3 in contrast to 5.2.1 (all three
cards worked flawlessly with 5.2.1) has some problems dealing with my
hardware. :-)
I'm anything but a network guru and will see if I have some time to dig
further into the packets. Perhaps I can find the broken bit then.
cu
Gerrit
--
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Strange networking problems after update 5.2.1-5.3
On Mon, 3 Jan 2005, Gerrit Kühn wrote: arp things look ok, but I cannot ping the router, though I can ping any other host (the same thing I already noticed here at work). But my router at home complains about this: arp: ether address is multicast for IP address 192.168.1.4! Ah, now this is very interesting -- could you send me the output of ifconfig on the interface? Could you tell me if a tcpdump on another host shows the same hardware address as the source of packets from this host as ifconfig shows? Likewise, dmesg? A multicast source address might cause other systems to treat your system like it had the plague, with some OS's ignoring it, others not, etc. So if the router refuses to talk to your system because of its ethernet address, that might explain many of the symptoms you are seeing. 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. The best thing I can guess here is that 5.3 in contrast to 5.2.1 (all three cards worked flawlessly with 5.2.1) has some problems dealing with my hardware. :-) I'm anything but a network guru and will see if I have some time to dig further into the packets. Perhaps I can find the broken bit then. I'm guessing it's a driver problem of some sort based on the above, but a few more details as described above would be helpful in confirming that. I've CC'd Warner Losh on the general principle that if it's a problem with a PCCARD ethernet adapter, he might be able to help (perhaps especially if it's possible to ship him one of the cards). Robert N M Watson ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Strange networking problems after update 5.2.1-5.3
On Mon, 3 Jan 2005 13:19:13 + (GMT) Robert Watson [EMAIL PROTECTED] wrote about Re: Strange networking problems after update 5.2.1-5.3: RW arp things look ok, but I cannot ping the router, though I can ping RW any other host (the same thing I already noticed here at work). But RW my router at home complains about this: RW arp: ether address is multicast for IP address 192.168.1.4! RW Ah, now this is very interesting -- could you send me the output of RW ifconfig on the interface? ed0: flags=108843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 inet 130.75.117.37 netmask 0x broadcast 130.75.255.255 ether 01:d4:ff:03:00:20 RW Could you tell me if a tcpdump on another RW host shows the same hardware address as the source of packets from this RW host as ifconfig shows? tcpdump -e shows the same address on the foreign host, so does arp -a. RW Likewise, dmesg? The same, too RW A multicast source address RW might cause other systems to treat your system like it had the plague, RW with some OS's ignoring it, others not, etc. So if the router refuses RW to talk to your system because of its ethernet address, that might RW explain many of the symptoms you are seeing. Right. Meanwhile I tried two further pcmcia cards which are 32bit (cardbus). Both (Xircom CBE2-100 and D-Link DFE-690-TXD) result in cbb0: CardBus card activation failed It seems it's rather the pcmcia bridge that's broken than the driver for the card itself. The notebook has a TI 1225 chip. RW I'm anything but a network guru and will see if I have some time to RW dig further into the packets. Perhaps I can find the broken bit then. RW I'm guessing it's a driver problem of some sort based on the above, but RW a few more details as described above would be helpful in confirming RW that. Just tell me what you would like to know. RW I've CC'd Warner Losh on the general principle that if it's a problem RW with a PCCARD ethernet adapter, he might be able to help (perhaps RW especially if it's possible to ship him one of the cards). I will do so if it's the support for the cards that is broken. However, I have tried 4 different cards now, and only one of them worked. So I'm tending to put the blame on the pcmcia bridge and it's driver. cu Gerrit ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Strange networking problems after update 5.2.1-5.3
On Mon, 2005-Jan-03 15:58:26 +0100, Gerrit Kühn wrote: ed0: flags=108843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 inet 130.75.117.37 netmask 0x broadcast 130.75.255.255 ether 01:d4:ff:03:00:20 That's a multicast MAC address (the LSB of the first byte is 1). More intelligent NICs will have an internal list of multicast MAC addresses that they have been programmed to respond to and will ignore all other multicast addresses (for dumber NICs, this checking should be in the driver). This would explain the peculiar behaviour you are seeing. Firstly, I presume you're not attempting to change the MAC address. Secondly, the MAC address should be reported as part of the ed0 probe message - can you have a look back through your messages file and report the ed0 probe messages for both 5.2.1 and 5.3. -- Peter Jeremy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Strange networking problems after update 5.2.1-5.3
On Thu, 30 Dec 2004, Gerrit Kühn wrote:
I recently updated my old Compaq Armada 1500c from 5.2.1 to 5-stable. 5.2.1
worked fine, the update went without any noticable problem according to the
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).
Things that do work:
- ping to hosts in /24
- ssh to hosts in /24
- nis with a server in /24
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.
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
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
