Menu
▾
▴
openlldp-users — OpenLLDP Users List - Public Access
You can subscribe to this list here.
| 2007 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2008 |
Jan
(9) |
Feb
|
Mar
|
Apr
|
May
|
Jun
(8) |
Jul
(10) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(2) |
| 2010 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(5) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2011 |
Jan
|
Feb
(2) |
Mar
|
Apr
|
May
(3) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2012 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
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-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: 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-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-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-01-28 01:00:36
|
Hi Tom,
I see what you mean about bpf_see_sent being confusing.
I've changed the code accordingly:
// Uncomment the following line to enable lldpd to see sent
frames.
// bpf_see_sent(lldp_port->socket, 1);
Hopefully that makes more sense. ;)
On Jan 23, 2008 10:45 AM, Tom Judge <to...@to...> wrote:
> Terry Simons wrote:
> > Hehe
> >
> > The code actually turns it off, but it's commented out... ;)
> >
> > So the comment refers to the code, not to the fact that it's disabled.
> >
> > I should probably just remove the whole thing.
>
> Its all just a bit confusing. The function is named bpf_see_sent and
> takes a socket and and int? with 1 being see my packets 0 being don't
> see my packets?
>
> And the comment says turn on echo cancellation, implying that the
> function all will stop you seeing what you send...
>
> Not really important just very confusing.
>
>
> Does bpf_see_sent(lldp_port->socket, 1) cause us to see sent packets?
>
>
> Just trying to clarify
>
> Thanks
>
> Tom
>
>
> >
> > - Terry
> >
> > On Jan 23, 2008, at 3:13 AM, Tom Judge wrote:
> >
> >> Terry Simons wrote:
> >>> Hi Tom,
> >>> These patches have been committed to CVS HEAD.
> >>> I also turned off "see sent", so you shouldn't see the frames echoed
> >>> back to you.
> >>> If you have a chance to test the latest CVS and make sure it's
> >>> working for you I would appreciate it. I've been holding off this
> >>> release in part because I haven't had the time to verify some of the
> >>> platforms that were previously verified with 0.3 and earlier.
> >>> BTW, there's a nifty "lldpneighbors" command in CVS that will show
> >>> you the localhost MSAP cache. If you get a chance to test it let me
> >>> know what you think or if you have problems. There are currently a
> >>> couple of bugs filed against it that I haven't had a chance to track
> >>> down, but it seems to work pretty well otherwise.
> >>> Thanks!
> >>> - Terry
> >>
> >> Hi Terry,
> >>
> >> Thanks for looking at this. I have one comment on
> >> /src/framehandlers/bpf/lldp_bpf_framer.c line 201-203
> >>
> >> Where you have this comment/code
> >> // Turn on bpf echo cancellation
> >> // I use this in testing, but it's not normally wanted.
> >> // bpf_see_sent(lldp_port->socket, 1);
> >>
> >> Surely this should read: Turn off echo cancellation
> >>
> >> Regards
> >>
> >> Tom
> >>
> >>> On Jan 16, 2008 7:08 PM, Tom Judge < to...@to...
> >>> <mailto:to...@to...>> wrote:
> >>> Terry Simons wrote:
> >>> > Hi Tom,
> >>> >
> >>> > Yes, you are correct.
> >>> >
> >>> > That code is an attempt to remove the BPF header, which on the
> >>> 32-bit
> >>> > systems I've tested is 18 bytes, including 32-bit versions of
> >>> FreeBSD.
> >>> >
> >>> > I never quite understood how the BPF layer worked with regards
> to
> >>> that,
> >>> > but it sounds like there's a difference in the header on 64-bit
> >>> systems?
> >>> >
> >>> > I'm happy to look into this for you if you want, or if you have
> a
> >>> patch
> >>> > or some knowledge that could help us determine what's going on
> >>> that
> >>> > would be great too.
> >>> >
> >>> > - Terry
> >>> Hi Terry,
> >>> Thanks for your response.
> >>> I took a quick look at this yesterday and found that on FreeBSD
> >>> 6.2 i386
> >>> sizeof(struct bpf_hdr) is 20 and on amd64 it is 32. However from
> the
> >>> bpf man page it seems that you cannot use the return value of
> >>> sizeof(struct bpf_hdr) to remove the header.
> >>> From bpf(4):
> >>> <quote>
> >>> The bh_hdrlen field exists to account for padding between the
> header
> >>> and the link level protocol. The purpose here is to guarantee
> proper
> >>> alignment of the packet data structures, which is required on
> >>> alignment
> >>> sensitive architectures and improves performance on many other
> >>> architectures. The packet filter insures that the bpf_hdr and the
> >>> network layer header will be word aligned. Suitable precautions
> >>> must be
> >>> taken when accessing the link layer protocol fields on alignment
> >>> restricted machines. (This is not a problem on an Ethernet, since
> >>> the
> >>> type field is a short falling on an even offset, and the addresses
> >>> are
> >>> probably accessed in a bytewise fashion).
> >>> </quote>
> >>> I have attached a patch (lldp_framer_fiX_read.patch) that reads the
> >>> packet into a bpf_hdr malloc'd to lldp_port->mtu (this should be
> >>> renamed to mru (max recieve unit) maybe?). Then uses bh_hdrlen and
> >>> bh_caplen to extract the first from from the receive buffer into
> >>> lldp_port->rx.frame.
> >>> Also on FreeBSD it seemed a little silly to put the network card
> into
> >>> promisc mode when we can just register to receive the multicast
> >>> ethernet
> >>> address on interface (affectively allowing us to program the mac
> >>> filter
> >>> on the NIC to allow the frames up the stack). I have attached a
> >>> patch
> >>> that enables this (bpf_frammer_reg_multi.patch).
> >>> One thing that I have just noticed is that we see our own frames
> >>> (i.e.
> >>> ones that we send) in the rx path. This may be related to not
> >>> putting
> >>> the interface into promisc mode. As I have only seen it on a box
> >>> that
> >>> was running the multicast code, also only on a i386 system. If I
> >>> cannot
> >>> find out why this is happening I will add some checks to make the
> rx
> >>> path drop packets that originated from the local tx path.
> >>> Also it seems that the usage and semantics of iface_list in
> >>> lldp_main.c
> >>> are miss matched. For example you can not add -i more than once
> >>> because
> >>> each time you specify it you overwrite the previous value. Also
> the
> >>> check for is the interface in the list is based on comparing the
> >>> first
> >>> value in the list which happens to be the only value. I may be
> >>> able to
> >>> come up with a patch for this in the next few days or at the
> >>> weekend, if
> >>> this is not already fixed in CVS?
> >>> Regards
> >>> Tom
> >>> Note: The patches attached are generated against the 0.3alpha
> >>> release.
> >>> >
> >>> > On Jan 16, 2008 5:01 PM, Tom Judge < to...@to...
> >>> <mailto:to...@to...>
> >>> > <mailto:to...@to... <mailto:to...@to...>>> wrote:
> >>> >
> >>> > Hi,
> >>> >
> >>> > I have a quick question about the bpf framer's read_lldp
> >>> function.
> >>> > Could someone please explain why 18 bytes are trimmed from
> >>> the begining
> >>> > of the frame that is read?
> >>> >
> >>> > The reason that I ask is I am trying to get openlldp to
> >>> work on a
> >>> > FreeBSD 6.2 amd64 system (plugged into the same switch as a
> >>> i386 system)
> >>> > And the amd64 system seems to be printing/receiving
> >>> gibberish.
> >>> >
> >>> > After having a quick skim over the bpf documentation/source
> >>> it would
> >>> > seem that the function is trying to drop the bpf_hdr off the
> >>> beginning
> >>> > of the packet. Is this a correct assumption?
> >>> >
> >>> > Thanks
> >>> >
> >>> > Tom
> >>> >
> >>> >
> >>> >
> >>>
> -------------------------------------------------------------------------
> >>>
> >>> >
> >>> > This SF.net email is sponsored by: Microsoft
> >>> > Defy all challenges. Microsoft(R) Visual Studio 2008.
> >>> > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> >>> > <http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/>
> >>> > _______________________________________________
> >>> > Openlldp-users mailing list
> >>> > Ope...@li...
> >>> <mailto:Ope...@li...>
> >>> > <mailto: Ope...@li...
> >>> <mailto:Ope...@li...>>
> >>> > https://lists.sourceforge.net/lists/listinfo/openlldp-users
> >>> >
> >>> >
> >>
> >
>
>
|
|
From: Tom J. <to...@to...> - 2008-01-23 17:45:41
|
Terry Simons wrote: > Hehe > > The code actually turns it off, but it's commented out... ;) > > So the comment refers to the code, not to the fact that it's disabled. > > I should probably just remove the whole thing. Its all just a bit confusing. The function is named bpf_see_sent and takes a socket and and int? with 1 being see my packets 0 being don't see my packets? And the comment says turn on echo cancellation, implying that the function all will stop you seeing what you send... Not really important just very confusing. Does bpf_see_sent(lldp_port->socket, 1) cause us to see sent packets? Just trying to clarify Thanks Tom > > - Terry > > On Jan 23, 2008, at 3:13 AM, Tom Judge wrote: > >> Terry Simons wrote: >>> Hi Tom, >>> These patches have been committed to CVS HEAD. >>> I also turned off "see sent", so you shouldn't see the frames echoed >>> back to you. >>> If you have a chance to test the latest CVS and make sure it's >>> working for you I would appreciate it. I've been holding off this >>> release in part because I haven't had the time to verify some of the >>> platforms that were previously verified with 0.3 and earlier. >>> BTW, there's a nifty "lldpneighbors" command in CVS that will show >>> you the localhost MSAP cache. If you get a chance to test it let me >>> know what you think or if you have problems. There are currently a >>> couple of bugs filed against it that I haven't had a chance to track >>> down, but it seems to work pretty well otherwise. >>> Thanks! >>> - Terry >> >> Hi Terry, >> >> Thanks for looking at this. I have one comment on >> /src/framehandlers/bpf/lldp_bpf_framer.c line 201-203 >> >> Where you have this comment/code >> // Turn on bpf echo cancellation >> // I use this in testing, but it's not normally wanted. >> // bpf_see_sent(lldp_port->socket, 1); >> >> Surely this should read: Turn off echo cancellation >> >> Regards >> >> Tom >> >>> On Jan 16, 2008 7:08 PM, Tom Judge < to...@to... >>> <mailto:to...@to...>> wrote: >>> Terry Simons wrote: >>> > Hi Tom, >>> > >>> > Yes, you are correct. >>> > >>> > That code is an attempt to remove the BPF header, which on the >>> 32-bit >>> > systems I've tested is 18 bytes, including 32-bit versions of >>> FreeBSD. >>> > >>> > I never quite understood how the BPF layer worked with regards to >>> that, >>> > but it sounds like there's a difference in the header on 64-bit >>> systems? >>> > >>> > I'm happy to look into this for you if you want, or if you have a >>> patch >>> > or some knowledge that could help us determine what's going on >>> that >>> > would be great too. >>> > >>> > - Terry >>> Hi Terry, >>> Thanks for your response. >>> I took a quick look at this yesterday and found that on FreeBSD >>> 6.2 i386 >>> sizeof(struct bpf_hdr) is 20 and on amd64 it is 32. However from the >>> bpf man page it seems that you cannot use the return value of >>> sizeof(struct bpf_hdr) to remove the header. >>> From bpf(4): >>> <quote> >>> The bh_hdrlen field exists to account for padding between the header >>> and the link level protocol. The purpose here is to guarantee proper >>> alignment of the packet data structures, which is required on >>> alignment >>> sensitive architectures and improves performance on many other >>> architectures. The packet filter insures that the bpf_hdr and the >>> network layer header will be word aligned. Suitable precautions >>> must be >>> taken when accessing the link layer protocol fields on alignment >>> restricted machines. (This is not a problem on an Ethernet, since >>> the >>> type field is a short falling on an even offset, and the addresses >>> are >>> probably accessed in a bytewise fashion). >>> </quote> >>> I have attached a patch (lldp_framer_fiX_read.patch) that reads the >>> packet into a bpf_hdr malloc'd to lldp_port->mtu (this should be >>> renamed to mru (max recieve unit) maybe?). Then uses bh_hdrlen and >>> bh_caplen to extract the first from from the receive buffer into >>> lldp_port->rx.frame. >>> Also on FreeBSD it seemed a little silly to put the network card into >>> promisc mode when we can just register to receive the multicast >>> ethernet >>> address on interface (affectively allowing us to program the mac >>> filter >>> on the NIC to allow the frames up the stack). I have attached a >>> patch >>> that enables this (bpf_frammer_reg_multi.patch). >>> One thing that I have just noticed is that we see our own frames >>> (i.e. >>> ones that we send) in the rx path. This may be related to not >>> putting >>> the interface into promisc mode. As I have only seen it on a box >>> that >>> was running the multicast code, also only on a i386 system. If I >>> cannot >>> find out why this is happening I will add some checks to make the rx >>> path drop packets that originated from the local tx path. >>> Also it seems that the usage and semantics of iface_list in >>> lldp_main.c >>> are miss matched. For example you can not add -i more than once >>> because >>> each time you specify it you overwrite the previous value. Also the >>> check for is the interface in the list is based on comparing the >>> first >>> value in the list which happens to be the only value. I may be >>> able to >>> come up with a patch for this in the next few days or at the >>> weekend, if >>> this is not already fixed in CVS? >>> Regards >>> Tom >>> Note: The patches attached are generated against the 0.3alpha >>> release. >>> > >>> > On Jan 16, 2008 5:01 PM, Tom Judge < to...@to... >>> <mailto:to...@to...> >>> > <mailto:to...@to... <mailto:to...@to...>>> wrote: >>> > >>> > Hi, >>> > >>> > I have a quick question about the bpf framer's read_lldp >>> function. >>> > Could someone please explain why 18 bytes are trimmed from >>> the begining >>> > of the frame that is read? >>> > >>> > The reason that I ask is I am trying to get openlldp to >>> work on a >>> > FreeBSD 6.2 amd64 system (plugged into the same switch as a >>> i386 system) >>> > And the amd64 system seems to be printing/receiving >>> gibberish. >>> > >>> > After having a quick skim over the bpf documentation/source >>> it would >>> > seem that the function is trying to drop the bpf_hdr off the >>> beginning >>> > of the packet. Is this a correct assumption? >>> > >>> > Thanks >>> > >>> > Tom >>> > >>> > >>> > >>> ------------------------------------------------------------------------- >>> >>> > >>> > This SF.net email is sponsored by: Microsoft >>> > Defy all challenges. Microsoft(R) Visual Studio 2008. >>> > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >>> > <http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/> >>> > _______________________________________________ >>> > Openlldp-users mailing list >>> > Ope...@li... >>> <mailto:Ope...@li...> >>> > <mailto: Ope...@li... >>> <mailto:Ope...@li...>> >>> > https://lists.sourceforge.net/lists/listinfo/openlldp-users >>> > >>> > >> > |
|
From: Terry S. <ter...@gm...> - 2008-01-23 17:37:21
|
Hehe The code actually turns it off, but it's commented out... ;) So the comment refers to the code, not to the fact that it's disabled. I should probably just remove the whole thing. - Terry On Jan 23, 2008, at 3:13 AM, Tom Judge wrote: > Terry Simons wrote: >> Hi Tom, >> These patches have been committed to CVS HEAD. >> I also turned off "see sent", so you shouldn't see the frames >> echoed back to you. >> If you have a chance to test the latest CVS and make sure it's >> working for you I would appreciate it. I've been holding off this >> release in part because I haven't had the time to verify some of >> the platforms that were previously verified with 0.3 and earlier. >> BTW, there's a nifty "lldpneighbors" command in CVS that will show >> you the localhost MSAP cache. If you get a chance to test it let >> me know what you think or if you have problems. There are >> currently a couple of bugs filed against it that I haven't had a >> chance to track down, but it seems to work pretty well otherwise. >> Thanks! >> - Terry > > Hi Terry, > > Thanks for looking at this. I have one comment on > /src/framehandlers/bpf/lldp_bpf_framer.c line 201-203 > > Where you have this comment/code > // Turn on bpf echo cancellation > // I use this in testing, but it's not normally wanted. > // bpf_see_sent(lldp_port->socket, 1); > > Surely this should read: Turn off echo cancellation > > Regards > > Tom > >> On Jan 16, 2008 7:08 PM, Tom Judge < to...@to... <mailto:to...@to... >> >> wrote: >> Terry Simons wrote: >> > Hi Tom, >> > >> > Yes, you are correct. >> > >> > That code is an attempt to remove the BPF header, which on >> the 32-bit >> > systems I've tested is 18 bytes, including 32-bit versions of >> FreeBSD. >> > >> > I never quite understood how the BPF layer worked with >> regards to >> that, >> > but it sounds like there's a difference in the header on 64-bit >> systems? >> > >> > I'm happy to look into this for you if you want, or if you >> have a >> patch >> > or some knowledge that could help us determine what's going >> on that >> > would be great too. >> > >> > - Terry >> Hi Terry, >> Thanks for your response. >> I took a quick look at this yesterday and found that on FreeBSD >> 6.2 i386 >> sizeof(struct bpf_hdr) is 20 and on amd64 it is 32. However >> from the >> bpf man page it seems that you cannot use the return value of >> sizeof(struct bpf_hdr) to remove the header. >> From bpf(4): >> <quote> >> The bh_hdrlen field exists to account for padding between the >> header >> and the link level protocol. The purpose here is to guarantee >> proper >> alignment of the packet data structures, which is required on >> alignment >> sensitive architectures and improves performance on many other >> architectures. The packet filter insures that the bpf_hdr and the >> network layer header will be word aligned. Suitable precautions >> must be >> taken when accessing the link layer protocol fields on alignment >> restricted machines. (This is not a problem on an Ethernet, >> since the >> type field is a short falling on an even offset, and the >> addresses are >> probably accessed in a bytewise fashion). >> </quote> >> I have attached a patch (lldp_framer_fiX_read.patch) that reads >> the >> packet into a bpf_hdr malloc'd to lldp_port->mtu (this should be >> renamed to mru (max recieve unit) maybe?). Then uses bh_hdrlen >> and >> bh_caplen to extract the first from from the receive buffer into >> lldp_port->rx.frame. >> Also on FreeBSD it seemed a little silly to put the network card >> into >> promisc mode when we can just register to receive the multicast >> ethernet >> address on interface (affectively allowing us to program the mac >> filter >> on the NIC to allow the frames up the stack). I have attached a >> patch >> that enables this (bpf_frammer_reg_multi.patch). >> One thing that I have just noticed is that we see our own frames >> (i.e. >> ones that we send) in the rx path. This may be related to not >> putting >> the interface into promisc mode. As I have only seen it on a >> box that >> was running the multicast code, also only on a i386 system. If >> I cannot >> find out why this is happening I will add some checks to make >> the rx >> path drop packets that originated from the local tx path. >> Also it seems that the usage and semantics of iface_list in >> lldp_main.c >> are miss matched. For example you can not add -i more than once >> because >> each time you specify it you overwrite the previous value. Also >> the >> check for is the interface in the list is based on comparing the >> first >> value in the list which happens to be the only value. I may be >> able to >> come up with a patch for this in the next few days or at the >> weekend, if >> this is not already fixed in CVS? >> Regards >> Tom >> Note: The patches attached are generated against the 0.3alpha >> release. >> > >> > On Jan 16, 2008 5:01 PM, Tom Judge < to...@to... >> <mailto:to...@to...> >> > <mailto:to...@to... <mailto:to...@to...>>> wrote: >> > >> > Hi, >> > >> > I have a quick question about the bpf framer's read_lldp >> function. >> > Could someone please explain why 18 bytes are trimmed from >> the begining >> > of the frame that is read? >> > >> > The reason that I ask is I am trying to get openlldp to >> work on a >> > FreeBSD 6.2 amd64 system (plugged into the same switch as a >> i386 system) >> > And the amd64 system seems to be printing/receiving >> gibberish. >> > >> > After having a quick skim over the bpf documentation/source >> it would >> > seem that the function is trying to drop the bpf_hdr off >> the >> beginning >> > of the packet. Is this a correct assumption? >> > >> > Thanks >> > >> > Tom >> > >> > >> > >> ------------------------------------------------------------------------- >> > >> > This SF.net email is sponsored by: Microsoft >> > Defy all challenges. Microsoft(R) Visual Studio 2008. >> > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >> > <http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/> >> > _______________________________________________ >> > Openlldp-users mailing list >> > Ope...@li... >> <mailto:Ope...@li...> >> > <mailto: Ope...@li... >> <mailto:Ope...@li...>> >> > https://lists.sourceforge.net/lists/listinfo/openlldp-users >> > >> > > |
|
From: Tom J. <to...@to...> - 2008-01-23 10:13:00
|
Terry Simons wrote: > Hi Tom, > > These patches have been committed to CVS HEAD. > > I also turned off "see sent", so you shouldn't see the frames echoed > back to you. > > If you have a chance to test the latest CVS and make sure it's working > for you I would appreciate it. I've been holding off this release in > part because I haven't had the time to verify some of the platforms that > were previously verified with 0.3 and earlier. > > BTW, there's a nifty "lldpneighbors" command in CVS that will show you > the localhost MSAP cache. If you get a chance to test it let me know > what you think or if you have problems. There are currently a couple of > bugs filed against it that I haven't had a chance to track down, but it > seems to work pretty well otherwise. > > Thanks! > > - Terry Hi Terry, Thanks for looking at this. I have one comment on /src/framehandlers/bpf/lldp_bpf_framer.c line 201-203 Where you have this comment/code // Turn on bpf echo cancellation // I use this in testing, but it's not normally wanted. // bpf_see_sent(lldp_port->socket, 1); Surely this should read: Turn off echo cancellation Regards Tom > > On Jan 16, 2008 7:08 PM, Tom Judge < to...@to... > <mailto:to...@to...>> wrote: > > Terry Simons wrote: > > Hi Tom, > > > > Yes, you are correct. > > > > That code is an attempt to remove the BPF header, which on the 32-bit > > systems I've tested is 18 bytes, including 32-bit versions of > FreeBSD. > > > > I never quite understood how the BPF layer worked with regards to > that, > > but it sounds like there's a difference in the header on 64-bit > systems? > > > > I'm happy to look into this for you if you want, or if you have a > patch > > or some knowledge that could help us determine what's going on that > > would be great too. > > > > - Terry > > > Hi Terry, > > Thanks for your response. > > I took a quick look at this yesterday and found that on FreeBSD 6.2 i386 > sizeof(struct bpf_hdr) is 20 and on amd64 it is 32. However from the > bpf man page it seems that you cannot use the return value of > sizeof(struct bpf_hdr) to remove the header. > > From bpf(4): > <quote> > The bh_hdrlen field exists to account for padding between the header > and the link level protocol. The purpose here is to guarantee proper > alignment of the packet data structures, which is required on alignment > sensitive architectures and improves performance on many other > architectures. The packet filter insures that the bpf_hdr and the > network layer header will be word aligned. Suitable precautions must be > taken when accessing the link layer protocol fields on alignment > restricted machines. (This is not a problem on an Ethernet, since the > type field is a short falling on an even offset, and the addresses are > probably accessed in a bytewise fashion). > </quote> > > I have attached a patch (lldp_framer_fiX_read.patch) that reads the > packet into a bpf_hdr malloc'd to lldp_port->mtu (this should be > renamed to mru (max recieve unit) maybe?). Then uses bh_hdrlen and > bh_caplen to extract the first from from the receive buffer into > lldp_port->rx.frame. > > Also on FreeBSD it seemed a little silly to put the network card into > promisc mode when we can just register to receive the multicast ethernet > address on interface (affectively allowing us to program the mac filter > on the NIC to allow the frames up the stack). I have attached a patch > that enables this (bpf_frammer_reg_multi.patch). > > > One thing that I have just noticed is that we see our own frames (i.e. > ones that we send) in the rx path. This may be related to not putting > the interface into promisc mode. As I have only seen it on a box that > was running the multicast code, also only on a i386 system. If I cannot > find out why this is happening I will add some checks to make the rx > path drop packets that originated from the local tx path. > > > Also it seems that the usage and semantics of iface_list in lldp_main.c > are miss matched. For example you can not add -i more than once because > each time you specify it you overwrite the previous value. Also the > check for is the interface in the list is based on comparing the first > value in the list which happens to be the only value. I may be able to > come up with a patch for this in the next few days or at the > weekend, if > this is not already fixed in CVS? > > > Regards > > Tom > > > Note: The patches attached are generated against the 0.3alpha release. > > > > On Jan 16, 2008 5:01 PM, Tom Judge < to...@to... > <mailto:to...@to...> > > <mailto:to...@to... <mailto:to...@to...>>> wrote: > > > > Hi, > > > > I have a quick question about the bpf framer's read_lldp > function. > > Could someone please explain why 18 bytes are trimmed from > the begining > > of the frame that is read? > > > > The reason that I ask is I am trying to get openlldp to work on a > > FreeBSD 6.2 amd64 system (plugged into the same switch as a > i386 system) > > And the amd64 system seems to be printing/receiving gibberish. > > > > After having a quick skim over the bpf documentation/source > it would > > seem that the function is trying to drop the bpf_hdr off the > beginning > > of the packet. Is this a correct assumption? > > > > Thanks > > > > Tom > > > > > > > ------------------------------------------------------------------------- > > > > > This SF.net email is sponsored by: Microsoft > > Defy all challenges. Microsoft(R) Visual Studio 2008. > > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > > <http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/> > > _______________________________________________ > > Openlldp-users mailing list > > Ope...@li... > <mailto:Ope...@li...> > > <mailto: Ope...@li... > <mailto:Ope...@li...>> > > https://lists.sourceforge.net/lists/listinfo/openlldp-users > > > > > > |
|
From: Terry S. <ter...@gm...> - 2008-01-23 05:53:05
|
Hi Tom, These patches have been committed to CVS HEAD. I also turned off "see sent", so you shouldn't see the frames echoed back to you. If you have a chance to test the latest CVS and make sure it's working for you I would appreciate it. I've been holding off this release in part because I haven't had the time to verify some of the platforms that were previously verified with 0.3 and earlier. BTW, there's a nifty "lldpneighbors" command in CVS that will show you the localhost MSAP cache. If you get a chance to test it let me know what you think or if you have problems. There are currently a couple of bugs filed against it that I haven't had a chance to track down, but it seems to work pretty well otherwise. Thanks! - Terry On Jan 16, 2008 7:08 PM, Tom Judge <to...@to...> wrote: > Terry Simons wrote: > > Hi Tom, > > > > Yes, you are correct. > > > > That code is an attempt to remove the BPF header, which on the 32-bit > > systems I've tested is 18 bytes, including 32-bit versions of FreeBSD. > > > > I never quite understood how the BPF layer worked with regards to that, > > but it sounds like there's a difference in the header on 64-bit systems? > > > > I'm happy to look into this for you if you want, or if you have a patch > > or some knowledge that could help us determine what's going on that > > would be great too. > > > > - Terry > > > Hi Terry, > > Thanks for your response. > > I took a quick look at this yesterday and found that on FreeBSD 6.2 i386 > sizeof(struct bpf_hdr) is 20 and on amd64 it is 32. However from the > bpf man page it seems that you cannot use the return value of > sizeof(struct bpf_hdr) to remove the header. > > From bpf(4): > <quote> > The bh_hdrlen field exists to account for padding between the header > and the link level protocol. The purpose here is to guarantee proper > alignment of the packet data structures, which is required on alignment > sensitive architectures and improves performance on many other > architectures. The packet filter insures that the bpf_hdr and the > network layer header will be word aligned. Suitable precautions must be > taken when accessing the link layer protocol fields on alignment > restricted machines. (This is not a problem on an Ethernet, since the > type field is a short falling on an even offset, and the addresses are > probably accessed in a bytewise fashion). > </quote> > > I have attached a patch (lldp_framer_fiX_read.patch) that reads the > packet into a bpf_hdr malloc'd to lldp_port->mtu (this should be > renamed to mru (max recieve unit) maybe?). Then uses bh_hdrlen and > bh_caplen to extract the first from from the receive buffer into > lldp_port->rx.frame. > > Also on FreeBSD it seemed a little silly to put the network card into > promisc mode when we can just register to receive the multicast ethernet > address on interface (affectively allowing us to program the mac filter > on the NIC to allow the frames up the stack). I have attached a patch > that enables this (bpf_frammer_reg_multi.patch). > > > One thing that I have just noticed is that we see our own frames (i.e. > ones that we send) in the rx path. This may be related to not putting > the interface into promisc mode. As I have only seen it on a box that > was running the multicast code, also only on a i386 system. If I cannot > find out why this is happening I will add some checks to make the rx > path drop packets that originated from the local tx path. > > > Also it seems that the usage and semantics of iface_list in lldp_main.c > are miss matched. For example you can not add -i more than once because > each time you specify it you overwrite the previous value. Also the > check for is the interface in the list is based on comparing the first > value in the list which happens to be the only value. I may be able to > come up with a patch for this in the next few days or at the weekend, if > this is not already fixed in CVS? > > > Regards > > Tom > > > Note: The patches attached are generated against the 0.3alpha release. > > > > On Jan 16, 2008 5:01 PM, Tom Judge <to...@to... > > <mailto:to...@to...>> wrote: > > > > Hi, > > > > I have a quick question about the bpf framer's read_lldp function. > > Could someone please explain why 18 bytes are trimmed from the > begining > > of the frame that is read? > > > > The reason that I ask is I am trying to get openlldp to work on a > > FreeBSD 6.2 amd64 system (plugged into the same switch as a i386 > system) > > And the amd64 system seems to be printing/receiving gibberish. > > > > After having a quick skim over the bpf documentation/source it would > > seem that the function is trying to drop the bpf_hdr off the > beginning > > of the packet. Is this a correct assumption? > > > > Thanks > > > > Tom > > > > > > > ------------------------------------------------------------------------- > > > > This SF.net email is sponsored by: Microsoft > > Defy all challenges. Microsoft(R) Visual Studio 2008. > > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > > <http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/> > > _______________________________________________ > > Openlldp-users mailing list > > Ope...@li... > > <mailto:Ope...@li...> > > https://lists.sourceforge.net/lists/listinfo/openlldp-users > > > > > > |
|
From: Terry S. <ter...@gm...> - 2008-01-17 18:01:41
|
Hi Tom, I suspect that when I was testing the FreeBSD code I didn't notice the extra 2 bytes... I did my original testing on Mac OS X PPC, which wasn't padded, so the issues didn't appear for me. Thanks for the patches and the insight on the BPF issues. I'll get your patches committed sometime within the next couple of days. The reason you are seeing your own frames is due to to the following BPF IOCTL: BIOCSSEESENT BIOCGSEESENT (u_int) Set or get the flag determining whether locally generated packets on the interface should be returned by BPF. Set to zero to see only incoming packets on the interface. Set to one to see packets originating locally and remotely on the interface. This flag is initialized to one by default. I had this enabled by default to help me debug the BPF frame handler, but I guess I forgot to disable it on the release tarball. Try setting that flag to 0 and see if it fixes the problem. The interface problem you mentioned isn't fixed in CVS, so if you feel like kicking us a patch for that we'd be happy to integrate it. - Terry On Jan 16, 2008 7:08 PM, Tom Judge <to...@to...> wrote: > Terry Simons wrote: > > Hi Tom, > > > > Yes, you are correct. > > > > That code is an attempt to remove the BPF header, which on the 32-bit > > systems I've tested is 18 bytes, including 32-bit versions of FreeBSD. > > > > I never quite understood how the BPF layer worked with regards to that, > > but it sounds like there's a difference in the header on 64-bit systems? > > > > I'm happy to look into this for you if you want, or if you have a patch > > or some knowledge that could help us determine what's going on that > > would be great too. > > > > - Terry > > > Hi Terry, > > Thanks for your response. > > I took a quick look at this yesterday and found that on FreeBSD 6.2 i386 > sizeof(struct bpf_hdr) is 20 and on amd64 it is 32. However from the > bpf man page it seems that you cannot use the return value of > sizeof(struct bpf_hdr) to remove the header. > > From bpf(4): > <quote> > The bh_hdrlen field exists to account for padding between the header > and the link level protocol. The purpose here is to guarantee proper > alignment of the packet data structures, which is required on alignment > sensitive architectures and improves performance on many other > architectures. The packet filter insures that the bpf_hdr and the > network layer header will be word aligned. Suitable precautions must be > taken when accessing the link layer protocol fields on alignment > restricted machines. (This is not a problem on an Ethernet, since the > type field is a short falling on an even offset, and the addresses are > probably accessed in a bytewise fashion). > </quote> > > I have attached a patch (lldp_framer_fiX_read.patch) that reads the > packet into a bpf_hdr malloc'd to lldp_port->mtu (this should be > renamed to mru (max recieve unit) maybe?). Then uses bh_hdrlen and > bh_caplen to extract the first from from the receive buffer into > lldp_port->rx.frame. > > Also on FreeBSD it seemed a little silly to put the network card into > promisc mode when we can just register to receive the multicast ethernet > address on interface (affectively allowing us to program the mac filter > on the NIC to allow the frames up the stack). I have attached a patch > that enables this (bpf_frammer_reg_multi.patch). > > > One thing that I have just noticed is that we see our own frames (i.e. > ones that we send) in the rx path. This may be related to not putting > the interface into promisc mode. As I have only seen it on a box that > was running the multicast code, also only on a i386 system. If I cannot > find out why this is happening I will add some checks to make the rx > path drop packets that originated from the local tx path. > > > Also it seems that the usage and semantics of iface_list in lldp_main.c > are miss matched. For example you can not add -i more than once because > each time you specify it you overwrite the previous value. Also the > check for is the interface in the list is based on comparing the first > value in the list which happens to be the only value. I may be able to > come up with a patch for this in the next few days or at the weekend, if > this is not already fixed in CVS? > > > Regards > > Tom > > > Note: The patches attached are generated against the 0.3alpha release. > |
|
From: Tom J. <to...@to...> - 2008-01-17 02:08:39
|
Terry Simons wrote: > Hi Tom, > > Yes, you are correct. > > That code is an attempt to remove the BPF header, which on the 32-bit > systems I've tested is 18 bytes, including 32-bit versions of FreeBSD. > > I never quite understood how the BPF layer worked with regards to that, > but it sounds like there's a difference in the header on 64-bit systems? > > I'm happy to look into this for you if you want, or if you have a patch > or some knowledge that could help us determine what's going on that > would be great too. > > - Terry Hi Terry, Thanks for your response. I took a quick look at this yesterday and found that on FreeBSD 6.2 i386 sizeof(struct bpf_hdr) is 20 and on amd64 it is 32. However from the bpf man page it seems that you cannot use the return value of sizeof(struct bpf_hdr) to remove the header. From bpf(4): <quote> The bh_hdrlen field exists to account for padding between the header and the link level protocol. The purpose here is to guarantee proper alignment of the packet data structures, which is required on alignment sensitive architectures and improves performance on many other architectures. The packet filter insures that the bpf_hdr and the network layer header will be word aligned. Suitable precautions must be taken when accessing the link layer protocol fields on alignment restricted machines. (This is not a problem on an Ethernet, since the type field is a short falling on an even offset, and the addresses are probably accessed in a bytewise fashion). </quote> I have attached a patch (lldp_framer_fiX_read.patch) that reads the packet into a bpf_hdr malloc'd to lldp_port->mtu (this should be renamed to mru (max recieve unit) maybe?). Then uses bh_hdrlen and bh_caplen to extract the first from from the receive buffer into lldp_port->rx.frame. Also on FreeBSD it seemed a little silly to put the network card into promisc mode when we can just register to receive the multicast ethernet address on interface (affectively allowing us to program the mac filter on the NIC to allow the frames up the stack). I have attached a patch that enables this (bpf_frammer_reg_multi.patch). One thing that I have just noticed is that we see our own frames (i.e. ones that we send) in the rx path. This may be related to not putting the interface into promisc mode. As I have only seen it on a box that was running the multicast code, also only on a i386 system. If I cannot find out why this is happening I will add some checks to make the rx path drop packets that originated from the local tx path. Also it seems that the usage and semantics of iface_list in lldp_main.c are miss matched. For example you can not add -i more than once because each time you specify it you overwrite the previous value. Also the check for is the interface in the list is based on comparing the first value in the list which happens to be the only value. I may be able to come up with a patch for this in the next few days or at the weekend, if this is not already fixed in CVS? Regards Tom Note: The patches attached are generated against the 0.3alpha release. > > On Jan 16, 2008 5:01 PM, Tom Judge <to...@to... > <mailto:to...@to...>> wrote: > > Hi, > > I have a quick question about the bpf framer's read_lldp function. > Could someone please explain why 18 bytes are trimmed from the begining > of the frame that is read? > > The reason that I ask is I am trying to get openlldp to work on a > FreeBSD 6.2 amd64 system (plugged into the same switch as a i386 system) > And the amd64 system seems to be printing/receiving gibberish. > > After having a quick skim over the bpf documentation/source it would > seem that the function is trying to drop the bpf_hdr off the beginning > of the packet. Is this a correct assumption? > > Thanks > > Tom > > > ------------------------------------------------------------------------- > > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > <http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/> > _______________________________________________ > Openlldp-users mailing list > Ope...@li... > <mailto:Ope...@li...> > https://lists.sourceforge.net/lists/listinfo/openlldp-users > > |
|
From: Terry S. <ter...@gm...> - 2008-01-17 00:07:37
|
Hi Tom, Yes, you are correct. That code is an attempt to remove the BPF header, which on the 32-bit systems I've tested is 18 bytes, including 32-bit versions of FreeBSD. I never quite understood how the BPF layer worked with regards to that, but it sounds like there's a difference in the header on 64-bit systems? I'm happy to look into this for you if you want, or if you have a patch or some knowledge that could help us determine what's going on that would be great too. - Terry On Jan 16, 2008 5:01 PM, Tom Judge <to...@to...> wrote: > Hi, > > I have a quick question about the bpf framer's read_lldp function. > Could someone please explain why 18 bytes are trimmed from the begining > of the frame that is read? > > The reason that I ask is I am trying to get openlldp to work on a > FreeBSD 6.2 amd64 system (plugged into the same switch as a i386 system) > And the amd64 system seems to be printing/receiving gibberish. > > After having a quick skim over the bpf documentation/source it would > seem that the function is trying to drop the bpf_hdr off the beginning > of the packet. Is this a correct assumption? > > Thanks > > Tom > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Openlldp-users mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openlldp-users > |
|
From: Tom J. <to...@to...> - 2008-01-17 00:01:00
|
Hi, I have a quick question about the bpf framer's read_lldp function. Could someone please explain why 18 bytes are trimmed from the begining of the frame that is read? The reason that I ask is I am trying to get openlldp to work on a FreeBSD 6.2 amd64 system (plugged into the same switch as a i386 system) And the amd64 system seems to be printing/receiving gibberish. After having a quick skim over the bpf documentation/source it would seem that the function is trying to drop the bpf_hdr off the beginning of the packet. Is this a correct assumption? Thanks Tom |
|
From: Terry S. <ter...@gm...> - 2007-04-14 23:30:49
|
The OpenLLDP team is pleased to announce the release of OpenLLDP 0.3alpha! This release contains support for new platforms including: Mac OS X OpenBSD FreeBSD NetBSD Please give it a spin and let us know how you make out. - The OpenLLDP Team |
