vlan möglichkeiten der 7170 / 7140

[cuma]

Es funktioniert, du musst aber den Kernel tauschen. Probleme gibts bei mir nur in der Anwendung der Funktionlität

 

[derheimi]

@cuma:
Was keinen Sinn macht, ist, dass eth1 keine IP-Adresse zugeordnet ist: wenn Du den WLAN-AP vom restlichen Netz isolieren willst, muss er in ein separates IP-Subnetz verbannt werden, d.h. eth1 darf mit eth0 und mit dem WLAN nicht zusammengebridged werden. Wenn ich mir Deine Daten so anschaue, vermute ich mal, dass der multid alle Devices zusammenbridged.
Auch an den Routen sieht man, dass nur das "lan"-Interface aktiv im IP-Routing berücksichtigt wird.

Eventuell musst Du in der ar7.cfg mal ein paar händische Einstellungen vornehmen:

 ...
 ethmode = ethmode_router;
 ...
ethinterfaces {
                name = "lan";
...
                interfaces = "eth0", "tiwlan0", "wdsup0", "wdsdw0", "wdsdw1",
                             "wdsdw2", "wdsdw3";
...
        } {
                name = "eth1";
...
        } {
        ...

Wichtig ist hier, dass der ethmode auf Router steht und somit die Konfigurationen aus dem ethinterfaces-Bereich genommen werden (ggf. musst Du die Einträge aus dem folgenden brinterfaces-Abschnitt abgleichen). Mit Hilfe des "interface"-Zeile schaltest Du eth0 und das WLAN wieder zusammen. Anschließend fügst Du einen Abschnitt für "eth1" ein, der analog dem vorherigen aufgebaut ist. Dort IP-Adressen anpassen und die interface-Zeile weglassen.

 

[MReimer]

Es funktioniert, du musst aber den Kernel tauschen. Probleme gibts bei mir nur in der Anwendung der Funktionlität

:bahnhof: Funktioniert, Funktionalität eingeschränkt oder Kernel muss getauscht werden?

Was genau macht cpmaccfg, wenn es auf dem Original AVM-Kernel genutzt wird?

 

[derheimi]

Funktioniert eingeschränkt trifft es wohl am besten. Ohne gepatchtem Kernel gehen nur folgende Befehle: gsm, ssm, gpme, spme.
Das bedeutet, dass Du nur in die bereits definierten Portkonfigurationen umschalten kannst, also "normal", "ata" (1. Port=wan, 2-3=lan), "split" (alle 4 Ports einzeln) bzw. "split_ata" (1. Port=wan, 2-3 jeweils einzeln). Was Du erreichen willst, müsste damit eigentlich gehen. Ein vorcompiliertes Binary findest Du z.B. auf meiner Webseite: http://www.heimpold.de/dsmod/cpmaccfg

 

[cuma]

Hallo
"ethmode" steht momentan bei mir auf "ethmode_bridge". Welche Veränderung bringt denn "ethmode_router" denn mit sich, ich traue mich noch nicht so recht. Nicht dass ich nachher nichtmehr auf die Box komme!
Ich wollte eigentlich bei Netze im gleiche IP Bereich lassen, so kann der dnsmasq beiden bedienen. Dies funktioniert auch manchmal. Vielleicht ein Fehler im cpmac(cfg)? Eine IP für eth1 setzen geht, diese verschwindet aber ständig, zB wenn ich auf der ds-mod Oberfläche den dns neu starte.
Und wenn ich eth1 (unsicheres Netz) eine IP gabe und von einem Gerät an diesem Port (mit entsprechender IP) die Box anpinge wollte, hat dies nicht funktioniert.
Wie kann ich denn den set_switch_mode (ssm) dauerhaft eintragen? In der ar7.cfg habe ich dazu nichts gefunden.

Habe jetzt auch mal "split_ata" ausprobiert. Dies scheint aber fehlerhaft zu sein:

$ cpmaccfg gsmc
Devices: 3
WAN is port: 0
Device 1: name=eth0, portmask=0x26
Device 2: name=eth1, portmask=0x28
Device 3: name=wan, portmask=0x21
$ cpmaccfg ssm split_ata
Setting switch_mode to 'split_ata' (4).
$ cpmaccfg gsmc
ioctl: No such device
$ cpmaccfg ssm ata
Setting switch_mode to 'ata' (2).
ioctl: No such device

Danach bleiben eth0-3 erhalten und die Box damit anscheinend im split Modus.

 

[derheimi]

ethmode_router bedeutet -mal laienhaft ausgedrückt-, dass die Fritzbox nicht blind
alle verfügbaren Ports mit einer logischen Bridge zu einem großen LAN zusammenschaltet,
sondern dass Du eben mehrere getrennte Subnetze auf die Ports und ggf. WLAN legen kannst.
Kurz: eigentlich das was Du willst.
Die beiden Netze im gleichen IP-Bereich ist (wenn ich ganz direkt sein darf) Quatsch:
wie soll die Box denn unterscheiden, aus welchem Netz die Daten kommen? Eine Trennung
ist so nicht möglich!
Das die IP für eth1 ständig wieder verschwindet ist mir bei ethmode_bridge vollkommen
klar: der multid sieht dann irgendwann das eth1-Device und fügt es zur o.g. Bridge
hinzu und die Trennung ist wieder weg!
Zu obigen Fehlermeldung: poste doch mal bitte die Ausgaben von dieser Befehlsabfolge
(ggf. als Anhang, wenn es länger ist):

cpmaccfg ssm split_ata
ifconfig -a
cpmaccfg ssm ata
ifconfig -a

 

[cuma]

Hallo,
ich habe den Befehl mal etwas geändert:

cpmaccfg ssm split_ata
ifconfig -a |grep eth
cpmaccfg ssm ata
ifconfig -a |grep eth
dmesg|tail -n 15

Ergebnis:

$ cpmaccfg ssm split_ata
Setting switch_mode to 'split_ata' (4).

$ ifconfig -a |grep eth
eth1      Link encap:Ethernet  HWaddr 00:1A:4F:xx:xx:xx
eth2      Link encap:Ethernet  HWaddr 00:1A:4F:xx:xx:xx
eth3      Link encap:Ethernet  HWaddr 00:1A:4F:xx:xx:xx

$ cpmaccfg ssm ata
Setting switch_mode to 'ata' (2).
ioctl: No such device

$ ifconfig -a |grep eth
eth1      Link encap:Ethernet  HWaddr 00:1A:4F:xx:xx:xx
eth2      Link encap:Ethernet  HWaddr 00:1A:4F:xx:xx:xx
eth3      Link encap:Ethernet  HWaddr 00:1A:4F:xx:xx:xx

$ dmesg|tail -n 15
[speedup] -> 62.5 MHz
[speedup] -> 125 MHz
lan: port 1(eth0) entering disabled state
lan: port 1(eth0) entering disabled state
[cpmac] cpmac_main_ioctl, unknown ioctl 35142
lan: port 1(eth1) entering learning state
lan: topology change detected, propagating
lan: port 1(eth1) entering forwarding state
[cpmac] cpmac_main_ioctl, unknown ioctl 35142
lan: port 2(eth2) entering learning state
lan: topology change detected, propagating
lan: port 2(eth2) entering forwarding state
[cpmac] cpmac_main_ioctl, unknown ioctl 35142
[speedup] -> 62.5 MHz
[speedup] -> 125 MHz

Taucht dieser Fehler nur bei mir auf und habe ich etwas verpfuscht? Kann dies jemand reproduzieren?

EDIT: Das Problem war anscheinend wirklich, dass beide Netzte den gleichen IP-bereich hatten. Habe jetzt den "router" modus in ar7 gesetzt und 2 Interfaces: "lan" mit allen wie im bridge-Modus und "air" mir dem interface eth1. Danke!
Ich benutze noch diese iptables Regel zusätzlich, um das routen zwischen "lan" und "air" zu unterbinden (leider wird conntrack für state benötigt):

iptables -A FORWARD -i air -o lan -m state --state NEW -j REJECT

Habe jetzt aber noch ein Problem ^^ : Der cpmac Modus "special" wird bei mir in der debug.cfg gesetzt. Wenn ich jetzt zB beim dnsmasq auf der ds-mod Oberfläche "übernehmen" klicke, wechselt die Box wieder in den "ata" Modus (wird auch im Syslog angezeigt), was natürlich sehr unschön ist, wenn unvertraute Clients im "air" Netz hängen. Wo setze ich denn am besten den Modus für cpmac, damit dieser immer geladen wird? Muss ich hierfür evtl direkt im Source-Code etwas ändern?

 

[derheimi]

ich habe den Befehl mal etwas geändert:

Eigentlich wollte ich damit herausfinden, welche Netzwerk-Devices nach den Befehlen vorhanden sind: die können nicht nur ethX heißen, sondern z.B. auch wan oder cpmac0 oder... Du kannst aber die Liste einfach kürzen, die Details zu den einzelnen Geräten interessieren mich nicht. Der Fehler "no such device" deutet nämlich daraufhin, dass das Device, um das diese ioctls abgeschickt werden, nicht vorhanden ist...

[cpmac] cpmac_main_ioctl, unknown ioctl 35142

Das ist normal und hat IMHO nichts mit cpmaccfg zu tun.

Ich habe den 5-Port Switch der 7170 so verstanden:Es gibt "eth"0-3 welche intern per "lan" ansprechbar sind. Im split-Modus sind die einzelnen Ports dann noch per "lan" ansprechbar, können aber untereinander keine Daten austauschen.

Nein, das ist so nicht richtig. Es gibt cpmac0 als "übergeordnetes" "Container"-Device (mir fällt grad keine passende Bezeichnung ein). Je nach Modus gibt es dann eth0-3, im "Normal"-Modus z.B. nur eth0 über das alle 4 ports angesprochen werden. Zusammen mit dem WLAN wird mittels bridge-Funktion das lan-Device gebildet, falls nichts anderes eingestellt ist.

Im split-Modus wird dann tatsächlich jedem einzelnem Port ein eth0-3 zugeordnet. Allerdings kommt es auf die Konfiguration in der ar7.cfg an: der multid schnappt sich unter Umständen alle Devices, die er findet, und macht darauf wieder ein lan-Device, siehe oben.

So sollte es meiner Meinung nach auch keine Probleme bei gleichen IP-Netzen geben, da ja anhand der MACs die IPs zugeordnet werden, und so das richtige "eth" für jeder IP ermittelt werden sollte.

Jein. Wenn Du einen Rechner anschaltest und er sich beim dnsmasq eine IP-Adresse holt, dann entscheidet dnsmasq anhand der MAC-Adresse, welche IP zugeteilt wird. Ab diesem Zeitpunkt läuft es dann aber genau andersrum: die Fritzbox (genauer gesagt der Linuxkernel) merkt sich die MAC-Adresse der einzelnen Geräte nicht, und schon gar nicht, über welchen Port dieses Gerät erreichbar ist. Da muss der FB quasi geholfen werden, indem man verschiedene IP-Netze auf die einzelnen Ports legt.

 

[cuma]

Uups, hätte doch nicht versuchen sollen, mitzudenken. Im Anhang nun die ungekürzte Ausgabe der Befehle von oben.

Ab diesem Zeitpunkt läuft es dann aber genau andersrum: die Fritzbox (genauer gesagt der Linuxkernel) merkt sich die MAC-Adresse der einzelnen Geräte nicht, und schon gar nicht, über welchen Port dieses Gerät erreichbar ist

Hab wohl zuviel mit Cisco Switches zu tun gehabt, ging davon aus, dass die FB/jeder Switch das auch so handhabt. Aber man lernt wohl nie aus..

 

[olistudent]

Habe jetzt aber noch ein Problem ^^ : Der cpmac Modus "special" wird bei mir in der debug.cfg gesetzt. Wenn ich jetzt zB beim dnsmasq auf der ds-mod Oberfläche "übernehmen" klicke, wechselt die Box wieder in den "ata" Modus (wird auch im Syslog angezeigt), was natürlich sehr unschön ist, wenn unvertraute Clients im "air" Netz hängen. Wo setze ich denn am besten den Modus für cpmac, damit dieser immer geladen wird? Muss ich hierfür evtl direkt im Source-Code etwas ändern?

Das liegt wohl daran, dass der multid neu gestartet wird.

/var/tmp # multid -? 2>&1 |grep changed
  -S STRING          - script to call when onlinestatus changes. ("/bin/onlinechanged")
/var/tmp # ls -l /bin/onlinechanged
lrwxrwxrwx    1 root     root           24 Nov 18  2007 /bin/onlinechanged -> ../var/tmp/onlinechanged

Vielleicht kommst du weiter, wenn du cpmaccfg in dieses Skriptfile einträgst.

MfG Oliver

 

[cuma]

Hey cool, da ist ja schon eine einfach Möglichkeit im ds-mod eingebaut, mir welcher cpmac ausgetricks werden kann.
Da hat der Entwickler aber gut mitgedacht :-] Danke, ein Problem weniger!

 

