WLAN-Router Problem

[FabiUnne]

achso. Naja, das kannte ich schon aber unter nem anderen Namen
Insgesamt muss ich sagen, dass ich enorm viel über Netzwerk und Sicherheit in den letzten Wochen gelernt habe. Da kanns schonmal vorkommen, dass ich mit manchen Begriffen nichts anzufangen weiß, Ich werde es jetzt probieren.

//edit:
Habe die Config verändert und neugestartet. Nun heißt es abwarten...

hab noch etwas herausgefunden:
1. wenn der Stick mit seiner Aufgabe aufhört, erscheint eine Meldung auf dem Bildschirm, aber nicht im Log.

Code: Alles auswählen

ath: phy0: Unable to remove station entry for:

2. wenn der Stick dann nicht mehr erreichbar war, hab ich ihn herausgezogen und wieder reingesteckt, sodass "auto-hotplug" ihn wieder anschaltet. In dem Moment wenn ich ihn rausziehe, erscheint die Meldung, also ist sie nicht System- sondern User-ausgelöst. Das lässt darauf schließen, dass der Stick immernoch läuft, aber die Arbeit des AP aufgibt. Kann das immer noch am Treiber liegen???

Code: Alles auswählen

ath: phy0: Failed to wakeup in 500us

3. Durch die Configänderung, merkt das Modul, dass es sich in Deutschland befindet, und schreibt sich dann [temporär] auf Deutchland um.

Code: Alles auswählen

