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: André G. N. L. <an...@on...> - 2012-07-24 18:39:54
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi
We've been using lldpd for a couple weeks now, but we have found a issue
recently: when we need to use carp interfaces (freebsd) in the same
servers we have lldpd running we get tons of logs like this:
carp_looutput: af=1 unexpected
carp_looutput: af=1 unexpected
Looking around the source code of carp, it looks like the address family
used by lldp is not expected over carp interfaces:
### sys/netinet/ip_carp.c
#if 1 /* XXX */
switch (dst->sa_family) {
case AF_INET:
case AF_INET6:
case AF_IPX:
case AF_APPLETALK:
break;
default:
printf("carp_looutput: af=%d unexpected\n", dst->sa_family);
m_freem(m);
return (EAFNOSUPPORT);
}
#endif
return(if_simloop(ifp, m, dst->sa_family, 0));
}
We are stuck trying to figure a way of listening just a few interfaces,
avoiding then the lldp usage over carp interfaces (we actually would
like to listen just real interfaces and avoid all pseudo interfaces
(vlan, carp, pflog, etc).
Did someone face this before?
Best regards,
- --
André Gustavo N. Lopes
Equipe TI Onda Empresas
Tel: +55(41)3331-8282
Fax: +55(41)3331-8256
Onda Empresas
www.ondaempresas.com.br
Hospedagem, E-mail, Banda Larga, Telefonia IP, Data Center.
"Este endereço de e-mail se destina exclusivamente ao uso profissional.
Todo o conteúdo nele inserido é de responsabilidade exclusiva de seu
remetente e não reflete, necessariamente, a opinião ou o ponto de vista
oficial do Onda Provedor de Serviços S/A.
A mensagem, incluindo seus anexos, pode conter informações legais
privilegiadas e/ou confidenciais, não podendo ser retransmitida,
arquivada, divulgada ou copiada sem autorização expressa do remetente.
Caso tenha recebido esta mensagem por engano, por favor, informe o
remetente e em seguida apague-a do seu computador."
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJQDufHAAoJED/ohHvKzwrPj90IAJ/E1zHa/IY0ESZ6MAA4Lu8f
3RxR6AWu8TqCoLD4K37XGrhqNz8Tn/2ENNJKSPusx32InhE0Fj1MDusYCAhx/EMD
cHiojY6goYGeppcu1B1rmQVD3nge8gCeDo0TEjQ0F+tY7X8H4RMlB65mcGABgeJv
bYYOUPkFflYcrJhreoeiLfZJIy0Ep7K8khLLkGGmM9fun5U6MdorQ095zPQxT01g
Hrd7vnJbIVl0ffIxFXnrYos5B91jlUGY631bUmtns8rCXpBuSVbNeyYmUkmpw2pt
rHXBHs+k3qAmJgxZxycRVgJO19LSOwHaMQ3NI+o2pwwJZaXO5mTBJH1chVJQjCI=
=vdyY
-----END PGP SIGNATURE-----
|
|
From: 李艳伟 <liy...@gm...> - 2012-07-12 00:40:45
|
Hi, I am trying to run openlldp alpha 4 and I add an example config file for It.It complies ok,seems to start in the background on my Fedora16 i686 GNU/Linux,but it does start up with errors. [root@localhost src]# ./lldpd /var/run/lldpd.sock:19 [Error] Unable to bind to the unix domain socket for client registration! [Error] Unable to listen to the unix domain socket for client registration! SIOCGIFADDR returned an error: -1 SIOCGIFADDR returned an error: -1 Would stuff interface #: 2 [ERROR] in config file: invalid location_data_format '0' Would stuff interface #: 3 [ERROR] in config file: invalid location_data_format '0' SIOCGIFADDR returned an error: -1 SIOCGIFADDR returned an error: -1 Would stuff interface #: 4 [ERROR] in config file: invalid location_data_format '0' sysinfo.machine: i686 sysinfo.sysname: Linux sysinfo.release: 3.1.0-7.fc16.i686.PAE lldp_systemdesc: i686/Linux 3.1.0-7.fc16.i686.PAE lldp_systemname: localhost.localdomain.(none) Regards Li |
|
From: 김인기(Inkee K. <ink...@lg...> - 2011-05-26 08:59:50
|
Thank you very much!!! Regards, I.K.Kim ________________________________________ 보낸 사람: Karl Heinz Wolf [kh...@gm...] 보낸 날짜: 2011년 5월 26일 목요일 오후 5:29 받는 사람: 김인기(Inkee Kim) 참조: ope...@li... 제목: Re: [Openlldp-users] lldp.conf for LLDP-MED Kim, here is an example lldp.conf file: --- location_data_format = 1 civic_countrycode = "AT" civic_what = 1 civic_ca0 = "" civic_ca1 = "Burgenland" civic_ca2 = "Neusiedl am See" civic_ca3 = "Neusiedl am See" civic_ca4 = "" civic_ca5 = "" civic_ca6 = "Hauptplatz" civic_ca7 = "" civic_ca8 = "" civic_ca9 = "" civic_ca10 = "" civic_ca11 = "" civic_ca12 = "" civic_ca13 = "" civic_ca14 = "" civic_ca15 = "" civic_ca16 = "" civic_ca17 = "" civic_ca18 = "" civic_ca19 = "1" civic_ca20 = "" civic_ca21 = "" civic_ca22 = "" civic_ca23 = "Gemeindeamt" civic_ca24 = "7100" civic_ca25 = "" civic_ca26 = "" civic_ca27 = "" civic_ca28 = "" civic_ca29 = "" civic_ca30 = "" civic_ca31 = "" coordinate_based_lci = "4B:BD:C2:8F:5C:49:2E:6E:2E:C3:13:C0:00:21:B3:01" elin = "001234567890123" --- Use location_data_format to select the type of location information (civic, geodetic, or ELIN). civic_caXX means the CAtype number listed in RFC4776, coordiate_based_lci uses the format of RFC3825 (you can use the encoder available at http://www.voip-sos.net/demo/dhcloc/) Best, Karl 2011/5/26 김인기(Inkee Kim) <ink...@lg...>: > Dear All, > > > > I'd like to enable LLDP-MED by "lldpd -l <file>" > > > > However, I could not fine any information about lldp.conf. > > > > Could you please give me an example of lldp.conf or detail information about > it? > > > > Best regards, > > > > I.K.Kim > > ------------------------------------------------------------------------------ > vRanger cuts backup time in half-while increasing security. > With the market-leading solution for virtual backup and recovery, > you get blazing-fast, flexible, and affordable data protection. > Download your free trial now. > http://p.sf.net/sfu/quest-d2dcopy1 > _______________________________________________ > Openlldp-users mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openlldp-users > > |
|
From: Karl H. W. <kh...@gm...> - 2011-05-26 08:30:04
|
Kim, here is an example lldp.conf file: --- location_data_format = 1 civic_countrycode = "AT" civic_what = 1 civic_ca0 = "" civic_ca1 = "Burgenland" civic_ca2 = "Neusiedl am See" civic_ca3 = "Neusiedl am See" civic_ca4 = "" civic_ca5 = "" civic_ca6 = "Hauptplatz" civic_ca7 = "" civic_ca8 = "" civic_ca9 = "" civic_ca10 = "" civic_ca11 = "" civic_ca12 = "" civic_ca13 = "" civic_ca14 = "" civic_ca15 = "" civic_ca16 = "" civic_ca17 = "" civic_ca18 = "" civic_ca19 = "1" civic_ca20 = "" civic_ca21 = "" civic_ca22 = "" civic_ca23 = "Gemeindeamt" civic_ca24 = "7100" civic_ca25 = "" civic_ca26 = "" civic_ca27 = "" civic_ca28 = "" civic_ca29 = "" civic_ca30 = "" civic_ca31 = "" coordinate_based_lci = "4B:BD:C2:8F:5C:49:2E:6E:2E:C3:13:C0:00:21:B3:01" elin = "001234567890123" --- Use location_data_format to select the type of location information (civic, geodetic, or ELIN). civic_caXX means the CAtype number listed in RFC4776, coordiate_based_lci uses the format of RFC3825 (you can use the encoder available at http://www.voip-sos.net/demo/dhcloc/) Best, Karl 2011/5/26 김인기(Inkee Kim) <ink...@lg...>: > Dear All, > > > > I'd like to enable LLDP-MED by "lldpd -l <file>" > > > > However, I could not fine any information about lldp.conf. > > > > Could you please give me an example of lldp.conf or detail information about > it? > > > > Best regards, > > > > I.K.Kim > > ------------------------------------------------------------------------------ > vRanger cuts backup time in half-while increasing security. > With the market-leading solution for virtual backup and recovery, > you get blazing-fast, flexible, and affordable data protection. > Download your free trial now. > http://p.sf.net/sfu/quest-d2dcopy1 > _______________________________________________ > Openlldp-users mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openlldp-users > > |
|
From: 김인기(Inkee K. <ink...@lg...> - 2011-05-26 07:38:55
|
Dear All, I'd like to enable LLDP-MED by "lldpd -l <file>" However, I could not fine any information about lldp.conf. Could you please give me an example of lldp.conf or detail information about it? Best regards, I.K.Kim |
|
From: Terry S. <ter...@gm...> - 2011-02-11 19:08:28
|
Hi Elliott, Thanks for supporting OpenLLDP. Windows is a tricky platform to support because of the necessity of the protocol driver. I started working on this a while back but got stuck and I really haven't had a chance to dig back into it. Which version of Windows would you be most interested in seeing the support for? The Windows networking driver stack changed dramatically between XP and Vista and then again minimally between Vista and Windows 7, so there will be a fair bit of work there. It's possible that we could write an NDIS 5 driver that will work on all 3 platforms, but I haven't fully investigated that yet. We've added the necessary bits to make the client install/start as a Windows service and the code also was compiling on Windows (though it probably requires some additional work now). I also had worked on an installer for the project, but I don't recall if that has been checked into the source tree yet. In terms of what still needs to be done: * The Protocol Driver needs to be written (we can use the Open1X NDIS 5 driver as a starting point - it's largely what we need). * The internals of the project need to be reworked to facilitate Windows' networking methodologies. * An IPC mechanism would need to be implemented to get lldpneighbors to work. There may be other issues that aren't obvious right now, but those are the basic things needed to get the project working in Windows. It's not a lot of work, but it's involved. I may have some time to work on this over the weekend. If I can get the protocol driver working it will be a lot easier to move forward with the port. - Terry On Fri, Feb 11, 2011 at 9:11 AM, ELLIOTT SHAWD <sh...@bu...>wrote: > Hi, > > I work for the Math Department IT at The Ohio State University and > recently came across your lldp client. Our environment consists primarily of > Mac OS X and Linux machines and we have implemented OpenLLDP for the > majority of our environment. On behalf of my IT group, we would like to > thank you for your contributions as we are absolutely in heaven with your > product. We continually strive for these sorts of additions to our > environment to help us maintain a centralized and organized management > strategy. We greatly appreciate the time and effort you have put into your > work as it has greatly benefitted us and IT professionals abroad. > > I have done a fair amount of research on LLDP and it seems there are many > options for OSX and Linux out there. This is great seeing as how most of our > environment consists of these operating systems. However, unfortunately, we > have begun to assimilate the Windows OS into our environment and would > obviously like consistency and the same level of vision for these machines > as we do our Mac and Linux machines. I have read that you guys have been > developing OpenLLDP for Windows and I understand that this is a much bigger > task than your LLDP implementation for Linux and OSX. > > Please let me know if there is anything we, as an organization, can help > to push this project forward and come up with an LLDP solution for Windows. > My team, as well as others in Math IT, are very interested to see the > benefits this can provide. We are constantly researching and staying on top > of technology to try and make improvements the best we can and I feel that > LLDP is a simple feature that would greatly improve our ability to peer > inside our network. If possible, enlighten me on the progress you have made > on the Windows version and, again, please let me know if there is anything I > can do to help. > > > Thank you, > Elliott Shawd > Network Engineer > Math Department IT > The Ohio State University > > > ------------------------------------------------------------------------------ > The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: > Pinpoint memory and threading errors before they happen. > Find and fix more than 250 security defects in the development cycle. > Locate bottlenecks in serial and parallel code that limit performance. > http://p.sf.net/sfu/intel-dev2devfeb > _______________________________________________ > Openlldp-users mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openlldp-users > > |
|
From: ELLIOTT S. <sh...@bu...> - 2011-02-11 17:24:13
|
Hi, I work for the Math Department IT at The Ohio State University and recently came across your lldp client. Our environment consists primarily of Mac OS X and Linux machines and we have implemented OpenLLDP for the majority of our environment. On behalf of my IT group, we would like to thank you for your contributions as we are absolutely in heaven with your product. We continually strive for these sorts of additions to our environment to help us maintain a centralized and organized management strategy. We greatly appreciate the time and effort you have put into your work as it has greatly benefitted us and IT professionals abroad. I have done a fair amount of research on LLDP and it seems there are many options for OSX and Linux out there. This is great seeing as how most of our environment consists of these operating systems. However, unfortunately, we have begun to assimilate the Windows OS into our environment and would obviously like consistency and the same level of vision for these machines as we do our Mac and Linux machines. I have read that you guys have been developing OpenLLDP for Windows and I understand that this is a much bigger task than your LLDP implementation for Linux and OSX. Please let me know if there is anything we, as an organization, can help to push this project forward and come up with an LLDP solution for Windows. My team, as well as others in Math IT, are very interested to see the benefits this can provide. We are constantly researching and staying on top of technology to try and make improvements the best we can and I feel that LLDP is a simple feature that would greatly improve our ability to peer inside our network. If possible, enlighten me on the progress you have made on the Windows version and, again, please let me know if there is anything I can do to help. Thank you, Elliott Shawd Network Engineer Math Department IT The Ohio State University |
|
From: Karl H. W. <kh...@gm...> - 2010-06-28 13:57:52
|
> >> This release also includes a man page contributed by Roar Petterson as well >> as LLDP-MED location patches submitted by Karl Heinz. > > Didn't find any man page. There seems no example location file, and trying to include a file, gives the following message > > $ sudo ./lldpd -i en0 -f -dx -l loc.txt > Using interface en0 > OpenLLDP wasn't compiled with libconfuse support. > > How can I force it to send LLDP-MED TLV's? Hi Mike! Do you have libconfuse available on your system? It is necessary to parse the config file. The config file is currently only used for location information, I'll attach an example config file to this mail. "caXX" refers to the civic address types, coordinate based (already encoded) as well as ELIN are supported - but just one location format can be sent out (selected by "location_data_format" in the first line of the config file). So if you install libconfuse, recompile openlldp, and use the config file, location information should be sent. Does it work now? cheers karl > > > Thanks > > Mike > > > > ------------------------------------------------------------------------------ > ThinkGeek and WIRED's GeekDad team up for the Ultimate > GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the > lucky parental unit. See the prize list and enter to win: > http://p.sf.net/sfu/thinkgeek-promo > _______________________________________________ > Openlldp-users mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openlldp-users > |
|
From: Savory M. <msa...@nz...> - 2010-06-25 00:46:54
|
Hi > The OpenLLDP team is pleased to announce the release of OpenLLDP 0.4 alpha! Seems to install and run OK on Mac OS X 10.6.4 > Another exciting improvement is the lldpneighbors command, which will > display the LLDP MSAP cache data from connected systems. OpenLLDP Neighbor Info: Interface 'en0' has 1 LLDP Neighbors: Neighbor 1: Chassis ID: MAC Address - 00 15 77 c9 c6 34 Port ID: Port Component - 30 31 Time To Live: 120 seconds Port Description: Port_01 System Name: AT-9000/28 System Description: AT-9000/28 System Capabiltiies: Bridge/Switch (enabled) Router (enabled) Management Address: IPv4 - 10.0.37.13 (System Port Number - 16777216) (OID: Standard LLDP MIB) Organizationally Specific: 00 80 c2 01 00 Organizationally Specific: 00 80 c2 02 00 00 Organizationally Specific: 00 80 c2 03 00 01 0c 44 65 66 61 75 6c 74 5f 56 4c 41 Organizationally Specific: 00 12 0f 01 03 6c 01 00 Organizationally Specific: 00 12 0f 02 00 00 Organizationally Specific: 00 12 0f 03 01 00 00 00 Organizationally Specific: 00 12 0f 04 05 End Of LLDPDU: > This release also includes a man page contributed by Roar Petterson as well > as LLDP-MED location patches submitted by Karl Heinz. Didn't find any man page. There seems no example location file, and trying to include a file, gives the following message $ sudo ./lldpd -i en0 -f -dx -l loc.txt Using interface en0 OpenLLDP wasn't compiled with libconfuse support. How can I force it to send LLDP-MED TLV's? Thanks Mike |
|
From: Terry S. <ter...@gm...> - 2010-06-18 16:33:32
|
Hi Mike, There isn't currently a configuration file for OpenLLDP except for the location specific data (which may not have made it into the tarball). OpenLLDP queries all interfaces and dynamically determines the values as of now. It's possible that you're seeing innocuous errors that won't prevent OpenLLDP from working, but I'd need to see a full debug log to be sure. By default OpenLLDP daemonizes and runs in the background, but you can run it in full debug in the foreground with the following command: ./lldpd -d A -f If you can send me the output from that I can tell you what might be going on. What sorts of configuration data are you looking for? Thanks! - Terry On Fri, Jun 18, 2010 at 10:21 AM, Michael Schwager <msc...@gm...>wrote: > Hi, > I am trying to run openlldp alpha 4 and I can't find an example config file > for it. It compiles ok, seems to start in the background on my RHEL5.3 > x86_64 box, but it does start up with errors. > > Thanks for any help. > > -- > -Mike Schwager > > > ------------------------------------------------------------------------------ > ThinkGeek and WIRED's GeekDad team up for the Ultimate > GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the > lucky parental unit. See the prize list and enter to win: > http://p.sf.net/sfu/thinkgeek-promo > _______________________________________________ > Openlldp-users mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openlldp-users > > |
|
From: Michael S. <msc...@gm...> - 2010-06-18 16:21:22
|
Hi, I am trying to run openlldp alpha 4 and I can't find an example config file for it. It compiles ok, seems to start in the background on my RHEL5.3 x86_64 box, but it does start up with errors. Thanks for any help. -- -Mike Schwager |
|
From: Terry S. <ter...@gm...> - 2010-06-11 05:53:52
|
The OpenLLDP team is pleased to announce the release of OpenLLDP 0.4 alpha! The license for OpenLLDP has been changed to BSD to facilitate inclusion into commercial products without needing to license the code. We would still appreciate patches so that OpenLLDP can continue to benefit the community. Another exciting improvement is the lldpneighbors command, which will display the LLDP MSAP cache data from connected systems. This release also includes a man page contributed by Roar Petterson as well as LLDP-MED location patches submitted by Karl Heinz. Stig Telfer also submitted a patch to fix a configuration issue and Tom Judge submitted some BPF patches for FreeBSD. We appreciate the patches, so keep them coming! Example output from lldpneighbors: OpenLLDP Neighbor Info: Interface 'en5' has 2 LLDP Neighbors: Neighbor 1: Chassis ID: MAC Address - 00 25 61 90 81 b0 Port ID: Locally Assigned - 1 Time To Live: 120 seconds Port Description: Port #1 System Name: PROCURVE J9449A System Description: HP ProCurve 1810G - 8 GE, P.1.17, eCos-2.0 System Capabiltiies: Bridge/Switch (enabled) Management Address: IPv4 - 192.168.2.10 (ifIndex - 419430400) (OID: Proprietary MIB) End Of LLDPDU: Neighbor 2: Chassis ID: MAC Address - 00 22 3f ff f1 16 Port ID: Interface Name - g1 Time To Live: 120 seconds Port Description: Port #1 System Description: Smart Switch System Capabiltiies: Bridge/Switch (enabled) Management Address: IPv4 - 192.168.0.239 (Unknown - 0) (OID: Proprietary MIB) Organizationally Specific: 00 80 c2 01 00 Organizationally Specific: 00 12 0f 01 03 0c 3f 00 Organizationally Specific: 00 12 0f 03 01 00 00 00 Organizationally Specific: 00 12 0f 04 05 End Of LLDPDU: The OpenLLDP Team |
|
From: Terry S. <ter...@gm...> - 2008-12-17 22:36:52
|
We were considering it at one point but I'm not sure there is actually a benefit to the project to do it, honestly. Ultimately it would be nice for us to get patches back (via GPLv2 or whatnot) or some other useful thing (such as gear to test on) because we are doing this in our free time and it isn't clear whether licensing the code GPL/BSD would actually benefit us. If the code was BSD licensed, would you still be contributing patches back? - Terry On Wed, Dec 17, 2008 at 2:34 PM, mark mckinstry <mar...@al...> wrote: > Hi Terry > > In your reply to Vincent Bernat you said: > > "We're actually going to change the license over to GPLv2/BSD, so I'll get the license files updated to reflect the actual version." > > Did you make this change? The latest LICENCE file says: > > "This software offers a choice of a GPL (v2) license or the option to negotiate and purchase a private license from the OpenLLDP team." > > and source code headers say "GPL/Proprietary license". Are you still intending to offer a BSD licence? > > Thanks > Mark > > > > ------------------------------------------------------------------------------ > SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. > The future of the web can't happen without you. Join us at MIX09 to help > pave the way to the Next Web now. Learn more and register at > http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ > _______________________________________________ > Openlldp-users mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openlldp-users > |
|
From: mark m. <mar...@al...> - 2008-12-17 22:02:09
|
Hi Terry In your reply to Vincent Bernat you said: "We're actually going to change the license over to GPLv2/BSD, so I'll get the license files updated to reflect the actual version." Did you make this change? The latest LICENCE file says: "This software offers a choice of a GPL (v2) license or the option to negotiate and purchase a private license from the OpenLLDP team." and source code headers say "GPL/Proprietary license". Are you still intending to offer a BSD licence? Thanks Mark |
|
From: Vincent B. <be...@lu...> - 2008-07-27 16:37:46
|
OoO En cette matinée pluvieuse du dimanche 06 juillet 2008, vers 10:07, je disais: >> I will try to write the manual page this week-end, as well as an init >> script so that you can include them in the next release. > Here is a manual page for lldpneighbors: [...] Hi Terry! Any news on this matter? -- BOFH excuse #333: A plumber is needed, the network drain is clogged |
|
From: Vincent B. <be...@lu...> - 2008-07-06 08:07:56
|
OoO En ce début de soirée du vendredi 04 juillet 2008, vers 21:18, je disais: > I will try to write the manual page this week-end, as well as an init > script so that you can include them in the next release. Here is a manual page for lldpneighbors: |
|
From: Tom J. <to...@to...> - 2008-07-06 00:42:49
|
Sorry for the late reply.
Terry Simons wrote:
> I've done a bit more digging into this, as my system (Intel Mac Pro) was
> having problems receiving frames.
>
> Oddly enough, if I fired up tcpdump -i en1 -vvvv or some such, I would
> begin seeing the frames. This led me to believe that the multicast
> settings weren't taking effect on my system.
[See comment about tcpdump further down]
>
> I've added some code to try and determine if the multicast set fails,
> and attempt to set promiscuous mode in that case, but after reading this
> E-mail thread again, maybe that's not the right behavior?
[All comments are related to FreeBSD rather than OSX, although the user
land code is going to be similar the kernel is a completely different beast]
Looking through the add_multi function in the bpf framer, it looks like
I could be making a mistake about the lifetime of the address being
bound to the interface.
The function opens a socket on the interface and then sets/unsets the
multi cast address filter and then closes the socket. I don't know if
this is true, but what if closing the socket removes the address filter?
This would explain the error when trying to remove the address from
the interface as it shuts down, however it would not explain why we
still receive the frames on the interface.
>
> I suppose I can wrap that code with #ifdef __APPLE__ defines, but I
> don't particularly like doing that.
>
Not sure that this is and Apple problem, I have only tested on FreeBSD
not any of the other BSD's (Net, Open, DragonFly etc...), this may be a
problem there as well.
> Tom, do you think that it's safe to kick into promiscuous mode if adding
> multicast mode fails?
Other than the IOCTL failing, i'm not sure that there is a reliable way
to check that the address is programmed into the MAC, on FreeBSD anyway,
there may be ways to do this on other BPF platforms.
Maybe the fall back should be to enable ALLMULTI rather than promisc,
from a security point of view I would not want my production routers
running openlldpd if it was going to put the interfaces into promisc mode.
> The odd thing is that Mike's system appeared to
> be receving frames just fine... Mike you weren't running tcpdump or
> wireshark or anything like that in your testing were you?
>
If you test with tcpdump -p, tcpdump will not put the interface into
PROMISC, this should allow you to see if the controller is accepting the
frames.
> It certainly seems that if a multicast add failure occurs, we can't
> assume that the interface is properly set up to recieve frames....
Agreed.
Unfortunately I don't have a Mac or any other *BSD installations to test
with, although I may setup a NetBSD box for some development soon.
There is still the problem of broken hardware, that does nothing with
SOICADDMULTI. Maybe is worth adding a command line flag or two to force
putting the interfaces into promisc or allmulti rather than trying to
detect all of the complex failure modes?
Another option would be to have a flag for the timer on the remote
system and to fire an event every interval*2 to change the interface
mode (program with addmulti -> allmulti -> promisc) each time the timer
expires and no packet was received.
On a side note my original patch for init_multi had a huge nasty kludge
in it. I think it may be worth considering the attached patch.
Tom
>
> On Tue, Jun 10, 2008 at 6:47 PM, Tom Judge <to...@to...
> <mailto:to...@to...>> wrote:
>
> Terry Simons wrote:
>
> Hmmm interesting. There could be a bug there. I'll look into
> it. I did the original Apple dev on a PPC G5, so there might be
> some Intel bugs lurking.
>
> Also, the error about not being able to malloc is not good...
> that's scary. I'll see if I can reproduce it. ;) How much
> memory does your system have? I wonder if I didn't initialize a
> variable correctly and it had some insane default value that
> would cause malloc to fail... Worst case we can put some
> additional debug in and have you try again.
>
> I'll take a look at the code and see if anything obvious pops out.
>
> - Terry
>
>
>
> It seems that I am responsible for this error message:
>
> ioctl[SIOC{ADD/DEL}MULTI]: Device not configured
>
> Do you see the message during process startup or shutdown?
>
> From the little digging that I have just done, and what I can
> remember here my attempt at explaining why I adding this code.
>
> To start out the BPF framer was placing the nic into promiscuous
> mode so that the interface would receive packets for link level
> ethernet multicast address. So during setup and teardown of the
> interface we blindly register and un-register the the LLDP ethernet
> address with the interface MAC.
>
> On the FreeBSD 6.2 test systems that I was using this error would
> present during lldpd shutdown and framer tear down.
>
> From what I can see it is down to the NIC driver to decide how to
> deal with this ioctl, the drivers I have been testing on will emit
> this error during shutdown (Intel em driver and Broadcom bce) but
> not startup. It seems that they only support adding the address to
> the MAC not removing it.
>
> See this thread on thread on the FreeBSD net mailing list about
> implementing this feature:
>
> http://unix.derkeiler.com/Mailing-Lists/FreeBSD/net/2008-01/msg00133.html
>
>
> From what I can see from your debug output, it seems that your nic
> is receiving the packets and passing them into bpf and lldpd. Can
> you please confirm that your nic is not promisc when running lldpd?
>
> If the nic is not promiscuous and lldpd is receiving frames then you
> can safely ignore the warning emitted during the programming of the
> MAC with the multicast address.
>
> These warnings should have absolutely no effect on transmitting the
> LLDP frame, you should see packets in and out to the following mac
> 01:80:c2:00:00:0e.
>
> Maybe its worth checking the debug level and only calling perror if
> a suitable debug level is set? That is if this error seems to be
> safe to ignore.
>
>
> I can't help you with the malloc issue I am afraid.
>
>
> Regards
>
> Tom
>
>
>
>
>
>
> On Mon, Jun 9, 2008 at 4:22 PM, Mike Savory <ms...@nz...
> <mailto:ms...@nz...> <mailto:ms...@nz...
> <mailto:ms...@nz...>>> wrote:
>
> Hi
>
> Its not actually sending any packets, is it meant to? Do I
> need to
> point it at a configuration file?
>
> Looks like it may fail to open a multicast socket...
> ioctl[SIOC{ADD/DEL}MULTI]: Device not configured
>
> When it receives a packet it does this...
>
> Running RX state machine for en0
> Copying TLV1 for MSAP Processing...
> Copying TLV2 for MSAP Processing...
> [ERROR] Unable to malloc buffer in rxProcessFrame() at line: 237!
> Decrementing RX Timers
> Displaying RX Timers
> ) rxInfoTTL: 119
> Running RX state machine for en0
> Decrementing RX Timers
> Displaying RX Timers
> ) rxInfoTTL: 118
> ....
>
>
> The packet it was receiving...
>
> $ sudo tcpdump -i en0 ether dst 01:80:c2:00:00:0e
>
> 15:01:20.625892 00:00:cd:27:be:72 (oui Unknown) >
> 01:80:c2:00:00:0e
> (oui Unknown), ethertype Unknown (0x88cc),
> length 127:
> 0x0000: 0207 0400 00cd 27be 7204 0605 706f 7274
> ......'.r...port
> 0x0010: 3106 0200 7808 0570 6f72 7431 0a00 0c39
> 1...x..port1...9
> 0x0020: 7839 3030 2d32 3458 5420 4154 2d39 3932
> x900-24XT.AT-992
> 0x0030: 3454 7369 2c20 7665 7273 696f 6e20 332e
> 4Tsi,.version.3.
> 0x0040: 322e 312d 3033 2c20 6275 696c 7420 3232
> 2.1-03,.built.22
> 0x0050: 2d4d -M
>
>
>
> Regards
>
> Mike
>
>
>
> On Jun 8, 2008, at 2:15 PM, Mike Savory wrote:
>
> > Hi
> >
> > Trying to build on a OSX Leopard 10.5.3 Intel Core 2 Duo
> (64 bit)
> > Seems to be a disagreement in the BPF code, tried
> >
>
>
>
|
|
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: Vincent B. <be...@lu...> - 2008-07-04 19:18:39
|
OoO En ce début de soirée du vendredi 04 juillet 2008, vers 21:06, "Terry Simons" <ter...@gm...> disait : > I've committed your /var/run socket patch as well as this daemonizing patch. > Do you want me to send you the debian files that I was given so you can use > those to base a package off of? I'd like to incorporate that sort of work into > the project, if possible, to make everyone's life easier as well as allow > end-users to re-roll their packages if needed. I have already packaged openlldp. I attach you a tar.gz of the debian directory that I intend to use (obviously, the patch are not needed any more). This is not a final work since it is missing some things (manual page for lldpneighbors, missing an init script). I will try to write the manual page this week-end, as well as an init script so that you can include them in the next release. You can send me what you have, I may digg some ideas. If you plan to put the debian/ directory into CVS, please, don't ship it with releases: this makes difficult for us to modify the packaging (for example, removing files is difficult). |
|
From: Terry S. <ter...@gm...> - 2008-07-04 19:06:08
|
I've committed your /var/run socket patch as well as this daemonizing patch. Do you want me to send you the debian files that I was given so you can use those to base a package off of? I'd like to incorporate that sort of work into the project, if possible, to make everyone's life easier as well as allow end-users to re-roll their packages if needed. Now that I've squashed the last couple of weird issues I was seeing, I'm going to run through some Net/Free/OpenBSD testing with OS X and Linux as well. If things look good I'll update the license documentation and get ready to roll out a release. - Terry On Fri, Jul 4, 2008 at 12:15 PM, Vincent Bernat <be...@lu...> wrote: > OoO En ce doux début de matinée du vendredi 04 juillet 2008, vers 08:54, > je disais: > > > I will try to submit you a patch to make lldpd a daemon. > > Here it is. I also implement the -o option. > > > -- > MY MOM IS NOT DATING JERRY SEINFELD > MY MOM IS NOT DATING JERRY SEINFELD > MY MOM IS NOT DATING JERRY SEINFELD > -+- Bart Simpson on chalkboard in episode AABF06 > > |
|
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: Vincent B. <be...@lu...> - 2008-07-04 18:15:02
|
OoO En ce doux début de matinée du vendredi 04 juillet 2008, vers 08:54, je disais: > I will try to submit you a patch to make lldpd a daemon. Here it is. I also implement the -o option. |
|
From: Vincent B. <be...@lu...> - 2008-07-04 06:54:18
|
On Fri, 4 Jul 2008 00:32:37 -0600, "Terry Simons" <ter...@gm...> wrote: > It seems as though we have a few bugs regarding processing of certain > frames. Can you run lldpd with the "-d A" flags and send me the output of > your Nortel frame? That will help me reproduce the "can't allocate > memory" > error. Here it is : [INT] br0 is readable! [INT] Got an LLDP frame 251 bytes long on br0! Running RX state machine for br0 [STATE] [br0] RX_WAIT_FOR_FRAME -> RX_FRAME [INT] (br0) Processing Frame: 000 | 01 80 c2 00 00 0e 00 1f 46 d2 fc 01 88 cc 02 07 | ........F....... 010 | 04 00 1f 46 d2 fc 00 04 07 03 00 1f 46 d2 fc 04 | ...F........F... 020 | 06 02 00 78 08 06 50 6f 72 74 20 34 0a 07 73 77 | ...x..Port 4..sw 030 | 69 74 63 68 31 0c 4c 45 74 68 65 72 6e 65 74 20 | itch1.LEthernet 040 | 52 6f 75 74 69 6e 67 20 53 77 69 74 63 68 20 35 | Routing Switch 5 050 | 35 31 30 2d 32 34 54 20 20 20 20 20 20 48 57 3a | 510-24T HW: 060 | 33 33 20 20 20 20 20 20 20 46 57 3a 35 2e 30 2e | 33 FW:5.0. 070 | 30 2e 34 20 20 20 53 57 3a 76 35 2e 31 2e 30 2e | 0.4 SW:v5.1.0. 080 | 30 31 34 0e 04 00 14 00 14 10 15 05 01 ac 14 03 | 014............. 090 | 02 01 00 00 00 00 09 2b 06 01 04 01 2d 03 34 01 | .......+....-.4. 0a0 | fe 06 00 80 c2 01 00 01 fe 07 00 80 c2 02 06 00 | ................ 0b0 | 01 fe 0e 00 80 c2 03 00 01 07 56 4c 41 4e 20 23 | ..........VLAN # 0c0 | 31 fe 0d 00 80 c2 04 08 00 26 42 42 03 00 00 00 | 1........&BB.... 0d0 | fe 08 00 80 c2 04 03 88 8e 01 fe 07 00 80 c2 04 | ................ 0e0 | 02 88 cc fe 09 00 12 0f 01 03 6c 21 00 1e fe 09 | ..........l!.... 0f0 | 00 12 0f 03 00 00 00 00 00 00 00 | ........... [INT] LLPDU Dst: 01 80 c2 00 00 0e [EXCESSIVE] Expect Dst: 01 80 c2 00 00 0e [INT] LLPDU Src: 00 1f 46 d2 fc 01 [INT] LLPDU Ethertype: 88cc [EXCESSIVE] Expect Ethertype: 88cc [TLV] Processing TLV #: 1 [EXCESSIVE] TLV type: 1 (Chassis ID) Length: 7 [EXCESSIVE] TLV would read to: 23, Frame ends at: 251 [EXCESSIVE] Found a validator for TLV type 1. 000 | 04 00 1f 46 d2 fc 00 | ...F... [EXCESSIVE] Adding exploded TLV to MSAP TLV list. [EXCESSIVE] Done Copying TLV1 for MSAP Processing... [TLV] Processing TLV #: 2 [EXCESSIVE] TLV type: 2 (Port ID) Length: 7 [EXCESSIVE] TLV would read to: 32, Frame ends at: 251 [EXCESSIVE] Found a validator for TLV type 2. 000 | 03 00 1f 46 d2 fc 04 | ...F... [EXCESSIVE] Adding exploded TLV to MSAP TLV list. [TLV] Setting temp->next to 1CCF8A0 [EXCESSIVE] Done Copying TLV2 for MSAP Processing... [MSAP] MSAP TLV1 Length: 7 [MSAP] MSAP TLV2 Length: 7 [MSAP] MSAP is 12 bytes: 00 1f 46 d2 fc 00 00 1f 46 d2 fc 04 000 | 00 1f 46 d2 fc 00 00 1f 46 d2 fc 04 | ..F.....F... [TLV] Processing TLV #: 3 [EXCESSIVE] TLV type: 3 (Time To Live) Length: 2 [EXCESSIVE] TLV would read to: 36, Frame ends at: 251 [EXCESSIVE] rxTTL is: 120 [EXCESSIVE] Found a validator for TLV type 3. 000 | 00 78 | .x [EXCESSIVE] Adding exploded TLV to MSAP TLV list. [TLV] Setting temp->next to 1CCF800 [EXCESSIVE] Done [TLV] Processing TLV #: 4 [EXCESSIVE] TLV type: 4 (Port Description) Length: 6 [EXCESSIVE] TLV would read to: 44, Frame ends at: 251 [EXCESSIVE] Found a validator for TLV type 4. 000 | 50 6f 72 74 20 34 | Port 4 [EXCESSIVE] Adding exploded TLV to MSAP TLV list. [TLV] Setting temp->next to 1CCF940 [EXCESSIVE] Done [TLV] Processing TLV #: 5 [EXCESSIVE] TLV type: 5 (System Name) Length: 7 [EXCESSIVE] TLV would read to: 53, Frame ends at: 251 [EXCESSIVE] Found a validator for TLV type 5. 000 | 73 77 69 74 63 68 31 | switch1 [EXCESSIVE] Adding exploded TLV to MSAP TLV list. [TLV] Setting temp->next to 1CCF9A0 [EXCESSIVE] Done [TLV] Processing TLV #: 6 [EXCESSIVE] TLV type: 6 (System Description) Length: 76 [EXCESSIVE] TLV would read to: 131, Frame ends at: 251 [EXCESSIVE] Found a validator for TLV type 6. 000 | 45 74 68 65 72 6e 65 74 20 52 6f 75 74 69 6e 67 | Ethernet Routing 010 | 20 53 77 69 74 63 68 20 35 35 31 30 2d 32 34 54 | Switch 5510-24T 020 | 20 20 20 20 20 20 48 57 3a 33 33 20 20 20 20 20 | HW:33 030 | 20 20 46 57 3a 35 2e 30 2e 30 2e 34 20 20 20 53 | FW:5.0.0.4 S 040 | 57 3a 76 35 2e 31 2e 30 2e 30 31 34 | W:v5.1.0.014 [EXCESSIVE] Adding exploded TLV to MSAP TLV list. [TLV] Setting temp->next to 1CCFA80 [EXCESSIVE] Done [TLV] Processing TLV #: 7 [EXCESSIVE] TLV type: 7 (System Capabiltiies) Length: 4 [EXCESSIVE] TLV would read to: 137, Frame ends at: 251 [EXCESSIVE] Found a validator for TLV type 7. 000 | 00 14 00 14 | .... [EXCESSIVE] Adding exploded TLV to MSAP TLV list. [TLV] Setting temp->next to 1CCFAA0 [EXCESSIVE] Done [TLV] Processing TLV #: 8 [EXCESSIVE] TLV type: 8 (Management Address) Length: 21 [EXCESSIVE] TLV would read to: 160, Frame ends at: 251 [EXCESSIVE] Found a validator for TLV type 8. 000 | 05 01 ac 14 03 02 01 00 00 00 00 09 2b 06 01 04 | ............+... 010 | 01 2d 03 34 01 | .-.4. [EXCESSIVE] Adding exploded TLV to MSAP TLV list. [TLV] Setting temp->next to 1CCFB00 [EXCESSIVE] Done [TLV] Processing TLV #: 9 [EXCESSIVE] TLV type: 127 (Organizationally Specific) Length: 6 [EXCESSIVE] TLV would read to: 168, Frame ends at: 251 [EXCESSIVE] Found a validator for TLV type 127. 000 | 00 80 c2 01 00 01 | ...... [EXCESSIVE] Adding exploded TLV to MSAP TLV list. [TLV] Setting temp->next to 1CCFB60 [EXCESSIVE] Done [TLV] Processing TLV #: 10 [EXCESSIVE] TLV type: 127 (Organizationally Specific) Length: 7 [EXCESSIVE] TLV would read to: 177, Frame ends at: 251 [EXCESSIVE] Found a validator for TLV type 127. 000 | 00 80 c2 02 06 00 01 | ....... [EXCESSIVE] Adding exploded TLV to MSAP TLV list. [TLV] Setting temp->next to 1CCFBC0 [EXCESSIVE] Done [TLV] Processing TLV #: 11 [EXCESSIVE] TLV type: 127 (Organizationally Specific) Length: 14 [EXCESSIVE] TLV would read to: 193, Frame ends at: 251 [EXCESSIVE] Found a validator for TLV type 127. 000 | 00 80 c2 03 00 01 07 56 4c 41 4e 20 23 31 | .......VLAN #1 [EXCESSIVE] Adding exploded TLV to MSAP TLV list. [TLV] Setting temp->next to 1CCFC20 [EXCESSIVE] Done [TLV] Processing TLV #: 12 [EXCESSIVE] TLV type: 127 (Organizationally Specific) Length: 13 [EXCESSIVE] TLV would read to: 208, Frame ends at: 251 [EXCESSIVE] Found a validator for TLV type 127. 000 | 00 80 c2 04 08 00 26 42 42 03 00 00 00 | ......&BB.... [EXCESSIVE] Adding exploded TLV to MSAP TLV list. [TLV] Setting temp->next to 1CCFC80 [EXCESSIVE] Done [TLV] Processing TLV #: 13 [EXCESSIVE] TLV type: 127 (Organizationally Specific) Length: 8 [EXCESSIVE] TLV would read to: 218, Frame ends at: 251 [EXCESSIVE] Found a validator for TLV type 127. 000 | 00 80 c2 04 03 88 8e 01 | ........ [EXCESSIVE] Adding exploded TLV to MSAP TLV list. [TLV] Setting temp->next to 1CCFCE0 [EXCESSIVE] Done [TLV] Processing TLV #: 14 [EXCESSIVE] TLV type: 127 (Organizationally Specific) Length: 7 [EXCESSIVE] TLV would read to: 227, Frame ends at: 251 [EXCESSIVE] Found a validator for TLV type 127. 000 | 00 80 c2 04 02 88 cc | ....... [EXCESSIVE] Adding exploded TLV to MSAP TLV list. [TLV] Setting temp->next to 1CCFD40 [EXCESSIVE] Done [TLV] Processing TLV #: 15 [EXCESSIVE] TLV type: 127 (Organizationally Specific) Length: 9 [EXCESSIVE] TLV would read to: 238, Frame ends at: 251 [EXCESSIVE] Found a validator for TLV type 127. 000 | 00 12 0f 01 03 6c 21 00 1e | .....l!.. [EXCESSIVE] Adding exploded TLV to MSAP TLV list. [TLV] Setting temp->next to 1CCFDA0 [EXCESSIVE] Done [TLV] Processing TLV #: 16 [EXCESSIVE] TLV type: 127 (Organizationally Specific) Length: 9 [EXCESSIVE] TLV would read to: 249, Frame ends at: 251 [EXCESSIVE] Found a validator for TLV type 127. 000 | 00 12 0f 03 00 00 00 00 00 | ......... [EXCESSIVE] Adding exploded TLV to MSAP TLV list. [TLV] Setting temp->next to 1CCFE00 [EXCESSIVE] Done [TLV] Processing TLV #: 17 [EXCESSIVE] TLV type: 0 (End Of LLDPDU) Length: 0 [EXCESSIVE] TLV would read to: 251, Frame ends at: 251 [EXCESSIVE] Found a validator for TLV type 0. [ERROR] Couldn't allocate memory!! [TLV] Error copying TLV for MSAP cache! [EXCESSIVE] Adding exploded TLV to MSAP TLV list. [TLV] Setting temp->next to 1CCFE40 [EXCESSIVE] Done [TLV] We have a(n) 12 byte MSAP! [MSAP] Setting rxInfoTTL to: 120 [MSAP] MSAP Length: C [MSAP] MSAP Cache Hit on br0 [MSAP] MSAP cache: 1CCFE60 [MSAP] MSAP ID: 00 1f 46 d2 fc 00 00 1f 46 d2 fc 04 [MSAP] MSAP Length: C [MSAP] MSAP Next: 0 [TLV] Destroy TLV List [TLV] Entering Destroy loop [TLV] current = 1CCF2F0 [TLV] current->next = 1CCF210 [TLV] Freeing TLV Info String. [TLV] Freeing TLV. [TLV] Freeing TLV List Node. [TLV] current = 1CCF210 [TLV] current->next = 1CCF2B0 [TLV] Freeing TLV Info String. [TLV] Freeing TLV. [TLV] Freeing TLV List Node. [TLV] current = 1CCF2B0 [TLV] current->next = 1CCF190 [TLV] Freeing TLV Info String. [TLV] Freeing TLV. [TLV] Freeing TLV List Node. [TLV] current = 1CCF190 [TLV] current->next = 1CCF110 [TLV] Freeing TLV Info String. [TLV] Freeing TLV. [TLV] Freeing TLV List Node. [TLV] current = 1CCF110 [TLV] current->next = 1CCF130 [TLV] Freeing TLV Info String. [TLV] Freeing TLV. [TLV] Freeing TLV List Node. [TLV] current = 1CCF130 [TLV] current->next = 1CCF090 [TLV] Freeing TLV Info String. [TLV] Freeing TLV. [TLV] Freeing TLV List Node. [TLV] current = 1CCF090 [TLV] current->next = 1CCF370 [TLV] Freeing TLV Info String. [TLV] Freeing TLV. [TLV] Freeing TLV List Node. [TLV] current = 1CCF370 [TLV] current->next = 1CCF400 [TLV] Freeing TLV Info String. [TLV] Freeing TLV. [TLV] Freeing TLV List Node. [TLV] current = 1CCF400 [TLV] current->next = 1CCF4C0 [TLV] Freeing TLV Info String. [TLV] Freeing TLV. [TLV] Freeing TLV List Node. [TLV] current = 1CCF4C0 [TLV] current->next = 1CCF520 [TLV] Freeing TLV Info String. [TLV] Freeing TLV. [TLV] Freeing TLV List Node. [TLV] current = 1CCF520 [TLV] current->next = 1CCF580 [TLV] Freeing TLV Info String. [TLV] Freeing TLV. [TLV] Freeing TLV List Node. [TLV] current = 1CCF580 [TLV] current->next = 1CCF5E0 [TLV] Freeing TLV Info String. [TLV] Freeing TLV. [TLV] Freeing TLV List Node. [TLV] current = 1CCF5E0 [TLV] current->next = 1CCF640 [TLV] Freeing TLV Info String. [TLV] Freeing TLV. [TLV] Freeing TLV List Node. [TLV] current = 1CCF640 [TLV] current->next = 1CCF6A0 [TLV] Freeing TLV Info String. [TLV] Freeing TLV. [TLV] Freeing TLV List Node. [TLV] current = 1CCF6A0 [TLV] current->next = 1CCF700 [TLV] Freeing TLV Info String. [TLV] Freeing TLV. [TLV] Freeing TLV List Node. [TLV] current = 1CCF700 [TLV] current->next = 1CCF740 [TLV] Freeing TLV Info String. [TLV] Freeing TLV. [TLV] Freeing TLV List Node. [TLV] current = 1CCF740 [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] (br0 with MSAP: 00 1f 46 d2 fc 00 00 1f 46 d2 fc 04 ) rxInfoTTL: 91 [STATE] [TIMER] (br0) tooManyNeighborsTimer: 0 > That error is definitely causing you a problem, and would have prevented > lldpneighbors from working, but there was also a socket read bug in > lldpneighbors that was causing it to misbehave as well... I've committed a > fix for that. Your fix seems to be sufficient to get neighbors : Interface 'br0' has 1 LLDP Neighbors: Neighbor 1: Chassis ID: MAC Address - 00 1f 46 d2 fc 00 Port ID: MAC Address - 00 1f 46 d2 fc 04 Time To Live: 120 seconds Port Description: Port 4 System Name: switch1 System Description: Ethernet Routing Switch 5510-24T HW:33 FW:5.0.0.4 SW:v5.1.0.014 System Capabiltiies: Bridge/Switch (enabled) Router (enabled) Management Address: IPv4 - 172.20.3.2 (Unknown - 0) (OID: Proprietary MIB) Organizationally Specific: 00 80 c2 01 00 Organizationally Specific: 00 80 c2 02 06 00 Organizationally Specific: 00 80 c2 03 00 01 07 56 4c 41 4e 20 23 Organizationally Specific: 00 80 c2 04 08 00 26 42 42 03 00 00 Organizationally Specific: 00 80 c2 04 03 88 8e Organizationally Specific: 00 80 c2 04 02 88 Organizationally Specific: 00 12 0f 01 03 6c 21 00 Organizationally Specific: 00 12 0f 03 00 00 00 00 End Of LLDPDU: I will try to submit you a patch to make lldpd a daemon. |
|
From: Terry S. <ter...@gm...> - 2008-07-04 06:32:37
|
Hi Vincent, Thanks for the comments. Yes, we're still maintaining OpenLLDP as time permits. We did have someone contribute bits to get debian packages going, but I haven't had time to figure out how to integrate them (I'm not a debian user myself, so some research is needed for me to understand the pieces). We'd be glad to take any patches, and if you'd like me to send you the pieces I have I'd be happy to do that. We're actually going to change the license over to GPLv2/BSD, so I'll get the license files updated to reflect the actual version. Thanks for the patch. I'll get it committed. The command line options do need some work. The ultimate goal is to have it be a daemon, but we've spent most of our time attempting to get basic functionality working and as such haven't had time to clean up everything yet, but I'll take your suggestions. Thanks. :) It seems as though we have a few bugs regarding processing of certain frames. Can you run lldpd with the "-d A" flags and send me the output of your Nortel frame? That will help me reproduce the "can't allocate memory" error. That error is definitely causing you a problem, and would have prevented lldpneighbors from working, but there was also a socket read bug in lldpneighbors that was causing it to misbehave as well... I've committed a fix for that. I'm hoping that I can get a release pushed out this weekend (we had a long weekend here in the US). Thanks again for the feedback and let me know what I can do to help you with the debian pieces. - Terry On Thu, Jun 26, 2008 at 10:47 AM, Vincent Bernat <be...@lu...> wrote: > Hi! > > I have just discovered OpenLLDP. I have however a few questions about > its current state. > > I would like to package it for Debian but no release have been done > since more than one year. Therefore, I have started packaging CVS which > has little activity. Will OpenLLDP still be maintained in the future? > > The license is a bit unclear. You should ship a copy of the GPL (as > required by the GPL, even if, as authors, you are not tied to the > license). Maybe you should precise which GPL version you license the > software (GPLv2 or later maybe). Moreover, you don't say what is the > proprietary license. If the license is determined with the client, you > can just license the whole as GPL: as authors, you can relicense your > software as you want, when you want. > > I see that the socket is created in /tmp. I have attached a patch to > create it in /var/run instead to avoid any symlink attack. > > > The manual page does not seem to list the correct options. "-o" is > missing, "-c" should be "-l". Moreover, some options are not > implemented, like "-f" and "-s" (which means that lldpd cannot be > daemonized). The getopt string is wrong: > char *theOpts = "i:d:f:s:h:l:o"; > It should be: > char *theOpts = "i:d:fshl:o"; > > At least, I was unable to make lldpneighbour work. I get just a few > blank lines with a w at the start of one of them. Maybe this is related > to the fact that I periodically get this: > > Running RX state machine for lan > Copying TLV1 for MSAP Processing... > Copying TLV2 for MSAP Processing... > [ERROR] Couldn't allocate memory!! > > However, lldpd seems to work as a simple agent (I use it with Nortel > Baystack 5510). > > Thanks. > -- > No fortunes found > > ------------------------------------------------------------------------- > 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: Vincent B. <be...@lu...> - 2008-06-26 16:51:50
|
The manual page does not seem to list the correct options. "-o" is
missing, "-c" should be "-l". Moreover, some options are not
implemented, like "-f" and "-s" (which means that lldpd cannot be
daemonized). The getopt string is wrong:
char *theOpts = "i:d:f:s:h:l:o";
It should be:
char *theOpts = "i:d:fshl:o";
At least, I was unable to make lldpneighbour work. I get just a few
blank lines with a w at the start of one of them. Maybe this is related
to the fact that I periodically get this:
Running RX state machine for lan
Copying TLV1 for MSAP Processing...
Copying TLV2 for MSAP Processing...
[ERROR] Couldn't allocate memory!!
However, lldpd seems to work as a simple agent (I use it with Nortel
Baystack 5510).
Thanks.
--
No fortunes found
|
