Wireless Joint

On my GL-iNet MiFi, I'm able to SSH in to the router and enter something like this:
And it will return the information I requested (in this case, the set band). Note that the above is copy/pasted from android code and I actually lost the *exact* stuff I used to be able to send in terminal via ssh. But I do know that it a) worked, and b) didn't hang anything - as in after it replied, I could enter another command.

I moved my EC25-AF modem from the MiFi to the new NEX6QGO and ssh'd in the same as before. But I can't get my AT commands to execute, and I cannot enter another command - like it's still waiting for me to complete entering the command... no cursor returned to be able to type more. So my syntax is incorrect or it's expecting something else at the end (maybe a line break) to signify the end of the command?

IN SHORT

Can anyone tell me exactly what they enter in to terminal while SSH'd in to this router to get back some basic data?
AT+CSQ would probably be a good one as it doesn't involve escaping quotation marks and stuff, very vanilla.

Once I can figure out how to make it happy and give me data back while ssh'd, I can work on some other crap (sending AT commands over NEX serial pins, parsing response)

Thanks!

lookup using the socat command


https://openwrt.org/docs/guide-user/net ... t_commands

you can also use picocom or microcom if they are installed

Didneywhorl wrote: Thu Feb 03, 2022 6:27 pm you can also use picocom or microcom if they are installed

Thanks for the leads! I ended up doing http calls which actually worked out better in terms of parsing... picking pieces out of AT responses can be a chore, especially when you can't bank on a value being in the same position all the time.

May be a little less reliable than reading over serial, but I'm making the same calls that the WiFiX console is (after I do a login call). If any of the details calls get back a bad response code it'll force another login to hopefully clear it up.

Getting the basic info (signal, mode, band, temperature) comes from /cgi-bin/luci/admin/modem/get_csq - same as WiFiX. Easily digestible JSON once you trim off everything that isn't a numeric in the field's value.

Getting the locked band(s) involves calling /cgi-bin/luci/admin/modem/check_misc - also same as the WiFiX router. I can then match the enormous and convoluted "bndstr" value to something like bands 2, 4, and 71.

Band locking was done by just copying the URLs fired by WiFix's little check box band picker thing. Copied URLs and "bndstr" values for all the combinations I'll use. Ex:

Fire the call using the _PATH bit, wait for /modem/check_misc to return the _CODE bit for bndstr.

Interesting! Do tell more!

If anyone were trying to do something similar, the easiest way would be to download the Postman browser app or something similar for naming and organizing your web calls. It can generate cURL commands for pasting in terminal, but is really just a great source of truth. If it's working in Postman, you can figure out a way to make the same calls from anything web connected. I used Chrome's Inspect->Network tab to look at the calls being made by WiFiX. Then I right clicked on them and opened them in a browser to discover lovely JSON. The same was true for setting bands - looked at what was executed from the router UI when I had a number of bands selected and pressed save/apply (and confirmed the "modem will reconnect" prompt).

The Particle Photon microcontroller is cool because it works on their cloud, which has been rock solid reliable for the near decade I've been using their products. You can define variables and functions in your code. For instance, I have a function called "setTheBand" that expects an integer. 2 = B2, 4 = B4, etc. 24 = B2 & 4, 2471 = B2, B4, & B71, 99 = all bands that my carrier supports.

When that function is executed from their console (or via HTTP, all Particle cloud stuff is accessible via simple HTTP GET and returns JSON) I match up the requested band(s) to the correct SIERRA_####_PATH and fire out the request. Then I sleep the microcontroller for a minute or so before it starts trying to hammer the router for info. This allows for the modem to reconnect and stuff.

The Particle variables can just be a String or something defined in your code.
Every time I parse the data from /cgi-bin/luci/admin/modem/get_csq I update the mode variable (LTE, or whatever) and can then access that variable from the Particle console or again by HTTP GET. But that's a bunch of requests to populate a user interface, which is what I use this data for. So I build out JSON strings to return as a variable and try to keep them as compact as possible.

There's always the chance that I screw something up like band locking to something that isn't available. If the Particle Photon can't reach the cloud, I can't access it through the console or HTTP get. So, they run a local web server too. As long as they can hop on a network (static IPs for the photons) then I can still access them, and make the call to lock to all bands instead of the troubled one I had just tried.

Here's a screenshot from the particle console showing a bunch of combined data, or calls to get individual values which I was using in testing this afternoon. You can see that I'm locked to bands 2, 4 and 71 by the "2471". The two following that indicates that the router is actually on band 2. I need to update that data structure now that I have a modem capable of CA, so I can return "2|71" as an example.. which isn't numeric.



This router lives in my truck, so I built an app to run on my truck's Android head unit. Also built a phone app to use. These apps query the router microcontroller and also another microcontroller that controls my DIY lithium iron phosphate battery in the truck bed. The end result is a ton of geek information for the battery and the router. If the truck is on the same network as the lifepo4 battery and router (which it should be, since it lives in there) then it uses local requests via the microcontroller's webserver. Otherwise it defaults to fetching from the particle cloud HTTP GET. App does the same.. if it fails to fetch locally it'll pull from the cloud.

When I start snooping around the woods trying to find a camp site (all over national forest), I can easily test bands to see what's going to work best for my morning work video meeting. Hate to say that this usually factors in to the spot I pick.



Can see everything going on with battery and router, lock bands, run connection tests, set the heating temperature for the battery (so it can charge when its 0*F outside), log data, galore. Phone app is a little more spartan.

So there's about everything there is to know about why this was important to me, and not a functionality I wanted to lose upgrading routers. I also installed the MC7411 and good grief it's amazing how much better it is than the EC25-AF. Excited to see how uploads do in the woods where I usually camp - as I've had to disable my video most of the time for years. DL speeds doubled/tripled and uploads tripled/quadrupled at home.