I'm trying to send UDP packets over the t-mobile NB-IoT network using AT-commands on a SIM7020E chip. I used the product wiki as reference. The starter version of the sim card I have doesn't support TCP, but I'm planning on using that later if I can succesfully communicate using UDP.
I created a UDP-socket on a Raspberry Pi using "nc -u -l 9999". I set an A-record on my hosting provider to refer dev.mydomain.com to the IP address of the Raspberry Pi. I verified the portforward and A-record settings by sending UDP packets from my laptop on another network using "nc -u dev.mydomain.com 9999" and typing some teststrings, so this all works.
On the 4G chip I use the following AT-commands:
// Check network
AT+CSQ
+CSQ: 21,0
AT+CGREG?
+CGREG: 0,5
AT+COPS?
+COPS: 0,2,"20416",9
AT+CGCONTRDP
+CGCONTRDP: 1,5,"iot.t-mobile.nl","x.x.x.x.255.255.255.0" <-- crossed out my ip
// Create UDP socket
AT+CSOC=1,2,1
+CSOC: 0
// Connect socket 0 to the listening port on the Raspberry Pi
AT+CSOCON=0,9999,"dev.mydomain.com"
OK
// Send "test"
AT+CSOSEND=0,0,"test"
At this point I expect to see "test" appear in the command line on the Raspberry Pi, but nothing happens. In the T-mobile portal it shows a PDP-context is successfully activated.
Also, setting the APN manually with AT*MCGDEFCONT="IP","iot.t-mobile.nl","username","password" doesn't work.
Did you work this out Hans? I was plodding along with a SIM7020E following https://www.waveshare.com/wiki/Pico-SIM7020E-NB-IoT code examples. Was successfully sending HTTP GETS to a server (without having to use micropython's wretched urequests lib) via the CHTTPCREATE/CHTTPCON/CHTTPSEND AT cmds, that seem to be be able to send packets over LTE to a server without specifying TCP/UDP etc or using a socket. Maybe give it a try?
Sadly I got the bright idea of trying an 'AT+POWD=1' cmd over the uart (was supposed to power the 7020E down) & now the module now does nothing but echo AT cmds (still auto connects to the LTE network & slow flashes the network led, just won't do anything else.) Real shame, nice little module otherwise.
Related
I have the following connection in Ubuntu
Linux PC -> Switch (PoE) -> DUT
with the following ip configurations:
Ethernet adaptor Statically assigned
BASE IP (ipv4): 10.0.0.1
subnet : 255.255.255.0
gateway : 10.0.0.0
eth0 network address : 10.0.0.3
This setup enables me to send and receive UDP packets.Works perfectly fine in Ubuntu.
Now in Windows, I have made relevant changes to the python code of the codebase, but the code gets stuck waiting for UDP packets from the Hardware. I have statically assigned the same values as in Ubuntu. I am very new to networking..
(1) I have ensured Firewall is allowing UDP packets
(2) I have made the same IP address,subnet,gateway settings configurations.
Where am I going wrong?
It's impossible to say exactly what goes wrong based on this information.
I'd suggest trying Wireshark from https://www.wireshark.org/.
With that running on your windows PC, you can see if your packets are being sent out or not, and you can also see if the device responds or not. That way you can determine if the problem is in sending or receiving the packets.
I have a problem with getting GSM connection to work.
Currently used:
Advantech UNO-2272G device
Ubuntu 18.04
NetworkManager/nmcli package
The card works when put in a mobile phone.
*Note: following screenshots are made over SSH and remotely, as the device is currently plugged in ethernet until this issue is resolved.
This is current state of "nmcli" command:
nmcli print
The system connection for GSM is called "radi". My guess is that somehow the interface of that connection is trying to work with the other interface (underlined in red), which in turn is trying to get its DNS conf from router (to which it currently is connected with ethernet, but nothing changes if device is plugged out from router and NetworkManager and network is restarted, it still tries to get to router for its DNS).
This is current state of "ip addr" command:
ip addr
This is current state of /etc/network/interfaces file:
interfaces
This is current state of /etc/NetworkManager/system-connections/radi file:
systemconnection
So, the question is, what am I missing here? Is it the interface issue as written above, or something else entirely?
Disclaimer: I am not that proficient in the stuff presented here, most if not all of it was configured following guidelines on the internet.
Hey I'm not expert in this but I do have a different cellular modem connected to a linux system (RPI) and working with NetworkManager (and ModemManager). My modem was connected by a serial UART port (ttyACM0) so that seems similar to what you have done.
When I configured my cellular connection profile in NM I had to setup the ppp section of the connection profile on top of the gsm part. I also went into my ppp options (on the host) and configured those to match a chat script that came from my modem manufacturer. WHen NetworkManager runs a ppp interface it expects the ppp options for the pppd (daemon) to be configured properly.
Here is the ppp section of my NetworkManager cellular connection settings file. Most are defaults and in my case I only added the baud rate for my modem (since it was connected to a UART).
ppp.noauth: yes
ppp.refuse-eap: no
ppp.refuse-pap: no
ppp.refuse-chap: no
ppp.refuse-mschap: no
ppp.refuse-mschapv2: no
ppp.nobsdcomp: no
ppp.nodeflate: no
ppp.no-vj-comp: no
ppp.require-mppe: no
ppp.require-mppe-128: no
ppp.mppe-stateful: no
ppp.crtscts: no
ppp.baud: 115200
ppp.mru: 0
ppp.mtu: auto
ppp.lcp-echo-failure: 0
ppp.lcp-echo-interval: 0
If this is not helpful then have a look at this thread on NM and routing. In their case eth0 was a local network interface and eth1 was their cellular interface
Now to save you 10 hours of troubleshooting - note that the route
metric is independent of the DNS priority! So if you still have
connectivity issues, make sure it's not a DNS resolution issue (eg.
your DHCP server is providing a dummy resolution service). If it is,
then increase the ipv4.dns-priority of your eth0 connection to make it
lower priority, and/or make sure the ipv4.dns-search of your eth1 is
set to "~" to make it the go-to option.
I've made a project to send sensor data from
STM32F767ZI
nucleo board
(Client) to a desktop computer (Server), using ethernet and lwip with
FreeRTOS
on
STM32CubeIDE.
The nucleo board is connected with ethernet cable to a wired broadband router, to which the desktop computer is also connected.
In a terminal running under Ubuntu, I am sending a ping message as:
$ sudo ping 192.168.0.3
However, with same code and configurations, the result of ping test is
Destination Host Unreachable
or
64 bytes from 192.168.0.3: icmp_seq=1 ttl=255 time=0.864ms
When the ethernet connection is built successfully, the result of ping test is done correctly and continuously. However, when I try to rebuild the project with the same code and configuration and I use debugging mode, the same ping test fails.
After these findings, I tried to reconnect ethernet in various ways like changing cables, rebooting the board or computer, and reconnecting the debugging port.
Sometimes it works, but then the connection is fails again while I redo the same procedure that worked well before.
What can be wrong about the setup? What should I change?
I am using fauxmo to have Alexa trigger a script on a Raspberry Pi, which then triggers a BroadLink RM hub to send out IR and RF signals for my home theatre.
This has worked beautifully for a year or two, and yesterday it stopped. I did not touch anything, I swear!
I found out that fauxmo does no longer receive Alexa discovery requests.
When I ask Alexa (voice/web/app) to discover devices, it sends out SSDP M-SEARCH requests to 239.255.255.250 1900. I can verify this using Wireshark on a Windows laptop.
However, these requests do not seem to get to the Raspberry Pi anymore. I have tried with two Raspberries. Confirmed they are on they same WiFi network, which is Google Wifi (and confirmed Upnp is enabled). And I powercycled Alexa and Google Wifi.
I also sent M-SEARCH requests locally on the Raspberry Pi, and those are received.
window 1:
sudo tcpdump -n udp dst port 1900 -A
window 2 (on same Pi):
echo -e "M-SEARCH\r\nurn:Belkin:device:**" | nc.traditional -q 1 -u 239.255.255.250 1900
window 1 result:
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on wlan0, link-type EN10MB (Ethernet), capture size 262144 bytes
02:06:41.485902 IP 192.168.86.247.45796 > 239.255.255.250.1900: UDP, length 31
E..;+.#...FO..V........l.'m.M-SEARCH
urn:Belkin:device:**
However, if I do this on 2 Pi's (window 1 on one, window 2 on the other), the request is not received. Actually, I also tried with another Ubuntu machine, so it's not specific to Pi.
I thought that it could be a general network issue, but then I would not see the Alexa requests on my Windows laptop.
I am at a loss - I did not make any code or configuration changes (actually it worked at the beginning of a movie "Alexa turn projector on", and it did not work after the end of the movie "Alexa turn projector off").
Wiring the Pi to the Google WiFi pod worked, I posted this at Google WiFi instead - https://support.google.com/wifi/thread/13904262
I am using raspberry pi
I am using signalR to send data to my client browser.
If my raspberry is on the same network via Ethernet or WiFi then I can get it to work.
If I now disconnect Ethernet and WiFi and switch on my gsm module I get assigned a dhcp address like 10.126.88.4 etc
If I now go to a client browser and type that ip address in the browser it will eventually time-out and upon investigation I find the raspberry pi has been assigned a different IP address.
This happens every time I refresh the browser.
After googling I find that it is the network providers doing this to stop the gsm being used as a server gateway.
One of the solutions is to use a proxy server but I could potentially have a lot of data passing through and
my initial idea was to have client browser talking directly to the raspberry pi device using gsm and thus not going through my own server.
Is there a solution to my predicament?