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

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

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