Hello, Our network administrators say that *our company's switches do not block multicast or broadcast traffic*. To check if this it's true, we've forgotten about Reggie and we've written a little Java program that simply uses a MulticastSocket to send packets to the multicast IP *224.0.1.84 and attacking the port 4160*. Of course, this program failed in the network office, while it worked perfectly on my home's network.
We are completely sure that it's a problem related to multicast packets. Maybe it's related to Windows XP or 7 Firewall? In the company there is a Group Policy commanding the Firewall, but we can define some exceptions and we have the multicast/broadcast response enabled. Is that enough, or is there some other issue that remains hidden? Please, any hint is welcome, because our goal is to deploy this software in a production environment, not only in a domestic network! Thanks and regards 2011/9/29 Christopher Dolan <[email protected]> > Yes, most enterprise switches block multicast by default. That's probably > your issue. > > Another possible issue is reverse DNS. If reggie is broadcasting a private > hostname or IP address for other machines to call back to it, then it's not > going to work. We've also had issues with dual-NIC servers where clients > always try to connect to the primary NIC (as specified in the Windows > interface binding order) and do not fail over to the secondary NIC. The > usual cause of that problem is passing a null host to > TcpServerEndpoint.getInstance() because in that code path, JERI just picks > the first IP address from a reverse DNS lookup. The solution in that case is > to instead pass the results of > InetAddress.getLocalHost().getCanonicalHostName() as the hostname, or > hard-code the public host name. > > I'm suspicious of your "just once" result. Maybe you changed the group > name? Remember that the group is case-sensitive. > Chris > > > -----Original Message----- > From: Sergio Aguilera Cazorla [mailto:[email protected]] > Sent: Thursday, September 29, 2011 1:16 PM > To: [email protected] > Subject: Re: Reggie's visibility in discovery process > > Hello, > > At last we could perform some testing on Reggie's discovery using multicast > protocol. I can provide the following results: > > - The program performs perfectly when we make a Unicast discovery, > attacking > directly the URL where the Lookup service is located. > > - We can ping the two machines. Even, we can acces the folder server by the > HTTP server, and get the reggie-dl.jar classfiles needed to communicate > with > the Lookup. > > - All machines in the office are Windows XP SP3 and Windows 7. None of the > combinations server/client XP-7 has thrown a good result. > > - We are communicating through switches in the LAN of a enterprise. Do you > think that multicast packets are bein blocked by intermediate nodes? > > - The most misteryous fact: we could perform multicast discovery > succesfully > *just once*, the first time we tried. That's suspicious, is there some > class > or service that remains hidden and doesn't allow you to perform multicast > discovery more than once? > > Any help on reggie's weird behaviour is very welcome. If I can solve this > problem, no doubt I will write a short explanation for the community, > because I think it has to be a very common problem. > > Regards. > > > > 2011/9/22 Иван Бишевац <[email protected]> > > > 1. Could you ping two machines? > > 2. Which operating system you use? > > 3. Are you communicating through router? > > > > > -- *Sergio Aguilera*
