What's new

Router killing USB modem and OpenVPN server problems

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

Pila

Regular Contributor
Router RT-AC56U apparently hangs itself up after "ohci_hcd ... bad entry" in log, leaving OpenVPN server working but unusable, while disabling WLAN access too at the same time. But OpenVPN has some strange entries indicating routing problems prior to that. So, who is to blame?

On an Asus RT-AC56U (192.168.2.1) remote router there is an OpenVPN server. Local router, an Asus RT-AC68U (192.168.1.1) connects to it using a VPN client. Only the other segment traffic (to 192.168.2.1/24) is routed through the VPN. Normally, VPN client connects only as needed, for short period of time (minutes, never hours), does what it needs and logs out. RT-AC56U worked perfectly for some 2 months with several various client connections made daily to its OpenVPN server. Both routers are RT-380.59_0 now, previously it was .58. Bi-directional HMAC authorisation is activated.

I was doing several things:
1) Asus RT-AC68U had client 1 connected to AC56U (for 4 hours) without any payload trafic toward RT-AC56U.
2) testing some port forwarding on RT-AC68U using both GUI and command line - iptables -t nat -I VSERVER 1 ...
3) Asus RT-AC68U had running second OpenVPN client 3 connected to VPN server in Romania.

My poking around local firewall for a short time should not have impacted remote VPN server on AC56U as its tunnel remained unused the entire time. But... I finished, ended client 3. I disconnected Client 1 to RT-AC56U after 4 hours, and went away.

Later that evening, I was not able to connect VPN client to my remote server. Router is UP, VPN server is up, Inet access is up. I used different devices, different OS-s, I could not connect to my remote VPN server.

Problem 1. Remote Asus RT-AC56U log shows one line I can not explain and is likely related:
Code:
Jun  9 16:42:29 openvpn[32521]: ...
Jun  9 22:19:46 kernel: ohci_hcd 0000:00:0b.0: bad entry 9c24e040

The only USB device on a remote router is USB 3G modem, but there were no further log activity related to remote modem or its IP link in any way, shape or form.

Problem 2. Immediatelly following the above line, the remote log shows me trying, but failing to connect with:
Code:
Jun 10 02:41:56 openvpn[32521]: 5.5.5.5:60127 TLS: Initial packet from [AF_INET]5.5.5.5:60127, sid=3b3aa30b 8d6e0cd7
Jun 10 02:42:56 openvpn[32521]: 5.5.5.5:60127 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Jun 10 02:42:56 openvpn[32521]: 5.5.5.5:60127 TLS Error: TLS handshake failed
Jun 10 02:42:56 openvpn[32521]: 5.5.5.5:60127 SIGUSR1[soft,tls-error] received, client-instance restarting

