Box-Info von trunk

[MaxMuster]

... ziemlich sicher aus "/usr/bin/modhosts", dort steht u.a.:

...
                ipaddr=$(ar7ipaddr $section $devname)
                if [ -z "$ipaddr" ] ; then
                  devname=eth0
                  ipaddr=$(ar7ipaddr $section $devname)
                fi
                if [ -z "$ipaddr" ] ; then
                 [B] ipaddr=169.254.1.1[/B]
                fi
                echo -e "$ipaddr\tfritz.box\t$(ar7hostname)" >> /var/tmp/hosts
                ;;
....

Das müsste vermutlich mal angesehen werden, ob es ggf. bei cpmaccfg nicht wie gewünscht funktioniert??

@Gero: könntest du das mal mit "sh -x" ausführen? Vielleicht erkennt man, wo das hängt??

Jörg

 

[olistudent]

Ich tippe mal, dass folgender Abschnitt nicht mehr passt:

		ethmode=$(echo 'ar7cfg.ethmode' | ar7cfgctl -s)
		devname=lan
		case $ethmode in
			ethmode_bridge)
				section=brinterfaces
				break
				;;
			ethmode_router)
				section=ethinterfaces
				break
				;;
			*)
				section=ethinterfaces
		esac
		ipaddr=$(ar7ipaddr $section $devname)
		if [ -z "$ipaddr" ]; then
		  devname=eth0
		  ipaddr=$(ar7ipaddr $section $devname)
		fi

Ich hab jetzt nicht nachgeschaut von wem das stammt. Aber in meinen Augen macht das so keinen Sinn. Wenn die Box in "ethmode_bridge" läuft, dann braucht man die Adresse vom lan Interface. Und wenn die Box im "ethmode_router" läuft, dann ist eth0 das richtige Interface.

MfG Oliver

edit: So würde das mehr Sinn machen.

--- root/usr/bin/modhosts	(revision 5137)
+++ root/usr/bin/modhosts	(working copy)
@@ -70,25 +70,23 @@
 		fi
 
 		ethmode=$(echo 'ar7cfg.ethmode' | ar7cfgctl -s)
-		devname=lan
 		case $ethmode in
 			ethmode_bridge)
+				devname=lan
 				section=brinterfaces
 				break
 				;;
 			ethmode_router)
+				devname=eth0
 				section=ethinterfaces
 				break
 				;;
 			*)
+				devname=eth0
 				section=ethinterfaces
 		esac
 		ipaddr=$(ar7ipaddr $section $devname)
 		if [ -z "$ipaddr" ]; then
-		  devname=eth0
-		  ipaddr=$(ar7ipaddr $section $devname)
-		fi
-		if [ -z "$ipaddr" ]; then
 		  ipaddr=169.254.1.1
 		fi
 		echo -e "$ipaddr\tfritz.box\t$(ar7hostname)" >> /var/tmp/hosts

Behebt aber noch nicht das Problem.

 

[Gero013]

Hallo,

Jörg und Oliver - herzlichen Dank, dass Ihr mich ernst nehmt und zumindest versucht, mein Anliegen zu verstehen!

könntest du das mal mit "sh -x" ausführen?

Weiß nicht ob's richtig war, ich habe einfach die Zeilen in ein Shellscript gepackt und das ausgeführt.
Ergebnis wie folgt:
//Edit habe noch die Funktionen aus modhost zugefügt

+ ar7ipaddr
+ local SEC=
+ local DEV=
+ echo ar7cfg.[].ipaddr
+ ar7cfgctl -s
+ echo
+ paddr=
+ [ -z  ]
+ devname=eth0
+ ar7ipaddr eth0
+ local SEC=eth0
+ local DEV=
+ echo ar7cfg.eth0[].ipaddr
+ ar7cfgctl -s
+ echo
+ ipaddr=
+ [ -z  ]
+ ipaddr=169.254.1.1
+ ar7hostname
+ echo servercfg.hostname
+ ar7cfgctl -s
+ HOSTNAME="(none)"
+ eval echo "(none)"
+ echo (none)
+ HOSTNAME=(none)
+ [ (none) != (none) ]
+ echo fritz.fonwlan.box
+ echo -e 169.254.1.1\tfritz.box\tfritz.fonwlan.box

