protocol handler for a proprietary protocol - Linux

This is a discussion on protocol handler for a proprietary protocol - Linux ; Hi, I am writing a protocol handler for a proprietary protocol wherein the user application forms the raw ethernet frames encapsulating packets of this protocol. I have also written the PCI network driver for the proprietary device which communicates using ...

+ Reply to Thread
Results 1 to 10 of 10

Thread: protocol handler for a proprietary protocol

  1. protocol handler for a proprietary protocol

    Hi,

    I am writing a protocol handler for a proprietary protocol wherein the
    user application forms the raw ethernet frames encapsulating packets of
    this protocol. I have also written the PCI network driver for the
    proprietary device which communicates using this protocol. For most
    part the PCI driver is done. I want to keep the Ethernet driver and
    protocol handler separate so that things still work, if in future, one
    chooses to use some other Ethernet driver.

    Now I have to write a protocol handler, just above this Ethernet
    driver, for a particular packet_type. Now what would be the way for the
    protocol handler to interact with the user application to
    transmit/receive Ethernet frames. I don't want the user application to
    require root access (as in case of PF_PACKET sockets). I am thinking of
    implementing Rx/Tx using ioctl calls. I could not find how to insert my
    own ioctl handler at the protocol handler level. Also I am not able to
    find much documentation for this non-socket kind of ioctl handler in
    protocol handlers. Whether Rx/Tx thru' ioctl sounds good or there is
    some better way for interacting with user app? Can someone please point
    me in the right direction?

    Cheers,
    Aman.


  2. Re: protocol handler for a proprietary protocol

    aman79@gmail.com wrote:
    > Hi,
    >
    > I am writing a protocol handler for a proprietary protocol wherein the
    > user application forms the raw ethernet frames encapsulating packets of
    > this protocol. I have also written the PCI network driver for the
    > proprietary device which communicates using this protocol. For most
    > part the PCI driver is done. I want to keep the Ethernet driver and
    > protocol handler separate so that things still work, if in future, one
    > chooses to use some other Ethernet driver.
    >
    > Now I have to write a protocol handler, just above this Ethernet
    > driver, for a particular packet_type. Now what would be the way for the
    > protocol handler to interact with the user application to
    > transmit/receive Ethernet frames. I don't want the user application to
    > require root access (as in case of PF_PACKET sockets). I am thinking of
    > implementing Rx/Tx using ioctl calls. I could not find how to insert my
    > own ioctl handler at the protocol handler level. Also I am not able to
    > find much documentation for this non-socket kind of ioctl handler in
    > protocol handlers. Whether Rx/Tx thru' ioctl sounds good or there is
    > some better way for interacting with user app? Can someone please point
    > me in the right direction?


    It is a serious breach of network security to allow a process
    to handle raw Ethernet frames without superuser privileges.

    PF_PACKET *is* the correct way to interact with the raw frames,
    and any driver to sneak by the limitation is a very unwise idea.

    Could you think of making the protocol handler a suid root process?

    --

    Tauno Voipio
    tauno voipio (at) iki fi

  3. Re: protocol handler for a proprietary protocol

    aman79@gmail.com wrote:
    > I want to keep the Ethernet driver and
    > protocol handler separate so that things still work, if in future, one
    > chooses to use some other Ethernet driver.
    >
    > Now what would be the way for the
    > protocol handler to interact with the user application to
    > transmit/receive Ethernet frames. I don't want the user application to
    > require root access (as in case of PF_PACKET sockets).


    Have you considered using the tun/tap support? What about netfilter?

    Chris

  4. Re: protocol handler for a proprietary protocol

    Chris Friesen wrote:
    > aman79@gmail.com wrote:
    >
    >> I want to keep the Ethernet driver and
    >> protocol handler separate so that things still work, if in future, one
    >> chooses to use some other Ethernet driver.
    >>
    >> Now what would be the way for the
    >> protocol handler to interact with the user application to
    >> transmit/receive Ethernet frames. I don't want the user application to
    >> require root access (as in case of PF_PACKET sockets).

    >
    >
    > Have you considered using the tun/tap support? What about netfilter?
    >
    > Chris


    Chris:

    The tun/tap driver is in reverse to what the OP wants to do.
    The tun/tap creates a pseudo-interface to connect to the network
    stack toward the internals of the host, but the OP wants to
    connect to the link level interface (Ethernet). The packet
    socket is the correct method here.

    For the root access requirement, see my other answer.

    The OP's question was about data link layer access, but the
    customary netfilter (except the special ebtables) operates
    one floor higher in the network stack, at the network (IP)
    layer - not applicable here.

    --

    Tauno Voipio
    tauno voipio (at) iki fi

  5. Re: protocol handler for a proprietary protocol

    Tauno Voipio wrote:

    > The tun/tap driver is in reverse to what the OP wants to do.
    > The tun/tap creates a pseudo-interface to connect to the network
    > stack toward the internals of the host, but the OP wants to
    > connect to the link level interface (Ethernet). The packet
    > socket is the correct method here.


    If you set up ethernet bridging you can forward the packets injected via
    tun/tap out a real ethernet device.

    > The OP's question was about data link layer access, but the
    > customary netfilter (except the special ebtables) operates
    > one floor higher in the network stack, at the network (IP)
    > layer - not applicable here.



    Hmm...true.

    Chris

  6. Re: protocol handler for a proprietary protocol

    Hi Tauno/Chris,

    Thanks for your replies.

    The protocol handler would ensure that only ethernet frames containing
    ethertype = this new protocol (say ETH_P_NP), would be passed to the
    user application. In the setup that I have, there isn't really much
    harm that the malicious user can do using this application and this
    protocol. Protocol handler would anyway ensure that the user
    application can Rx/Tx only packets belonging to ETH_P_NP.

    Ok another question, if I were to provide socket interface to the user
    application, how should I be proceeding ? To me socket seem to be
    unnecessary overhead, but I may be wrong. Please correct me, if that's
    the case.

    Cheers,
    Aman.

    PS: what's OP ?


    Tauno Voipio wrote:
    > aman79@gmail.com wrote:
    > > Hi,
    > >
    > > I am writing a protocol handler for a proprietary protocol wherein the
    > > user application forms the raw ethernet frames encapsulating packets of
    > > this protocol. I have also written the PCI network driver for the
    > > proprietary device which communicates using this protocol. For most
    > > part the PCI driver is done. I want to keep the Ethernet driver and
    > > protocol handler separate so that things still work, if in future, one
    > > chooses to use some other Ethernet driver.
    > >
    > > Now I have to write a protocol handler, just above this Ethernet
    > > driver, for a particular packet_type. Now what would be the way for the
    > > protocol handler to interact with the user application to
    > > transmit/receive Ethernet frames. I don't want the user application to
    > > require root access (as in case of PF_PACKET sockets). I am thinking of
    > > implementing Rx/Tx using ioctl calls. I could not find how to insert my
    > > own ioctl handler at the protocol handler level. Also I am not able to
    > > find much documentation for this non-socket kind of ioctl handler in
    > > protocol handlers. Whether Rx/Tx thru' ioctl sounds good or there is
    > > some better way for interacting with user app? Can someone please point
    > > me in the right direction?

    >
    > It is a serious breach of network security to allow a process
    > to handle raw Ethernet frames without superuser privileges.
    >
    > PF_PACKET *is* the correct way to interact with the raw frames,
    > and any driver to sneak by the limitation is a very unwise idea.
    >
    > Could you think of making the protocol handler a suid root process?
    >
    > --
    >
    > Tauno Voipio
    > tauno voipio (at) iki fi



  7. Re: protocol handler for a proprietary protocol

    Aman wrote:
    > Hi Tauno/Chris,
    >
    > Thanks for your replies.
    >
    > The protocol handler would ensure that only ethernet frames containing
    > ethertype = this new protocol (say ETH_P_NP), would be passed to the
    > user application. In the setup that I have, there isn't really much
    > harm that the malicious user can do using this application and this
    > protocol. Protocol handler would anyway ensure that the user
    > application can Rx/Tx only packets belonging to ETH_P_NP.


    This is just what the packet sockets do.

    > Ok another question, if I were to provide socket interface to the user
    > application, how should I be proceeding ? To me socket seem to be
    > unnecessary overhead, but I may be wrong. Please correct me, if that's
    > the case.


    This is more difficult, as you had to interface to the protocol stack
    at the socket layer. If the protocol is completely proprietary,
    the TCP/IP or Unix domain sockets probably won't do as such.

    Maybe you could create a daemon (with root privileges) which runs
    as root and communicates with the users using Unix domain sockets.
    This would solve the privilege problem, too.

    >
    > PS: what's OP ?


    Original Poster - the person initially starting a thread.

    --

    Tauno Voipio
    tauno voipio (at) iki fi

  8. Re: protocol handler for a proprietary protocol

    Chris Friesen wrote:
    > Tauno Voipio wrote:
    >
    >> The tun/tap driver is in reverse to what the OP wants to do.
    >> The tun/tap creates a pseudo-interface to connect to the network
    >> stack toward the internals of the host, but the OP wants to
    >> connect to the link level interface (Ethernet). The packet
    >> socket is the correct method here.

    >
    >
    > If you set up ethernet bridging you can forward the packets injected via
    > tun/tap out a real ethernet device.




    Sending network layer packets to another host is forwarding,
    sending data link layer packets directly to another interface is
    bridging.



    The bridging is set up so that there will be a new pseudo-interface,
    the bridge, named from br0 onward. The IP properties are set to the
    bridge interface, and the IP packets are handled like the packets
    to / from a real data link interface. The data-link frames are
    'forwarded' between the members of the bridge without ever visiting
    the IP layer. An important detail is that the bridge component
    interfaces shall not have IP addresses or routings of their own
    anymore. This applies to the bridged tap interface as well.

    The bridge interface is included into the normal routing tables
    of the IP layer as any other data link interface, and the packets
    can be forwarded to an interface not in the same bridge (and back,
    of course).

    --

    Tauno Voipio
    tauno voipio (at) iki fi

  9. Re: protocol handler for a proprietary protocol

    Hi,

    Thanks for the ideas. I would collect all these ideas and then finally
    choose one of them which fits my needs the best. Just clarify one
    thing, if I were to implement communication between protocol handler
    and user application thru' ioctl interface, how should I proceed ? Can
    this really be done at all ? The signature of the ioctl handler is:

    int (*do_ioctl) (struct net_device *dev, struct ifreq *ifr, int cmd)

    So in user application what would be the first parameter fd in ioctl
    system call and how would the kernel be able to invoke this ioctl
    handler and with what net_device structure ? I am a bit new to the
    linux kernel, so I would appreciate some clarity on this flow.

    Are there any other good books on Linux kernel networking internals
    other than the O'reilly book on this topic ?

    Thanks for your time.

    Cheers,
    Aman.


    Tauno Voipio wrote:
    > Aman wrote:
    > > Hi Tauno/Chris,
    > >
    > > Thanks for your replies.
    > >
    > > The protocol handler would ensure that only ethernet frames containing
    > > ethertype = this new protocol (say ETH_P_NP), would be passed to the
    > > user application. In the setup that I have, there isn't really much
    > > harm that the malicious user can do using this application and this
    > > protocol. Protocol handler would anyway ensure that the user
    > > application can Rx/Tx only packets belonging to ETH_P_NP.

    >
    > This is just what the packet sockets do.
    >
    > > Ok another question, if I were to provide socket interface to the user
    > > application, how should I be proceeding ? To me socket seem to be
    > > unnecessary overhead, but I may be wrong. Please correct me, if that's
    > > the case.

    >
    > This is more difficult, as you had to interface to the protocol stack
    > at the socket layer. If the protocol is completely proprietary,
    > the TCP/IP or Unix domain sockets probably won't do as such.
    >
    > Maybe you could create a daemon (with root privileges) which runs
    > as root and communicates with the users using Unix domain sockets.
    > This would solve the privilege problem, too.
    >
    > >
    > > PS: what's OP ?

    >
    > Original Poster - the person initially starting a thread.
    >
    > --
    >
    > Tauno Voipio
    > tauno voipio (at) iki fi



  10. Re: protocol handler for a proprietary protocol


    Aman wrote:
    > Hi,
    >
    > Thanks for the ideas. I would collect all these ideas and then finally
    > choose one of them which fits my needs the best. Just clarify one
    > thing, if I were to implement communication between protocol handler
    > and user application thru' ioctl interface, how should I proceed ? Can
    > this really be done at all ? The signature of the ioctl handler is:
    >
    > int (*do_ioctl) (struct net_device *dev, struct ifreq *ifr, int cmd)
    >
    > So in user application what would be the first parameter fd in ioctl
    > system call and how would the kernel be able to invoke this ioctl
    > handler and with what net_device structure ? I am a bit new to the
    > linux kernel, so I would appreciate some clarity on this flow.


    I have done it quite while ago. I do no remember very details. I
    believe the kernel
    figures if out from the interface name. In your user application, you
    first open socket by calling socke to get the file descriptor fd. And
    then when you call your ioctl(), you input the interface name (eth0?
    what ever the name your use) into parameter struct ifreq *ifr,
    ifr->ifr_name, then your iotcl() will be deliverd to the driver you
    specified. I do not remember what type socket I put when I open the
    socket.


+ Reply to Thread