[Fli4l_dev] Unschönes Verhalten von arping

[Heinz-Peter Faasen]

Hallo Peter,

>>>> Man weiß also nachher, dass der Client irgendwann mal angemeldet war,
>>>> aber nicht wann und für wie lange.
>>>
>>> ist logisch, da arping den/die Clients regelmäßig anspricht!
>>
>> Ja, er pingt sich systematisch durch das Netz und findet alle Clients,
>> die aktiv sind. So weit, so gut.
> 
> falsch - er ping nur die, die er aus der dns_dhcp-Konfiuration (HOST_*)
> kennt, und die nicht via RPIN_IGNORE ausgeschlossen wurden.

ah, ok. Das war eine Fehlinterpretation meinerseits.

>>> Aug 12 01:29:06 fli4l local1.info arping[7835]: host 'tk-anlage' is no
>>> longer reachable
>>> Aug 12 01:30:24 fli4l local1.info arping[7835]: host 'tk-anlage' is now
>>> reachable
>>> Aug 12 04:03:19 fli4l local1.info arping[7835]: host 'sky-receiver' is no
>>> longer reachable
>>
>> So sieht das bei mir auch aus und das ist ja auch völlig in Ordnung.
>> Aber es gibt eben nur dann eine Ausgabe, wenn der Client in der
>> DNS-Konfig eingetragen ist und das finde ich nicht schön.
> 
> irgendwoher muss der fli4l die Clients ja kennen, und da ist die
> DNS/DHCP-Konfiguration nun mal die Stelle wo Daten zu Clients konfiguriert
> werden.

Ja sicher, für den ersten Schritt ist das eine absolut legitime 
Vorgehensweise.

Es wäre aber eben schön, wenn er das Auftauchen eines Client, den er 
nicht kennt, ebenfalls protokollieren würde.

>> , die 192.168.1.121 ist für Test-Installationen bewusst ausgespart.
>>
>> Starte ich nun einen Client mit der IP 192.168.1.121, so erfolgt kein
>> Eintrag in das Log, wohl aber in die ARP-Tabelle.
> 
> in der ARP-Tabelle erscheint jedes Gerät, das auf Layer 2 mit dem fli4l
> kommuniziert hat!

Also z.B. jeder Rechner, der ihn als DNS- oder ntp-Server genutzt hat.

>> Ein auf der Konsole ausgelöstes
>>
>> arp -a  ergibt
>>
>> ? (192.168.1.121) at 30:85:a9:a7:e0:18 [ether]  on eth0  ,
>>
>> im Web-IF erscheint die Zeile
>>
>> online	 	   192.168.1.121	30:85:a9:a7:e0:18	eth0
>>
>> Beide Einträge müssten nach dem Abschalten der Maschine verschwinden,
>> aber das passiert leider nicht. Ein Eintrag im Log erfolgt natürlich
>> auch nicht.
> 
> in der ARP-Tabelle versvchwinden Einträge erst nach einem durch den Kernel
> vorgegebenen Timeout

Da passiert bei mir nie etwas. Wie ist der Kernel-Parameter gewählt?

> bzw. wenn man den Eintrag explizit via
> arp -d <ip> -i <Interface>
> aus der arp-Tabelle löscht.

Ja, das hatte ich schon mal probiert und es klappt auch.
Allerdings tauchen die Einträge dann nicht noch mal auf, auch wenn sich 
der entsprechende Rechner erneut anmeldet.

>> host '192.168.1.121' is now reachable
>>
>> bzw.
>>
>> host '192.168.1.121' is no longer reachable
> 
> für Clients, die ihre IP aus der DHCP-Range erhsalten könnte man das ev.
> einbauen.
> Für Clients mit statischer IP Konfiguration müsste mann dazu regelmäßig die
> ARP-Tabelle scannen um diese dynamisch in die arping-Routinen aufnehmen zu
> können,

So hätte ich mir das vorgestellt.

> da sehe ich aber ein eventuelles Problem, das die Last des fli4l
> dann unnötig erhöht wird (abhängig von der Reaktionszeit - also wie of man
> dir ARP-Tabelle scannt und auswertet.

In sehr komplexen Netzwerken und bei hohen Ansprüchen an die Aktualität 
der Tabelle könnte das natürlich passieren.
Aber über zwei Konfig-Parameter (scannen oder nicht, Zeit zw. den 
Läufen) ließe sich das leicht steuern.

Vielen Dank für die ausführlichen Erläuterungen!
Heinz-Peter