discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Timothy Brown
Subject: Re: [Discuss-gnuradio] updated packet format on USRP inband signaling
Date: Wed, 28 Feb 2007 09:44:30 -0500

This is a somewhat unrelated question, but i'm just curious if multicast is part of the thought process here?



On Feb 28, 2007, at 2:06 AM, Eric Blossom wrote:

On Tue, Feb 27, 2007 at 11:28:26AM -0500, Greg Troxel wrote:

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)

OK.

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

OK.

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.

OK.

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?

Sure.  It's a common operation now.  We often run an fft in one
process and some kind of transmitter in another.  Somebody's got to
handle the dumuxing of command replies.  Using your UDP example, we'd
have the source port of the request to route the reply.  That still
leaves the flags such as Overrun, Underrun, etc., which I was thinking
were only going to get reported once, and then cleared.  (I didn't see
a good reason for forcing the host to explicitly clear the flag.)


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.

I'd hate to try to stuff either of those in an inexpensive FPGA.  Of
course if somebody wanted those, they could stick some kind of single
board computer next to the USRPng and have it run TCP or SCTP or
whatever.

Eric


_______________________________________________
Discuss-gnuradio mailing list
address@hidden
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio





reply via email to

[Prev in Thread] Current Thread [Next in Thread]