Greetings!
I've just purchased a UM175 USB wireless-broadband adaptor from
Verizon, with Verizon EVDO wireless broadband service, in Boston, MA.
There are many reports on the web of the UM175 being used successfully
with linux, but I haven't been able to get mine to work.
Has anyone experienced similar problems with this device? Any ideas
for work-arounds? For patching the drivers?
Under Windows XP, the device works properly: it uses the manufacture's
(PANTECH's) driver, and shows up as a standard COM port. A ppp connection can be established either using Verizon's software, or using the standard Windows dial-up networking facilities.
Under linux, when trying to start a ppp session, we get as far as
successfully configuring the ppp interface and retrieving DNS server
IP addresses; but then, within usually a second or two, the modem
seems to hang up the line, causing pppd to receive a SIGHUP and exit.
I see the same behaviour under kernels 2.6.10 (with ppd 2.4.1), and
2.6.24.7 and 2.6.29.2 (with pppd 2.4.4). The snippets given below are
from a machine using the 2.6.29.2 kernel and pppd 2.4.4.
My adaptor is labelled as part # "UM175VW." Its /proc/bus/usb/devices
entry is:
T: Bus=07 Lev=01 Prnt=01 Port=02 Cnt=01 Dev#= 3 Spd=12 MxCh= 0
D: Ver= 1.10 Cls=02(comm.) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
P: Vendor=106c ProdID=3714 Rev= 1.00
S: Manufacturer=PANTECH
S: Product=PANTECH USB MODEM
C:* #Ifs= 3 Cfg#= 1 Atr=80 MxPwr=500mA
I:* If#= 0 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=02 Prot=01 Driver=cdc_acm
E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=32ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=cdc_acm
E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
I:* If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none)
E: Ad=84(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
E: Ad=04(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
Sidenote: notice that my adaptor's product ID is 0x3714. Older
versions of the UM175 have product ID 0x3701. Devices with both ProdIDs have been reported to work under linux, using the cdc-acm or the usbserial driver.
When the adaptor is plugged into the computer, the cdc-acm module is
autoloaded, and dmesg reports:
[10078.187270] usb 7-3: new full speed USB device using ohci_hcd and address 4
[10078.376952] usb 7-3: New USB device found, idVendor=106c, idProduct=3714
[10078.376957] usb 7-3: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[10078.376960] usb 7-3: Product: PANTECH USB MODEM
[10078.376963] usb 7-3: Manufacturer: PANTECH
[10078.377079] usb 7-3: configuration #1 chosen from 1 choice
[10078.403299] cdc_acm 7-3:1.0: ttyACM0: USB ACM device
which is all good. When we run:
chat -v -s '' AT OK 'ATE0V1&D2&C1S0=0' OK ATS7=60 \
OK ATS0=0 OK ATDP#777 CONNECT </dev/ttyACM0 >/dev/ttyACM0
echo -e \\nStarting ppp:
pppd updetach debug /dev/ttyACM0
echo -e \\nRouting table immediately after pppd connects:
route -n
We get (skipping the chat output):
Starting ppp:
using channel 32
Using interface ppp0
Connect: ppp0 <--> /dev/ttyACM0
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0xc27f9d7e> <pcomp> <accomp>]
rcvd [LCP ConfReq id=0x27 <mru 1500> <asyncmap 0x0> <magic 0xd075c580> <pcomp> <accomp>]
sent [LCP ConfAck id=0x27 <mru 1500> <asyncmap 0x0> <magic 0xd075c580> <pcomp> <accomp>]
rcvd [LCP ConfAck id=0x1 <asyncmap 0x0> <magic 0xc27f9d7e> <pcomp> <accomp>]
sent [CCP ConfReq id=0x1 <deflate 15> <deflate(old#) 15>]
sent [IPCP ConfReq id=0x1 <compress VJ 0f 01> <addr 0.0.0.0>]
rcvd [LCP DiscReq id=0x28 magic=0xd075c580]
rcvd [IPCP ConfReq id=0xd <addr 66.174.121.64>]
sent [IPCP ConfAck id=0xd <addr 66.174.121.64>]
rcvd [LCP ProtRej id=0x29 80 fd 01 01 00 0c 1a 04 78 00 18 04 78 00]
Protocol-Reject for 'Compression Control Protocol' (0x80fd) received
rcvd [IPCP ConfRej id=0x1 <compress VJ 0f 01>]
sent [IPCP ConfReq id=0x2 <addr 0.0.0.0>]
rcvd [IPCP ConfNak id=0x2 <addr 75.222.27.224>]
sent [IPCP ConfReq id=0x3 <addr 75.222.27.224>]
rcvd [IPCP ConfAck id=0x3 <addr 75.222.27.224>]
local IP address 75.222.27.224
remote IP address 66.174.121.64
Routing table immediately after pppd connects:
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
66.174.121.64 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0
[The 'updetach' option makes pppd detach immediately after it makes its
ppp connection.]
I.e. the ppp connection is established, and the endpoint ip address is
entered into the routing table. Yay!
Sadly, the modem seems consistently to hang itself up within a
fraction of a second after this. When we run:
chat -v -s '' AT OK 'ATE0V1&D2&C1S0=0' OK ATS7=60 \
OK ATS0=0 OK ATDP#777 CONNECT </dev/ttyACM0 >/dev/ttyACM0
echo -e \\nStarting ppp:
pppd nodetach debug usepeerdns /dev/ttyACM0
echo -e \\npppd terminated with exit status $?
We get:
Starting ppp:
using channel 36
Using interface ppp0
Connect: ppp0 <--> /dev/ttyACM0
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0xd4e2ee53> <pcomp> <accomp>]
rcvd [LCP ConfReq id=0x33 <mru 1500> <asyncmap 0x0> <magic 0xd07d0a15> <pcomp> <accomp>]
sent [LCP ConfAck id=0x33 <mru 1500> <asyncmap 0x0> <magic 0xd07d0a15> <pcomp> <accomp>]
rcvd [LCP ConfAck id=0x1 <asyncmap 0x0> <magic 0xd4e2ee53> <pcomp> <accomp>]
sent [CCP ConfReq id=0x1 <deflate 15> <deflate(old#) 15>]
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>]
rcvd [LCP DiscReq id=0x34 magic=0xd07d0a15]
rcvd [IPCP ConfReq id=0x11 <addr 66.174.121.64>]
sent [IPCP ConfAck id=0x11 <addr 66.174.121.64>]
rcvd [LCP ProtRej id=0x35 80 fd 01 01 00 0c 1a 04 78 00 18 04 78 00]
Protocol-Reject for 'Compression Control Protocol' (0x80fd) received
rcvd [IPCP ConfRej id=0x1 <compress VJ 0f 01>]
sent [IPCP ConfReq id=0x2 <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>]
rcvd [IPCP ConfNak id=0x2 <addr 75.223.231.72> <ms-dns1 66.174.95.44> <ms-dns3 66.174.92.14>]
sent [IPCP ConfReq id=0x3 <addr 75.223.231.72> <ms-dns1 66.174.95.44> <ms-dns3 66.174.92.14>]
rcvd [IPCP ConfAck id=0x3 <addr 75.223.231.72> <ms-dns1 66.174.95.44> <ms-dns3 66.174.92.14>]
local IP address 75.223.231.72
remote IP address 66.174.121.64
primary DNS address 66.174.95.44
secondary DNS address 66.174.92.14
Modem hangup
Connect time 0.0 minutes.
Sent 0 bytes, received 0 bytes.
Connection terminated.
pppd terminated with exit status 16
Exit status 16 means (per 'man pppd') "The link was terminated by the
modem hanging up."
The /var/log/messages output is:
May 20 22:34:22 fs pppd[4256]: pppd 2.4.4 started by root, uid 0
May 20 22:34:22 fs pppd[4256]: Using interface ppp0
May 20 22:34:22 fs pppd[4256]: Connect: ppp0 <--> /dev/ttyACM0
May 20 22:34:22 fs pppd[4256]: local IP address 75.222.203.140
May 20 22:34:22 fs pppd[4256]: remote IP address 66.174.121.64
May 20 22:34:22 fs pppd[4256]: primary DNS address 66.174.95.44
May 20 22:34:22 fs pppd[4256]: secondary DNS address 66.174.92.14
May 20 22:34:23 fs pppd[4256]: Modem hangup
May 20 22:34:23 fs pppd[4256]: Connect time 0.1 minutes.
May 20 22:34:23 fs pppd[4256]: Sent 0 bytes, received 0 bytes.
May 20 22:34:23 fs pppd[4256]: Connection terminated.
May 20 22:34:24 fs pppd[4256]: Exit.
If we start pppd without the 'nodetach' option, it reports in
/var/log/messages that it receives a SIGHUP immediately before the
"Modem hangup" message. [The cdc-acm driver sends a SIGHUP in
response to the modem hanging up.]
By the way, the Hayes modem-initialization codes shown above are the
ones that are used when the device works properly under Windows:
they were found by using a USB sniffer on a Windows machine.
I have tried the following, none of which affect the above-described
behaviour:
- Almost all imaginable pppd options. :-)
The 'speed,' 'user,' and 'name' options have no effect.
[These also have no effect when the device is working properly
under Windows XP. Apparently, Verizon does not perform
PAP authentication on these broadband wireless connections.]
- Many Hayes AT-command initialization sequences, found on the web,
that are reported to work with other UM175s
- Removing all scripts from /etc/ppp, in case they're causing problems
- Running in single-user mode, with barely any daemons running
- Using the usbserial driver instead of the cdc-acm driver,
and using the 'local' option for pppd. Both of these cause pppd
not to be able to detect a modem hangup. In these cases, pppd
happily stops, leaving the ppp0 device present, but ppp0 does not
function. This is consistent with the modem having hung itself up.
After all of this, I'm inclined to think that I have a newer revision
of the UM175 that simply doesn't work properly with the cdc-acm or
usbserial drivers. I'd be glad to do some work patching the drivers,
but I fear that it might be a bottomless reverse-engineering pit. It
would be fabulous if I'm just missing something stupid. Any ideas?
This is my first post to linuxquestion.org. I apologize if it's too
long. Thank you all for reading this far! Suggestions on helpful posting strategies are welcome.
Many thanks!
Sincerely,
Your obedient Pirate King