[cuma]

Die Möglichkeit mit der "onlinechanged" funktioniert. Nur manchmal wird ein Reboot bei Aufruf derer ausgeführt. Deshalb möchte ich lieber die Konfiguartion der cpmac-Modi fest einstellen. Irgendwo hab ich schonmal gelesen, dass dies jemand getan hat, nur finde ich es nicht mehr. Es müsste sich doch irgendwo in der Nähe dieser Datei befinden:

source/avm-gpl-04.49/GPL/base/kernel/linux-2.6.13.1/drivers/net/avm_cpmac/linux_avm_cpmac.h

Kann jemand helfen?

 

[derheimi]

Also ich baue beim Bauen des Kernel noch folgenden Patch mit ein, den ich unter make/linux/patches als Datei abgelegt habe. Damit patche ich den "normalen" Modus meine eigene Konfiguration.

--- linux-2.6.13.1/drivers/net/avm_cpmac/cpphy_adm6996.c.orig   2006-12-20 13:54:47.000000000 +0100
+++ linux-2.6.13.1/drivers/net/avm_cpmac/cpphy_adm6996.c        2007-01-27 09:30:39.062066125 +0100
@@ -106,8 +106,9 @@
                                         { {"", 0x0}
                                         }
                                    },
-        /* CPMAC_MODE_NORMAL    */ { 1, 0xff,
-                                        { {"eth0", 0x2f}
+        /* CPMAC_MODE_NORMAL    */ { 2, 0xff,
+                                        { {"eth0", 0x23},
+                                          {"eth1", 0x2c}
                                         }
                                    },
         /* CPMAC_MODE_ATA       */ { 2, 0,

Ist es das, was Du suchst?

 

[cuma]

Oh geil, genau das hab ich gesucht! Danke
Hab einen Patch erstellt und nach make/linux/patches/2.6.13.1 kopiert. Vorher hatte ich cpmac mittels

 cpmaccfg ssms -w 1 eth0 0x26 eth1 0x28 wan 0x21

konfiguriert (ATA für Port1, Lan für Port 2&3, getrenntes Port4)
Diesen Patch hab ich dann erstellt:

--- linux-2.6.13.1/drivers/net/avm_cpmac/cpphy_adm6996.c_orig	2007-11-21 14:50:51.000000000 +0100
+++ linux-2.6.13.1/drivers/net/avm_cpmac/cpphy_adm6996.c	2008-03-26 00:46:06.000000000 +0100
@@ -108,8 +108,10 @@
                                         { {"", 0x0}
                                         } 
                                    },
-        /* CPMAC_MODE_NORMAL    */ { 1, 0xff,
-                                        { {"eth0", 0x2f}  
+        /* CPMAC_MODE_NORMAL    */ { 3, 0,
+                                        { {"wan",  0x21},
+                                          {"eth0", 0x26},
+                                          {"eth1", 0x28}
                                         } 
                                    },
         /* CPMAC_MODE_ATA       */ { 2, 0,

Traue mich noch nicht so recht. Sollte doch passen??

 

[RalfFriedl]

Trau Dich doch.
Schlimmstenfalls machst Du wieder die vorherige Version drauf.

 

[derheimi]

Der Patch sieht gut aus, allerdings würde ich den CPMAC_MODE_ATA anpassen, nicht den CPMAC_MODE_NORMAL. Denn wenn Du deine Fritzbox bereits auf ATA konfiguriert hast, setzt der multid den Modus anhand der Einstellungen in der ar7.cfg bei Booten automatisch auf ATA-Modus, der Normal-Mode dürfte daher gar nicht zum Zug kommen. Da hatte Ralf IMHO mal tiefer geforscht, inwieweit welcher Modus des cpmac-Treibers wann gesetzt wird?!?!

 

[RalfFriedl]

Nein, ich hatte von Hand verschiedene Modi durchprobiert, aber mich nicht groß darum gekümmert, was multid macht.

Hauptsächlich ging es mir darum, von Hand ohne multid eine funktionierende Netzwerk-Konfiguration zu erreichen. Das hat mit cpmaccfg (und brctl) auch funktioniert.

 

[cuma]

Ja stimmt, es muss natürlich zum "ata" Abschnitt. Hatte dann dummerweise 2 Interfaces gleich benannt und somit einene downtime.. :heul:
Jetzt funktioniert es aber, ich hatte mir echt schon den wolf nach diese codestelle gesucht. Nochmals vielen dank!

 

[dj_eike]

Hallo Zusammen!
Leider muss ich mich doch nun auch mal zu Wort melden.
Bisher bin ich immer mit der SuFu super ausgekommen, aber hierzu hab ich da auch mal eine Frage:

Ich habe auch das Problem, dass nach Änderungen im Freetz Menü immer der Modus "split", den ich beim booten über die rc.custom mittels cpmmaccfg manuell setze, zurück auf "normal" springt.

Die Lösung finde ich super, einfach die Konfig im Kernel zu Ändern. Ich habe auch wie oben schon beschrieben den Kernel-Patch erstellt.
Jetzt kommen meine Probleme ins Spiel: Ich habe noch nie einen Kernel kompiliert. ich habe "make kernel-dirclean", dann "make kernel-menuconfig" ausgeführt und dann hörts bei mir auf. Ich hab da echt kein Plan von, was da alles einzustellen ist. Gibts hier speziell für die 7170 irgendwelche Vorgaben?

Ich habe einfach mal alles übernommen und gespeichert und dann "make kernel-precompiled" ausgeführt. Hier kam dann auch ziemlich schnell mein Ende:

In file included from drivers/mtd/maps/ohio-flash.c:18:
include/linux/squashfs_fs.h:37:2: #error unsupported
drivers/mtd/maps/ohio-flash.c: In function `ohio_find_hidden_filesystem':
drivers/mtd/maps/ohio-flash.c:133: warning: unsigned int format, different type arg (arg 2)
drivers/mtd/maps/ohio-flash.c:133: warning: unsigned int format, different type arg (arg 3)
make[4]: *** [drivers/mtd/maps/ohio-flash.o] Fehler 1
make[3]: *** [drivers/mtd/maps] Fehler 2
make[2]: *** [drivers/mtd] Fehler 2
make[2]: *** Warte auf noch nicht beendete Prozesse...
  CC      drivers/char/tffs-2.0/tffs_panic.o
  LD      drivers/char/tffs-2.0/built-in.o
  LD      drivers/char/built-in.o
make[1]: *** [drivers] Fehler 2
make[1]: Leaving directory `/home/eike/fritz/freetz-trunk/source/ref-8mb_26-04.49/kernel/kernel_8mb_26_build/kernel/linux-2.6.13.1'
make: *** [source/ref-8mb_26-04.49/kernel/kernel_8mb_26_build/kernel/linux-2.6.13.1/vmlinux.eva_pad] Fehler 2

Gibts hier speziell für so Anfänger wie mich ein Kernel-Kompilier-Howto speziell für die Fritzbox 7170?

Bitte die Schimpfe-Antworten einfach mal weglasse
Gruß
Eike

 

[derheimi]

Ein einfaches "make kernel-dirclean", dann "make menuconfig" und dabei die Option "Replace kernel" wählen und ein finales "make" sollten eigentlich reichen, um den Patch wirksam werden zu lassen. Den Schritt "make kernel-menuconfig" solltest Du lieber weglassen, wenn Du noch nie nen Kernel gebaut hast.
Ich verstehe gerade auch nicht, woher Dein Fehler kommt. Daher fände ich es am besten, wenn Du mit einer "sauberen" (frisch ausgecheckten) Freetz-Version nochmal durchstartest: auschecken, Patch hinterlegen, "make menuconfig" und dann "make" sollte eigentlich problemlos durchlaufen.