| Message ID | 20190908150439.29183-1-tim@tn-x.org |
|---|---|
| State | Deferred |
| Headers | show |
diff --git a/src/packages/fff/fff-network/files/usr/sbin/configurenetwork b/src/packages/fff/fff-network/files/usr/sbin/configurenetwork index 448bd04..0b47b4f 100755 --- a/src/packages/fff/fff-network/files/usr/sbin/configurenetwork +++ b/src/packages/fff/fff-network/files/usr/sbin/configurenetwork @@ -33,10 +33,15 @@ setAutoConf() { # Usage: setAutoConf <interface> <[0|1]> local iface=$1 local on=$2 + local ra=$2 + + if [ "$ra" -eq "1" ]; then + ra=2; + fi sysctlfile="/etc/sysctl.d/51-fff-network-$iface.conf" echo "# Generated from configurenetwork" > "$sysctlfile" - echo "net.ipv6.conf.$iface.accept_ra = $on" >> "$sysctlfile" + echo "net.ipv6.conf.$iface.accept_ra = $ra" >> "$sysctlfile" echo "net.ipv6.conf.$iface.accept_ra_defrtr = $on" >> "$sysctlfile" echo "net.ipv6.conf.$iface.accept_ra_pinfo = $on" >> "$sysctlfile" echo "net.ipv6.conf.$iface.autoconf = $on" >> "$sysctlfile"
Hey Tim, Theoretisch ein guter Fund. Praktisch ist es egal, weil "forwarding" von der gleichen Funktion für das Interface auf 0 gesetzt wird. Sonst wäre IPv6 auch in der Node Firmware kaputt, dort ist Forwarding ebenfalls aktiv. Ich bin hier noch etwas unschlüssig, wie genau wir accept_ra jetzt setzen sollten.. Gruß Fabian On 08.09.19 17:04, Tim Niemeyer wrote: > Else we can't enable accept_ra while forwarding is enabled. > > Signed-off-by: Tim Niemeyer <tim@tn-x.org> > --- > > .../fff/fff-network/files/usr/sbin/configurenetwork | 7 ++++++- > 1 file changed, 6 insertions(+), 1 deletion(-) > > diff --git a/src/packages/fff/fff-network/files/usr/sbin/configurenetwork b/src/packages/fff/fff-network/files/usr/sbin/configurenetwork > index 448bd04..0b47b4f 100755 > --- a/src/packages/fff/fff-network/files/usr/sbin/configurenetwork > +++ b/src/packages/fff/fff-network/files/usr/sbin/configurenetwork > @@ -33,10 +33,15 @@ setAutoConf() { > # Usage: setAutoConf <interface> <[0|1]> > local iface=$1 > local on=$2 > + local ra=$2 > + > + if [ "$ra" -eq "1" ]; then > + ra=2; > + fi > > sysctlfile="/etc/sysctl.d/51-fff-network-$iface.conf" > echo "# Generated from configurenetwork" > "$sysctlfile" > - echo "net.ipv6.conf.$iface.accept_ra = $on" >> "$sysctlfile" > + echo "net.ipv6.conf.$iface.accept_ra = $ra" >> "$sysctlfile" > echo "net.ipv6.conf.$iface.accept_ra_defrtr = $on" >> "$sysctlfile" > echo "net.ipv6.conf.$iface.accept_ra_pinfo = $on" >> "$sysctlfile" > echo "net.ipv6.conf.$iface.autoconf = $on" >> "$sysctlfile" >
Is mir eigentlich Wurst. Der Punkt ist, dass auf der GW Firmware kein v6 am WAN ging. :P Tim Am 8. September 2019 20:46:53 MESZ schrieb "Fabian Bläse" <fabian@blaese.de>: >Hey Tim, > >Theoretisch ein guter Fund. Praktisch ist es egal, weil "forwarding" >von der gleichen Funktion für das Interface auf 0 gesetzt wird. Sonst >wäre IPv6 auch in der Node Firmware kaputt, dort ist Forwarding >ebenfalls aktiv. >Ich bin hier noch etwas unschlüssig, wie genau wir accept_ra jetzt >setzen sollten.. > >Gruß >Fabian > >On 08.09.19 17:04, Tim Niemeyer wrote: >> Else we can't enable accept_ra while forwarding is enabled. >> >> Signed-off-by: Tim Niemeyer <tim@tn-x.org> >> --- >> >> .../fff/fff-network/files/usr/sbin/configurenetwork | 7 >++++++- >> 1 file changed, 6 insertions(+), 1 deletion(-) >> >> diff --git >a/src/packages/fff/fff-network/files/usr/sbin/configurenetwork >b/src/packages/fff/fff-network/files/usr/sbin/configurenetwork >> index 448bd04..0b47b4f 100755 >> --- a/src/packages/fff/fff-network/files/usr/sbin/configurenetwork >> +++ b/src/packages/fff/fff-network/files/usr/sbin/configurenetwork >> @@ -33,10 +33,15 @@ setAutoConf() { >> # Usage: setAutoConf <interface> <[0|1]> >> local iface=$1 >> local on=$2 >> + local ra=$2 >> + >> + if [ "$ra" -eq "1" ]; then >> + ra=2; >> + fi >> >> sysctlfile="/etc/sysctl.d/51-fff-network-$iface.conf" >> echo "# Generated from configurenetwork" > "$sysctlfile" >> - echo "net.ipv6.conf.$iface.accept_ra = $on" >> "$sysctlfile" >> + echo "net.ipv6.conf.$iface.accept_ra = $ra" >> "$sysctlfile" >> echo "net.ipv6.conf.$iface.accept_ra_defrtr = $on" >> >"$sysctlfile" >> echo "net.ipv6.conf.$iface.accept_ra_pinfo = $on" >> >"$sysctlfile" >> echo "net.ipv6.conf.$iface.autoconf = $on" >> "$sysctlfile" >>
Doch, geht. Ich verwende das ja schon. Du bist vermutlich in ein Problem gelaufen, für das ich bisher keine gute Lösung habe: Linux sendet nur wenige Router Solicitations und verringert die Rate auch sehr schnell. (vgl.: https://tools.ietf.org/html/rfc7559) Sobald ein Link UP geht, fängt Linux mit den RS (und auch der Verringerung der Rate) an. Weil das Interface intern aber an einem Switch hängt, ist es immer UP und die RS beginnen schon, bevor WAN tatsächlich aktiv ist. Gruß Fabian On 08.09.19 21:07, Tim Niemeyer wrote: > Is mir eigentlich Wurst. Der Punkt ist, dass auf der GW Firmware kein v6 am WAN ging. :P > > Tim > > Am 8. September 2019 20:46:53 MESZ schrieb "Fabian Bläse" <fabian@blaese.de>: >> Hey Tim, >> >> Theoretisch ein guter Fund. Praktisch ist es egal, weil "forwarding" >> von der gleichen Funktion für das Interface auf 0 gesetzt wird. Sonst >> wäre IPv6 auch in der Node Firmware kaputt, dort ist Forwarding >> ebenfalls aktiv. >> Ich bin hier noch etwas unschlüssig, wie genau wir accept_ra jetzt >> setzen sollten.. >> >> Gruß >> Fabian >> >> On 08.09.19 17:04, Tim Niemeyer wrote: >>> Else we can't enable accept_ra while forwarding is enabled. >>> >>> Signed-off-by: Tim Niemeyer <tim@tn-x.org> >>> --- >>> >>> .../fff/fff-network/files/usr/sbin/configurenetwork | 7 >> ++++++- >>> 1 file changed, 6 insertions(+), 1 deletion(-) >>> >>> diff --git >> a/src/packages/fff/fff-network/files/usr/sbin/configurenetwork >> b/src/packages/fff/fff-network/files/usr/sbin/configurenetwork >>> index 448bd04..0b47b4f 100755 >>> --- a/src/packages/fff/fff-network/files/usr/sbin/configurenetwork >>> +++ b/src/packages/fff/fff-network/files/usr/sbin/configurenetwork >>> @@ -33,10 +33,15 @@ setAutoConf() { >>> # Usage: setAutoConf <interface> <[0|1]> >>> local iface=$1 >>> local on=$2 >>> + local ra=$2 >>> + >>> + if [ "$ra" -eq "1" ]; then >>> + ra=2; >>> + fi >>> >>> sysctlfile="/etc/sysctl.d/51-fff-network-$iface.conf" >>> echo "# Generated from configurenetwork" > "$sysctlfile" >>> - echo "net.ipv6.conf.$iface.accept_ra = $on" >> "$sysctlfile" >>> + echo "net.ipv6.conf.$iface.accept_ra = $ra" >> "$sysctlfile" >>> echo "net.ipv6.conf.$iface.accept_ra_defrtr = $on" >> >> "$sysctlfile" >>> echo "net.ipv6.conf.$iface.accept_ra_pinfo = $on" >> >> "$sysctlfile" >>> echo "net.ipv6.conf.$iface.autoconf = $on" >> "$sysctlfile" >>>
Würde mich wundern. Der hing schon echt ewig am Netz. Und am Ende war ja die forwarding und accept_ra Kiste falsch eingestellt auf dem iface. Tim Am 8. September 2019 21:37:09 MESZ schrieb "Fabian Bläse" <fabian@blaese.de>: >Doch, geht. Ich verwende das ja schon. > >Du bist vermutlich in ein Problem gelaufen, für das ich bisher keine >gute Lösung habe: >Linux sendet nur wenige Router Solicitations und verringert die Rate >auch sehr schnell. (vgl.: https://tools.ietf.org/html/rfc7559) > >Sobald ein Link UP geht, fängt Linux mit den RS (und auch der >Verringerung der Rate) an. >Weil das Interface intern aber an einem Switch hängt, ist es immer UP >und die RS beginnen schon, bevor WAN tatsächlich aktiv ist. > >Gruß >Fabian > >On 08.09.19 21:07, Tim Niemeyer wrote: >> Is mir eigentlich Wurst. Der Punkt ist, dass auf der GW Firmware kein >v6 am WAN ging. :P >> >> Tim >> >> Am 8. September 2019 20:46:53 MESZ schrieb "Fabian Bläse" ><fabian@blaese.de>: >>> Hey Tim, >>> >>> Theoretisch ein guter Fund. Praktisch ist es egal, weil "forwarding" >>> von der gleichen Funktion für das Interface auf 0 gesetzt wird. >Sonst >>> wäre IPv6 auch in der Node Firmware kaputt, dort ist Forwarding >>> ebenfalls aktiv. >>> Ich bin hier noch etwas unschlüssig, wie genau wir accept_ra jetzt >>> setzen sollten.. >>> >>> Gruß >>> Fabian >>> >>> On 08.09.19 17:04, Tim Niemeyer wrote: >>>> Else we can't enable accept_ra while forwarding is enabled. >>>> >>>> Signed-off-by: Tim Niemeyer <tim@tn-x.org> >>>> --- >>>> >>>> .../fff/fff-network/files/usr/sbin/configurenetwork | 7 >>> ++++++- >>>> 1 file changed, 6 insertions(+), 1 deletion(-) >>>> >>>> diff --git >>> a/src/packages/fff/fff-network/files/usr/sbin/configurenetwork >>> b/src/packages/fff/fff-network/files/usr/sbin/configurenetwork >>>> index 448bd04..0b47b4f 100755 >>>> --- a/src/packages/fff/fff-network/files/usr/sbin/configurenetwork >>>> +++ b/src/packages/fff/fff-network/files/usr/sbin/configurenetwork >>>> @@ -33,10 +33,15 @@ setAutoConf() { >>>> # Usage: setAutoConf <interface> <[0|1]> >>>> local iface=$1 >>>> local on=$2 >>>> + local ra=$2 >>>> + >>>> + if [ "$ra" -eq "1" ]; then >>>> + ra=2; >>>> + fi >>>> >>>> sysctlfile="/etc/sysctl.d/51-fff-network-$iface.conf" >>>> echo "# Generated from configurenetwork" > "$sysctlfile" >>>> - echo "net.ipv6.conf.$iface.accept_ra = $on" >> "$sysctlfile" >>>> + echo "net.ipv6.conf.$iface.accept_ra = $ra" >> "$sysctlfile" >>>> echo "net.ipv6.conf.$iface.accept_ra_defrtr = $on" >> >>> "$sysctlfile" >>>> echo "net.ipv6.conf.$iface.accept_ra_pinfo = $on" >> >>> "$sysctlfile" >>>> echo "net.ipv6.conf.$iface.autoconf = $on" >> "$sysctlfile" >>>>
"richtig" ist immer Auslegungssache.. :-) Da es nicht weh tut und defintiv erwartetes verhalten ist, dass RA auf WAN akzeptiert werden, ist es wohl dennoch nicht verkehrt: Reviewed-by: Fabian Bläse <fabian@blaese.de> Ich bin mir aber dennoch sehr sicher, dass deine Problematik daher kam, ich hab das auch schon häufiger beobachtet, auch mit accept_ra=2. "forwarding" ist aber aktuell schon richtig eingestellt, oder wo denkst du ist es falsch? Gruß Fabian On 08.09.19 21:39, Tim Niemeyer wrote: > Würde mich wundern. Der hing schon echt ewig am Netz. Und am Ende war ja die forwarding und accept_ra Kiste falsch eingestellt auf dem iface. > > Tim > > Am 8. September 2019 21:37:09 MESZ schrieb "Fabian Bläse" <fabian@blaese.de>: >> Doch, geht. Ich verwende das ja schon. >> >> Du bist vermutlich in ein Problem gelaufen, für das ich bisher keine >> gute Lösung habe: >> Linux sendet nur wenige Router Solicitations und verringert die Rate >> auch sehr schnell. (vgl.: https://tools.ietf.org/html/rfc7559) >> >> Sobald ein Link UP geht, fängt Linux mit den RS (und auch der >> Verringerung der Rate) an. >> Weil das Interface intern aber an einem Switch hängt, ist es immer UP >> und die RS beginnen schon, bevor WAN tatsächlich aktiv ist. >> >> Gruß >> Fabian >> >> On 08.09.19 21:07, Tim Niemeyer wrote: >>> Is mir eigentlich Wurst. Der Punkt ist, dass auf der GW Firmware kein >> v6 am WAN ging. :P >>> >>> Tim >>> >>> Am 8. September 2019 20:46:53 MESZ schrieb "Fabian Bläse" >> <fabian@blaese.de>: >>>> Hey Tim, >>>> >>>> Theoretisch ein guter Fund. Praktisch ist es egal, weil "forwarding" >>>> von der gleichen Funktion für das Interface auf 0 gesetzt wird. >> Sonst >>>> wäre IPv6 auch in der Node Firmware kaputt, dort ist Forwarding >>>> ebenfalls aktiv. >>>> Ich bin hier noch etwas unschlüssig, wie genau wir accept_ra jetzt >>>> setzen sollten.. >>>> >>>> Gruß >>>> Fabian >>>> >>>> On 08.09.19 17:04, Tim Niemeyer wrote: >>>>> Else we can't enable accept_ra while forwarding is enabled. >>>>> >>>>> Signed-off-by: Tim Niemeyer <tim@tn-x.org> >>>>> --- >>>>> >>>>> .../fff/fff-network/files/usr/sbin/configurenetwork | 7 >>>> ++++++- >>>>> 1 file changed, 6 insertions(+), 1 deletion(-) >>>>> >>>>> diff --git >>>> a/src/packages/fff/fff-network/files/usr/sbin/configurenetwork >>>> b/src/packages/fff/fff-network/files/usr/sbin/configurenetwork >>>>> index 448bd04..0b47b4f 100755 >>>>> --- a/src/packages/fff/fff-network/files/usr/sbin/configurenetwork >>>>> +++ b/src/packages/fff/fff-network/files/usr/sbin/configurenetwork >>>>> @@ -33,10 +33,15 @@ setAutoConf() { >>>>> # Usage: setAutoConf <interface> <[0|1]> >>>>> local iface=$1 >>>>> local on=$2 >>>>> + local ra=$2 >>>>> + >>>>> + if [ "$ra" -eq "1" ]; then >>>>> + ra=2; >>>>> + fi >>>>> >>>>> sysctlfile="/etc/sysctl.d/51-fff-network-$iface.conf" >>>>> echo "# Generated from configurenetwork" > "$sysctlfile" >>>>> - echo "net.ipv6.conf.$iface.accept_ra = $on" >> "$sysctlfile" >>>>> + echo "net.ipv6.conf.$iface.accept_ra = $ra" >> "$sysctlfile" >>>>> echo "net.ipv6.conf.$iface.accept_ra_defrtr = $on" >> >>>> "$sysctlfile" >>>>> echo "net.ipv6.conf.$iface.accept_ra_pinfo = $on" >> >>>> "$sysctlfile" >>>>> echo "net.ipv6.conf.$iface.autoconf = $on" >> "$sysctlfile" >>>>>
Es war forwarding auf 1 und accept_ra auf 1 jeweils auf dem San interface. Da kann man dann lange warten..;) Am 8. September 2019 21:44:15 MESZ schrieb "Fabian Bläse" <fabian@blaese.de>: >"richtig" ist immer Auslegungssache.. :-) > >Da es nicht weh tut und defintiv erwartetes verhalten ist, dass RA auf >WAN akzeptiert werden, ist es wohl dennoch nicht verkehrt: >Reviewed-by: Fabian Bläse <fabian@blaese.de> > >Ich bin mir aber dennoch sehr sicher, dass deine Problematik daher kam, >ich hab das auch schon häufiger beobachtet, auch mit accept_ra=2. >"forwarding" ist aber aktuell schon richtig eingestellt, oder wo denkst >du ist es falsch? > >Gruß >Fabian > >On 08.09.19 21:39, Tim Niemeyer wrote: >> Würde mich wundern. Der hing schon echt ewig am Netz. Und am Ende war >ja die forwarding und accept_ra Kiste falsch eingestellt auf dem iface. >> >> Tim >> >> Am 8. September 2019 21:37:09 MESZ schrieb "Fabian Bläse" ><fabian@blaese.de>: >>> Doch, geht. Ich verwende das ja schon. >>> >>> Du bist vermutlich in ein Problem gelaufen, für das ich bisher keine >>> gute Lösung habe: >>> Linux sendet nur wenige Router Solicitations und verringert die Rate >>> auch sehr schnell. (vgl.: https://tools.ietf.org/html/rfc7559) >>> >>> Sobald ein Link UP geht, fängt Linux mit den RS (und auch der >>> Verringerung der Rate) an. >>> Weil das Interface intern aber an einem Switch hängt, ist es immer >UP >>> und die RS beginnen schon, bevor WAN tatsächlich aktiv ist. >>> >>> Gruß >>> Fabian >>> >>> On 08.09.19 21:07, Tim Niemeyer wrote: >>>> Is mir eigentlich Wurst. Der Punkt ist, dass auf der GW Firmware >kein >>> v6 am WAN ging. :P >>>> >>>> Tim >>>> >>>> Am 8. September 2019 20:46:53 MESZ schrieb "Fabian Bläse" >>> <fabian@blaese.de>: >>>>> Hey Tim, >>>>> >>>>> Theoretisch ein guter Fund. Praktisch ist es egal, weil >"forwarding" >>>>> von der gleichen Funktion für das Interface auf 0 gesetzt wird. >>> Sonst >>>>> wäre IPv6 auch in der Node Firmware kaputt, dort ist Forwarding >>>>> ebenfalls aktiv. >>>>> Ich bin hier noch etwas unschlüssig, wie genau wir accept_ra jetzt >>>>> setzen sollten.. >>>>> >>>>> Gruß >>>>> Fabian >>>>> >>>>> On 08.09.19 17:04, Tim Niemeyer wrote: >>>>>> Else we can't enable accept_ra while forwarding is enabled. >>>>>> >>>>>> Signed-off-by: Tim Niemeyer <tim@tn-x.org> >>>>>> --- >>>>>> >>>>>> .../fff/fff-network/files/usr/sbin/configurenetwork | 7 >>>>> ++++++- >>>>>> 1 file changed, 6 insertions(+), 1 deletion(-) >>>>>> >>>>>> diff --git >>>>> a/src/packages/fff/fff-network/files/usr/sbin/configurenetwork >>>>> b/src/packages/fff/fff-network/files/usr/sbin/configurenetwork >>>>>> index 448bd04..0b47b4f 100755 >>>>>> --- >a/src/packages/fff/fff-network/files/usr/sbin/configurenetwork >>>>>> +++ >b/src/packages/fff/fff-network/files/usr/sbin/configurenetwork >>>>>> @@ -33,10 +33,15 @@ setAutoConf() { >>>>>> # Usage: setAutoConf <interface> <[0|1]> >>>>>> local iface=$1 >>>>>> local on=$2 >>>>>> + local ra=$2 >>>>>> + >>>>>> + if [ "$ra" -eq "1" ]; then >>>>>> + ra=2; >>>>>> + fi >>>>>> >>>>>> sysctlfile="/etc/sysctl.d/51-fff-network-$iface.conf" >>>>>> echo "# Generated from configurenetwork" > "$sysctlfile" >>>>>> - echo "net.ipv6.conf.$iface.accept_ra = $on" >> "$sysctlfile" >>>>>> + echo "net.ipv6.conf.$iface.accept_ra = $ra" >> "$sysctlfile" >>>>>> echo "net.ipv6.conf.$iface.accept_ra_defrtr = $on" >> >>>>> "$sysctlfile" >>>>>> echo "net.ipv6.conf.$iface.accept_ra_pinfo = $on" >> >>>>> "$sysctlfile" >>>>>> echo "net.ipv6.conf.$iface.autoconf = $on" >> "$sysctlfile" >>>>>>
On 08.09.19 21:45, Tim Niemeyer wrote:
> Es war forwarding auf 1 und accept_ra auf 1 jeweils auf dem San interface. Da kann man dann lange warten..;)
Huch? Das dürfte nicht sein. Warst du tatsächlich mit dem aktuellen master unterwegs und hast den Boot komplett abgewartet?
forwarding wird nämlich eigentlich gesetzt, siehe 5 Zeilen unter der Zeile, die du editiert hast..
Gruß
Fabian
Nein natürlich war ich nicht auf dem master. Es war dein branch. In wie weit die auseinandergelaufen sind weiss ich nicht. Am 8. September 2019 22:31:22 MESZ schrieb "Fabian Bläse" <fabian@blaese.de>: >On 08.09.19 21:45, Tim Niemeyer wrote: >> Es war forwarding auf 1 und accept_ra auf 1 jeweils auf dem San >interface. Da kann man dann lange warten..;) >Huch? Das dürfte nicht sein. Warst du tatsächlich mit dem aktuellen >master unterwegs und hast den Boot komplett abgewartet? >forwarding wird nämlich eigentlich gesetzt, siehe 5 Zeilen unter der >Zeile, die du editiert hast.. > >Gruß >Fabian
Hi Tim, das Problem liegt nicht hier. Die Funktion schreibt accept_ra=1 und forwarding=0 nach 51-fff-gateway.conf Das passt schon. Es gibt aber jetzt eine neue sysctl.d/60-fff-gateway.conf . Und da überschreibt ein net.ipv6.conf.all.forwarding=1 die 0 wieder. Man möchte die 0 aber gerne am wandev haben. Mann sollte diese Zeile raus nehmen. Das net.ipv6.conf.default.forwarding=1 reicht für die devices die später dazu kommen. (wireguard etc.) Noch eine andere Frage in die Runde, weil ich es gerade gesehen habe. Die Funktion kann nur ein device konfigurieren weil die 51-fff-gateway.conf jedes mal neu geschrieben wird. War das Absicht? Grüße Robert Am 08.09.19 um 17:04 schrieb Tim Niemeyer: > Else we can't enable accept_ra while forwarding is enabled. > > Signed-off-by: Tim Niemeyer <tim@tn-x.org> > --- > > .../fff/fff-network/files/usr/sbin/configurenetwork | 7 ++++++- > 1 file changed, 6 insertions(+), 1 deletion(-) > > diff --git a/src/packages/fff/fff-network/files/usr/sbin/configurenetwork b/src/packages/fff/fff-network/files/usr/sbin/configurenetwork > index 448bd04..0b47b4f 100755 > --- a/src/packages/fff/fff-network/files/usr/sbin/configurenetwork > +++ b/src/packages/fff/fff-network/files/usr/sbin/configurenetwork > @@ -33,10 +33,15 @@ setAutoConf() { > # Usage: setAutoConf <interface> <[0|1]> > local iface=$1 > local on=$2 > + local ra=$2 > + > + if [ "$ra" -eq "1" ]; then > + ra=2; > + fi > > sysctlfile="/etc/sysctl.d/51-fff-network-$iface.conf" > echo "# Generated from configurenetwork" > "$sysctlfile" > - echo "net.ipv6.conf.$iface.accept_ra = $on" >> "$sysctlfile" > + echo "net.ipv6.conf.$iface.accept_ra = $ra" >> "$sysctlfile" > echo "net.ipv6.conf.$iface.accept_ra_defrtr = $on" >> "$sysctlfile" > echo "net.ipv6.conf.$iface.accept_ra_pinfo = $on" >> "$sysctlfile" > echo "net.ipv6.conf.$iface.autoconf = $on" >> "$sysctlfile"
Hi nochmal, also da hab ich ja einen Stuss geschrieben gestern. War schon spät. Ich versuche es noch einmal. So wie ich das sehe, ist die Reihenfolge in /etc/sysctl.d das Problem. In 60-fff-gateway.conf ist ein net.ipv6.conf.all.forwarding=1 drin. Das überschreibt das vorher in 51-fff-network-$iface.conf gesetzte net.ipv6.conf.all.forwarding=0 . Man könnte einfach die Reihenfolge verändern und gut is. Patch kommt. Robert Am 11.09.19 um 01:10 schrieb robert:
Hallo Robert, das ist auf jeden Fall auch ein guter Fund. Interessant an dieser Stelle ist aber: Wenn das WAN-Interface (neu) startet, ist forwarding auch jetzt schon auf "0" (und überschreibt damit scheinbar unsere sysctl Einstellungen, da es wie Robert ja festgestellt hat, eigentlich aktuell 1 sein müsste).. Ich bin mir hier auch gar nicht wirklich sicher, wann und wie oft /etc/sysctl.d/* angewendet wird. Im OpenWRT hab ich dazu folgendes gefunden: https://github.com/openwrt/openwrt/commit/875ff445925ff10df5bf7c491c007de661248003 Das finde ich in der Version, die wir grade als Basis verwenden, gar nicht mehr. Aktuell bin ich mir etwas unsicher, wie wir das ordentlich lösen können, zumal ich den Ist-Zustand noch gar nicht so genau kenne. Sollten wir aber auf jeden Fall weiter verfolgen. Gruß Fabian On 11.09.19 21:01, robert wrote: > Hi nochmal, > > also da hab ich ja einen Stuss geschrieben gestern. War schon spät. Ich > versuche es noch einmal. > > So wie ich das sehe, ist die Reihenfolge in /etc/sysctl.d das Problem. > In 60-fff-gateway.conf ist ein net.ipv6.conf.all.forwarding=1 drin. Das > überschreibt das vorher in 51-fff-network-$iface.conf gesetzte > net.ipv6.conf.all.forwarding=0 . > > Man könnte einfach die Reihenfolge verändern und gut is. Patch kommt. > > Robert > > Am 11.09.19 um 01:10 schrieb robert: >
Hallo Robert, > Noch eine andere Frage in die Runde, weil ich es gerade gesehen habe. > Die Funktion kann nur ein device konfigurieren weil die > 51-fff-gateway.conf jedes mal neu geschrieben wird. War das Absicht? Das ist mir vor einiger Zeit auch aufgefallen. Schreibt man das Interface mit in den Namen, kriegt man aber Probleme, wenn sich der ändert. Wenn du also irgendwann mal eine dingsbums-eth0.2.conf anlegst, ist das blöd, wenn du das VLAN veränderst etc., weil du theoretisch vorher löschen musst. Das wiederum beißt sich dann mit dem Prinzip von configure/apply/revert bei configuregateway fürchterlich. Ich habe lange versucht, das ordentlich zu bauen, und bin dann aber bei einer sehr ähnlichen Lösung wie der jetzigen geblieben: https://github.com/adrianschmutzler/fff-firmware/blob/devtree/src/packages/fff/fff-network/files/lib/functions/fff/networksetup Grüße Adrian
Else we can't enable accept_ra while forwarding is enabled. Signed-off-by: Tim Niemeyer <tim@tn-x.org> --- .../fff/fff-network/files/usr/sbin/configurenetwork | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-)