dass hostname eine IP liefert, die nicht die ist, die er gerne hätte

Nur zur Klärung: was hostname liefert ist mir völlig schnurz. Mich interessiert nur box-info von Freetz und mein Wunsch ist der, dass die Ausgabe einen Sinn ergibt.
Wenn die Adresse eines unbenutzen interfaces als lokale Adresse ausgegeben wird, dann macht das in meinen Augen wenig Sinn.

Aber in meinen Augen macht das so keinen Sinn. Wenn die Box in "ethmode_bridge" läuft, dann braucht man die Adresse vom lan Interface. Und wenn die Box im "ethmode_router" läuft, dann ist eth0 das richtige Interface.

Zur Erklärung noch dies:
Ich hatte mit cpmaccfg angefangen, als ich noch 1.13 drauf hatte und habe die Anweisungen aus dem Wiki nachvollzogen (incl. Kernelpatch, etc. pp). Ich weiß natürlich nicht, was aus dem gepanschten Kernel beim Update auf trunk-Image wurde. Ob der noch aktiv ist oder nicht - keinen Plan.

Meine Box hat in ar7 als mode "dsldmode_router" eingetragen.

Wenn ich ifconfig auf der Box ausführe, erhalte ich folgende Schnittstellen:

adsl
cpmac0
dsl
eth0
eth0:0
eth1
external
internal
lo

wobei eth0 keine IP-Adresse hat, eth0:0 die IP-Adresse hat, die von hostname -i ausgegeben wird (also 169.254.1.1), eth1 ist ein virtuelles Lan in cpmaccfg konfiguriert, external dürfte dem WLAN entsprechen und internal enthält die Adresse der Box in meinem lokalen Netz (also die Adresse, die mir sehr vertraut ist und die ich unter Box-info erwartet hätte).

Gruß Gero

 

[olistudent]

internal? external? Wo kommen denn die Interfaces her?
Was liefert denn folgender Aufruf bei dir?

/var/mod/root # echo 'ar7cfg.ethmode' | ar7cfgctl -s
ethmode_bridge
/var/mod/root # echo 'ar7cfg.ethinterfaces[eth0].ipaddr | ar7cfgctl -s
192.168.178.1

MfG Oliver

 

[hermann72pb]

Wie gesagt, wir können anstelle von 'hostname -i' auch ifconfig grepen. Bei einer 7270v2, wo ich cpmaccfg zwar drauf habe, allerdings unkonfiguriert sieht es so aus (die Box ist offline, daher wahrscheinlich kein dsl-Device):

ath0     KEINE IP
cpmac0    KEINE IP
eth0       KEINE IP   
lan       INTERNE LAN-IP
lan:0    169.254.1.1  Bcast:169.254.255.255  Mask:255.255.0.0
lo        127.0.0.1  Mask:255.0.0.0
wifi0     KEINE IP

Bei einer 7170 sieht es noch wilder aus:

adsl      KEINE IP
cpmac0    KEINE IP
dsl       Externe IP
dsl:dsld  169.254.2.1  P-t-P:169.254.2.1  Mask:255.255.255.255
eth0     KEINE IP
lan       INTERNE LAN-IP
lan:0    169.254.1.1  Bcast:169.254.255.255  Mask:255.255.0.0
lo        127.0.0.1  Mask:255.0.0.0
tiwlan0   KEINE IP
wdsdw0    KEINE IP
wdsdw1    KEINE IP
wdsdw2    KEINE IP
wdsdw3    KEINE IP
wdsup0    KEINE IP

