Ethernet Layer communications

[Brett Swimley]

Is it true that this tap interface only allows inspection of incoming
packets, but does not allow generation of outgoing packets?

I did a little nosing around in the networking code.  bpf.h is present, but
bpf.c is not.  I'm assuming that this file would need to be ported from
FreeBSD to allow generation of and operation on the device nodes.
 Additionally bpf support would need to be added to the ethernet drivers, as
Daron supposed.

I'm torn between diving into this and making it happen, or just rewriting my
peripheral to generate UDP packets for communication on this interface.
 Does anyone see a need for this in the future?

Thanks,

Brett

On Thu, Apr 14, 2011 at 3:35 PM, Eric Norum <wenorum at lbl.gov> wrote:

> The documentation for this is in the networking suplement:
>
> 3.4.2 Tapping Into an Interface
> RTEMS add two new ioctls to the BSD networking code: SIOCSIFTAP and
> SIOCGIFTAP. These may be used to set and get a tap function. The tap
> function will be called for every Ethernet packet received by the interface.
> These are called like other interface ioctls, such as SIOCSIFADDR. When
> setting the tap function with SIOCSIFTAP, set the ifr tap field of the ifreq
> struct to the tap function. When retrieving the tap function with
> SIOCGIFTAP, the current tap function will be returned in the ifr tap field.
> To stop tapping packets, call SIOCSIFTAP with a ifr tap field of 0.
> The tap function is called like this:
> int tap (struct ifnet *, struct ether_header *, struct mbuf *)
> The tap function should return 1 if the packet was fully handled, in which
> case the caller will simply discard the mbuf. The tap function should return
> 0 if the packet should be passed up to the higher networking layers.
> The tap function is called with the network semaphore locked. It must not
> make any calls on the application levels of the networking level itself. It
> is safe to call other non-networking RTEMS functions.
>
>
> On Apr 14, 2011, at 2:21 PM, Daron Chabot wrote:
>
>
>
> On Thu, Apr 14, 2011 at 5:16 PM, Brett Swimley <
> brett.swimley at aedbozeman.com> wrote:
>
>> Thanks Daron,
>>
>> I had found this reference, and it appears that libpcap uses this API, so
>> I will continue looking. I'm hoping that the RTEMS stack does support bpf.
>>
>
> I had a brief grep through the source tree and noted that there were only 3
> NIC drivers that had the bpf_mtap( ) interface (all ported from FreeBSD!):
>
> dchabot at dev32new--> git grep -n bpf c/src/libchip/network
> c/src/libchip/network/i82586.c:1280:  if (sc->arpcom.ac_if.if_bpf != 0)
> c/src/libchip/network/i82586.c:1282:    bpf_mtap(sc->arpcom.ac_if.if_bpf,
> m);
> c/src/libchip/network/i82586.c:1378:    if (ifp->if_bpf)
> c/src/libchip/network/i82586.c:1379:      bpf_mtap(ifp->if_bpf, m0);
> c/src/libchip/network/if_dc.c:159:#include <net/bpf.h>
> c/src/libchip/network/if_dc.c:3372:             if (ifp->if_bpf)
> c/src/libchip/network/if_dc.c:3373:                     bpf_mtap(ifp,
> m_head);
> c/src/libchip/network/if_fxp.c:87:#include <net/bpf.h>
> c/src/libchip/network/if_fxp.c:1262:             * Pass packet to bpf if
> there i
> c/src/libchip/network/if_fxp.c:1264:            if (ifp->if_bpf)
> c/src/libchip/network/if_fxp.c:1265:                    bpf_mtap(ifp,
> mb_head);
>
> But, on further inspection, the bpf_mtaps( ) were "#if 0"'d out of
> commission.
>
> Then there's the issue of creating /dev/bpfX device nodes...
>
> I would be surprised if someone out there doesn't have something already,
> perhaps created to support message passing between nodes of a distributed,
> multi-processing system?
>
> I'm looking at you Till... ;-)
>
>
> -- dc
>
>
>>
>> Brett
>>
>>
>> On Thu, Apr 14, 2011 at 2:30 PM, Daron Chabot <daron.chabot at gmail.com>wrote:
>>
>>> Hi Brett,
>>>
>>> I have not looked into this in much detail, but since RTEMS' network
>>> stack is ported from FreeBSD, you may be able to use the Berkley Packet
>>> Filter (bpf) API for this.
>>>
>>>
>>>
>>> -- dc
>>>
>>>
>>>
>>>
>>
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-users
>
>
> --
> Eric Norum
> wenorum at lbl.gov
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20110415/d16b68c7/attachment-0001.html>