[fli4l] Neues stable Release fli4l 3.10.4

[Kay Martinen]

Am 03.11.2015 um 09:41 schrieb Christoph Schulz:
> Kay Martinen schrieb:
> 
>> [win-imonc] zeigte sonst einen hosts-tab an. Der taucht nicht mehr auf. im
>> syslog-tab sehe ich aber die meldungen von arping das seinen loop
>> beendet und auf dem fli in messages noch mehr meldungen über die jew.
>> hosts und ihren status. 
> 
> Kann ich nicht sagen, bei mir erscheint der Hosts-Reiter, allerdings habe 
> ich das jetzt nur mit der korrigierten Version getestet (siehe FFL-1530).

Ich bin unsicher ob ich nicht doch was änderte das dies erklären würde.
Nachfrage: Die Hosts im imonc tauchen doch nur auf wenn in httpd.txt der
arping-bereich aktiv ist. Oder?

Jedenfalls werden sie in der Weboberfläche des FLI korrekt und
vollzählig angezeigt.

N.B. Ein Stolperstein bei OAC. In der Doku steht nur HOST_X_NAME solle
man für die OAC-Hosts eintragen. Ich hab das dummerweise genau so
gemacht (also OAC_x_...='HOST_2_NAME' was Natürlich NICHT funktionierte. :-)

Den Text sollte man ändern das dort der WERT von HOST_X_NAME reingehört
(hätte ja sonst auch die IP sein können) denn mit dem dort vergebenen
Hostnamen funktioniert es.

>> ist aber im bootprotokoll finde ich das hier:
>> [...]
>>> Tue Nov 3 2015 	01:00:56 	Nov 3 01:00:56 fli4l daemon.crit
>>> mini_httpd[2009]: socket :: - Address family not supported by protocol
>>> Tue Nov 3 2015 	01:00:56 	socket: Address family not supported by
>>> protocol
> 
> Ja, das ist normal -- du hast IPv6 nicht aktiviert. Wundert dich die 
> Meldung? Die Zukunft gehört nun einmal IPv6, und alle fli4l-Programme werden 

Ha, Nun nicht mehr! Aber ich sehe da keinen Hinweis auf *anyprotocol*
und das es mit IPv6 zusammen hängt kam mir nicht in den Sinn. Wie auch.
"Adressfamily" kann noch mehr sein als nur ip4 und ip6 (IMHO).


>> Per Telnet und http ist es aber erreichbar, wenn ich auf einem internen
>> host eine extraroute eintrage. Spezielle Fw-regeln habe ich noch NICHT
>> angelegt.
> 
> Das habe ich (siehe meine andere Antwort) immer noch nicht kapiert. Ich 

Das Modem hängt an eth1 und die beiden haben das gleiche Netzsegment
(192.268.254.0/24) und sind direkt per Patchkabel miteinander verbunden.
Da braucht das modem weder route noch gateway damit antworten zum fli
finden.

Und wenn ich im LAN (eth0-seite des FLI) auf meiner Linux-box ein

'route add 192.168.254.0 gw 192.168.1.1' setze dann weiß der wohin er
pakete für dieses Netz senden soll. Also kann der PC das Modem
erreichen, das Modem kann antworten an den PC senden und alles ist
*Knut*! :) Das soll natürlich kein Dauerzustand bleiben. Nur als Test
und Übergang bis DSLTool daten bekommt.

Der FLI forwarded das ja dann sowieso von eth0 zu eth1. Oder ist das der
Punkt wo du stutzig wurdest?


> wette, du hast eine MASQUERADE-Regel und irgendeine Forward-Regel aktiv. 
> Zeig uns doch mal deine Firewall-Konfiguration.

Ich meine ich hätte immer die default-konfig verwendet die ja eh das
wichtige abdeckt. Aber, sieh selbst.

Hier der Ausschnitt aus rc.cfg vom laufenden 3.10.4-x86

NET_DRV_N='2'
NET_DRV_1='via-rhine'
NET_DRV_1_OPTION=''
NET_DRV_2='3c59x'
NET_DRV_2_OPTION=''
IP_NET_N='2'
IP_NET_1='192.168.1.1/24'
IP_NET_1_DEV='eth0'
IP_NET_2='192.168.254.2/24'
IP_NET_2_DEV='eth1'
IP_ROUTE_N='0'
PF_INPUT_POLICY='REJECT'
PF_INPUT_ACCEPT_DEF='yes'
PF_INPUT_LOG='no'
PF_INPUT_LOG_LIMIT='3/minute:5'
PF_INPUT_REJ_LIMIT='1/second:5'
PF_INPUT_UDP_REJ_LIMIT='1/second:5'
PF_INPUT_N='1'
PF_INPUT_1='IP_NET_1 ACCEPT'
PF_FORWARD_POLICY='REJECT'
PF_FORWARD_ACCEPT_DEF='yes'
PF_FORWARD_LOG='no'
PF_FORWARD_LOG_LIMIT='3/minute:5'
PF_FORWARD_REJ_LIMIT='1/second:5'
PF_FORWARD_UDP_REJ_LIMIT='1/second:5'
PF_FORWARD_N='2'
PF_FORWARD_1='tmpl:samba DROP'
PF_FORWARD_2='IP_NET_1 ACCEPT'
PF_OUTPUT_POLICY='ACCEPT'
PF_OUTPUT_ACCEPT_DEF='yes'
PF_OUTPUT_LOG='no'
PF_OUTPUT_LOG_LIMIT='3/minute:5'
PF_OUTPUT_REJ_LIMIT='1/second:5'
PF_OUTPUT_UDP_REJ_LIMIT='1/second:5'
PF_OUTPUT_N='0'
PF_POSTROUTING_N='1'
PF_POSTROUTING_1='IP_NET_1 MASQUERADE'
PF_PREROUTING_N='0'
PF_PREROUTING_CT_ACCEPT_DEF='yes'
PF_PREROUTING_CT_N='1'
PF_PREROUTING_CT_1='tmpl:ftp IP_NET_1 HELPER:ftp'
PF_OUTPUT_CT_ACCEPT_DEF='yes'
PF_OUTPUT_CT_N='0'
PF_USR_CHAIN_N='0'

> 
> Abgesehen davon sind diese Regeln für die Kommunikation zwischen fli4l und 
> dem DSL-Modem natürlich irrelevant. Wenn die Kommunikation also nicht 

Ja, sicher. S.o.

> funktioniert, liegt in dsltool und nicht in der Firewall ein Fehler vor. Du 
> solltest DSLTOOL_DEBUG='yes' setzen, in der WebGUI vom fli4l dann unter 
> "DSL-Tool" über den "Debug"-Reiter ein Archiv herunterladen und dieses dann 
> zu Carsten schicken (E-Mail steht in der dsltool-Dokumentation auf der 
> Titelseite).

Ja, das mache ich anschließend.

>>> ping plugin: No host could be added to ping object. Giving up.
> 
> Das kann passieren, wenn der Rechner zu diesem Zeitpunkt nicht online ist. 
> Dafür gibt es momentan keine Lösung (siehe FFL-740).

ein kurzes 'delay' an passender stelle würde vermutlich schon reichen,
denke ich. Oder ist's doch komplizwickter...


>> und als letztes von chronyd der keine dump files öffnen kann.
> 
>> Vielleicht war die DSL-Verbindung da noch nicht aufgebaut...
> 
> So ist es.

Noch'n 'delay'? :)


Kay

-- 
https://www.linuxcounter.net/cert/224140.png