Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 318260

Summary:

UDP Discovery does not send out any packets

Product:

[Tools] TCF

Reporter:

Daniel Friederich <danielfriederich>

Component:

Core

Assignee:

Project Inbox <dsdp.tm.tcf-inbox>

Status:

RESOLVED FIXED

QA Contact:

Martin Oberhuber <mober.at+eclipse>

Severity:

normal

Priority:

CC:

cdtdoug, eugene, john.cortell

Version:

unspecified

Target Milestone:

0.4.0

Hardware:

OS:

Windows 7

Whiteboard:

Attachments:

Description	Flags
Do not explicitly check if the udp broadcast address is contained in the subnet.	none

Description Daniel Friederich

2010-06-28 19:07:19 EDT

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.

Comment 1 Daniel Friederich

2010-06-28 19:54:58 EDT

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.

Comment 2 Daniel Friederich

2010-06-28 20:10:14 EDT

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.

Comment 3 Eugene Tarassov

2010-06-30 16:12:46 EDT

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.

Comment 4 Doug Schaefer

2011-05-17 10:50:52 EDT

Moving bugs to new home for IP log.

Comment 5 Martin Oberhuber

2013-05-23 19:16:29 EDT

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.

Comment 6 Martin Oberhuber

2013-06-05 06:28:39 EDT

Bulk change: Marking all bugs from the TM era (until June 2011) target 0.3