|
|
Quozl's Maxon BP3-USB on Linux |
| quozl@us.netrek.org
| up |
|
Scope: Linux with Maxon BP3-USB, or BP3-EXT modem.
|
|
|
Since all this work was done, the Linux distributions have been busy making this so much easier.
As an example, Ubuntu 9.04 recognises these modems when they are plugged in, and the NetworkManager application is launched to configure them.
See the instructions.
It is very bare metal stuff at this stage, it could really do with a window.
However, the non-standard modem control line behaviour makes it difficult to reliably get the modem to wake up again after disconnect ... so a better driver is still needed.
The way to get the option driver to adopt the modem is to:
modprobe option echo "0x16d8 0x6280" > /sys/bus/usb-serial/drivers/option1/new_idOr if you are into rebuilding your kernel, the patch to it would look like this:
--- a/drivers/usb/serial/option.c 2008-04-09 18:34:51.000000000 +1000
+++ b/drivers/usb/serial/option.c 2008-04-09 18:45:53.000000000 +1000
@@ -165,6 +165,8 @@
#define QUALCOMM_VENDOR_ID 0x05C6
+#define MAXON_VENDOR_ID 0x16d8
+
static struct usb_device_id option_ids[] = {
{ USB_DEVICE(OPTION_VENDOR_ID, OPTION_PRODUCT_COLT) },
{ USB_DEVICE(OPTION_VENDOR_ID, OPTION_PRODUCT_RICOLA) },
@@ -249,6 +251,7 @@
{ USB_DEVICE(BANDRICH_VENDOR_ID, BANDRICH_PRODUCT_C100_2) },
{ USB_DEVICE(KYOCERA_VENDOR_ID, KYOCERA_PRODUCT_KPC680) },
{ USB_DEVICE(QUALCOMM_VENDOR_ID, 0x6613)}, /* Onda H600/ZTE MF330 */
+ { USB_DEVICE(MAXON_VENDOR_ID, 0x6280) }, /* BP3-USB & BP3-EXT HSDPA */
{ } /* Terminating entry */
};
MODULE_DEVICE_TABLE(usb, option_ids);
Compared to the older CDMA 1x RTT service, this new service has quite low latency:
--- bigpond.com ping statistics --- 100 packets transmitted, 100 packets received, 0% packet loss round-trip min/avg/max = 110.2/120.5/175.7 ms
| Problem | Cause | Workaround | Solution |
|---|---|---|---|
| modem does not appear in list of known devices | kernel predates release of modem | manual probing with usbserial driver, see below | patch the airprime driver, see below |
| multiple interfaces appear | the device has an interface for serial use, for network device mode, and for firmware access | use the one that responds to AT commands, usually /dev/ttyUSB1 with the usbserial module, or /dev/ttyUSB3 with a patched airprime module | manufacturer could sponsor or write a driver for network device mode |
| bit rate seems to peak at 550 kbit/sec, when using usbserial driver | usbserial does not use bulk transfers | patch the airprime driver, see below | manufacturer could sponsor or write a driver for network device mode |
| "Modem Hangup", IPCP fails to negotiate any IP address |
Unlike with PSTN modems, the PPP negotiation occurs in absence
of radio signal. Your computer talks to the PPP program in the modem.
So several causes lead to this problem:
|
varies |
|
| IPCP always fails to negotiate a remote IP address | apparently normal, pppd on your system will report Could not determine remote IP address: defaulting to 10.64.64.x (plus the interface unit number), but provided you have a route via the interface it will continue to work. | do nothing, add the replacedefaultroute pppd option, or discover the remote IP address by other means | service provider could configure network to provide the remote IP address |
| latency sometimes increases significantly | the network path can change to include unexpected hops, using route tracing tools we've seen Dubbo, Perth, Sydney, and Melbourne hosts in the route before exiting the service provider's network, so this can slow things down due to the speed of light | none | contact service provider with route trace |
Workaround: use the number that dials in a way that selects the alternate profile ... *99***2#
Solution: using a terminal emulator attached to the modem port, before upgrading the firmware record the profile 1 settings using at+cgdcont? then after upgrading rewrite profile 1:
at+cgdcont=1,"IP","telstra.datapack"You can also check the current setting with, at+cgdcont? ... and mine responds with:
AT+CGDCONT? +CGDCONT: 1,"IP","telstra.bigpond","",0,0Yours may respond differently, according to your contract.
#!/usr/bin/python
import sys, struct
# existing USB ID reference in module
usb_id_old = struct.pack('@HH', 0x413c, 0x8115)
# replacement USB ID for Maxon USB BP3
usb_id_new = struct.pack('@HH', 0x16d8, 0x6280)
# read the old module file
old = file(sys.argv[1], 'rb').read()
# find and replace the string
new = old.replace(usb_id_old, usb_id_new, 1)
if new == old:
print "no change made"
sys.exit(1)
# write a new copy of the file
file(sys.argv[1] + '.modified', 'wb').write(new)
There is a false belief that a remote IP address for the link needs to be known.
This stems from an assumption that the link operates with MAC addressing.
This can be disproved with tcpdump or wireshark, the remote IP address is never seen on the data stream once IPCP completes. Packets transmitted over the link have the target IP address.
If it was operated as Ethernet, it would be quite different ... with shared media links the Ethernet encapsulation has to have a destination MAC address that corresponds to the router through which the packets are to be forwarded. So a packet is Ethernet-addressed to a router, but IP-addressed to the target. The router receives the packet, readdresses it in the Ethernet headers, and forwards it on otherwise unchanged, unless it has to do NAT.
I've heard and seen that Windows systems show point to point links as if they are Ethernet adaptors ... and I shake my head in confusion. Linux point to point links are different: the remote IP address has no use, and I find everything works fine without it.
Anthony Wesley has contributed a script to demonstrate, but note that the script also includes usbserial configuration, rather than airprime patching.
pppd options in effect: debug # (from /etc/ppp/peers/3g) updetach # (from command line) unit 9 # (from /etc/ppp/peers/3g) dump # (from command line) noauth # (from /etc/ppp/peers/3g) refuse-chap # (from /etc/ppp/peers/3g) user dors # (from /etc/ppp/peers/3g) /dev/ttyUSB3 # (from /etc/ppp/peers/3g) 230400 # (from /etc/ppp/peers/3g) lock # (from /etc/ppp/options) connect /usr/sbin/chat -v -f /etc/chatscripts/3g # (from /etc/ppp/peers/3g) crtscts # (from /etc/ppp/options) modem # (from /etc/ppp/options) asyncmap 0 # (from /etc/ppp/options) lcp-echo-failure 4 # (from /etc/ppp/options) lcp-echo-interval 30 # (from /etc/ppp/options) hide-password # (from /etc/ppp/peers/3g) ipparam 3g # (from /etc/ppp/peers/3g) noipdefault # (from /etc/ppp/peers/3g) defaultroute # (from /etc/ppp/peers/3g) proxyarp # (from /etc/ppp/options) noccp # (from /etc/ppp/peers/3g) noipx # (from /etc/ppp/options) Serial connection established. using channel 12 Using interface ppp9 Connect: ppp9 <--> /dev/ttyUSB3 sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x31d9de19> <pcomp> <accomp>] rcvd [LCP ConfReq id=0x21 <asyncmap 0x0> <auth chap MD5> <magic 0xf395783b> <pcomp> <accomp>] sent [LCP ConfNak id=0x21 <auth pap>] rcvd [LCP ConfAck id=0x1 <asyncmap 0x0> <magic 0x31d9de19> <pcomp> <accomp>] rcvd [LCP ConfReq id=0x22 <asyncmap 0x0> <auth pap> <magic 0xf395783b> <pcomp> <accomp>] sent [LCP ConfAck id=0x22 <asyncmap 0x0> <auth pap> <magic 0xf395783b> <pcomp> <accomp>] sent [LCP EchoReq id=0x0 magic=0x31d9de19] sent [PAP AuthReq id=0x1 user="dors" password=<hidden>] rcvd [LCP DiscReq id=0x23 magic=0xf395783b] rcvd [LCP EchoRep id=0x0 magic=0xf395783b 31 d9 de 19] rcvd [PAP AuthAck id=0x1 ""] PAP authentication succeeded sent [IPCP ConfReq id=0x1 <compress VJ 0f 01> <addr 0.0.0.0>] rcvd [IPCP ConfNak id=0x1 <ms-dns1 10.11.12.13> <ms-dns3 10.11.12.14> <ms-wins 10.11.12.13> <ms-wins 10.11.12.14>] sent [IPCP ConfReq id=0x2 <compress VJ 0f 01> <addr 0.0.0.0>] rcvd [IPCP ConfNak id=0x2 <ms-dns1 10.11.12.13> <ms-dns3 10.11.12.14> <ms-wins 10.11.12.13> <ms-wins 10.11.12.14>] sent [IPCP ConfReq id=0x3 <compress VJ 0f 01> <addr 0.0.0.0>]Things tried ... novj, noipdefault, noip, ipcp-accept-remote, ipcp-accept-local, and setting an ip address manually for either end of the link.
Dany tells me the solution is to use a different number, provided by Bigpond wireless technical support. I'm asking Maxon about that. Standby.
Also, it seems Mondays are a bad morning for web surfing with this service ... on the 15th, 22nd, and 29th, the service seems very resistant to completing web page viewing. Other aspects of the symptom are that some sites work fine, but some do not. A ping of bigpond.com yields 50% loss, every odd numbered packet is not returned.
I've already found that the HTTP requests from the service to the internet are translated to multiple IP source addresses ... that is if you are seen by a web server from one particular IP, the next time you load the page chances are you will be seen as coming from a different IP, but in the same general range. To me this suggests a distributed transparent proxy ... and one of the paths goes bad.
usb 1-2: new full speed USB device using uhci_hcd and address 2 usb 1-2: configuration #1 chosen from 1 choice usbcore: registered new interface driver usbserial drivers/usb/serial/usb-serial.c: USB Serial support registered for generic usbcore: registered new interface driver usbserial_generic drivers/usb/serial/usb-serial.c: USB Serial Driver core drivers/usb/serial/usb-serial.c: USB Serial support registered for airprime airprime 1-2:1.0: airprime converter detected usb 1-2: airprime converter now attached to ttyUSB0 usb 1-2: airprime converter now attached to ttyUSB1 usb 1-2: airprime converter now attached to ttyUSB2 airprime 1-2:1.1: airprime converter detected usb 1-2: airprime converter now attached to ttyUSB3 usb 1-2: airprime converter now attached to ttyUSB4 usb 1-2: airprime converter now attached to ttyUSB5 airprime 1-2:1.2: airprime converter detected usb 1-2: airprime converter now attached to ttyUSB6 usb 1-2: airprime converter now attached to ttyUSB7 usb 1-2: airprime converter now attached to ttyUSB8 usbcore: registered new interface driver airprimeAgain /dev/ttyUSB3 is the device to tell pppd to use.
The airprime patch is quite simple ...
CONFIG_USB_SERIAL_AIRPRIME=m
diff -ru linux-2.6.19.2/drivers/usb/serial/airprime.c linux-2.6.19.2-maxon/drivers/usb/serial/airprime.c
--- linux-2.6.19.2/drivers/usb/serial/airprime.c 2006-11-30 08:57:37.000000000 +1100
+++ linux-2.6.19.2-maxon/drivers/usb/serial/airprime.c 2007-01-25 08:23:02.000000000 +1100
@@ -20,6 +20,7 @@
{ USB_DEVICE(0x0c88, 0x17da) }, /* Kyocera Wireless KPC650/Passport */
{ USB_DEVICE(0x1410, 0x1110) }, /* Novatel Wireless Merlin CDMA */
{ USB_DEVICE(0x1410, 0x1100) }, /* ExpressCard34 Qualcomm 3G CDMA */
+ { USB_DEVICE(0x16d8, 0x6280) }, /* Maxon BP3-USB 3G Bigpond Telstra */
{ },
};
MODULE_DEVICE_TABLE(usb, id_table);
The existing sierra.ko module does not detect the device.
So I added the device vendor ID and product ID to the sierra.c source, rebuilt the kernel, and now it works to 3.6 megabits per second. You will get /dev/ttyUSB0 through to /dev/ttyUSB8 created, but it is /dev/ttyUSB3 that should be used. I may work to figure out why.
Here is the patch. I've sent it to the driver author.
CONFIG_USB_SERIAL_SIERRAWIRELESS=m
--- linux-2.6.19.2/drivers/usb/serial/sierra.c 2006-11-30 08:57:37.000000000 +1100
+++ linux-2.6.19.2-maxon/drivers/usb/serial/sierra.c 2007-01-24 10:36:24.000000000 +1100
@@ -44,6 +44,7 @@
{ USB_DEVICE(0x1199, 0x0112) }, /* Sierra Wireless AirCard 580 */
{ USB_DEVICE(0x0F3D, 0x0112) }, /* AirPrime/Sierra PC 5220 */
+ { USB_DEVICE(0x16d8, 0x6280) }, /* Maxon BP3-USB 3G Bigpond Telstra */
{ }
};
MODULE_DEVICE_TABLE(usb, id_table);
@@ -65,6 +66,7 @@
{ USB_DEVICE(0x1199, 0x6804) }, /* Sierra Wireless MC8755 for Europe */
{ USB_DEVICE(0x1199, 0x6812) }, /* Sierra Wireless MC8775 */
{ USB_DEVICE(0x1199, 0x6820) }, /* Sierra Wireless AirCard 875 */
+ { USB_DEVICE(0x16d8, 0x6280) }, /* Maxon BP3-USB 3G Bigpond Telstra */
{ }
};
The modem has a USB series "A" plug and an antenna socket. The firmware claims USB 1.1 specification compliance. No USB logo is present. The lsusb output (see end of page) implies that CDC ACM is not supported.
The modem may not be immediately recognised by the kernel, because the vendor and product code are not in the list. Until that is fixed, use usbserial. Quozl has submitted a patch for usb.ids.
(tested on this distribution, and it worked, and since most of the functionality is part of the kernel and PPP program, expect it to work on other recent distributions)
(tested on these versions, and it worked, tests haven't been attempted on other kernel versions yet, reports welcome to quozl@us.netrek.org)
(you need this package to establish an internet connection)
(these packages make configuration much easier)
The red power symbol light on the modem should turn on. Shortly after, the blue signal light should begin to indicate the received signal strength. The kernel should detect the new device on the bus, look at dmesg, for example:
ohci_hcd 0000:00:03.2: wakeup usb 3-1: new full speed USB device using ohci_hcd and address 2 usb 3-1: configuration #1 chosen from 1 choice
# lsusb
Bus 004 Device 001: ID 0000:0000 Bus 002 Device 001: ID 0000:0000 Bus 003 Device 002: ID 16d8:6280 Bus 003 Device 001: ID 0000:0000 Bus 001 Device 001: ID 0000:0000# lsusb -v
... iManufacturer 1 CMOTECH CO., LTD. iProduct 2 CMOTECH CDMA Technologies ...
insmod /lib/modules/`uname -r`/kernel/\ drivers/usb/serial/usbserial.ko \ vendor=0x16d8 product=0x6280This may result in the following dmesg output:
usbcore: registered new driver usbserial drivers/usb/serial/usb-serial.c: USB Serial support registered for generic usbserial_generic 3-1:1.0: generic converter detected usb 3-1: generic converter now attached to ttyUSB0 usbserial_generic 3-1:1.1: generic converter detected usb 3-1: generic converter now attached to ttyUSB1 usbserial_generic 3-1:1.2: generic converter detected usb 3-1: generic converter now attached to ttyUSB2 usbcore: registered new driver usbserial_generic drivers/usb/serial/usb-serial.c: USB Serial Driver coreNote that three device nodes are created, only ttyUSB1 was found to respond to AT commands. The purpose of the other two nodes remains unknown.
options usbserial vendor=0x16d8 product=0x6280 usbserial
pppd noauth nodetach /dev/ttyUSB1 user '' \ connect '/usr/sbin/chat ABORT BUSY ABORT "NO CARRIER" "" ATZ OK ATDT*99# CONNECT'
then click OK to commit the account,
click on New to create a modem, then in the modem pane, in the Device tab set the Modem device to /dev/ttyUSB1, like so:
and in the Modem tab turn off Wait for dial tone before dialing, like so:
then click OK to create the modem,
| Option | Value |
|---|---|
| Manually Select Modem Port | /dev/ttyUSB1 |
| Number | *99# |
| User | anything |
| Password | anything |
| Speed | 460800 (or 230400, makes no difference) |
This created two configuration files, /etc/ppp/peers/name and /etc/chatscripts/name, where name is the name you set for the connection.
Start the connection the first time using pon updetach debug dump.
This generates lots of information, just in case something goes wrong and you want to work out why. It isn't necessary to do it every time. The updetach option makes PPP wait until the connection is established before finishing the command. The debug and dump options are described in the manual page for pppd(8).
Test internet access, e.g. using a web browser or mail client, and when you're finished turn it off using the command poff.
If it all worked, in future start the connection using pon, stop it using poff.
| Date | Change |
|---|---|
| 2008-01-16 | Add instructions for making the insmod happen each boot. |
| 2008-01-15 | Add replacedefaultroute. Fixed the 2006 dates in this log to be 2007. |
| 2007-06-02 | Added a rant about the remote IP address of the link not being needed. |
| 2007-04-24 | Replaced the sample log with a recent working example. |
| 2007-03-06 | Paul Gampe reports the alternate number does not work for the IPCP problem in his case. |
| 2007-03-05 | Reworked initial summary, and tabulated known problems. |
| 2007-02-28 | Another workaround for obtaining an IP address is reported, using a script to discover the gateway using traceroute |
| 2007-01-31 | A workaround for obtaining an IP address is reported, using an alternate telephone number. |
| 2007-01-29 | A problem obtaining an IP address is reported. |
| 2007-01-25 | Author of Sierra Wireless module says to use the airprime module. |
| 2007-01-24 | The Sierra Wireless module is discovered as one solution to the low bitrate problem. |
| 2007-01-12 | Username and password normally required, but my test USIM did not need it. |
| 2007-01-02 | Initial write-up |
Bus 001 Device 004: ID 16d8:6280
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.10
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x16d8
idProduct 0x6280
bcdDevice 0.00
iManufacturer 1 CMOTECH CO., LTD.
iProduct 2 CMOTECH CDMA Technologies
iSerial 4 Serial Number
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 173
bNumInterfaces 3
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xa0
(Bus Powered)
Remote Wakeup
MaxPower 500mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 3
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 255 Vendor Specific Subclass
bInterfaceProtocol 255 Vendor Specific Protocol
iInterface 3 Data Interface
Class specific interface descriptor for class 255 is unsupported
Class specific interface descriptor for class 255 is unsupported
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x85 EP 5 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0010 1x 16 bytes
bInterval 128
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x03 EP 3 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 3
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 255 Vendor Specific Subclass
bInterfaceProtocol 255 Vendor Specific Protocol
iInterface 3 Data Interface
Class specific interface descriptor for class 255 is unsupported
Class specific interface descriptor for class 255 is unsupported
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0010 1x 16 bytes
bInterval 128
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 2
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 255 Vendor Specific Subclass
bInterfaceProtocol 255 Vendor Specific Protocol
iInterface 3 Data Interface
Class specific interface descriptor for class 255 is unsupported
Class specific interface descriptor for class 255 is unsupported
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x84 EP 4 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x04 EP 4 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Device Status: 0x0000
(Bus Powered)
# pon bpw
Serial connection established. using channel 1 Using interface ppp9 Connect: ppp9 <--> /dev/ttyUSB3 sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x4dc1175a> <pcomp> <accomp>] rcvd [LCP ConfReq id=0x0 <asyncmap 0x0> <auth chap MD5> <magic 0x80df4fff> <pcomp> <accomp>] sent [LCP ConfAck id=0x0 <asyncmap 0x0> <auth chap MD5> <magic 0x80df4fff> <pcomp> <accomp>] rcvd [LCP ConfAck id=0x1 <asyncmap 0x0> <magic 0x4dc1175a> <pcomp> <accomp>] sent [LCP EchoReq id=0x0 magic=0x4dc1175a] rcvd [LCP DiscReq id=0x1 magic=0x80df4fff] rcvd [CHAP Challenge id=0x1 <34719deadbeefdeadbeef8119cfadb91>, name = "UMTS_CHAP_SRVR"] sent [CHAP Response id=0x1 <ec947deadbeefdeadbeef66c16dd4906>, name = "username@bigpond.com"] rcvd [LCP EchoRep id=0x0 magic=0x80df4fff 4d c1 17 5a] rcvd [CHAP Success id=0x1 ""] CHAP authentication succeeded CHAP authentication succeeded sent [IPCP ConfReq id=0x1 <compress VJ 0f 01> <addr 0.0.0.0>] rcvd [IPCP ConfNak id=0x1 <ms-dns1 10.11.12.13> <ms-dns3 10.11.12.14> <ms-wins 10.11.12.13> <ms-wins 10.11.12.14>] sent [IPCP ConfReq id=0x2 <compress VJ 0f 01> <addr 0.0.0.0>] rcvd [IPCP ConfNak id=0x2 <ms-dns1 10.11.12.13> <ms-dns3 10.11.12.14> <ms-wins 10.11.12.13> <ms-wins 10.11.12.14>] sent [IPCP ConfReq id=0x3 <compress VJ 0f 01> <addr 0.0.0.0>] rcvd [IPCP ConfNak id=0x3 <ms-dns1 10.11.12.13> <ms-dns3 10.11.12.14> <ms-wins 10.11.12.13> <ms-wins 10.11.12.14>] sent [IPCP ConfReq id=0x4 <compress VJ 0f 01> <addr 0.0.0.0>] rcvd [IPCP ConfReq id=0x0] sent [IPCP ConfNak id=0x0 <addr 0.0.0.0>] rcvd [IPCP ConfRej id=0x4 <compress VJ 0f 01>] sent [IPCP ConfReq id=0x5 <addr 0.0.0.0>] rcvd [IPCP ConfNak id=0x5 <addr 58.170.183.213>] sent [IPCP ConfReq id=0x6 <addr 58.170.183.213>] rcvd [IPCP ConfAck id=0x6 <addr 58.170.183.213>] rcvd [IPCP ConfReq id=0x1] sent [IPCP ConfAck id=0x1] Could not determine remote IP address: defaulting to 10.64.64.73 Cannot determine ethernet address for proxy ARP local IP address 58.170.183.213 remote IP address 10.64.64.73
