UDP Broadcast: WSA Error Not Available
person
I'm trying to port a simple program from Linux to Windows. The code
works great on Linux but won't work on Windows. I'm writing this from
memory so please excuse blatant errors, the code compiles and links,
just doesn't run.
WSAStartup ();
sock_addr_in internet_socket;
internet_socket.s_addr.sin_addr = inet_addr("X.Y.Z.255");
internet_socket.s_port = htons(3000);
SOCKET s1 = socket (...);
setsockopt (..., SO_REUSEADDR,...);
setsockopt (...,SO_BROADCAST,...);
bind(...);// the bind fails with the unavailable issue
WSACleanup ();
Is this a machine configuration issue? The code compiles, links, and
binds if INADDR_ANY is used instead of the broadcast address for the
subnet. The people I'm porting it for are superstitious about the
address and insist it be X.Y.Z.255.
Any help here will be greatly appreciated,
Frank
Rick Jones
> WSAStartup ();
> WSACleanup ();
Using a broadcast IP as a source IP is a no-no. Bind()ing a socket
sets the source IP to be used when communicating via that socket. My
understanding is that setting SO_BROADCAST is only to allow _sending_
to a broadcast IP address and says nothing about receiving broadcasts.
Perhaps therein lies the problem?
Is it known with certainty that the bind() to a broadcast address is
succeding under Linux? Any background on why the people for whom you
are porting insist on only receiving datagrams sent to the broadcast
address rather than the broadcast+localunicast addresses?
rick jones
--
denial, anger, bargaining, depression, acceptance, rebirth...
where do you want to be today?
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...
person
Thanks for the response!:-)
Unfortunately the bind under Linux succeeds and the socket
sends/receives data.
I'm still green at using UDP/Broadcasting so I'm not sure I understand
what you mean by broadcast + localunicast address. Would you be so
kind as to provide an illustrative example?
Is broadcast the infamous 255.255.255.255? And then somehow you mask
(via AND) in the local machine address as localunicast address?
Thanks again,
Frank
Rick Jones
> Unfortunately the bind under Linux succeeds and the socket
> sends/receives data.
Figures. The only OS that likes to be different as much as Windows is
Linux :) Still, that it works under OS Fu does not a priori imply it
should work under OS Bar.
What was the specific IP address and subnetmask on the Linux system?
What happens if you happen to try to send a datagram out that socket?
> I'm still green at using UDP/Broadcasting so I'm not sure I understand
> what you mean by broadcast + localunicast address. Would you be so
> kind as to provide an illustrative example?
> Is broadcast the infamous 255.255.255.255? And then somehow you mask
> (via AND) in the local machine address as localunicast address?
255.255.255.255 is _one_ broadcast address. IIRC that is called the
"all nets, all subnets" broadcast. There is also the subnet-local
broadcast address. IIRC you arrive at that by doing:
localip | ~subnetmask
Which is shorthand for the bitwise OR of the local IP with the
complement of the subnetmask. So, with a classic "Class-C" example
just to make the math simple:
IP 192.168.1.123
Netmask 255.255.255.0
~Netmask 0.0.0.255
The subnet broadcast address would be:
192.168.1.255
Now, I cannot recall all the matching rules, but if the application
binds to INADDR_ANY and a port, it will receive all traffic received
and accepted for local delivery by that host - that will be:
1) All the local IP's
2) All the local subnet broadcasts
3) The "all nets, all subnets" broadcast
(destined for the application's bound port number of course :)
What I cannot recall, but presently ass-u-me :) that if it bound to
one of the local IP's it might still receive datagrams for the
broadcast IP's and that local IP.
I'm still curious to know more about their paranoia.
I'm not sure if there is a (portable) way to say "I just want to
receive broadcasts and no unicasts"
rick jones
--
firebug n, the idiot who tosses a lit cigarette out his car window
Albert Manfredi
> I'm still green at using UDP/Broadcasting so I'm not sure I understand
> what you mean by broadcast + localunicast address. Would you be so
> kind as to provide an illustrative example?
>
> Is broadcast the infamous 255.255.255.255? And then somehow you mask
> (via AND) in the local machine address as localunicast address?
The "all 1s" broadcast address is called the "limited broadcast"
address. Limited in the sense that packets with all 1s IP destination
address do not go across routers to other IP subnets. They visit all
hosts in the same subnet as the source host. (RFC 1122, section
3.2.1.3(c)).
If you want to direct a broadcast from one IP subnet to another IP
subnet, you need to use something called a "directed broadcast" (same
RFC, subparagraph (d)). That consists of the address of the destination
subnet prefix followed by all 1s. These packets are routed from the
source subnet to the destination subnet, then they are broadcast locally
at that destination subnet.
Bert
Vernon Schryver
Albert Manfredi <albert.e...@nospam.com> wrote:
>RFC, subparagraph (d)). That consists of the address of the destination
>subnet prefix followed by all 1s. These packets are routed from the
>source subnet to the destination subnet, then they are broadcast locally
>at that destination subnet.
They are broadcast locally only by very old routers that in my view
were always broken or by less ancient routers whose BCP 34/RFC 2644
default has been unwisely changed. Note that RFC 2644 had a date of
August 1999.
Directed broadcasting was never universally supported and was always
at least dangerous, even if you don't agree with me that it was always
a clearly bad idea.
Vernon Schryver v...@rhyolite.com
Albert Manfredi
> IP 192.168.1.123
> Netmask 255.255.255.0
> ~Netmask 0.0.0.255
>
> The subnet broadcast address would be:
> 192.168.1.255
Agreed, except that's the "directed broadcast" address. It works fine if
it's sourced locally, exactly the same as an all 1s broadcast address.
But this directed broadcast also works if it was sourced from some other
IP subnet. Whereas the all 1s broiadcast is blocked at any router it
encounters (with some notable exceptions, like DHCP to a server outside
own subnet -- a special case the router needs to accommodate
explicitly).
> Now, I cannot recall all the matching rules, but if the application
> binds to INADDR_ANY and a port, it will receive all traffic received
> and accepted for local delivery by that host - that will be:
>
> 1) All the local IP's
> 2) All the local subnet broadcasts
> 3) The "all nets, all subnets" broadcast
Agree on 1 and 2, but I'm not sure what 3 is. I don't think any such
broadcast address exists. And lucky thing that is.
> What I cannot recall, but presently ass-u-me :) that if it bound to
> one of the local IP's it might still receive datagrams for the
> broadcast IP's and that local IP.
That should be the case, agreed.
Bert
Albert Manfredi
> Directed broadcasting was never universally supported and was always
> at least dangerous, even if you don't agree with me that it was always
> a clearly bad idea.
I won't dispute that point. I knew directed broadcast was not popular,
but I didn't know that routers had essentially stopped implementing it
altogether.
Thanks for the info.
Bert
Rick Jones
> "Rick Jones" <rick....@hp.com> wrote:
>> 1) All the local IP's
>> 2) All the local subnet broadcasts
>> 3) The "all nets, all subnets" broadcast
> Agree on 1 and 2, but I'm not sure what 3 is. I don't think any such
> broadcast address exists. And lucky thing that is.
I meant the 255.255.255.255 broadcast address for #3. I guess just
calling it "all nets" would suffice.
rick jones
--
No need to believe in either side, or any side. There is no cause.
There's only yourself. The belief is in your own precision. - Jobert
person
Thanks for the help! The directed broadcast is what I think is being
attempted.
The actual numbers are:
localip: 130.122.43.155
subnetmask: 255.255.254.0
It's desired for the data to be broadcast out of the subnet to another
subnet. I'm on a different system from the actual deployment target so
all my addresses are of the 130.122.43.zzz flavor. When I use
130.122.43.255 as my directed broadcast address it doesn't bind. If I
understand what Rick is saying about deriving an address using the
inverse of the subnet mask the address of 130.122.43.255 is correct?
Also, am I reading Vernon correctly in concluding from his post that
this might never work because Windows doesn't have to support directed
broadcast?
I think the paranoia is a side effect of having something that works
and the deadline is coming at us like a freight train.
On the Linux box when a packet is sendto that address it jumps across
the networks as it was anticipated it would work on the Windows box.
I didn't think to say what is being done. We read in broadcast packets
from one port, modify the packet slightly, then rebroadcast out on a
different port.
Please excuse my addressing issues from several posts in this one,
Frank
Albert Manfredi
> The actual numbers are:
> localip: 130.122.43.155
> subnetmask: 255.255.254.0
>
> It's desired for the data to be broadcast out of the subnet to another
> subnet. I'm on a different system from the actual deployment target
> so
> all my addresses are of the 130.122.43.zzz flavor. When I use
> 130.122.43.255 as my directed broadcast address it doesn't bind. If I
> understand what Rick is saying about deriving an address using the
> inverse of the subnet mask the address of 130.122.43.255 is correct?
Yes, that's correct. The lower 9 bits of the address must be set to 1,
and they are. The upper 23 bits must be the subnet ID, unchanged from
what you'd use in unicast.
But in a directed broadcast, you would expect the upper 23 bits to be
different from your own subnet ID. That's why it's called "directed." I
wonder if the Windows box is getting confused by your attempt to create
a directed broadcast with the same subnet ID as its own. Just a wild
guess. I would not really expect that confusion, assuming directed
broadcasts are allowed at all.
> Also, am I reading Vernon correctly in concluding from his post that
> this might never work because Windows doesn't have to support directed
> broadcast?
Certainly routers might not support diretced broadcasts any longer.
Whether Windows does or not I don't know. Did you search the Microsoft
knowledge base? For example:
http://www.microsoft.com/technet/archive/security/prodtech/network/secdeny.mspx?mfr=true
says among other things:
"Ensure that routers are not converting layer 3 broadcasts into layer 2
broadcasts. The Cisco command to disable this is: no ip
directed-broadcast. This is the default setting for routers that use IOS
version 12.0 or greater"
That doesn't say "Windows," but since this is a security fix, it could
well include Windows. I didn't search long enough, but my bet is that
one of the Windows security updates disabled directed broadcasts, and
that you'd have to go and change a registry setting to re-enable them.
Check out that link and see, because it discusses a lot of fixes.
> I think the paranoia is a side effect of having something that works
> and the deadline is coming at us like a freight train.
>
> On the Linux box when a packet is sendto that address it jumps across
> the networks as it was anticipated it would work on the Windows box.
Can you send the packet unicast to host on the other subnet, and have
that host broadcast locally? That would be a more fool-proof way of
doing this.
Bert
Rick Jones
> It's desired for the data to be broadcast out of the subnet to another
> subnet. I'm on a different system from the actual deployment target so
> all my addresses are of the 130.122.43.zzz flavor. When I use
> 130.122.43.255 as my directed broadcast address it doesn't bind.
One doesn't bind the address to which one wants to send. One binds to
the address on which on wants to recieve, and I'm not sure it is
strictly kosher to try to bind to a broadcast address.
> On the Linux box when a packet is sendto that address it jumps across
> the networks as it was anticipated it would work on the Windows box.
But what is the _source_ IP address of that datagram? You were saying
that the bind() to the broadcast address "worked" under Linux, which
presumably would be setting the source IP address, and using a
broadcast address as a source IP address is _definitely_ verbotten.
rick jones
--
Process shall set you free from the need for rational thought.
Barry Margolin
"Albert Manfredi" <albert.e...@nospam.com> wrote:
I don't think that routers have actually stopped implementing it, they
just usually have options to block it. And network administrators are
strongly encouraged to enable the option if it's not the default,
because there are many more bad uses than good ones.
--
Barry Margolin, bar...@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***
person
I fell off the face of the earth for a couple of days. Please forgive.
The _source_IP address of the datagram is another box on the same
subnet. This seems strange to write and to read but we have a subnet
that covers a great deal of geographic area.
I'm struggling here, wouldn't we have to use a broadcast address as a
source IP? If not what should we be doing?
Thanks,
Frank
Albert Manfredi
>
> The _source_IP address of the datagram is another box on the same
> subnet. This seems strange to write and to read but we have a subnet
> that covers a great deal of geographic area.
>
> I'm struggling here, wouldn't we have to use a broadcast address as a
> source IP? If not what should we be doing?
Must not use a broadcast address as source address. The source IP
address has to be the unique IP address of the source host interface.
Bert