Hi, 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.
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.
person <frank.l.l...@boeing.com> wrote: > 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.
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...
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?
Rick Jones wrote: > person <frank.l.l...@boeing.com> wrote: > > 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.
> > 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.
> 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 <frank.l.l...@boeing.com> wrote: > 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 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" <frank.l.l...@boeing.com> wrote: > 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.
Albert Manfredi <albert.e.manfr...@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.
> 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.
"Vernon Schryver" <v...@calcite.rhyolite.com> wrote: > 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.
Albert Manfredi <albert.e.manfr...@nospam.com> wrote: > "Rick Jones" <rick.jon...@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 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...
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
"person" <frank.l.l...@boeing.com> wrote: > 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:
"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.
person <frank.l.l...@boeing.com> wrote: > 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. 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...
> > 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.
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 ***
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?
> 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.