Vermutlich hat 'hostname -i' Probleme damit lan-Device zu finden.

Was wollt ihr für Ermittlung von externer Adresse nehmen? getip? Mit welchem Parameter (da gibt es drei Methoden, wenn ich mich richtig erinnere)?

MfG

 

[olistudent]

Das ändert nichts daran, dass im Fall von Gero eine "falsche" /etc/hosts geschrieben wird. Wenn die stimmt, dann funktioniert ja auch die hostname Abfrage wieder.

MfG Oliver

 

[MaxMuster]

internal? external? Wo kommen denn die Interfaces her?

Das ist das Ergebis der "Wiki-Howto-Anwendung"

@Gero: Der Fall ist aus meiner Sicht tatsächlich so "einzigartig" (mit händisch geänderter ar7.cfg), dass man es verschmerzen kann, wenn der Aufruf von /usr/bin/modhosts damit durcheinander kommt. Ich glaube nicht, dass man damit jeden Fall abfangen kann, so dass du wohl mit der "falschen" Anzeige leben musst . Im "ethmode_router" hat jedes Interface eine eigene IP (Standard wären hier LAN und WLAN getrennt), deshalb wählt das Skript halt eine Schnittstelle aus (eth0), um die IP abzufragen...

Alternativ könnte ich mir nur eine Kombination aus brctl und ifconfig vorstellen, bei dem ich mittels brctl das Interface suche, das eth0 enthält, und dessen IP nehme (auch, wenn das "intern" oder wie auch immer heißt), oder (ohne bridge) die IP von eth0. Auch das wäre aber falsch, wenn ich per cpmaccfg das eth1 als "internes" Interface definierte. Aber solche Spezialfälle sollte man vielleicht doch einfach ignorieren, der Grund für Geros "Problem" ist auf alle Fälle gefunden ;-)


Jörg

 

[Gero013]

Was liefert denn folgender Aufruf bei dir?

Das hier:

/ # echo 'ar7cfg.ethmode' | ar7cfgctl -s
ethmode_router
/ # echo 'ar7cfg.ethinterfaces[eth0].ipaddr' | ar7cfgctl -s
/ #

Der Fall ist aus meiner Sicht tatsächlich so "einzigartig" (mit händisch geänderter ar7.cfg), dass man es verschmerzen kann, wenn der Aufruf von /usr/bin/modhosts damit durcheinander kommt. Ich glaube nicht, dass man damit jeden Fall abfangen kann, so dass du wohl mit der "falschen" Anzeige leben musst .

Ok, hätte ich prinzipiell kein Problem mit.

Bleiben folgende Fragen offen:
1. was passiert mit dem (veralteten?) Wiki-Artikel (denn jeder, der das nachmacht hat dann "mein" Problem)?
und
2. wie bekomme ich die Box wieder in einen Freetz-kompatiblen Zustand?

Gruß Gero

 

[sf3978]

[...]
Was wollt ihr für Ermittlung von externer Adresse nehmen? getip? Mit welchem Parameter (da gibt es drei Methoden, wenn ich mich richtig erinnere)?

Mein Vorschlag:

get_ip -d

 

[olistudent]

2. wie bekomme ich die Box wieder in einen Freetz-kompatiblen Zustand?

Du könntest dein Interface "intern" in eth0 umbenennen.

MfG Oliver

 

[MaxMuster]

Wäre nicht besser "lan"? Dann würde die Original-Version funktionieren, die immer erst "lan" abfragt, oder??

Ergänzung: Denn das "intern" ist ein Bridge-Interface, wenn ich das richtig verstnanden habe, das würde ich nicht wie ein physikalisches IF benennen.
@Gero: Mach doch mal ein "brctl show", falls deine Box das Programm hat.

Jörg

 

[Gero013]

Mach doch mal ein "brctl show"

# brctl show
bridge name     bridge id               STP enabled     interfaces
internal          8000.0024fe216abf       no              eth0
external          8000.000000000000       no