Sep 29 11:46:56 kernel: [ 3495.084103] cfg80211: Regulatory domain changed to country: CN
Sep 29 11:46:56 kernel: [ 3495.084108] cfg80211:  (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
Sep 29 11:46:56 kernel: [ 3495.084110] cfg80211:  (2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 2000 mBm)
Sep 29 11:46:56 kernel: [ 3495.084113] cfg80211:  (5735000 KHz - 5835000 KHz @ 40000 KHz), (N/A, 3000 mBm)
Sep 29 11:46:56 kernel: [ 3495.259719] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
Sep 29 11:47:08 kernel: [ 3507.540226] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
Sep 29 11:47:08 kernel: [ 3507.540277] cfg80211: Calling CRDA for country: DE
Sep 29 11:47:08 kernel: [ 3507.588119] cfg80211: Regulatory domain changed to country: DE
Sep 29 11:47:08 kernel: [ 3507.588123] cfg80211:  (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
Sep 29 11:47:08 kernel: [ 3507.588126] cfg80211:  (2400000 KHz - 2483500 KHz @ 40000 KHz), (N/A, 2000 mBm)
Sep 29 11:47:08 kernel: [ 3507.588129] cfg80211:  (5150000 KHz - 5250000 KHz @ 40000 KHz), (N/A, 2000 mBm)
Sep 29 11:47:08 kernel: [ 3507.588131] cfg80211:  (5250000 KHz - 5350000 KHz @ 40000 KHz), (N/A, 2000 mBm)
Sep 29 11:47:08 kernel: [ 3507.588133] cfg80211:  (5470000 KHz - 5725000 KHz @ 40000 KHz), (N/A, 2698 mBm)
Sep 29 11:47:08 kernel: [ 3507.604544] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready

[unitra]

Ich kann mir aber nicht vorstellen, dass mein Problem mit dem Frequenzbereich zusammen hängt, also es an der deutschen Landluft liegt. Außerdem müsste es ja dann eine Regelmäßigkeit geben. Und der Stick sag ja manchmal schon nach 2 Minuten nichts mehr, oder funktioniert 2 Tage ohne Probleme.

Die deutsche Landluft ist nicht der Träger, die Frequenz die von der Regulierungsbehörde festgellegt wurde ist der Träger der Information.

Der Sender sowie der Empfänger oszillieren (vibrieren) auf einer festgellegten Frequenz. Das erzeugt Schwingungen, eine elektro-magnetische Welle. Auf dieser Welle werden Nachrichten moduliert übertragen, mit einem festgellegtem Algorithmus. Es gibt Phasenmodulation, Amplitudenmodulation (AM) und Frequenzmodulation (FM), (AM/FM wie im Radio) , und/oder eine Verbindung aus den dreien und bestimmt noch andere Modulationsarten.

So ungefähr funktioniert die Kommunikation. Dazu ist keine Luft benötigt. Die elektromagnetische Welle ist der Träger.
Bestes Beispiel sind Satelliten die um die Erde kreisen, oder z.B. wenn die NASA Informationen zur ihrer Mars Sonde schickt, und wir schauen uns mal eben im Internet die neuesten Bilder vom Mars an.

[r900]

2. wenn der Stick dann nicht mehr erreichbar war, hab ich ihn herausgezogen und wieder reingesteckt, sodass "auto-hotplug" ihn wieder anschaltet. In dem Moment wenn ich ihn rausziehe, erscheint die Meldung, also ist sie nicht System- sondern User-ausgelöst.
[...]

Code: Alles auswählen

ath: phy0: Failed to wakeup in 500us

Aha, dann sind also die bisherigen Fehlermeldungen auf das Abziehen des Sticks zurückzuführen und haben somit nichts mit dem eigentlichen Problem zu tun.

Falls das Problem weiterhin besteht solltest du als nächstes mal deine hostapd-Konfiguration posten und selbigen mit den Optionen "-d -v" starten. Damit läuft er im Vordergrund und Fehlermeldungen werden direkt auf dem Terminal ausgegeben. Außerdem wird er so gesprächiger.

[catdog2]

2. wenn der Stick dann nicht mehr erreichbar war, hab ich ihn herausgezogen und wieder reingesteckt, sodass "auto-hotplug" ihn wieder anschaltet. In dem Moment wenn ich ihn rausziehe, erscheint die Meldung, also ist sie nicht System- sondern User-ausgelöst. Das lässt darauf schließen, dass der Stick immernoch läuft, aber die Arbeit des AP aufgibt. Kann das immer noch am Treiber

Code: Alles auswählen

ath: phy0: Failed to wakeup in 500us

Das ist aber eine zentrale Information. Bisher ging zumindest ich davon aus, dass der Stick hier komplett verreckt und sich neu am USB Controller anmeldet oder ähnliches (Vieleicht auch weil die V2 dieses Teils genau dieses Problem hat aber da ist auch ein anderer Chip drin ).

hab noch etwas herausgefunden:
1. wenn der Stick mit seiner Aufgabe aufhört, erscheint eine Meldung auf dem Bildschirm, aber nicht im Log.

Code: Alles auswählen

ath: phy0: Unable to remove station entry for:

Hmm das klingt irgendwie nach einem Bug im Treiber oder im hostapd. Schön wäre da natürlich, wenn man das irgendwie reproduzieren könnte.

edit://
Achja so nebenbei weil ich das grad sehe: Es gehen nur 8 Stations mit dem Teil (https://lists.ath9k.org/pipermail/ath9k ... 09474.html ff.)

On 10 August 2012 08:23, twebb <taliaferro62 at gmail.com> wrote:
> I see in htc.h the definition for ATH9K_HTC_MAX_STA is 8. Is this
> limitation imposed in the htc_9271.fw firmware? If so, are there any
> plans for new firmware that would support more stations? Is there any
> way to increase the number of stations supported by the htc_9271.fw in
> AP mode? I am looking to use this chipset in an implementation that
> requires 250 clients/stations.
>
> Also, does anyone know the reasons behind the current limit of 8?

The platform is memory limited and I think it's mostly intended as a
station device.

My invitation is still there - sign up for an open source NDA, work
with us to get firmware source and start improving the ath9k_htc
firmware.

Adrian

Meine Rede…

[FabiUnne]

Falls das Problem weiterhin besteht solltest du als nächstes mal deine hostapd-Konfiguration posten und selbigen mit den Optionen "-d -v" starten. Damit läuft er im Vordergrund und Fehlermeldungen werden direkt auf dem Terminal ausgegeben. Außerdem wird er so gesprächiger.

Und es ist wieder vorgekommen.
Mein Config:
http://pastebin.com/pzYLPxNe

Der Debug.log von hostapd vom Start bis zum Absturz:
http://pastebin.com/jqaLSkpQ

[r900]

In deiner Konfiguration setzt du die maximale Anzahl an clients auf 150.

Achja so nebenbei weil ich das grad sehe: Es gehen nur 8 Stations mit dem Teil (https://lists.ath9k.org/pipermail/ath9k ... 09474.html ff.)

Schon mal in diese Richtung überlegt?

[FabiUnne]

klar, wobei das bei mir nicht zutrifft. Habe in der Config nur 150 stehen, weil ich zwei WLAN-Drucker und 148 DHCP-Clients von dhcpd seitends einbinden kann. Außerdem meine ich, dass dieses Problem sogar schon gefixt wurde. Werde es mal im Log überprüfen.
Du sagst ja, der Stick könnte nur max 8 Clients (Stations) einbinden. Aber dann dürfte er, wenn die zahl überschritten wird, nicht einfach aus gehen, sondern müsste der Zugang einfach verweigern. Also kanns daran eigentlich cniht liegen.

Habe in der zwischen Zeit mir ein bisschen die Log durch geschaut. Unter anderem habe ich gemerkt, dass alle 10 Minuten die Clients die Lease-Time aktuallisieren wollen. Das steht jetzt auf zwei Stunden.
Außerdem habe ich die Inaktivitätszeit von hostapd zu den Clients auf einen Tag gestellt, denn nur weil die Verbindung mal kurz nicht genutzt wird, soll die Verbindung nicht gleich geclosed werden. Und ich glaube hier liegt auch mein Problem. Denn Windows kommt mit der Verbindungsunterbrechung nicht zu recht und zeigt den AP nicht mehr an, während Ubuntu(Netbook) den AP zwar noch anzeigt, sich aber nicht mehr verbinden kann, was glaub ich auch an der noch existieren Leasetime liegt.
Dann habe ich getestet, ob der AP vielleicht kein unregelmäßigen Verbindung mag. Also habe ich eine regelmäßige PING Anfrage gestartet, während mein Windowsclient mit dem AP verbunden ist.
Der AP hat eine grüne Statuslampe, an der man erkennt, ob der AP funktioniert, oder nicht. Immer wenn damals Windows den AP nicht mehr erkannt hat, leuchtete aber die Lampe noch, also der Stick war gar nicht abgestürtzt. Er sendete gar nichts mehr.

Also stehe ich mitlerweile vor zwei Problemen:
1. Der AP bricht manchmal eine laufende offensichtlich unregelmäßige Verbindung ab, ist aber dennoch laut Kernel nicht abgestürtzt
2. Der AP bricht manchmal die komplette Verbindung ab, blockiert den Treiber und stürtzt ab. Dieses Problem kann ich nur mit einem Warmstart lösen, den bei den Comand "reboot" blockiert apache, oder auch bind9 (warum auch immer) den Stop-Prozess mit den Worten "task blocked more than 120 seconds". Zusätzlich erscheit bei einem Komplettabsturz die wiederkehrende Message: "ath: phy0: Unable to remove station entry for <mac_addr>".

Bei Probleme kann ich bis jetzt nicht erklären. Beim ersten Problem reicht ein ganz einfaches "ifdown; ifup" bei dem zweiten Problem muss erst ein mechanischer Warmstart gemacht werden.

Ich hoffe, dass euch die Infos weiterhelfen. Die Frage ist, wo ich suchen soll. Am der Stick-Hardware kanns eig nciht liegen, denn dafür gibts keine Anzeichen. Hostapd selbst lässt auch nichts im Debug darüber verlauten. Also bleibt noch Firmware und Modul. Hat das Modul eigentlich eine Config??? Die Firmware habe ich geupdatet, aber ohne Erfolg. Für das Modul gibts keine Updates, auf jeden Fall kein offiziellen.

//edit: Könnte es sein, dass der AP bei zu viel Traffic abstürtzt? Wollte nämlich gerade online zocken und sobald TS und Game Packete am senden waren. Stürtzte der AP innerhalb von Sekunden erst nach Problem 1 und dann auch nach Problem 2 ab.

[r900]

Du sagst ja, der Stick könnte nur max 8 Clients (Stations) einbinden. Aber dann dürfte er, wenn die zahl überschritten wird, nicht einfach aus gehen, sondern müsste der Zugang einfach verweigern. Also kanns daran eigentlich cniht liegen.

Das war nicht ich sondern catdog2. Und wie ich die Nachrichten in der verlinkten mailing list verstehe ist das eine Limitierung in der Firmware, also nichts was auf Treiberseite gelöst werden könnte. Wenn der hostapd denkt er könnte 150 clients bedienen, die Hardware aber auf 8 beschränkt ist könnte ich mir das schon als mögliche Fehlerquelle vorstellen. Was spricht denn dagegen die Zahl einfach mal auf 8 zu ändern?

Was das andere angeht bin ich etwas überfragt. Geht das log eigentlich bis zum Beenden von hostapd oder nur bis zu dem Zeitpunkt wo er den Dienst verweigert? Ich frage wegen dieser Zeilen:

Code: Alles auswählen

1348939001.298950: Signal 2 received - terminating
1348939001.299001: 1348939001.299014: 1348939001.299040: wpa_driver_nl80211_set_key: ifindex=3 alg=0 addr=0x2397220 key_idx=0 set_tx=1 seq_len=0 key_len=0
1348939001.299064:    addr=5c:ac:4c:10:09:1a
1348939008.969177: Removing station 5c:ac:4c:10:09:1a
1348939008.969209: wlan0: AP-STA-DISCONNECTED 5c:ac:4c:10:09:1a
1348939034.969305: eloop: could not process SIGINT or SIGTERM in two seconds. Looks like there
is a bug that ends up in a busy loop that prevents clean shutdown.
Killing program forcefully.

Also ist das "Signal 2 received - terminating" durch dich hervorgerufen? Zu der letzten Meldung findet sich hier etwas: http://lists.shmoo.com/pipermail/hostap ... 25097.html Also eventuell doch ein bug in hostapd?

For the last several weeks, I've been troubleshooting a problem with hostapd-0.7.3 where it gets stuck somewhere in the event loop and clients are no longer able to connect to the AP until I kill and restart hostapd.

[FabiUnne]

hostapd hat seinen Dienst aufgegeben, und danach habe ich den kill ausgeführt.

Zum maxClient-Problem:
Ich werde die Config mal so abändern, dass maxClient auf 8 steht, doch:
1. wenns mal vorkommen sollte, dass alle Clients, die den Schlüssel des APs kennen, sich mit ihm verbinden komme ich aber trotzdem auf 7 Clients und nicht 8.
2. gilt eine Scan-Anfrage eines nicht autorisierten Clients auch als Verbindung? Eigentlich doch nicht.
3. Müsste hostapd dann nicht von Anfang an von der Firmware gesagt bekommen, dass diese nur 8 Clients bedienen kann?
4. Welches Modul lässt hostapd eigentlich auf die Firmware zugreifen?
5. die Mailinglist bezieht sich auf die htc_9271.fw Firmware, welche Version auch immer. Ich verwende aber die htc_9270.fw Firmware, Version 1.3.

Was mir noch aufgefallen ist:
Wenn der AP mal wieder offline geht. Habe ich erst versucht über die Comands "ifdown: ifup" das wlan0 neuzustarten. Da ifup durch das Modul blockiert wird, habe ich spontan den Stick vom Server getrennt. Das Kommando wurde bis zum ende ausgeführt, ausgegeben wurde:

Code: Alles auswählen

ath: phy0: Unable to remove station entry for: <mac_addr>

Nachdem der Stick physisch getrennt und wieder angeschlossen wurde, funktionierte wieder alle, wie es sollte.

Also stellt sich doch die Frage, warum ath ein Remove eines Client auslöst, dabei versagt und abstürtzt.
Ich meine, dass das mein Problem ist. Demnach liegt das Problem weder am Dient, noch an der Firmware, sondern am Modul.

//edit:
btw: ich verwende die hostapd-Release 1.0

[FabiUnne]

Nach kurzer google-Suche: probier mal das Modul ath9k_htc zu entladen und dann mit der Option "nohwcrypt=1" zu laden.

Hab das nochmals überprüft und dabei gemerkt, das Debian die option statt beim _htc, beim reinen ath9k eingefügt hat. Und du hast recht, laut Google müsste es daran liegen. Das würde auch erklären, warum sich immer noch das ath Modul einmischt. Werde es mal morgen auf ein paar Verbindungen testen. Weiter werde ich auch mal versuchen mehr als 8 Connections zu realisieren.

1. Gibts eigentlich ne Liste von Moduloptinen?
2. Was bedeutet jetzt "nohwcrypt=1" im Klartext?

[catdog2]

2. Was bedeutet jetzt "nohwcrypt=1" im Klartext?

Naja dann wird die Verschlüsselung halt in der CPU gerechnet.

1. Gibts eigentlich ne Liste von Moduloptinen?

Code: Alles auswählen

modinfo modulname

Das würde auch erklären, warum sich immer noch das ath Modul einmischt.

Nö ath9k_htc hängt davon ab. Die ath* Treiber teilen einiges an Code.

Hab das nochmals überprüft und dabei gemerkt, das Debian die option statt beim _htc, beim reinen ath9k eingefügt hat.

Na dann wirkts natürlich nicht.

[FabiUnne]

2. Was bedeutet jetzt "nohwcrypt=1" im Klartext?

Naja dann wird die Verschlüsselung halt in der CPU gerechnet.

Joar, das ist mir shcon klar, aber welche Verschlüsselung, die des Netzwerks doch wohl nciht.

Das würde auch erklären, warum sich immer noch das ath Modul einmischt.

Nö ath9k_htc hängt davon ab. Die ath* Treiber teilen einiges an Code.

Ja, aber phy0 wird von ath9k_htc gesteuert, also "ath: phy0: " würde dann ja soviel heißen, wie:

unable to remove station entry
-> wird ausgelöst von "phy0"
-> wird gesteuert von "ath9k_htc"
-> hängt ab von "ath9k"
-> hängt ab von "ath"

Oder nicht?

[FabiUnne]

also ich glaube Problem 1 (siehe älteren Post) konnte ich mit nohwcrypt lösen.
Aber der Stick stürzt immer noch ab und langsam frage ich mich, obs nicht doch an der Hardware liegt, wobei ich immer noch von einem Softwareproblem ausgehe.

Zwischenzeitlich kam mir die Idee, dass der Stick, wenn ein ganz bestimmter Client connected, aufhört zu arbeiten. Konnte ich aber bis jetzt noch nicht festigen.

Ansonsten erscheint neben dem bekannten "Unable to remove station entry" jetzt auch noch die Meldung

Code: Alles auswählen

dma out of sw-iommu space[code], warum wieso weiß ich cniht, nur, dass diese Meldung wenn sie kommt ununterbrochen geprintet wird.

Sonst noch irgendjemand ne Idee dazu?
"Unable to remove station entry" muss ja von irgendwas ausgelöst werden, also
-> irgendwas läuft schief
--> die Clients werden removed
----> beim removen tritt ein Fehler auf

aber wieso läuft etwas schief???
Außerdem weiß ich wie geschrieben nichts mit der "neuen" Fehlermeldung anzufangen.

[FabiUnne]

so habe mir die Logs nochmals angesehen.

Code: Alles auswählen

ieee 802.11 deauthenticated due to local deauth request

Diese Meldung taucht nach ner Weile im Debug von hostapd auf und ist glaub ich auch das Problem.
Zu diesem Print habe ich nen Foreneintrag gefunden.
http://forum.ubuntuusers.de/topic/iphon ... cesspoint/
Jedoch lag es nicht an meiner in der Config angegebenen Verschlüsselung, die handshake-runtime hab ich aber angepasst. Im Moment kommt das Problem aber wieder. Was ich aber jetzt weiß ist, dass es mit der Verschlüsselung der Packete zu tun hat, also kann ich jetzt die Frage beantworten:

Code: Alles auswählen

ath: phy0: Unable to remove station entry for: <mac_addr>

Also stellt sich doch die Frage, warum ath ein Remove eines Client auslöst, dabei versagt und abstürtzt.

Das ist jetzt sehr theoretisch, aber ich versuchs mal zu formulieren:
hostapd setzt einen Monitor-Interface auf, dieses bekommt ein Problem beim Encrypten/Decrypten des 10 Minütigen Handshakes mit und stürtzt ab. Hostapd bemerkt dies, kann nicht mehr richtig arbeiten und beginnt alle Clients zu disconneten, was aber ohne den Monitor nicht geht. So hängt sich das ganze Interface auf. Und wenn man den Stick jetzt wieder reconnectet, wird ein frisches Interface (phyX) aufgesetzt, welches von hostapd erkannt wird und initialisiert wird.

Diesen Fehler kann man mit "nohwcrypt" umgehen, da dann das Crypting nicht mehr vom Interface, sondern vom kernel übernommen wird und der Stick weniger zu tun hat. Desweiteren könnte man den handshake auf 2 Stunden setzen, was ich aber auch gemacht hab. Man könnte den auth_algs runtersetzen.

Habe einen Bugreport zu dem hostapd-code gefunden: https://dev.openwrt.org/ticket/10311. Aber damit konte ich irgendwie nichts anfangen.

Also ist mein Problem ententlich die Verschlüsselung, also die Sicherheit, die das Modul nur verbuggt anbieten kann?!? Wie wäre es mit einem anderen Modul???

//edit:
Demnach würde aber eine Karte zum gleichen Problem führen.

[FabiUnne]

könnte es sein, dass der fehlerhafte Handshake gar nicht von hostapd sondern von meinem dhcp-Server ausgelöst wird??? Als ich nämlich meinen Server nach dem Absturz rebooten wollten, wurde ein Error beim dhcp-Server geprinted. Später habe ich durch probieren herausbekommen, dass der DHCP-Server beim Wlan-Absturz gar nicht mehr aktiv war, bzw. das ganze Network-Interface zum Absturz gebracht hat, demnach sind auch die Fehler von SSH, apache, usw. einleuchtend.

Werde es heute Nachmittag mal bei statischen IPs und ohne dhcp probieren.

Jaa, nach 40 Posts komm ich der Lösung doch recht nahe.

[FabiUnne]

auch wenn mir dieser Thread immer weiter als Tagebuch vorkommt, werde ich weiter schreiben.

Weder hat das Ausschalten des dhcp-Servers etwas gebracht, noch konnte ich ein vergleichbares Modul für ath9k_htc finden. Aber es erscheinen keine neuen Fehlermeldungen mehr, also kam ich jetzt endlich damit beginnen, das Gesamtbild zu analysieren:

Ich habe bemerkt, das der dhcp-Server immer mal wieder versucht hat, "mon.wlan0" eine IP zuzuweisen, dies habe ich umgangen, indem ich dhcpd anweise, nur auf wlan0 zu hören. Btw, könnte mir jemand ne kurze Erklärung zu diesem komischen Monitor posten???
Eine Liste der Fehler und Logs folgt noch.
Was ich auch, nachdem der Client (komischerweise immer abends) nochmals abgestürzt war, getan habe, ist alles was nicht auf dem erste Blick wichtig aussieht, in der hostapd.conf auszukommentieren. Bis jetzt läufts mit der Config ganz gut. Nu hab ich dazu die Theorie, es würde am enable vom 802.11n liegen. Das wäre aber vom Standard her nicht das, was ich erwarte, womit wir beim Problem Stick wären. Aber ich könnte das Problem auf hostapd und der Hardware eingrenzen.
Kann es sein, dass es trotz des gleichen Modulcodes, einen Unterschied macht, ob ich jetzt die Hardware im Stick per USB betreibe, oder mir ne Karte per PCI hole??? Naja, außer, dass PCI mehr I/O hat, arbeiten beide Hardware ja gleich.

Auch wenn ich das mit den 8 Stations immer noch nicht glauben mag, gibt es den eine Karte, die meinen Anforderungen entspricht und mind. 16 Clients bedienen kann?

[wanne]

Ich weiß nicht, in der Anfangszeit war es schwer Treber zu finden, die auch mit USB-Wlans konnten. Insofern glaube ich schon das es was aus macht, wie das Ding angeschlossen ist.
Zur Karte kann ich sagen dass die reichweite mit ner ordentlichen Antenne wesentlich weiter ist als mit nem Stick. (Für mich immer der Grund für sowas.) (Karten haben die Anenne eigentlich immer außerhalb des Gehäuses. So ein Stahlgehäuse müste ja wirklich nahezu perfekt abschirmen.) Mit ner schönen Antenne kann man die ganze Nachbarschaft legal mit WLAN versorgen. Geht aber natürlich auch mit USB-Sticks mit externem Antennenanschluss.
An hostapd selbst kann es eigentlich nicht liegen. (Hier läuft der nähmlich perfekt. Allerdings nur mit 3 Clients) Wenn an dem Treiber oder noch eher an der fw.
Zum Stromversorgungsproblem: Ich würde einfach mal testen ob's an nem modernen Rechner funktioniert. (Die lassen im Normalfall wesentlich mehr Strom zu.)
Zu dhcpclient Warum läuft daüberhaupt ein DHCP-Client? Da brauchst du doch eigentlich nur nen dhcpd.
Leider kann ich auf deine Pastebin-Links nicht drücken.

Wenn ich mir den Log anschaue: Der AP läuft ne halbe Stunde dann kommt ein Client abhanden. Und hostapd schmiert ab. Kannst du mal probieren ob du den Absturz reproduzieren kannst, indem du bei nem Client einfach den Wlan-Stick ziehst?
Und kannst du mal posten, was der hostapd meldet, wenn du die Crypto auf dem Stick machen lässt?

[FabiUnne]

es gibt nur einen einzigen Client mit WLan-Stick, bei dem werde ich es noch probieren. Aber das würde ja hostapd nicht stören, wenn da mal ein Client out-timed. Es gibt keine Regelmäßigkeit, wobei ich jetzt noch keine Perioden zum Zeitpunkt des Absturzes feststellen konnte. Das einzige was regelmäßig ist, ist die Kommunikation mit dhcpd und den Handshakes von hostapd. Eine andere Regelmäßigkeit gibt es nicht.

Was mir noch aufgefallen ist: wenn der AP den Dienst aufgibt, zeigt hostapd keinerlei Error über die Inaktivität seinerseits an. Erst wenn man ihn versucht neuzustarten, kann er kein AP auf das geladene Modul "ath9k_htc" aufsetzen. Ich habe probiert, nach einem Absturtz das Modul zuendladen - ohne Erfolg, die Shell hing sich komplett auf, und reagierte erst wieder, als ich den Stick gezogen hab:

Bildschirmmeldung:

Code: Alles auswählen

ath: phy0: Unable to remove interface at idx: 0
ath: phy0: Chip reset failed
ath: phy0: Unable to reset hardware: rest status -22 (freq 2417 MHz)
ath: phy0: Failed to wakeup in 500us
usb 1-1.2: ath9k_htc: USB reboot failed

Das sagt mir, dass sich das Modul selbst aufgehangen hat, also "ath9k_htc". Der Grund könnte eigentlich nur Überlastung sein.

Wenn das Modul abstürzt kann den Clients ja nicht mehr begebracht werden, dass der AP nicht mehr existiert. Hier kommt die Fehlermeldung ins Spiel:

Code: Alles auswählen

Unable to remove station entry for: <mac-addr>

Hostad möchte etwas entfernen, was gar nicht mehr existiert.

Desweiteren ist mir aufgefallen, dass nur Cients, die neu connecten und Handshake und Lease durchlaufen, den Stick zum Absturtz bringen können. Nur selten kommt es vor, dass der Stick die laufende Übertragung abbricht,

Heute ist der Stick NUR einmal abgestürzt (Grund noch unbekannt), was an der geänderten Config liegen kann. Ich habe den Draft-N Modus deaktiviert, offensichtlich hat dieser Modus das Modul überlastet. Dies ist vorerst meine Lösung. Werde jetzt ein bisschen testen, bevor ich den Status entgültig auf gelöst setze.
Ich möchte mich bei allen bedanken, die mich in 43 Beträgen begleitet haben

Um nochmal auf meinen allerersten Post zu antworten:
"Failed to wakeup in 500us" bedeutet nicht anderes als: "Stick antwortet nicht mehr auf Anfragen: Er wurde vom Server getrennt." Dieser Fehler wird normal vom user ausgelöst, wenn er unerwartet den Stick entfernt. Es hat nicht damit zu tun, dass der Stick zu wenig Strom bekommt.

[wanne]

es gibt nur einen einzigen Client mit WLan-Stick, bei dem werde ich es noch probieren. Aber das würde ja hostapd nicht stören, wenn da mal ein Client out-timed.

Im Log tauchen 4 Clients auf:

• AID 1: 00:26:bb:da:9d:fa
• AID 2: 00:20:00:6a:5a:78
• AID 3: 38:59:f9:56:f8:86
• AID 4: 5c:ac:4c:10:09:1a

Im log hat 00:20:00:6a:5a:78 einen Timeout (150sec bevor der AP abkratzt.) Das ist zwar ne ganze Weile vorher aber es kommt eben in der Halben stunde davor nie vor.
PS: Hast du eigentlich Strg+C gedrückt nachdem nichts mehr funktioniert hat?

[FabiUnne]

*lach* willst du etwa damit damit sagen, dass der Drucker (00:20:00:6a:5a:78) das WLAN zum absturtz bringt??? Das kann sogar sein, weil der Drucker ja immer erreichbar sein muss. Also meinst du, dass der Drucker die Verbindung unterbricht, aber dem AP nichts davon sagt - das AP dann irgentwann mitbekommt, dass der Drucker nen timeout hat - aber sich in der Zeit der Drucker wieder einwählen will? Rein logisch würde es passen.

Hast du eigentlich Strg+C gedrückt nachdem nichts mehr funktioniert hat?

Naja, welchen Fehler meinst du jetzt. Hostapd selbst läuft als Daemon, als ich gedebugt habe, reagierte hostapd nicht mehr auf Strg+C. Ansonsten habe ich auch Strg+C gedrückt, wenn die Meldung "Unable to remove station entry for" erschiien.

Aber dann würde es ja nicht am Draft-N Modus liegen, was mich sehr freuen würde. Wie könnte man denn den Timeout unterbinden???

Bis jetzt ist der AP noch nicht abgestürtzt, letzer Neustart gestern um 23 Uhr etwa.

[wanne]

willst du etwa damit damit sagen, dass der Drucker (00:20:00:6a:5a:78) das WLAN zum absturtz bringt???

Mehr der Auslöser als die Ursache aber ich finde es halt schon erstaunlich dass sich zuerst der rucker nicht mehr meldet und dann das WLAN abstürzt.

Wie könnte man denn den Timeout unterbinden???

Da der Drucker sich ja vermutlich nicht einfach so aus dem Empfangsberreich bewegt sollte es eigentlich gar keine Timeouts geben...
Aber wenn sich das Problem wirklich darauf einkrenzenl lässt kann man ja vielleicht einen Bugreport schreiben, der dann dazu führ, das das Problem behoben wird. AP darf ja nicht abkrazen, wenn sich ein Clein nicht mehr meldet...

[FabiUnne]

naja, ich kann mir schon vorstellen, dass es am Drucker liegen könnte.
1. nach jedem Neustart war der Drucker der erste, der sich eingewählt hat -> stetige Verbindung
2. hatte schon vor meiner Aktion Probleme mit meinem Drucker -> er war manchmal nicht erreichbar

Also nochmal - der Drucker bricht ohne Ankündigung die Verbindung ab - der AP bemerkt nicht davon. Soweit so gut...
Jetzt kommen die 150 Sekunden ins Spiel: nahc 150 Sekunden versucht der Drucker einen neuen Handshake zu machen - der AP bemerkt die für ihn noch existierende Verbindung und blockiert die Neuanfragen - das passt dem Drucker aber nicht und er versuchts weitere Male...
So ungefähr wie eine DDOS-Attacke. Bis dann irgendwann der AP überlastet und das Modul sich aufhängt.

Heute hing sich der AP nochmals auf und diesmal habe ich erst den Drucker heruntergefahren, dann den Server neugestartet und dann erst den Drucker gestartet. Bis jetzt läuft alles. Aber dann könnte es auch sein, dass es nicht am Drucker liegt, sondern an hostapd, den hostapd müsste einen Timeout bemerken. In der Config sehe ich zwie Attribute:
"ap_max_inactivity" und "wpa_group_rekey" - habe beides auf 2 Stunden gestellt, damit nicht alle 5 Minuten ein Handshake mit allen Clients (Drucker, Handy, Konsolen) gemacht wird.