Bluetooth DUN tun0 IP setting

Wed Mar 2 03:22:03 UTC 2011

On Tue, 2011-03-01 at 20:54 +1100, Ian Smith wrote:
> On Mon, 28 Feb 2011, Gary Dunn wrote:
>  > My research led to descriptions of my symptoms caused by an
>  > incompatibility between ifconfig and tun,. I am planning to upgrade
>  > FreeBSD and Gnome anyway, and with that and a little luck my problem
>  > will be solved. If not I'll be back.
[snip]
> Gary, I know nothing about this gadgetry at all and haven't used ppp for 
> years, but I can say that 'File exists' here really - at least usually - 
> means 'Route exists'.  Dunno if ppp execs route or duplicates that code.
> 
> Could be due to ppp trying to assign a default route when one already 
> exists, perhaps because it wasn't cleared on a previous connection, or 
> otherwise already exists.  Check ppp.conf doesn't assign it twice.  It 
> may be necessary to 'route delete default' externally, eg by script?
> 
> Watching 'netstat -rn | grep default' or 'route -n monitor' may help?
> 
> cheers, Ian

Thanks for the help. I admit I was confused by the "file" error.

Here are two messages from a related thread back in 2009, which resulted
in my decision to wait for 8.2:

> Subject: recent change to ifconfig breaks OpenVPN?
> 
> 
> I just updated this afternoon (r195941), and after rebooting, OpenVPN  
> has problems ifconfig'ing a tun interface.
> 
> With sources from about one week ago, this is working:
> Jul 29 03:07:15 diesel openvpn_zs64[14785]: /sbin/ifconfig tun1  
> 44.128.127.2 44.128.127.2 netmask 255.255.255.0 mtu 1500 up
> Jul 29 03:07:15 diesel openvpn_zs64[14785]: /sbin/route add -net  
> 44.128.127.0 44.128.127.2 255.255.255.0
> Jul 29 03:07:15 diesel openvpn_zs64[14785]: /sbin/route add -net  
> 44.128.64.0 44.128.127.1 255.255.192.0
> 
> Now, the same sequence fails:
> Jul 29 17:31:41 diesel openvpn_zs64[1855]: /sbin/ifconfig tun1  
> 44.128.127.2 44.128.127.2 netmask 255.255.255.0 mtu 1500 up
> Jul 29 17:31:41 diesel openvpn_zs64[1855]: FreeBSD ifconfig failed:  
> external program exited with error status: 1
> 
> Trying the same command manually gets me:
> /sbin/ifconfig tun1 44.128.127.2 44.128.127.2 netmask 255.255.255.0  
> mtu 1500 up
> ifconfig: ioctl (SIOCAIFADDR): File exists
> 
> even though no address was assigned before.
> 
> Another OpenVPN instance using tap continues to work.
> 
> 
> Stefan
> 

And after a few exchanges:

> 
> m 30.07.2009 um 01:46 schrieb Matthias Andree:
> 
> > Hi everybody,
> >
> > If that is the case, then we should go quickly to either make it go  
> > into 8-CURRENT's ports or OpenVPN 2.1, or both.
> >
> > I'm not sure I have sufficient context or time to read up to  
> > determine my own role here (I haven't been following -current for  
> > lack of time); can someone summarize the issue for me?
> 
> I can try to summarize; I don't think I'll have time to come up with a  
> patch this weekend.
> 
> The problem appears to be that OpenVPN invokes ifconfig with incorrect  
> (but previously working) parameters, namely "ifconfig tun0 local_ip  
> local_ip" instead of "ifconfig tun0 local_ip remote_ip".  The problem  
> does not appear to be the SIOCAIFADDR but the RT_ADD that ifconfig  
> does.  When I drafted a replacement OpenVPN --up script yesterday, I  
> also noticed that the parameters passed to the script are wrong  
> (netmask instead of remote ip), and environment variables are  
> partially not set (ifconfig_remote is empty).
> 
> This issue appears to affect tun-mode connections; tap-mode  
> connections appear to continue to work.
> 
> I'm not sure if that is a more general problem with OpenVPN (at least  
> in --topology subnet mode), or a specific problem in the FreeBSD- 
> specific code.  I just looked at a Linux box connected to the same  
> OpenVPN server, and their ifconfig invocation looks different from  
> ours, so the FreeBSD-specific code at least plays some role.
> 
> I'd still like to know whether the change to the routing code is  
> intentional or a regression.
> 
> 
> Stefan
> 
> p.s. log output wrt ifconfig:
> 
> FreeBSD (working up to last week, continues to work in -stable):
> /sbin/ifconfig tun1 44.128.127.2 44.128.127.2 netmask 255.255.255.0  
> mtu 1500 up
> 
> Linux:
> /sbin/ifconfig tun4 44.128.127.15 netmask 255.255.255.0 mtu 1500  
> broadcast 44.128.127.255
> 
> It is interesting to note that tun4 on the Linux box has the same  
> local and remote address:
> /sbin/ifconfig tun4
> tun4      Link encap:UNSPEC  HWaddr  
> 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
>            inet addr:44.128.127.15  P-t-P:44.128.127.15  Mask: 
> 255.255.255.0
>            UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
> 
> -- 
> Stefan Bethke <stb at lassitu.de>   Fon +49 151 14070811

-- 
Gary Dunn, Honolulu
Open Slate Project
http://openslate.org
http://www.facebook.com/garydunn808
http://e9erust.blogspot.com
Twitter @garydunn808
Sent from Slate001