Menu
▾
▴
#1675 SLP discovery fails on Unix IPv6 systems
closed-fixed
7
2009-12-15
2009-08-18
No
On UNIX systems which have an IPv6 address configured on the loopback device the SLP discovery fails.
The following example code
ServiceLocationEnumeration mSLEnum = ServiceLocationManager.getLocator(Locale.getDefault()).findServices(new ServiceType("service:wbem"), new Vector().add("default"),"");
while(mSLEnum.hasNext() {}
fails with:
Exception in thread "main" java.lang.RuntimeException: org.sblim.slp.ServiceLocationException: INTERNAL_ERROR; nested exception is:
java.net.SocketException: The socket name is not available on this system.
at org.sblim.slp.internal.ua.SLEnumerationImpl.hasMoreElements(SLEnumerationImpl.java:131)
at slptest.SLPTest.main(SLPTest.java:37)
Caused by: org.sblim.slp.ServiceLocationException: INTERNAL_ERROR; nested exception is:
java.net.SocketException: The socket name is not available on this system.
... 2 more
Caused by: java.net.SocketException: The socket name is not available on this system.
at java.net.PlainDatagramSocketImpl.join(Native Method)
at java.net.PlainDatagramSocketImpl.join(PlainDatagramSocketImpl.java:220)
at java.net.MulticastSocket.joinGroup(MulticastSocket.java:288)
at org.sblim.slp.internal.ua.DatagramRequester.<init>(DatagramRequester.java:121)
at org.sblim.slp.internal.ua.SLEnumerationImpl.getDAList(SLEnumerationImpl.java:184)
at org.sblim.slp.internal.ua.SLEnumerationImpl.hasMoreElements(SLEnumerationImpl.java:129)
... 1 more
Suggestion
Attached Net.patch as a fix proposal
ifconfig info from Patrick:
en0: flags=5e080863,c0<UP,BROADCAST,NOTRAILERS,RUNNING,SIMPLEX,MULTICAST,GROUPRT,64BIT,CHECKSUM_OFFLOAD(ACTIVE),PSEG,LARGESEND,CHAIN>
inet 9.11.98.33 netmask 0xffffff00 broadcast 9.11.98.255
tcp_sendspace 131072 tcp_recvspace 65536 rfc1323 0
en1: flags=5e080863,c0<UP,BROADCAST,NOTRAILERS,RUNNING,SIMPLEX,MULTICAST,GROUPRT,64BIT,CHECKSUM_OFFLOAD(ACTIVE),PSEG,LARGESEND,CHAIN>
inet 10.10.10.4 netmask 0xff000000 broadcast 10.255.255.255
tcp_sendspace 131072 tcp_recvspace 65536 rfc1323 0
lo0: flags=e08084b<UP,BROADCAST,LOOPBACK,RUNNING,SIMPLEX,MULTICAST,GROUPRT,64BIT>
inet 127.0.0.1 netmask 0xff000000 broadcast 127.255.255.255
inet6 ::1/0
tcp_sendspace 131072 tcp_recvspace 131072 rfc1323 1
Two questions:
1) Is the exception happening because lo0 is being treated as an IPv6 address and shouldn't be, or because lo0 is not being treated as an IPv6 address but should be? I'm guessing the former.
2) Is attached patch complete? It would seem to make it much more restrictive on IPv6 addresses, i.e.Net.hasIPv6 would only return true if there is an IPv6 address AND it is site local address. What about link local or global addresses?
Patrick Schaefer: for 2)
? the patch worked for us the best in this way
? it may be that allowing link local addresses could result in the CIMOM reported twice (on the link-local and the site local address)
? for global addresses:
? would it make sense to consider them as well, as SLP makes only sense for the hosts which are in the same subnet
? and for this just the site local would be the correct one
? i think a better fix may be to leave Net.java as it is, but that the SLP code which binds to addresses just uses the site local address
Please see section 4.2.3 of
http://www.ipv6-tf.com.pt/documentos/files/RFCs/rfc3111.txt
This would seem to indicate that global, site-local and link-local are all valid depending on request, so perhaps site-local is all you need in your environment.
I am still trying to track down more info so that this can be resolved correctly.
Hi Patrick:
I could not recreate the problem in linux on my local pc and on blade3f. Can you please provide me access to the env, in which i can recreate the problem.
Thanks and Regards
-Ravi Gummadavelli
There is already a try-catch block in DatagramRequester around the send() because some kernels can't handle sending IPv6 mcast, so there could be issues with joining as well. How about this?
RCS file: /cvsroot/sblim/jsr48-client/src/org/sblim/slp/internal/ua/DatagramRequester.java,v
retrieving revision 1.1.2.11
diff -u -r1.1.2.11 DatagramRequester.java
--- src/org/sblim/slp/internal/ua/DatagramRequester.java 23 Feb 2009 18:25:57 -0000 1.1.2.11
+++ src/org/sblim/slp/internal/ua/DatagramRequester.java 16 Sep 2009 12:35:34 -0000
@@ -118,7 +118,14 @@
if (this.iUseV6) {
this.iDst0 = IPv6MulticastAddressFactory
.get(SLPDefaults.IPV6_MULTICAST_SCOPE, pRqstMsg);
- mcastSocket.joinGroup(this.iDst0);
+ try {
+ mcastSocket.joinGroup(this.iDst0);
+ } catch (IOException ioe) {
+ // some kernels can't handle IPv6 mcast
+ TRC.warning("IOException caught during join, disabling IPv6: " + ioe.getMessage(),
+ ioe);
+ this.iDst0 = null;
+ }
}
if (this.iUseV4) {
this.iDst1 = SLPConfig.getMulticastAddress();
There seems to be some indecision as to whether to filter out loopback interfaces before SLP discovery. RFC 4291 (IP Version 6 Addressing Architecture) contains the following:
*****
2.5.3. The Loopback Address
The unicast address 0:0:0:0:0:0:0:1 is called the loopback address.
It may be used by a node to send an IPv6 packet to itself. It must
not be assigned to any physical interface. It is treated as having
Link-Local scope, and may be thought of as the Link-Local unicast
address of a virtual interface (typically called the "loopback
interface") to an imaginary link that goes nowhere.
The loopback address must not be used as the source address in IPv6
packets that are sent outside of a single node. An IPv6 packet with
a destination address of loopback must never be sent outside of a
single node and must never be forwarded by an IPv6 router. A packet
received on an interface with a destination address of loopback must
be dropped.
*****
I don't see anything in here that precludes looking for services over the loopback interface.
Christoph: On IPv4 SLP using the broadcast and so also for the IPv4 loopback a SLP broadcast is possible. But with IPv6 SLP do multicast and that is not possible with just the loopback address. Because of this protocol change I suggested to skip the loopback address for IPv6 since only an IPv6 loopback address will always fail the IPv6 SLP. If there is any other IPv6 adress available on the system I agree to try the SLP IPv6 discovery and handle the exception.
Dave: The part about ignoring IPv6 loopbacks for SLP still bothers me. Do you have a reference to an RFC or other specification that states that it is not possible to do multicast with just the loopback address. Or is this something specific to SLP only? The RFCs I have read indicate that multicasting is quite possible on the loopback address, and I have asked a couple networking experts with one responding:
Is this what you are trying to say? We need to put in a solution that works for everyone, so if you are saying that IPv6 loopback will always fail in TPC environment, we still need to consider other environments. Much like your original patch (ignoring everything except site-local addresses) works great in TPC but will prohibit other folks from using IPv6 over link-local addresses.
So, lots of typing (: but what it boils down to, does your statement "But with IPv6 SLP do multicast and that is not possible with just the loopback address" just apply to TPC environment or does it apply to all environments everywhere for SLP?
2839595_patch
Patch sent for community review. During a 2 week period any exploiter may comment on the patch, request changes or turn it down completely (with good reason). For the time being the patch is part of the "Experimental" branch in CVS.
The community review is completed and we received no substantial critisism. Therefore the patch has been approved and merged into the "HEAD" branch. The next release will pick it up.
The patch was picked up by release 2.1.3 and will be closed.