opensand team mailing list archive

[Fabrice HOBAYA <fabrice.hobaya@xxxxxxxxxxxxxxxxxxxx>]

Hi all,

It seems that there is an unusual behavior regarding the SARP (Satellite
Address Resolution Protocol) management in the OpenSAND platform.

*** Usual behavior: (well known)
Let's take a host with the following routing and ARP tables:

Routing table:
Dest         Gateway   iface
@IP_dst      @IP_gw    ...
...          ...       ...

ARP table:
IP         MAC
@IP_gw     @MAC_gw
...        ...

When the host sends a packet to the PC_dst, it first checks the routing
table to get the gateway, then it checks the ARP table to get the
layer 2 (MAC) address of the gateway.

*** Behavior in OpenSAND:
Considering ST1 in the OpenSAND platform with the following routing and
SARP tables:

Routing table:
Dest                      Gateway       iface
192.168.30.0/24   192.168.19.1 (ST3)    opensand
192.168.19.0      0.0.0.0               opensand
...               ...                   ...

SARP table:
IP                Tal_ID
192.168.19.0/24     3


ST1 wants to reach the network 192.168.30.0/24 behind the ST3. When the
ST1 checks the SARP table to join 192.168.30.X it looks for the entry
corresponding to 192.168.30.X (instead of looking for 192.168.19.1, that
is the gateway to join 192.168.30.0/24). To make it work in OpenSAND,
you have to add the entry 192.168.30.0/24 <=> 3 in the SARP table.

IMHO, it has to be corrected in order to first check the routing table to get
the gateway before checking the SARP table (in such case; we could have a
"standard" behavior).

BR,
Fab.

--
Fabrice HOBAYA
PhD - Réseaux, Télécommunications, Systèmes et Architectures
Ingénieur d'études Viveris Technologies
1 Avenue de l'Europe - Parc technologique du Canal -
Bat C - 1er étage - 31400 Toulouse - France
fabrice.hobaya@xxxxxxxxxxxxxxxxxxxx