- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I am using an embedded Linux platform running Ubuntu 16.04 and connects to the internet using the U620L device. My device works as a router for an internal WiFi network. I am experiencing disconnections very often specially when an Android Phone connects to the Wifi and some apps starts using the internet.
My setup:
To Setup the USB620L on Linux:
# Verizon Modem Setup
sudo -u "$user" route delete default
sudo -u "$user" rmmod rndis_host
sudo -u "$user" usb_modeswitch -v 0x1410 -p 0x9020 -u 2
sudo -u "$user" dhclient eth1
sudo -u "$user" ifconfig eth1 up
# Internet Sharing Setup
sudo -u "$user" sysctl -w net.ipv4.ip_forward=1
sudo -u "$user" sysctl -p
sudo -u "$user" iptables -I INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
sudo -u "$user" iptables -I FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
sudo -u "$user" iptables -t nat -I POSTROUTING -o eth1 -j MASQUERADE
So I can ping my destination all the time, but as soon as I connect the Android Phone to the Wifi for internet access, I experience the disconnection issues:
Checking the Log from the USB620L itself, I noticed the following:
Oct 12 16:47:05 (none) ccm: [CCM_S] - {mifios_sysevent}: CCM updated system time from TIME_SOURCE_NETWORK
Oct 12 16:47:05 (none) ccm: [CCM_S] - {mifios_sysevent}:New IP client: mac=00:15:ff:08:59:00, ifc=USB, type=DHCP, ip= [removed] , host=LTJVILELA
Oct 12 16:47:07 (none) ccm: [CCM_S] - {mifios_sysevent}:Removed IP client: mac=00:15:ff:08:59:00, ifc=USB, type=DHCP, ip= [removed] , host=LTJVILELA
Oct 12 16:47:20 (none) ccm: [CCM_S] - {mifios_sysevent}:New IP client: mac=00:15:ff:08:59:00, ifc=USB, type=DHCP, ip= [removed] , host=MK5
Oct 12 16:51:48 (none) ccm: [CCM_S] - {mifios_sysevent}:Removed IP client: mac=00:15:ff:08:59:00, ifc=USB, type=DHCP, ip= [removed] , host=MK5
Jan 1 00:00:18 (none) ccm: [CCM_S] - {mifios_sysevent}: Central Control Module Start!
Jan 1 00:00:19 (none) ccm: [CCM_S] - {mifios_sysevent}: Central Control Module Start!
Oct 12 16:56:40 (none) ccm: [CCM_S] - {mifios_sysevent}: CCM updated system time from TIME_SOURCE_NETWORK
Jan 1 00:00:18 (none) ccm: [CCM_S] - {mifios_sysevent}: Central Control Module Start!
Jan 1 00:00:19 (none) ccm: [CCM_S] - {mifios_sysevent}: Central Control Module Start!
Oct 12 16:57:07 (none) ccm: [CCM_S] - {mifios_sysevent}: CCM updated system time from TIME_SOURCE_NETWORK
Oct 12 16:57:19 (none) ccm: [CCM_S] - {mifios_sysevent}:New IP client: mac=00:15:ff:08:59:00, ifc=USB, type=DHCP, ip= [removed] , host=LTJVILELA
The message:
Oct 12 16:51:48 (none) ccm: [CCM_S] - {mifios_sysevent}:Removed IP client: mac=00:15:ff:08:59:00, ifc=USB, type=DHCP, ip= [removed] , host=MK5
Happens when my host (embedded platform) gets disconnected (no internet access). Curious thing is after that disconnection there are couple messages with January 1st date which it is odd.
Jan 1 00:00:18 (none) ccm: [CCM_S] - {mifios_sysevent}: Central Control Module Start!
Jan 1 00:00:19 (none) ccm: [CCM_S] - {mifios_sysevent}: Central Control Module Start!
Oct 12 16:56:40 (none) ccm: [CCM_S] - {mifios_sysevent}: CCM updated system time from TIME_SOURCE_NETWORK
And then the date is refresh from the network.
Checking tcpdump internally in the Wifi Network does not show any abnormal activity:
[removed] IP [removed] > satyr.vtti.vt.edu.https: Flags [S], seq 348227043, win 65535, options [mss 1460,sackOK,TS val 2654589 ecr 0,nop,wscale 7], length 0
[removed] IP 1 [removed] > satyr.vtti.vt.edu.https: Flags [S], seq 348227043, win 65535, options [mss 1460,sackOK,TS val 2654689 ecr 0,nop,wscale 7], length 0
[removed] IP [removed] > qn-in-f188.1e100.net.5228: Flags [P.], seq 1017:1071, ack 385, win 693, options [nop,nop,TS val 2654752 ecr 3180555890], length 54
[removed] IP [removed] > satyr.vtti.vt.edu.https: Flags [S], seq 2464292174, win 65535, options [mss 1460,sackOK,TS val 2654998 ecr 0,nop,wscale 7], length 0
[removed] IP [removed] > satyr.vtti.vt.edu.https: Flags [S], seq 4045076907, win 65535, options [mss 1460,sackOK,TS val 2655190 ecr 0,nop,wscale 7], length 0
[removed] IP [removed] > satyr.vtti.vt.edu.https: Flags [S], seq 4045076907, win 65535, options [mss 1460,sackOK,TS val 2655290 ecr 0,nop,wscale 7], length 0
[removed] IP [removed] > satyr.vtti.vt.edu.https: Flags [S], seq 4045076907, win 65535, options [mss 1460,sackOK,TS val 2655490 ecr 0,nop,wscale 7], length 0
[removed] IP [removed] > satyr.vtti.vt.edu.https: Flags [S], seq 266591695, win 65535, options [mss 1460,sackOK,TS val 2655501 ecr 0,nop,wscale 7], length 0
[removed] IP 1 [removed] > satyr.vtti.vt.edu.https: Flags [S], seq 266591695, win 65535, options [mss 1460,sackOK,TS val 2655601 ecr 0,nop,wscale 7], length 0
[removed] IP 1 [removed] > iad23s59-in-f10.1e100.net.https: Flags [P.], seq 3655:3686, ack 743, win 703, options [nop,nop,TS val 2655728 ecr 1356914537], length 31
[removed] IP [removed] > satyr.vtti.vt.edu.https: Flags [S], seq 266591695, win 65535, options [mss 1460,sackOK,TS val 2655801 ecr 0,nop,wscale 7], length 0
[removed] IP [removed] > satyr.vtti.vt.edu.https: Flags [S], seq 4045076907, win 65535, options [mss 1460,sackOK,TS val 2655891 ecr 0,nop,wscale 7], length 0
[removed] IP [removed] > satyr.vtti.vt.edu.https: Flags [S], seq 266591695, win 65535, options [mss 1460,sackOK,TS val 2656202 ecr 0,nop,wscale 7], length 0
[removed] IP [removed] > satyr.vtti.vt.edu.https: Flags [S], seq 1179478554, win 65535, options [mss 1460,sackOK,TS val 2657326 ecr 0,nop,wscale 7], length 0
[removed] IP 1 [removed] > iad23s59-in-f10.1e100.net.https: Flags [P.], seq 32923:32954, ack 6178, win 835, options [nop,nop,TS val 2658056 ecr 1356914491], length 31
[removed] IP [removed] > ec2-107-21-16-206.compute-1.amazonaws.com.https: Flags [P.], seq 106546:107575, ack 15756, win 1846, options [nop,nop,TS val 2658720 ecr 1356919983], length 1029
[removed] IP [removed] > iad23s59-in-f10.1e100.net.https: Flags [P.], seq 3655:3686, ack 743, win 703, options [nop,nop,TS val 2659064 ecr 1356914537], length 31
[removed] IP [removed] > iad23s59-in-f10.1e100.net.https: Flags [P.], seq 32923:32954, ack 6178, win 835, options [nop,nop,TS val 2665248 ecr 1356914491], length 31
[removed] IP [removed] > iad23s59-in-f10.1e100.net.https: Flags [P.], seq 3655:3686, ack 743, win 703, options [nop,nop,TS val 2665728 ecr 1356914537], length 31
[removed] IP [removed] > qn-in-f188.1e100.net.5228: Flags [P.], seq 1017:1071, ack 385, win 693, options [nop,nop,TS val 2666784 ecr 3180555890], length 54
[removed] IP [removed] > ec2-107-21-16-206.compute-1.amazonaws.com.https: Flags [P.], seq 106546:107575, ack 15756, win 1846, options [nop,nop,TS val 2670752 ecr 1356919983], length 1029
[removed] IP [removed] > iad23s59-in-f10.1e100.net.https: Flags [P.], seq 3655:3686, ack 743, win 703, options [nop,nop,TS val 2672400 ecr 1356914537], length 31
[removed] IP [removed] > iad23s59-in-f10.1e100.net.https: Flags [P.], seq 32923:32954, ack 6178, win 835, options [nop,nop,TS val 2672432 ecr 1356914491], length 31
So my concern is why my embedded platform gets disconnect so quickly (less than 3 minutes) when my Android Phone is trying to access the internet?
Private content removed as required by the Verizon Wireless Terms of Service.
Message edited by Verizon Moderator.
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
We want to assist you with this, Jptalledo. Just to verify, what is running the Linux to be a hotspot for other devices? This may be too much drain for the USB620L as it is mostly used to only have one device connected to it at a time. Do other devices cause disconnects besides the Android device? Please use this link to verify that the USB and Linux were set up properly: https://www.verizonwireless.com/dam/support/pdf/user_guide/u620-linux-integration-guide-7-17-15.pdf .
JoshuaT_VZW Follow us on TWITTER @VZWSupport
If my response answered your question please click the Correct Answer button under my response. This ensures others can benefit from our conversation. Thanks in advance for your help with this!
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
> My device works as a router for an internal WiFi network.
> Oct 12 16:47:07 (none) ccm: [CCM_S] -{mifios_sysevent}:Removed IP client: mac=00:15:ff:00:00:00, ifc=USB, type=DHCP, ip=[reserved], host=LTJVILELA
> Oct 12 16:47:20 (none) ccm: [CCM_S] -{mifios_sysevent}:New IP client: mac=00:15:ff:00:00:00, ifc=USB, type=DHCP, ip=[reserved], host=MK5
These two events show different IP addresses from Verizon's carrier-grade NAT with a 13 second difference between them. This isn't Verizon playing up on you, this is Verizon responding to conditions on its network and the modem reacting to the change. It seems to me that by responding this way it is likely seeing the two host= as two different network devices trying to use the same modem so it removes the old in favor of the new. A router should make both host= look the same going to and then through the modem. IIRC, the only difference in the source packets between the two host= should be the port NAT assigns when striping off the non-routable IP address--are you sure your sharing logic is doing this?
Are the non-routable IP addresses you're getting at host=, 100.64.0.0 to 100.127.255.255?
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The two host described above are independent. They are not in the same network. I connect the MiFi to a laptop (LT..) and then to the embedded computer (mk5).
my virtual router only consist in IPTables configuration described above:
# Internet Sharing Setup
sudo -u "$user" sysctl -w net.ipv4.ip_forward=1
sudo -u "$user" sysctl -p
sudo -u "$user" iptables -I INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
sudo -u "$user" iptables -I FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
sudo -u "$user" iptables -t nat -I POSTROUTING -o eth1 -j MASQUERADE
I will verify about NAT support.
Also, the android phone is the only device going out to the internet behind the WiFi network. I disabled Google Store automatic updates and the connection had been improved a lot! almost no disconnections.