datagram socket (UDP) broadcasting in Linux
elch
i like to use the technic shown in:
contrib/hbmisc/udpds.prg ( work by Mindaugas Kavaliauskas )
to send a broadcast packet for discovering a network service.
That seem to work ok in Windows -- BUT not in LINUX !
Here no broadcast packet seem to be send ( packet sniffer Wireshark means that ;)
After longer research and try-outs:
it seem NOT allowed to broadcast to *ALL* local address using 255.255.255.255
Allowed by client seem to broadcast to a C-class subnet, e.g.: 192.168.1.xxx
Broadcast address would be for this example: 192.168.1.255
So the client side: hb_udpds_Find() is wrong -at least- for Linux.
---
my solution:
stumble through: hb_socketGetIFaces( HB_SOCKET_AF_INET, .T. )
excluding all ifaces with blank or empty MAC-address
[ e.g.: loopback -- but even a software bridge or WLAN should have a MAC ]
replace the last tuple of found IP address with 255 [ xxx.xxx.xxx.255 ]
then call with new third param: hb_udpds_Find( nPort, cName, cBroadcastIP )
[ made me also a C-version of that function ]
if then not got a hb_socketRecvFrom() answer [ == array with length 0 ]
try the next iface ...
---
above only a suggest ..., but seem now to work for me
best regards
Rolf
Francesco Perillo
--
You received this message because you are subscribed to the Google Groups "Harbour Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to harbour-deve...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
elch
Are you user root on linux ?
but not for some days :-)
and maybe even root wouldn't be allowed, not checked ...
regards
Rolf
Francesco Perillo
--
elch
out of curiosity, please check.
tryed it at 3 different Linux ( and one Windows ), confirmed none as root --
my hair have got 1 mm longer ;-)
Further that seem no option, a test something senseless, because:
a non-privileged user app should search a server service, instead that i hardcode the address in source.
I maybe post shortly working update for my recent network benchmark test -- seem now works fine ..
best regards
Rolf
Przemyslaw Czerpak
Use function below to send broadcast messages.
best regards,
Przemek
#include "hbsocket.ch"
FUNCTION SendBroadcastMessages( hSocket, nPort, cMessage )
LOCAL lResult := .F.
LOCAL aIFaces, aIF
IF Empty( aIFaces := hb_socketGetIFaces() )
aIFaces := { array( HB_SOCKET_IFINFO_LEN ) }
aIFaces[ 1, HB_SOCKET_IFINFO_BROADCAST ] := "255.255.255.255"
ENDIF
FOR EACH aIF IN aIFaces
IF ! Empty( aIF[ HB_SOCKET_IFINFO_BROADCAST ] ) .AND. ;
hb_socketSendTo( hSocket, cMessage, , , ;
{ HB_SOCKET_AF_INET, ;
aIF[ HB_SOCKET_IFINFO_BROADCAST ], ;
nPort } ) == hb_BLen( cMessage )
lResult := .t.
ENDIF
NEXT
RETURN lResult
elch
..
IF Empty( aIFaces := hb_socketGetIFaces() )
aIFaces := { array( HB_SOCKET_IFINFO_LEN ) }
aIFaces[ 1, HB_SOCKET_IFINFO_BROADCAST ] := "255.255.255.255"
ENDIF
exakt that broadcast address made me the big trouble in Linux.
Linux:
A station with only one physical interface reported for hb_socketSendTo() correct:
0 bytes send.
A station with 3 physical interfaces, and another station with 3 physical, 2
virtual from VM machine plus a software bridge ('bridge-utils') reported:
all bytes send --- but i'm unsure which detoure they took ;)
Result: never got any answer with hb_socketRecvFrom().
Second problem: these HB_SOCKET_IFINFO_BROADCAST entries in aIFaces array
seem correct in Linux --- but it seem *always* '255.255.255.255' for any iface,
even for the loopback, in tested Windows XP.
Using this 255.255.... broadcast IP in Windows seem only to broadcast the first
interface in list ( but VM uses two emulated e1000 'network bridges' )
The only reliable way to detect the loopback (or 'invalid' ) device(s) i found:
(HB_SOCKET_IFINFO_HWADDR), so MAC address was here at me:
NIL -or- empty ('00:00...') for Windows / Linux.
I enhanced my strategy to remember already broadcasted C-class network divisions
-- as especially my 'virtual' interfaces are in the same subnet as the physical ones.
---
My function: detectServer(),
is now used in the source for my benchmark in Harbour user group.
That works now in *any* situation for me -- maybe others with multiple interfaces,
complex network and different OS-versions like to countercheck:
just start and stop the benchmark server is enough for that test ...
https://groups.google.com/d/msg/harbour-users/neLoEoBLRnA/9hXJaO6dQmkJ
best regards
Rolf
Przemyslaw Czerpak
In MS-Windows you can use 255.255.255.255 as broadcast address
and message should be propagated to all interfaces.
The only bad side effect is that you send more then one BC message
but it's unimportant in most of cases and also in this one. Just
simply you have bigger chance that message is delivered (remember
that it's UDP) and you only have to eliminate repeated answers.
In all cases HB_SOCKET_IFINFO_BROADCAST should be preferred.
Generating broadcast address without knowing network mask is
impossible. The trick you are using with setting 255 does not
work at all for small subnets with less then 255 addresses
(i.e. for netmask 255.255.255.240 (28) to create broadcast
message you should set only last four bits in address) and
for bigger subnets more then 255 addresses you do not generate
proper broadcast address but only address of one possible
device in this network so only this device can answer.
If you want to create broadcast yourself then you have to
use HB_SOCKET_IFINFO_NETMASK and set only this bit in
HB_SOCKET_IFINFO_ADDR which are 0 in netmask.
I do not see any reason to eliminate lo interface. The service can
be located on the same computer I execute my program so it should
also be scanned and in such case lo should be faster then real
network interfaces from which I'll receive the same server answer
so it should be preferred.
Also any other virtual interfaces should be accessed. There are
many interesting pseudo devices which may not have any hardware
address but be fully functional and give access to some virtual
networks.
best regards,
Przemek
On Mon, 19 May 2014, elch wrote: