Bluetooth DUN tun0 IP setting

Tue Mar 1 10:30:01 UTC 2011

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.
 > 
 > For the record, here is my data:
 > 
 > $ uname -a
 > FreeBSD slate01 8.0-RELEASE-p2 FreeBSD 8.0-RELEASE-p2 #0: Thu Jan 28
 > 06:16:14 HST 2010     gary at slate01:/usr/obj/usr/src/sys/GENERIC  i386
 > 
 > 
 > On Wed, 2011-02-23 at 13:05 +0100, Maciej Milewski wrote:
 > > Dnia ?roda, 23 lutego 2011 o 10:13:29 Gary Dunn napisa?(a):
 > > > Here is my ppp.conf. My googling returns two trends, 1) info about
 > > > rfcomm ON Android, 2) a lot of people having problems with PDA Net in
 > > > DUN mode. The developers appear to be focused on the Windows and Mac USB
 > > > tether configuration, which requires a custom app on the PC.
 > > Well, I don't know what you mean by 1) but if there is much problems with dun 
 > > on different systems there may be a deeper problem in the pda net.
 > > Could you provide additionaly a full ppp log of the session?
 > > And maybe in the /var/log/messages will be sth interesting.
 > 
 > Here is the command sequence I entered:
 > 
 > slate01# hccontrol -n ubt0hci inquiry
 > Inquiry result, num_responses=1
 > Inquiry result #0
 > 	BD_ADDR: mini-slate
 > 	Page Scan Rep. Mode: 0x1
 > 	Page Scan Period Mode: 0x2
 > 	Page Scan Mode: 00
 > 	Class: 7a:02:04
 > 	Clock offset: 0xa64
 > Inquiry complete. Status: No error [00]
 > slate01# rfcomm_pppd -a mini-slate -c -C dun -l rfcomm-dialup
 > 
 > Here are the entries from /var/log/messages. The first came immediately
 > after I entered the rfcomm_pppd command. The "link start changed to
 > DOWN" was in response to my turning off PDA Net DUN service on the
 > phone.
 > 
 > Feb 27 13:06:38 slate01 kernel: tun0: link state changed to UP
 > Feb 27 13:06:41 slate01 ppp[1624]: tun0: Warning: iface add:
 > ioctl(SIOCAIFADDR, 68.245.171.115/24 -> 68.245.171.115): File exists
 > Feb 27 13:06:41 slate01 kernel: ifa_add_loopback_route: insertion failed
 > Feb 27 13:06:41 slate01 ppp[1624]: tun0: Error: ipcp_InterfaceUp: unable
 > to set ip address
 > Feb 27 13:06:42 slate01 kernel: tun0: link state changed to DOWN
 > Feb 27 13:06:42 slate01 kernel: ng_l2cap_l2ca_receive: ubt0l2cap -
 > unexpected L2CAP data packet. Channel does not exist, cid=66
 > 
 > The IP address looks like it came from the phone, because it does not
 > match anything else. But what file exists?

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

 > Found this in man tun:
 > 
 >     If the sysctl(8) variable net.link.tun.devfs_cloning is 
 >     non-zero, the tun interface permits opens on the special 
 >     control device /dev/tun.  When this device is opened, 
 >     tun will return a handle for the lowest unused tun
 >     device (use devname(3) to determine which).
 > 
 > 
 >     Disabling the legacy devfs cloning functionality may break existing
 >     applications which use tun, such as ppp(8) and ssh(1).  It therefore
 >     defaults to being enabled until further notice.
 > 
 > I checked mine:
 > 
 > slate01# sysctl net.link.tun.devfs_cloning
 > net.link.tun.devfs_cloning: 1
 > 
 > 
 > -- 
 > Gary Dunn, Honolulu
 > Open Slate Project
 > http://openslate.org
 > http://www.facebook.com/garydunn808
 > http://e9erust.blogspot.com
 > Twitter @garydunn808
 > Sent from Slate001