Discussion:
new EtherIP driver for 4.0
(too old to reply)
Hans Rosenfeld
2006-10-31 14:36:01 UTC
Permalink
Hi,

I wrote a new EtherIP driver for 4.0 based on tap(4) and gif(4).

I did this because the current EtherIP implementation is buggy
(kern/34268), quite unclean (it magically works by bridging a gif
interface) and, as I have been told, its way of hijacking a random
ethernet interfaces input routine to insert packets into the bridge is
at least questionable. It is also not possible to use bridge features
like STP with the current implementation.

The new driver presents itself to the system as a virtual ethernet
interface just like tap that has to be configured for tunnelling just
like gif.

The driver can be found in http://headcrashers.org/comp/programs/etherip.tar.gz

This tarball is supposed to be extracted in /usr/src. This will create
the following files:

etherip.diff
share/man/man4/etherip.4
sys/net/if_etherip.c
sys/net/if_etherip.h
sys/netinet/ip_etherip.c
sys/netinet/ip_etherip.h
sys/netinet6/ip6_etherip.c
sys/netinet6/ip6_etherip.h

The diff will remove the current EtherIP implementation from gif(4) and
bridge(4) and register the new files in share/man/man4/Makefile,
sys/net/Makefile, sys/conf/files.

To actually use it one has to add "pseudo-device etherip" to the
kernel configuration file.

Please try it and review the code, I would really like to get some
feedback about this. (And I would love to see this in 4.0 :))


Hans
--
%SYSTEM-F-ANARCHISM, The operating system has been overthrown

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
Rui Paulo
2006-10-31 15:09:01 UTC
Permalink
Hi,
Post by Hans Rosenfeld
Hi,
I wrote a new EtherIP driver for 4.0 based on tap(4) and gif(4).
I did this because the current EtherIP implementation is buggy
(kern/34268), quite unclean (it magically works by bridging a gif
interface) and, as I have been told, its way of hijacking a random
ethernet interfaces input routine to insert packets into the bridge is
at least questionable. It is also not possible to use bridge features
like STP with the current implementation.
The new driver presents itself to the system as a virtual ethernet
interface just like tap that has to be configured for tunnelling just
like gif.
The driver can be found in http://headcrashers.org/comp/programs/
etherip.tar.gz
This tarball is supposed to be extracted in /usr/src. This will create
etherip.diff
share/man/man4/etherip.4
sys/net/if_etherip.c
sys/net/if_etherip.h
sys/netinet/ip_etherip.c
sys/netinet/ip_etherip.h
sys/netinet6/ip6_etherip.c
sys/netinet6/ip6_etherip.h
The diff will remove the current EtherIP implementation from gif(4) and
bridge(4) and register the new files in share/man/man4/Makefile,
sys/net/Makefile, sys/conf/files.
To actually use it one has to add "pseudo-device etherip" to the
kernel configuration file.
Please try it and review the code, I would really like to get some
feedback about this. (And I would love to see this in 4.0 :))
I took a very skim look and I couldn't find anything obviously wrong.
There are some KNF nits but nothing important.

Thanks for doing this, I'll try to play with it when I have more
spare time!

--
Rui Paulo



--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
David Young
2006-10-31 22:25:11 UTC
Permalink
Post by Hans Rosenfeld
Hi,
I wrote a new EtherIP driver for 4.0 based on tap(4) and gif(4).
I did this because the current EtherIP implementation is buggy
(kern/34268), quite unclean (it magically works by bridging a gif
interface) and, as I have been told, its way of hijacking a random
ethernet interfaces input routine to insert packets into the bridge is
at least questionable. It is also not possible to use bridge features
like STP with the current implementation.
Hans,

That's cool, thanks! I can adapt this code to work with gre, too.

***

It occurred to me this morning that instead of adding entries to the
protocol switch for gif or gre, maybe we can use raw sockets like so?

struct socket *so;

socreate(AF_xxx ..., &so, SOCK_RAW, IPPROTO_xxx, ...)
sobind(so, local_outer_address, ...);
soconnect(so, remote_outer_address, ...);

