fff-network: restart the firewall

Submitted by Robert Langhammer on Aug. 14, 2018, 11:17 p.m.

Details

Message ID 20180814231724.15649-1-rlanghammer@web.de
State Superseded
Headers show

Commit Message

Robert Langhammer Aug. 14, 2018, 11:17 p.m.
Restart the firewall after networkcofiguration to use the correct interfaces.

Fixes: #103

Signed-off-by: Robert Langhammer <rlanghammer@web.de>
---
 src/packages/fff/fff-network/files/usr/sbin/configurenetwork | 3 +++
 1 file changed, 3 insertions(+)

Patch hide | download patch | download mbox

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
+
 /etc/init.d/network restart
 
 if [ -n "$ETHMESHMAC" ]; then

Comments

Adrian Schmutzler Aug. 15, 2018, 8:38 a.m.
Hallo Robert,

gute Idee, zwei Fragen dazu.

> -----Original Message-----
> From: franken-dev [mailto:franken-dev-bounces@freifunk.net] On Behalf
> Of Robert Langhammer
> Sent: Mittwoch, 15. August 2018 01:17
> To: franken-dev@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@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"?

> +
>  /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?

Grüße

Adrian

> 
>  if [ -n "$ETHMESHMAC" ]; then
> --
> 2.11.0
Robert Langhammer Aug. 15, 2018, 10:16 a.m.
Hi Adrian, s. inline


Am 15.08.2018 um 10:38 schrieb mail@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@freifunk.net] On Behalf
>> Of Robert Langhammer
>> Sent: Mittwoch, 15. August 2018 01:17
>> To: franken-dev@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@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.

Robert
>
> Grüße
>
> Adrian
>
>>  if [ -n "$ETHMESHMAC" ]; then
>> --
>> 2.11.0
>
Adrian Schmutzler Aug. 15, 2018, 11:25 a.m.
Hallo nochmal,

Folgefrage siehe inline.

> -----Original Message-----
> From: franken-dev [mailto:franken-dev-bounces@freifunk.net] On Behalf Of
> robert
> Sent: Mittwoch, 15. August 2018 12:17
> To: franken-dev@freifunk.net
> Subject: Re: [PATCH] fff-network: restart the firewall
> 
> Hi Adrian, s. inline
> 
> 
> Am 15.08.2018 um 10:38 schrieb mail@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@freifunk.net] On Behalf
> >> Of Robert Langhammer
> >> Sent: Mittwoch, 15. August 2018 01:17
> >> To: franken-dev@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@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?

Heißt "bevor die Interfaces" da sind, dass sie zwar angelegt sein müssen, aber nur das "up" noch nicht erfolgt ist?

Grüße

Adrian



> 
> Robert
> >
> > Grüße
> >
> > Adrian
> >
> >>  if [ -n "$ETHMESHMAC" ]; then
> >> --
> >> 2.11.0
> >
>
Robert Langhammer Aug. 15, 2018, 12:23 p.m.
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@freifunk.net] On Behalf Of
>> robert
>> Sent: Mittwoch, 15. August 2018 12:17
>> To: franken-dev@freifunk.net
>> Subject: Re: [PATCH] fff-network: restart the firewall
>>
>> Hi Adrian, s. inline
>>
>>
>> Am 15.08.2018 um 10:38 schrieb mail@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@freifunk.net] On Behalf
>>>> Of Robert Langhammer
>>>> Sent: Mittwoch, 15. August 2018 01:17
>>>> To: franken-dev@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@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
>
Robert Langhammer Jan. 20, 2019, 12:05 p.m.
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@freifunk.net] On Behalf Of
>>> robert
>>> Sent: Mittwoch, 15. August 2018 12:17
>>> To: franken-dev@freifunk.net
>>> Subject: Re: [PATCH] fff-network: restart the firewall
>>>
>>> Hi Adrian, s. inline
>>>
>>>
>>> Am 15.08.2018 um 10:38 schrieb mail@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@freifunk.net] On Behalf
>>>>> Of Robert Langhammer
>>>>> Sent: Mittwoch, 15. August 2018 01:17
>>>>> To: franken-dev@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@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
>
Adrian Schmutzler Jan. 21, 2019, 12:47 p.m.
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@freifunk.net] On Behalf Of
> robert
> Sent: Sonntag, 20. Januar 2019 13:05
> To: franken-dev@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@freifunk.net] On Behalf
> Of
> >>> robert
> >>> Sent: Mittwoch, 15. August 2018 12:17
> >>> To: franken-dev@freifunk.net
> >>> Subject: Re: [PATCH] fff-network: restart the firewall
> >>>
> >>> Hi Adrian, s. inline
> >>>
> >>>
> >>> Am 15.08.2018 um 10:38 schrieb mail@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@freifunk.net] On
> Behalf
> >>>>> Of Robert Langhammer
> >>>>> Sent: Mittwoch, 15. August 2018 01:17
> >>>>> To: franken-dev@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@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
> >
Adrian Schmutzler April 17, 2019, 3:46 p.m.
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@freifunk.net] On Behalf Of Adrian Schmutzler
Sent: Montag, 21. Januar 2019 13:47
To: 'robert' <rlanghammer@web.de>; franken-dev@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@freifunk.net] On Behalf Of 
> robert 
> Sent: Sonntag, 20. Januar 2019 13:05 
> To: franken-dev@freifunk.net <mailto:franken-dev@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@freifunk.net] On Behalf 
> Of 
> >>> robert 
> >>> Sent: Mittwoch, 15. August 2018 12:17 
> >>> To: franken-dev@freifunk.net <mailto:franken-dev@freifunk.net>  
> >>> Subject: Re: [PATCH] fff-network: restart the firewall 
> >>> 
> >>> Hi Adrian, s. inline 
> >>> 
> >>> 
> >>> Am 15.08.2018 um 10:38 schrieb mail@adrianschmutzler.de <mailto:mail@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@freifunk.net] On 
> Behalf 
> >>>>> Of Robert Langhammer 
> >>>>> Sent: Mittwoch, 15. August 2018 01:17 
> >>>>> To: franken-dev@freifunk.net <mailto:franken-dev@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@web.de <mailto:rlanghammer@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 
> >
Robert Langhammer April 17, 2019, 8:52 p.m.
Hi Adrian,

