logo

Could not compile stylesheet for simplistic. Using last compiled stylesheet.
Issue

USB communication problem with a 3G module

posted in IGEPv2
Monday, April 20 2015, 07:22 PM
0
Hi,

We work on a USB communication problem that we get between the USB port type A of the IGEPv2 board and a 3G module (Teleorigin RB800U, modem Telit UL865). When the problem occurs, AT commands write fails with a timeout on the serial communication (related to a USB response timeout), and even could lead to block the connexion.
We activated USB debug logs in Linux kernel (2.6.37), and when AT command fails, i got the dmesg log attached.

In first analysis, it could be observed errors in ehci driver:
ehci-omap ehci-omap.0: detected XactErr len 0/1024 retry 1

And when this error log starts, i notice some interesting logs of throughput changing in usb hub driver (480Mbps -> 12Mbps -> 480Mbps):
[35038.831604] hub 1-0:1.0: state 7 ports 3 chg 0000 evt 0002
[35038.831634] ehci-omap ehci-omap.0: GetStatus port:1 status 001002 0 ACK POWER sig=se0 CSC
[35038.831665] hub 1-0:1.0: port 1, status 0100, change 0001, 12 Mb/s
[35038.831695] usb 1-1: USB disconnect, address 4

[35039.157318] ehci-omap ehci-omap.0: devpath 1 ep0in 3strikes
[35039.218292] ehci-omap ehci-omap.0: GetStatus port:1 status 001002 0 ACK POWER sig=se0 CSC
[35039.218322] ehci-omap ehci-omap.0: port 1 cannot be enabled
[35039.224121] ehci-omap ehci-omap.0: Maybe your device is not a high speed device?
[35039.231842] ehci-omap ehci-omap.0: USB host (EHCI) controller does not support full speed or low speed device on it's root port.
[35039.243896] ehci-omap ehci-omap.0: Please connect full/low speed device via a high speed hub.
[35039.252777] hub 1-0:1.0: unable to enumerate USB device on port 1
[35039.259124] hub 1-0:1.0: state 7 ports 3 chg 0000 evt 0002
[35039.318206] hub 1-0:1.0: state 7 ports 3 chg 0000 evt 0002
[35039.318237] ehci-omap ehci-omap.0: GetStatus port:1 status 001803 0 ACK POWER sig=j CSC CONNECT
[35039.318267] hub 1-0:1.0: port 1, status 0501, change 0001, 480 Mb/s
[35039.468292] hub 1-0:1.0: debounce: port 1: total 100ms stable 100ms status 0x501
[35039.530761] ehci-omap ehci-omap.0: port 1 high speed

In second analysis, we found some useful information in forum:
http://comments.gmane.org/gmane.linux.usb.general/70083
http://forums.synapse-wireless.com/archive/index.php/t-4753.html
http://www.at91.com/discussions/viewtopic.php/f,9/t,5600/
http://comments.gmane.org/gmane.linux.usb.general/56591

And this hardware note:
"clock settings for USB block give 0.16% of clock error. To the error we
need to add oscillator error (eg. capacitance load of crystal) and jitter,
and PLL jitter. USB tolerates 0.252% for full speed (0.21ns / bit). For HUB
full speed allowed is 1ns, ie. even 1.2%."

Could you check the oscillator settings on the IGEPv2 with Linux corresponding to USB usage please?
Would there be some interesting actions to execute on IGEPv2 board to fix the USB problem we have please?

We are using kernel 2.6.37, from Poky distribution delivered by ISEE for IGEPv2.

Thanks in advance for your help,

