On Aug 19 at 11:50, "Paul Koch" wrote: > The second problem we found was, various NICs would report that they > were "active" after doing auto negotiation, but no rx packets were > being passed into to the OS. Not sure if it was a hardware or driver > issue, but we discovered that by forcing a packet out the NIC via the > bpf interface, it would immediately start doing stuff. It was if the > auto negotiation had not really completed fully until a packet was > transmitted. This only occurred on certain types of NICs, the newer > ones. This was a problem for us because we build something called > a "remote network appliance" (RNA) which is basically FreeBSD on a > floppy and runs a statistical lan analyser. The RNA might have many > NICs in it, one with an IP, the others just connected to network > segments in promiscuous mode. Our apps couldn't monitor any traffic > because no packets had be sent out the interfaces. So, early in the > boot process we force out a couple of "Loopback" packets and everything > works just fine. > > Not sure if the second issue would be a problem for normal installations > though.
I have a feeling this is related to windows; I recently watched a windows server boot with ethereal and it did an "arp x.x.x.x is-at a:b:c:d:e:f" (or 2 or 3) first thing (it had a static IP)...so of course a nic vendor would never realize there's a problem since they only test with windows....*sigh*. Not sure how DHCP would play into that. _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
