'C#: Problem receiving UDP packet from device connected via mobile hotspot
I'm having a problem with simple UDP packet receive from a device connected remotely via Windows mobile hotspot.
The device (an esp32 wifi board) connects to the laptop via wifi, DHCP parameters are all received correctly. The device is correctly sending packets to the laptop, which I can see in wireshark. The packets show the ip of the device (192.168.137.xx sending to 192.168.137.1 port 4444). A testprogram "UDP Sender-Recevier" from Microsoft store is able to receive the packets when configured to listen on port 4444.
The problem now is that the program that is intended to receive the packets does not seem to see them. The listener thread basically looks like this:
public void serverThread()
{
UdpClient udpClient = new UdpClient(4444);
while (true)
{
IPEndPoint RemoteIpEndPoint = new IPEndPoint(IPAddress.Any, 0);
Byte[] receiveBytes = udpClient.Receive(ref RemoteIpEndPoint);
string returnData = Encoding.ASCII.GetString(receiveBytes);
// do something with received string
}
}
When running it starts the server, but receiveBytes
never gets the message the remote device is sending. Interestingly enough, using a testprogram called "PacketSender" to send something to port 4444 on the PC locally works, the message is received.
I suppose there is some issue with packages being received from the hotspot side of the network. Since UDP Sender-Receiver gets the message, I think it should be possible from within the C# application as well, but I can't figure it out.
Any help is greatly appreciated!
Reiner
Added information to original post: Here is some data collected by wireshark. These four packets are observed when the program starts: 1 is the initial message send by my program to the external device, 2 and 3 are ARP related, apparently the device requests and receives the MAC address of the PC interface, 4 is the answer coming back from the device to the local PC. This answer is never received by the udpClient listening on port 4444 (listening on 0.0.0.0:4444 according to netstat):
1 0.000000 192.168.137.1 192.168.137.255 UDP 43 60138 → 3333 Len=1
2 0.374833 Espressi_66:95:58 Broadcast ARP 42 Who has 192.168.137.1? Tell 192.168.137.251
3 0.374882 e6:a7:a0:8e:1e:bc Espressi_66:95:58 ARP 42 192.168.137.1 is at e6:a7:a0:8e:1e:bc
4 0.377677 192.168.137.251 192.168.137.1 UDP 48 3333 → 4444 Len=6
Following is the complete dump of packages 1 (from program to device) and 4 (from device to program):
Frame 1: 43 bytes on wire (344 bits), 43 bytes captured (344 bits) on interface \Device\NPF_{B71E40C1-C840-4749-B189-3646E2B2A741}, id 0
Ethernet II, Src: e6:a7:a0:8e:1e:bc (e6:a7:a0:8e:1e:bc), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
Internet Protocol Version 4, Src: 192.168.137.1, Dst: 192.168.137.255
User Datagram Protocol, Src Port: 60138, Dst Port: 3333
Data (1 byte)
Frame 4: 48 bytes on wire (384 bits), 48 bytes captured (384 bits) on interface \Device\NPF_{B71E40C1-C840-4749-B189-3646E2B2A741}, id 0
Ethernet II, Src: Espressi_66:95:58 (08:3a:f2:66:95:58), Dst: e6:a7:a0:8e:1e:bc (e6:a7:a0:8e:1e:bc)
Internet Protocol Version 4, Src: 192.168.137.251, Dst: 192.168.137.1
User Datagram Protocol, Src Port: 3333, Dst Port: 4444
Data (6 bytes)
Solution 1:[1]
Well, not an answer in the sense that I can explain what went wrong, but a workaround!
When I make the udpServer thread send to the remote device before starting the while loop, it suddenly receives the data. Apparently it needs to establish contact once from this thread before it can receive.
Strange thing, but works.
Code now looks like this:
public void serverThread()
{
UdpClient udpClient = new UdpClient(4444);
var address = IPAddress.Parse("192.168.137.255");
var ipEndPoint = new IPEndPoint(address, 3333);
byte[] bytes = Encoding.ASCII.GetBytes("testing");
udpClient.Send(bytes, 7, ipEndPoint);
while (true)
{
IPEndPoint RemoteIpEndPoint = new IPEndPoint(IPAddress.Any, 0);
Byte[] receiveBytes = udpClient.Receive(ref RemoteIpEndPoint);
string returnData = Encoding.ASCII.GetString(receiveBytes);
// do something with received data here ...
}
}
Thanks for your support!
Reiner
Solution 2:[2]
Check that the UDP packets sent have the source ip specified. Specifying it for me solved the problem.
Sources
This article follows the attribution requirements of Stack Overflow and is licensed under CC BY-SA 3.0.
Source: Stack Overflow
Solution | Source |
---|---|
Solution 1 | Pipeloops |
Solution 2 |