Opened 14 months ago
Last modified 9 months ago
#18611 new bug
Unable to receive UDP broadcast packets
Reported by: | jeremy-list | Owned by: | axeld |
---|---|---|---|
Priority: | normal | Milestone: | Unscheduled |
Component: | Network & Internet/UDP | Version: | R1/beta4 |
Keywords: | Cc: | nephele | |
Blocked By: | Blocking: | ||
Platform: | All |
Description
Using the BDatagramSocket
helper class. After calling the SetBroadcast(true)
method it's possible to send UDP broadcast packets using SendTo
and they are received by another computer on the same network. However, RecvFrom
does not receive anything even though the other computer is also broadcasting.
Attachments (1)
Change History (8)
by , 14 months ago
Attachment: | broadcasttest.tar.bz2 added |
---|
comment:2 by , 13 months ago
I've upgraded my Haiku version a few times since I first noticed this but I'm currently on R1/Beta4 hrev56578+93 x86_64 and still seeing it.
comment:4 by , 13 months ago
I see the packets if I run tcpdump with -i /dev/net/atheroswifi/0
but not if I omit the interface argument or use -i local
comment:5 by , 9 months ago
DHCP which uses UDP broadcast , is working properly, which means the socket APIs are working fine . I suspect issue is with the BDataGramSocket class .
comment:6 by , 9 months ago
A part of this problem space is that on R1/beta4 a packet capture on the loopback interface never sees any packets. Switching to nightly builds would fix that. It would not fix the Haiku-specific bugs in libpcap 1.10.4, so, for example, if your diagnostics requires meaningful packet timestamps and packet counters, it would take to use the libpcap-1.10 branch or the master branch of libpcap, and to link tcpdump with it.
Then you would be able to reason more reliably where the UDP packets get lost: before they make it into the listening socket (e.g. the destination port number could be wrong) or after.
comment:7 by , 9 months ago
I was using hrev 57579, and I was able to see the udp packets exchanged for loopback interface in case of unicast . In case of broadcast , I could see the packets being sent by sender and captured by tcpdump but not received by the receiver .
A pair of test programs for confirming existence of this bug