Hm, könntet Ihr mir bitte mal zum Verständnis folgende Fragen beantworten:
1. wodurch entsteht ein Interface - durch Patchen des Kernels, oder durch Eintrag in der ar7.cfg?
2. Wie kann ich rausfinden, welchen Kernel ich drauf habe?
Ich meine jetzt nicht die Version (cat /proc/version kenne ich), sondern ob der Kernel der gepanschte aus replace kernel der 1.13 Version ist, oder ob der Kernel von trunk stammt (dort gibt es zwar keine Menüoption, um den Kernel zu ersetzen, aber ein kernel scheint ja doch dabei zu sein).
3. eth0 wird in der ar7.cfg zwar referenziert, aber imho nicht angelegt. Wer erzeugt das interface, das ja per ifconfig angezeigt wird?

Gruß Gero

 

[olistudent]

Der multid legt die Interfaces aus der ar7.cfg an. Der Switch muss im passenden Modus dazu sein.
Entweder hast du den Kernel ersetzt oder nicht. Also wenn du ein trunk Image auf der Box hast, dann ist das entweder der Freetz Kernel aus dem trunk oder der AVM Kernel. Feststellen lassen sollte sich das am Datum der Kompilation (uname -a).

MfG Oliver

 

[Gero013]

Hallo Oliver,

danke für Deine Unterstützung!

Feststellen lassen sollte sich das am Datum der Kompilation (uname -a).

# uname -a
Linux fritz.fonwlan.box 2.6.19.2 #2 Mon Mar 15 14:10:13 CET 2010 mips GNU/Linux

also an dem Datum habe ich noch keinen Kernel für die Box gebacken.

Bei menuconfig heißt es, dass "replace kernel" derzeit nicht zur Verfügung steht.
Liegt das an meinen lokalen Einstellungen, oder ist da noch eine offene Baustelle?

Offensichtlich scheint cpmaccfg auch ohne selbst gebackenen Kernel zu funktioklappen. Wie weit stimmt dann noch die Wiki-Bauanleitung?
Wie sieht denn der Bereich ethinterfaces auf einer "normalen" Box aus?
Kann ich cpmaccfg auch ohne modifizierte ar7.cfg verwenden?
Irgendwie würde ich meine Box gerne wieder auf den "Standard"-pfad der Freetz-Tugend zurückführen

Gruß Gero

 

[hermann72pb]

@Gero013: Lass uns doch zunächst dein Problem versuchen wenigstens zu beheben, wenn wir schon lange bei sind die Ursachen festzustellen. Zunächst würde mich interessieren, ob denn die Trennung von interfaces bei dir tatsächlich funktioniert. Und wenn ja, versuch doch "internal" nach "lan" zu benennen, wie oben vorgeschlagen. Dann wird es evtl. mit hostname -i korrekt angezeigt. Wenn es dem so ist, dann sollte man die WIKI-Anleitung korrigieren.
Zurück zum ursprünglichen Zustand kannst du durch die Werkseinstellungen kehren. Allerdings ist dann alles weg. Wenn man geschickter vorgeht, kann man vielleicht nur separate Bereiche in ar7.cfg editieren.
@Oliver: Kannst du bitte diese Diskussion hier wenigstens ab dem Zeitpunkt, wo es festgestellt wurde, dass es an cpmaccfg liegt abtrennen? Denn mit box.info hat es mittlerweile wenig zu tun.

MfG

 

[Silent-Tears]

Ich glaube, um einen sauberen Stand zu haben, wäre ein Recover vonnöten, und nicht nur ein Reset auf die Werkseinstellungen...

 

[Gero013]

Zunächst würde mich interessieren, ob denn die Trennung von interfaces bei dir tatsächlich funktioniert

Hm, wenn Du mir sagst, wie ich das testen kann, tue ich das gerne.

Und wenn ja, versuch doch "internal" nach "lan" zu benennen

