arp error : /etc/ethers cannot have self MAC<->IP?

I was trying to specify a static arp list for servers in a cluster by using

arp -f /etc/ethers

cat /etc/ethers
00:07:43:06:8A:AD 192.168.0.1
00:07:43:06:8A:AA 192.168.0.2
00:07:43:06:8A:B0 192.168.0.3
00:07:43:06:8A:AB 192.168.0.4
00:07:43:06:8A:AC 192.168.0.5
00:07:43:06:88:38 192.168.0.6
[snip]

I thought I could copy the same /etc/ethers on all servers but it seems
that if the (MAC,IP) of the server itself is in the file then arp throws an
error:

SIOCSARP: Invalid argument
arp: cannot set entry on line 1 of etherfile /opt/sbin/ethers !

Then if I comment out the offending line things work fine.

e.g. on 192.168.0.1 I must remove line1 of /etc/ethers.

Is this behaviour to be expected? Or is there something else at work here?

--
Rahul

Hello,

Rahul a écrit :
> I was trying to specify a static arp list for servers in a cluster by using
>
> arp -f /etc/ethers
>
> cat /etc/ethers
> 00:07:43:06:8A:AD 192.168.0.1
> 00:07:43:06:8A:AA 192.168.0.2
> 00:07:43:06:8A:B0 192.168.0.3
> 00:07:43:06:8A:AB 192.168.0.4
> 00:07:43:06:8A:AC 192.168.0.5
> 00:07:43:06:88:38 192.168.0.6
> [snip]
>
> I thought I could copy the same /etc/ethers on all servers but it seems
> that if the (MAC,IP) of the server itself is in the file then arp throws an
> error:
>
> SIOCSARP: Invalid argument
> arp: cannot set entry on line 1 of etherfile /opt/sbin/ethers !

/opt/sbin/ethers ?

> Then if I comment out the offending line things work fine.
>
> e.g. on 192.168.0.1 I must remove line1 of /etc/ethers.
>
> Is this behaviour to be expected? Or is there something else at work here?

man 8 arp says :
-i If, --device If
Select an interface. [...] When setting a
permanent or temp ARP entry this interface will be associated
with the entry; if this option is not used, the kernel will
guess based on the routing table.

Read the last part. The host's own address is routed on the loopback
interface lo, and trying to create an ARP entry on this interface leads
to the error. I guess you can avoid this by explicitly specifying the
interface in the arp command with the -i option.

habibielwa7id a écrit :
> On Aug 7, 2:05 am, Rahul <nos...@nospam.invalid> wrote:
>>
>> arp -f /etc/ethers
>>
>> cat /etc/ethers
>> 00:07:43:06:8A:AD 192.168.0.1
>> 00:07:43:06:8A:AA 192.168.0.2
[...]
> You just reversed the order, The ip addresses should be mentioned
> first like,
> 192.168.0.1 00:07:43:06:8A:AD

man 8 arp says :

As a special case for compatibility the order of the hostname and the
hardware address can be exchanged.

habibielwa7id a écrit :
>
>>> On Aug 7, 2:05 am, Rahul <nos...@nospam.invalid> wrote:
>>>> arp -f /etc/ethers
>>>> cat /etc/ethers
>>>> 00:07:43:06:8A:AD 192.168.0.1
>>>> 00:07:43:06:8A:AA 192.168.0.2
>> [...]
>>> You just reversed the order, The ip addresses should be mentioned
>>> first like,
>>> 192.168.0.1 00:07:43:06:8A:AD
>>
>> man 8 arp says :
>>
>> As a special case for compatibility the order of the hostname and the
>> hardware address can be exchanged.
>
> -Try it and you will find it will not work but in the order I
> mentioned, First the ip address then the mac address, This is what I
> found but on RedHat systems.

It does not work in the command line with -s, but it does works in a
file with -f, at least on my Debian system. I guess the man page lacks
accuracy. Note that Rahul wrote :

>>>> Then if I comment out the offending line things work fine.

clearly meaning that the reverse order is accepted.

Pascal Hambourg <boite-a-(E-Mail Removed)> wrote in news:i3p0ov$1h7l
$(E-Mail Removed):

> It does not work in the command line with -s, but it does works in a
> file with -f, at least on my Debian system. I guess the man page lacks
> accuracy. Note that Rahul wrote :
>
>>>>> Then if I comment out the offending line things work fine.
>
> clearly meaning that the reverse order is accepted.
>