Am 17.04.19 um 17:46 schrieb 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.
ja, uci_apply_defaults ist in /etc/init.d/boot (START=10) drin. Mit
deinem Patchset braucht man den Patch nicht mehr.
> 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…?
Die einzige Variable in den Firewallskripten ist $IF_WAN:

# grep \\\$ /usr/lib/firewall.d/*

/usr/lib/firewall.d/20-filter-ssh:iptables -A INPUT -i $IF_WAN -m
conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

/usr/lib/firewall.d/20-filter-ssh:iptables -A INPUT -i $IF_WAN -j REJECT

und die kommt aus :

/etc/init.d/fff-firewall:IF_WAN=$(uci get network.wan.ifname)

Man muss also die Firewall nur neu starten, wenn man spaeter
network.wan.ifname aendert. Ich finde, ein fff-firewall start ist ok.
Man sollte da nicht mit einzelnen iptables Zeilen in irgendwelchen
Skripen anfangen.

Man koennte auch einen reload_trigger auf network legen, dann
aktualisiert sich die Firewall bei jedem commit network. Da aber alles
ausser $IF_WAN statisch ist, finde ich das uebertrieben.

Gruesse Robert

>
>  
>
> Grüße
>
>  
>
> Adrian
>
>  
>
>
Adrian Schmutzler April 23, 2019, 11:12 a.m.
Hallo Robert,

 

mir ist eingefallen, dass die Package fff-firewall spezifisch für die node-Firmware ist, also nicht in die GW-Firmware reinkommt.

 

Es wäre also unpraktisch, wenn wir dann in der fff-network explizit irgendwo fff-firewall (re)start reinschreiben.

Ich würde daher die Lösung mit reload_trigger auf fff-network anstreben, falls man sowas dann in der fff-firewall package belassen könnte?

 

Kannst du für so eine Lösung einen Patch schicken?

 

Beste Grüße

 

Adrian

 

From: franken-dev [mailto:franken-dev-bounces@freifunk.net] On Behalf Of robert
Sent: Mittwoch, 17. April 2019 22:53
To: franken-dev@freifunk.net
Subject: Re: [PATCH] fff-network: restart the firewall

 

Hi Adrian, 

Am 17.04.19 um 17:46 schrieb 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.

ja, uci_apply_defaults ist in /etc/init.d/boot (START=10) drin. Mit 
deinem Patchset braucht man den Patch nicht mehr. 
> 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…? 
Die einzige Variable in den Firewallskripten ist $IF_WAN: 

# grep \\\$ /usr/lib/firewall.d/* 

/usr/lib/firewall.d/20-filter-ssh:iptables -A INPUT -i $IF_WAN -m 
conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT 

/usr/lib/firewall.d/20-filter-ssh:iptables -A INPUT -i $IF_WAN -j REJECT 

und die kommt aus : 

/etc/init.d/fff-firewall:IF_WAN=$(uci get network.wan.ifname) 

Man muss also die Firewall nur neu starten, wenn man spaeter 
network.wan.ifname aendert. Ich finde, ein fff-firewall start ist ok. 
Man sollte da nicht mit einzelnen iptables Zeilen in irgendwelchen 
Skripen anfangen. 

Man koennte auch einen reload_trigger auf network legen, dann 
aktualisiert sich die Firewall bei jedem commit network. Da aber alles 
ausser $IF_WAN statisch ist, finde ich das uebertrieben. 

Gruesse Robert 

> 
>  
> 
> Grüße 
> 
>  
> 
> Adrian 
> 
>  
> 
>