Wir haben das Jahr 2014. Da muss WLAN rennen, das ist nix exotisches
Falsch. Du magst recht haben, wenn du ein Device kaufst, dass für WLAN konstruiert wurde. Gibts genügend für und die haben auch ihre eigenen (teils proprietären) Treiber dafür. Aber niemand definiert, dass eine Security "Distribution" (oder Image oder Firmware, wie auch immer man es nennen mag) auch optimal für WLAN gebaut ist oder sein muss.
Gegenbeispiel: Nenne einen (größeren) Hersteller, dessen Security Appliance super für WLAN gebaut ist. Cisco ASA? Nope. Juniper SRX o.ä.? Nö. Setzen BTW auch fast alle auf BSD als Unterbau (bei Juniper sieht mans schön beim Bootvorgang).
Captive Portal funktioniert schick, allerdings baue ich da bspw. eben den WLAN AP dahinter genau aus dem Grund, weil ich WLAN nicht auf dem Gateway haben möchte und es eh nicht in der Weise gut funktionieren würde, dass es sich lohnt. Egal wie, unter Eigenbau Lösungen (Linux + teil-closed-source Treiber ausgenommen) läuft heute eben kein Super-Duper-WiFi mit 4 Antennen und WLAN-AC so gut wie in den fertigen Kisten, die Netgear, Asus und sonstige Firmen rauskloppen. Die sind eben auch primär genau dafür gebaut. Und wenn meine 'Kunden' eben schon Clients haben, die inzwischen sogar WLAN-ac haben, dann brauche ich mit Eigenbau eben gar nicht mehr anfangen, da es kaum sinnvolle Lösungen gibt. Ich bekomme solche Sachen wie Asus mit 4 Antennen, Beamforming und MultiChannel eben nicht hin, dafür haben die da auch ein paar Jährchen Entwicklung reingehauen.
Das mit WLAN wusst ich auch vorher und trotzdem, man darf es nichtmal erwähnen, weil sonst bekommt man genau so Antworten.
Was heißt "solche" Antworten? Es ist aber eben so, wenn ich mich vorher informiere und mir die Plattform ansehe und lese, "Hey, WLAN geht vllt. bis g-Standard OK, bei n wirds wackelig und ac kannst du gerade voll vergessen", dann weiß ich ob ich das will und entsprechend gebastel habe oder nicht. PFsense hat sich nirgends auf die Fahne geschrieben eine tolle WiFi out-of-the-box AP Lösung zu sein. Es ist primär immer noch eine Security Appliance/Firmware/Distro. Nicht weniger, aber auch nicht mehr (was WiFi angeht).
Ich habe alle Foren durch zu dem Thema, aber immer nur aussagen von Usern, den Devs ist es wohl egal.
Sorry, dann bist du leider blind, ich habe allein dazu 2 Tickets im Bugtracker gesehen, bei denen Devs dazu geantwortet haben. Den Link den ich oben gepostet hatte mit einem evtl. Workaround, der eben bei manchen Leuten klappte, kam auch von einem Dev bzw. Teammember (Jimp). Also was soll die Misanthropie? Ich will hier nichts beschönigen und ich habe weder mit ESF noch mit dem Team was zu tun, sondern moderiere nur noch bestem Wissen und Gewissen, aber sinnloses "auskotzen" wie du meinst, bringt niemand was und ist kontraproduktiv. Was genau bringt es anderen, wenn Sie einen Rant von dir lesen dürfen à la "Alles scheiße, 2014 muss das laufen, wir sind doch nicht bei Deppen blabla". Herrjeh bei dir läuft es nicht. Das ist wirklich bedauerlich und ich würde es gern ändern. Kann es auch nicht nachvollziehen. Komischerweise läuft es bei - ich sage mal frech - 95% aber ohne genau das Problem.
Ich kann deinen Ärger verstehen - keine Frage. Aber stell doch mal im Umkehrschluß dir selbst die Frage wie DU das debuggen würdest? Alle Anschlüsse dieser Welt dir nach Texas legen lassen? Geht nicht. Alle Modem und sonstige Gegenstellen prüfen? Wie denn? Geht auch nicht.
Du kannst ja durchaus mal ein neues Image mit 2.1.3 versuchen (sollten auf den Mirrors unter old o.ä. noch herumliegen) oder auch mal hergehen und die 2.2-Beta versuchen, bei der einige auch schon gute Erfahrungen hatten. Oder im Bugtracker suchen, ob der Bug für 2.1.5 konkret wieder offen ist und dort versuchen mehr Infos zuzusteuern, um dem Wurm endlich beizukommen.
Ansonsten gab es für das Problem noch 2 andere Ansätze:
http://www.overclockers.com/forums/archive/index.php/t-744150.html
einer war das Gateway Monitoring zu verändern und die Werte zu erhöhen, ein anderer die Verbindung zwischen pfSense und Kabelmodem zu verändern und eine statische IP zu vergeben (und nach Möglichkeit am Kabelmodem DHCP abzuschalten). Grund in dem Thread war ebenfalls, dass das Kabelmodem und sein DHCP Server angefangen haben, das externe Interface der pfSense mit DHCP Queries zu fluten bzw. teilweise unerreichbar zu machen. Der Gateway Ping schlägt dann fehl, resettet das WAN Interface und das WAN der pfSense geht down. Deshalb Verbindungsabbruch. Alternativ könnte auch eine andere IP als Monitoring eingetragen werden, ggf. bringt das Abhilfe und der State Reset bei Monitor Fail könnte abgeschaltet werden.
Beste Grüße in der Hoffnung Abhilfe zu schaffen
