slp on dual stack linux box

[Chuck-66]

Hello LiveTribe Team,

  When I run a service agent and a user agent on a dual stack linux box using an IPv6 multicast address,  the service discovery does not work.  But when I run the same code bound to an IPv4 multicast address, it all works like a charm.  The unfortunate thing is that we need slp discovery to run on IPv6.  I've attached the log file of my IPv6 run.  What could be the reason for slp to not run on IPv6?  Below are some system/application config that may help you in your analysis:

 - slp version = livetribe-slp-2.0.1
 - java version = "1.6.0_07"
 - uname -a = Linux ctaf5 2.6.24-19-server #1 SMP Wed Aug 20 18:43:06 UTC 2008 x86_64 GNU/Linux
 - ifconfig:

    eth0      Link encap:Ethernet  HWaddr 00:50:56:b5:67:ee
          inet addr:172.16.109.82  Bcast:172.16.0.0  Mask:255.255.255.0
          inet6 addr: fe80::250:56ff:feb5:67ee/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:335853 errors:0 dropped:0 overruns:0 frame:0
          TX packets:36039 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:31658295 (30.1 MB)  TX bytes:8078160 (7.7 MB)
          Base address:0x1070 Memory:f4820000-f4840000

eth1      Link encap:Ethernet  HWaddr 00:50:56:b5:3f:7d
          inet6 addr: fdf8:c879:493e:1:250:56ff:feb5:3f7d/64 Scope:Global
          inet6 addr: fe80::250:56ff:feb5:3f7d/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:26945 errors:0 dropped:0 overruns:0 frame:0
          TX packets:446 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:2250217 (2.1 MB)  TX bytes:50957 (49.7 KB)
          Base address:0x1078 Memory:f4840000-f4860000

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:12201 errors:0 dropped:0 overruns:0 frame:0
          TX packets:12201 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:9452744 (9.0 MB)  TX bytes:9452744 (9.0 MB)

Please let me know if you need more information.  Thanks in advance for your help.

Regards,
Chuck Davies


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[simonebordet]

Hi,

On Fri, Jan 23, 2009 at 17:49, Chuck <foxman74@...> wrote:
> Hello LiveTribe Team,
>
>   When I run a service agent and a user agent on a dual stack linux box
> using an IPv6 multicast address,  the service discovery does not work.  But
> when I run the same code bound to an IPv4 multicast address, it all works
> like a charm.  The unfortunate thing is that we need slp discovery to run on
> IPv6.  I've attached the log file of my IPv6 run.  What could be the reason
> for slp to not run on IPv6?

The specification for SLP on IPv6 is RFC 3111, which specify different
addresses for binding directory agents and service agents to multicast
addresses so they can be found. This is currently not implemented in
LiveTribe SLP.

So there is SLP for IPv4 and SLP for IPv6, and they're like 2
different beasts (apart the SLP messages which of course are
identical).

I think you are in a mixed situation where you're using SLP for IPv4
on an IPv6 stack. There may be a small chance that this will work, but
I am not sure.

Specifically, from your logs I see that you are binding to FF01::1
(line 317 and 330). This multicast address is the equivalent of
127.0.0.1, so basically no packet ever hits the cable.
Can you configure that correctly ? Most of the times, this is due to
the fact that the host configuration is not setup properly, so double
check your /etc/hosts file. Doing InetAddress.getLocalhost() should
*not* return the loopback address, but the real address of the host.

Simon
--
http://bordet.blogspot.com
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless.   Victoria Livschitz

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Chuck-66]

Hi,
 
Thank you for the prompt reply.  I went ahead and changed to bind to multicast address = "FF05::1:1000".  And it still was not able to locate the services.  One thing I noticed in the log though is that calling InetAddress.getLocalHost() returns an IPv4 address - ctaf5/172.16.109.82.  Another strange twist is running this application on a dual stack windows XP OS works (and calling InetAddress.getLocalHost() returns an IPv4 address too) !  I've attached a zip file containing the linux log as well as the windows log.  Thanks again for the help.

Regards,
Chuck

On Fri, Jan 23, 2009 at 12:38 PM, Simone Bordet <simone.bordet@...> wrote:

Hi,

