bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: first shot at tunnel interface for pfinet


From: Marcus Brinkmann
Subject: Re: first shot at tunnel interface for pfinet
Date: Wed, 4 Oct 2000 20:29:19 +0200
User-agent: Mutt/1.1.4i

Hi,

On Wed, Oct 04, 2000 at 04:42:55AM -0400, Roland McGrath wrote:
> > 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).

I didn't set hard_header at all (at least I don't see it),
but hard_header_len. Fixed now.

There is another slight problem: net_bh checks if skb->mac.raw is between
skb->head and skb->data. For us, head==data and mac.raw == 0, so I put a
skb->mac.raw = skb->data into trivfs_S_io_write. (Whatever mac is)
 
This revealed another problem: we don't see printk error messages from the
linux code anywhere.

> 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).

Yes, I fixed it by adding the missing stubs.

> > 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.

Mmh. Doesn't work yet. One problem was mac.raw (see above), and now that I
fixed it, the packets are accepted by net_bh and forwarded to ip_rcv in
linux_src/net/ipv4/ip_input.c. I have traced through it, but didn't see
anything suspicious. It seemed to work ok, but I don't know which path it
should take through this lengthy routine. Can't be such a big problem, I
guess.

> > * 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.

Yes, thanks a lot.
 
> > * 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.

I've seen that, and decided to not support it for now. That's left as an
exercise for someone else, if needed ;) Can be done as an option through
fsysopts, too.

> 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.

The problem with adding options is that they need to be passed through
find_device to setup_*_device. So find_device gets the union of all possibly
needed options, which is a bit ugly. Also, it needs some special treatment
in fsysopts or even configure_device, I think. But I added it to the TODO list
anyway.

> Of course all the
> SIOC* ioctls for setting the addresses and such will have to be the same.

I don't understand what you mean with "have to be the same". The same as was?
As far as I see, we don't support those ioctls and simply call fsysopts.

Which leads to yet another problem: fsysopts on server/sockets/2 succeeds,
but returns "No such process". I will debug this later.

> 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.

Done.

Attached is the current version.
 
Thanks,
Marcus

-- 
`Rhubarb is no Egyptian god.' Debian http://www.debian.org Check Key server 
Marcus Brinkmann              GNU    http://www.gnu.org    for public PGP Key 
Marcus.Brinkmann@ruhr-uni-bochum.de,     marcus@gnu.org    PGP Key ID 36E7CD09
http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/       brinkmd@debian.org

Attachment: pfinet-tunnel.diff.gz
Description: Binary data


reply via email to

[Prev in Thread] Current Thread [Next in Thread]