[PATCH] fff-network: restart the firewall

[Adrian Schmutzler]

Hallo,

 

auch dieser Patch liegt schon seit einiger Zeit im Patchwork herum.

 

Ich verstehe das so: Wenn wir die ganze network-config mit meinem Patchset per uci-defaults machen, dann bräuchte man keinen firewall-(re)start wie hier vorgeschlagen.

 

Eine entsprechende Zeile müsste man dann aber bei den Skripten ergänzen, die die Portconfig zur Laufzeit updaten (z.B. setoneport, setcpev1, etc.)?

Oder man könnte die Änderungen der Firewall-Regeln einzeln in die entsprechenden Skripte mit reinschreiben…?

 

Grüße

 

Adrian

 

From: franken-dev [mailto:franken-dev-bounces at freifunk.net] On Behalf Of Adrian Schmutzler
Sent: Montag, 21. Januar 2019 13:47
To: 'robert' <rlanghammer at web.de>; franken-dev at freifunk.net
Subject: RE: [PATCH] fff-network: restart the firewall

 

Nach meinem Kenntnisstand hat sich da bisher niemand wirklich damit befasst. 

Ich selbst hatte auch leider keine Zeit, mir das genauer anzuschauen. 

Insofern (nach meiner Kenntnis): noch aktuell 

Grüße 

Adrian 

