I am using RAK7258LTE and found annoying problem with it.
The problem is related to the settings of the LTE module (it is impossible to establish a connection with a known good AT&T SIM card tested on other equipment).
In fact, it looks like the module is working. From the gateway interface, I see that there is an exchange of packets. In fact, this is not the transmitted / received packets, but the exchange of the gateway with the LTE module.
In all cases, Quectel Support recommends using (and provides on their website) the latest drivers.
But here we are faced with the problem of a “commercial gateway”.
It is impossible to install additional packages or update from the developer’s repository by standard means.
It seems to me that the gateway developers could create a driver repository so that users can perform driver updates without affecting the “commercial” OpenWRT (!) System as a whole.
But this is from the area of ​​wishes, while the problem continues.
Out tcpdump for eth0 and wwan0:
I checked the /etc/apns-full-conf.xml file and added the APN “AT&T Broadband” to it because I couldn’t find such an entry.
The data was taken from the official page https://www.att.com/support/article/wireless/KM1062162/
I’m not sure, but it seems to me that the APN “ATT NEXTGENPHONE” is also incorrect. At least they don’t match those given on the official AT&T page.
However, the problem continues. Disconnecting ethernet (eth0 interface) does not switch to wwan0.
Given that this gateway is not designed to support GPS and lacks the routing of a PPS signal between any GPS capability that might be present on a modem and the concentrator meaning the GPS won’t really be usable for LoRaWAN no matter what you do, I’d recommend that you don’t try to do that; among other things, it could contribute to connection problems as the modem may dislike having two channels of communication going on at once.
The connection problem was ORIGINAL, that is, long before my experiments with GPS.
If everything worked as expected initially, most likely I would not get into such “jungle”.
Although absolutely all sources agree that obtaining PPS from a GPS receiver is the best of all possible options. Excluding, perhaps, the use of the atomic time standard
Therefore, I do not lose anything, and the information may be useful to someone, since support is silent.
You seem to not really understanding how a gateway would interact with GPS: without a PPS signal, the packet forwarder simply can’t use the GPS for timing at all. And you presumably know where you put the gateway, so there’s not much use for positioning either.
Given that GPS is not a supported or supportable feature for this hardware, that whole aspect of your thread is just noise.
Drop that and focus on the connection issue alone.
Generally speaking, this particular gateway was purchased by me specifically for the purpose of experimental verification of the possibility of organizing coverage in separate small areas.
That is why I needed a gateway with the ability to reserve a communication channel via 3G/4G/LTE.
It would be even more convenient if I could get information about the position of the gateway - just so as not to manually do a bunch of additional work with coordinates.
Since the backup channel does NOT work initially, even if this is the only communication channel, not to mention switching from ethernet, I started looking for information about the LTE EG95-NA module, among other things, I came across a mention of GPS. Which I checked.
Given that the equipment is not able to function as the manufacturer claims, I see no reason why I cannot try to figure it out on my own.
If at the same time I can find useful things / solutions for myself (and possibly for the manufacturer), then where do you see the problem?
You’re much less likely to get help from the manufacturer when you distract from issues with the sold functionality by filling up the thread with attempts to make it do something it was never intended to.
Perhaps you `re right. However, judging by the fact that I see reports of similar problems from other contributors, support is not at all rushed. In some cases, support does not even make it clear that users’ messages have been read.
However, this is not a place to request functionality or make claims, it is a forum where we can discuss certain aspects of equipment and its functioning.
By the way, I am surprised by the fact that the firmware does not include a program for working with AT commands of the module. It is possible, but very inconvenient. And available informational messages in the logs do not provide any useful information (except for outright errors).
It was a good idea to install the socat package (socat_1.7.3.0-1_ramips_24kec.ipk from the OpenWRT version 15.05 archive).
Run: socat - /dev/ttyUSB2,crnl or socat - /dev/ttyUSB2.
String “crnl” indicates the need to automatically add CR (Carrige Return) and NL (New Line) to each command.
