[ltp] Re: Cannot get Ericsson F3507G to work with the Option module
Bjørn Mork
linux-thinkpad@linux-thinkpad.org
Fri, 13 Feb 2009 13:12:58 +0100
Per Dalgas Jakobsen <pdj@knaldgas.dk> writes:
> I seem to have an issue with the "option" module...
>
> When this module is loaded, enabling the F3507G card with
> "echo 1 > /sys/devices/platform/thinkpad_acpi/wwan_enable"
> causes a number of /dev/ttyUSB? to be created.
> None of these seems to be accessible by "cu"
Don't use the "option" module. Adding the F3507g vid/pid to it was
wrong, and it will be removed again. See the discussion starting
with http://article.gmane.org/gmane.linux.usb.general/14422
> If I unload the option module, then it seems like the cdc_acm module takes
> control instead, creating /dev/ttyACM[0-2] when the F3507G is activated.
> These nodes, however, work as expected.
>
> For the moment I have blacklisted the option module, but I'm uncertain if
> this is the right approach.
This is the correct workaround until the option driver is updated.
In addition to the three CDC ACM interfaces, there are two more classes
supported by the F3507g:
CDC Device Management (2 "devices")
CDC Mobile Direct Line (1 "device")
The first is supported by the cdc-wdm driver available in 2.6.29
(haven't checked exactly when it was added, but it is rather new). It
will add two new devices you can send AT commands to /dev/cdc-wdm[01],
but not do any high speed data transfers over. Quite useful, since the
three ACM devices are easily "lost" to GPS, SMS daemon and PPP.
The CDC Mobile Direct Line is actually a masqueraded CDC Ethernet
device. Ericsson has provided a driver which is mostly a copy of
cdc_ether.c. Nice feature to have, but I've not been able to measure
any speed advantages compared to PPP on ttyACM0. Still, fun to play
with :-)
The original Ericsson patch is available from
http://article.gmane.org/gmane.linux.usb.general/12875
Please not that the usbnet changes are only for interface naming and
strictly not necessary if you want to keep the driver isolated.
I've also made a stripped down version of it, just to see how little was
necessary: http://article.gmane.org/gmane.linux.usb.general/14624
The last article also includes the usage instructions, which you'll need
if yout want to test either version. The main clue is the undocumented(?)
AT*ENAP=1,1 command.
I do have an ifupdown script for automating this, but I hesitate to post
it here as it is in no way pretty and reliable enough... Let me know if
you want to have a copy by email. Or if anyone else is interested in
ripping out the interesting parts of it and reimplement it in a
distributable fashion, let me know...
Using it, a typical connection goes like this:
nemi:/tmp# ifup mb0
trying cdc-wdm0
Selected /dev/cdc-wdm0 for management of mb0
*EMRDY: 1
AT+CPIN?
+CPIN: READY
OK
AT*ENAP?
ERROR
AT+CGDCONT?
+CGDCONT: 1,"IP","telenor","0.0.0.0",0,0
+CGDCONT: 2,"IP","test","0.0.0.0",0,0
+CGDCONT: 3,"IP","","0.0.0.0",0,0
OK
AT+CFUN?;*E2CFUN=1;+CGREG=2
+CFUN: 4
Powering on radio
OK
AT+CFUN=1
OK
+CGREG: 0
Not registered
*E2CFUN: 1,1,0
Powered on (auto mode)
+CGREG: 0
Not registered
*EMWI: 1,0
+PACSP0
+CGREG: 1,"36B1","0000095E",3
Registered to home network
AT*ENAP=1,3;*E2NAP=1;+CMEE=2
OK
*E2NAP: 1
Connected
Internet Systems Consortium DHCP Client V3.1.1
Copyright 2004-2008 Internet Systems Consortium.
All rights reserved.
For info, please visit http://www.isc.org/sw/dhcp/
wmaster0: unknown hardware address type 801
wmaster0: unknown hardware address type 801
Listening on LPF/mb0/02:80:37:ec:02:00
Sending on LPF/mb0/02:80:37:ec:02:00
Sending on Socket/fallback
DHCPDISCOVER on mb0 to 255.255.255.255 port 67 interval 3
DHCPOFFER from 77.16.175.249
DHCPREQUEST on mb0 to 255.255.255.255 port 67
DHCPACK from 77.16.175.249
bound to 77.16.175.250 -- renewal in 131 seconds.
nemi:/tmp# ifdown mb0
There is already a pid file /var/run/dhclient.mb0.pid with pid 681
killed old client process, removed PID file
Internet Systems Consortium DHCP Client V3.1.1
Copyright 2004-2008 Internet Systems Consortium.
All rights reserved.
For info, please visit http://www.isc.org/sw/dhcp/
wmaster0: unknown hardware address type 801
wmaster0: unknown hardware address type 801
Listening on LPF/mb0/02:80:37:ec:02:00
Sending on LPF/mb0/02:80:37:ec:02:00
Sending on Socket/fallback
DHCPRELEASE on mb0 to 77.16.175.249 port 67
trying cdc-wdm0
Selected /dev/cdc-wdm0 for management of mb0
+CGREG: 1,"36B1","00CBB5FA",2
+CGREG: 1,"4F4D","00CBB5FA",2
AT*ENAP?
*ENAP: 1
OK
AT*ENAP=0;*E2NAP=1;*E2CFUN=1
OK
*E2NAP: 0
Disconnected
Powering down radio
AT+CFUN=4
OK
*E2CFUN: 1,4,0
Radio is off
nemi:/tmp#
Bjørn
--
return -ENOCOFFEE;