Menu
▾
▴
Re: [Openlldp-users] Question about the bpf framer
|
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 > > > > > > |
