On Thu, Jul 06, 2006 at 07:11:57PM -0700, Atanas wrote: > Pyun YongHyeon said the following on 7/6/06 6:03 PM: > > > >Hmm, that's strange. I've double checked that stock em(4) didn't > >generate ARP packets when its addresses were changed. So I made > >em(4) generate ARP. Could you see a gratuitous ARP with tcpdump > >when you change its address? > > > I just left a "tcpdump -n arp host 10.10.64.40" on a third machine > sniffing around and tested all em module versions I had (the stock 6.1, > 6-STABLE and 6-STABLE with your patch), but got silence on all three: >
That's odd. I've tested it on CURRENT and I could see the ARP packet. Are you sure you patched correctly? If so I have to build a RELENG_6 machine and give it try. > EM# ifconfig em1 inet alias 10.10.64.40 > <nothing> > EM# ifconfig em1 inet -alias 10.10.64.40 > <nothing> > It's normal. > The fxp driver appears to send something on startup and nothing on > shutdown: > > FXP# ifconfig fxp0 inet alias 10.10.64.40 > 18:41:54.584059 arp who-has 10.10.64.40 tell 10.10.64.40 > FXP# ifconfig fxp0 inet -alias 10.10.64.40 > <nothing> > > When I manually arping the em alias after startup (i.e. simulate what > fxp does), everything works as expected: > > EM# ifconfig em1 inet alias 10.10.64.40 > <nothing> > EM# arping -c1 -S10.10.64.40 10.10.64.40 > 18:46:07.808701 arp who-has 10.10.64.40 tell 10.10.64.40 Because arping requested it em(4) generated it. > EM# ifconfig em1 inet -alias 10.10.64.40 > <nothing> > > It appears that this is what the em driver is supposed to do, or at > least fxp does it in this way. > No, it's an em(4) driver bug. fxp(4)'s behavior is correct. > >This is other issue. em(4) performs two time-consuming operations > >in its initialization routine. One is DMA tag/map creation and the > >other is checksumming EEPROM contents in init routine. > >I have an experimental patch for it but let's fix one at a time. > > > OK, let's put that aside for now. > > Regards, > Atanas > -- Regards, Pyun YongHyeon _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"