> -----Original Message----- 
> From: franken-dev [mailto:franken-dev-bounces at freifunk.net] On Behalf Of 
> robert 
> Sent: Sonntag, 20. Januar 2019 13:05 
> To: franken-dev at freifunk.net <mailto:franken-dev at freifunk.net>  
> Subject: Re: [PATCH] fff-network: restart the firewall 
> 
> Hi, 
> 
> besteht das Problem #103 eigentlich noch? Oder kann das weg? 
> 
> Robert 
> 
> Am 15.08.18 um 14:23 schrieb robert: 
> > Hi, s.unten 
> > 
> > 
> > Am 15.08.2018 um 13:25 schrieb Adrian Schmutzler: 
> >> Hallo nochmal, 
> >> 
> >> Folgefrage siehe inline. 
> >> 
> >>> -----Original Message----- 
> >>> From: franken-dev [mailto:franken-dev-bounces at freifunk.net] On Behalf 
> Of 
> >>> robert 
> >>> Sent: Mittwoch, 15. August 2018 12:17 
> >>> To: franken-dev at freifunk.net <mailto:franken-dev at freifunk.net>  
> >>> Subject: Re: [PATCH] fff-network: restart the firewall 
> >>> 
> >>> Hi Adrian, s. inline 
> >>> 
> >>> 
> >>> Am 15.08.2018 um 10:38 schrieb mail at adrianschmutzler.de <mailto:mail at adrianschmutzler.de> : 
> >>>> Hallo Robert, 
> >>>> 
> >>>> gute Idee, zwei Fragen dazu. 
> >>> Ne, schön ist das nicht. Aber in Anbetracht dessen, dass der Start eher 
> >>> einem Knoten ähnelt und man selbigen auch im Hirn bekommt wenn man 
> >>> versucht das aufzudröseln, und das ganze nur einmal beim Booten läuft; 
> >>> Augen zu und ok. 
> >>>>> -----Original Message----- 
> >>>>> From: franken-dev [mailto:franken-dev-bounces at freifunk.net] On 
> Behalf 
> >>>>> Of Robert Langhammer 
> >>>>> Sent: Mittwoch, 15. August 2018 01:17 
> >>>>> To: franken-dev at freifunk.net <mailto:franken-dev at freifunk.net>  
> >>>>> Subject: [PATCH] fff-network: restart the firewall 
> >>>>> 
> >>>>> Restart the firewall after networkcofiguration to use the correct 
> >>>> interfaces. 
> >>>>> Fixes: #103 
> >>>>> 
> >>>>> Signed-off-by: Robert Langhammer <rlanghammer at web.de <mailto:rlanghammer at web.de> > 
> >>>>> --- 
> >>>>>  src/packages/fff/fff-network/files/usr/sbin/configurenetwork | 3 +++ 
> >>>>>  1 file changed, 3 insertions(+) 
> >>>>> 
> >>>>> diff --git a/src/packages/fff/fff-network/files/usr/sbin/configurenetwork 
> >>>>> b/src/packages/fff/fff-network/files/usr/sbin/configurenetwork 
> >>>>> index 0e038a4..cdfd064 100755 
> >>>>> --- a/src/packages/fff/fff-network/files/usr/sbin/configurenetwork 
> >>>>> +++ b/src/packages/fff/fff-network/files/usr/sbin/configurenetwork 
> >>>>> @@ -173,6 +173,9 @@ if [ "$ONE_PORT" = "YES" ] && ( ! uci -q get 
> >>>>> network.$SWITCHDEV.ifname || [ "$FO 
> >>>>>      uci commit network 
> >>>>>  fi 
> >>>>> 
> >>>>> +# Restart the firewall 
> >>>>> +/etc/init.d/fff-firewall start 
> >>>> Warum "start" und nicht "restart"? 
> >>> Schau mal ins fff-firewall init-skript. Da gibt es kein Target für stop 
> >>> bzw. restart. Was auch ok ist, da es kein Dienst/daemon ist der gestoppt 
> >>> und neu gestartet werden muss. Es geht mit restart auch, fühlt sich aber 
> >>> irgendwie falsch an. 
> >>>>> + 
> >>>>>  /etc/init.d/network restart 
> >>>> Macht es Sinn, fff-firewall NACH dem network restart neu zu (re)starten, 
> >>>> damit die entsprechenden interfaces wirklich "da" sind? 
> >>> Nein. Das schöne am Kernel-Paketfilter ist eben, dass man mit iptables 
> >>> Rules definieren kann, bevor die Interfaces da sind. Dadurch greifen die 
> >>> sofort beim ifup. Darum immer erst firewall an und dann ifup. 
> >> Und warum geht es dann mit der jetzigen Lösung nicht? 
> > In unserer Firmware ist das WANDEV mit eth1 vorbelegt. s. 
> > src/packages/fff/fff-network/files/etc/config/network -> interface wan. 
> > die Firewall liest diesen uci Eintrag. configurenetwork ändert das erst 
> > später. Aber das passiert alles nur beim ersten Boot nach dem Flashen. 
> > Später steht ja das richtige WANDEV drin. 
> >> Heißt "bevor die Interfaces" da sind, dass sie zwar angelegt sein müssen, 
> aber nur das "up" noch nicht erfolgt ist? 
> > Man kann Rules für Interfaces anlegen, die noch nicht existieren. Darum 
> > kann man den netfiler recht früh mit Rules füttern. Die greifen dann 
> > sofort, wenn die Interfaces entstehen bzw up gehen. 
> > Das ist hier aber nicht das eigentliche Problem. s.oben. 
> > 
> > Robert 
> >> Grüße 
> >> 
> >> Adrian 
> >> 
> >> 
> >> 
> >>> Robert 
> >>>> Grüße 
> >>>> 
> >>>> Adrian 
> >>>> 
> >>>>>  if [ -n "$ETHMESHMAC" ]; then 
> >>>>> -- 
> >>>>> 2.11.0 
> > 
-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <https://{'listname': 'franken-dev-freifunk.net', 'hostname': 'lists.freifunk.net'}/pipermail/franken-dev-freifunk.net/attachments/20190417/e16b4367/attachment.html>
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : nicht verfügbar
Dateityp    : application/pgp-signature
Dateigröße  : 834 bytes
Beschreibung: nicht verfügbar
URL         : <https://{'listname': 'franken-dev-freifunk.net', 'hostname': 'lists.freifunk.net'}/pipermail/franken-dev-freifunk.net/attachments/20190417/e16b4367/attachment.sig>