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.
Related
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.
I have a local Linux machine (L), with a network interface (eth0) connected to (currently) only one device (D).
L/eth0 only has an ipv6 link local address.
D also only has an ipv6 link local address.
Client software on L discovers D's link local address by sending a custom multicast packet over eth0. The response contain the device link local address as well as some configuration information. From there it communicates with the device using various UDP or TCP port.
My goal is to be able to use the device from a remote machine (R). The remote machine being most likely a Linux docker container running on some host - although it could be a native macOS or other.
That means running both the discovery protocol and communicate with the device. I definitely cannot modify software on the device, and cannot modify most of the client software running on the local Linux or remote machine (Limited modification could possibly be requested)
My idea was to somehow create a virtual interface on the remote machine, that would remotely be bridged to the the local machine, so that the multicast discovery works from the remote, and so that I can just connect to D link local address from the remote.
I'm not sure which tool(s) I should be using.
I'm googling various things about VPN and tunnel, TUN/TAP interfaces, bridges, VETH, VLAN, etc... but I'm having trouble connecting the dots here... I have no budget for this, so I'm looking for open source tools, or just something I can cobble up together with common tools.
Thanks
I am generating UDP packets on a 100 multicast groups on one VM Ubuntu 16.04 machine and subscribe to those groups on the other VM Ubuntu 16.04 machine. Both are on a HP server run by Hyper-V manager. The problem is that my application only receives 2 out of 100 groups. However, when Wireshark is capturing, the application starts receiving all messages.
I found several other similar questions like this one, where it explains that because Wireshark is running in promiscuous mode, it allows all packets to get through (through what?), and this explains why my application starts "seeing" them too. Thus, changing the Ethernet interface configuration to promiscuous mode allows the application to receive all the messages without running the Wireshark.
But what is the problem with the other packets that are not normally received? I tried to cross-verify the hex-dump of the "good" and "bad" messages and they don't seem to be different. The check sums for on the IP and UDP levels are correct. What else could be the problem?
Multicast ip range 239.1.4.1-100
Destination port 50003
Source port range ~33000 - 60900
firewall is disabled
EDIT:
It looks like when the application is subscribed to only 8 multicast groups, it works fine, however, if subscribed to more than 8, it receives only 2 (if they end on .7 or .8) or none, as described above. So, I would assume that the packets are correct. Could the problem be in the network settings? Or the application itself - need to find the bug in the script I did not write.
EDIT2:
I installed the ISO image on the other machine (Virtual box instead of HP Windows Server) and it works as it should. Thus, I assume my application works fine and all the ubuntu OS configurations are correct. Now I put all the blame on the Virtual Manager/settings. Any ideas?
It sounds as if you didn't tell the kernel about them.
See http://tldp.org/HOWTO/Multicast-HOWTO-6.html
You have to use setsockopt with IP_ADD_MEMBERSHIP. And be sure to use the correct values for your local interfaces.
I have two applications communicating on same machine (localhost) using socket. If application are on different machine I can use Wireshark. But how to capture packets on same machine.
I do not know on which port number application are communicating. Because I am using library calls and do not know lower level details.
We are having our application on Ubuntu and Windows XP.
On Linux you can use netstat to determine the ports that your application are using. Then you can use Wireshark to capture on the loopback interface (just enter your own IP address if 127.0.0.1 dont work).
Refer to: https://stackoverflow.com/questions/1566234/ for capturing on Windows.
I'm using this python example to test a connection using broadcast udp packets. For some strange reason I can see the packets coming in on my RHEL server through wireshark (not in promiscuous mode), though the python recv doesn't get them. Sending the packets on the same computer to 'localhost' does work. Also, using a different pair of computers, my code does work. So I have this specific RHEL computer that's problematic.
I've tried binding on 127.0.0.1, 0.0.0.0, 255.255.255.255 to no avail. I turned off SELinux, the RHEL firewall, iptables and ip6tables. I checked netstat and see my python script is the only one listening on that udp port. In thor's name what's wrong?
Got it! This is the command that fixed the problem:
ifconfig eth2 -broadcast 30.255.255.255
The original Bcast address was 30.0.0.255 and I was broadcasting to 30.255.255.255, so while wireshark saw this as a relevant Bcast (not promiscuous), the OS did not.