[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: first shot at tunnel interface for pfinet
From: |
Roland McGrath |
Subject: |
Re: first shot at tunnel interface for pfinet |
Date: |
Wed, 4 Oct 2000 04:42:55 -0400 (EDT) |
> 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.