User-space controlled raw ethernet - Is this the way to go? - Linux

This is a discussion on User-space controlled raw ethernet - Is this the way to go? - Linux ; Hi All, I've got a FPGA development board directly connected to a PC via an ethernet connection. This provides a fairly high speed connection between the two. I want to be able to send raw ethernet frames between the two. ...

+ Reply to Thread
Results 1 to 15 of 15

Thread: User-space controlled raw ethernet - Is this the way to go?

  1. User-space controlled raw ethernet - Is this the way to go?

    Hi All,

    I've got a FPGA development board directly connected to a PC via an
    ethernet connection. This provides a fairly high speed connection
    between the two.

    I want to be able to send raw ethernet frames between the two. I've
    looked at libpcap, libdnet and direct socket code. For each of these
    I've got something working, BUT, they all seem to need root permissions
    to do low level ethernet frame sending and receiving.

    Could you comment on the sanity of the following approach to allow
    user-space controlled ethernet transmission/reception:

    My plan is to create a very simple kernel module that probably uses
    direct socket code to perform ethernet frame transmission and reception.
    I plan to use ioctl calls to give the user-space access to these operations.

    Is there is an easier way? Perhaps to use libpcap directly as non-root.

    Many thanks
    Andy

  2. Re: User-space controlled raw ethernet - Is this the way to go?

    On Feb 25, 2:23 am, Andrew Greensted wrote:
    > Hi All,
    >
    > I've got a FPGA development board directly connected to a PC via an
    > ethernet connection. This provides a fairly high speed connection
    > between the two.
    >
    > I want to be able to send raw ethernet frames between the two. I've
    > looked at libpcap, libdnet and direct socket code. For each of these
    > I've got something working, BUT, they all seem to need root permissions
    > to do low level ethernet frame sending and receiving.
    >
    > Could you comment on the sanity of the following approach to allow
    > user-space controlled ethernet transmission/reception:
    >
    > My plan is to create a very simple kernel module that probably uses
    > direct socket code to perform ethernet frame transmission and reception.
    > I plan to use ioctl calls to give the user-space access to these operations.
    >
    > Is there is an easier way? Perhaps to use libpcap directly as non-root.


    Implement minimal ARP and UDP.

    DS

  3. Re: User-space controlled raw ethernet - Is this the way to go?

    David Schwartz wrote:
    > On Feb 25, 2:23 am, Andrew Greensted wrote:
    >> Hi All,
    >>
    >> I've got a FPGA development board directly connected to a PC via an
    >> ethernet connection. This provides a fairly high speed connection
    >> between the two.
    >>
    >> I want to be able to send raw ethernet frames between the two. I've
    >> looked at libpcap, libdnet and direct socket code. For each of these
    >> I've got something working, BUT, they all seem to need root permissions
    >> to do low level ethernet frame sending and receiving.
    >>
    >> Could you comment on the sanity of the following approach to allow
    >> user-space controlled ethernet transmission/reception:
    >>
    >> My plan is to create a very simple kernel module that probably uses
    >> direct socket code to perform ethernet frame transmission and reception.
    >> I plan to use ioctl calls to give the user-space access to these operations.
    >>
    >> Is there is an easier way? Perhaps to use libpcap directly as non-root.

    >
    > Implement minimal ARP and UDP.
    >
    > DS


    Hi David,

    Actually this was my first approach. But I really wasn't that happy with
    the overhead of the IP and UDP headers.

    Thanks
    Andy

  4. Re: User-space controlled raw ethernet - Is this the way to go?

    Andrew Greensted schrieb:
    >
    > Is there is an easier way? Perhaps to use libpcap directly as non-root.
    >

    Essentially, libpcap does not neet root priviledge, but CAP_NET_RAW and
    maybe CAP_NET_ADMIN capabilities.

    man 7 capablities
    man 2 capset

    So a program may start as root, change inheritable capabilities and
    seteuid() to non-root, then execve() the libpcap application.

    Kind regards

    Jan

  5. Re: User-space controlled raw ethernet - Is this the way to go?

    On Feb 25, 2:54 am, Andrew Greensted wrote:

    > Hi David,
    >
    > Actually this was my first approach. But I really wasn't that happy with
    > the overhead of the IP and UDP headers.


    Then you will need to provide a driver to figure out what goes where.
    Otherwise, there is simply no way for the kernel to arbitrate who gets
    the data.

    DS

  6. Re: User-space controlled raw ethernet - Is this the way to go?

    On Mon, 25 Feb 2008 04:24:57 -0800 (PST) David Schwartz wrote:
    | On Feb 25, 2:54 am, Andrew Greensted wrote:
    |
    |> Hi David,
    |>
    |> Actually this was my first approach. But I really wasn't that happy with
    |> the overhead of the IP and UDP headers.
    |
    | Then you will need to provide a driver to figure out what goes where.
    | Otherwise, there is simply no way for the kernel to arbitrate who gets
    | the data.

    I've said this years ago. It applies here, too. All network interfaces
    should have been device nodes. Then you could let a process open one of
    them in the normal I/O way (as long as it is not busy from being an active
    network interface). An ethernet port is really not much more than a fancy
    serial port. Then the answer to the OPs question (if even asked) would be
    something like: give permission for the user in question via permission on
    the device node file, and let it open it as needed.

    --
    |---------------------------------------/----------------------------------|
    | Phil Howard KA9WGN (ka9wgn.ham.org) / Do not send to the address below |
    | first name lower case at ipal.net / spamtrap-2008-02-25-0816@ipal.net |
    |------------------------------------/-------------------------------------|

  7. Re: User-space controlled raw ethernet - Is this the way to go?

    phil-news-nospam@ipal.net schrieb:
    >
    > I've said this years ago. It applies here, too. All network interfaces
    > should have been device nodes. Then you could let a process open one of
    > them in the normal I/O way (as long as it is not busy from being an active
    > network interface). An ethernet port is really not much more than a fancy
    > serial port.
    >

    With Linux, such a function is both easy to implement and relatively
    useless. From kernel's point of view, the actual port could be exposed at
    most the way you'll described: if the Linux kernel does not "claim" the
    interface, a userspace program may do.

    The network code is one of the biggest in-kernel applications Linux have.
    All the address handling, filtering, routing is done within this kernel
    application -- mostly for speed reasons, Linux' networking is really fast
    because of it.

    In a microkernel, one certainly *would* go the way you described, exposing
    the raw interface to the userspace and let a demon do all the work, but
    within Linux, passing all the ethernet data to a device node is just a
    function without too many use cases.

    Kind regards

    Jan



  8. Re: User-space controlled raw ethernet - Is this the way to go?

    Andrew Greensted wrote:

    > I want to be able to send raw ethernet frames between the two. I've
    > looked at libpcap, libdnet and direct socket code. For each of these
    > I've got something working, BUT, they all seem to need root permissions
    > to do low level ethernet frame sending and receiving.


    There's a reason for this. Low level ethernet frame processing lets you
    spoof to your heart's content...so by default only root is allowed to do it.

    If you can get the root privileges to install a kernel module, can't you
    make the executable setuid root?

    Chris

  9. Re: User-space controlled raw ethernet - Is this the way to go?

    Bernhard Agthe writes:
    >>>> My plan is to create a very simple kernel module that probably uses
    >>>> direct socket code to perform ethernet frame transmission and reception.

    >
    > There's something like that, the TUN/TAP interface which provides access
    > to the raw sockets. This is used e.g. by the former ethereal or by
    > various IPsec/VPN solutions.


    TUN/TAP is a virtual network interface, which can be used to forward
    ethernet frames or IP datagrams addressed to certain destinations to
    some 'ordinary' process, which can also inject 'somehow constructed'
    replies/ packing coming from such a destination by writing them to the
    chardev associated with a particual TUN (IP) or TAP (ethernet) device.

    'raw sockets' are something completely different.

  10. Re: User-space controlled raw ethernet - Is this the way to go?

    Hi,

    >>> My plan is to create a very simple kernel module that probably uses
    >>> direct socket code to perform ethernet frame transmission and reception.


    There's something like that, the TUN/TAP interface which provides access
    to the raw sockets. This is used e.g. by the former ethereal or by
    various IPsec/VPN solutions. Don't know about the most recent
    development, though.

    >> Implement minimal ARP and UDP.


    > Actually this was my first approach. But I really wasn't that happy with
    > the overhead of the IP and UDP headers.


    Have you ever had a look at TCP/UDP/IP header compression? You might
    have to look at IPv6 for this... They've been invented for directly
    linked devices and you've got the benefit of a standardized solution.

    As far as I understand, you're trying to squeeze as much bandwidth as
    possible out of the connection? Well, I'm not sure, if the additional
    processing power you need for your implementation doesn't "cost" more
    than using the existing implementation - as stated elsewhere in this
    thread, Linux Networking is fast. In most cases the system periphery
    will limit you more. Take a look at cluster computing also, they do face
    the same problem and did solve it already.

    Bye....


  11. Re: User-space controlled raw ethernet - Is this the way to go?

    Jan Kandziora wrote:
    > Essentially, libpcap does not neet root priviledge, but CAP_NET_RAW and
    > maybe CAP_NET_ADMIN capabilities.


    Yes, I remember looking into this when I was considering the libpcap
    route. But to be honest, I got totally lost, and could find little
    examples/further explanation that helped. My conclusion (that might be
    totally wrong) was that most of the capabilities stuff is deprecated (or
    haeding that way).

    Chris Friesen wrote:
    > If you can get the root privileges to install a kernel module, can't you
    > make the executable setuid root?


    Perhaps If I added a bit more detail. That main application that will be
    sending/receiving data (on the PC side) will be Java based. My plan
    was to use a bit of JNI to link the Java to the low-level socket code
    (whether it's a kernel module or libpcap based). I don't want the Java
    app running as root. I'm not too sure how to have the ethernet access
    running with root permissions, but the Java app running as a regular user.

    With regards to the kernel module. Things _were_ going well. But with
    further reading, it seems creating and using a socket from within a
    kernel module isn't good practice, or even allowed. (Again, I may be
    totally wrong here). When I try to compile a module using the socket
    function I get:

    warning: implicit declaration of function 'socket'

    I'm certain I have the right headers included. The same set worked when
    used with a non-kernel module test program.

    Andy

  12. Re: User-space controlled raw ethernet - Is this the way to go?

    Andy writes:
    > Jan Kandziora wrote:
    >> Essentially, libpcap does not neet root priviledge, but CAP_NET_RAW and
    >> maybe CAP_NET_ADMIN capabilities.

    >
    > Yes, I remember looking into this when I was considering the libpcap
    > route. But to be honest, I got totally lost, and could find little
    > examples/further explanation that helped. My conclusion (that might be
    > totally wrong) was that most of the capabilities stuff is deprecated
    > (or haeding that way).


    That's quite an absurd assumption. If your application should operate
    on its own, it would need the CAP_NET_RAW-capability to open a
    PF_PACKET socket, which can be used to send and receive 'link-layer
    SDUs'. Another options would be to let a suitably priviledged helper
    application create the socket and pass it to the main application,
    either by passing a descriptor over an PF_UNIX socket or implicitly by
    inheritance.


    [...]

    > With regards to the kernel module. Things _were_ going well. But with
    > further reading, it seems creating and using a socket from within a
    > kernel module isn't good practice, or even allowed. (Again, I may be
    > totally wrong here). When I try to compile a module using the socket
    > function I get:
    >
    > warning: implicit declaration of function 'socket'


    'socket' is the C-library name for an interface providing one of the
    functions (AFAIK) implemented by the 'socketcall' system call. You
    cannot use system calls from within the kernel. Interfacing with the
    stack from inside the kernel requires using a different interface (I
    unfortunately have no exact knowledge of).

  13. Re: User-space controlled raw ethernet - Is this the way to go?

    >> Yes, I remember looking into this when I was considering the libpcap
    >> route. But to be honest, I got totally lost, and could find little
    >> examples/further explanation that helped. My conclusion (that might be
    >> totally wrong) was that most of the capabilities stuff is deprecated
    >> (or haeding that way).

    >
    > That's quite an absurd assumption.


    I guess I worded that wrong. What I meant was from what I read at the
    time, various things suggested that the capabilities framework was on
    it's way out. I'm happy to be told/proved wrong. I'm certainly no expert
    in this area.

    If you could suggest some good sources of info with regards to
    capabilities and libpcap, that would be a great help.

    Andy

  14. Re: User-space controlled raw ethernet - Is this the way to go?

    On Feb 25, 8:43 am, Bernhard Agthe wrote:

    > There's something like that, the TUN/TAP interface which provides access
    > to the raw sockets. This is used e.g. by the former ethereal or by
    > various IPsec/VPN solutions. Don't know about the most recent
    > development, though.


    Depending on the OP's exact requirements, a server (that would have to
    run as root or have access to TUN/TAP) that normal programs could
    connect to and use as a proxy to access his device might work. That
    would save him having to write/install a kernel driver.

    DS

  15. Re: User-space controlled raw ethernet - Is this the way to go?

    On Mon, 25 Feb 2008 15:39:29 +0100 Jan Kandziora wrote:
    | phil-news-nospam@ipal.net schrieb:
    |>
    |> I've said this years ago. It applies here, too. All network interfaces
    |> should have been device nodes. Then you could let a process open one of
    |> them in the normal I/O way (as long as it is not busy from being an active
    |> network interface). An ethernet port is really not much more than a fancy
    |> serial port.
    |>
    | With Linux, such a function is both easy to implement and relatively
    | useless. From kernel's point of view, the actual port could be exposed at
    | most the way you'll described: if the Linux kernel does not "claim" the
    | interface, a userspace program may do.

    But where do you store the permissions and ownership (e.g. a user that
    is allowed certain access)? With a device nice file, there it is. But
    without one, then where?


    | The network code is one of the biggest in-kernel applications Linux have.
    | All the address handling, filtering, routing is done within this kernel
    | application -- mostly for speed reasons, Linux' networking is really fast
    | because of it.

    And a device node would not change that. It would merely be a way to
    access the device as a file. Networking code could still all work the
    same. It would be optional for ifconfig to reference the interface to
    configure by means of opening the device node and passing the descriptor
    (how I would have suggested designing it from the beginning). But it
    can just do it the way it does now, anyway.


    | In a microkernel, one certainly *would* go the way you described, exposing
    | the raw interface to the userspace and let a demon do all the work, but
    | within Linux, passing all the ethernet data to a device node is just a
    | function without too many use cases.

    Yes, it would be rare to use an ethernet port other than as a network
    interface. But I still think that it would not have been hard to do it
    right from the beginning, if the designers had intended to keep things
    consistent in the whole principle of having all devices be files.
    --
    |---------------------------------------/----------------------------------|
    | Phil Howard KA9WGN (ka9wgn.ham.org) / Do not send to the address below |
    | first name lower case at ipal.net / spamtrap-2008-02-25-2203@ipal.net |
    |------------------------------------/-------------------------------------|

+ Reply to Thread