|
From: Tom J. <to...@to...> - 2008-06-11 00:47:47
|
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
> >
>
|