Bevor ich irgendwas umbenennen, würde ich gerne die Zusammenhänge verstehen (zugegeben, als ich den Wiki-Artikel durchgearbeitet habe, war das nicht der Fall und jetzt zeigt sich ja, dass das nicht unbedingt die beste Vorgehensweise ist).
Außerdem ist "lan" der erste Eintrag bei "brinterfaces".

"internal" taucht auch noch mehrfach in dem Bereich "nqos" als Typ "qos_cfg_internal" auf. Hängen die Einträge mit dem interface "internal" zusammen oder ist die namensgleichheit eher Zufall?

Denn mit box.info hat es mittlerweile wenig zu tun.

Da bin ich noch nicht von überzeugt.
Denn wenn jemand anderes die Wiki-Anleitung nachmacht, passiert ihm sicher das Gleiche, wie mir.
Der Umstand, dass sich bisher niemand gemeldet hat, heißt nicht unbedingt, dass der Fall nicht eingetreten ist.

Ich glaube, um einen sauberen Stand zu haben, wäre ein Recover vonnöten, und nicht nur ein Reset auf die Werkseinstellungen...

Puh - also ein recover habe ich schon mehrfach hinter mir, einen Reset auf Werkseinstellungen würde ich - wenn möglich - gerne vermeiden!

Gruß Gero

 

[olistudent]

Ich wüsste auch nicht wo ich hier sinnvoll was abtrennen soll.

MfG Oliver

 

[hermann72pb]

@Gero: Das heißt aber jetzt nicht, dass man deswegen an box.info drehen muss, um die Anzeige zurecht zu biegen. Mit dem externen IF und 'get_ip -d' ist bei mir angekommen, sonst sollte man eher die Anleitung in WIKI anpassen.
Ich weiß jetzt nicht, was da in der Anleitung steht, und habe leider keine Zeit und Lust es durchzulesen, meine Vermutung liegt aber darin, dass du es ruhig an einer Stelle von "internal" in "lan" umbenennen kannst und zwar dort überall, wo "internel" alleine steht. Die ganzen Sachen mit Unterstrichen würde ich erstmal so stehen lassen.
Selbst wenn du die Box dadurch "zerschießen" solltest, Recover würde immer gehen und das wurde dir sowieso oben vorgeschlagen.
Zu dem, wie du testen kannst, ob es denn funktioniert. Ich dachte, du kennst dich damit aus, wenn du die IFs schon trennst. Wie gesagt, ich weiß nicht, wie es konkrett in dieser Anleitung gemacht ist, ich vermute aber stark, dass beide getrennten Netze idealerweise zwei unterschiedliche Subnetzbereiche besitzen werden. Und du kommst nicht ohne weiteres von einem ins andere. Das ist der Sinn der Sache mit Separierung der IFs. Allerdings weiß ich nicht, ob AVM-Firewall alleine reicht, die beiden Netze miteinender zu verbinden und zu forwarden, oder ob man dafür besser iptables nehmen sollte.
Die Idee mit dem getrennten WLAN ist an sich nicht ganz verkehrt. Man kann dadurch im WLAN die WEP-Verschlüsselung einschalten oder sogar komplett unverschlüsselt funken, um irgendwelche alte Geräte mit dem Internet zu verbinden. Gleichzeitig würde man allerdings diese schwach verschlüsselte Geschichte von seinem Heimnetz etwas abtrennen. Für irgendwelche kleine Hotels oder Ähnliches wäre sowas ideal.

MfG

 

[RalfFriedl]

Zunächst würde mich interessieren, ob denn die Trennung von interfaces bei dir tatsächlich funktioniert

Hm, wenn Du mir sagst, wie ich das testen kann, tue ich das gerne.

Du wirst ja wohl einen Grund gehabt habe, den Switch umzukonfigurieren. Wenn Du keine Möglichkeit hast, den Unterschied festzustellen, warum hast Du das dann überhaupt getan?