WiFi & PFsense - Fakten und Erfahrungen
-
Hallo,
in den System logs General taucht sehr oft folgender Fehler auf:ath0: stuck beacon; resetting (bmiss count 4)
Ich benutze die WLAN Card Compex WLE200NX.
Kennt jemand das Problem?
Gruß
Peter -
Ja! Das selbe habe ich auch mit WLE200NX.
Tut dem allerdings nichts ab da WLAN ohne Probleme funktioniert.Hoffe das es mit FreeBSD 10 als Basis in der 2.2 Version besser und schneller wird (WLAN-N)
-
Hallo BeNe,
naja, die Log Protokolle laufen voll.
Außerdem ist es ja trotzdem ein Fehler.Der Hinweis von @Anaximelis auf Seite 3 brachte bei meiner Config nichts.
Die Fehlermeldung tritt dennoch auf.Irgendwie habe ich das Gefühl, dass das APU Board zusammen mit pfSense keine gute Wahl ist.
Mit meinem ALIX Board gibt es überhaupt keine Probleme.Gruß
Peter -
ath0: stuck beacon; resetting (bmiss count 4)
…
Außerdem ist es ja trotzdem ein Fehler.Das ist kein Fehler, sondern eine Warning/Info, ansonsten würde fett davor stehen ERROR.
Ggf. muss man nach den Änderungen von Anaxi nochmal das komplette System durchbooten.Irgendwie habe ich das Gefühl, dass das APU Board zusammen mit pfSense keine gute Wahl ist.
Sorry, aber das ist Unsinn. pcEngines ist schon lange nicht nur unterstützte Plattform, sondern auch immer gern mit Vorserienmodellen am Start gewesen (WRAP, ALIX, APU) und hat mit den entsprechenden Projekten / OSen zusammengearbeitet. Wir hauen die APUs gerade auch bei Kundeninstallationen im Dutzend ohne Probleme raus, allerdings brauchen wir keine (m)SSD, ist unnötig. Bei uns läuft dafür das System von der SD Karte trotzdem recht flott, und so es einmal ordentlich läuft gibt es mit externem Logging kaum mehr Grund an den Einstellungen zu schrauben (Performance SSD/SD daher für uns an der Stelle vernachlässigbar).
Dass WLAN mit pfSense generell ein heikles Thema ist, weiß man - sofern man sich im Forum ein wenig umgeschaut hat - auch schon länger, nicht nur Treiber und OS Basis sind da eben nicht gerade auf dem aktuellsten Stand. Gerade deshalb sind einige bereits dabei - auch mit APUs - den 2.2er Snapshot zu testen um auch die neuen WiFi Treiber zu testen.
An deinen Erfahrungen mit der APU wundert mich allerdings die Herangehensweise - bitte nicht persönlich nehmen - aber schon: wenn du so viel schon mit ALIX Boards gemacht hast, sollte doch eigentlich klar sein, dass eine ALIX, APU o.ä. eben via serielle Console befüttert wird und dementsprechend KEIN Standardsystem, sondern ein embedded Device ist und eben auch der embedded Kernel genutzt werden sollte. Fehler der WLAN Karte oder Probleme bei der Installation, die du selbst verursachst dann aber auf die APU zu projezieren ist der Hardware ein wenig unfair gegenüber.
Zudem sollte man sich vor Augen halten, dass die APU auch als OFFIZIELLES Produkt des pfSense Teams erhältlich ist und somit auch Hardwareseitig definitiv unterstützt wird.
Siehe: http://store.pfsense.org/VK-2D13/ (ALIX), http://store.pfsense.org/VK-T40E/ (APU)Ich kann dich also insofern beruhigen, dass - sollte es generelle Probleme mit APUs geben - das definitiv bekannt wäre bzw. abgeschafft würde, da das Team die Dinger offiziell mit Support/Gold Sub selbst vertreibt und damit berechtigtes Eigeninteresse hat, dass die Kisten funktionieren.
Grüße
-
Hallo JeGr,
danke für Deine Ausführungen.Nun, ich nehme grundsätzlich nichts persönlich, solange ich nicht mit unsachlichen Argumenten "erschlagen" werden soll ;-))
Das bezüglich des APU Boards und pfSense von mir Geschriebenen, war/ist mein persönlicher Eindruck und bezog sich auch nur
auf meine Sichtweise.Es sollte in keiner Weise dazu führen, irgendetwas "im schlechten Licht" erscheinen zu lassen.
Das APU Board habe ich mir aus reinem Interesse für private Zwecke gekauft und hatte keine Erfahrungen damit.
Deshalb ging die Installation doch etwas "hölzern" vonstatten.Mir war wirklich nicht klar, dass wenn ich im Downloadcenter das entsprechende pfSense Image File mit der Option Serial auswähle,
dann trotzdem extra "Embedded" auswählen muss.
Das ist bei den ALIX Bords nicht so. Dort nehme ich das entsprechende Image File für CF Karten und das funktioniert dann ohne nochmals
"Embedded" auszuwählen.Ansonsten setze ich pfSense schon seit einigen Jahren in verschiedenen Umgebungen (VM's, IBM Server, ALIX etc.) ein.
Naja, egal. Auf jedem Fall wieder was dazu gelernt!
Die Problematik bezüglich WLAN Unterstützung war mir schon klar. Dennoch hatte ich bis jetzt keine Probleme damit.
Ich bin jetzt leider auch nicht der FreeBSD Profi und deshalb kann ich manches nicht so richtig zuordnen.
Dafür habe ich mich aber hier im Forum angemeldet und freue mich über die vielen Hinweise!!!Gruß
Peter -
Ahoi,
Nun, ich nehme grundsätzlich nichts persönlich, solange ich nicht mit unsachlichen Argumenten "erschlagen" werden soll ;-))
Niemals ;)
Es sollte in keiner Weise dazu führen, irgendetwas "im schlechten Licht" erscheinen zu lassen.
So kam es auch nicht an, aber du bist schon der zweite oder dritte Poster (im englischen Forenteil ebenso), von dem ich nach ein paar Problemen lese, dass sie die APU wieder verkaufen weil sie - angeblich - nicht funktioniert etc. und ich denke mit etwas Reinknien wird sie nicht nur funktionieren, sondern man selbst hat auch eine Ecke dazugelernt :)
Deshalb ging die Installation doch etwas "hölzern" vonstatten.
Das kenne ich noch gut von meinem ersten WRAP und Soekris Board :)
Mir war wirklich nicht klar, dass wenn ich im Downloadcenter das entsprechende pfSense Image File mit der Option Serial auswähle, dann trotzdem extra "Embedded" auswählen muss.
Guter Punkt, das neue Downloadmenü ist mitunter wirklich etwas verstrickt, aber man muss sich dann wohl genau vor Augen halten, was man für ein Gerät bespielen will (ich hatte auch schon meine Probleme mit der Auswahl) ;)
Die Problematik bezüglich WLAN Unterstützung war mir schon klar. Dennoch hatte ich bis jetzt keine Probleme damit.
Gut für dich (das ist mein Ernst), ich hatte meine Versuche mit Winstrom-CM9ern und einem Soekris 5500er Board und das WLAN war - naja lassen wir das ;) Hat zumindest nicht in dem Maße funktioniert und bringt eben nicht die Leistung was man momentan im WiFi Wettrüsten erwartet (mindestens eben -n Standard oder sogar -ac). Aber die Hoffnung liegt hier bei pfSense 2.2 und FreeBSD >=10
Ich bin jetzt leider auch nicht der FreeBSD Profi und deshalb kann ich manches nicht so richtig zuordnen.
Dafür habe ich mich aber hier im Forum angemeldet und freue mich über die vielen Hinweise!!!Meine aktive BSD Zeit liegt auch etwas zurück (und da wars OpenBSD). Und viele Aspekte der pfSense habe ich oder wir auch nicht im Einsatz (Squid, Snort, etc.) so dass ich da leider auch nicht wirklich was zu sagen oder große Hilfe anbieten kann, aber ich versuche mein Bestes :)
Was momentan noch auf meiner Nachfragen Liste zur APU steht, ist bspw. warum es wohl manche Geräte gibt, bei denen die Front LEDs funktionieren und gesteuert werden können und manche nicht (ich vermute hier die Netgate Geräte und Unterstützung von pfSense direkt). Daraus hoffe ich, dass wir vllt. bald noch - ähnlich den NanoBSD CF Images - welche für die APU direkt bekommen können/werden, die bessere Out-of-the-Box Unterstützung bieten.
Grüße
Jens -
Hallo,
in den System logs General taucht sehr oft folgender Fehler auf:ath0: stuck beacon; resetting (bmiss count 4)
Ich benutze die WLAN Card Compex WLE200NX.
Kennt jemand das Problem?
Gruß
PeterHabe im 2.2er Forum was dazu gelesen –> https://forum.pfsense.org/index.php?topic=79827.msg442014#msg442014
Konnte es aber leider bisher noch nicht versuchen. -
Hallo,
ja danke.
Das habe ich bereits probiert.
Leider hat es nichts gebracht.
die Meldungen sind immer noch vorhanden.Gruß
Peter -
Dazu auch ein Erfahrungsbericht von mir:
Ich nutze APU.1C seit einigen Wochen. Bisher ohne diese Meldung. Nun bin ich in eine neue Wohnung umgezogen.
In der alten Wohnung gab es maximal 1-2 WLAN in Reichweite, die physikalisch Einfluss hatten. Damit meine ich: Es gab ein WLAN im gleichen Haus das meine Clients und die pfsense gesehen haben und das ich bei Bedarf auch nutzen konnte (vom Vermieter) und maximal ein WLAN vom Nachbar, dessen WLAN ich nicht mal mehr mit irgendwelche Diagnosetools sehen konnte, aber allerhöchstens noch ein paar Funkfragmente ankamen. Auf dem Land ist das noch so und "ath0: stuck beacon; resetting (bmiss count 4)" war mir deshalb unbekannt.
In der neuen Wohnung sehe ich mit jedem Client 3 Netze und es gibt sicher noch einige mehr, die Funkfragmente streuen, die ich aber mit Diagnosetools nicht mehr als WLAN erkennen kann. Seitdem ich hier wohne, spuckt die pfsense "ath0: stuck beacon; resetting (bmiss count 4)" am laufenden Band.
In der alten Wohnung konnte ich die pfsense stabil mit WLAN betreiben. In der neuen Wohnung hab ich das bisher noch nicht hinbekommen… Ich hoffe, dass 2.2 bald raus ist und einige Verbesserungen in Sachen WiFi mit Atheros Karten mitbringt.
-
Noch einen Kommentar zu den Stuck Beacons:
https://forum.pfsense.org/index.php?topic=79827.0
Habt ihr das dort vorgeschlagene bereits ausprobiert? (System tunables etc.)?
Ansonsten ist das Ganze leider generell kein oder nur ein marginales pfSense und erst gar kein APU Problem ;) denn das Ganze klemmt stark an den Treibern (FreeBSD) und an der WiFi Unterstützung bzgl. Linux/BSD generell.
(siehe http://madwifi-project.org/wiki/StuckBeacon)Wir können da gern über das Wifi Problem weiterdiskutieren, allerdings würde ich dann die Topics hier raus abspalten, da es nichts mehr mit der APU direkt zu tun hat.
Grüße
Jens -
Hallo,
ja, wäre nicht schlecht, wenn dafür ein neuer Beitrag eröffnet wird.Bei mir haben die u. a. Einstellungen wenig gebracht.
hw.ath.bstuck = 8
hw.ath.longcal = 30Gruß
Peter -
Hallo zusammen,
ich habe eure WiFi Probleme mal unter diesem Topic hier zusammengefasst, vielleicht gibt es ja doch bald noch mehr zu dem Thema "stuck beacon", "madwifi" und generell zu WLAN an Erfahrungsberichten.
Grüße
Jens -
Habe seit eben pfsense 2.1.5 drauf und die letzten 4-5 Stunden getestet ( mit 2.1.4 habe ich nicht wirklich getestet, weil ich in der Vergangenheit keine Zeit hatte ).
Ich habe mir die Mühe gemacht, den Test nach jedem Schritt den ich durchgeführt habe, hier zu protokollieren. Ich habe jeden Schritt mit Sorgfalt durchgeführt und auch immer wieder nachgeschaut, ob die Schritte die ich beschrieben habe auch wirklich mit "apply changes" gegriffen haben. Auch habe ich nach jedem Schritt nicht gleich den nächsten eingeleitet, um Auswirkungen auch Zeit zu geben.
Ich weiß, dass das nachfolgende etwas viel Text ist und in Anbetracht der Uhrzeit und der abflachenden Lust, dieses Protokoll zu schreiben, nicht immer leicht zu lesen oder zu verstehen ist und Rechtschreibfehler drin sind. Ich denke aber, dass ggf. einige Erkenntnisse dabei rum gekommen sind, die helfen könnten, dem Problem auf dem Grund zu gehen. Ggf. hilft es einigen auch dabei, mit etwas rumprobieren ein mehr oder weniger brauchbares WiFi einzurichten.
Während des gesamten Tests, hatte ich laufend eine Konsolensitzung offen, die über RS232 verbunden war. Änderungen im Webinterface habe ich direkt beobachten können.
Zum System:
OS: pfsense 2.1.5
Systemhardware: PCEngines APU.1C4
SSD: TRANSCEND MSA370 16GB SSD mSATA 6Gb/s MLC
WiFi-Card: 1 x Compex WLE200NX a/b/g/n miniPCI Express Radio Card
Antennenkabel: 2 x RP-SMA Pigtail Buchse (Reverse Polarity) 30cm
Antennenkabel: 2 x Omni Antenne 5dBi RP-SMA, Dualband, 2,4GHz und 5GHzZur Umgebung:
Wohnsiedlung. WiFi-Scanner zeigen in der Umgebung 3 sichtbare Netze , verteilt auf Channel 1, 6 und 11. Die Kanalzuweisung dieser Netze scheint automatisch zu erfolgen. Wahrscheinlich gibts noch mehr Netze, aber für genauere Untersuchungen hab ich keine Zeit.
Testaufbau:
Physische Kabelverbindung:
Internet <-> Telekom-Router mit 4-Port Switch und IP V4 DHCP <-> pfsense wie oben beschrieben ( BRIDGE0 = LAN ; re2 = WAN ; BRIDGE0 = RE0 und AP PRIVAT ) <-> Laptop (über RS232 an der Konsole von pfsense und RJ45 an re2 von pfsense)
Dazu noch ein weiterer Laptop mit WIN7, der sich sobald möglich auf die pfsense über den WiFi Accesspoint PRIVAT verbinden wollte und als Test einige Downloads startete.
So bin ich eingestiegen und chronoligisch vorgegangen:
Start um ca. 23:30
1.
Nach der Install von 2.1.5. hab ich zunächst meine alte Konfig von der 2.1.4 Installation aufgespielt. Diese Konfig hatte 2 APs eingerichtet, die aber beide mit 2.1.4 disabled waren weil sie zunächst nicht stabil liefen.
Diese sind:
SSID PRIVAT, gebridged mit dem LAN-Interface. Dieses Interface wurde nach dem Aufspielen der Konfig enabled.
SSID GAST, wird aktuell nicht genutzt und bleibt erst mal disabled.Das Interface PRIVAT ist folgendermaßen konfiguriert:
Persist common settings: checked
Standard: 802.11g
802.11g OFDM Protection Mode: Off
Transmit Power: 99
Channel: Auto
Antenna Settings: Default / Default
Distance Settings: empty
Regulatory Settings: Default / Default / DefaultErgebnis mit dieser Einstellung:
Die stuck beacon Meldung erscheint ca. 10x pro Sekunde, abwechselnd mit dem bmiss count 0 und 8.
Der Win7-Laptop sieht PRIVAT, kann sich mal anmelden, mal nicht anmelden und schafft es auch mal ne IP abzurufen, bekommt aber eigentlich nie Daten übertragen.
Ähnliches beim Samsung S4 Active.2.
Ich habe angefangen die unter 1. genannten Settings zu modifizieren. Irgendwann habe ich einen Status erreicht, in dem ich keine stuck beacons mehr hatte. Bis ich an diesem Punkt war, hatte ich an folgendem Stellschrauben in diversen Konstellationen gedreht (abweichend zu der unter 1. genannten Konfig):
Antenna Settings: Hatte ich mal auf "Default / Default", mal auf "Auto / Auto", mal auf "#1 / #2"
Distance Settings: Hatte ich mal empty, mal 2000Mal mit den Systunables ( hw.ath.bstuck = 8 / hw.ath.longcal = 30 ) , aber auch mal ohne diese Systunables
Oder aber auch mal hw.ath.bstuck modifiziert und auf 8 / 12 / 16 gestellt
Wie die genaue Konfig lautet, die ich zwischendrin hatte, spielt an dieser Stelle noch keine Rolle. Es ist auch nicht ganz so einfach zu sagen, wenn man weiter liest.
Festzuhalten blieb: Solange ich stuck beacons hatte, funktionierte eine WiFi-Verbindung nie stabil, meist überhaupt nicht. Sobald die stuck beacons weg waren, funktionierte WiFi stabil.
3.
Weil ich ein Freund von Reproduzierbarkeit bin und wissen will, was zur Veränderung des Status Quo führt, habe ich den stabilen Status wieder verworfen und die Settings aus Punkt 1. eingestellt. Ich war mir nämlich nicht mehr sicher, was letztendlich zum stabilen Status führte. Die Settings aus Punkt 1. haben erst mal wieder zu Stuck beacons in Massen geführt. Immerhin war das reproduzierbar. :)
Ausgehend von Punkt 1. habe ich die Änderungen, die ich in Punkt 2. angesprochen habe, jeweils einzeln getestet. Ohne Erfolgt. Sprich:
-> Ausgehend von Punkt 1. z.B. nur die Distance Settings von empty auf 2000 geändert -> Wifi getestet -> Test negativ -> zurück zu Settings aus Punkt 1. , da reproduzierbarer Zustand
-> Dann ausgehend von Punkt 1. z.B. nur die Systunables hinzugefügt -> Wifi getestet -> Test negativ -> zurück zu Settings aus Punkt 1. , da reproduzierbarer ZustandEinzelne Änderungen hatten bei mir nie einen Einfluss.
4.
Da einzelne Änderungen keinen Einfluss hatten, habe ich wieder, wie in Punkt 2. die Guerilla-Taktik angewandt und so lang an mehreren Schrauben gedreht, bis ich wieder einen stabilen Zustand (= keine stuck beacons) hatte.
Dabei stellte ich fest, dass die Reihenfolge der Änderungen Einfluss hat.
Der Weg zu einem stabilen Zustand (wieder ausgehend von Punkt 1.) ist bei mir z.B. folgender:
4.a) Hinzufügen von hw.ath.bstuck = 8 und hw.ath.longcal = 30 , dann Apply changes
-> Noch sind stuck beacons da
4.b) Antenna Settings = #1 / #2 , dann Save, dann Apply Settings
-> Noch sind stuck beacons da
4.c) Distance Settings = 2000 , dann Save, dann Apply Settings
-> Systuneables weg5.
Sehr schön. Stabiler Zustand , basierend auf Punkt 4. :)
6.
Mit Punkt 5. könnte ich ja nun leben. Will ich aber nicht, weil mir bis hier hin zu viel Ungereimtheiten aufgefallen sind.
Ausgehend von Punkt 5. habe ich die hinzugefügten Systunables gelöscht und Apply Settings gedrückt.
Oh Wunder: Nach wie vor stabiler Zustand und keine stuck beacons. Wie kann das sein?
Nun habe ich im direkten Anschluss die Seite aufgerufen, in der ich die Interface-Settings ändern kann (nur aufgerufen, nichts geändert!). Ich habe dann die ungeänderte Seite mit allen Werten wie sie waren einfach nur gespeichert (Save) und anschließend gleich angwandt (Apply changes). Mit Drücken von Apply changes waren die stuck beacons wieder da. Wie kann das sein, wo ich doch einfach nur Einstellungswerte noch mal gespeichert habe, die doch schon da waren?
An dieser Stelle hab ich weiter gemacht und die Systuneables wieder wie in 4.a) beschrieben hinzugefügt. Keine Änderung. Die Stuck beacons bleiben. Auch bin ich wieder in die Interface Settings gegangen und habe diese Seite nochmal gespeichert und apply changes gedrückt. Somit habe ich eigentlich den Zustand aus Punkt 5. und es sollte funktionieren. Pustekuchen: Die stuck beacons bleiben. Anaschließend habe ich noch versucht die Antenna Settings mit Default / Default und wieder auf #1 / #2 oder die Distance Settings auf empty und dann wieder auf 2000 "zu resetten" aber auch das half nichts - die stuck beacons bleiben.
Was bleibt mir anderes übrig: Zurück zum einzig reproduzierbaren Status aus Punkt 1. Vorgehensweise: Zuerst die Interface Settings wie in Punkt 1. eingestellt und applyed, dann die Systunables gelöscht.
Nun kommt der Hammer: Die stuck beacons bleiben weg. Wie kann das sein? Der Laptop bleibt verbunden und lädt fleißig runter. Das darf doch nicht wahr sein!
7.
Jetzt langts. Neustart über Diagnose -> Reboot , mit den Settings aus Punkt 1.
Nach dem Reboot: Obwohl die Systunables gelöscht sind und die Interface Settings ebenfalls wie in Punkt 1., läuft das WiFi stabil und keine stuck beacons.
Wie kann das sein? Sind die anderen WiFis in der Nähe ausgefallen und um 3Uhr nachts in den Schlafmodus? Nein, der Netzwerkscanner zeigt: Alle anderen APs in der Umgebung sind aktiv. Hat vielleicht ein Client dieser Netze seine Downloads beendet und es ist nun kein Traffic mehr in der Luft? Kann ich leider mangels Monitoring nicht nachvollziehen.
Es kann doch nicht sein, dass die stuck beacons sich in nichts aufgelöst haben! Jetzt also anders rum: Was muss ich tun, um sie wieder zurück zu holen?
Ich starte also noch mal neu. Diesmal aber mit Trennung des Netzteils für 15 Sekunden. Cold boot quasi.
Tatsächlich: Die stuck beacons sind nach dem cold boot (mit den Settings aus Punkt 1.) wieder da. Puh! Es gibt doch einen reproduzierbaren Zustand.
Glücklicherweise lässt sich Zustand Punkt 5. nach Durchführung von 4. auch wieder herstellen.
8.
Ein allerletzter Versuch.
Ich habe nun zwei reproduzierbare Zustände. Den aus Punkt 1. und den aus Punkt 4./5.
Die letzte Frage die mich nun quält: Bleibt das System brauchbar, wenn man einen cold reboot durchführt, oder muss man nach dem Reboot wieder auf Punkt 1. zurück und dann Punkt 4. erneut durchführen um stabil zu werden?
Die Antwort ist: Ja, das System bleibt auch nach dem cold reboot stabil. Aktuell um 4:17 gibts nach dem Reboot seit ca. 25 Minuten Uptime keine stuck beacons.
Eigentlich müsste ich nun Punkt 1. wieder einstellen und gucken ob der Zustand nach wie vor reproduzierbar ist und dann wieder Punkt 4. durchführen um zu sehen, ob es wieder weg geht. Darauf hab ich zum aktuellen Zeitpunkt aber kein Bock… Ich lass die Kiste jetzt einfach mal so laufen und schaue später am Tag, ob in der Konsole stuck beacons aufgetaucht sind.
Erkenntnisse:
Ich habe es geschafft, die pfsense in der neuen Wohnung/Umgebung mit WiFi zu versehen. Um diesen Status zu erreichen, ist die Reihenfolge der Änderungen, die man durchführt, als auch die Werte die man ändert von Bedeutung. Für meinen Fall habe ich einen Weg gefunden, wie das Wifi im Moment stabil funktioniert, selbst nach einem cold reboot.
Vermutungen:
Warum pfsense an dieser Stelle so ein Theater macht, kann ich nur vermuten. Ich bin zwar Informatiker, kenne mich aber nicht mit OpenBSD aus, noch schreibe ich selbst Software.
Es ist merkwürdig, dass man gewisse Reihenfolgen einhalten muss um Änderugen zu bewirken. Es ist auch merkwürdig, dass die Verhaltensweise nach einem warm reboot sich nicht zwingend ändern, nach einem cold reboot aber schon.
Das wirft folgende Fragen auf:
- Übergibt das Webinterface Werte nicht richtig ans System?
- Lassen sich Werte nicht richtig speichern, wenn Werte an anderen Stellen nicht geändert wurden?
- Wieso hat das alleinige löschen von Systunables keine Auswirkung, aber in Verbindung mit dem nochmaligen Abspeichern der Interface Settings ohne Änderung schon?
- Wieso kann ein warm reboot ggf. keine Änderung bewirken? Hängen da noch Einstellungen auf der Wifi-Karte fest?
- Sind diese Probleme nur bei Atheros Karten der Fall?
- Würde es vielleicht funktionieren, wenn man eine USB-WiFi-Hardware nutzt, die auf komplett anderen Treibern/Chipsätzen bassiert und von FreeBSD 8.3 unterstützt wird?
Hinweis: Performancetests habe ich bis jetzt noch zu keiner Zeit gemacht, weder Reichweite noch Bandbreite oder sonstiges wie Signalqualität, Packet loss. Es ging an dieser Stelle zunächst mal um eine verwertbare WiFi-Verbindung. Ob diese Verbindung brauchbar ist, wird sich dann im Betrieb zeigen. Um zu prüfen, ob die WiFi-Verbindungen funktionierten, lief ständig der Win7 Rechner nebenher, der sich unverzüglich ins WiFi eingebucht hat, sobald dies möglich war und auch gleich diverse Testdownloads fortgesetzt hat. Leider hab ich aktuell noch nur eine 2-3Mbit Leitung, deshalb gibts keine Aussage zur WiFi-Bandbreite.
Uhrzeit: 4:18. Genug für heute.
-
Hallo,
danke für Deinen ausführlichen Bericht.
Ich werde das mal nächste Woche (genau wie Du beschrieben) nachstellen.
Was ich aber bereits festgestellt habe ist folgendes:1. Die WLAN Verbindung funktioniert trotz der "stuck beacon; resetting (bmiss count 4)" ohne Einschränkung.
2. Ich kann die "stuck beacon; resetting (bmiss count 4)" erzwingen indem ich alle WLAN Kanäle belege.
3. Gleiches stelle ich fest, wenn in meiner Umgebung alle AP's (ca. 25 Stück) aktive sind.Gruß
Peter -
Die stuck beacon waren in der Nacht und am Morgen wieder da. ::)
Habe leider wenig Zeit, daher teste ich später oder morgen weiter.
-
Habe daheim auf meiner APU 1.C die pfSense 2.2-BETA (amd64) built on Thu Sep 18 09:00:31 CDT 2014 mit der Compex WLE200NX Card am laufen.
Leider kann ich für 2.2 nichts gutes sagen was WLAN angeht. Hatte beide WLAN Netze (Intern + Gäste mit CP) schon am laufen. Nach einiger Zeit sind dann beide Interfaces down.Das einzige was in den Wireless Logs ständig auftaucht ist das:
hostapd: ath0_wlan0: WPA rekeying GTK
Stelle ich dann nur bei einem WLAN Netz bei den Einstellungen unter "Standard" von "802.11b" auf "802.11ng" und wieder zurück kommen beide Interfaces wieder up.
Aber leider nur sporadisch. Wenn ich ein drittes WLAN Netz erstellen will geht nichts mehr. Es bleiben alle WLAN Interfaces down bis ich das dritte wieder deaktiviere.
Mehr als der "802.11b" geht auch nicht von der Geschwindigkeit, bei mehr sind die Interfaces wieder down.Als (noch) überhaupt nix stabiles bzw. besser geworden mit FreeBSD 10 als Basis - leider. :-\ Habe alles soweit auf "Default" gelassen.
(Ja, ist alles noch Alpha - aber von dem WLAN Support hatte ich mir Besserung erwartet) -
Spiele nach wie vor mit dem Thema WiFi herum.
Habe nun das WLAN mit 65Mbps stabil am laufen und strahle drei verschiedene Netze aus.In den Logs steht zwar nach wie vor mehrmals pro Sekunde:
kernel: ath0_wlan0: discard frame w/o leading ethernet header (len 6 pkt len 6)
aber es funktioniert schon den ganzen Tag.
Anbei ein Screenshot von den Einstellungen.