design question - new protocol handler

design question - new protocol handler

Post by T » Mon, 01 Jul 2002 15:15:17



Hi,

  I am involved in porting a broadband-bridge-router to Linux.  I
decided against using the linux bridging code since we already have
all the necessary data-structures & code etc... in place. Using Linux
briding code would mean sufficient re-write of our code ...we might do
it later on but definitely not for version 1.0.  So what I am planning
to do is to define our own LLC protocol type (ETH_P_OUROWN), define a
handler for it. The ethernet driver (also written by us) stamps the
incoming packets with ETH_P_OUROWN (after eth_type_trans() call) . The
handler takes care of diverting it to linux code (for ARP packets
etc..) or to our code for IP packets.

I have following questions in this regard:

[1] Is defining ETH_P_OUROWN OK ... I mean it fits well from a
coding-perspective..but I am not sure if there are any other issues
involved here ... I mean do we need to officially register it ?  Can
someone point me to helpful resources on web ?

[2] Is this the usual way of doing it...are there any better ways ?

Basically IP packets have to go to our code before they go to Linux IP
code...We are planning to use our code as a net-filter hook at
LOCAL_OUT...however for forwarding & packets destined for
localhost...we plan to define a protocol handler ...this handler takes
the incoming packets (local/forward) does XXXXX on them, uses IP
exposed functions to do some IP operations....and does local_deliver /
hard_start_xmit.

We could have very well used IP pre-routing hook...but as I said
before,,,the emphasis is on minimal code changes (to our code).

This is my first project on Linux networking so any, even seemingly
obvious hints/solutions will help.

[3] Are there any issues related to the amount of processing involved
in the protocol handler... I mean if the protocol handler (the func()
invoked from net_rx_action) is quite heavy (in processing) , are there
any problems ?...since I guess this same tasklet is responsible for
dequeing the packets from the per-CPU queue (in which the driver
deposits the packets)....are they any gotchas or design tricks
involved here?

P.S. we had thought of using ETH_P_ALL first...but since our handler
is a kind of protocol-mangler (packets may be even dropped...) so we
ruled out that option (since as per comments in dev_add_pack() ...
ETH_P_ALL was meant only for packet watchers and not packet manglers).

-Krishna

 
 
 

1. design question - new protocol handler

Hi,

  I am involved in porting a broadband-bridge-router to Linux.  I
decided against using the linux bridging code since we already have
all the necessary data-structures & code etc... in place. Using Linux
briding code would mean sufficient re-write of our code ...we might do
it later on but definitely not for version 1.0.  So what I am planning
to do is to define our own LLC protocol type (ETH_P_OUROWN), define a
handler for it. The ethernet driver (also written by us) stamps the
incoming packets with ETH_P_OUROWN (after eth_type_trans() call) . The
handler takes care of diverting it to linux code (for ARP packets
etc..) or to our code for IP packets.

I have following questions in this regard:

[1] Is defining ETH_P_OUROWN OK ... I mean it fits well from a
coding-perspective..but I am not sure if there are any other issues
involved here ... I mean do we need to officially register it ?  Can
someone point me to helpful resources on web ?

[2] Is this the usual way of doing it...are there any better ways ?

Basically IP packets have to go to our code before they go to Linux IP
code...We are planning to use our code as a net-filter hook at
LOCAL_OUT...however for forwarding & packets destined for
localhost...we plan to define a protocol handler ...this handler takes
the incoming packets (local/forward) does XXXXX on them, uses IP
exposed functions to do some IP operations....and does local_deliver /
hard_start_xmit.

We could have very well used IP pre-routing hook...but as I said
before,,,the emphasis is on minimal code changes (to our code).

This is my first project on Linux networking so any, even seemingly
obvious hints/solutions will help.

[3] Are there any issues related to the amount of processing involved
in the protocol handler... I mean if the protocol handler (the func()
invoked from net_rx_action) is quite heavy (in processing) , are there
any problems ?...since I guess this same tasklet is responsible for
dequeing the packets from the per-CPU queue (in which the driver
deposits the packets)....are they any gotchas or design tricks
involved here?

P.S. we had thought of using ETH_P_ALL first...but since our handler
is a kind of protocol-mangler (packets may be even dropped...) so we
ruled out that option (since as per comments in dev_add_pack() ...
ETH_P_ALL was meant only for packet watchers and not packet manglers).

-Krishna

2. redefining keyboard with xmodmap

3. exec in SIGALARM handler, no new SIGALARM handler??

4. Installing JAR as a daemon

5. Handlers, Handlers, Handlers

6. Apache 1.2.1 and ssi

7. Designing a error message handler

8. Linux/Win95 mounts

9. $$$FORM HANDLER DESIGN BRIEF$$$

10. General Exception-Handler and Design by Contract for C Programmers

11. 2.5.43: "fix old protocol handler pppoe_rcv+0x0/0x124 [pppoe]"

12. osid: call for collaborators on protocol design (initially)

13. designing client server protocols