>I think the solution would be to have openvpn disable TUN_NO_IP for
Linux tun devices and just not care about the actual value when
the packets arrive.
So if the linux side disables TUN_NO_PI, does the problem go away when
connecting to BSD?
James
> >Yes, but since BSD wont let you choose if you want it or not, and the
> chance of changing Linux-TUN-drivers now is slim, I guess it has to be
> the application that takes care of this. I'll try to make a patch and
> test it, and send you the diff later.
>
> Some thoughts:
>
> * probably the
On Thu, 2002-04-04 at 10:46, James Yonan wrote:
> >I don't know the openvpn data format, but if 4554 is some sort of
> openvtun identifier, you/we/I could add some code that checked for
> 0002 followed by 4554 and then strip the first u_int_32 from
> the packet and go on. Perhaps a --re
On Thu, 2002-04-04 at 10:46, James Yonan wrote:
> >I don't know the openvpn data format, but if 4554 is some sort of
> openvtun identifier, you/we/I could add some code that checked for
> 0002 followed by 4554 and then strip the first u_int_32 from
> the packet and go on. Perhaps a --re
>I don't know the openvpn data format, but if 4554 is some sort of
openvtun identifier, you/we/I could add some code that checked for
0002 followed by 4554 and then strip the first u_int_32 from
the packet and go on. Perhaps a --remote-is-bsd or something similar?
Openvpn doesn't look
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 ord
>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 shoul
Sorry for "spamming" so much with my porting issues.
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.
That's why my last mail contains sending of "0002" as the first
32 bits, it's telling the other en
