[jboss-jira] [JBoss JIRA] Commented: (JGRP-978) JGroups diagnostics uses hard-coded IPv4 multicast address

[Richard Achmatowicz (JIRA)]

    [ https://jira.jboss.org/jira/browse/JGRP-978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12485286#action_12485286 ] 

Richard Achmatowicz commented on JGRP-978:
------------------------------------------

One of the requirements for being able to implement this task is to move assigment of all addresses which may need defaults assigned (i.e. bind_addr, mcast_addr, diagnostics_addr and related addresses such as external_addr) to a single point in the startup of the stack, namely X.init() where X = {UDP, TCP, TCP-NIO, LOOPBACK, SHARED_LOOPBACK, TUNNEL}. This is after properties from the user have been processed, and before sockets are allocated in X.start().

Previously, assignment of addreses was being done:
(i) during Properties processing
(ii) during TP.init() 
(iii) during X.init() processing
(iiv) during X.start() processing

I have now placed all this processing in the following locations:
UDP.init()
BasicTCP.init()
SHARED_LOOPBACK.init()
TUNNEL.init()
LOOPBACK.init()

So addresses are being assigned exactly as before, but now always in init().

Now that this is complete, the algorithm which calculates the desired IP version and and assigns the addresses can be simply performed during init() as well.
Plan to test that for the first time tomorrow.


 

> JGroups diagnostics uses hard-coded IPv4 multicast address 
> -----------------------------------------------------------
>
>                 Key: JGRP-978
>                 URL: https://jira.jboss.org/jira/browse/JGRP-978
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Richard Achmatowicz
>            Assignee: Bela Ban
>            Priority: Minor
>             Fix For: 2.8
>
>         Attachments: UDP.java
>
>
> When  running JGroups using IPv6 bind and multicast addresses, the following messages appear on the console:
> > 20:21:36,565 WARN [UDP] failed to join /224.0.75.75:7500 on vif0.0:
> > java.net.SocketException: No such device
> > 20:21:36,566 WARN [UDP] failed to join /224.0.75.75:7500 on peth0:
> > java.net.SocketException: No such device
> > 20:21:36,566 WARN [UDP] failed to join /224.0.75.75:7500 on xenbr0:
> > java.net.SocketException: No such device 
> The multicast address 224.0.75.75 is used by the JGroups diagnostics handler (in TP.java) to listen for incoming probe requests. Probe requests are issued from clients using Probe.java to find out which JGroups members are using UDP in a given network.
>  
> These messages expose two issues:
> (i) JGroups is trying to join a multicast group on certain Xen virtual interfaces (vif0, peth0, xenbr0) and this is failing
> (ii) JGroups is using a fixed IPv4 multicast address, despite the fact that IPv6 addresses are being used as bind_addresses and multicast addreses.
> Something similar to the first issue was addressed in https://jira.jboss.org/jira/browse/JGRP-167..
> As for the second issue, shouldn't JGroups use default IP addresses which correspond to the IP mode the JGroups instance has been started in (i.e. if JGroups instance bound to IPv4 bind address, use IPv4 diagnostics multicast address; if JGroups bound to IPv6 global address, use IPv6 global diagnostics multicast address, etc)
> This may very likely cause problems if JGroups is run in an IPv6 only environment, where IPv4 socket use is disallowed.
>  

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira