Hallo liebe Mitdenker,
nachdem dieser Thread eine Weile ruhte, habe ich den IPFire neu
aufgesetzt und die auf dem server gespeicherten Einstellungen mit
linuxmuster-ipfire --restore zurückgespielt. Da mein virtualisierter
Client danach noch immer die gleichen Symptome zeigte, habe ich auf dem
Coov
Hallo Christian,
bei mir sind alle Maschinen mit libvirt/KVM (Ubuntu 14.04)
virtualisiert. Als Netzwerkkarten hatte ich auf der Verbindungsseite
IPFire - Coova auf beiden Maschinen "virtio" ausgewählt, aber auch mit
"e1000" kam das gleiche Ergebnis.
Das sind alles GB-Karten die der Coova sieht, a
Hallo Mathias,
bei mir sind alle Maschinen mit libvirt/KVM (Ubuntu 14.04)
virtualisiert. Als Netzwerkkarten hatte ich auf der Verbindungsseite
IPFire - Coova auf beiden Maschinen "virtio" ausgewählt, aber auch mit
"e1000" kam das gleiche Ergebnis.
Viele Grüße
Christian
>
> Gruß,
>
> Mathias
>
>
Hallo Christian,
ein Neustart wäre nicht nötig gewesen. Ganz im Gegenteil, die
Einstellungen sind noch nicht "gespeichert". Das war nur ein Versuch.
Was ich gelesen habe, tritt dieser langsame Datendurchsatzt vorallem
(oder nur) bei GB-Netzwerkkarten auf. Und dann hilft das beschriebene
Vorgeh
Hallo Christian,
> Der Proxy bzw. URL-Filter des IPFire scheinen zu stören, da das Surfen
> am Proxy vorbei über Port 443 oder auch Pings ans www funktionieren.
.. aber https läuft doch über 443.
Schick doch mal screenshots von der Proxyconfiguration im IPFire.
VIele Grüße
Holger
--
Mein öff
Hallo Mathias,
ich habe alle Schritte so ausgeführt und nebenher den IPFire auf Core97
aktualisiert. Danach ging wieder nichts mehr. Oder hätte ich den
CoovaChilli neustarten müssen?
Schöne Grüße
Christian
Am 13.02.2016 um 08:28 schrieb Mathias Rettich:
> Hallo Christian,
>
> probier doch mal
Hallo Christian,
probier doch mal meine An twort vom 11.2.
Ich hatte genau das gleiche Problem. Du muss nur ethtools installieren
und zwei Befehlszeilen eingeben:
1. Melde dich als root auf deinem CoovaChilli an
2. apt-get install ethtool
3. ethtool -K eth0 gro off
4. ethtool -K eth1 gro off
Die DNS-Auflösung funktioniert, bei beiden Aufrufen erscheint in
kürzester Zeit: "warten auf"
Allerdings werden nur Aufrufe mit https auch in gewohnter
Geschwindigkeit umgesetzt.
Der Proxy bzw. URL-Filter des IPFire scheinen zu stören, da das Surfen
am Proxy vorbei über Port 443 oder auch Pings an
Hallo Christian,
Am 04.02.16 schrieb Christian Weichhard :
> Wo soll ich nun anfangen zu suchen?
>
beim DNS
bspw. der Besuch von
http://141.19.87.190/home/index.php
vs.
http://www.irt.hs-mannheim.de/home/index.php
Wenn der erste Aufruf sofort funktioniert, hats Du ein DNS-Problem.
Dirk
__
Top sagt nur, dass sich der Coova (0,3% CPU Auslastung durch chilli)
und
IPFire (alles maximal auf 0,1%) langweilen.
Vielleicht hilft iftop weiter? Das zeigt den Durchsatz über die
einzelnen Devices an (muss aber ggf nachinstalliert werden).
Wir sind noch auf Core <96 -- ich warte aber nach
Am 10.02.2016 um 09:02 schrieb Alois Raunheimer:
> Hallo Christian,
>
> wenn das Netz lahmt lohnt sich ein Blick mit "top" auf der Konsole
> eventuell. Bei uns waren es Rechner die Bitdefender installiert
> hatten. Diese Rechner versuchten ständig nach Hause zu telefonieren
> und verursachten dab
Hallo,
vielleicht klappt das : https://github.com/coova/coova-chilli/issues/32
Bei GBit-Netzwerkkarten scheint diese Problem aufzutauchen.
Mit
ethtool -K eth0 gro off
ethtool -K eth1 gro off
könnte der Upload und der Download wieder annehmbar schnell sein.
Ich habe die beiden Befehle in /etc
Hallo Christian,
wenn das Netz lahmt lohnt sich ein Blick mit "top" auf der Konsole
eventuell. Bei uns waren es Rechner die Bitdefender installiert hatten.
Diese Rechner versuchten ständig nach Hause zu telefonieren und
verursachten dabei 100 % Serverlast. Nachdem ich die Rechner aus dem Netz
geki
Nachtrag: zum Coovachilli Problem
Verschiedene Tests mit unterschiedlichen Coovachilli-Unterbau-Versionen
und unterschiedlichen IPFire Versionen haben bei mir ergeben, dass das
IPFire Core Update 96 bzw. 97 nicht mit Coovachilli verträglich ist.
Coovachilli hat auch mit Ubuntu 14.04 bei mir funkti
Ja, da ist wohl meine Phantasie mit mir durchgegangen. Ich meinte
irgendwo gelesen zu haben, dass ein do-release-upgrade auf trusty beim
coovachilli ungefährlich sei und bei irgendjemandem geklappt hätte. Die
Grundregel bleibt also auf allen Servern im lmn-Zoo: nie einfach so
upgraden.
Danke,
Chr
> ein dist-upgrade hieft das ubuntu nicht auf eine neue Verion.
> Da muß man schon anders hand an legen.
Äh, ja klar ... das war ein Tippfehler im Eifer des Gefechts ...
ich meinte natürlich das release-upgrade.
Michael
___
linuxmuster-user mailing lis
Hallo,
Am 04.02.2016 um 17:54 schrieb Michael Hagedorn:
> Hi.
>> Was hat sich in letzter Zeit geändert?
> cat /var/log/apt/history.log (bzw. zcat /var/log/apt/history.log.1.gz )
>
Dank der Log-Dateien habe ich herausgefunden, dass das Release-Upgrade
schon Anfang November letzten Jahres war. Dana
Hallo,
>> Im Verdacht steht das Release Upgrade des Coovachilli von Ubuntu 12.04.x
>> auf 14.04.x, seitdem habe ich unter Umständen keine Internetseite mehr
> Hmm -- hast du das dist-upgrade (selbst) durchgeführt???
ein dist-upgrade hieft das ubuntu nicht auf eine neue Verion.
Da muß man schon an
Hi.
> Was hat sich in letzter Zeit geändert?
cat /var/log/apt/history.log (bzw. zcat /var/log/apt/history.log.1.gz )
> Im Verdacht steht das Release Upgrade des Coovachilli von Ubuntu 12.04.x
> auf 14.04.x, seitdem habe ich unter Umständen keine Internetseite mehr
Hmm -- hast du das dist-upgrade
An alle Mitdenker.
Seit kurzem - aufgefallen ist es erst gestern - hängt unser WLAN.
Das Netzwerk sieht so aus:
Server lmn 6.1
IPFire Core 97 (auch Core 96 ging nicht)
Coovachilli an Blau des IPFire
Der Fehler äußert sich so:
Die Anmeldung eines WLAN-Clients am Coovachilli-Hotspot funktioniert
20 matches
Mail list logo
