Re: [Openlldp-users] Question about the bpf framer

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

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
>>>     >
>>>     >
>>
> 