Re: [Discuss-gnuradio] updated packet format on USRP inband signaling

[Greg Troxel]

Eric Blossom <address@hidden> writes:

> On Tue, Feb 27, 2007 at 07:49:02AM -0500, Greg Troxel wrote:
>>   I'm thinking layer 2 with a unique Ethernet packet type (probably use
>>   some abandoned packet type).  That said, there's nothing stopping us
>>   from doing UDP, except the additional bandwidth.  I don't see any need
>>   to do TCP.
>> 
>> I think that it should be possible for an unprivileged user (on most
>> Free systems) to interact with a USRP over GigE.  Actually this raises
>> the issue of authorization and confidentiality/integrity of the data,
>> probably taken care of by a dedicated ethernet port.
>
> Under GNU/Linux they may need to be holding CAP_NET_RAW, since I
> think the way to get the raw ethernet frames is with libpcap and/or
> opening a raw socket using socket(PF_PACKET, SOCK_RAW, ...)
>
> Any idea how we would get this done under *BSD?

Two ways:

  use bpf.  This requires r/w access to /dev/bpf, but that also
  enables reading and writing other traffic.  Presumably CAP_NET_RAW
  on Linux does too, and that's overly broad.

  write a protocol family driver for the USRP ethertype (hard)

To me, this all argues for IP/UDP (at the cost of 28 bytes) being the
standard approach, with raw being an optimization if needed.  It
handles the privilege issues, and gives you multiplexing hooks (which
we may not usually need).

> I'm hoping on suitable machines to be able to run near wire-speed, so
> that also argues for a dedicated ethernet port.

Sure, but speed should be an orthogonal design issue from security and
multiplexing.

> Also, absent some driver hacking to mux and demux commands and
> responses, we may need a user space process to handle that stuff.  In
> that case, only that processes would need access to the magic socket,
> and the rest of the user code would use some kind of IPC to talk to
> that one.

OK, but that's likely to be somewhat slower.   But I don't understand
the mux/demux need, beyond connecting a USRP to a user process.  Do
you envision two programs each accessing some part of the resources on
a single GigE connected USRPng?

> Pause frames provide flow control.  According to folks at Vanu
> (who use Gigabit ethernet to implement their basestations), that's
> been sufficient, assuming any switches along the way aren't brain
> damaged. 

Locally, sure one can enforce that by declaring them broken and
replacing them.

> If somebody wanted to ship samples a long way reliably, then some
> higher-level protocol is probably in order.

It may make sense to define a TCP or SCTP method, but then again it
may not - this is perhipheral attachment.

pgpEPlHacVmdB.pgp
Description: PGP signature