Re: broadcast over loopback
Joshua Graessley wrote:
[ ... ]
If someone is using broadcast for a service discovery protocol instead
of multicast, they would want services, whether running locally or
remotely, to receive that broadcast.
Sure, since the thing doing service discovery may not be the same as
the thing (or things) advertising services.
If loopback is the only interface, it might still be desirable to find
services running on the local machine.
Besides, giving the loopback special case behavior when it's not needed doesn't
strike me as a good idea. Presumably one would want to remove the second test:
/*
* Multicasts with a time-to-live of zero may be looped-
* back, above, but must not be transmitted on a network.
* Also, multicasts addressed to the loopback interface
* are not sent -- the above call to ip_mloopback() will
* loop back a copy if this host actually belongs to the
* destination group on the loopback interface.
*/
if (ip-ip_ttl == 0 || ifp-if_flags IFF_LOOPBACK) {
m_freem(m);
goto done;
}
...around line 380 of /usr/src/sys/netinet/ip_output.c, and rebuild the kernel
to test your suggested change out.
-Chuck
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-net in the body of the message
Re: broadcast over loopback
On Friday, December 6, 2002, at 04:15 PM, Jason Hunt wrote: 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? Any examples? I cannot think of a practical case where this would be required. I would think that an application will know if it sent a broadcast or not, so it shouldn't have to receive that broadcast itself. Anyone disagree? If someone is using broadcast for a service discovery protocol instead of multicast, they would want services, whether running locally or remotely, to receive that broadcast. If loopback is the only interface, it might still be desirable to find services running on the local machine. -josh To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message
Re: broadcast over loopback
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: 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. 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. 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
Re: broadcast over loopback
On Fri, 6 Dec 2002, Joshua Graessley wrote: 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?). With any kind of broadcast media, unless this is specific to Ethernet, or there are some exceptions, a broadcast packet sent by a station is received on every port other than the port that the packet came from. As far as I know, a station should never receive it's own broadcast packets unless you have a loop somewhere in your Layer 2 infrastructure. I believe that the above applies to IP broadcasts (or any other Layer 3 protocols) as well. 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? Any examples? I cannot think of a practical case where this would be required. I would think that an application will know if it sent a broadcast or not, so it shouldn't have to receive that broadcast itself. Anyone disagree? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message
Re: broadcast over loopback
[EMAIL PROTECTED] wrote, On 12/05/02 20:41: 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. 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. 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). Dan -- Dan Lukes tel: +420 2 21914205, fax: +420 2 21914206 root of FIONet, KolejNET, webmaster of www.freebsd.cz AKA: [EMAIL PROTECTED], [EMAIL PROTECTED],[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message
