[fli4l] Neues stable Release fli4l 3.10.4

[Christoph Schulz]

Hallo!

Kay Martinen schrieb:

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

Die Fehlermeldungen kommen vom System (d.h. der uClibc) und sind nicht 
beeinflussbar.

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

Das ist klar, die Verbindung zwischen fli4l und Modem ist auch nicht das 
Problem.

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

Ja...

> das Modem kann antworten an den PC senden

...nein. Wie auch? Das Modem erhält eine Anfrage von 192.168.1.123 (z.B.) an 
seine Adresse 192.168.254.1 und weiß nicht, wohin es die Antwort verschicken 
soll, denn 192.168.1.0/24 steht nicht in seiner Routing-Tabelle. Was aber 
geht, ist die Anfrage *im fli4l* so umzuformen, dass sie beim Modem so 
ankommt, als käme sie von 192.168.254.2 (der fli4l-Adresse). Da dies im 
selben Netzsegment liegt wie 192.168.254.1, kann das Modem die Antwort 
zurücksenden, der fli4l ändert flugs die Zieladresse und schickt sie weiter 
nach 192.168.1.123. Das erfordert auf fli4l-Seite aber ein SNAT bzw. 
MASQUERADE.

Und siehe da...

>> 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.
> [...]
> PF_POSTROUTING_N='1'
> PF_POSTROUTING_1='IP_NET_1 MASQUERADE'

Da ist sie ja, die MASQUERADE-Regel. Damit geht's natürlich.

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

Na sicher. Wer sagt dir, wie lange die Zeitspanne sein soll? Was ist, wenn 
dein Provider gerade "down" ist? Soll der fli4l solange seinen Boot-Vorgang 
unterbrechen? Was ist, wenn ein Warten gar nicht nötig wäre, der fli4l aber 
trotzdem (unnötig) wartet? Soll sich alles deshalb verzögern, nur einer 
Eventualität wegen?

> Noch'n 'delay'? :)

Sicher nicht. Man kann nicht alle Probleme mit irgendwelchen Wartereien 
lösen. Das verlängert nur unnötig die Boot-Zeit oder sonstige Vorgänge. Man 
muss das alles ordentlich (d.h. ereignisgetrieben) machen, und genau das ist 
der Weg, der mit 4.0 beschritten werden wird.


Viele Grüße,
-- 
Christoph Schulz
[fli4l-Team]