Re: first shot at tunnel interface for pfinet

[Roland McGrath]

> in light of the recent discussions, and considering that no code resulted
> from them, I had a go at the Hurd related changes for a tunnel interface in
> pfinet.

Excellent hackery, Marcus!

> Currently, the interface emits ethernet frames, if I am not completely
> mistaken,

Yes, because you set hard_header to eth_header.  Just set hard_header and
hard_header_len to zero, because there is no hardware header.  
Set the skb->protocol to htons(ETH_P_IP).

> and who knows what happens with the data you send to
> it. Apropos sending: Writing seems to be quite unstable, there are a
> couple of callbacks missing, and if you try to write with tools like "cat
> > /dev/tun0" you will get EIOIO and Resource lost and other inconvient
> stuff. However, normal write() seems to work fine. Mmmh.

That is probably S_trivfs_file_set_size ("> foo" redirections call open
with O_WRONLY|O_TRUNC|O_CREAT, which turns into a file_set_size RPC after
the dir_lookup).  trivfs has stubs that crash if trivfs_support_write is set,
but return EOPNOTSUPP if it's zero.  In fact, those asserts are the only
thing that ever use trivfs_support_write, so you could just turn it off to
get the trivfs EOPNOTSUPP stubs for the functions you haven't written.

> If you have screen, try "cat /dev/tun0" on one screen, and "ping 192.168.1.1"
> on the other. You will see how the packages appear on the first screen when
> pfinet sends them. Testing if write works correctly is harder, as you need
> to produce valid network packages in user space. 

Use dd if=/dev/tun0 of=file to capture packets you write e.g. with ping.
Then swap the IP addreses on your tun interface, and 
use dd if=file of=/dev/tun0 to replay the pings back at it.
I can't think of anything wrong with this, so if it's working your
should see the ping packets from the file.

> What else? select() works! As well as reading in O_NONBLOCK mode. This is
> required for ppp as well.

Excellent!

> * Implement all other required callbacks for trivfs.
> * Correct protocol details, see tunnel.c::tunnel_xmit (for packages

I think the changes I've described will get you most of the way there for
both of these.

> * Porting user space ppp.
>   This should be a piece of cake, but requires some careful code reading and
>   debugging. There are generic porting issues, as well as the need to turn
>   ioctls into fsysopts calls.

Shouldn't be much to it.  I'm looking at the userland ppp source in
freebsd.  It appears the BSD tun device has a mode where it prepends a
32-bit word of AF_INET to each packet (and expects them on packets
written).  Should be trivial enough to support that if you want to (set
hard_header/hard_header_len to push the word), but it's also easy to make
userppp not care.

You might want to add a --mtu option and make userppp able to set that via
fsys_set_options instead of the ioctls it uses on BSD.  Of course all the
SIOC* ioctls for setting the addresses and such will have to be the same.
BTW, I don't think there is any reason not to support --netmask with the
tun interface; it's just the default in the absence of the option should be
all-ones for the pointtopoint interfaces.

The tty ioctls it uses ought to work ok.