Re: Network manager auto-upgraded, ppp no longer connects.
- From: "A. F. Cano" <afc shibaya lonestar org>
- To: Dan Williams <dcbw redhat com>
- Cc: networkmanager-list gnome org
- Subject: Re: Network manager auto-upgraded, ppp no longer connects.
- Date: Sat, 14 Jan 2017 15:57:37 -0500
On Fri, Jan 13, 2017 at 12:11:38PM -0600, Dan Williams wrote:
...
Ok, did that and now ModemManager is writing thousands of lines to
syslog. What seems relevant is this:
Jan 12 13:33:56 fbx ModemManager[315]: <debug> Got failure code 100:
Unknown error
I think these are not the critical issue. After all MM/NM could connect
before December 30.
These also seem relevant:
Jan 12 13:34:10 fbx ModemManager[315]: <debug> User: unspecified
Jan 12 13:34:10 fbx ModemManager[315]: <debug> Password:
unspecified
Jan 12 13:34:10 fbx ModemManager[315]: <debug> Number: #777
Not sure how/why the user and password are unspecified, they are set
in
the connection description (qnc).
Is it normal that the user name and password are not set at this stage?
This seems to me to be a more likely cause of the problem.
The following seem contradictory, it seems that the regiestration
checks
don't stick.
Jan 12 13:34:22 fbx ModemManager[315]: <debug> Not registered in any
CDMA network
Jan 12 13:34:22 fbx ModemManager[315]: <debug> All CDMA registration
state checks done
Jan 12 13:34:22 fbx ModemManager[315]: <debug> (ttyACM0) device open
count is 1 (close)
Jan 12 13:34:22 fbx ModemManager[315]: <debug> Modem not yet
registered in a CDMA network... will recheck soon
Jan 12 13:34:25 fbx ModemManager[315]: <debug> Running registration
checks (CDMA1x: 'yes', EV-DO: 'yes')
Jan 12 13:34:25 fbx ModemManager[315]: <debug> Will skip all QCDM-
based registration checks
Ok, so it's a "Motorola e815" phone. It seems the device doesn't
support some common AT commands for CDMA, or the device is registered
Not surprising given that this device is one of the most crippled
devices ever made. It was sold as a top-of-the-line device but then
I (and everyone else) started finding out that this and that feature
had been disabled by Verizon.
on EVDO which AT+CSS doesn't necessarily report. ModemManager would
need to be updated for this device.
Still, if MM/NM could be made to behave as before December 30 or so it
would be sufficient.
Could you run "lsusb -v -d 22b8:2a62" for me? It may be that kernel
drivers don't know about other ports the phone provides, which may
prevent ModemManager from reading some device status.
Ok, here goes:
$ sudo lsusb -v -d 22b8:2a62
Bus 004 Device 009: ID 22b8:2a62 Motorola PCS E815 GSM Phone (AT)
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.10
bDeviceClass 2 Communications
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x22b8 Motorola PCS
idProduct 0x2a62 E815 GSM Phone (AT)
bcdDevice 0.01
iManufacturer 1 Motorola, Inc.
iProduct 2 Motorola E815
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 67
bNumInterfaces 2
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xc0
Self Powered
MaxPower 20mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 2 Communications
bInterfaceSubClass 2 Abstract (modem)
bInterfaceProtocol 1 AT-commands (v.25ter)
iInterface 3 Motorola Communication Interface
CDC Header:
bcdCDC 1.09
CDC Call Management:
bmCapabilities 0x03
call management
use DataInterface
bDataInterface 1
CDC ACM:
bmCapabilities 0x0f
connection notifications
sends break
line coding and serial state
get/set/clear comm features
CDC Union:
bMasterInterface 0
bSlaveInterface 1
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 32
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 10 CDC Data
bInterfaceSubClas 0 Unused
bInterfaceProtocol 0
iInterface 3 Motorola Communication Interface
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
Device Status: 0x0000
(Bus Powered)
Could you run the following commands for me on ttyACM0 after stopping
ModemManager, using something like "minicom -D /dev/ttyACM0"? Then
copy & paste the responses to a reply and we'll see if we can find out
what we need:
AT&V
&C: 1; &D: 2; &F: 0; E: 0; L: 0; M: 0; Q: 0; V: 1; X: 4; Z: 0; S0: 0;
S3: 13; S4: 10; S5: 8; S6: 2; S7: 50; S8: 2; S9: 6; S10: 14; S11: 95;
+FCLASS: 0; +ICF: 3,3; +IFC: 1,1; +IPR: 19200; +DR: 0; +DS: 0,0,2048,6;
+MODE: 0; +CDR: 0; +CDS: 0,1,2048,6; +CFC: 0; +CFG: ""; +CMUX: C,2;
+CQD: 10; +CRC: 0; +CRM: 2; +CTA: 0; +CXT: 0; +EB: 1,0,30; +EFCS: 1;
+ER: 0; +ES: 3,0,2; +ESR: 1; +ETBM: 1,1,20; +ILRR: 0; +MA: ; +MR: 0;
+MS: ; +MV18R: 0; +MV18S: 0,0,0; +FAA: 0; +FAP: 0,0,0; +FBO: 0; +FBU: 0;
+FCQ: 1,0; +FCC: 0,1,0,0,0,0,0,0; +FCR: 0; +FCT: 1E; +FEA: 0;
+FFC: 0,0,0,0; +FHS: 0; +FIE: 0; +FIP: 0; +FIS: 0,1,0,0,0,0,0,0;
+FLI: ""; +FLO: 1; +FLP: 0; +FMS: 0; +FNR: 0,0,0,0; +FNS: ""; +FPA: "";
+FPI: ""; +FPP: 0; +FPR: 8; +FPS: 1; +FPW: ""; +FRQ: 0,0; +FRY: 0;
+FSA: ""; +FSP: 0
OK
AT+CLAC
ERROR
AT+CIND=?
ERROR
AT+CIND?
ERROR
AT+MODE?
+MODE: 0
OK
AT+MODE=?
+MODE: (0-65355)
OK
I can't seem to find out much about Motorola CDMA-specific AT commands.
I'm not surprised. Verizon keeps most (all?) devices so completely
locked up and crippled that doing anything other than pay them big $$$
for lesser and lesser levels of "service" is just about a lost cause.
Unfortunately I'm stuck with this device for now. Can't find anything
newer that would allow me the same access without changing my plan
(which is obviously what Verizon wants) and paying a lot more.
I would love to be able to do "seem editing" to have some more control
over my phone...
Dan
Thank you very much for helping.
Augustine
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]
