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.
Related
I need to find out the devices IP so that I can manually set my laptops computer to the devices network and reconfigure the devices IP. I have only its MAC address which was acquired from the devices label. I am new to networking trouble shooting. I am hoping to do this using Windows PowerShell, but I also have wireshark and linux available.
This might help you if the firewall is not active on that device.
In one cmd.exe ping your broadcast address, assuming your ip is 192.168.0.X
ping -t 192.168.0.255
In another cmd.exe window type arp -A to see your ARP table aka MAC to IP address table, because you mention you have the MAC you should be able to see the IP
arp -A
How it works? This will send ping packets to the broadcast address, everybody on your broadcast domain will see the packet and respond to it, once they respond they will be added to your computer ARP table.
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 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 am trying to make a connection between my pod and a camera through RTSP (using ffmpeg).
My container, when running locally and in the server can establish the connection.
However, in Kubernetes, looks to be able to reach and identify the camera server, but it can not initialize a stream. I did a tcpdump on my container when trying to connect and I received the following:
10:55:37.065954 IP **CAMERA_SERVER_IP** > **POD_NAME**: ICMP **CAMERA_SERVER_IP** udp port 36337 unreachable, length 44
10:55:37.066003 IP **CAMERA_SERVER_IP** > **POD_NAME**: ICMP **CAMERA_SERVER_IP** udp port 36336 unreachable, length 48
**CAMERA_SERVER_IP** -> is the camera server IP addresss
**POD_NAME** -> is my pod's name in kubernetes.
When I try locally, the first UDP port fails too, but the second can establish a connection and stream.
I think this has something to do with port communication, but I am bit lost in what I should try or test.
Thanks!
UPDATE*
Actually I found something strange.
I tried again to start the connection and I analyzed the logs from tcpdump and netstat -tulpn.
When connecting locally, netstat identified the creation of two UDP connections. And tcpdump showed ffmpeg was trying to reach a connection from the server using the same UDP ports from netstat
However, in a pod in Kubernetes, the ports opened on netstat were different from the ports that ffmpeg tried a connection (verified using tcpdump).
I think this is the error, as ffmpeg immediately fails when trying to access a port that is not opened.
I actually made a work around using another ffmpeg server wrapper as I explained here: https://github.com/kubernetes/kubernetes/issues/94561
If someone has a similar problem, specially with Intelbras DVR or those that use DAHUA API, this might be interesting to read.
I have a TCP server which runs in localhost (127.0.0.1), I am trying to connect to the server by injecting SYN packets to the loopback interface, but the server doesn't answer them. These packets have the source IP of the Ethernet interface of my internet adapter (and not localhost IP).
I watch the SYN packet that goes to my loopback server in Wireshark, but the server does not answer it with a SYN/ACK. I think it is because the IP source is not 127.0.0.1, which for example is 192.168.1.24.
If I go to the browser and I connect to my localhost server it works fine, but the source IP that I am using is 127.0.0.1 and the destination IP is 127.0.0.1 too; the only difference between the packets is the source IP.
I want to establish a TCP connection with my loopback server (localhost) by using different IP source addresses than 127.0.0.1. Is that possible?
For example, a Loopback TCP SYN packet which comes from 192.168.1.24 to 127.0.0.1 should be answered by the loopbackserver?
Thanks and regards!
You can send packets to localhost via Npcap Loopback Adapter and get response from the counterpart (e.g. a process on the same machine). An example is Nmap, Nmap uses Npcap Loopback Adapter to scan the ports of localhost. The command is: nmap -v -A 127.0.0.1. Nmap is open-sourced here, so you can see its code about the implementation. If you think Nmap is too complicated, you can see the source code of Nping here, a ping tool shipped by Nmap. Nping also uses Npcap Loopback Adapter when pinging localhost, which works differently with the original ping shipped by Windows.
Using IP of one of local adapters or using 127.0.0.1 should be the same. You can run Nmap to test it. Whatever, using 127.0.0.1 is the best and recommended by Npcap when talking to localhost.
So I think the issue still relates to your own implementation.
Does the server bind() using INADDR_LOOPBACK? If so, you could try changing it to INADDR_ANY to see if that helps. See also man 7 ip.
(These links are obviously Linux-specific; if your platform is something else, then refer to the documentation applicable to your system. For example, if you're on Windows, then maybe refer to https://msdn.microsoft.com/en-us/library/windows/desktop/ms737550(v=vs.85).aspx.)
I solved the problem, thank you very much for your answers.
The problem was a bit stupid, I was trying to establish a TCP connection with the loopback server (localhost) with IP source addresses that were not in the range of the loopback, loopback gateway: 127.0.0.1, loopback netmask: 255.255.0.0; It cant accept packets from IP source addresses that are not in the range of 127.0.X.X ; if I do NAT and I translate the packet from for example 192.168.1.154 to 127.0.1.154 the packet is received by the server and I can establish the server connection, I do not know how I did not realize it before.
Thank you for the time, regards!.
I think too that maybe it is better to bind the server to other virtual network adapter and not to the loopback, I am studing this: https://github.com/Microsoft/Windows-driver-samples/tree/master/network/ndis/netvmini/6x
It would be fine to create a miniport driver and bind the server there, we would have the advantage of having our own gateway and netmask and the layer would be ethernet and not BSD loopback. Your opinions will be interesting for me.