On Fri, Jan 23, 2009 at 17:49, Chuck <foxman74@...> wrote:
> Hello LiveTribe Team,
>
>   When I run a service agent and a user agent on a dual stack linux box
> using an IPv6 multicast address,  the service discovery does not work.  But
> when I run the same code bound to an IPv4 multicast address, it all works
> like a charm.  The unfortunate thing is that we need slp discovery to run on
> IPv6.  I've attached the log file of my IPv6 run.  What could be the reason
> for slp to not run on IPv6?

The specification for SLP on IPv6 is RFC 3111, which specify different
addresses for binding directory agents and service agents to multicast
addresses so they can be found. This is currently not implemented in
LiveTribe SLP.

So there is SLP for IPv4 and SLP for IPv6, and they're like 2
different beasts (apart the SLP messages which of course are
identical).

I think you are in a mixed situation where you're using SLP for IPv4
on an IPv6 stack. There may be a small chance that this will work, but
I am not sure.

Specifically, from your logs I see that you are binding to FF01::1
(line 317 and 330). This multicast address is the equivalent of
127.0.0.1, so basically no packet ever hits the cable.
Can you configure that correctly ? Most of the times, this is due to
the fact that the host configuration is not setup properly, so double
check your /etc/hosts file. Doing InetAddress.getLocalhost() should
*not* return the loopback address, but the real address of the host.

Simon
--
http://bordet.blogspot.com
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless.   Victoria Livschitz

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email

[simonebordet]

Hi,

On Fri, Jan 23, 2009 at 19:44, Chuck <foxman74@...> wrote:

>
> Hi,
>
> Thank you for the prompt reply.  I went ahead and changed to bind to
> multicast address = "FF05::1:1000".  And it still was not able to locate the
> services.  One thing I noticed in the log though is that calling
> InetAddress.getLocalHost() returns an IPv4 address - ctaf5/172.16.109.82.
> Another strange twist is running this application on a dual stack windows XP
> OS works (and calling InetAddress.getLocalHost() returns an IPv4 address
> too) !

This is surprising, but seems that there's hope then.

> I've attached a zip file containing the linux log as well as the
> windows log.  Thanks again for the help.

Where did you attach it ?

Simon
--
http://bordet.blogspot.com
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless.   Victoria Livschitz

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Chuck-66]

Oops.  Sorry.  Please see attached file.  There's hope indeed. :)

On Fri, Jan 23, 2009 at 2:35 PM, Simone Bordet <simone.bordet@...> wrote:

Hi,

On Fri, Jan 23, 2009 at 19:44, Chuck <foxman74@...> wrote:
>
> Hi,
>
> Thank you for the prompt reply.  I went ahead and changed to bind to
> multicast address = "FF05::1:1000".  And it still was not able to locate the
> services.  One thing I noticed in the log though is that calling
> InetAddress.getLocalHost() returns an IPv4 address - ctaf5/172.16.109.82.
> Another strange twist is running this application on a dual stack windows XP
> OS works (and calling InetAddress.getLocalHost() returns an IPv4 address
> too) !

This is surprising, but seems that there's hope then.

> I've attached a zip file containing the linux log as well as the
> windows log.  Thanks again for the help.

Where did you attach it ?

Simon
--
http://bordet.blogspot.com
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless.   Victoria Livschitz

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[simonebordet]

Hi,

On Fri, Jan 23, 2009 at 20:44, Chuck <foxman74@...> wrote:
> Oops.  Sorry.  Please see attached file.  There's hope indeed. :)

From the XP logs, I see no SLP discovery ever succeeded; this may be
normal (nothing to discovery), but only you can tell this.
So I am not sure what you mean by XP working: could you do a
successful SLP discovery ?

From the Linux logs, it seems JGroups is bound to the same port and
receives the packet but discards it (line 329) ?

I think the best way to go now is to write the simplest possible
multicast client and server app on IPv6 Linux, and see if that works.
If not, then you may have other problems. I would also use address
FF05::1:50008, to see if it makes any difference.

Basically the idea is to reduce the variables at minimum, and check
first if multicast is working with a small app, and then step by step
see what is needed to make JBoss + JGroups + LiveTribeSLP work.

Simon
--
http://bordet.blogspot.com
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless.   Victoria Livschitz

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Chuck-66]

Yes SLP discovery worked on XP.  The way I know this is because certain services would only come up if a specific service is discovered.  I will do like you said and write the simplest client and server and try it on linux IPv6.  Will keep you posted.  Thanks.

