Wie mit coova verfahren ?

Hallo Jörg,

daran hab ich auch schon gedacht. Habe leider die VM vor der Abfrage der MAC-ID zerstört. Ich denke jedoch, dass sich das nochmals aus dem IPFire herauslesen lässt.

Versuche den Ansatz von Andreas

du kannst (wenn du per ssh auf den Server kommst) mit der Option -L von ssh einen Tunnel bauen und dann per Browser auf den ipfire zugreifen:

ssh -p2222 -L 8801:10.16.1.254:444 xxx@eure-schule.xx

Im Browser dann die Adresse [https://127.0.0.1:8801](https://127.0.0.1:8801) aufrufen.

Ansonsten muss ich das am Montag irgendwie lösen.

Grüße

Marcus

So wie es aussieht, kann ich von daheim nicht wirklich von außen einen ssh-Tunnel auf ipfire aufbauen, obwohl die IP-Fire-IP in

ssh -p2222 -L 8801:10.16.1.254:444

stimmt. Das habe ich via ifconfig auf der virtuellen Maschinenverwaltung in der IP-Fire-VM überprüft.

Das Terminal meldet nach Anwahl:

ssh -p2222 -L 8801:10.16.1.254:444 xyz@141.xx.xx.xx
ssh: connect to host 141.xx.xx.xx port 2222: Connection timed out

Kann das sein? Wenn das so ist, dann verstehe ich nicht die Möglichkeit von außen über die öffentliche IP 141.xx.xx.xx zugreifen zu können. Mit der virtuellen Maschinenverwaltung von kvm geht das. Daher muss von meinem Verständnis dies auch über den Konsolenzugriff funktionieren. Oder sehe ich hier was falsch?

Grüße
Marcus

Die 141.xx.xx.xx muss die IP des ipfire in rot sein, ist sie das denn?

Andreas

Hallo Marcus,

ihr driftet mit ssh-port-forwarding ziemlich ab.

Du kannst auf dem IPFire auch einfach per konsole die Regeln auslesen:

# ssh ipfire
# less /var/ipfire/wireless/config 
1,172.16.16.1,52:54:00:4c:1b:a7,on,coovachilli

oder die anderen regeln alle:

# less /var/ipfire/firewall/config

mit der MAC von dir kommst du vielleicht weiter.
Irgendwie hab ich das gefühl, dass sich deine Mac vielleicht gar nicht geändert hat und es einen anderen grund gibt, weswegen du kein LAN hast auf dem Coova.
mach mal dort ifconfig -a.

VG, tobias

Hallo Marcus,

ssh -p2222 -L 8801:10.16.1.254:444 xyz@141.xx.xx.xx ssh: connect to host
141.xx.xx.xx port 2222: Connection timed out |

Kann das sein? Wenn das so ist, dann verstehe ich nicht die Möglichkeit
von außen über die öffentliche IP 141.xx.xx.xx zugreifen zu können. Mit
der virtuellen Maschinenverwaltung von kvm geht das. Daher muss von
meinem Verständnis dies auch über den Konsolenzugriff funktionieren.
Oder sehe ich hier was falsch?

xyz muß aber root sein: nur der darf tunnel bauen.

Und wegen KVM: Vorsicht: das ist eine andere Maschine, also auch eine
andere IP.
Deswegen stimmt was Andreas sagt: die IP muss die vom IPFire sein, nicht
die vom KVM Host.

Ich nehme aber eh an, dass der Vorgänger den SSH Zugang mit keys
abgesichert hat: dann kommst du so nicht ran (es sie den du hast den key).

Aber: du brauchst den tunnel nicht.
Geh auf den IPFire (console per virtmanager) und schau in die Datei
/var/ipfire/dhcp/dhcpd.conf

Da steht bei mir:

host fix0 # coovachilli
{
hardware ethernet 52:54:00:xx:xx:xx;
fixed-address 172.16.16.3;
}

… aber auch nur, weil ich dem coova im DHCP des IPFire eine feste IP
zugewiesen hab.

LG

Holger

Hallo Andreas,

das hat geholfen! War ne falsche IP.

Jetzt brauch ich noch weiter Hilfe.

Vielen Dank,

Marcus

ssh-port-forwarding hat auch nicht geholfen. Ich hab die Coova-Einträge mit beiden MAC-IDs des Coova-Servers versucht. Leider ohne Erfolg. Der Chilli kommt immer noch nicht raus. Hab jetzt mal die Ausgangszustände im IP-Fire wieder hergestellt. Muss mal für 4 Stunden weg und versuch mich dann nochmals.

Ich komm dann wieder auf euch zurück.

Grüße und erstmal vielen Dank,
Marcus

du meinst, du hast der Coova-virtuellen Maschine die MACs gegeben, die du in /var/ipfire… gefunden hast (die also der alten MAC der Coova VM entsprechen sollten) ?

oder hast du andersherum versucht die neue MAC-Adresse in die configurationsdateien zu speichern?

Ich würde den ersten Fall probieren.
Bei zweiten Fall müsstest du die konfiguration des IPFire auch „Übernehmen“, aber mangels Webinterface müsstest du neustarten. den zweiten Fall würde ich also nciht machen, nachher schließt du dich aus…

VG, Tobias

Hallo Marcus,

ssh-port-forwarding hat auch nicht geholfen. Ich hab die Coova-Einträge
mit beiden MAC-IDs des Coova-Servers versucht. Leider ohne Erfolg. Der
Chilli kommt immer noch nicht raus. Hab jetzt mal die Ausgangszustände
im IP-Fire wieder hergestellt. Muss mal für 4 Stunden weg und versuch
mich dann nochmals.

natürlich muss die Netzwerkkarte auch im richtigen Netz vom IPFire sein:
also am richtigen virtuallen Switch hängen.

LG

Holger

Hallo Holger,

So wie ich das einschätze, sollten die Netzwerkkarten des Coova im richtigen Netz hängen:

Ist ja auch ein Klon des Ursprungs-Chili gewesen. Somit sollten auch die meisten Einstellungen (bis auf die MAC-ID) mit geklont werden.

Zu Tobias:

Ich habe den 2. Fall versucht, da ich über Andreas’ Vorschlag doch mit Hilfe des SSH-Tunnels und eines Browsers auf den IPFire kam.

Noch zu Holger:

So wie es aussieht, haben wir keine feste IP für den Coova.
Die Ausgabe von dhcpd.conf ergibt
{
range 172.xx.xx.1 172.yy.yy.200;
option subnet-mask 255.255.255.0;
option domain-name „schule.lokal“;
option routers 172.yy.yy.254;
option domain-name-servers 172.yy.yy.254;
default-lease-time 3600;
max-lease-time 7200;
} #Blue
include „/var/ipfire/dhcp/dhcp.conf.local“;

Schau ich dann in dhcp.conf.local nach, dann gibt mir die Ausgabe folgendes:
~
~
~
~

Also nix.

Wo finde ich im Pfad /var/ipfire… die alten MAC der Coova-VM und wie bekomme ich die MAC-IDs umgeschrieben?

Grüße
Marcus

Hallo Marcus,

ich meinte zwar hier:

würdest du deine MAC von damals finden, aber wenn du jetzt einen zugang zur Oberfläche hast, dann bleibe bei deiner Variante zwei und ändere die MAC im IPFire und mache es doch über die Weboberfläche, also wie in der Anleitung geschrieben. (aus dem kopf: „Zugriff auf blau“ dort muss der coovachilli drin stehen und ichdenke das ist identisch mit obiger datei „wireless/config“)

Aber wichtig ist ja auch, dass der Coovachilli auch die IP hat, die dort drin steht (also bei mir die 172.16.16.1) und zwar mit dem richtig verbundenen interface (die mit e1000 als treiber).

D.h. du musst, weil du nicht wie Holger per DHCP die IP bekommst, dem Coova die IP fest anlegen.
So hab ich das auch, bei mir sieht das so aus:

root@gilliam:~# cat /etc/network/interfaces
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto eth0

iface eth0 inet static
        address 172.16.16.1
        netmask 255.255.255.0
        network 172.16.16.0
        broadcast 172.16.16.255
        gateway 172.16.16.254
        dns-nameservers 172.16.16.254
        dns-search linuxmuster-net.lokal

Dagegen wird bei mir eth1 nicht konfiguriert, und coovachilli erzeugt noch ein tun0-interface, das auch nicht von mir konfiguriert wird.

spätestens nach einem neustart des coova (ein „service networking restart“ funktioniert bei mir nicht) sieht es bei mir so aus:

# ifconfig eth0
eth0      Link encap:Ethernet  Hardware Adresse 52:54:00:4c:1b:a7  
          inet Adresse:172.16.16.1  Bcast:172.16.16.255  Maske:255.255.255.0

VGlück, Tobias

Hallo Tobias,

ich hab jetzt tatsächlich mit

die ursprüngliche MAC-ID herausfinden können. Unser Coova ist als 172.16.16.5 nach IP-Fire konfiguriert worden.

Ein ifconfig auf dem Coova gibt mir aber keine 172.16.16.5 aus. Wahrscheinlich, weil der IPFire blockt oder die VM noch keine statische Adresse zugewiesen bekommen hat.

Ein Blick auf /etc/network/interfaces liefert

Nach

müsste ich die 172.16.16.1 mit unserer 172.16.16.5 ersetzen. Danach hätte ich meiner coova-vm eine Statische Adresse zugewiesen. Verstehe ich das richtig?

Wenn das so ist, dann frage ich mich, warum mein Vorgänger dem Coova keine statische IP, sondern nur eine IP-Range im IPFire reserviert hat.

Dann interessiert mich noch was: Im IPFire wird mir ein Update von Core 104 nach 119 vorgeschlagen. Soll ich das anstoßen, oder lieber lassen? Ihr wisst ja, bin nun ein gebranntes Update/Upgrade-Kind.

Grüße
Marcus

Hallo Marcus,

habe jetzt erst deinen Post mit der IP-Range im DHCP gelesen.

Weil es auch so gehen sollte: der alte Coova bekam irgendwann mal eine zufällige IP aus dem Range (16.16.5) und danach wurde der Zugriff für die alte MAC mit der IP 16.16.5 erlaubt.
Glücklicherweise bekommt der Coova dann meist dieselbe IP aus dem Range, auch wenn man dem DHCP das nicht sagt. Es muss aber nicht so sein und daher war die alte Config instabil.

Ich würde jetzt entweder wie Holger: die IP im DHCP für den neuen Coova fixieren und die neue MAC wie die fixierte IP bei Zugriff auf blau eintragen.
oder wie bei mir: such dir eine IP raus (172.16.16.6), trage sie beim Coova fest in /etc/network/interfaces ein und trage sie mit der neuen MAC bei Zugriff auf blau ein. Dann ist der DHCP völlig egal.

p.s. ifconfig liefert vermutlich schon jetzt ein IP, aber nicht die 16.16.5, das ist mein Tipp.

VG, Tobias

pps.
ich verwirre jetzt noch ein bisschen: mein IPFire machte auf blau auch noch DHCP in derselben Range wie bei dir, sieht so aus

und weiter unten auf der Seite “DHCP-Server” hatte ich damals testweise noch dem Coovachilli fest seine MAC-IP-Zuordnung fixiert, das sieht so aus:


Das ist aber bei mir (weil ich die IP static konfiguriere) meines Erachtens nicht nötig, selbst wenn der DHCP aktiviert wäre.

Vielleicht versteht man jetzt, warum die IP 16.16.5 bei dir früher für den alten Coova mit DHCP immer funktionierte, wenn man den DHCP für den neuen Coova eben will, sollte man diese feste Zuordnung auch machen.

Ich werde meinen zweiten Coova jedenfalls nicht wie oben fixieren und DHCP machen, sondern wieder statisch konfigurieren und bei “Zugriff auf blau” eintragen.

VG, Tobias

Hallo Tobias,

vielen lieben Dank für deine Hilfe. Ich versteh nun mehr wie das mit dem IPFire und Coova funktioniert. Jedoch raucht mir jetzt gerade der Kopf und ich werd morgen noch weiter probieren und deinen Weg

versuchen und hoffe, dass dann der Coova wieder on ist. Danach muss ich ans Upgrade der Ubuntu-Release gehen und zwar so, dass ich nicht noch einmal die vm schrotte.

Vielen herzlichen Dank euch allen. Ohne euch wär ich noch mehr aufgeschmissen als jetzt schon.

Grüße und bis morgen,
Marcus

Hallo Tobias,

ich hab dem coova nun die IP 172.16.16.6 durch

statisch vergeben. Dias hab ich auch im IPFire hinterlegt (bei Zugriff auf blau). Ein Neustart der Coova-VM hat die VM endlich raus gebracht (ping auf google.de).

Komisch war nur, dass ifconfig im coova nur den lokalen Server gezeigt, jedoch IPFire schon dynamisch 172.16.16.6 zugeordnet hat (nach seiner Ausgabe).

Vielen Dank Tobias, das hat geholfen!!!

Ich werd gleich mal die VMMaschine erneut klonen und dann heute Mittag mich an das Upgrade wagen, ohne dass ich irgendetwas am Ende löschen lasse.

Grüße und vielen Dank,
Marcus

das ist zufall. 172.16.16.6 war vermutlich die nächste, die nach 16.16.5 frei war.

freut mich, dass es funktioniert.
VG, Tobias

Auf jeden Fall funktioniert es von daheim aus. Mal schauen, ob unser Coova beim w-LAN-Stellen noch in der Schule Probleme macht. Das war nämlich vor den Ferien so. Ich hoffe, dass mit Upgrade und den statischen Einstellungen die Config nun stabil ist, und der Coova wieder ohne Probleme w-LAN stellt.

Der IPFire von uns sollte auch so schnell wie möglich aktualisiert werden. Jetzt hab ich aber in diversen Streams hier auf linuxmuster Probleme beim Update gelesen.

Wie soll ich verfahren? Soll ich auch den Server da hinter upgraden (do-release-upgrade)? Gibt es hierzu ähnliche Erfahrungswerte wie beim Upgrade von Ubuntu 12.04 auf 14.04? So wie es mit unserem licence-Server und letztendlich auch mit unserem Coova geklappt hat, sollte ein do-release-upgrade eigentlich durchlaufen, oder?

Grüße
Marcus

Hallo Marcus,

/var/ipfire/dhcp/dhcpd.conf

Da steht bei mir:

host fix0 # coovachilli

{

hardware ethernet 52:54:00:xx:xx:xx;

fixed-address 172.16.16.3;

}

So wie es aussieht, haben wir keine feste IP für den Coova.
Die Ausgabe von dhcpd.conf ergibt
{
range 172.xx.xx.1 172.yy.yy.200;
option subnet-mask 255.255.255.0;
option domain-name “schule.lokal”;
option routers 172.yy.yy.254;
option domain-name-servers 172.yy.yy.254;
default-lease-time 3600;
max-lease-time 7200;
} #Blue
include “/var/ipfire/dhcp/dhcp.conf.local”;

trag doch die MAC der NIC des Coova dort in der FOrm ein, wie bei mir.
Dann hat er eine Feste.
Starte danach den IPFire neu.

LG

Holger

Hallo Marcus,

Der IPFire von uns sollte auch so schnell wie möglich aktualisiert
werden. Jetzt hab ich aber in diversen Streams hier auf linuxmuster
Probleme beim Update gelesen.

der IPFire wird am Besten vom Server aus mittels
linuxmuster-ipfire --upgrade
aktualisiert.

Wie soll ich verfahren? Soll ich auch den Server da hinter upgraden
(do-release-upgrade)? Gibt es hierzu ähnliche Erfahrungswerte wie beim
Upgrade von Ubuntu 12.04 auf 14.04? So wie es mit unserem licence-Server
und letztendlich auch mit unserem Coova geklappt hat, sollte ein
do-release-upgrade eigentlich durchlaufen, oder?

bitte niemals das Ubuntu unter dem Server aktualisieren: das machen wir,
wenn es soweit ist!
Das sit essentiell wichtig.
Machst du auf dem lmn Server ein do-release-upgrade, dann hast du ein
gutes Backup oder kein funktionierendes Netz mehr …

LG

Holger