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)

broadcasttest.tar.bz2 (1.3 KB ) - added by jeremy-list 14 months ago.
A pair of test programs for confirming existence of this bug

Download all attachments as: .zip

Change History (8)

by jeremy-list, 14 months ago

Attachment: broadcasttest.tar.bz2 added

A pair of test programs for confirming existence of this bug

comment:1 by nephele, 13 months ago

Cc: nephele added

What haiku revision did you see this on?

comment:2 by jeremy-list, 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:3 by korli, 13 months ago

Please check the packets are coming with tcpdump.

comment:4 by jeremy-list, 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 sayanc, 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 dovsienko, 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 sayanc, 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 .

Note: See TracTickets for help on using tickets.