VLAN Frage

[Freifunk Kontakt @ Konrad GmbH]

Hi,

ja ich schon wieder. Ich veresuhce das Gnaz auf einene andreen Router
anzuwenden und scheitere kläglich. Da ist offensichtlich bereits ein
VLAN drauf:

...
config interface 'wan'
	option ifname 'eth0.2'
	option proto dhcp

config device 'wan_dev'
	option name 'eth0.2'
	option macaddr 'GeräteMAC +1'
...
config switch_vlan 'vlan2'
	option device switch0
	option vlan '2'
	option ports '0t 1'
...

Warum eigentlich VLAN2 - vmtl. sind alle ports physikalisch auf einem
Switch und dadurch trenne ich die WAN von den übrigen, aber warum würde
dann auch ohne VLAN eine Kommunikation statt finden, evtl. weil bei der
option ports kein t an der 1 dran ist?

Bin verwirrt!
Bekomme ich das jetzt hin indem überall aus dere 2 ein 11 wird und ein t
an die 1 bei option ports?

Auch das wäre nicht updatesicher ....

Mit Knoten im Kopf grüßt,
Stefan

Am 21.10.2019 um 11:40 schrieb Adrian Schmutzler:
> Nebenbei sei noch bemerkt, dass configurenetwork WAN ifname überschreibt.
> 
>  
> 
> Dies erfolgt zwar nicht mehr bei jedem Boot, aber triggert man z.B. eine
> Änderung der Config über /etc/network.config, dann fliegt auch das
> ifname wieder weg (z.B. auch indirekt bei Änderungen im WebUI).
> 
>  
> 
> configurenetwork wird in der normalen rc.local (S=95) ausgelöst, also
> vor /etc/rc.local.fff_userconfig (S=96). Diese Variante würde also
> tatsächlich funktionieren.
> 
>  
> 
> In meiner Firmware hingegen könnte man /etc/firstbootfff nutzen, was
> aber keinen Vorteil gegenüber der beschriebenen Lösung bieten würde.
> 
>  
> 
> Sofern sich nichts zwischendurch ändert, sollte auch der uci set/uci
> commit bei jedem Boot kein Nachteil sein, da nur geschrieben wird, wenn
> sich der Hash der Datei ändert.
> 
>  
> 
> Grüße
> 
>  
> 
> Adrian
> 
>  
> 
> *From:*franken [mailto:franken-bounces at freifunk.net] *On Behalf Of
> *Fabian Bläse
> *Sent:* Montag, 21. Oktober 2019 10:51
> *To:* fff.konrad at gmx.net
> *Cc:* franken at freifunk.net
> *Subject:* Re: VLAN Frage
> 
>  
> 
> Hey Stefan,
> 
> keiner der beiden Orte ist updatesicher.
> Die einzige Möglichkeit Dinge abseits von /etc/config/fff halbwegs
> update-sicher zu machen, ist die /etc/rc.local.fff_userconfig - Dieses
> Script wird bei jedem Boot ausgeführt und ist updatefest.
> 
> Dort könnte z.B. "uci set network.wan.ifname=xy" etc. eingetragen
> werden. Das garantiert aber keine Updatesicherheit, da sich die
> Firmwarekonfiguration ändern kann.
> 
> Gruß
> Fabian
> 
> P.S.: Bitte "Reply All" / "Allen antworten" verwenden, damit die Liste
> deine Antworten auch bekommt. :-)
> 
> On 21.10.19 10:45, Freifunk Kontakt @ Konrad GmbH wrote:
>> Hallo,
>> 
>> danke für die weiteren Infos.
>> PD habe ich in diesem Zusammenhang erwähnt, weil ich das am
>> vorgeschalteten Router aktivieren kann. SLAAC wird ja vom Client selbst
>> gemacht - soweit ich das verstanden habe.
>> 
>> 
>> 51-fff-network- schau ich mir mal an - welcher der beiden "Orte" wäre
>> denn Update-sicher?
>> 
>> Gruß,
>> Stefan
>> 
>> Am 20.10.2019 um 20:47 schrieb Fabian Bläse:
>>> Hey Stefan,
>>>
>>> die passenden Kernel-Einstellungen setzen wir dafür manuell in /etc/sysctl.d/51-fff-network-*, die von configurenetwork erzeugt wird.
> 
>>> Dort könntest du das ganze auch anpassen.
>>>
>>> On 20.10.19 16:57, Freifunk Kontakt @ Konrad GmbH wrote:
>>>> Nachtrag,
>>>>
>>>> eine IPv6 wurde dann nicht mehr per PD zugewiesen.
>>> Randnotiz: Der Mechanismus heißt "SLAAC" (Stateless Address Autoconfiguration).
>>> PD (Prefix Delegation) ist eine Möglichkeit per DHCPv6 ein ganzes Prefix zu beziehen. ;-)
>>>
>>> Gruß
>>> Fabian
>>>
>> 
> 
>  
> 

-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 819 bytes
Beschreibung: OpenPGP digital signature
URL         : <https://lists.freifunk.net/pipermail/franken-freifunk.net/attachments/20191023/62e25d7f/attachment.sig>