net(t)forum
net(t)work(s) - fli4l - eisfair

Startseite » fli4l » spline.fli4l.dev » Unschönes Verhalten von arping
Unschönes Verhalten von arping [Beitrag #73331] Mon, 12 August 2019 13:04 Zum nächsten Beitrag gehen
Heinz-Peter Faasen ist gerade offline  Heinz-Peter Faasen
Beiträge: 1087
Registriert: July 2010
Senior Member
Hallo,

ich habe kürzlich auf einem System arping aktiviert und nun, bei
Durchsicht der Logs, ein recht unschönes Verhalten bemerkt:

Nur wenn der fli in der Lage ist, einen Name aufzulösen, gelangen die
entsprechenden Einträge ins Log. Da in dem Umfeld der fli den DNS-Server
gibt, werden also alle Clients, die nicht in der Konfig aufgeführt sind,
auch nicht registriert.
Außerdem werden die entsprechenden Einträge nach dem Abschalten des
clients nicht mehr aus der arp-Tabelle gelöscht, egal, wie lange man wartet.
Man weiß also nachher, dass der Client irgendwann mal angemeldet war,
aber nicht wann und für wie lange.

Ist das ein Konfigurationsproblem oder müsste das Design geändert werden?

Gruß
Heinz-Peter
Re: Unschönes Verhalten von arping [Beitrag #73349 ist eine Antwort auf Beitrag #73331] Mon, 12 August 2019 20:31 Zum vorherigen Beitrag gehenZum nächsten Beitrag gehen
LanSpezi
Beiträge: 1109
Registriert: August 2010
Senior Member
Hallo Heinz-Peter,

Am Mon, 12 Aug 2019 13:04:20 +0200 schrieb Heinz-Peter Faasen:

> Hallo,
>
> ich habe kürzlich auf einem System arping aktiviert und nun, bei
> Durchsicht der Logs, ein recht unschönes Verhalten bemerkt:
>
> Nur wenn der fli in der Lage ist, einen Name aufzulösen, gelangen die
> entsprechenden Einträge ins Log. Da in dem Umfeld der fli den DNS-Server
> gibt, werden also alle Clients, die nicht in der Konfig aufgeführt sind,
> auch nicht registriert.
> Außerdem werden die entsprechenden Einträge nach dem Abschalten des
> clients nicht mehr aus der arp-Tabelle gelöscht, egal, wie lange man wartet.
> 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!

> Ist das ein Konfigurationsproblem oder müsste das Design geändert werden?

ich nutze zum eineb in der SYSLOG-Config das folgende:
SYSLOGD_DEST[]='local1.info /var/log/syslog_hosts'
SYSLOGD_DEST[]='local1.debug /dev/null'

das Ergebnis in der /var/log/syslog_hosts sieht dann so aus:
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
Aug 12 04:04:40 fli4l local1.info arping[7835]: host 'sky-receiver' is now
reachable
Aug 12 11:47:20 fli4l local1.info arping[7835]: host 'pc-xxx' is now
reachable
Aug 12 11:54:05 fli4l local1.info arping[7835]: host 'pc-xxx' is no longer
reachable
Aug 12 13:37:18 fli4l local1.info arping[7835]: host 'pc-xxx' is now
reachable
Aug 12 13:44:02 fli4l local1.info arping[7835]: host 'pc-xxx' is no longer
reachable
Aug 12 17:40:28 fli4l local1.info arping[7835]: host 'pc-xxx' is now
reachable
Aug 12 17:44:46 fli4l local1.info arping[7835]: host 'pc-xxx' is no longer
reachable

zusätzlich nutze ich
HTTPD_ARPING_IGNORE_x='<Host der unter HOST_x definiert wurde'

um diese nicht regelmäßig per arpping ansusprechen, z.B. hilft das um bei
nem Smartphone Akku zu sparen.

Gruß Peter
Re: Unschönes Verhalten von arping [Beitrag #73358 ist eine Antwort auf Beitrag #73349] Tue, 13 August 2019 07:56 Zum vorherigen Beitrag gehenZum nächsten Beitrag gehen
Heinz-Peter Faasen ist gerade offline  Heinz-Peter Faasen
Beiträge: 1087
Registriert: July 2010
Senior Member
Hallo Peter,

vielen Dank für Deine Antwort.
Leider ist es mir offenbar nicht gelungen, das Problem hinreichend klar
zu beschreiben. daher versuche ich es nochmals.

>> ich habe kürzlich auf einem System arping aktiviert und nun, bei
>> Durchsicht der Logs, ein recht unschönes Verhalten bemerkt:
>>
>> Nur wenn der fli in der Lage ist, einen Name aufzulösen, gelangen die
>> entsprechenden Einträge ins Log. Da in dem Umfeld der fli den DNS-Server
>> gibt, werden also alle Clients, die nicht in der Konfig aufgeführt sind,
>> auch nicht registriert.
>> Außerdem werden die entsprechenden Einträge nach dem Abschalten des
>> clients nicht mehr aus der arp-Tabelle gelöscht, egal, wie lange man wartet.
>> 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.


> das Ergebnis in der /var/log/syslog_hosts sieht dann so aus:
> 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.

Beispiel:
In der dns_dhcp.txt steht

HOST[]
{
NAME='Mail-Server'
IP4='192.168.1.120'
# MAC='de:ad:be:ef:08:15'
}

HOST[]
{
NAME='Print-Server'
IP4='192.168.1.122'
# MAC='de:ad:be:ef:08:15'
}

, 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.

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.

Zusammenfassung:
Es wäre schön, wenn bei Clients, die nicht in der DNS-Konfig definiert
sind, im Log

host '192.168.1.121' is now reachable

bzw.

host '192.168.1.121' is no longer reachable

erscheinen würde.
Zudem sollten die Einträge aus der ARP-Tabelle gelöscht werden, wenn der
entsprechende Rechner nicht mehr im Netz ist.

Ich hoffe, diesmal ist es klar geworden. Ansonsten bitte einfach
nachfragen. ;)

Vielen Dank für das ausdauernde Lesen!
Heinz-Peter
Re: Unschc3b6nes Verhalten von arping [Beitrag #73359 ist eine Antwort auf Beitrag #73358] Tue, 13 August 2019 09:06 Zum vorherigen Beitrag gehenZum nächsten Beitrag gehen
Marcus Roeckrath ist gerade offline  Marcus Roeckrath
Beiträge: 13107
Registriert: August 2010
Senior Member
Hallo Heinz-Peter,

Heinz-Peter Faasen wrote:

>>> ich habe kürzlich auf einem System arping aktiviert und nun, bei
>>> Durchsicht der Logs, ein recht unschönes Verhalten bemerkt:
>>>
>>> Nur wenn der fli in der Lage ist, einen Name aufzulösen, gelangen die
>>> entsprechenden Einträge ins Log. Da in dem Umfeld der fli den DNS-Server
>>> gibt, werden also alle Clients, die nicht in der Konfig aufgeführt sind,
>>> auch nicht registriert.

Es gibt ein Problem in der aktuellen Version von arping, der teilweise
falsche Exitcodes zurückliefert.

Das habe ich

https://github.com/iputils/iputils/issues/190

gemeldet und ist im Repository auch gefixt. Im eisfair haben wir den Patch
manuell in unsere Version eingebaut.

Vielleicht schlägt hier ja auch dieses Problem durch.

--
Gruss Marcus


Gruß Marcus
Re: Unschc3b6nes Verhalten von arping [Beitrag #73360 ist eine Antwort auf Beitrag #73359] Tue, 13 August 2019 09:59 Zum vorherigen Beitrag gehenZum nächsten Beitrag gehen
Heinz-Peter Faasen ist gerade offline  Heinz-Peter Faasen
Beiträge: 1087
Registriert: July 2010
Senior Member
Hallo Marcus,

danke für den Hinweis.

>>>> ich habe kürzlich auf einem System arping aktiviert und nun, bei
>>>> Durchsicht der Logs, ein recht unschönes Verhalten bemerkt:
>>>>
>>>> Nur wenn der fli in der Lage ist, einen Name aufzulösen, gelangen die
>>>> entsprechenden Einträge ins Log. Da in dem Umfeld der fli den DNS-Server
>>>> gibt, werden also alle Clients, die nicht in der Konfig aufgeführt sind,
>>>> auch nicht registriert.
>
> Es gibt ein Problem in der aktuellen Version von arping, der teilweise
> falsche Exitcodes zurückliefert.
>
> Das habe ich
>
> https://github.com/iputils/iputils/issues/190
>
> gemeldet und ist im Repository auch gefixt. Im eisfair haben wir den Patch
> manuell in unsere Version eingebaut.
>
> Vielleicht schlägt hier ja auch dieses Problem durch.

Ich habe mal auf der Eis64-Testkiste arpscan installiert und einen Scan
laufen lassen.
Er findet nur die Rechner, die im DNS-Server (der fli4l) eingetragen
sind. Jedenfalls werden nur die bei einem

arp -a

ausgegeben.

Ich denke im Moment, dass es an den Skripten liegt, die die Infos
auswerten. Die sind wohl darauf ausgelegt, dass sich eine Verbindung von
Rechnername und IP-Addi herstellen lässt. Bei fehlendem Eintrag in der
DNS-Konfig ist das aber leider nicht der Fall.

Gruß
Heinz-Peter
Re: Unschönes Verhalten von arping [Beitrag #73366 ist eine Antwort auf Beitrag #73360] Tue, 13 August 2019 12:26 Zum vorherigen Beitrag gehenZum nächsten Beitrag gehen
Marcus Roeckrath ist gerade offline  Marcus Roeckrath
Beiträge: 13107
Registriert: August 2010
Senior Member
Hallo Heinz-Peter,

Heinz-Peter Faasen wrote:

>>>> > ich habe kürzlich auf einem System arping aktiviert und nun, bei
>
> Er findet nur die Rechner, die im DNS-Server (der fli4l) eingetragen
> sind. Jedenfalls werden nur die bei einem
>
> arp -a

Der von mir gemeldete Bug betrifft explizit das arping-Binary nicht arp.

> Ich denke im Moment, dass es an den Skripten liegt, die die Infos
> auswerten.

Wegen des arping-Bugs konnte im eisfair-wolsol-Paket nicht der korrekte
On-Off-Status eines Clients ermittelt werden.

--
Gruss Marcus


Gruß Marcus
Re: Unschönes Verhalten von arping [Beitrag #73367 ist eine Antwort auf Beitrag #73366] Tue, 13 August 2019 13:18 Zum vorherigen Beitrag gehenZum nächsten Beitrag gehen
Heinz-Peter Faasen ist gerade offline  Heinz-Peter Faasen
Beiträge: 1087
Registriert: July 2010
Senior Member
Hallo Marcus,

>>>> >> ich habe kürzlich auf einem System arping aktiviert und nun, bei
>>
>> Er findet nur die Rechner, die im DNS-Server (der fli4l) eingetragen
>> sind. Jedenfalls werden nur die bei einem
>>
>> arp -a
>
> Der von mir gemeldete Bug betrifft explizit das arping-Binary nicht arp.

ich habe leider erst beim zweiten Lesen wirklich verstanden, wo das
Problem lag. *knirsch*

>> Ich denke im Moment, dass es an den Skripten liegt, die die Infos
>> auswerten.
>
> Wegen des arping-Bugs konnte im eisfair-wolsol-Paket nicht der korrekte
> On-Off-Status eines Clients ermittelt werden.

Es gibt einen fundamentalen Unterschied:

Der Zustand der bekannten Clients wird korrekt erfasst und Änderungen
werden sauber protokolliert. Da funktioniert also alles.

Auch die unbekannten IPs findet das System, nur kann es sie nicht
entsprechend weiterverarbeiten. Da dürfte der Hebel anzusetzen sein.
Ich muss mal schauen, wann ich genug Zeit am Stück finde, um die Skripte
zu verstehen. Vllt. finde ich dann eine Lösung.

Gruß
Heinz-Peter
Re: Unschönes Verhalten von arping [Beitrag #73413 ist eine Antwort auf Beitrag #73358] Wed, 14 August 2019 16:08 Zum vorherigen Beitrag gehenZum nächsten Beitrag gehen
LanSpezi
Beiträge: 1109
Registriert: August 2010
Senior Member
Hallo Heinz-Peter,

Am Tue, 13 Aug 2019 07:56:22 +0200 schrieb Heinz-Peter Faasen:

>>> 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.

>> 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.

> , 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!
>
> 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 bzw. wenn mann den Eintrag explizit via
arp -d <ip> -i <Interface>
aus der arp-Tabelle löscht.


> 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, 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.


Gruß Peter
Re: Unschc3b6nes Verhalten von arping [Beitrag #73414 ist eine Antwort auf Beitrag #73359] Wed, 14 August 2019 16:11 Zum vorherigen Beitrag gehenZum nächsten Beitrag gehen
LanSpezi
Beiträge: 1109
Registriert: August 2010
Senior Member
Hallo Marcus,

Am Tue, 13 Aug 2019 09:06:06 +0200 schrieb Marcus Roeckrath:

> Es gibt ein Problem in der aktuellen Version von arping, der teilweise
> falsche Exitcodes zurückliefert.

wir sind hier bei fli4l und nicht bei eisfair - fli4l verwendet das in der
busybox integrierte arping

> Vielleicht schlägt hier ja auch dieses Problem durch.

definitiv nicht!

Gruß Peter
Re: Unschönes Verhalten von arping [Beitrag #73416 ist eine Antwort auf Beitrag #73414] Wed, 14 August 2019 16:44 Zum vorherigen Beitrag gehenZum nächsten Beitrag gehen
Marcus Roeckrath ist gerade offline  Marcus Roeckrath
Beiträge: 13107
Registriert: August 2010
Senior Member
Hallo Peter,

Peter Schiefer wrote:

>> Es gibt ein Problem in der aktuellen Version von arping, der teilweise
>> falsche Exitcodes zurückliefert.
>
> wir sind hier bei fli4l und nicht bei eisfair - fli4l verwendet das in der
> busybox integrierte arping
>
>> Vielleicht schlägt hier ja auch dieses Problem durch.
>
> definitiv nicht!

OK, wollte nur auf ein Problem hinweisen, dem wir in eisfair aufgesessen
sind.

--
Gruss Marcus


Gruß Marcus
Re: Unschönes Verhalten von arping [Beitrag #73418 ist eine Antwort auf Beitrag #73413] Wed, 14 August 2019 17:40 Zum vorherigen Beitrag gehenZum nächsten Beitrag gehen
Heinz-Peter Faasen ist gerade offline  Heinz-Peter Faasen
Beiträge: 1087
Registriert: July 2010
Senior Member
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
Re: Unschönes Verhalten von arping [Beitrag #73530 ist eine Antwort auf Beitrag #73413] Sun, 18 August 2019 09:50 Zum vorherigen Beitrag gehen
Heinz-Peter Faasen ist gerade offline  Heinz-Peter Faasen
Beiträge: 1087
Registriert: July 2010
Senior Member
Hallo Peter,

ich habe jetzt mal einen frisch aufgesetzten fli eine Woche lang völlig
unangetastet gelassen und mir angeschaut, was da passiert.

> in der ARP-Tabelle versvchwinden Einträge erst nach einem durch den Kernel
> vorgegebenen Timeout

Der gleich nach dem Start bewusst erzeugte Eintrag in der ARP-Tabelle
ist bis heute nicht verschwunden, obwohl definitiv kein Rechner mit der
speziell ausgewählten IP mehr im Netz aktiv war.

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

Auch das habe ich noch mal ganz genau angeschaut und meine Aussage
bestätigt gefunden: Einmal gelöschte Einträge tauchen nicht mehr auf,
wenn sich eine Maschine mit dieser IP wieder 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.

Die sind dem fli dann ja ohnehin bekannt, sodass man nur den Mechanismus
etwas erweitern würde.

> 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, 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.

Das würde ja leider nicht helfen, wie die obigen Erfahrungen zeigen,
weil die ARP-Tabelle nicht aktuell bleibt.
Evtl. ließe sich das mit entsprechenden Kernel-Einstellungen bereinigen,
aber da habe ich noch nicht geschaut, welche Möglichkeiten es gibt.

Gruß
Heinz-Peter
Vorheriges Thema: Informationen zu den wöchentlichen 4.0-Archiven vom 16.08.2019 (r56456)
Nächstes Thema: FLI4L 4.0 als Ethernet-Router: Stand der "Technik"
Gehe zum Forum:
  


aktuelle Zeit: Tue Dec 10 01:58:36 CET 2019

Insgesamt benötigte Zeit, um die Seite zu erzeugen: 0.15325 Sekunden