Bluetooth DUN tun0 IP setting
smithi at nimnet.asn.au
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 
> 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
> Feb 27 13:06:38 slate01 kernel: tun0: link state changed to UP
> Feb 27 13:06:41 slate01 ppp: tun0: Warning: iface add:
> ioctl(SIOCAIFADDR, 126.96.36.199/24 -> 188.8.131.52): File exists
> Feb 27 13:06:41 slate01 kernel: ifa_add_loopback_route: insertion failed
> Feb 27 13:06:41 slate01 ppp: 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?
> 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
> Twitter @garydunn808
> Sent from Slate001
More information about the freebsd-mobile