When I tried connecting a Client from another device (another IP address) I got the following, which at later time also was logged for 5.5.5.5 address:
Code:
Jun 10 02:45:26 openvpn[32521]: 10.218.57.123:54390 Authenticate/Decrypt packet error: bad packet ID (may be a replay): [ #1 / time = (1465519520) Fri Jun 10 02:45:20 2016 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings

Another thing that should not have happend: after my last try I went to sleep. But, my remote RT-AC56U shows my IP address retries again, 2h03m later / after my actuall last try!

Problem 3. LEDs on it looked normal. (edit: removed rest of this point as it turned out it was not related to the issue). That suggests to me my RT-AC56U was hung up somehow.

Turning the RT-AC56U manually off and back on solved everything. But, it takes a person to do so :(

Problem 4. Stil not an end of it! In the remote log, there was something that should not have been there. I was using Client 3 to connect to another VPN server at the same time. Remote server address is: 176.126.237.214. Lets say mine is 5.5.5.5. I do not think 176.126.237.214 should ever appear on my private remote server! Log shows it and that I was again connected after that incindent to remote RT-AC56U.
Code:
Jun  9 12:48:18 openvpn[32521]: 5.5.5.5:57060 TLS: Initial packet from [AF_INET]5.5.5.5:57060, sid=a89fd0d9 e555d62a
Jun  9 12:48:20 openvpn[32521]: 5.5.5.5:57060 VERIFY OK: ...
Jun  9 12:48:20 openvpn[32521]: 5.5.5.5:57060 VERIFY OK: ...
...
...
Jun  9 12:50:06 openvpn[32521]: pila_pc/5.5.5.5:53786 [pila_pc] Inactivity timeout (--ping-restart), restarting
Jun  9 12:50:06 openvpn[32521]: pila_pc/5.5.5.5:53786 SIGUSR1[soft,ping-restart] received, client-instance restarting
Jun  9 13:05:27 openvpn[32521]: pila_pc/5.5.5.5:57060 [pila_pc] Inactivity timeout (--ping-restart), restarting
Jun  9 13:05:27 openvpn[32521]: pila_pc/5.5.5.5:57060 SIGUSR1[soft,ping-restart] received, client-instance restarting
Jun  9 13:06:17 openvpn[32521]: 176.126.237.214:42274 TLS: Initial packet from [AF_INET]176.126.237.214:42274, sid=dc228dd7 f691381c
Jun  9 13:07:17 openvpn[32521]: 176.126.237.214:42274 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Jun  9 13:07:17 openvpn[32521]: 176.126.237.214:42274 TLS Error: TLS handshake failed
Jun  9 13:07:17 openvpn[32521]: 176.126.237.214:42274 SIGUSR1[soft,tls-error] received, client-instance restarting
Jun  9 13:07:20 openvpn[32521]: 5.5.5.5:51662 TLS: Initial packet from [AF_INET]5.5.5.5:51662, sid=6abc56e2 3bc311bd
Jun  9 13:07:22 openvpn[32521]: 5.5.5.5:51662 VERIFY OK: ...
Jun  9 13:07:22 openvpn[32521]: 5.5.5.5:51662 VERIFY OK: ...
...
 
Last edited:
Router killing USB modem!

Seems to me the problem is with the USB and ASUS. Again. For some reason, router manages to kill my USB 3G modem.

And few days later, dead again. This time nobody was touching (using) a router for 2 days at all. But, logs are not similar at all! Above, only one log line indicates USB problem.

As my DDNS service was not updated at the incident time, I believe that the router Asuswrt-Merlin RT-AC56U_380.59_0 managed to kill modem and leave it without a connection.

I do not think this is a ISP problem. I can not comment definitively on the USB modem itself as I have it for about 2 months, but it was working for over a month perfectly. But, I have had several USB catastrophies with these Asus routers! So, I think the router is to blame.

Here is the entire log, showing at the beggining the last line of previous event and at the end the last line - moment after the manual restart.

Code:
,,,
Jun 12 17:09:31 dropbear[21211]: Exit (pila): Exited normally
Jun 14 03:02:20 kernel: hub 2-0:1.0: port 2 disabled by hub (EMI?), re-enabling...
Jun 14 03:02:20 kernel: usb 2-2: USB disconnect, address 3
Jun 14 03:02:20 kernel: option: option_instat_callback: error -108
Jun 14 03:02:20 pppd[1334]: Modem hangup
Jun 14 03:02:20 pppd[1334]: Connect time 457981.2 minutes.
Jun 14 03:02:20 pppd[1334]: Sent 18999174 bytes, received 6846065 bytes.
Jun 14 03:02:20 kernel: option1 ttyUSB0: GSM modem (1-port) converter now disconnected from ttyUSB0
Jun 14 03:02:20 kernel: option 2-2:1.0: device disconnected
Jun 14 03:02:20 kernel: option: option_instat_callback: error -108
Jun 14 03:02:20 kernel: option1 ttyUSB1: GSM modem (1-port) converter now disconnected from ttyUSB1
Jun 14 03:02:20 kernel: option 2-2:1.1: device disconnected
Jun 14 03:02:20 kernel: option1 ttyUSB2: GSM modem (1-port) converter now disconnected from ttyUSB2
Jun 14 03:02:20 kernel: option 2-2:1.2: device disconnected
Jun 14 03:02:20 kernel: option1 ttyUSB3: GSM modem (1-port) converter now disconnected from ttyUSB3
Jun 14 03:02:20 kernel: option 2-2:1.3: device disconnected
Jun 14 03:02:20 pppd[1334]: Connection terminated.
Jun 14 03:02:21 WAN Connection: Fail to connect with some issues.
Jun 14 03:02:21 stop_nat_rules: apply the redirect_rules!
Jun 14 03:02:21 dnsmasq[413]: read /etc/hosts - 5 addresses
Jun 14 03:02:21 dnsmasq[413]: read /etc/hosts.dnsmasq - 2 addresses
Jun 14 03:02:21 dnsmasq-dhcp[413]: read /etc/ethers - 2 addresses
Jun 14 03:02:21 dnsmasq[413]: using nameserver 212.91.97.4#53
Jun 14 03:02:21 dnsmasq[413]: using nameserver 212.91.97.3#53
Jun 14 03:02:21 pppd[1334]: Hangup (SIGHUP)
Jun 14 03:02:21 pppd[1334]: Terminating on signal 15
Jun 14 03:02:21 pppd[1334]: Exit.
Jun 14 03:02:23 kernel: usbcore: deregistering interface driver option
Jun 14 03:02:23 kernel: USB Serial deregistering driver GSM modem (1-port)
Jun 14 03:02:23 kernel: usbcore: deregistering interface driver usbserial_generic
Jun 14 03:02:23 kernel: USB Serial deregistering driver generic
Jun 14 03:02:23 kernel: usbcore: deregistering interface driver usbserial
Jun 14 03:02:23 rc_service: hotplug 4672:notify_rc restart_nasapps
Jun 14 03:02:23 iTunes: daemon is stopped
Jun 14 03:02:23 FTP Server: daemon is stopped
Jun 14 03:02:23 Samba Server: smb daemon is stopped
Jun 14 03:02:23 kernel: gro disabled
Jun 14 03:02:24 Timemachine: daemon is stopped
Jun 14 03:02:25 kernel: usb 2-2: new high speed USB device using ehci_hcd and address 4
Jun 14 03:02:25 kernel: scsi3 : usb-storage 2-2:1.0
Jun 14 03:02:26 kernel: scsi 3:0:0:0: CD-ROM            HUAWEI   Mass Storage     2.31 PQ: 0 ANSI: 2
Jun 14 03:02:26 kernel: scsi 3:0:0:0: Attached scsi generic sg0 type 5
Jun 14 03:02:26 kernel: scsi 3:0:0:1: Direct-Access     HUAWEI   TF CARD Storage  2.31 PQ: 0 ANSI: 2
Jun 14 03:02:26 kernel: sd 3:0:0:1: Attached scsi generic sg1 type 0
Jun 14 03:02:26 kernel: sd 3:0:0:1: [sda] Attached SCSI removable disk
Jun 14 03:02:26 kernel: usb 2-2: USB disconnect, address 4
Jun 14 03:02:27 rc_service: hotplug 4730:notify_rc restart_nasapps
Jun 14 03:02:27 iTunes: daemon is stopped
Jun 14 03:02:27 FTP Server: daemon is stopped
Jun 14 03:02:28 Samba Server: smb daemon is stopped
Jun 14 03:02:28 kernel: gro disabled
Jun 14 03:02:28 kernel: usb 2-2: new high speed USB device using ehci_hcd and address 5
Jun 14 03:02:28 Timemachine: daemon is stopped
Jun 14 03:02:29 kernel: scsi4 : usb-storage 2-2:1.4
Jun 14 03:02:29 kernel: scsi5 : usb-storage 2-2:1.5
Jun 14 03:02:30 kernel: scsi 4:0:0:0: CD-ROM            HUAWEI   Mass Storage     2.31 PQ: 0 ANSI: 2
Jun 14 03:02:30 kernel: scsi 4:0:0:0: Attached scsi generic sg0 type 5
Jun 14 03:02:30 kernel: scsi 5:0:0:0: Direct-Access     HUAWEI   TF CARD Storage  2.31 PQ: 0 ANSI: 2
Jun 14 03:02:30 kernel: sd 5:0:0:0: Attached scsi generic sg1 type 0
Jun 14 03:02:30 kernel: sd 5:0:0:0: [sda] Attached SCSI removable disk
Jun 14 03:02:32 kernel: usbcore: registered new interface driver usbserial
Jun 14 03:02:32 kernel: USB Serial support registered for generic
Jun 14 03:02:32 kernel: usbcore: registered new interface driver usbserial_generic
Jun 14 03:02:32 kernel: usbserial: USB Serial Driver core
Jun 14 03:02:33 kernel: USB Serial support registered for GSM modem (1-port)
Jun 14 03:02:33 kernel: option 2-2:1.0: GSM modem (1-port) converter detected
Jun 14 03:02:33 kernel: usb 2-2: GSM modem (1-port) converter now attached to ttyUSB0
Jun 14 03:02:33 kernel: option 2-2:1.1: GSM modem (1-port) converter detected
Jun 14 03:02:33 WAN Connection: Ethernet link down.
Jun 14 03:02:33 kernel: usb 2-2: GSM modem (1-port) converter now attached to ttyUSB1
Jun 14 03:02:33 kernel: option 2-2:1.2: GSM modem (1-port) converter detected
Jun 14 03:02:33 kernel: usb 2-2: GSM modem (1-port) converter now attached to ttyUSB2
Jun 14 03:02:33 kernel: option 2-2:1.3: GSM modem (1-port) converter detected
Jun 14 03:02:33 kernel: usb 2-2: GSM modem (1-port) converter now attached to ttyUSB3
Jun 14 03:02:33 kernel: usbcore: registered new interface driver option
Jun 14 03:02:33 kernel: option: v0.7.2:USB Driver for GSM modems
Jun 14 03:02:38 WAN Connection: Ethernet link up.
Jun 14 03:02:46 WAN Connection: Fail to connect with some issues.
Aug  1 02:00:16 syslogd started: BusyBox v1.20.2
...

A line "WAN Connection: Fail to connect with some issues." appears before every normal connection is established, too. Example:

Code:
Jun  2 02:06:00 kernel: usbcore: registered new interface driver option
Jun  2 02:06:00 kernel: option: v0.7.2:USB Driver for GSM modems
Jun  2 02:06:03 WAN Connection: Ethernet link up.
Jun  2 02:06:03 rc_service: wanduck 398:notify_rc restart_wan_if 0
Jun  2 02:06:03 dnsmasq[413]: read /etc/hosts - 5 addresses
Jun  2 02:06:03 dnsmasq[413]: read /etc/hosts.dnsmasq - 2 addresses
Jun  2 02:06:03 dnsmasq-dhcp[413]: read /etc/ethers - 2 addresses
Jun  2 02:06:18 WAN Connection: Fail to connect with some issues.
Jun  2 02:06:23 pppd[2954]: pppd 2.4.7 started by pila, uid 0
Jun  2 02:06:31 pppd[2954]: Serial connection established.
Jun  2 02:06:31 pppd[2954]: Using interface ppp0
Jun  2 02:06:31 pppd[2954]: Connect: ppp0 <--> /dev/ttyUSB0
Jun  2 02:06:35 pppd[2954]: Could not determine remote IP address: defaulting to 10.64.64.64
Jun  2 02:06:35 pppd[2954]: local  IP address 37.244.208.220
Jun  2 02:06:35 pppd[2954]: remote IP address 10.64.64.64
Jun  2 02:06:35 pppd[2954]: primary   DNS address 212.91.97.4
Jun  2 02:06:35 pppd[2954]: secondary DNS address 212.91.97.3

My problem is: I must get this remote router to work stand-alone 24/7 without anyone being able to reboot it.

OK, as a workaround: watchdog rebooting a router if WAN is unavailable or VPN not connecting? But, my problem is that I do not know how are these problems manifested within a router itself. First post seems to have had a connection, but unusable, for second situation, I preusme there was no connection at all. I would strongly prefer not to generate unncessary external trafic.
 
Last edited:
Many of the USB modems may draw more current than the port can safely deliver if they're in less than good coverage - might consider using a powered hub in the middle.
 
Many of the USB modems may draw more current than the port can safely deliver if they're in less than good coverage

Actually, a good idea. Ccovrage shold be great, but UMTS sucks in wall penetration. So, a temporary glitch in the network might confuse the modem and ask for a lot of power. Will have to investigate.
 

Similar threads

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top