Regards,
Chuck

On Fri, Jan 23, 2009 at 3:06 PM, Simone Bordet <simone.bordet@...> wrote:

Hi,

On Fri, Jan 23, 2009 at 20:44, Chuck <foxman74@...> wrote:
> Oops.  Sorry.  Please see attached file.  There's hope indeed. :)

From the XP logs, I see no SLP discovery ever succeeded; this may be
normal (nothing to discovery), but only you can tell this.
So I am not sure what you mean by XP working: could you do a
successful SLP discovery ?

From the Linux logs, it seems JGroups is bound to the same port and
receives the packet but discards it (line 329) ?

I think the best way to go now is to write the simplest possible
multicast client and server app on IPv6 Linux, and see if that works.
If not, then you may have other problems. I would also use address
FF05::1:50008, to see if it makes any difference.

Basically the idea is to reduce the variables at minimum, and check
first if multicast is working with a small app, and then step by step
see what is needed to make JBoss + JGroups + LiveTribeSLP work.

Simon
--
http://bordet.blogspot.com
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless.   Victoria Livschitz

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email

[Chuck-66]

Ok, so I created a simple test that advertises "test-service" then locates it after.  The advertisement and location happen on the same box.  I've attached 2 logs (ipv4.log - shows a successful location, ipv6.log - unsuccessful).  Please let me know if you need more information.  Thanks again.

Regards,
Chuck

On Fri, Jan 23, 2009 at 3:06 PM, Simone Bordet <simone.bordet@...> wrote:

Hi,

On Fri, Jan 23, 2009 at 20:44, Chuck <foxman74@...> wrote:
> Oops.  Sorry.  Please see attached file.  There's hope indeed. :)

From the XP logs, I see no SLP discovery ever succeeded; this may be
normal (nothing to discovery), but only you can tell this.
So I am not sure what you mean by XP working: could you do a
successful SLP discovery ?

From the Linux logs, it seems JGroups is bound to the same port and
receives the packet but discards it (line 329) ?

I think the best way to go now is to write the simplest possible
multicast client and server app on IPv6 Linux, and see if that works.
If not, then you may have other problems. I would also use address
FF05::1:50008, to see if it makes any difference.

Basically the idea is to reduce the variables at minimum, and check
first if multicast is working with a small app, and then step by step
see what is needed to make JBoss + JGroups + LiveTribeSLP work.

Simon
--
http://bordet.blogspot.com
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless.   Victoria Livschitz

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[simonebordet]

Hi,

On Fri, Jan 23, 2009 at 22:05, Chuck <foxman74@...> wrote:
> Ok, so I created a simple test that advertises "test-service" then locates
> it after.  The advertisement and location happen on the same box.  I've
> attached 2 logs (ipv4.log - shows a successful location, ipv6.log -
> unsuccessful).  Please let me know if you need more information.  Thanks
> again.

At this point I have no idea.
Can you just try a simpler program that uses UDP (and not SLP) ? I
mean something like binding a multicast socket on one side to simulate
a listening server, and sending "hello".getBytes() from a datagram
socket from another side to simulate a client ?
If this does not work, we have the proof that something's wrong with
the multicast setup of the machine.

Simon
--
http://bordet.blogspot.com
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless.   Victoria Livschitz

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Chuck-66]

Thanks Simon.  Also worth noting is that JGroups UDP works on IPv6 on the same machine.  Again, thanks for all the help.

Regards,
Chuck

On Fri, Jan 23, 2009 at 5:22 PM, Simone Bordet <simone.bordet@...> wrote:

Hi,

On Fri, Jan 23, 2009 at 22:05, Chuck <foxman74@...> wrote:
> Ok, so I created a simple test that advertises "test-service" then locates
> it after.  The advertisement and location happen on the same box.  I've
> attached 2 logs (ipv4.log - shows a successful location, ipv6.log -
> unsuccessful).  Please let me know if you need more information.  Thanks
> again.

At this point I have no idea.
Can you just try a simpler program that uses UDP (and not SLP) ? I
mean something like binding a multicast socket on one side to simulate
a listening server, and sending "hello".getBytes() from a datagram
socket from another side to simulate a client ?
If this does not work, we have the proof that something's wrong with
the multicast setup of the machine.

Simon
--
http://bordet.blogspot.com
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless.   Victoria Livschitz

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email