Bug 72468
| Summary: | OS does not know how to handle broadcast... | ||
|---|---|---|---|
| Product: | Base System | Reporter: | Magnus L <knatte> |
| Component: | kern | Assignee: | Andre Oppermann <andre> |
| Status: | Closed FIXED | ||
| Severity: | Affects Only Me | ||
| Priority: | Normal | ||
| Version: | Unspecified | ||
| Hardware: | Any | ||
| OS: | Any | ||
|
Description
Magnus L
2004-10-09 23:00:45 UTC
Responsible Changed From-To: freebsd-i386->freebsd-bugs This does not sound i386-specific. On Sun, 24 Oct 2004, Mark Linimon wrote:
> Synopsis: OS does not know how to handle broadcast...
>
> Responsible-Changed-From-To: freebsd-i386->freebsd-bugs
> Responsible-Changed-By: linimon
> Responsible-Changed-When: Sun Oct 24 00:20:47 GMT 2004
> Responsible-Changed-Why:
> This does not sound i386-specific.
The submitter may be interested in the following socket option documented
in ip(4);
If the IP_ONESBCAST option is enabled on a SOCK_DGRAM or a SOCK_RAW
socket, the destination address of outgoing broadcast datagrams on that
socket will be forced to the undirected broadcast address,
INADDR_BROADCAST, before transmission. This is in contrast to the
default behavior of the system, which is to transmit undirected broad-
casts via the first network interface with the IFF_BROADCAST flag set.
Sample code is present in the ip(4) man page.
Robert N M Watson
You can replicate this easily with 'ping 255.255.255.255' and 'tcpdump -i fxp0 -n -e'. tcpdump shows packets being encapsulated to the default router's MAC address rather than ff:ff:ff:ff:ff:ff I see this with both fxp0 and vr0, so I don't think it's driver-specific. This appears to be a regression from FreeBSD 4.x. See also http://lists.freebsd.org/pipermail/freebsd-net/2005-October/008626.html Responsible Changed From-To: freebsd-bugs->andre Take over. On Tue, Oct 18, 2005 at 02:20:16PM +0000, Brian Candler wrote: B> You can replicate this easily with 'ping 255.255.255.255' and B> 'tcpdump -i fxp0 -n -e'. tcpdump shows packets being encapsulated to the B> default router's MAC address rather than ff:ff:ff:ff:ff:ff B> B> I see this with both fxp0 and vr0, so I don't think it's driver-specific. B> B> This appears to be a regression from FreeBSD 4.x. See also B> http://lists.freebsd.org/pipermail/freebsd-net/2005-October/008626.html I have just checked that FreeBSD 4.10 and 4.11 behave like 5.4. You speak about 4.9 in the above quoted URL. Looks like this narrows the search for regression. btw, this thing makes me really angry: ----- The following addresses had permanent fatal errors ----- <B.Candler@pobox.com> (reason: 554 <B.Candler@pobox.com>: Recipient address rejected: country/russia returned deny: client hostname cell.sick.ru matches TLD .ru (russia)) -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE Well, I have checked that 4.8-RELEASE doesn't send to ff:ff:ff:ff:ff:ff, too, when using ping 255.255.255.255. So it looks like the regression is not in the ping behavior, but in your application only. What is this application? May be it uses the IP_ONESBCAST option? -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE State Changed From-To: open->closed Sends to 255.255.255.255 have been resolved in 7.x and 6.x |
