Wireless Joint

Some are experiencing issues with reconnecting to a cellular network after losing its connection. Usually, a hard reboot is required to reconnect.

UPDATE 03-08-2019: Our latest WiFiX 2019 version of GoldenOrb contains an internal ping script that runs in the background that resets/reboots the modem. As always when upgrading a router's firmware, be certain to UNCHECK the box to Save Settings.

The instructions and tasks below are no longer required when using the WiFiX firmware. The discussions below are for reference only.

For those running any brand or version of GoldenOrb (i.e., ROOter, WiFiX) firmware, you may want to try this modification.

It will modify a script in the firmware so that the AT!RESET is issued to the modem after the ping test fails.

This modification will apply to the 'Enabled with Modem Reconnect' option in the Connection Monitoring.

Using WinSCP (free download) you will need to access the firmware files.

In the conmon.sh file located at:
You will need to use a program like Notepad++ (free download) to edit the file, and change line 48 from :
to
In the alternative, you may want to just comment out the original ATTCMDD… by using the # sign, and add the new command right below it:

Save the file.

Go to Connecting Monitoring and enable ‘Enabled with Modem Reconnect’ and set the tracking IP to 8.8.8.8 and Save & Apply.

Reboot the router for it to take effect.

UPDATE: 1-15-2019

John (one of our customers) created a ping script that runs as a cron job--and runs independent from the Connection Monitoring ping script. Johns_ping script acts as a backup when all else fails.


The script should be placed in the directory at: /usr/lib/rooter/connect/

Next, go to SYSTEM > SCHEDULED TASKS and set up the cron job:

great idea Jim! It's funny you just posted this, cause I was thinking it would be nice to have the option to issue the at!reset command instead of USB rebooting the modem, or restarting the whole router.

Just thought I'd follow up on this. I set this up on my GoldenOrb install, and it worked great. Last night I had a couple disconnects, and the modem was reset and it easily re-established connection very quickly.

Is there a way to just reset the wan1 interface instead of the modem? I have found if I manually reset just the wan1 interface, the connection comes back very quickly, with only a few packet drops.

drakax wrote: Tue Dec 04, 2018 6:56 pm Is there a way to just reset the wan1 interface instead of the modem? I have found if I manually reset just the wan1 interface, the connection comes back very quickly, with only a few packet drops.

what do you mean by reset the wan1 interface? what commands are you running to do that?

So to give a bit of background, I have been having a terrible time with Sprint dropping connectivity. I have found that the actual LTE connection remains, but somehow the IP traffic is not being passed. When this happens, a simple "ifdown wan1 && ifup wan1" brings the connection back very quickly, and does not cause the reset of the modem, and re-connection to the tower, without having to wait through the entire process of the modem restarting, finding the tower, connecting, getting an IP.

I am currently trying to see if just forcing udhcpc service to release and renew the ip causes the connection to come back.

#!/bin/sh

# get pid of udhcpc
PID=`pidof udhcpc`
#release dhcp lease
/bin/kill -SIGUSR2 $PID
# renew dhcp lease
/bin/kill -SIGUSR1 $PID

drakax

Any success with this? I am running into the same issue.

I have been travelling for work, so i set it to band 25 before I left, since that never has issues. I am testing today, and will post back if I find out anything.

I joined just to keep a eye on this, ever since a tower upgrade, with my mc7455, I can no longer surf the web but still ping. This happens very irregularly, sometimes 6hrs, sometime 48hrs, and connection monitoring does not work, because ping still works.

I have not had a chance to put it into the connection monitoring script, but I did create a simple shell script to run it from the custom command line, and it brings it back online instantly.

I went out and got the verizon prepaid plan also (i travel alot), and swapped the sim, it stays up all the time with 4g from verizon. It seems to be something not jiving with sprint and the mc7455, or something with openwrt. I am not sure which.

I edited my original post and attached a ping script that should help resolve several related issues.

Just wanted to comment on this thread with some info on what I experienced implementing this MOD. To re-cap, I was also getting a dropped internet connection (i.e. wifi devices indicated they were connected but no internet present) - however the modem did appear to still be connected. I was doing a hard re-boot to remedy.

