I have a problem with UDP messages under Python3 on Windows10.
The UDP messages are a command/response scheme.
Example: CMD_TURN_ON_LIGHT_BULB, Bulb #4
Response: RSP_TURN_ON_LIGHT_BULB, Bulb #4 - OK.
My local Windows PC address is: 10.1.1.10
In all cases, the netmask here is 255.255.255.0
The remote device has 2 network addresses.
There are various routers between the PC and the remote device.
Device Address (A) is 10.2.2.10 (and is the "default route").
Device Address (B) is 10.3.3.10 (it is a backup interface)
Case 1: This works.
PC sends UDP to 10.2.2.10 (it uses "sendto()")
The remote device responds to the source address using sendto()
The PC receives the response, and the application receives the response.
The PC has a pending/waiting "recvfrom()"
Case 2: This does not work.
PC Sends UDP to 10.3.3.10 (the backup interface)
The remote device replies -
However - due to default route rules, the device replies from 10.2.2.10
The PC receives the reply (I see the reply/response in Wireshark)
The PC has the firewall 100% disabled
But - The application does not receive the UDP message from the remote device.
Any suggestions?
Stated differently:
This works: Transmit to UPD address (A), Port X - reply from: A, port Y
This fails: Transmit to UDP address (B), port X - reply from: A, port Y
The second case, the packet seems to be lost inside the bowels of Windows...
Related
My ubuntu machine's wireless interface is connecting to the wireless router. I wrote a simple web server listening on port 8888. I would like to understand how the packets are sent and receive using localhost. So I did the following experiment:
I started wireshark on the same machine listening wlan0 and on the terminal I type:
$telnet localhost 8888
Then I observe TCP SYN, SYN/ACK, ACK. In these messages, the MAC src and dest addresses are all 00:00:00:00:00:00. The src and dst IP addresses are all 127.0.0.1.
Does this mean these packet never go out from my wlan0 interface to the wireless router and directly loop back within my machine? Does it even reach my wireless card or just looping back within the ubuntu linux OS?
The packets to localhost do NOT 'go out on wire'; i.e. the packets are send to receive buffers locally by the network driver.
IF you telnet to local server IP, then the packets do go out on wire. e.g. telnet 192.168.100.1 would make packets go out on wire.
I am trying to learn something about sockets in Linux. I have small development board something like raspberry Pi with Linux running inside. Unfortunatly it doesn't have ethernet or usb port.
I have created a dummy network interface and used it like default gateway. I have written a small program using raw sockets listening on dummy interface (then sends all packets over serial line to computer where is program which send this packets to the internet and recieves answers a sends them back).
My problem is when i am trying to ping some public IP address i can see in tcpdump the ICMP requests and responses in both computer and development board. But the ping looks like it does recieve nothing.
I have tryed to use loopback interface instead of dummy interface, but in this case the pings gets looped and the device becomes unresponsible in a while :). But the ping did recieve ICMP response, and TCP connection didn't work.
I also have tryed to use 2 dummy interfaces and create bridge.
I would be very grateful for any advices.
My Linux (Debian) server has eth0 and eth1, and both are on the same subnet.
It receives packets from both interfaces, but it only replies from eth0.
Packets that are sent to eth1 are replied from eth0, and the reply has eth0's src mac and eth1's src IP.
I verified this by sending a ping to eth1 while running tcpdump on the Linux server.
This is a problem because:
Since no packets are sent with a source mac of eth1 (with the exception of the initial arp), the switch forgets the eth1 mac. Then, every packet with the destination mac of eth1 that is received by the switch is broadcasted across the network, flooding it which makes us sad.
I want:
My Linux server to send packets out from both eth0 and eth1. I think the nicest solution is that for each packet we get, we reply from the same interface. Another way to put it is that I want to bind each interface to its IP and MAC - so that it will only send packets from these addresses.
More details:
My Linux server is an ISCSI Target communicating with an ESX which is an ISCSI Initiator - though a Cisco switch. The switch forgets MACs after 5 minutes, and the ESX probably remembers them for 20 minutes (as discussed here and here). So while the ESX remembers the mac of the Linux, the ESX keeps sending ISCSI requests which flood the network, while my server sends ISCSI replies through only one of the interfaces.
This isn't what you asked for, but if you just set up a cron job on the box that did
ping -c 1 -I eth1 <address of eth1's default gateway>
every minute, then you would have at least one packet per minute leaving eth1 with eth1's MAC address on it. -I tells ping to bind to a specific interface, so it won't use eth0 even if that's the preferred route.
For the sake of simplicity, I will refer you to http://en.wikipedia.org/wiki/Berkeley_sockets and the UDP server and client source code there.
I am trying to send a packet using UDP protocol to a linux VirtualMachine server program. Both my host and VM ping well; all packets sent are received in both directions. However my server program is either not receiving any packets, or it is simply not printing. Either way, it isn't printing the confirmation or contents of any packets I send to it from the host.
I do not have another PC handy, but both programs communicate well enough if I stage them on the same computer and Wireshark reports that the packets are being sent.
Mine is a three part question: first, how can I fix this. Second, why would the host and VM receive each others ping messages, but not pass these on to the open sockets of both ends of my UDP system? Finally, do you have any suggestions about the form or intent of this question?
EDIT: I've tried running my VM with the NAT and bridged adapter network setups. However, I can't conceptualize the relationship between those setups and my problems right now.
With NAT networking, the VM gets a private IP address (usually 192.168.x.y) and the host does NAT translation of outgoing packets, and translates reply packets back to the VM. In this mode, all communication must be initiated by the VM -- outside machines can only send packets to the VM in reply to packets the VM sent to them. On the network, the packets will look like they're coming from/going to the host on some unrelated port.
With bridged networking, the VM gets a device that connects directly to the host's network device. In this mode, the VM appears as a separate machine on the same network LAN as the host, with its own IP address. You need to allocate an IP address for it, the same as the host get allocated an IP address (usually via DHCP).
In either case, to debug what is going on, use tcpdump/wireshark on the host to monitor the host's network device. Send packets from the VM, and you should see them in the trace -- they'll appear to come from the host and a different port in the NAT case, and will appear to come from the VM's IP address (and unchanged ports) in the bridged case.
Once you see that, you should be able to send packets back to the VM, though in the NAT case, they must come FROM the address/port the original packet(s) were sent to.
There are known issues with VirtualBox bridged networking not working properly on wifi devices; in general you can only use bridged networking with wired networks.
Oracles VB manual page clear all the terminology used in settings.
I've had similar problem, where my VB program didn't receive any packets, which I solved by setting "Bridged Networking" and setting up proper source/destination IP address in my program by analyzing WLAN interface with wireshark and using ifconfig (or ipconfig) in terminal.
(edit: solved -- see below)
This is my situation:
TL-MR3020 -----ethernet----- mbed
OpenWRT C/C++ custom networking stack
192.168.2.1 192.168.2.16
TL-MR3020 is a Linux embedded router
mbed is an ARM microcontroller.
On the network I just want them to exchange messages using UDP packets on port 2225. In particular, TL-MR3020 has to periodically send packets every second to 192.168.2.16:2225, while mbed has to periodically send packets every 50ms to 192.168.2.1:2225.
Everything was good untill I removed the network stack library from mbed (lwIP, not so lightweight for me) and written a new minimal stack.
My new stacks sends 5 gratuitous ARP reply just after the ethernet link gets up, then starts sending and receiving udp packets.
Now TL-MR3020 doesn't receive any UDP packet. In particular, with ifconfig I can see packets coming, but my application can't get them.
Also, if I connect my laptop instead of the TL-MR3020, I can see the UDP packets coming, using Wireshark. There's nothing wrong, except done for my application.
I have a node.js script that has to receive the packets, but it doesn't receive nothing, but if I send UDP packets from local to local, the script receives them.
I think that my application is OK also because neither SOCAT can receive the UDP packets using socat - UDP-LISTEN:2225.
I've already checked on TL-MR3020:
arp table has the correct ip-mac assiciation
destination MAC address matches the incoming interface
destination IP address matches the incoming interface
IP checksum: wireshark says good=false, bad=false
UDP checksum: wireshark says good=false, bad=false
So, I'm asking... what are the minimum requirements for a custom networking stack to send UDP packets?
SOLVED:
You need a good checksum in the IP header.
UDP checksum, my case, can be set to zero.
tcpdump is very helpful (thanks to AndrewMcDonnell)