On Wed, 2002-04-03 at 00:44, James Yonan wrote: > >Sorry for "spamming" so much with my porting issues. > > Hey, I think it's great you're trying to port it! Post as much as you want. > > >Now it seems that BSD (at least Free/OpenBSD) TUN devices send AF_INET > as a u_int32_t in network byte order first, which Linux tun-devs > dont. > > Interesting. We should post something about that on the TUN/TAP list. I > would think that network byte order should be the correct behaviour.
I'll get back to this further down, but to clarify, _each_ packet read from tun will have this u_int_32 prepended. > >That's why my last mail contains sending of "00000002" as the first > 32 bits, it's telling the other end which AF to use. > > >When initiated from the Linux end, the BSD will say > "unknown address family" or something very similar, which is true > since it gets "45000054" as the first data. > > >Is there two types of tun or is the BSD tuns just slightly different and > incompatible by design? > > Also sounds like a TUN/TAP list question. I know the TUN/TAP driver became > an official part of the linux kernel as of the early 2.4 releases. > > A fix on the linux side to conform to network byte ordering would be dicey > since it would break compatibility. Well, sooner or later Linux should do that too, to support big endian machines. But the issue was more to the fact that the BSD sends this: "00000002 45000054 ..blabla" whereas Linux sends this: "45000054 ..blabla". The manpage for tun on BSD says: "The first u_int32_t of data will always be the address family (eg, AF_INET) of the packet in network byte order. By default, the packet data follows immediately, but if the PREPADDR bit is set, the address to which the packet is to be sent is placed after the address family u_int32_t and before the packet data." Now, I don't want to rant about OSes, but being able to just type "man tun" when you're dealing with tun interfaces and get serious info is quite nice. I googled a bit yesterday and could not find neither tun info for Linux nor the kernel source as cvsweb, so I could read the source at least. 8-/ > My approach would be to do the fix on the linux side but add an extra check > for compatibility and allow packets if the order is wrong. Since there > aren't too many address families to worry about, the bad ordering test > should't be terribly ambiguous. > > And since linux kernel changes take a long time to happen, it might be > necessary to add a workaround in OpenVPN to deal with this. > > What do you think? I don't know the openvpn data format, but if 45000054 is some sort of openvtun identifier, you/we/I could add some code that checked for 00000002 followed by 45000054 and then strip the first u_int_32 from the packet and go on. Perhaps a --remote-is-bsd or something similar? The last bit of the manpage says: "NOTES Very old versions of the tunnel device did not include the address family at the start of the packet. More recent versions passed the address family as a single byte, but this caused problems with bpf, hence the current version passes a u_int32_t of address family. This was initially pass in host byte order, but the current version now uses network byte order." I checked the CVS for openbsd, and the native -> network byte order change was done 3 years ago, which is a really long time. I wonder if Vtun ever did work between linux-vs-bsd ? Or does it have code to handle this? -- Janne Johansson jan.johans...@biomatsys.com BioMat Systems AB Klarabergsg 37 3tr 111 21 Stockholm
signature.asc
Description: This is a digitally signed message part
