From owner-freebsd-mobile@FreeBSD.ORG Wed Mar 2 03:22:03 2011 Return-Path: Delivered-To: freebsd-mobile@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 583DB1065676 for ; Wed, 2 Mar 2011 03:22:03 +0000 (UTC) (envelope-from knowtree@aloha.com) Received: from mail004.26.12.a.static.mtka.securence.com (mail004.26.12.A.static.MTKA.securence.com [216.17.12.26]) by mx1.freebsd.org (Postfix) with ESMTP id 121E98FC13 for ; Wed, 2 Mar 2011 03:22:02 +0000 (UTC) received: from usi-mail08-mtka.usinternet.com. (216.17.3.12) by mta30.mtka.securence.com (securence); tue, 1 mar 2011 21:07:22 -0600 (cst) Received: from [10.0.1.10] (atm-251-63.pixi.com [206.127.251.63]) by usi-mail08-mtka.usinternet.com (Postfix) with ESMTP id 579F72204AA; Tue, 1 Mar 2011 21:07:01 -0600 (CST) From: Gary Dunn To: Ian Smith 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> Content-Type: text/plain; charset="us-ascii" Date: Tue, 01 Mar 2011 07:58:33 -0800 Message-ID: <1298995113.1570.5.camel@slate01> Mime-Version: 1.0 X-Mailer: Evolution 2.28.2 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit x-securence-id: 1299035242738-030-03001642 x-securence-country-code: us - united states x-securence-odset: main.outbound.usinternet.com x-securence-remote-host: usi-mail08-mtka.usinternet.com. x-securence-remote-addr: 216.17.3.12 x-securence-rfc2821-mail-from: knowtree@aloha.com x-securence-pp1t: 0 x-securence-trat: 5 x-securence-omc: 0 x-securence-tsist: 6 x-securence-urt: 2 x-securence-art: 0 x-securence-drt: 8 x-securence-info: d8; 0orl0; 1otrp0; 100opp10; 2osrb5; 84ous164; 45oavs0; 0ovxr0; 100oclm100; 100ocom0; 100obsp0; 1ovrc0; 99ophc0; 0isd0; 15dds0; 86domsplt0; 100vac0; 7dogp0; 96med0; 97fsqd0; 97fsdd0; 3dod0; 0dds0; 3domsplt0; 98vac0; 1dogp0; 1med0; 40fsqd0; 22fsdd2; 34dod0; 8cld0; 93lrd0; 7dlv1; dmqq150; s201; t203 x-securence-defer-note-1: attempted to deliver at 2011-03-01 21:07:25 (cst) x-securence-defer-note-2: attempted to deliver at 2011-03-01 21:09:02 (cst) x-securence-defer-note-3: attempted to deliver at 2011-03-01 21:11:03 (cst) x-securence-defer-note-4: attempted to deliver at 2011-03-01 21:15:03 (cst) X-Securence-Latseq: <30-1299035244277> Cc: Maciej Milewski , freebsd-mobile@freebsd.org Subject: Re: Bluetooth DUN tun0 IP setting X-BeenThere: freebsd-mobile@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile computing with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 03:22:03 -0000 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 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