C#:从通过移动热点连接的设备接收 UDP 数据包时出现问题
我在从通过 Windows 移动热点远程连接的设备接收简单 UDP 数据包时遇到问题。
设备(esp32 wifi板)通过wifi连接到笔记本电脑,DHCP参数全部正确接收。该设备正在正确地将数据包发送到笔记本电脑,我可以在wireshark中看到这一点。数据包显示设备的 IP(192.168.137.xx 发送到 192.168.137.1 端口 4444)。来自 Microsoft 商店的测试程序“UDP Sender-Recevier”在配置为侦听端口 4444 时能够接收数据包。
现在的问题是,打算接收数据包的程序似乎看不到它们。侦听器线程基本上如下所示:
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
}
}
运行时它会启动服务器,但 receiveBytes 永远不会获取远程设备正在发送的消息。有趣的是,使用名为“PacketSender”的测试程序向本地 PC 上的端口 4444 发送一些内容,可以收到消息。
我认为从网络热点端接收的包存在一些问题。由于 UDP 发送方-接收方获取消息,我认为它也应该可以从 C# 应用程序内部实现,但我无法弄清楚。
非常感谢任何帮助!
Reiner
在原始帖子中添加了信息: 这是wireshark收集的一些数据。程序启动时观察到这四个数据包:1是我的程序发送到外部设备的初始消息,2和3与ARP相关,显然设备请求并接收PC接口的MAC地址,4是到来的答案从设备返回到本地PC。侦听端口 4444 的 udpClient 永远不会收到此答案(根据 netstat 侦听 0.0.0.0:4444):
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
以下是包 1(从程序到设备)和 4(从设备到程序)的完整转储:
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)
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)
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
好吧,这不是我可以解释出了什么问题的答案,而是一种解决方法!
当我在启动 while 循环之前让 udpServer 线程发送到远程设备时,它突然收到数据。显然它需要与该线程建立一次联系才能接收。
奇怪的事情,但是有效。
代码现在如下所示:
感谢您的支持!
赖纳
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:
Thanks for your support!
Reiner
检查发送的UDP数据包是否指定了源ip。
为我指定它解决了问题。
Check that the UDP packets sent have the source ip specified.
Specifying it for me solved the problem.