Thank you for the reply Dan!
I am aware of the issues with broadcast, and I strongly urge people to use multicast instead of broadcast for a variety of reasons. All the same, I've been asked to address this issue and I wanted to understand why FreeBSD doesn't allow broadcast on the loopback interface. Conceptually, it sort of makes sense to allow it. Using a broadcast should result in everyone on some link receiving your packet. If loopback is your only interface that's up, then why not use that? In the case of loopback, you are the only one on your link, so you should still receive your broadcast.
Is there a technical reason this was done (i.e. if I set the broadcast flag on loopback I'll be chasing down other bugs until my hair turns grey or falls out) or is it a conceptual reason (i.e. broadcast, on loopback, are you out of your mind?).
Other platforms out there will handle broadcast on the loopback interface. Is it desirable to make changes to the FreeBSD stack to get this behavior?
Thanks,
-josh
On Thursday, December 5, 2002, at 04:50 PM, Dan Lukes wrote:
[EMAIL PROTECTED] wrote, On 12/05/02 20:41:Your application shouldn't use broadcast unless it knows it run in broadcast capable environment or it shouldn't refuse to run when it cannot send a packet - as it doesn't care where it's packets are sent to.Is there a reason that the broadcast flag is not set on the loopback interface? It seems like it might be useful to allow applications that use broadcast to continue to work even when loopback is the only interface.
BTW, the broadcast are handled in mad way in TCP/IP stack already - the destination of 255.255.255.255 is silently rewritten to network broadcast and sent over first interface (if it is broadcast capable) or it is routed (often to default route). You can't send the non-network broadcast to interface of your choice (unless you use > bpf).
To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
