Date: Tue, 01 Mar 2011 07:58:33 -0800 From: Gary Dunn <knowtree@aloha.com> To: Ian Smith <smithi@nimnet.asn.au> Cc: Maciej Milewski <milu@dat.pl>, freebsd-mobile@freebsd.org Subject: Re: Bluetooth DUN tun0 IP setting Message-ID: <1298995113.1570.5.camel@slate01> In-Reply-To: <20110301203001.K62968@sola.nimnet.asn.au> References: <1298129174.1540.7.camel@slate01> <201102192242.35920.milu@dat.pl> <1298452409.1549.0.camel@slate01> <201102231305.37013.milu@dat.pl> <1298952823105-029-00654977.knowtree.aloha.com@usi-mail08-mtka.usinternet.com> <20110301203001.K62968@sola.nimnet.asn.au>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1298995113.1570.5.camel>