Wie mit coova verfahren ?

Infrastruktur WLAN
7

Ich habe den coova jetzt auf dem aktuellen source basierend auf einem ubuntu 16.04 64bit kompiliert. Ich werde das jetzt in eine neue virtuelle Machine einbauen und dann mal sehen ob es funktioniert.
Das Packet hat nur knapp ein halbes MB und kann gerne hier:
https://www.lehrerwerkzeuge.de/owncloud/index.php/s/6VY84hxq47L16zg
heruntergeladen werden.

8

Ich habe heute mein Upgrade auf 14.04 testen können: Es funktioniert! Wie gesagt: Ich musste explizit die neuen config-Dateien der Paketersteller von freeradius übernehmen, damit es ging. Habe ich meine config-Dateien behalten (was die Standardeinstellung ist), so konnte sich im Anschluss kein Benutzer mehr anmelden (Passwort angeblich falsch…).

LG Alex

9

Dieses Thema lief auch schon vor einiger Zeit … und auch hier mal nochmal kurz die Rückfrage:
Einige Schüler berichteten neulich, dass die Verbindung über coova (12.04) sehr langsam (geworden?) sei. Das war vor einiger Zeit aber noch nicht der Fall. Bringt hier eine Neuinstallation auf eine aktuelle Version etwas? Ich meine im Hinterkopf zu haben, dass einige auch deshalb von 12.04 auf 14.04/16.04 gewechselt haben, oder?

10

Hallo Michael,

das war auch genau meine Beobachtung: Die Verbindung über den Coova (12.04) ist sehr langsam geworden. Daran hat aber auch eine Installation unter 14.04 nichts geändert. Ich habe den Coova jetzt rausgeschmissen, und mache es direkt über den unifi-Controller, seitdem ist die Verbindung einwandfrei.

LG Alex

11

Hi.
Hm … es muss doch eine Ursache dafür geben, dass der coova “plötzlich” langsamer wird??? Hatten nicht andere berichtet, dass die Verbindung unter 14.04 (wieder) flott läuft??

Ich hatte von der netzint-Lösung gehört und weiß nicht, was du “direkt mit den Unifi-Controllern” meinst?
Bei uns ist es so, dass ein paar Scripte im coova laufen, die z.B. automatisch die Verbindung trennen, wenn Schüler in die große Pause gehen. Auf diese Funktionalität würde ich nur sehr ungerne verzichten…

12

Hallo Michael,

Bei GBit-Netzwerkkarten scheint diese Problem aufzutauchen.

mit

ethtool -K eth0 gro off
ethtool -K eth1 gro off

sind der Upload und der Download wieder annehmbar schnell. Ich habe die beiden Befehle in /etc/network/if-up.d/ethtool am Ende eingefügt:

$ETHTOOL -K eth0 gro off
$ETHTOOL -K eth1 gro off

allerdings ist das schon eine Weile her. Probiert’s einfach mal aus…

Und hier noch der Link zum nachlesen: https://github.com/coova/coova-chilli/issues/32

Gruß,

Mathias

13

Hi. Ich habe die Befehle abgesetzt – frage mich aber dennoch, ob hier auch virtuelle coova-Instanzen betroffen sind / sein können?? Wir haben alles unter Proxmox virtualisiert …

14

Hallo Michael,

Wir auch :wink:

15

Hallo Holger,

nachtrag: genau wie Rainer und Alex: ich habe ein do-release-upgrade gemacht und immer auf „I“ getippt, also die Version des Paketbetreuers übernehmen.
Ohne weiteres zutun funktioniert nun auch coovachilli auf einem 14.04.
Ich finde das einfacher als eure Empfehlung, denn ich wüsste nichtmal welche Configdateien ich kopieren sollte.

VG, Tobias

16

Ein herzliches Hallo an alle,

ich habe heute versucht den coova nach Tobias Methode auf 14.04 upzugraden:

Dabei ist mir wohl ein Fehler passiert, da ich am Schluss kein Netzwerk mehr hatte.

Ich dachte mir: Gott sei dank hab ich noch einen Backup-Clone des Coova erstellt. Da etwas schiefgelaufen ist, hab ich die alte Coova-VM gelöscht und die neue in Coova umbenannt und gestartet.

Nun hab ich folgendes Problem: Ubuntu zeigt mir auf dieser Maschine ein neues Release an. So weit so gut. Wenn ich jedoch ein do-release-upgrade machen möchte, dann sagt er mir, dass kein neues release da ist.

Nun habe ich folgendes versucht: ping gesetzt auf https://www.google.com brachte mir ein

ping: unknown host https://google.com

Es scheint also, dass die neue Virtuelle Maschine vom IPFire geblockt wird.
Muss ich die neu zugewiesenen MAC-IDs im IPFire eintragen? Und wenn ja, wie mach ich das?

Grüße
Marcus

17

Und was macht ein ping www.google.com (ohne https://)?

Andreas

18

Hallo Andreas,

das gleiche. Ich habe nochmals auf docs.linuxmuster.net nachgeschaut, wie man den ipfire einrichtet. Und hier sind die Netzwerkkarten definitv über MAC-ID am IPFire angemeldet. So wie es ausschaut, kann ich auf den IPFire aber nur mit Browserzugriff kommen. D.h. dass ich mich hier erst am Montag in der Schule drum kümmern kann. Was nicht so in meinem Sinne war.

Oder weißt du noch eine andere Möglichkeit?

Grüße

Marcus

19

Hallo Marcus,

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 aufrufen.

Viele Grüße

Andreas

20

Hallo Marcus,

Du könntest der neuen VM dieselbe MAC-Adresse geben wie der alten, dann merkt der IPFire keinen Unterschied.

Viele Grüße

Jörg

21

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

22

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

23

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

Andreas

24

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

25

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

26

Hallo Andreas,

das hat geholfen! War ne falsche IP.

Jetzt brauch ich noch weiter Hilfe.

Vielen Dank,

Marcus