Regards,
Simon Andrieu
Attachments:
Responses (21)
  • Accepted Answer

    mcaro
    mcaro
    Offline
    Tuesday, April 21 2015, 10:08 AM - #permalink
    0
    Dear Simon,

    This is a DM3730 processor known bug Advisory 2.1 page 110

    This issue was minimized with the workaround described in the document and applied in our kernel with this commit.

    Probably you're using a previous kernel version due our poky release uses kernel 2.6.37-8 and just this patch was released after that.

    I suggest you upgrade the kernel to 2.6.37-10 (it's the last one) ...

    Thanks & Cheers
    Manel
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, April 21 2015, 11:42 AM - #permalink
    0
    Hi,

    Thanks for these useful informations, we are going to work on upgrading our IGEPv2 distribution to Linux kernel 2.6.37-10.

    We also meet this USB problem using the USB 2 OTG port. As I see that this patch concerns EHCI USB that is related to USB 1 type A, would this patch also correct this problem on USB OTG?

    Thanks for your help.

    Regards,
    Simon
    The reply is currently minimized Show
  • Accepted Answer

    mcaro
    mcaro
    Offline
    Tuesday, April 21 2015, 12:57 PM - #permalink
    0
    Do you found this issue in the OTG ?

    Manel
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, April 21 2015, 01:14 PM - #permalink
    0
    We first connected the modem on the USB OTG port and had this connexion issue.
    We changed to USB 1 type A to check if the behavior was better, and had again the same issue. Then we activated USB debug on kernel, and get the log of the issue with an USB 1 type A connexion.

    As we have now several installation sites with modem connected through USB OTG port, i would like to know please if the patch you indicated would also help to fix this connexion issue using the USB OTG port.
    Maybe there would be some other patches or specific actions to execute concerning this USB OTG issue?

    Thanks for your help.

    Regards,
    Simon
    The reply is currently minimized Show
  • Accepted Answer

    mcaro
    mcaro
    Offline
    Tuesday, April 21 2015, 04:32 PM - #permalink
    0
    Please post the debug kernel log related to the OTG ... the patch only affect to PLL5 drift that is used as USB host main clock so I'm not sure but I guess no, it not fix the issue in the OTG ...

    Regards

    Manel
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, April 21 2015, 05:09 PM - #permalink
    0
    I will try to get debug kernel log also with modem connected on USB OTG, and then send it.

    As we use the USB OTG port in host side, maybe the patch would then apply also on this port?

    Kernel upgrade to 2.6.37-10: we have started working on compiling Poky with kernel 2.6.37-10, and with getting meta-isee layer, we see that the latest commit refer to 2.6.37-8.
    Could you help us to know the method to upgrade meta-isee to 2.6.37-10 please?

    Thanks,
    Simon
    The reply is currently minimized Show
  • Accepted Answer

    mcaro
    mcaro
    Offline
    Tuesday, April 21 2015, 05:37 PM - #permalink
    0
    As we use the USB OTG port in host side, maybe the patch would then apply also on this port?

    USB Host and USB OTG uses a different controllers and clocks too ... you can check if the issue is minimized in the OTG but probably not due PLL5 is only used by USB Host. I guess the debug info can help us to check what is the issue related to the OTG ...

    Could you help us to know the method to upgrade meta-isee to 2.6.37-10 please?


    Yes I'm not the expert about yocto but I will try to help you, go to our git at this address:

    http://git.isee.biz/?p=pub/scm/meta-isee.git;a=shortlog;h=refs/heads/denzil

    this is the last patch:

    http://git.isee.biz/?p=pub/scm/meta-isee.git;a=commit;h=85dcee5012873cee30a76479265a973db6d3216d

    and this is the diff patch:

    --- a/recipes-kernel/linux/linux-igep_2.6.37.bb
    +++ b/recipes-kernel/linux/linux-igep_2.6.37.bb
    @@ -8,13 +8,13 @@ COMPATIBLE_MACHINE_igep00x0 = "igep00x0"
     
     inherit kernel kernel-arch
     
    -PR = "r7"
    -KV = "${PV}-7"
    +PR = "r8"
    +KV = "${PV}-8"
     
     SRC_URI = "http://downloads.isee.biz/pub/releases/linux_kernel/v${KV}/linux-omap-${KV}.tar.gz"
     
    -SRC_URI[md5sum] = "4a5392c11c06e3eeb165a378165903f6"
    -SRC_URI[sha256sum] = "5e2e2c35457b77d1ecd3340f6db97fc1a9f3c660fbdfe308aef82b7ff4a89df3"
    +SRC_URI[md5sum] = "87026aaa2901a39a7ce87021175d23b3"
    +SRC_URI[sha256sum] = "0faa4327b3601878d3220a2deb3e1360fb42de6840f53b44157ba753e3ab7a08"
     
     do_configure() {
            rm -f ${S}/.config || true
    


    Change the r8 to r10 probably you need to sha256sum and md5sum the file and update the values in the recipe ...

    and modify this too:

    +KV = "${PV}-10"

    Regards

    Manel
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, April 21 2015, 06:36 PM - #permalink
    0
    Thanks for the method on how to upgrade meta-isee layer to 2.6.37-10 kernel.
    We checked the following dev branch on which 2.6.37-10 kernel is already upgraded: http://git.isee.biz/?p=pub/scm/meta-isee.git;a=shortlog;h=refs/heads/denzil-next
    Could you confirm if this branch is stable please? If yes, we would use the latest commit of this branch to synchronize on a meta-isee layer based on the 2.6.37-10 kernel.
    Otherwise, could you indicate us a stable meta-isee version/commit containing 2.6.37-10 kernel to synchronize on please?

    Thanks in advance,
    Simon
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, April 23 2015, 05:20 PM - #permalink
    0
    Hi,

    As for now rebase to kernel 2.6.37-10 would be too much work, we decided to apply this commit that you mentioned, on the 2.6.37-7 kernel that we use with our Poky/ISEE based distribution.

    From there, i made some new tests and had a USB connexion failure on OTG port (i have different test setups with USB Host and USB OTG).
    I attach the USB system logs (lsusb -v, dmesg) concerning this OTG failure to this thread.

    I can observe various failing logs when the failure occurs:
    ...
    [ 2347.252166] musb_stage0_irq 842: unhandled DISCONNECT transition (a_wait_bcon)
    [ 2347.910888] hub 2-0:1.0: state 7 ports 1 chg 0000 evt 0002
    [ 2347.910919] hub 2-0:1.0: port 1, status 0101, change 0001, 12 Mb/s
    [ 2347.910949] usb 2-1: USB disconnect, address 4
    [ 2347.915557] usb 2-1: unregistering device
    [ 2347.915557] usb 2-1: unregistering interface 2-1:1.0
    [ 2347.915679] drivers/usb/class/cdc-acm.c: Entering stop_data_traffic
    ...
    [ 2347.917419] musb-hdrc musb-hdrc.0: shutdown urb d5181e40 ep7in-intr
    [ 2347.917419] drivers/usb/class/cdc-acm.c: Entering stop_data_traffic
    [ 2347.918243] drivers/usb/class/cdc-acm.c: acm_ctrl_irq - urb shutting down with status: -108
    ...
    [ 2347.928161] usb 2-1: usb_disable_device nuking all URBs
    [ 2348.080932] hub 2-0:1.0: debounce: port 1: total 100ms stable 100ms status 0x101
    [ 2348.205932] usb 2-1: new high speed USB device using musb-hdrc and address 5
    [ 2348.371337] usb 2-1: config 1 interface 0 altsetting 0 endpoint 0x81 has an invalid bInterval 255, changing to 11
    [ 2348.382049] usb 2-1: skipped 4 descriptors after endpoint
    [ 2348.382049] usb 2-1: device v058b p0041 is not supported
    [ 2348.387603] usb 2-1: udev 5, busnum 2, minor = 132
    [ 2348.387603] usb 2-1: New USB device found, idVendor=058b, idProduct=0041
    [ 2348.394592] usb 2-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
    [ 2348.402343] usb 2-1: usb_probe_device
    [ 2348.402343] usb 2-1: rejected 1 configuration due to insufficient available bus power
    [ 2348.410522] usb 2-1: no configuration chosen from 1 choice
    [ 2348.416320] drivers/usb/core/inode.c: creating file '005'
    [ 2348.416442] hub 2-0:1.0: 92mA power budget left
    [ 2348.416473] hub 2-0:1.0: state 7 ports 1 chg 0000 evt 0002
    [ 2348.416503] hub 2-0:1.0: port 1 enable change, status 00000503
    [ 2351.304809] hub 2-0:1.0: state 7 ports 1 chg 0000 evt 0002
    [ 2351.304840] hub 2-0:1.0: port 1, status 0100, change 0001, 12 Mb/s
    [ 2351.304870] usb 2-1: USB disconnect, address 5
    [ 2351.309509] usb 2-1: unregistering device
    [ 2351.309539] usb 2-1: usb_disable_device nuking all URBs


    Could you have an analysis please on this new USB OTG connexion failure?
    Would there be some known patches to correct this problem?

    Thanks for your help,
    Simon
    The reply is currently minimized Show
  • Accepted Answer

    mcaro
    mcaro
    Offline
    Thursday, April 23 2015, 05:32 PM - #permalink
    0
    Hi Simon,

    The OTG is 100mA current limited if your modem consumption is bigger (probably it is) then the port will disconnect or reject setup this port at desired configuratio, so in this case I suggest you use a powered hub ...

    Regards
    Manel
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, April 23 2015, 06:50 PM - #permalink
    0
    Thanks for this information.

    Meanwhile, i have also observed that the power cable of the modem is damaged on this OTG test setup, which could explain the observed failures...
    Sorry for inconvenience, i will post later OTG debug logs if failing with a valid setup.

    Regards,
    Simon
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, May 05 2015, 02:39 PM - #permalink
    0
    Hi,

    We deployed boxs on client sites with USB debug activated in kernel to have information if new USB issues happen (around 35 sites have this debug feature for now).

    On one site, a USB OTG issues happened (without issues on cables this time...) and i attach the corresponding USB debug log that we get.

    On the end of the dmesg log, it can be observed that the write procedure fails:

    [63045.286376] drivers/usb/class/cdc-acm.c: Entering acm_tty_write to write 30 bytes,
    [63045.286407] drivers/usb/class/cdc-acm.c: Get 30 bytes...
    [63045.286407] drivers/usb/class/cdc-acm.c: acm_write_start susp_count: 0
    [63048.289886] drivers/usb/class/cdc-acm.c: Entering acm_tty_write to write 30 bytes,
    [63048.289886] drivers/usb/class/cdc-acm.c: Get 30 bytes...
    [63048.289886] drivers/usb/class/cdc-acm.c: acm_write_start susp_count: 0


    Previously in dmesg log, i observe a read procedure longer than usual:

    [63034.038299] drivers/usb/class/cdc-acm.c: acm_rx_tasklet: sending urb 0xd5bff6c0, rcv 0xd50bf318, buf 0xd50bf458
    [63034.038299] drivers/usb/class/cdc-acm.c: acm_rx_tasklet: sending urb 0xd5bff5c0, rcv 0xd50bf304, buf 0xd50bf444
    [63034.038330] drivers/usb/class/cdc-acm.c: acm_rx_tasklet: sending urb 0xd5bff540, rcv 0xd50bf2f0, buf 0xd50bf430
    [63034.038330] drivers/usb/class/cdc-acm.c: acm_rx_tasklet: sending urb 0xd790d0c0, rcv 0xd50bf2dc, buf 0xd50bf41c
    [63034.038330] drivers/usb/class/cdc-acm.c: acm_rx_tasklet: sending urb 0xd5b61540, rcv 0xd50bf2c8, buf 0xd50bf408


    and a little next to this read sequence, some suspect lines that i don't understand for now:

    [63035.232482] drivers/usb/class/cdc-acm.c: input control lines: dcd+ dsr+ break- ring- framing- parity- overrun-
    [63035.233581] drivers/usb/class/cdc-acm.c: connected to network
    [63035.234710] drivers/usb/class/cdc-acm.c: input control lines: dcd+ dsr+ break- ring- framing- parity- overrun-
    [63035.235839] drivers/usb/class/cdc-acm.c: connected to network



    USB OTG connection doesn't work anymore following this (timeout on the connection).
    This timeout can be also observed with the lsusb -v command (also in the attached log):
    ...
    Interface Descriptor:
    bLength 9
    bDescriptorType 4
    bInterfaceNumber 10
    bAlternateSetting 0
    bNumEndpoints 1
    bInterfaceClass 2 Communications
    bInterfaceSubClass 2 Abstract (modem)
    bInterfaceProtocol 1 AT-commands (v.25ter)
    iIntecan't get device qualifier: Connection timed out
    can't get debug descriptor: Connection timed out
    cannot read device status, Connection timed out (110)
    rface 14
    ...

    Could you have an analysis on this behavior and logs please?
    Would there be some actions to do to correct this?

    Thanks for your help,
    Simon
    Attachments:
    The reply is currently minimized Show
  • Accepted Answer

    mcaro
    mcaro
    Offline
    Tuesday, May 05 2015, 02:49 PM - #permalink
    0
    Are you using a USB hub ?
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, May 05 2015, 03:00 PM - #permalink
    0
    We don't use a USB hub in our box, the modem is connected directly to the USB OTG connector using a USB cable (mini A OTG - IGEP side to mini B - modem side, 50cm).

    The modem has a separate power supply connection (12V 2,5A).
    The reply is currently minimized Show
  • Accepted Answer

    Wednesday, May 06 2015, 08:56 AM - #permalink
    0
    The numerous boxs we have installed on site doesn't have a USB hub, and it would be then difficult to add it.

    Could you help us to know why a USB hub would be required and would correct the behavior i observed above?

    Concerning power, the modem connected with USB has it's own power supply.
    Only the detected device idVendor=058b, idProduct=0041 on the USB link requires 500mA. This a flash loader that appear on the USB link only when modem is booting. When this occurs, we don't observe failure on the USB link, the configuration is only rejected with cause insufficient power by USB core driver.
    Then we don't think there is a power problem that would require a USB hub, but maybe you would know some other information that would justify to use one?

    Thanks for your help,
    Simon
    The reply is currently minimized Show
  • Accepted Answer

    Wednesday, May 06 2015, 01:09 PM - #permalink
    0
    As there is a USB read sequence longer than usual before the failure happens:

    [63034.038299] drivers/usb/class/cdc-acm.c: acm_rx_tasklet: sending urb 0xd5bff6c0, rcv 0xd50bf318, buf 0xd50bf458
    [63034.038299] drivers/usb/class/cdc-acm.c: acm_rx_tasklet: sending urb 0xd5bff5c0, rcv 0xd50bf304, buf 0xd50bf444
    [63034.038330] drivers/usb/class/cdc-acm.c: acm_rx_tasklet: sending urb 0xd5bff540, rcv 0xd50bf2f0, buf 0xd50bf430
    [63034.038330] drivers/usb/class/cdc-acm.c: acm_rx_tasklet: sending urb 0xd790d0c0, rcv 0xd50bf2dc, buf 0xd50bf41c
    [63034.038330] drivers/usb/class/cdc-acm.c: acm_rx_tasklet: sending urb 0xd5b61540, rcv 0xd50bf2c8, buf 0xd50bf408


    and that some lines concerning flow control parameters appear:
    [63035.232482] drivers/usb/class/cdc-acm.c: input control lines: dcd+ dsr+ break- ring- framing- parity- overrun-

    i wonder if there could be some flow control problem, and if flow control compliance between modem and USB OTG could cause problem.

    Concerning modem, flow control is configured through AT commands and there are some used default values. I have listed here the concerned AT commands:

    AT&C: Data Carrier Detect (DCD) Control
    By default, AT&C1: DCD follows the Carrier detect status: if carrier is detected DCD is high, otherwise DCD is low. (factory default)

    AT&D: Data Terminal Ready (DTR) Control
    By default, AT&D0: device ignores DTR transitions (factory default)

    AT\Q: standard flow control
    By default, AT\Q3: hardware bi-directional flow control (both RTS/CTS active) (factory default)

    AT&K: Flow Control
    By default, AT&K3: hardware bi-directional flow control (both RTS/CTS active) (factory default)

    AT&S: Data Set Ready (DSR) Control
    By default, AT&S3: High when device is ready to receive commands (factory default).

    AT+IPR: Fixed DTE Interface Rate
    Configured to 115200

    AT+IFC: DTE-Modem Local Flow Control
    By default, AT+IFC=2,2: C105 (RTS), C106 (CTS) (factory default)

    AT+ILRR: DTE-Modem Local Rate Reporting

    AT+ICF: DTE-Modem Character Framing
    Set command defines the asynchronous character framing to be used when autobauding is disabled.

    The modem we use is a Teleorigin RB800U based on Telit UL865.

    Could you have an analysis on flow control management on USB OTG please, and if there could be compliance problems with modem?

    Thanks for your help,
    Simon
    The reply is currently minimized Show
  • Accepted Answer

    mcaro
    mcaro
    Offline
    Wednesday, May 06 2015, 03:12 PM - #permalink
    0
    Hi Simon,

    OTG only can drive 100mA (theoretic) and it's self protected but it's true the drive tolerance it's too high ...

    I'm not familiar with this modem but I suggest you test it using the USB host instead and check if the results be similar ...

    I don't have any modem like this for check it ... :( so what driver are you using for control this modem ? Did you tested other modem ?

    Cheers
    Manel
    The reply is currently minimized Show
  • Accepted Answer

    Wednesday, May 06 2015, 03:36 PM - #permalink
    0
    Hi,

    With the USB identifier v1bc7 p0021 corresponding to the Telit module, the generic CDC-ACM driver is used to manage this USB link (driver managing serial over USB, and enables to enumerate /dev/ttyACM* interfaces to communicate with modem).

    The boxes we make know use the USB host connexion, on which this issue has not been observed yet, but we have now many boxes on installation sites that use USB OTG, and that we must correct.

    We tested previously on modem Motorola H24 (end 2014), this was not observed, but we didn't deployed with this modem as it has been obsolete.
    On production, we only use Telit HE910/UL865 modems.

    I am currently analyzing CDC-ACM flow control, maybe would you have some corrective actions for this subject?
    Or maybe concerning dmesg logs, some other corrective actions could help?

    Thanks,
    Simon
    The reply is currently minimized Show
  • Accepted Answer

    mcaro
    mcaro
    Offline
    Wednesday, May 06 2015, 04:33 PM - #permalink
    0
    Hi Simon,

    I'm checking your log usbdump_select.txt and I don't see any USB issue there only a GSM operator disconnection command ... maybe you can give more points about that :)

    Manel
    The reply is currently minimized Show
  • Accepted Answer

    Wednesday, May 06 2015, 06:02 PM - #permalink
    0
    On my side, i compared USB debug logs with a working setup, and i found same USB logs, then you're right it doesn't seem that there are USB issue in log, except the failing writes at the end:
    ...
    [63039.279296] drivers/usb/class/cdc-acm.c: Entering acm_tty_write to write 30 bytes,
    [63039.279296] drivers/usb/class/cdc-acm.c: Get 30 bytes...
    [63039.279327] drivers/usb/class/cdc-acm.c: acm_write_start susp_count: 0
    [63039.279602] cdc_acm 2-1:1.1: tx 30/30 bytes -- > 0
    [63039.279632] cdc_acm 2-1:1.1: tx work
    [63042.282897] drivers/usb/class/cdc-acm.c: Entering acm_tty_write to write 30 bytes,
    [63042.282897] drivers/usb/class/cdc-acm.c: Get 30 bytes...
    [63042.282897] drivers/usb/class/cdc-acm.c: acm_write_start susp_count: 0
    [63045.286376] drivers/usb/class/cdc-acm.c: Entering acm_tty_write to write 30 bytes,
    [63045.286407] drivers/usb/class/cdc-acm.c: Get 30 bytes...
    [63045.286407] drivers/usb/class/cdc-acm.c: acm_write_start susp_count: 0
    [63048.289886] drivers/usb/class/cdc-acm.c: Entering acm_tty_write to write 30 byte
    ...

    You're also right that the USB failure happens with a failing pppd negotiation. I extracted the pppd logs (normaly mixed with USB debug logs):
    ...
    Apr 28 08:13:08 igep00x0 daemon.debug pppd[6654]: sent [IPCP ConfReq id=0x1 ]
    Apr 28 08:13:11 igep00x0 daemon.debug pppd[6654]: sent [IPCP ConfReq id=0x1 ]
    Apr 28 08:13:14 igep00x0 daemon.debug pppd[6654]: sent [IPCP ConfReq id=0x1 ]
    Apr 28 08:13:17 igep00x0 daemon.debug pppd[6654]: sent [IPCP ConfReq id=0x1 ]
    Apr 28 08:13:20 igep00x0 daemon.debug pppd[6654]: sent [IPCP ConfReq id=0x1 ]
    Apr 28 08:13:23 igep00x0 daemon.warn pppd[6654]: IPCP: timeout sending Config-Requests
    Apr 28 08:13:23 igep00x0 daemon.debug pppd[6654]: sent [LCP TermReq id=0x2 "No network protocols running"]
    Apr 28 08:13:26 igep00x0 daemon.debug pppd[6654]: sent [LCP TermReq id=0x3 "No network protocols running"]
    Apr 28 08:13:29 igep00x0 daemon.notice pppd[6654]: Connection terminated.

    and i made some google search ("telit pppd No network protocols running") and found the following ISEE forum with similar topics:
    https://www.isee.biz/support/upgrading-the-telit-modem-firmware
    https://www.isee.biz/support/problems-with-ppp-connection-using-telit-modem

    From reading these discution threads, i mainly noticed for now that it would be recommended to use this configuration: AT+IFC=0,0
    I am going to test this setting, although i cannot correlate for now the pppd failure with USB having write fails and stopping the connexion.
    Maybe would you have some more feedback from these new inputs please?

    Thanks,
    Simon
    The reply is currently minimized Show
Your Reply

SUPPORT


This email address is being protected from spambots. You need JavaScript enabled to view it.
This email address is being protected from spambots. You need JavaScript enabled to view it.
IGEP Community Wiki
IGEP Community Forum
IGEP Community Online Chat