I'm pretty sure that my "MAC IP" tuples were accepted. There was no error
and a subsequent arp showed that the tables were correctly popluated.

Furthermore I based it upon what I read in man ethers. It clearly says
MAC followed by IP. I always used it with the arp -f option loading from
a file.


DESCRIPTION
/etc/ethers contains 48 bit Ethernet addresses and their
corresponding IP numbers, one line for each IP number:

Ethernet-address IP-number

The two items are separated by any number of SPACE and/or TAB char
acters. A # at the beginning of a line
starts a comment which extends to the end of the line. The
Ethernet-address is written as x:x:x:x:x:x, where x
is a hexadecimal number between 0 and ff which represents one byte
of the address, which is in network byte
order (big-endian). The IP-number may be a hostname which can be
resolved by DNS or a dot separated number.

EXAMPLES
08:00:20:00:61:CA pal

FILES
/etc/ethers

--
Rahul

habibielwa7id <(E-Mail Removed)> wrote in news:97f50116-4ac5-4a08-b735-
(E-Mail Removed):

> -Try it and you will find it will not work but in the order I
> mentioned, First the ip address then the mac address, This is what I
> found but on RedHat systems.
> A note for Rahul, The system will not add those static entries at
> startup automatically, So add command arp -f on rc.local for example,

You mean /etc/ethers is not read automatically by the system?

> -I use static ARP entries on not secure networks to add extra security
> as it fights the man in the middle attacks that use ARP spoofing, And
> it also blocks blocking using ARP poisoning that may be caused by
> using dump applications like NetCut or some similar methods, The
> author didn't ask about that but I talked my be some bodies can
> benefit from that information any way specially if there networks are
> not secure.

For me it wasn't a security issue. Trying to run some MPI codes using the
OFED stack and one of the developers had a suspicion that arp resolution
was somehow causing the timeouts.


--
Rahul

Pascal Hambourg <boite-a-(E-Mail Removed)> wrote in
news:i3iaee$2jg7$(E-Mail Removed):

> /opt/sbin/ethers ?

Sorry. Ignore that. It'll end up in /etc/ethers eventually. I was debugging
and /opt/sbin being a cross mounted NFS filesystem I was using it to share
the ethers file.

>> Then if I comment out the offending line things work fine.
>>
>> e.g. on 192.168.0.1 I must remove line1 of /etc/ethers.
>>
>> Is this behaviour to be expected? Or is there something else at work
>> here?
>
> man 8 arp says :
> -i If, --device If
> Select an interface. [...] When setting a
> permanent or temp ARP entry this interface will be
> associated with the entry; if this option is not used,
> the kernel will guess based on the routing table.
>
> Read the last part. The host's own address is routed on the loopback
> interface lo, and trying to create an ARP entry on this interface
> leads to the error. I guess you can avoid this by explicitly
> specifying the interface in the arp command with the -i option.

Thanks! I never figured that out. On the other hand I guess it's better to
get it routed on the loopback anyways. So I'll just keep commenting out the
line with the local MAC's.


--
Rahul

Rahul a écrit :
> Pascal Hambourg <boite-a-(E-Mail Removed)> wrote :
>
>> man 8 arp says :
>> -i If, --device If
>> Select an interface. [...] When setting a
>> permanent or temp ARP entry this interface will be
>> associated with the entry; if this option is not used,
>> the kernel will guess based on the routing table.
>>
>> Read the last part. The host's own address is routed on the loopback
>> interface lo, and trying to create an ARP entry on this interface
>> leads to the error. I guess you can avoid this by explicitly
>> specifying the interface in the arp command with the -i option.
>
> Thanks! I never figured that out. On the other hand I guess it's better to
> get it routed on the loopback anyways. So I'll just keep commenting out the
> line with the local MAC's.

Don't worry : creating an ARP entry for any local address on any
non-loopback interface won't change its routing, it will still be routed
through the loopback interface. The ARP entry is harmless, it will just
no be used because a local address will never be routed through a
non-loopback interface. The 'local' routing table takes absolute precedence.

First, routing selects the output interface. Only then the kernel checks
the ARP stuff on the selected interface if applicable.

Rahul a écrit :
> habibielwa7id <(E-Mail Removed)> wrote :
>
>> A note for Rahul, The system will not add those static entries at
>> startup automatically, So add command arp -f on rc.local for example,
>
> You mean /etc/ethers is not read automatically by the system?

It is read if something reads it. It seems that the RARP daemon rarpd
uses it as a database to reply to RARP queries, not to create entries in
the kernel ARP cache.