rarp daemon not responding to multicast mac address

[deepa_6]

The rarpd of HP-UX 11 is not responding to the RARP Request which
has the destination ethernet address set to 01:00:5e:00:00:01

The same process responds when the same request is sent to either the
ethernet broadcast address or to its ethernet address.

Any clarification in this regard will help.

FYI, ping to 224.0.0.1 (from linux) goes out with the ethernet
destination address set to 01:00:5e:00:00:01 for which the same solaris
box is responding, indicating that multicast is working. Infact the
ifconfig lan0 shows MULTICAST for that interface. Only the rarpd is
not responding to the request. FYI, nettl shows that the packet is
being received.

Thanks
optimist

[Michael Steele_2]

Some files to check: /var/tmp/rarpd.db and syslog. Debugging option -d.

[rick jones]

You seem to have three systems here? A linux box, a Solaris box and an HP-UX box.

Are you sure that the HP-UX box has joined the multicast group that would have it's NIC listening to that multicast address?

You might run tcpdump on the HP-UX system to see if the rarp request actually arrives in the host.

Ifconfig showing MULTICAST for an interface does not mean that a specific multicast address is enabled, only that the interface is capable of receiving multicasts.

Also, when you say the rarp request has the destination of 01:00:5e:00:00:01 is that a MAC in the rarp header (i'm not overly familiar with rarp packet headers), or is that the destination MAC in the Ethernet header?

[deepa_6]

michael
u asked to check some files
>Some files to check: /var/tmp/rarpd.db and syslog. Debugging option -d.

/var/tmp/rarpd.db says:
Dumping configuration file /etc/rarpd.conf as of Thu Jun 15 18:51:48 2006

hardware=0x00:11:25:bf:61:f9 ip=9.124.101.92
hardware=0x08:00:09:26:ec:19 ip=15.13.136.68
hardware=0x08:00:09:17:0a:93 ip=15.13.136.74
Dump complete

and syslog says:
mail.debug /var/adm/syslog/mail.log
*.info;mail.none /var/adm/syslog/syslog.log
*.alert /dev/console
*.alert root
*.emerg *

how does that help?

[deepa_6]

hey rick!

>You seem to have three systems here? A linux box, a Solaris box and an HP-UX box.
-right.

Are you sure that the HP-UX box has joined the multicast group that would have it's NIC listening to that multicast address?
>yes i am because all hp, solaris reply when i run multicast ping on linux:ping 224.0.0.1
then why doesn't it for rarp..

>You might run tcpdump on the HP-UX system to see if the rarp request actually arrives in the host.

>Also, when you say the rarp request has the destination of 01:00:5e:00:00:01 is that a MAC in the rarp header (i'm not overly familiar with rarp packet headers), or is that the destination MAC in the Ethernet header?
-No, the destination of 01:00:5e:00:00:01 is a MAC in the destination MAC in the Ethernet header.
The destination MAC address in rarp header is of the source mac so that it replies back to it!

FYI the HP-UX box dos receive the rarp request packet as it shows the foll dump on nettl:

=======Ethernet==========================
=
Source : 00-11-25-bf-61-f9 [I] [ ]
Dest : 01-00-5e-00-00-01 [M] [ ] TRACED LEN: 60
Date : Thu Jun 22 10:14:31.718397 IST 2006
================================ RARP PROBE (inbound -- [ICS]) ============
Source: 255.255.255.25500-11-25-bf-61-f9
Requesting: 0.0.0.0

But still end of the day rarpd replies only to unicast or broadcast but not to multicast..why?

[rick jones]

So, having seen that the rarp packet arrives at the host, the next thing to do is to see if it arrives at the rarpd. For that I would suggest a tusc system call trace of rarpd.

ftp://ftp.cup.hp.com/dist/networking/tools/

I think there is a copy on the developer resources site as well.

[deepa_6]

So, having seen that the rarp packet arrives at the host, the next thing to do is to see if it arrives at the rarpd.

> no it does not arrive at the rarpd at all!!
But nettl shows it arrived at the system
but what does that mean...is there any sort of software that hp os uses that prevents any multicast packet to reach rarp daemon??

if yes, plz suggest some work around..how to get it going through the s/w filter..
plz help ..i'm on a roadblock!! (* *)
} {
^ ^

[rick jones]

I suspect the rarpd needs to bind something additional when it creates its stream. Maybe DL_PROMISC_SAP or perhaps DL_PROMISC_MULTI. Decoding DLPI would be a bit "fun" with tusc since I don't think tusc will do it for you, but you might try taking a verbose tusc trace of rarpd from its startup (be sure to follow the forks).

Also, at this point you may need to open an official call with the Response Centre.

Of course, it would be helpful to your case to have chapter and verse from the RARP specs showing an expectation that a rarpd implementation should respond to requests carried in multicast MACs in the first place :) I cannot say I've looked at the specs myself, but from what I've heard over the years, I was under the impression that RARP was a "unicast" kind of thing. I guess at this point I'll be shown wrong and will have to read the specs :) :) :)

[rick jones]

BTW, are you also the person asking the same sort of question about Solaris 10 in comp.unix.solaris?

If so, that Solaris rarpd is behaving the same way suggests a number of possibilities:

*) RARP isn't meant to be multicast
*) HP-UX and Sun rarpd have a common ancestor
*) Linux rarpd is broken
*) others I've not thought of :)

One of the Sun people there had a good point - make sure you do the packet sniffing in "non-promiscuous" mode. There should be an option for that in tcpudmp just like in snoop.

[deepa_6]

>I suspect the rarpd needs to bind something additional when it creates its stream. Maybe DL_PROMISC_SAP or perhaps DL_PROMISC_MULTI. Decoding DLPI would be a bit "fun" with tusc since I don't think tusc will do it for you, but you might try taking a verbose tusc trace of rarpd from its startup (be sure to follow the forks).
-I am not getting any help with tusc..it just doesn't enter the rarpd daemon

>Also, at this point you may need to open an official call with the Response Centre.
-srry i don't know the process


BTW, are you also the person asking the same sort of question about Solaris 10 in comp.unix.solaris?
>yup! i am deepak the same person...the problem is same with solaris and hp but linux works!

*) RARP isn't meant to be multicast
>probably, but why not?

make sure you do the packet sniffing in "non-promiscuous" mode.
There should be an option for that in tcpudmp just like in snoop.
>i am using nettl in hp for tcpdump but i don't know how to do nettl in non promiscuous mode...
BTW on solaris when i tried using snoop -P command it gave the same result..:(

I still don't understand why sholdn't rarp work for multicast..

[rick jones]

Well, given that ARP is for resolving *unicast* IP addresses to MAC addresses, and that one is "never" supposed to get a broadcast or multicast MAC address for a unicast IP address, and given that one ostensibly has a unicast MAC one wants to reverse map to an IP, and that Multicast IP's map algorithmicly to MACs, it seems plausible that the designers of RARP would not have considered the case of someone sending a RARP request to a multicast MAC address.

If that is the case, you may have just found yourself an opportunity to contribute something to the IETF :)