Receiving INADDR_BROADCAST packets

Bruce M Simpson bms at spc.org
Fri Aug 22 04:19:39 PDT 2003


Hi all,

Ok, the broadcast sending problem is solved, as far as I'm concerned.

However, the reception problem isn't:
   14766 broadcast/multicast datagrams dropped due to no socket

This despite:
wi0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        inet 1.234.56.78 netmask 0xff000000 broadcast 1.255.255.255
udp4       0      0  1.234.56.78.654        *.*                    

I can:
a) patch udp_input() to pass INADDR_BROADCAST traffic to all sockets bound
   to the port and on the interface where the traffic was received.
   Possibly conditionalise this interface based on a socket-level option.
   e.g. 'Yes, I'm an interface-bound socket and I'd like undirected
   broadcasts on my interface thankyou very much'. This would be done in
   such a way which was 'opt-in' and didn't impact existing applications.
b) preserve the existing 4.2BSD kludge of binding to INADDR_ANY and not
   knowing what interface an undirected broadcast came in on.
c) same as b) but use IP_RECVIF to determine which interface the broadcast
   came in on, and change my network event dispatch code accordingly.
d) use a SOCK_RAW socket.
e) use BPF.

b), d), e) are not solutions. They are cop-outs.
Please don't suggest them.  Really.

I note that Apple are using IP_RECVIF in their mDNS code. The problem
there is not the same (they're dealing with multicasts), but similar.

I already cache the interface index in my internal RIB and track RTM_IFINFO,
RTM_IFANNOUNCE events, so this isn't too big a hit (the fact that this
ioctl provides an index, not a name).

I'm going to go with solution c) for now, but has anyone considered a)?
(Little choice really, we have a code freeze coming up, and I'd like my
code to run unchanged on 4.9-RELEASE).

BMS


More information about the freebsd-net mailing list