[PATCH] fff-network: restart the firewall

[Adrian Schmutzler]

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
> 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
> >>> Subject: Re: [PATCH] fff-network: restart the firewall
> >>>
> >>> Hi Adrian, s. inline
> >>>
> >>>
> >>> Am 15.08.2018 um 10:38 schrieb 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
> >>>>> 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>
> >>>>> ---
> >>>>>  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 Binärdaten wurde abgetrennt...
Dateiname   : nicht verfügbar
Dateityp    : application/pgp-signature
Dateigröße  : 834 bytes
Beschreibung: nicht verfügbar
URL         : <http://lists.freifunk.net/pipermail/franken-dev-freifunk.net/attachments/20190121/f6f18494/attachment.sig>