Date: Wed, 3 Feb 1999 09:26:24 -0500 (EST) From: Bill Paul <wpaul@skynet.ctr.columbia.edu> To: clkao@CirX.ORG (Chia-liang Kao) Cc: current@FreeBSD.ORG Subject: Re: problem with vr0 Message-ID: <199902031426.JAA06705@skynet.ctr.columbia.edu> In-Reply-To: <199902030647.OAA01948@genius.cirx.org> from "Chia-liang Kao" at Feb 3, 99 02:47:45 pm
next in thread | previous in thread | raw e-mail | index | archive | help
Of all the gin joints in all the towns in all the world, Chia-liang Kao had to walk into mine and say: > * From: Bill Paul <wpaul@skynet.ctr.columbia.edu> > * Date: Wed, 3 Feb 1999 00:24:27 -0500 (EST) > * > * > I did a `ping 192.168.100.1', and there is no response and no messages > * > at all. I think the most interesting part of this is that I can see > * > both of the lights on the hub blinking when I ping 192.168.100.1; > * > while only the light of the other side blinks when he pings me. > * > * What kind of hub is this? > > It's a nonaccredited 5-port 10Bast-T hub which we used to connect > outside world via another interface (my de0 and his ed0). And when > we're trying to use this hub for internal connection only via both of > our newly bought dfe530s, we're in trouble. Whoa whoa. Wait a minute; stop right there. Let me see if I understand this. You have a 5 port hub. One port has the connection that links you to the outside world (it goes to your router/switch/whatever). Another second port connects to your machine at de0. A third port connects to your roommate's machine on his ed0. And you have your vr0 interface and your roommate's vr0 interface both connected to this _same_ hub as well? (See, this is why I yell: I can see how somebody might try this and not think that it might cause problems. If I was right there looking at your systems I could probably spot this immediately, but it was only blind luck that you happened to mention it now, otherwise I could have spent months going back and forth with you via e-mail before finally dragging this piece of information out of you.) Uhm. I dunno. That doesn't seem right somehow. It adds another variable that has to be accounted for. The problem here is that when one of you sends a packet, it will end up a) delivered to _two_ interfaces on the target host and b) it will be echoed back to the other interface on the source host. Remember: an ordinary hub just retransmits whatever it hears on one port to every otgher port. Given that you don't seem to be experiencing any transmit or receive errors on the vr0 interface, I get the feeling that this configuration may be contributing to the problem somehow. You need to do one of three things to test to see if this is your problem: - Obtain (purchase/borrow/steal) a second hub, and connect all the 192.168.100 interfaces to it all by themselves. - Connect your vr0 interface to your roommate's vr0 interface directly using a crossover cable. (A crossover cable has the transmit and receive pairs reversed on one end.) - Temporarily unplug your de0 interface and his ed0 interface from the hub and leave just the vr0 interfaces plugged in. Use arp -d to remove each others' ARP entries from your respective ARP caches so that we start fresh. If you can successfully ping each other via the 192.168.100 interfaces and exchange traffic, then you have found the problem. (This is the easiest test, and it doesn't cost anything. :) If you had a _switch_ instead of a hub, then your configuration would probably work because a switch will only deliver traffic to one port (the port where the interface with the destination ethernet address is attached) instead of all ports. (Except for broadcasts and multicasts, without extra configuration.) At least, that's my suspicion. > * - What does netstat -in show? Are there any input errors? Are there > * any input packets? (If the input packet counter keeps incrementing > * then it has to be receiving something.) > * > > There are some Ipkts but very few as you can see in the following. > > # netstat -in > Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll > de0 1500 <Link> 00.80.c8.46.1e.d4 313987 34111 18717 185 2651 > de0 1500 140.112.240/2 140.112.240.59 313987 34111 18717 185 2651 > vr0 1500 <Link> 00.80.c8.ef.82.09 16 0 15804 0 0 > vr0 1500 192.168.100 192.168.100.2 16 0 15804 0 0 Hm... No transmit or receive errors. I wonder what all the output traffic is though. > * - If you run tcpdump on the vr0 interface (tcpdump -n -e -i vr0) can > * you see the traffic from the other host? Try the following: > * > * # arp -d 192.168.100.1 > * # tcpdump -n -e -i vr0 & > * # ping -c 5 192.168.100.1 > * > * Show us the output. > > PING 192.168.100.1 (192.168.100.1): 56 data bytes > 14:32:35.481753 0:80:c8:ef:82:9 ff:ff:ff:ff:ff:ff 0806 60: arp who-has 192.168.100.1 tell 192.168.100.2 > 14:32:36.486348 0:80:c8:ef:82:9 ff:ff:ff:ff:ff:ff 0806 60: arp who-has 192.168.100.1 tell 192.168.100.2 > 14:32:36.486561 0:80:c8:ef:3c:3f 0:80:c8:ef:82:9 0806 60: arp reply 192.168.100.1 is-at 0:80:c8:ef:3c:3f > 14:32:36.486625 0:80:c8:ef:82:9 0:80:c8:ef:3c:3f 0800 98: 192.168.100.2 > 192.168.100.1: icmp: echo request > 14:32:37.496739 0:80:c8:ef:82:9 0:80:c8:ef:3c:3f 0800 98: 192.168.100.2 > 192.168.100.1: icmp: echo request > 14:32:38.506383 0:80:c8:ef:82:9 0:80:c8:ef:3c:3f 0800 98: 192.168.100.2 > 192.168.100.1: icmp: echo request > 14:32:39.516717 0:80:c8:ef:82:9 0:80:c8:ef:3c:3f 0800 98: 192.168.100.2 > 192.168.100.1: icmp: echo request > --- 192.168.100.1 ping statistics --- > 5 packets transmitted, 0 packets received, 100% packet loss Hm. Okay. Here's a slightly different test: # tcpdump -n -e -i vr0 & # arp -d 192.168.100.1 # ping -c 192.168.100.1 # arp -d 192.168.100.1 # ping -c 192.168.100.1 One possibility is that the receiver is getting stuck and has to be reset; running tcpdump to put the interface in promiscuous mode implicity reinitializes and resets the card (it happens that that's how the driver works). In the above example, we initialize the card once and then leave it alone, then run the arp -d/ping test twice. If you see the same exact results both times (i.e. the chip receives at least one frame) then the receiver is not getting wedged, since it would be receiving at least two frames correctly without having to be reset. Anyway, to sum up: I think the problem has something to do with having both interfaces on both machines attached to the same hub at the same time. If you have ever tried the same configuration before and seen it work (with different cards) then I might be inclined to think the problem is somewhere else. On the other hand, if you and your roommate were just sitting around one day and said "Gee, maybe we can use those two empty ports on the hub to connect our machines together using a private ethernet link!" then you may want to prepare yourselves to be disappointed. :) -Bill -- ============================================================================= -Bill Paul (212) 854-6020 | System Manager, Master of Unix-Fu Work: wpaul@ctr.columbia.edu | Center for Telecommunications Research Home: wpaul@skynet.ctr.columbia.edu | Columbia University, New York City ============================================================================= "It is not I who am crazy; it is I who am mad!" - Ren Hoek, "Space Madness" ============================================================================= To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199902031426.JAA06705>