This has the advantage that it re-uses protocol demultiplexing code.
That is, we do not have to search the available tunnel interfaces as gre
does in gre_lookup(), but the socket demultiplexing code does this for us:

for (sc = LIST_FIRST(&gre_softc_list); sc != NULL;
sc = LIST_NEXT(sc, sc_list)) {
if ((sc->g_dst.s_addr == ip->ip_src.s_addr) &&
(sc->g_src.s_addr == ip->ip_dst.s_addr) &&
(sc->g_proto == proto) &&
((sc->sc_if.if_flags & IFF_UP) != 0))
return (sc);
}

Also, using raw sockets helps simplify gre, which already uses sockets
in UDP mode. GRE can dispense with IP encapsulation and demultiplexing,
and the kernel thread that does sosends and soreceives UDP datagrams can
sosend/soreceive IPv4- / IPv6-encapsulated packets, too. Many lines of
code will be saved. IPv6-enabling GRE will become very easy.

I believe the raw sockets approach will simplify etherip, too. I believe
virtually all of the code in sys/netinet{6,}/ can go away.

What do you think?

Dave
--
David Young OJC Technologies
***@ojctech.com Urbana, IL * (217) 278-3933

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
Hans Rosenfeld
2006-11-21 20:50:07 UTC
Permalink
Post by Rui Paulo
I took a very skim look and I couldn't find anything obviously wrong.
There are some KNF nits but nothing important.
After some brainstorming with Rui I made some (mostly cosmetic) changes to
the code to make it conform to KNF rules. I put the latest version in
http://headcrashers.org/comp/programs/etherip.tar.gz for others to take
another look at it.
--
%SYSTEM-F-ANARCHISM, The operating system has been overthrown

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
Rui Paulo
2006-11-22 17:11:10 UTC
Permalink
Post by Hans Rosenfeld
Post by Rui Paulo
I took a very skim look and I couldn't find anything obviously wrong.
There are some KNF nits but nothing important.
After some brainstorming with Rui I made some (mostly cosmetic) changes to
the code to make it conform to KNF rules. I put the latest version in
http://headcrashers.org/comp/programs/etherip.tar.gz for others to take
another look at it.
Anyone has anything to say ? I plan to commit this soon.
--
Rui Paulo



--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
Christos Zoulas
2006-11-22 20:02:59 UTC
Permalink
Post by Rui Paulo
Post by Hans Rosenfeld
Post by Rui Paulo
I took a very skim look and I couldn't find anything obviously wrong.
There are some KNF nits but nothing important.
After some brainstorming with Rui I made some (mostly cosmetic) changes to
the code to make it conform to KNF rules. I put the latest version in
http://headcrashers.org/comp/programs/etherip.tar.gz for others to take
another look at it.
Anyone has anything to say ? I plan to commit this soon.
1. The whole thing needs to be passed through unexpand and possibly
the indentation in ethersubr.c is wrong.
2. s/bzero/memset/
3. etherip_ether_aton() -> ether_snprintf(), same as the tap interface.

Go for it.

christos


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
Rui Paulo
2006-11-23 04:05:37 UTC
Permalink
Post by Christos Zoulas
Post by Rui Paulo
Post by Hans Rosenfeld
Post by Rui Paulo
I took a very skim look and I couldn't find anything obviously wrong.
There are some KNF nits but nothing important.
After some brainstorming with Rui I made some (mostly cosmetic) changes to
the code to make it conform to KNF rules. I put the latest
version in
http://headcrashers.org/comp/programs/etherip.tar.gz for others to take
another look at it.
Anyone has anything to say ? I plan to commit this soon.
1. The whole thing needs to be passed through unexpand and possibly
the indentation in ethersubr.c is wrong.
2. s/bzero/memset/
3. etherip_ether_aton() -> ether_snprintf(), same as the tap
interface.
Go for it.
Thanks. Committed.

--
Rui Paulo



--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
Loading...