Re: Best way to hook incoming eth pkts?

-----BEGIN PGP SIGNED MESSAGE-----

quoted

quoted

quoted

quoted

"Jeff" == Jeff Garzik [off-list ref] writes:

    Jeff> Essentially, all the things mentioned above need some way to listen
    Jeff> for incoming ethernet packets.  ATA-over-ethernet has its own
    Jeff> IANA-registered ethernet type, but netconsole and netdump are using
    Jeff> IP/UDP instead of a custom ethernet protocol.

    Jeff> So, two questions for the gurus of the crowd ;-)

    Jeff> 1) What is the best way for an in-kernel piece of software to
    Jeff> receive ethernet packets that are intended for it?

  For ethernet protocols, you can just register the protocol handler, and you
will get them.

    Jeff> 2) Possibly related to #1, is it a good or bad idea to consider
    Jeff> sending netconsole/netdump directly over ethernet, eschewing the
    Jeff> IP/UDP/syslog stuff?

  netconsole makes me really nervous, and I'd rather it was not over IP.
  (If you need a far-away remote console, then get another box with multiple 
serial ports + SSH, or get an Annex, or...)

  Another thing which would like UDP packets is the IPsec NAT-T stuff.
  It is even weirder, because some packets need to be *returned* to the 
UDP socket. (I didn't design this protocol, and argued against putting
the ESP and IKE traffic on the same port, but I lost that argument. I would
have prefered to implement Teredo, and then do IPv4-ESP-IPv6-UDP-IPv4
instead, since it would encourage IPv6)

]      Out and about in Ottawa.    hmmm... beer.                |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian/notebook using, kernel hacking, security guy");  [


  



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Finger me for keys - custom hacks make this fully PGP2 compat

iQCVAwUBP0O0p4qHRg3pndX9AQGjoAP/R37iSdbaK2aWqAwPZvY1DQ9JVSGdk+bq
RBhtuixa3V2SC/kqacw6eUf4gbEMZZgtA0IP4tP0vYXYv3eIUBeB4wJGTBD7Sezn
Tzwc1hJo/Eplbts+kirAM1DJ9Oh8/2HVVWvEQbyGvOqAE2WKzRrQYiCDuyuarH/F
ksardhGJKcM=
=daOJ
-----END PGP SIGNATURE-----

On Wed, 20 Aug 2003 13:59:29 -0400
Jeff Garzik [off-list ref] wrote:

On Wed, Aug 20, 2003 at 01:49:28PM -0400, Michael Richardson wrote:

quoted

  For ethernet protocols, you can just register the protocol handler, and you
will get them.

Dumb question:  how?  example code, or relevant functions to grep for?

He's talking about net/core/dev.c:dev_add_pack()

On Wed, Aug 20, 2003 at 01:49:28PM -0400, Michael Richardson wrote:

  For ethernet protocols, you can just register the protocol handler, and you
will get them.

Dumb question:  how?  example code, or relevant functions to grep for?

grepping for 'register.*prot' didn't seem to turn up anything useful,
and I didn't see any register*ether functions in linux/if_ether.h.

Thanks,

	Jeff

On Wed, Aug 20, 2003 at 10:54:37AM -0700, David S. Miller wrote:

On Wed, 20 Aug 2003 13:59:29 -0400
Jeff Garzik [off-list ref] wrote:

quoted

On Wed, Aug 20, 2003 at 01:49:28PM -0400, Michael Richardson wrote:

quoted

  For ethernet protocols, you can just register the protocol handler, and you
will get them.

Dumb question:  how?  example code, or relevant functions to grep for?

He's talking about net/core/dev.c:dev_add_pack()

Thanks much.

Tangent, from reading dev.c:  Is it ok that dev_queue_xmit_nit does not
check the return value of struct packet_type's ->func hook?  It seems to
do so in all other cases...

	Jeff

On Wed, 20 Aug 2003 14:15:12 -0400
Jeff Garzik [off-list ref] wrote:

Tangent, from reading dev.c:  Is it ok that dev_queue_xmit_nit does not
check the return value of struct packet_type's ->func hook?  It seems to
do so in all other cases...

The return value isn't really used currently.
It provides congestion heuristics that maybe eventually
will be taken advantage of.