Ed's Blog

A PhD Student's Musings

FoxFi/PdaNet on Mavericks

• ∞

In theory, I can work anywhere with my backpack. I just tether my laptop over bluetooth and I’m good to go. In practice, I do this infrequently enough that bluetooth breaks for some reason, and I spend an hour trying to fix my tethering setup, rather than completing an hour of work. Today was no exception.

I spent an hour trying to get my MacBook Air, which runs OS X 10.9.2, tethered over bluetooth to FoxFi/PdaNet. The last time I connected was before I had Mavericks, and of course the connection didn’t work. The connection displayed as connected, but the connection duration stayed at 0 seconds, and no IP address was shown. More importantly, there was no connectivity!

Turning on verbose PPP logging and peeking at ppp.log revealed this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42

Fri Feb 28 17:47:26 2014 : Serial connection established.
Fri Feb 28 17:47:26 2014 : using link 0
Fri Feb 28 17:47:26 2014 : Using interface ppp0
Fri Feb 28 17:47:26 2014 : Connect: ppp0 <--> /dev/cu.Bluetooth-Modem
Fri Feb 28 17:47:27 2014 : sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x1c48b84f> <pcomp> <accomp>]
Fri Feb 28 17:47:27 2014 : rcvd [LCP ConfRej id=0x1 <magic 0x1c48b84f>]
Fri Feb 28 17:47:27 2014 : sent [LCP ConfReq id=0x2 <asyncmap 0x0> <pcomp> <accomp>]
Fri Feb 28 17:47:27 2014 : rcvd [LCP ConfAck id=0x2 <asyncmap 0x0> <pcomp> <accomp>]
Fri Feb 28 17:47:27 2014 : rcvd [LCP ConfReq id=0x1c <asyncmap 0x0> <pcomp> <accomp>]
Fri Feb 28 17:47:27 2014 : lcp_reqci: returning CONFACK.
Fri Feb 28 17:47:27 2014 : sent [LCP ConfAck id=0x1c <asyncmap 0x0> <pcomp> <accomp>]
Fri Feb 28 17:47:27 2014 : sent [IPCP ConfReq id=0x1 <compress VJ 0f 01> <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>]
Fri Feb 28 17:47:27 2014 : sent [IPV6CP ConfReq id=0x1 <addr fe80::6aa8:6dff:fe02:81da>]
Fri Feb 28 17:47:28 2014 : rcvd [IPCP ConfRej id=0x1 <compress VJ 0f 01>]
Fri Feb 28 17:47:28 2014 : sent [IPCP ConfReq id=0x2 <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>]
Fri Feb 28 17:47:28 2014 : rcvd [IPCP ConfReq id=0x1c <addr 192.168.19.2>]
Fri Feb 28 17:47:28 2014 : ipcp: returning Configure-ACK
Fri Feb 28 17:47:28 2014 : sent [IPCP ConfAck id=0x1c <addr 192.168.19.2>]
Fri Feb 28 17:47:28 2014 : rcvd [IPV6CP ConfRej id=0x1 <addr fe80::6aa8:6dff:fe02:81da>]
Fri Feb 28 17:47:28 2014 : sent [IPV6CP ConfReq id=0x2]
Fri Feb 28 17:47:28 2014 : rcvd [IPCP ConfNak id=0x2 <addr 192.168.19.2> <ms-dns1 8.8.8.8> <ms-dns3 8.8.4.4>]
Fri Feb 28 17:47:28 2014 : sent [IPCP ConfReq id=0x3 <addr 192.168.19.2> <ms-dns1 8.8.8.8> <ms-dns3 8.8.4.4>]
Fri Feb 28 17:47:28 2014 : rcvd [IPV6CP ConfAck id=0x2]
Fri Feb 28 17:47:28 2014 : rcvd [IPCP ConfAck id=0x3 <addr 192.168.19.2> <ms-dns1 8.8.8.8> <ms-dns3 8.8.4.4>]
Fri Feb 28 17:47:28 2014 : ipcp: up
Fri Feb 28 17:47:28 2014 : local  IP address 192.168.19.2
Fri Feb 28 17:47:28 2014 : remote IP address 192.168.19.2
Fri Feb 28 17:47:28 2014 : primary   DNS address 8.8.8.8
Fri Feb 28 17:47:28 2014 : secondary DNS address 8.8.4.4
Fri Feb 28 17:47:31 2014 : sent [IPV6CP ConfReq id=0x2]
Fri Feb 28 17:47:31 2014 : rcvd [IPV6CP ConfAck id=0x2]
Fri Feb 28 17:47:34 2014 : sent [IPV6CP ConfReq id=0x2]
Fri Feb 28 17:47:34 2014 : rcvd [IPV6CP ConfAck id=0x2]
Fri Feb 28 17:47:37 2014 : sent [IPV6CP ConfReq id=0x2]
Fri Feb 28 17:47:37 2014 : rcvd [IPV6CP ConfAck id=0x2]
Fri Feb 28 17:47:40 2014 : sent [IPV6CP ConfReq id=0x2]
Fri Feb 28 17:47:40 2014 : rcvd [IPV6CP ConfAck id=0x2]
Fri Feb 28 17:47:43 2014 : sent [IPV6CP ConfReq id=0x2]
Fri Feb 28 17:47:43 2014 : rcvd [IPV6CP ConfAck id=0x2]
Fri Feb 28 17:47:46 2014 : sent [IPV6CP ConfReq id=0x2]
Fri Feb 28 17:47:46 2014 : rcvd [IPV6CP ConfAck id=0x2]
Fri Feb 28 17:47:49 2014 : sent [IPV6CP ConfReq id=0x2]

I’m not a PPP wizard, but it looks to me like something is wrong with the IPV6 autoconfiguration. I turned off IPV6 on my Bluetooth DUN interface via:

1

networksetup -setv6off "Bluetooth DUN"

And sure enough, I got a connection:

I hope this helps somewhat else. I have no idea why Apple’s PPP implementation would not do something, like, say, time out. In fact, the pppd man page even lists a ipv6cp-max-configure n option, which is described as:

1

Set the maximum number of IPv6CP configure-request transmissions to n (default 10).

This suggests to me that after 10 IPV6CP packets the connection should work. But this doesn’t happen. I don’t really have time to investigate why.

Comments