I'm using a WG3526 + MC7455 & WiFIX GoldenOrb (9/2/2018). When I tried to connect with WinSCP, I kept getting a connection refused message. Under System -> Administration ->SSH Access, I had to change the Interface from unspecified to explicitly allow access from the LAN, even though unspecified should have allowed it. Once I did that I was able to connect and modify the files as necessary and add the John's ping script, etc.

So far I haven't had any further connection issues.

Our latest WiFiX version of GoldenOrb 2019 has the reconnect ping script configured internally. This should help resolve this issue.

Jim,

When using the aforementioned WiFix version with the ping script, what connection monitoring settings should be selected?

daniel.hulse wrote: Tue Jun 04, 2019 10:33 pm Jim,

When using the aforementioned WiFix version with the ping script, what connection monitoring settings should be selected?

Depending on Carrier and 'if" it is not Sprint, I would try it without the connection monitor enabled. On Sprint, i would use the default settings.

To back up what Jim said, I recently put together a WE1326 and an EM7565. I'm using the generic firmware that came with the modem and the latest WiFiX firmware for the router. I haven't enabled the connection monitor and haven't noticed any problems so far. I've had it on for about 24 hours at a time, max, however, so I can't comment on longer runtimes. I am on AT&T.

Jim, is there a document/post that maps settings to carrier for using the ping script with the connection monitoring?

xdavidx wrote: Wed Jun 05, 2019 2:20 pm
Jim, is there a document/post that maps settings to carrier for using the ping script with the connection monitoring?

No, but I have been meaning to work one up (with a thousand others) but have not had the free time to do so.

Please feel free to post one.

I would, but I don't know the values.

There is no rush for me. I just figured since it was on topic, I'd ask and save the link if something exists.

xdavidx wrote: Wed Jun 05, 2019 4:00 pm I would, but I don't know the values.

There is no rush for me. I just figured since it was on topic, I'd ask and save the link if something exists.

I don't know the optimal values either. A lot of this is trial and error, or searching the ROOTer forum.

JimHelms wrote: Fri Mar 08, 2019 9:54 am Our latest WiFiX version of GoldenOrb 2019 has the reconnect ping script configured internally. This should help resolve this issue.

I noticed that my router is rebooting every night at just after 3 am. I'm running the WiFix firmware. Does the built in script do a reboot regardless of connectivity every night?

xdavidx wrote: Sun Jul 07, 2019 2:02 am I noticed that my router is rebooting every night at just after 3 am. I'm running the WiFix firmware. Does the built in script do a reboot regardless of connectivity every night?

The reboot script acts as an alarm clock-- a sort of reminder that it is way past your bedtime. haha

Actually, the scheduled reboot is designed to clear out the router’s volatile memory (which is both a security and performance feature) and renew the cellular connection and IP address via the modem rebooting (which helps to resolve a modem that is placed in an idle position).

We do have plans for the next WiFiX builds to expand the feature to include user controlled options and settings. The WiFiX builds are geared toward using the router for cellular applications--where the standard GoldenOrb builds extend to include non-modem routers. We attempt to resolve various (and common) issues that users have historically experienced with these type of cellular applications.

