I am trying to programatically send out ICMPv6 echo requests (ping6) using WinSock2. The ICMPv6 checksum is calculated based on the whole IPv6 packet that will be sent out. For that reason - from what I understand - the OS (kernel?) is supposed to calculate it and write it into the ICMPv6 header when sending the packet.
This works very well on a SUSE Linux Enterprise Server 11, however, Windows XP does not seem to do this. It leaves the checksum to what I set it by default (zero, I analyzed this using Wireshark), thus the receiving end will discard it and not reply.
IPv6 is correctly set up on this WinXP machine. With the help of Wireshark I even found out that it responds correctly to ICMPv6 pings from the SUSE Linux server, sent using the very same code. So it cannot be that Windows XP doesn't support ICMPv6. However, I wonder whether WinSock2 under Windows XP does.
The WinSock2 API does provide the IPPROTO_ICMPV6 protocol which I create my raw socket for. Is there any special socket option I need to set for the ICMPv6 checksum to be calculated automatically, or are there any other tricks?
Most probable reason for the behavior you describe is checksum offloading. It means, checksum calculation might be delegated to networking hardware, so that sniffed packet doesn't contain the correct checksum value. Refer to http://www.wireshark.org/docs/wsug_html_chunked/ChAdvChecksums.html or to http://en.wikipedia.org/wiki/Transmission_Control_Protocol#Checksum_offload
Related
We have a sensor connected to Computer#1. The sensor is driven by Software XY. This software has a Data Server XY running in the background in Windows. I can see this server by executing "services" after pressing the windows key.
I want to be able to access this Data Server (first in Computer #1, and eventually send/access this information to/from Computer#2).
How can I know what type of server is this? (I need to know this to find out how to connect to it, right?) In the Services application I can only see:
Service name = XYDataServer
Display Name = XY Data Server
Description = Distributes XY data to listening clients
Path to executable = C:\Program Files\XY\DataServer\XYDataServer.exe
Additional information which does not say much really
Additional information: the seller of the sensor and software gave us a .NET Assembly (a .dll) and a word file with some information of the .dll (Namespace, Constructors, Methods, etc.) but no other instructions. I am at a loss on how to proceed. My rational was to first find out what kind of server this is (SQL, Windoes), and then decide how to approach it (pick programming language, download examples, etc.)
There some tips and technics for information gathering about your target server but they are not precise.
To identify which OS is running on the server you can find a clue by ping command. Firstly, you should find IP address of the target server(if you don't have it, you can sniff send/receive package with third party applications like Wireshark). Than ping your target server IP address. Finally, look for TTL in your ping result like this.
TTL=64 = *nix - the hop count so if your getting 61 then there are 3 hops and its a *nix device. Most likely Linux.
TTL=128 = Windows - again if the TTL is 127 then the hop is 1 and its a Windows box.
TTL=254 = Solaris/AIX - again if the TTL is 250 then the hop count is 4 and its a Solaris box.
For identifying which database is active on the server , you can scan open ports on the server. In example, SQL Server default port is 1433.
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 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'm working on a legacy VB6 app that uses sockets to communicate to various devices.
On a 2012 system, we are noticing the time between calling winSock.Connect() to the connection event being fired is holding at about 9 seconds, across multiple systems on different domains.
On a 2008 R2 or lower system, it's taking 1-3 milliseconds between the call and the event being fired.
Has anyone run into this before, or has any ideas on what could be causing this?
I've done some snooping with Wireshark, and found that the first few TCP transmissions are not connecting and being retransmitted, not sure if that will help.
I ended up finding the answer to this after some extensive digging.
Starting in Windows Server 2012, Microsoft has enabled an extension of TCP called Explicit Congestion Notification (ECN). This allows end-to-end notification of network congestion with the loss of packets. The way this is enabled on a TCP packet is via a flag, which is defined in the definition of ECN (RFC 3168(2001)).
What was happening for me was that the devices my application talks to are older, and don't support the ECN flag. When they received packets with that flag enabled, they wouldn't acknowledge the transmission, leading to a timeout from the server. After two failed transmissions, it looks like Windows shuts off the ECN flag, and the device acknowledged the packets.
I disabled ECN running the following command from an Administrator Command Prompt:
netsh interface tcp set global ecncapability=disabled
There is nothing particularly "special" about the Winsock control, which is just a thin wrapper on top of the API. The only thing of note really is that it is 32-bit and must run inside WOW64.
You're probably doing something funny or all 32-bit programs using the winsock API the same way should see the same issue.
Perhaps you have a name resolution issue on this server?
Setup:
I have client C connecting to server S
Both C and S are on the same machine
In C the server address is hardcoded to 127.0.0.1. Likewise, in S the client address is hardcoded to 127.0.0.1
Problem:
I want to be able to sniff the traffic between the client and the server.
Due to the configuration, I cannot move the client nor the server to different locations (the address are hardcoded)
Installing the loopback interface and using tools like Wireshark+WinPcap doesn't lead anywhere (was actually already known but was worth a try)
RawCap, suggested in another topic, doesn't work. IP 127.0.0.1 is listed, but does not record any traffic.
Using rinetd to route the traffic elsewhere, as suggested here doesn't work (cannot bind on 127.0.0.1)
Not interested in using a HTTP local proxy, such as Fiddler, because I'd like to capture also other protocols
Two commercial tools work, specifically CommView and Local Network Monitor, which means it must be possible to do that ;)
How can I do to capture the traffic?
Any pointer on functions I should use or documentation I should read?
Thanks!
Basically you need to write a TDI filter driver to achieve that... for some pointers see:
http://msdn.microsoft.com/en-us/library/windows/hardware/ff565685%28v=vs.85%29.aspx
http://msdn.microsoft.com/en-us/library/windows/hardware/ff563317%28v=VS.85%29.aspx
Another option is to write a WinSock LSP.
BEWARE
Since Windows 8 it is strongly encouraged to use WFP (Windows Filtering Platform) for this sort of thing...
Although it might be more cost-effective to just use/buy an existing solution - esp. if you are not a very experienced driver developer...
Use RawCap, which can solve your concerns, see this