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.
Related
Before I proceed, I'd like to mention that I did try to research this topic on the internet, but I still need clarification.
Let's say I have two Linux machines connected to a switch (and only to a switch). Machine A has an IP address of 10.0.0.1 and machine B -- 10.0.0.2. I used nmcli command to set the IP address and create an ethernet interface for each machine. Everything works as expected.
Now, the confusing part is how machine A can find machine B and vice versa? I'm using the following command to connect from machine A to machine B:
ssh userB#10.0.0.2
And it works, even if this is the very first data transmission. This surely means that machine A somehow already knew the machine's B MAC address; otherwise, the frame wouldn't find its way to machine B. But how? Since the IP address is meaningless to the switch (Level2), why when I do ping 10.0.0.2 or ssh 10.0.0.2, it still works?
Probably the ARP cache was already populated. Maybe there was a grations ARP broadcast:
Every time an IP interface or link goes up, the driver for that interface will typically send a gratuitous ARP to preload the ARP tables of all other local hosts.
If not, most likely an ARP request/reply was happening right before the first ping. Check the arp command or ip neigh.
In general I suggest you use Wireshark to explore what's going on, or something like tcpdump -n -i eth0 not ssh if your are working remotely (note the -n to prevent name resolution). You can also record traffic with tcpdump -s 9999 -w output.pcap and view it later in Wireshark.
If you sniff network traffic on a third PC, keep in mind that switches will not send traffic to all ports when they have learned where the destination is. Some switches allow you to configure a mirror port to observe all traffic to or from a certain port. Either way you should always be able to observe ARP requests as they are broadcast.
basically, when the first packet reach to the switch ( virtual or physical switch ), the switch will populate arp broadcast packet for the sake of getting all devices mac and ip addresses. so even though ip addresses seem meaningless to switches ( cause they're layer 3 concept but switch is for layer 2 ), switches still need those data to process the packets. because this is how we, as human beings, interact with computers for transmitting data by using ip addresses.
when you ping a device, like 10.0.0.2, the switch will search in it's arp table and find the corresponding mac address and also the interface for reaching to the destination.
the best way to comprehend the whole process is to capture the data using wireshark or even implementing a simple topology in softwares like cisco packet tracer.
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.
Summary:
I am guessing that the issue here is something to do with how Windows and Linux handle TCP connections, or sockets, but I have no idea what it is. I'm initiating a TCP connection to a piece of custom hardware that someone else has developed and I am trying to understand its behaviour. In doing so, I've created a .Net core 2.2 application; run on a Windows system, I can initiate the connection successfully, but on Linux (latest Raspbian), I cannot.
It appears that it may be because Linux systems do not try to retry/retransmit a SYN after a RST, whereas Windows ones do - and this behaviour seems key to how this peculiar piece of hardware works..
Background:
We have a black box piece of hardware that can be controlled and queried over a network, by using a manufacturer-supplied Windows application. Data is unencrypted and requires no authentication to connect to it and the application has some other issues. Ultimately, we want to be able to relay data from it to another system, so we decided to make our own application.
I've spent quite a long time trying to understand the packet format and have created a library, which targets .net core 2.2, that can be used to successfully communicate with this kit. In doing so, I discovered that the device seems to require a kind of "request to connect" command to be sent, via UDP. Straight afterwards, I am able to initiate a TCP connection on port 16000, although the first TCP attempt always results in a RST,ACK being returned - so a second attempt needs to be made.
What I've developed works absolutely fine on both Windows (x86) and Linux (Raspberry Pi/ARM) systems and I can send and receive data. However, when run on the Raspbian system, there seems to be problems when initiating the TCP connection. I could have sworn that we had it working absolutely fine on a previous build, but none of the previous commits seem to work - so it may well be a system/kernel update that has changed something.
The issue:
When initiating a TCP connection to this device, it will - straight away - reset the connection. It does this even with the manufacturer-supplied software, which itself then immediately re-attempts the connection again and it succeeds; so this kind of reset-once-then-it-works-the-second-time behaviour in itself isn't a "problem" that I have any control over.
What I am trying to understand is why a Windows system immediately re-attempts the connection through a retransmission...
..but the Linux system just gives up after one attempt (this is the end of the packet capture..)
To prove it is not an application-specific issue, I've tried using ncat/netcat on both the Windows system and the Raspbian system, as well as a Kali system on a separate laptop to prove it isn't an ARM/Raspberry issue. Since the UDP "request" hasn't been sent, the connection will never succeed anyway, but this simply demonstrates different behaviour between the OSes.
Linux versions look pretty much the same as above, whereby they send a single packet that gets reset - whereas the Windows attempt demonstrates the multiple retransmissions..
So, does anyone have any answer for this behaviour difference? I am guessing it isn't a .net core specific issue, but is there any way I can set socket options to attempt a retransmission? Or can it be set at the OS level with systemctl commands or something? I did try and see if there are any SocketOptionNames, in .net, that look like they'd control attempts/retries, as this answer had me wonder, but no luck so far.
If anyone has any suggestions as to how to better align this behaviour across platforms, or can explain the reason for this difference is at all, I would very much appreciate it!
Nice find! According to this, Windows´ TCP will retry a connection if it receives a RST/ACK from the remote host after sending a SYN:
... Upon receiving the ACK/RST client from the target host, the client determines that there is indeed no service listening there. In the Microsoft Winsock implementation of TCP, a pending connection will keep attempting to issue SYN packets until a maximum retry value is reached (set in the registry, this value defaults to 3 extra times)...
The value used to limit those retries is set in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\TcpMaxConnectRetransmissions according to the same article. At least in Win10 Pro it doesn´t seem to be present by default.
Although this is a conveniece for Windows machines, an application still should determine its own criteria for handling a failed connect attempt IMO (i. e number of attempts, timeouts etc).
Anyhow, as I said, surprising fact! Living and learning I guess ...
Cristian.
I want to monitor the HTTP traffic sent/received from my iPhone. The iphone is connected to the Internet via my wifi router.
I want to capture packets from my windows 7 station.
Thanks for your help.
You have a few options here:
If your wireless router has a port mirroring or port spanning feature, turn it on and point it at your workstation's IP. Use Wireshark on your workstation to look at the packets arriving on the interface assigned to that IP.
If your workstation has a wireless card, get Connectify for Windows 7 (turns wireless card into Wifi Hotspot). Connect iPhone through Windows 7 wireless, and workstation through ethernet to the internet. Your workstation will effectively act as a router for your iPhone and you will be able to record iPhone's packets passing through it.
Get an ethernet hub (make sure it is not a switch, you won't see all packets on every interface with a switch), and connect your workstation, wifi router and internet to it.
Get a switch with port mirroring feature, configure port mirroring to forward a copy of all packets to your workstation.
Another option that I wish someone would have mentioned to me is pfSense. This is an operating system based on BSD made to serve as a firewall. Top of the line routers have, say 400 Mhz of processing speed, and unimpressive amounts of ram. The lowest-end computer you'll find these days has better specs than that, and of course, it's upgradeable. You don't have to bother with those terrible Cisco licenses (no DHCP with no license, 20 DHCP users at one license level, 100 users at an higher lever? Ludicrous), etc. Best of all, you have "root' access to the system, so you can run whatever you want on it (including wireshark, say)!!
Make sure you have two sufficiently fast ethernet cards. You'll set your wireless router to not do NAT (because pfSense will be doing that), then you can get to work setting up your VPN server, etc. without thinking about cisco licensing, etc.
I have written a small client server socket application. It is a proof of concept for some socket programming that I want to apply to a much bigger project.
For the moment I want to user wireshark to analyse the traffic that goes between them. They are both running on my local machine.
I have installed a loopback interface, and have tried to use wireshark with it.
No joy. Any ideas?
I have successfully analysed traffic between my machine and other machines no problems.
I have had a look here,
http://wiki.wireshark.org/CaptureSetup/Loopback
And I am not using the address 127.0.0.1 which they mention saying you can't capture traffic on 127.0.0.1
Thanks.
You might try creating a virtual machine to run your application and using wireshark on it.
Save yourself some grief and download Microsoft Network Monitor.
As good as Wireshark is on Unixen, Windows is a "special" case :)