Re: problem with vr0
On Wed, Feb 03, 1999 at 12:42:01PM +0800, Chia-liang Kao wrote: 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. ... I use this driver as well, and have had conversations with Bill Paul before on this. It is now working well enough for my needs (but not anywhere resembling perfect -- transfers either direction have to be initiated from a different host). Maybe your machine and my machine that flakes out are similar: [excerpts from dmesg] CPU: AMD Am5x86 Write-Back (486-class CPU) Origin = AuthenticAMD Id = 0x4f4 Stepping=4 Features=0x1FPU real memory = 67108864 (65536K bytes) chip0: SiS 85c496 rev 0x31 on pci0.5.0 vr0: VIA VT3043 Rhine I 10/100BaseTX rev 0x06 int a irq 9 on pci0.13.0 vr0: Ethernet address: 00:a0:0c:c0:03:c1 vr0: autoneg complete, link status good (half-duplex, 10Mbps) The best conclusion I could come up with is that particular PCI chipset is flakey [maybe the entire chipset]. Only one pci card I have tried in that system has worked properly, and that was a display adapter -- this is out of about 6 different PCI cards of various types. -- Zach Heilig z...@uffdaonline.net / Zach Heilig z...@gaffaneys.com Americans are sensitive about their money, and since this was the first major change in the greenback in nearly 70 years, a radical redesign might have been too much for consumers to comprehend -- John Iddings [COINage, Feb. 1999]. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: problem with vr0
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 wp...@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 AddressIpkts IerrsOpkts Oerrs Coll de0 1500 Link 00.80.c8.46.1e.d4 313987 3411118717 185 2651 de0 1500 140.112.240/2 140.112.240.59313987 3411118717 185 2651 vr0 1500 Link 00.80.c8.ef.82.09 16 015804 0 0 vr0 1500 192.168.100 192.168.100.2 16 015804 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
Re: problem with vr0
* From: Bill Paul wp...@skynet.ctr.columbia.edu * Date: Wed, 3 Feb 1999 09:26:24 -0500 (EST) * * 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.) Certainly not, sorry that I didn't specify precisely. I meant we used the hub very well connecting us and the outside world, and then we decided to use the hub for internal connection only. So the hub is now connecting our vr0's and nothing else. (Of course, the power adapter is connected. :) * - 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. :) We are poor students, so the easiest test has been performed right after we can't get the vr0s to work. (actually it's mine, his works very fine) We even swapped our cards and the result (the ping/trafshow test) is the same. Also, the vr0 currently on my box was originally his, and he used the card to connect outside world in the past. Shouldn't be a kernel issue, since I have tried to get it right by booting his kernel. Anyway, I'll try the first two tests tomorrow. (Ya, you know it, I'll steal one.) * vr0 1500 Link 00.80.c8.ef.82.09 16 015804 0 0 * vr0 1500 192.168.100 192.168.100.216 015804 0 0 * * Hm... No transmit or receive errors. I wonder what all the output traffic is * though. When I ping him, he can receive my packets and replies, while I can't get his reply. I think that's where th output packet came from. (ie the icmp outgoing packets when I ping him). And `netstat -in' on his box shows the input and output packets on vr0 are nearly identical. * 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. The difference of the above two arp -d/ping are: the first one have 3 `arp who-has' message and 1 arp reply and 3 icmp echo the second one have 5 `arp who-has' and 1 arp reply and 1 icmp echo To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: problem with vr0
Of all the gin joints in all the towns in all the world, Chia-liang Kao had to walk into mine and say: * 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.) Certainly not, sorry that I didn't specify precisely. I meant we used the hub very well connecting us and the outside world, and then we decided to use the hub for internal connection only. So the hub is now connecting our vr0's and nothing else. (Of course, the power adapter is connected. :) Ah, okay. My bad. It sure looked like you were saying you had everything attached to the same hub. We even swapped our cards and the result (the ping/trafshow test) is the same. Also, the vr0 currently on my box was originally his, and he used the card to connect outside world in the past. Shouldn't be a kernel issue, since I have tried to get it right by booting his kernel. What kind of machine/CPU does your friend have? Anyway, I'll try the first two tests tomorrow. (Ya, you know it, I'll steal one.) * vr0 1500 Link 00.80.c8.ef.82.09 16 015804 0 0 * vr0 1500 192.168.100 192.168.100.216 015804 0 0 * * Hm... No transmit or receive errors. I wonder what all the output traffic is * though. When I ping him, he can receive my packets and replies, while I can't get his reply. I think that's where th output packet came from. (ie the icmp outgoing packets when I ping him). And `netstat -in' on his box shows the input and output packets on vr0 are nearly identical. Hm. I have some more questions: - In your first posting, you mentioned this: vr0: VIA VT3043 Rhine I 10/100BaseTX rev 0x06 int a irq 12 on pci0.19.0 IRQ 12 is normally used by the mouse (if you have a PS/2 mouse). Do you have a mouse or PS/2 mouse port on this machine? (I suspect you don't but I have to ask.) - How many PCI bus slots does your machine have? - Have you tried putting the vr0 card in a different slot? Have you tried putting it in the slot where the de0 card is now? - What PCI chipset do you have? The test machine in which I currently have my sample VIA Rhine card installed is an Intel Pentium 200 system that says the following: chip0 Intel 82437VX PCI cache memory controller rev 1 on pci0:0:0 chip1 Intel 82371SB PCI-ISA bridge rev 1 on pci0:7:0 chip2 Intel 82371SB IDE interface rev 0 on pci0:7:1 [...] vr0 VIA VT3043 Rhine I 10/100BaseTX rev 6 int a irq 9 on pci0:15:0 vr0: Ethernet address: 00:a0:0c:c0:01:e7 vr0: autoneg complete, no carrier - Can you show me the output of the following: pciconf -r pci0:19:0 0xc I want to see what the latency timer setting looks like. This may be something do to with your particular PCI chipset or motherboard; unfortunately, I have only Intel systems here so it's hard to duplicate your exact setup. -Bill -- = -Bill Paul(212) 854-6020 | System Manager, Master of Unix-Fu Work: wp...@ctr.columbia.edu | Center for Telecommunications Research Home: wp...@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 majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: problem with vr0
* From: Bill Paul wp...@skynet.ctr.columbia.edu * Date: Wed, 3 Feb 1999 11:12:59 -0500 (EST) * * What kind of machine/CPU does your friend have? my friend's: CPU: Pentium II (233.86-MHz 686-class CPU) Origin = GenuineIntel Id = 0x634 Stepping=4 Features=0x80f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,MMX chip0: Host to PCI bridge (vendor=8086 device=7180) rev 0x03 on pci0.0.0 chip1: PCI to PCI bridge (vendor=8086 device=7181) rev 0x03 on pci0.1.0 chip2: Intel 82371AB PCI to ISA bridge rev 0x01 on pci0.4.0 ide_pci0: Intel PIIX4 Bus-master IDE controller rev 0x01 on pci0.4.1 chip3: Intel 82371AB Power management controller rev 0x01 on pci0.4.3 vr0: VIA VT3043 Rhine I 10/100BaseTX rev 0x06 int a irq 10 on pci0.11.0 vr0: Ethernet address: 00:80:c8:ef:3c:3f vr0: autoneg complete, link status good (half-duplex, 10Mbps) Mine: CPU: Pentium/P54C (133.64-MHz 586-class CPU) Origin = GenuineIntel Id = 0x52c Stepping=12 Features=0x1bfFPU,VME,DE,PSE,TSC,MSR,MCE,CX8 chip0: Intel 82437VX PCI cache memory controller rev 0x01 on pci0.0.0 chip1: Intel 82371SB PCI to ISA bridge rev 0x01 on pci0.7.0 ide_pci0: Intel PIIX3 Bus-master IDE controller rev 0x00 on pci0.7.1 vr0: VIA VT3043 Rhine I 10/100BaseTX rev 0x06 int a irq 12 on pci0.19.0 vr0: Ethernet address: 00:80:c8:ef:82:09 vr0: autoneg complete, link status good (half-duplex, 10Mbps) * Hm. I have some more questions: * * - In your first posting, you mentioned this: * vr0: VIA VT3043 Rhine I 10/100BaseTX rev 0x06 int a irq 12 on pci0.19.0 * IRQ 12 is normally used by the mouse (if you have a PS/2 mouse). Do you * have a mouse or PS/2 mouse port on this machine? (I suspect you don't but * I have to ask.) No, I use a mouse connected to com port. Actually we thought of the problem caused by irq conflicts, and we made sure it wasn't happening. It is very strange that when I used the incorporated diagnose program, I can connect to my friend's dfe530, running the same program. * - How many PCI bus slots does your machine have? I have 3 PCI bus slots. It's quite an old machine. * - Have you tried putting the vr0 card in a different slot? Have you tried * putting it in the slot where the de0 card is now? Yes, I had previously done exactly the same test you mentioned. * - What PCI chipset do you have? The test machine in which I currently have * my sample VIA Rhine card installed is an Intel Pentium 200 system that * says the following: As you can see in the top of this mail, my chipset configuration seemed to be identical as yours. * - Can you show me the output of the following: * * pciconf -r pci0:19:0 0xc * * I want to see what the latency timer setting looks like. It shows `0x2008' To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: problem with vr0
Of all the gin joints in all the towns in all the world, Chia-liang Kao
had to walk into mine and say:
[chop]
* - Can you show me the output of the following:
*
* pciconf -r pci0:19:0 0xc
*
* I want to see what the latency timer setting looks like.
It shows `0x2008'
Hmm... Alright, I have a patch I'd like you to try. I don't know that
this will really have an effect, but I'm curious to see what it does.
If this doesn't work, then the only other thing I can think of is if
you can give me login access to your machine so that I can try some
experiments.
Anyway, to apply the patch, do the following:
- Save this message to /tmp/vr.patch (or something similar).
- Become root.
- Type the following:
# cd /sys/pci
# patch /tmp/vr.patch
- Compile a new kernel and boot it.
Let me know if this has any effect on the card's behavior.
-Bill
--
=
-Bill Paul(212) 854-6020 | System Manager, Master of Unix-Fu
Work: wp...@ctr.columbia.edu | Center for Telecommunications Research
Home: wp...@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
=
*** ../CVSWORK/sys_pci/if_vr.c Mon Feb 1 16:25:52 1999
--- if_vr.c Wed Feb 3 16:11:24 1999
***
*** 899,905
vm_offset_t pbase, vbase;
#endif
u_char eaddr[ETHER_ADDR_LEN];
! u_int32_t command;
struct vr_softc *sc;
struct ifnet*ifp;
int media = IFM_ETHER|IFM_100_TX|IFM_FDX;
--- 899,905
vm_offset_t pbase, vbase;
#endif
u_char eaddr[ETHER_ADDR_LEN];
! u_int32_t command, lat;
struct vr_softc *sc;
struct ifnet*ifp;
int media = IFM_ETHER|IFM_100_TX|IFM_FDX;
***
*** 988,993
--- 988,1002
goto fail;
}
+ /* bump up the latency timer a little */
+ command = pci_conf_read(config_id, VR_PCI_LATENCY_TIMER);
+ lat = (command 0xFF00) 8;
+ if (lat 64) {
+ command = 0x00FF;
+ command |= 0x4000;
+ pci_conf_write(config_id, VR_PCI_LATENCY_TIMER, command);
+ }
+
/* Reset the adapter. */
vr_reset(sc);
***
*** 1675,1680
--- 1684,1692
VR_CLRBIT(sc, VR_TXCFG, VR_TXCFG_TX_THRESH);
VR_SETBIT(sc, VR_TXCFG, VR_TXTHRESH_STORENFWD);
+
+ /* Adjust configuration a little */
+ CSR_WRITE_2(sc, VR_BCR0, 0x0006);
/* Init circular RX list. */
if (vr_list_rx_init(sc) == ENOBUFS) {
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: problem with vr0
Of all the gin joints in all the towns in all the world, Chia-liang Kao had to walk into mine and say: I have problem with my newly bought D-link DFE530TX on my -current (which is very new). I have tested my NIC using the master/slave mode program came with my NIC with my room mate. And the results show the NIC work correctly. The most strange thing is that I can see the ethernet address of the other ip, see the following infomation. But I can't get the interface to work at all. AG!!! I really don't want to get mad at you personally, but this is really starting to annoy me. Virtually every time anybody reports a problem, the only thing they ever say is it doesn't work. WHAT DOESN'T WORK EXACTLY!?! Describe the problem(s)!! Show us examples!! Show us error messages!! Does it catch fire?! Does it spit pea soup at you and speak in tongues?! Does it lie around the house all day and refuse to cut its hair and get a job!? WHAT!! You have not explained exactly what is going wrong. You have not explained what it is that you're trying to do which isn't working. You have not explained how you came to the conclusion that the card isn't working. Show us what happens if you type 'ping 192.168.100.1'. Don't attempt to paraphrase the error messages: quote them exactly. Does ping not illustrate the problem accurately? Fine: choose another example and show us the results. -Bill -- = -Bill Paul(212) 854-6020 | System Manager, Master of Unix-Fu Work: wp...@ctr.columbia.edu | Center for Telecommunications Research Home: wp...@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 majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: problem with vr0
I'm really sorry about this, Bill. I'll be very careful and make a recheck before sending out problem report next time. And really thank you for shouting at me instead of leaving my problem along. 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. So we're starting to doubt the problem is the receiving function of my side. And we test again with `trafshow'. Then I found he does receive my packet and replies when I ping him, while I can only see the packets I sent out but no packets from his side. But sometimes it works for a tiny second, like the following: # traceroute i1 traceroute to i1 (192.168.100.1), 30 hops max, 40 byte packets 1 i1 (192.168.100.1) 0.720 ms * * * From: Bill Paul wp...@skynet.ctr.columbia.edu * Date: Tue, 2 Feb 1999 14:20:11 -0500 (EST) * * You have not explained exactly what is going wrong. You have not * explained what it is that you're trying to do which isn't working. * You have not explained how you came to the conclusion that the card * isn't working. Show us what happens if you type 'ping 192.168.100.1'. * Don't attempt to paraphrase the error messages: quote them exactly. * Does ping not illustrate the problem accurately? Fine: choose another * example and show us the results. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: problem with vr0
Of all the gin joints in all the towns in all the world, Chia-liang Kao had to walk into mine and say: I'm really sorry about this, Bill. I'll be very careful and make a recheck before sending out problem report next time. And really thank you for shouting at me instead of leaving my problem along. Shouting is my specialty. I get a lot of practice. 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? So we're starting to doubt the problem is the receiving function of my side. And we test again with `trafshow'. Then I found he does receive my packet and replies when I ping him, while I can only see the packets I sent out but no packets from his side. But sometimes it works for a tiny second, like the following: # traceroute i1 traceroute to i1 (192.168.100.1), 30 hops max, 40 byte packets 1 i1 (192.168.100.1) 0.720 ms * * Are you using any unusual networking tricks, like network address translation or firewalling or IP aliasing? People tend to forget to mention things like that. There are some things I'm curious about: - 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.) - Do you see any suspicious messages when you do a dmesg to look at the kernel message buffer? The vr driver should report receive errors if it encounters any. - 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. -Bill -- = -Bill Paul(212) 854-6020 | System Manager, Master of Unix-Fu Work: wp...@ctr.columbia.edu | Center for Telecommunications Research Home: wp...@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 majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: problem with vr0
* From: Bill Paul wp...@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. * Are you using any unusual networking tricks, like network address * translation or firewalling or IP aliasing? People tend to forget to * mention things like that. There are some things I'm curious about: No, that's why I typed a `ipfw list' in the very first mail which indicates I have no firewall configuration in my kernel at all. * - 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 AddressIpkts IerrsOpkts Oerrs Coll de0 1500 Link 00.80.c8.46.1e.d4 313987 3411118717 185 2651 de0 1500 140.112.240/2 140.112.240.59313987 3411118717 185 2651 vr0 1500 Link 00.80.c8.ef.82.09 16 015804 0 0 vr0 1500 192.168.100 192.168.100.2 16 015804 0 0 * - Do you see any suspicious messages when you do a dmesg to look at the * kernel message buffer? The vr driver should report receive errors if * it encounters any. Not at all, only `vr0: promiscuous mode enabled' when starting tcpdump. * - 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 and here is the result of the same test done on 192.168.100.1 (with the target changed to 192.168.100.2): ping -c 5 192.168.100.2 PING 192.168.100.2 (192.168.100.2): 56 data bytes 14:36:01.999162 0:80:c8:ef:3c:3f ff:ff:ff:ff:ff:ff 0806 60: arp who-has 192.168.100.2 tell 192.168.100.1 14:36:03.008614 0:80:c8:ef:3c:3f ff:ff:ff:ff:ff:ff 0806 60: arp who-has 192.168.100.2 tell 192.168.100.1 14:36:04.018622 0:80:c8:ef:3c:3f ff:ff:ff:ff:ff:ff 0806 60: arp who-has 192.168.100.2 tell 192.168.100.1 14:36:05.028656 0:80:c8:ef:3c:3f ff:ff:ff:ff:ff:ff 0806 60: arp who-has 192.168.100.2 tell 192.168.100.1 14:36:06.038664 0:80:c8:ef:3c:3f ff:ff:ff:ff:ff:ff 0806 60: arp who-has 192.168.100.2 tell 192.168.100.1 14:36:14.106056 0:80:c8:ef:3c:3f ff:ff:ff:ff:ff:ff 0800 142: 192.168.100.1.1090 192.168.100.255.111: udp 100 14:36:14.106075 0:80:c8:ef:3c:3f ff:ff:ff:ff:ff:ff 0800 142: 192.168.100.1.1090 192.168.100.255.111: udp 100 --- 192.168.100.2 ping statistics --- 5 packets transmitted, 0 packets received, 100% packet loss To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
