On 2014-Apr-21, at 6:28 AM, Jim Pingle <li...@pingle.org> wrote: > <snip'd> > > The Spoofed MAC address issue was a problem in the past with certain > drivers that sounds very similar because it got into a chicken-and-egg > scenario that went a little something like this: > > * pfSense sets the MAC address > * The NIC driver resets its own link on the MAC change > * The link down/up triggered pfSense to reconfigure the NIC > * pfSense sets the MAC address again while reconfiguring the NIC > * The NIC driver resets its own link on the MAC change > * The link down/up triggered pfSense to reconfigure the NIC > * [lather, rinse, repeat] > > We added some extra checks before resetting the MAC to prevent that sort > of thing from being a problem though, but it's possible that the HME NIC > is resetting its link when some _other_ setting is being applied. If you > have any special configuration on the NIC (spoofed MAC, custom MTU, > specific link speed, etc) it would help to know. > > Jim
FYI, in my case there was no MAC spoofing and the issue occurred when an hme port was used for a LAN and/or WAN interface. I don't have the resources, right now, but it'd be good if someone could try a "raw" OS-only install and see whether the issue exists there. Presumably that would eliminate pfSense's code or make it the more likely source. Again, in my case, it was only necessary to have the link go down once (e.g., unplug/re-plug the cable) and the runaway cycle was started ... so a native OS-only test should be easy. Given that the hme's are inexpensive, still readily available, seem to "last forever" and are very reliable, it's kind of a shame not to be able to use them any more (yes, I dp have some Scottish heritage). _______________________________________________ List mailing list List@lists.pfsense.org https://lists.pfsense.org/mailman/listinfo/list
