From: Terry S. <ter...@gm...> - 2008-07-04 18:41:44
|
I've done a bit more digging into this, as my system (Intel Mac Pro) was having problems receiving frames. Oddly enough, if I fired up tcpdump -i en1 -vvvv or some such, I would begin seeing the frames. This led me to believe that the multicast settings weren't taking effect on my system. I've added some code to try and determine if the multicast set fails, and attempt to set promiscuous mode in that case, but after reading this E-mail thread again, maybe that's not the right behavior? I suppose I can wrap that code with #ifdef __APPLE__ defines, but I don't particularly like doing that. Tom, do you think that it's safe to kick into promiscuous mode if adding multicast mode fails? The odd thing is that Mike's system appeared to be receving frames just fine... Mike you weren't running tcpdump or wireshark or anything like that in your testing were you? It certainly seems that if a multicast add failure occurs, we can't assume that the interface is properly set up to recieve frames.... - Terry On Tue, Jun 10, 2008 at 6:47 PM, Tom Judge <to...@to...> wrote: > Terry Simons wrote: > >> Hmmm interesting. There could be a bug there. I'll look into it. I did >> the original Apple dev on a PPC G5, so there might be some Intel bugs >> lurking. >> >> Also, the error about not being able to malloc is not good... that's >> scary. I'll see if I can reproduce it. ;) How much memory does your system >> have? I wonder if I didn't initialize a variable correctly and it had some >> insane default value that would cause malloc to fail... Worst case we can >> put some additional debug in and have you try again. >> >> I'll take a look at the code and see if anything obvious pops out. >> >> - Terry >> > > > It seems that I am responsible for this error message: > ioctl[SIOC{ADD/DEL}MULTI]: Device not configured > > Do you see the message during process startup or shutdown? > > From the little digging that I have just done, and what I can remember here > my attempt at explaining why I adding this code. > > To start out the BPF framer was placing the nic into promiscuous mode so > that the interface would receive packets for link level ethernet multicast > address. So during setup and teardown of the interface we blindly register > and un-register the the LLDP ethernet address with the interface MAC. > > On the FreeBSD 6.2 test systems that I was using this error would present > during lldpd shutdown and framer tear down. > > From what I can see it is down to the NIC driver to decide how to deal with > this ioctl, the drivers I have been testing on will emit this error during > shutdown (Intel em driver and Broadcom bce) but not startup. It seems that > they only support adding the address to the MAC not removing it. > > See this thread on thread on the FreeBSD net mailing list about > implementing this feature: > > http://unix.derkeiler.com/Mailing-Lists/FreeBSD/net/2008-01/msg00133.html > > > From what I can see from your debug output, it seems that your nic is > receiving the packets and passing them into bpf and lldpd. Can you please > confirm that your nic is not promisc when running lldpd? > > If the nic is not promiscuous and lldpd is receiving frames then you can > safely ignore the warning emitted during the programming of the MAC with the > multicast address. > > These warnings should have absolutely no effect on transmitting the LLDP > frame, you should see packets in and out to the following mac > 01:80:c2:00:00:0e. > > Maybe its worth checking the debug level and only calling perror if a > suitable debug level is set? That is if this error seems to be safe to > ignore. > > > I can't help you with the malloc issue I am afraid. > > > Regards > > Tom > > > > > > >> On Mon, Jun 9, 2008 at 4:22 PM, Mike Savory <ms...@nz... <mailto: >> ms...@nz...>> wrote: >> >> Hi >> >> Its not actually sending any packets, is it meant to? Do I need to >> point it at a configuration file? >> >> Looks like it may fail to open a multicast socket... >> ioctl[SIOC{ADD/DEL}MULTI]: Device not configured >> >> When it receives a packet it does this... >> >> Running RX state machine for en0 >> Copying TLV1 for MSAP Processing... >> Copying TLV2 for MSAP Processing... >> [ERROR] Unable to malloc buffer in rxProcessFrame() at line: 237! >> Decrementing RX Timers >> Displaying RX Timers >> ) rxInfoTTL: 119 >> Running RX state machine for en0 >> Decrementing RX Timers >> Displaying RX Timers >> ) rxInfoTTL: 118 >> .... >> >> >> The packet it was receiving... >> >> $ sudo tcpdump -i en0 ether dst 01:80:c2:00:00:0e >> >> 15:01:20.625892 00:00:cd:27:be:72 (oui Unknown) > 01:80:c2:00:00:0e >> (oui Unknown), ethertype Unknown (0x88cc), length 127: >> 0x0000: 0207 0400 00cd 27be 7204 0605 706f 7274 >> ......'.r...port >> 0x0010: 3106 0200 7808 0570 6f72 7431 0a00 0c39 >> 1...x..port1...9 >> 0x0020: 7839 3030 2d32 3458 5420 4154 2d39 3932 >> x900-24XT.AT-992 >> 0x0030: 3454 7369 2c20 7665 7273 696f 6e20 332e >> 4Tsi,.version.3. >> 0x0040: 322e 312d 3033 2c20 6275 696c 7420 3232 >> 2.1-03,.built.22 >> 0x0050: 2d4d -M >> >> >> >> Regards >> >> Mike >> >> >> >> On Jun 8, 2008, at 2:15 PM, Mike Savory wrote: >> >> > Hi >> > >> > Trying to build on a OSX Leopard 10.5.3 Intel Core 2 Duo (64 bit) >> > Seems to be a disagreement in the BPF code, tried >> > >> >> > |