TcpDrv not reading from buffer (recvBuffer function hanging)

[emaddocks]

Hi,

We have used the sample TcpDrv driver to develop a custom driver for sending and receiving UDP packets in WinCC OA.

We've been able to compile our custom driver, run it as a manager in the projects console and verify its operation using a Packet Sender application. By this I mean we can send out a UDP packet from WinCC OA and the Packet Sender software receives it. We can then send a UDP packet back from the Packet Sender software and WinCC OA receives it. All good! However...

When we take the computer off our office network and connect it to an isolated test network the packets being received by the Linux OS get stuck in the ports udp6 buffer and don't process (we have been able to see this by watching /proc/net/udp6) . When diagnosing the issue further we have found that the UdpSocket:RecvBuffer function hangs while trying to read the udp6 buffer. However this hanging does not occur when the computer is connected to the office network. When on our office network the buffer gets immediately processed.

As we only have the header files for the include projects (namely UdpSocket.hxx) we can't diagnose the issue any further.

Does anyone have an insight into what possible differences between networks could cause the RecvBuffer function to behave differently?


Regards
Eric

[kilianvp]

maybe a firwall issue?

[emaddocks]

We thought that aswell so disabled all firewalls on Linux (in a VM) and Windows (on the host) but the problem still occurs.

If a firewall was blocking the packets/port then would the packets still be seen filling up the buffer?

[emaddocks]

Hi All,

We found a resolution to this issue but still not sure on why the issue was occuring.

To resolve the issue we had to put the hostname and IP address into the etc/hosts file. Without this it seems the udp packets don't actually make it through to the buffer for processing by the driver. When the computer is connected to our office network we assume that the DNS server must be modifying the packets to include some sort of name resolution that allows it to get through to the buffer and processed by the driver.

Cheers
Eric

[gschijndel]

In 2015 I came across the same issue. The 'programmer friendly' version of 'Socket::recvfrom' (with CharString) tries to resolve the address into a name, which is slow without a DNS server.
So I went up using the 'programmer unfriendly' version to prevent the name resolving.