[Mark Gajdosik]

Regarding the logs, I had the same issue.

1. The modem disconnects without any warning.
2. It then reconnects back.
3. It is assigned an address which it does not accept and the cycle repeats forever, even after a reboot.

The radio reset script from above helped this issue. We have had the following happening to us as well, with the radio reset script above helping the situation.

g_serial gadget: Gadget Serial v2.4
g_serial gadget: g_serial ready
#### Everything works normal until here ####
tty_port_close_start: tty->count = 1 port count = 0.
tty_port_close_start: tty->count = 1 port count = 0.
tty_port_close_start: tty->count = 1 port count = 0.
tty_port_close_start: tty->count = 1 port count = 0.
tty_port_close_start: tty->count = 1 port count = 0.
tty_port_close_start: tty->count = 1 port count = 0.
tty_port_close_start: tty->count = 1 port count = 0.
tty_port_close_start: tty->count = 1 port count = 0.
tty_port_close_start: tty->count = 1 port count = 0.
tty_port_close_start: tty->count = 1 port count = 0.
tty_port_close_start: tty->count = 1 port count = 0.
tty_port_close_start: tty->count = 1 port count = 0.
tty_port_close_start: tty->count = 1 port count = 0.
tty_port_close_start: tty->count = 1 port count = 0.
tty_port_close_start: tty->count = 1 port count = 0.
tty_port_close_start: tty->count = 1 port count = 0.
tty_port_close_start: tty->count = 1 port count = 0.
tty_port_close_start: tty->count = 1 port count = 0.
tty_port_close_start: tty->count = 1 port count = 0.
tty_port_close_start: tty->count = 1 port count = 0.
tty_port_close_start: tty->count = 1 port count = 0.
#### This is when the radio reset script kicks in ####
usb 1-1: USB disconnect, address 2
usb 1-1: new full speed USB device using at91_ohci and address 4
at91_ohci at91_ohci: remove, state 1
usb usb1: USB disconnect, address 1
ftdi_sio ttyUSB0: usb_serial_generic_submit_read_urb - error submitting urb: -19
usb 1-1: device not accepting address 4, error -62
hub 1-0:1.0: cannot disable port 1 (err = -19)
hub 1-0:1.0: cannot reset port 1 (err = -19)
hub 1-0:1.0: cannot disable port 1 (err = -19)
hub 1-0:1.0: cannot reset port 1 (err = -19)
hub 1-0:1.0: cannot disable port 1 (err = -19)
hub 1-0:1.0: cannot reset port 1 (err = -19)
hub 1-0:1.0: cannot disable port 1 (err = -19)
hub 1-0:1.0: unable to enumerate USB device on port 1
hub 1-0:1.0: cannot disable port 1 (err = -19)
usb 1-2: USB disconnect, address 3
ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0
ftdi_sio 1-2:1.0: device disconnected
at91_ohci at91_ohci: USB bus 1 deregistered
#### ohci_hcd is modprobed back into the system ####
ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
at91_ohci at91_ohci: AT91 OHCI
at91_ohci at91_ohci: new USB bus registered, assigned bus number 1
at91_ohci at91_ohci: irq 20, io mem 0x00500000
usb usb1: New USB device found, idVendor=1d6b, idProduct=0001
usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb1: Product: AT91 OHCI
usb usb1: Manufacturer: Linux 2.6.35.14+ ohci_hcd
usb usb1: SerialNumber: at91
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 2 ports detected
usb 1-1: new full speed USB device using at91_ohci and address 2
usb 1-1: New USB device found, idVendor=1bc7, idProduct=0021
usb 1-1: New USB device strings: Mfr=18, Product=19, SerialNumber=20
usb 1-1: Product: Telit Wireless Module
usb 1-1: Manufacturer: Telit wireless solutions
usb 1-1: SerialNumber: 351579052169503

The script doesn’t prevent these things from happening, it is only used as a last resort. Also, we have sites where nothing like this ever happened to us, while other sites are very unstable.

[Mark Gajdosik]

Rafael,

I do what the script does + the extra radio reset, from inside our application:

1. Shut down PPPD, OpenVPN.
2. Stop checking for SMS messages in /dev/modem_at1.
3. Wait 30 seconds.

4. Write 0 into /sys/devices/platform/mtcdp/radio-reset
5. Wait 8 seconds.
6. /sbin/rmmod ohci_hcd
7. Wait 8 seconds.
8. Write 0 into /sys/devices/platform/mtcdp/radio-reset
9. Wait 8 seconds.
10. /sbin/modprobe ohci_hcd

11. Wait 30 seconds.
12. Restart PPPD, OpenVPN etc.

This did help on one of our sites which couldn’t stay online for longer than a day.

• This reply was modified 9 years ago by Mark Gajdosik.

[Mark Gajdosik]

Hi Rafael,

it was suggested to do the same to us by MultiTech. It does seem to overcome the issue, but we have one stubborn site where this solution does not work.

Would you have any dmesg output from the moment the modem plays up please? It would be helpful to compare the logs to see if the errors manifests in the same way.

[Mark Gajdosik]

Hi,

I can confirm that the devices with the patch applied have not crashed since we patched them 8 days ago.

Without the patch, it would have happened 4-5 times already.

[Mark Gajdosik]

The most unstable device (S/N: 17604609), which we updated first and kept it running since hasn’t crashed for 24 hours now. Fingers crossed. I will report here after a week.

[Mark Gajdosik]

For anyone with this issue:
read here.

[Mark Gajdosik]

Thanks. I will leave it alone then.

[Mark Gajdosik]

Thanks Lonny, that answers my question.

[Mark Gajdosik]

Lonny: Thank you. We are happy with the reboot procedure. The first MTCDP device we have on the network has been doing this every 4 hours since early autumn 2013, without issues.

I will consider using AT+COPS – thanks for the idea. Sounds lighter than AT#ENHRST and it should do what we need it to do. AT#ENHRST will be kept for, like you said, cases of a long-term disconnection.

If we were, however, to use the Ethernet as primary connection, is it still reasonable to re-register with the network even if it’s not in use, but it has SIM in it?

I need that modem to take over in case Ethernet fails. The whole project is about getting most out of MTCDPs, making them as maintenance free as possible.

[Mark Gajdosik]

Lonny: In 2011, when the project using wireless modems started (we used a different product back then), we had devices configured never to reboot their modems.

The first site in London (using Vodafone UK network) went offline after 3 weeks of consistent connection. They [Vodafone] told us that the device in London hasn’t re-registered on the network for some time and that it was blocked because of that.

They advised us to let our devices reconnect to the network every now and then, which we figured, should be a wireless modem reboot.

I spoke to Campbell Elder in Reading regarding this and he confirmed that the network providers don’t like consistently connected devices.

[Mark Gajdosik]

I find it quite easy to do this with cron.

Run crontab -e and add @reboot /usr/bin/python PATH-TO-YOUR-SCRIPT. Exit vi and reboot the device. Your script should be running.

[Author]

Posts