The patch actually fixes the test that was broadcasting to the loopback interface :)
Cheers, Philipp On 15/01/16 09:30, "[email protected] on behalf of Ian Boston" <[email protected] on behalf of [email protected]> wrote: >Hi, >Sorry. I misunderstood your question. >The Serverfault question referenced in the Oak issue was about broadcasting >to the loopback address, which can't be done. >The patch looked like it was attempting to do that. > >Best Regards >Ian > > >On 14 January 2016 at 20:48, Philipp Suter <[email protected]> wrote: > >> The patch is for unit tests “only”. It executes the unit tests on the >> first interface address that has the BROADCAST option already configured. >> Such the loopback interface is not taken into account. >> >> The test will fail if there is no interface address that has the BROADCAST >> option configured. >> >> All of that could also be solved differently, e.g. with a virtual network. >> I am not sure if that exists for unit testing. >> >> Cheers, >> >> Philipp >> >> >> On 14/01/16 19:41, "[email protected] on behalf of Ian Boston" < >> [email protected] on behalf of [email protected]> wrote: >> >> >Hi, >> > >> >Does the patch work ? >> > >> >According to the answer in the serverfault article referenced in OAK-3884 >> >it should not >> > >> >I tried the pattern referenced on OSX using nc and it doesn't work. The >> >original poster seems to think it works, but those answering disagree and >> >the posted wasn't able to tell them which kernel it worked on..... >> > >> > >> >"The "solution" you are asking for does not exist (or at least *should not >> >work*) on any platform unless the loopback interface supports BROADCAST >> (as >> >can be determined by the flags field in ifconfig) -- The platform(s) you >> >are talking about *do not advertise support for broadcasting on the >> >loopback interface*, therefore you cannot do what you're asking." >> > >> > >> >There are some other less complimentary comments. >> > >> >It might be possible, with root access to the test machine, to setup >> >several tun interfaces, connected to a bridge to create a virtual network >> >on the same machine. You can do the same with multiple docker hosts on the >> >same machine.... but all of that requires some setup that a Java process >> >isnt going to be able to do. >> > >> >---- >> > >> > >> > >> >For a non loopback network you should not try and work out the broadcast >> >address. IIRC you should set the broadcast flag on the UDP packet. (I >> >assume UDB == UDP ?). >> > >> >I assume you are doing something like: >> > >> > socket = new DatagramSocket(8888, InetAddress.getByName("0.0.0.0")); >> > socket.setBroadcast(true); >> > >> > >> >Hosts on the same subnet will have the same network mast, otherwise they >> >are not on the same subnet. All sorts of things will start to fail. eg if >> >some are /24 and some are /25 all the broadcasts on the /25 subnet will be >> >directed at the .127 host on the /24 subnet. (I haven't tried to see what >> >a switch does with 2 overlapping and misconfigured subnets.). >> > >> > >> > >> >HTH >> >Best Regards >> >Ian >> > >> > >> > >> > >> > >> >On 14 January 2016 at 17:30, Philipp Suter <[email protected]> wrote: >> > >> >> Hi >> >> >> >> I added a small patch to https://issues.apache.org/jira/browse/OAK-3884 >> >> that could fix the broadcast unit tests for UDBBroadcaster. It seems the >> >> loopback interface is not allowing broadcasting on *NIX systems. The >> >> broadcasting IP has to be found dynamically for a test execution. >> >> >> >> Interesting next step: How could this be configured dynamically within a >> >> clustered set-up? It needs an agreement among all cluster members to use >> >> the same network mask. >> >> >> >> Cheers, >> >> Philipp >> >> >> >> >> >> >>