For now, those who find it annoying or do not want to use the feature, can either modify the internal script by commenting out the line of code or deleting the script altogether. See, [url=http://wirelessjoint.com/viewtopic.php?f=12&t=397&sid=86164633f887704999c1b5a916bc1aa4] THIS[/url] post.

The reboot cronjob script is located at: /etc/crontabs/root

The custom ping script is located at: /usr/lib/custom

Or, in the alternative, use a standard build of GoldenOrb for their router.


Those members that have been around for several years when the original Hacks forum was active (before the database corrupted and crashed), can appreciate how this technology and router firmware have evolved into a usable product. Long past are the days of having to compile LEDE and manually write/modify and install .sh, gcom, network, connect, reconnect, MBIM scripts, etc... to get a modem connected.

But, at the same time, the innovation (and customization) has depreciated. As an example, I ran across the image below while searching my files for a specific script that someone was needing.

JimHelms wrote: Sun Jul 07, 2019 7:12 am The reboot script acts as an alarm clock-- a sort of reminder that it is way past your bedtime. haha

I need more of those!

JimHelms wrote: Sun Jul 07, 2019 7:12 am Actually, the scheduled reboot is designed to clear out the router’s volatile memory (which is both a security and performance feature) and renew the cellular connection and IP address via the modem rebooting (which helps to resolve a modem that is placed in an idle position).

Can you elaborate on the security implications? Do you mean booting out the bad guys if they somehow connect to it on the WAN side and getting a new IP address so they can't easily find it again?

Is there any negative to keeping the same IP address as far as the cellular providers are concerned? Do they use that as a mechanism to determine who might be using a sim in a router instead of a phone/tablet?

JimHelms wrote: Sun Jul 07, 2019 7:12 am For now, those who find it annoying or do not want to use the feature, can either modify the internal script by commenting out the line of code or deleting the script altogether. See, [url=http://wirelessjoint.com/viewtopic.php?f=12&t=397&sid=86164633f887704999c1b5a916bc1aa4] THIS[/url] post.

I *knew* I had seen something about 3 am before. I thought it was just my mind playing tricks on me, because I thought it was in this thread we are in now. I couldn't find any mention of it, so I figured I dreamed it up. In my case, it isn't currently causing me any problems. I just wanted to know where it was coming from. Thanks for clearing that up.

JimHelms wrote: Sun Jul 07, 2019 7:12 am Those members that have been around for several years when the original Hacks forum was active (before the database corrupted and crashed), can appreciate how this technology and router firmware have evolved into a usable product. Long past are the days of having to compile LEDE and manually write/modify and install .sh, gcom, network, connect, reconnect, MBIM scripts, etc... to get a modem connected.

You have my condolences.

xdavidx wrote: Sun Jul 07, 2019 2:35 pm
Can you elaborate on the security implications? Do you mean booting out the bad guys if they somehow connect to it on the WAN side and getting a new IP address so they can't easily find it again?

You will most likely find some information by googling "security rebooting router" or something similar.

Is there any negative to keeping the same IP address as far as the cellular providers are concerned? Do they use that as a mechanism to determine who might be using a sim in a router instead of a phone/tablet?

During prolonged periods of data inactivity, carriers can reduce their overhead by releasing the modem from the network without actually disconnecting it--thus placing the connection in an state of idle.

We have seen instances where the modem would not wake up from idle--even though it is still connected to the network. There is an official term for this but I cannot remember off the top of my head exactly what it is called... something...dormancy.

JimHelms wrote: Sun Jul 07, 2019 4:42 pm You will most likely find some information by googling "security rebooting router" or something similar.

I'm aware of the VPNFilter attack from early 2018. I guess I assumed firmware would have been patched by now. Has that come up as an issue with GoldenOrb?

I guess that's one good thing about carrier grade NAT. Harder for the bad guys to gain access from the WAN side of the routers.

JimHelms wrote: Sun Jul 07, 2019 4:42 pm During prolonged periods of data inactivity, carriers can reduce their overhead by releasing the modem from the network without actually disconnecting it--thus placing the connection in an state of idle.

We have seen instances where the modem would not wake up from idle--even though it is still connected to the network. There is an official term for this but I cannot remember off the top of my head exactly what it is called... something...dormancy.

That's nice of them.

Thanks again for the info.

What's the difference in using AT+CFUN=0;+CFUN=1,1 versus AT!RESET to reset the modem? I see the steps above to use RESET and comment out CFUN, but /usr/lib/custom/johns_ping.sh on my WE1326 GoldenOrb_2019-04-09 has AT!RESET commented out and uses the CFUN command to reset the modem.
My modem will not connect back to the router after a soft reboot without a power down/up or a modem reset by one of the previously mentioned commands. AT!GSTATUS shows the modem still connected to the provider, but no network ping and router Modem|Network shows disconnected. I would like to understand the difference between the commands and if one way is better than the other and why. Also if there is a reason the modem has to be reset after a soft reboot and if there's something I need to update/change to correct for this. Otherwise the setup works great
Thanks.

JimHelms wrote: Sun Jul 07, 2019 7:12 am

But, at the same time, the innovation (and customization) has depreciated. As an example, I ran across the image below while searching my files for a specific script that someone was needing.


Custom Bands and Carriers.png

Do you mind sharing that image with built in gcom scripts?

Is anyone using Connection Monitoring in Rooter? I am trying it out with a 10 min interval.

Lots of us have. I tend not to use it. Sometimes it can cause reboots when it's not necessary and I don't know why. The latest versions do have a cool page load versus ping feature though.