Menu
▾
▴
Re: [Openlldp-users] Build for Leopard Intel
|
From: Tom J. <to...@to...> - 2008-07-06 00:42:49
|
Sorry for the late reply.
Terry Simons wrote:
> 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.
[See comment about tcpdump further down]
>
> 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?
[All comments are related to FreeBSD rather than OSX, although the user
land code is going to be similar the kernel is a completely different beast]
Looking through the add_multi function in the bpf framer, it looks like
I could be making a mistake about the lifetime of the address being
bound to the interface.
The function opens a socket on the interface and then sets/unsets the
multi cast address filter and then closes the socket. I don't know if
this is true, but what if closing the socket removes the address filter?
This would explain the error when trying to remove the address from
the interface as it shuts down, however it would not explain why we
still receive the frames on the interface.
>
> I suppose I can wrap that code with #ifdef __APPLE__ defines, but I
> don't particularly like doing that.
>
Not sure that this is and Apple problem, I have only tested on FreeBSD
not any of the other BSD's (Net, Open, DragonFly etc...), this may be a
problem there as well.
> Tom, do you think that it's safe to kick into promiscuous mode if adding
> multicast mode fails?
Other than the IOCTL failing, i'm not sure that there is a reliable way
to check that the address is programmed into the MAC, on FreeBSD anyway,
there may be ways to do this on other BPF platforms.
Maybe the fall back should be to enable ALLMULTI rather than promisc,
from a security point of view I would not want my production routers
running openlldpd if it was going to put the interfaces into promisc mode.
> 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?
>
If you test with tcpdump -p, tcpdump will not put the interface into
PROMISC, this should allow you to see if the controller is accepting the
frames.
> It certainly seems that if a multicast add failure occurs, we can't
> assume that the interface is properly set up to recieve frames....
Agreed.
Unfortunately I don't have a Mac or any other *BSD installations to test
with, although I may setup a NetBSD box for some development soon.
There is still the problem of broken hardware, that does nothing with
SOICADDMULTI. Maybe is worth adding a command line flag or two to force
putting the interfaces into promisc or allmulti rather than trying to
detect all of the complex failure modes?
Another option would be to have a flag for the timer on the remote
system and to fire an event every interval*2 to change the interface
mode (program with addmulti -> allmulti -> promisc) each time the timer
expires and no packet was received.
On a side note my original patch for init_multi had a huge nasty kludge
in it. I think it may be worth considering the attached patch.
Tom
>
> On Tue, Jun 10, 2008 at 6:47 PM, Tom Judge <to...@to...
> <mailto: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...> <mailto: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
> >
>
>
>
|
