Community
Participate
Working Groups
Build Identifier: Not available. SVN revision 1042 I see on my PC that the java UDP discovery implementation does not send out any packets. The LocatorService considers 2 network interfaces for the UDP discovery, both interfaces get problematic broadcast addresses which do not match the interface address in the first network_prefix_len bits, hence all the UDP packets are filtered out. Details: Java 1.6 (19), machine with 1 HW network card, IP6 enabled, Win7, 64 bit. The LocatorService.refreshSubNetList method adds the following 2 subnets Subnet 0: IP 127.0.0.1, network prefix len = 8, Broadcast 0.255.255.255 Subnet 1: IP 10.82.136.36, network prefix len = 24, Broadcast 255.255.255.255 For Subnet 1, java 1.6 reports a network prefix length of 128, correct would be 22, the code contains a workaround with the guesses prefix of 24. The actual problem however are the broadcast addresses, both of them as reported by java 1.6 do not match the first bits of the network address, therefore the sendDatagramPacket method filters out all UDP messages to broadcast, no packet is sent when intending to broadcast. Eclipse is able to discover peers when it gets port 1534. I saw bug, 312457 about an exception in the UDP discovery, I was not sure if I should consider this to be the same bug. This bugs are related as in both cases the issue is with unexpected input we get from Windows, but here the issue is the discovery not working and not an exception as mentioned in the title of 312457. Reproducible: Always Steps to Reproduce: 1. Start agent which acquires UDP port 1534 2. Start eclipse and check the discovery -> Eclipse does not discover any peers.
As there are 2 network interfaces, there should be 2 UDP broadcast packets sent. For the loopback interface I don't really understand how java 1.6 comes up with a 0.255.255.255 broadcast address. For the other interface, I wonder if the issue is not on our code, more specifically in the assumption that the broadcast address has to match the network addresses first network prefix bits. Using 255.255.255.255 as broadcast address for the primary network adapted seems ok to me, well I have to admit that I'm not an network expert here.
Created attachment 172980 [details] Do not explicitly check if the udp broadcast address is contained in the subnet. This helps for the 2'nd subnet. For the first loopback interface I did not see the packet on the receiving side, so this is not a complete fix.
The problem is caused by JVM bug: InterfaceAddress.getNetworkPrefixLength() does not conform to Javadoc: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6707289 The bug shows up only on Windows when IPv6 is enabled. The bug is supposed to be fixed in Java 1.7. I have committed a workaround for the Java API bug. The workaround uses ipconfig.exe to get correct network prefix length and broadcast address.
Moving bugs to new home for IP log.
Comment on attachment 172980 [details] Do not explicitly check if the udp broadcast address is contained in the subnet. Marking patch obsolete since it was not used.
Bulk change: Marking all bugs from the TM era (until June 2011) target 0.3
