Menu
▾
▴
openlldp-users
|
From: Mike S. <ms...@nz...> - 2008-06-08 21:15:23
|
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
./configure --enable-generic-framer
to no effect...
Pulled the code from cvs at SF and it seems to compile/run.....
Both the src with ./configure; make
and the xcode project (With Xcode 3.1)
$ sudo ./src/lldpd -i en1
/tmp/lldpd.sock:15
Using interface en1
Skipping interface lo0 (not en1)
Skipping interface gif0 (not en1)
Skipping interface stf0 (not en1)
Skipping interface en0 (not en1)
Skipping interface fw0 (not en1)
ioctl[SIOC{ADD/DEL}MULTI]: Device not configured
BIOCGBLEN: 4096
en1 MAC: 00:17:F2:E6:75:75
en1 IP: 10.0.1.2
en1 MTU: 4096
Skipping interface en2 (not en1)
Skipping interface en3 (not en1)
sysinfo.machine: i386
sysinfo.sysname: Darwin
sysinfo.release: 9.3.0
lldp_systemdesc: i386/Darwin 9.3.0
lldp_systemname: PB15-Leo.local.
Running RX state machine for en1
Decrementing RX Timers
Displaying RX Timers
Running RX state machine for en1
Decrementing RX Timers
Displaying RX Timers
Running RX state machine for en1
Decrementing RX Timers
Displaying RX Timers
^C[AYBABTU] We Get Signal!
[CLEAN] en1 (6)
Will test it on some LLDP devices tomorrow, when is the next release
planned....
Regards
Mike
|
|
From: Terry S. <ter...@gm...> - 2008-06-09 22:00:08
|
Hi Mike,
CVS is definitely what you want to be using for Leopard.
Check that build out and see if you notice any problems. The CVS tree is
pretty stable, but there are still a few bugs lurking. I've been extremely
busy the past several months, so I haven't had much time to really devote to
the project, but I think if we can get some testing done on CVS and people
think it looks good we'll do another drop.
Also, check out lldpneighbors (which is new in CVS). It lets you see who is
connected to you.
I might possibly be able to push a drop out this next weekend. Let me know
if you see any major issues.
- Terry
On Sun, Jun 8, 2008 at 3:15 PM, Mike Savory <ms...@nz...> 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
> ./configure --enable-generic-framer
> to no effect...
>
> Pulled the code from cvs at SF and it seems to compile/run.....
>
> Both the src with ./configure; make
> and the xcode project (With Xcode 3.1)
>
>
> $ sudo ./src/lldpd -i en1
> /tmp/lldpd.sock:15
> Using interface en1
> Skipping interface lo0 (not en1)
> Skipping interface gif0 (not en1)
> Skipping interface stf0 (not en1)
> Skipping interface en0 (not en1)
> Skipping interface fw0 (not en1)
> ioctl[SIOC{ADD/DEL}MULTI]: Device not configured
> BIOCGBLEN: 4096
> en1 MAC: 00:17:F2:E6:75:75
> en1 IP: 10.0.1.2
> en1 MTU: 4096
> Skipping interface en2 (not en1)
> Skipping interface en3 (not en1)
> sysinfo.machine: i386
> sysinfo.sysname: Darwin
> sysinfo.release: 9.3.0
> lldp_systemdesc: i386/Darwin 9.3.0
> lldp_systemname: PB15-Leo.local.
> Running RX state machine for en1
> Decrementing RX Timers
> Displaying RX Timers
> Running RX state machine for en1
> Decrementing RX Timers
> Displaying RX Timers
> Running RX state machine for en1
> Decrementing RX Timers
> Displaying RX Timers
> ^C[AYBABTU] We Get Signal!
> [CLEAN] en1 (6)
>
>
> Will test it on some LLDP devices tomorrow, when is the next release
> planned....
>
>
>
> Regards
>
> Mike
>
>
>
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________
> Openlldp-users mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openlldp-users
>
|
|
From: Mike S. <ms...@nz...> - 2008-06-09 22:45:27
|
Hi Terry OK, Progress here Using the Xcode build version ..... xcode2.4/OpenLLDP/build/Debug/OpenLLDP -i en0 My switch is seeing the Mac sh lldp nei LLDP neighbour information Port 1: remoteIndex timeMark chassisId sysName ------------------------------------------------------------------------------- 1 35239362 00-17-f2-c2-4e-35 PB15-Leo.local. And the LLDP from the switch is being processed, but still fails.... Looks like offset issues with stepping through the parameters in the packet... [STATE] [TIMER] (en0 with MSAP: 00 00 cd 27 be 72 70 6f 72 74 31 ) rxInfoTTL: 0 [STATE] [TIMER] (en0) tooManyNeighborsTimer: 0 [INT] en0 is readable! [INT] (en0) Raw BPF Frame with BPF header: [INT] BPF Header Length: 18 000 | 28 b0 4d 48 f9 92 09 00 7f 00 00 00 7f 00 00 00 | (.MH............ 010 | 12 00 01 80 c2 00 00 0e 00 00 cd 27 be 72 88 cc | ...........'.r.. 020 | 02 07 04 00 00 cd 27 be 72 04 06 05 70 6f 72 74 | ......'.r...port 030 | 31 06 02 00 78 08 05 70 6f 72 74 31 0a 00 0c 39 | 1...x..port1...9 040 | 78 39 30 30 2d 32 34 58 54 20 41 54 2d 39 39 32 | x900-24XT AT-992 050 | 34 54 73 69 2c 20 76 65 72 73 69 6f 6e 20 33 2e | 4Tsi, version 3. 060 | 32 2e 31 2d 30 33 2c 20 62 75 69 6c 74 20 32 32 | 2.1-03, built 22 070 | 2d 4d 61 79 2d 32 30 30 38 0e 04 00 14 00 14 10 | -May-2008....... 080 | 0e 07 06 00 00 cd 27 be 72 01 00 00 00 00 00 00 | ......'.r....... 090 | 00 | . [INT] (en0) Raw BPF Frame without BPF header: 000 | 01 80 c2 00 00 0e 00 00 cd 27 be 72 88 cc 02 07 | .........'.r.... 010 | 04 00 00 cd 27 be 72 04 06 05 70 6f 72 74 31 06 | ....'.r...port1. 020 | 02 00 78 08 05 70 6f 72 74 31 0a 00 0c 39 78 39 | ..x..port1...9x9 030 | 30 30 2d 32 34 58 54 20 41 54 2d 39 39 32 34 54 | 00-24XT AT-9924T 040 | 73 69 2c 20 76 65 72 73 69 6f 6e 20 33 2e 32 2e | si, version 3.2. 050 | 31 2d 30 33 2c 20 62 75 69 6c 74 20 32 32 2d 4d | 1-03, built 22-M 060 | 61 79 2d 32 30 30 38 0e 04 00 14 00 14 10 0e 07 | ay-2008......... 070 | 06 00 00 cd 27 be 72 01 00 00 00 00 00 00 00 | ....'.r........ [INT] Got an LLDP frame 127 bytes long on en0! Running RX state machine for en0 [STATE] [en0] RX_WAIT_FOR_FRAME -> DELETE_INFO [STATE] [en0] DELETE_INFO -> RX_FRAME [STATE] [ERROR] Illegal Transition: [en0] DELETE_INFO -> RX_FRAME [INT] (en0) Processing Frame: 000 | 01 80 c2 00 00 0e 00 00 cd 27 be 72 88 cc 02 07 | .........'.r.... 010 | 04 00 00 cd 27 be 72 04 06 05 70 6f 72 74 31 06 | ....'.r...port1. 020 | 02 00 78 08 05 70 6f 72 74 31 0a 00 0c 39 78 39 | ..x..port1...9x9 030 | 30 30 2d 32 34 58 54 20 41 54 2d 39 39 32 34 54 | 00-24XT AT-9924T 040 | 73 69 2c 20 76 65 72 73 69 6f 6e 20 33 2e 32 2e | si, version 3.2. 050 | 31 2d 30 33 2c 20 62 75 69 6c 74 20 32 32 2d 4d | 1-03, built 22-M 060 | 61 79 2d 32 30 30 38 0e 04 00 14 00 14 10 0e 07 | ay-2008......... 070 | 06 00 00 cd 27 be 72 01 00 00 00 00 00 00 00 | ....'.r........ [INT] LLPDU Dst: 01 80 c2 00 00 0e [INT] LLPDU Src: 00 00 cd 27 be 72 [INT] LLPDU Ethertype: 88cc [TLV] Processing TLV #: 1 Copying TLV1 for MSAP Processing... [TLV] Processing TLV #: 2 [TLV] Setting temp->next to 1004E0 Copying TLV2 for MSAP Processing... [MSAP] MSAP TLV1 Length: 7 [MSAP] MSAP TLV2 Length: 6 [MSAP] MSAP is 11 bytes: 00 00 cd 27 be 72 70 6f 72 74 31 000 | 00 00 cd 27 be 72 70 6f 72 74 31 | ...'.rport1 [TLV] Processing TLV #: 3 [TLV] Setting temp->next to 1004C0 [TLV] Processing TLV #: 4 [TLV] Setting temp->next to 100530 [TLV] Processing TLV #: 5 [ERROR] Unable to malloc buffer in rxProcessFrame() at line: 237! [TLV] We have a(n) 11 byte MSAP! [MSAP] Setting rxInfoTTL to: 120 [MSAP] MSAP Length: B [MSAP] MSAP Cache Hit on en0 [MSAP] MSAP cache: 100300 [MSAP] MSAP ID: 00 00 cd 27 be 72 70 6f 72 74 31 [MSAP] MSAP Length: B [MSAP] MSAP Next: 0 [TLV] Destroy TLV List [TLV] Entering Destroy loop [TLV] current = 100560 [TLV] current->next = 100420 [TLV] Freeing TLV Info String. [TLV] Freeing TLV. [TLV] Freeing TLV List Node. [TLV] current = 100420 [TLV] current->next = 100400 [TLV] Freeing TLV Info String. [TLV] Freeing TLV. [TLV] Freeing TLV List Node. [TLV] current = 100400 [TLV] current->next = 100470 [TLV] Freeing TLV Info String. [TLV] Freeing TLV. [TLV] Freeing TLV List Node. [TLV] current = 100470 [TLV] current->next = 0 [TLV] Freeing TLV Info String. [TLV] Freeing TLV. [TLV] Freeing TLV List Node. Decrementing RX Timers Displaying RX Timers [STATE] [TIMER] (en0 with MSAP: 00 00 cd 27 be 72 70 6f 72 74 31 ) rxInfoTTL: 0 [STATE] [TIMER] (en0) tooManyNeighborsTimer: 0 [STATE] en0 -> TX_IDLE [STATE] [TIMER] (en0) txTTL: 120 [STATE] [TIMER] (en0) txTTR: 19 [STATE] [TIMER] (en0) txDelayWhile: 0 [STATE] [TIMER] (en0) txShutdownWhile: 0 Running RX state machine for en0 [STATE] [en0] RX_FRAME -> UPDATE_INFO Decrementing RX Timers Displaying RX Timers [STATE] [TIMER] (en0 with MSAP: 00 00 cd 27 be 72 70 6f 72 74 31 Anything else I can do to help (given that I am a network geek, but not a programer...) Once I get it building and working (and you can do another drop from CVS), I want to add a port for it to MacPorts. < http://www.macports.org/ > Cheers Mike On Jun 9, 2008, at 3:00 PM, Terry Simons wrote: > Hi Mike, > > CVS is definitely what you want to be using for Leopard. > > Check that build out and see if you notice any problems. The CVS > tree is pretty stable, but there are still a few bugs lurking. I've > been extremely busy the past several months, so I haven't had much > time to really devote to the project, but I think if we can get some > testing done on CVS and people think it looks good we'll do another > drop. > > Also, check out lldpneighbors (which is new in CVS). It lets you > see who is connected to you. > > I might possibly be able to push a drop out this next weekend. Let > me know if you see any major issues. > > - Terry > > On Sun, Jun 8, 2008 at 3:15 PM, Mike Savory <ms...@nz...> 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 > ./configure --enable-generic-framer > to no effect... > > Pulled the code from cvs at SF and it seems to compile/run..... > > Both the src with ./configure; make > and the xcode project (With Xcode 3.1) > > > $ sudo ./src/lldpd -i en1 > /tmp/lldpd.sock:15 > Using interface en1 > Skipping interface lo0 (not en1) > Skipping interface gif0 (not en1) > Skipping interface stf0 (not en1) > Skipping interface en0 (not en1) > Skipping interface fw0 (not en1) > ioctl[SIOC{ADD/DEL}MULTI]: Device not configured > BIOCGBLEN: 4096 > en1 MAC: 00:17:F2:E6:75:75 > en1 IP: 10.0.1.2 > en1 MTU: 4096 > Skipping interface en2 (not en1) > Skipping interface en3 (not en1) > sysinfo.machine: i386 > sysinfo.sysname: Darwin > sysinfo.release: 9.3.0 > lldp_systemdesc: i386/Darwin 9.3.0 > lldp_systemname: PB15-Leo.local. > Running RX state machine for en1 > Decrementing RX Timers > Displaying RX Timers > Running RX state machine for en1 > Decrementing RX Timers > Displaying RX Timers > Running RX state machine for en1 > Decrementing RX Timers > Displaying RX Timers > ^C[AYBABTU] We Get Signal! > [CLEAN] en1 (6) > > > Will test it on some LLDP devices tomorrow, when is the next release > planned.... > > > > Regards > > Mike > > > > > ------------------------------------------------------------------------- > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://sourceforge.net/services/buy/index.php > _______________________________________________ > Openlldp-users mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openlldp-users > |
|
From: Mike S. <ms...@nz...> - 2008-06-09 22:22:48
|
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
>
|
|
From: Terry S. <ter...@gm...> - 2008-06-10 07:29:32
|
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
On Mon, Jun 9, 2008 at 4:22 PM, Mike Savory <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
> >
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________
> Openlldp-users mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openlldp-users
>
|
|
From: Terry S. <ter...@gm...> - 2008-06-12 22:51:18
|
Ok good news.
I've reproduce the problem by hand-shoving the frame in your dump through
LLDP on my system.
I verified that we're properly processing frames from HP gear, so there's
either something weird about the frames we're getting from your gear, or
we've got a bug in our implementation.
Either way, I'll try to fix it.
I'll let you know when I have something more.
- Terry
On Mon, Jun 9, 2008 at 4:22 PM, Mike Savory <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
> >
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________
> Openlldp-users mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openlldp-users
>
|
|
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
> >
>
|
|
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
>> >
>>
>>
>
|
|
From: Mike S. <ms...@nz...> - 2008-07-05 22:38:57
|
Yes, I probably was running tcpdump when it was working for me....
Mike
On Jul 4, 2008, at 11:41 AM, 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.
>
> 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
> >
>
>
>
|
|
From: Tom J. <to...@to...> - 2008-07-06 00:42:49
Attachments:
patch
|
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
> >
>
>
>
|
Thanks for helping keep SourceForge clean.
X