@eSpezi: Offenbar hast Du Dir den Limiter noch nicht so genau angesehen. Doch, nur passt es für mein Anwendungsfall nicht (VOIP, Streaming und P2P Traffic) @eSpezi: Probier's einfach mal aus… Ich fahre derzeit mit PRIQ ganz gut :) Ich hatte seinerzeit auch mit dem Limiter gearbeitet aber das anders verstanden. Danke für die Info :)

@Dimkson Doch so ziemlich alle aus den Community Rules. Ich habe es entsprechend dieser Anleitung gemacht http://www.youtube.com/watch?v=8c1LRpWhL0I Alarme kommen auch bei anderen Clients. Danke für Dein Tutorial, leider in english. grüsse funroli

bump würde mich über heilfe freuen ! Danke :)

Hi Matthias, sorry, ich war jetzt länger weg (Urlaub und danach erstmal gar keine Zeit …). Besteht das Problem noch? Ich kenne das Problem so nicht. Allerdings ist es bei mir mittlerweile auch nicht mehr ganz reibungsfrei. Am Anfang hat alles perfekt funktioniert, inzwischen bekomme ich gelegentlich Hänger beim Umschalten: Wenn ich von einem Kanal auf einen anderen umschalte, dauert es manchmal ziemlich lange, bis da ein Bild kommt. Abhilfe: Receiver neu einschalten. Da ich beim Fernsehen nicht zappe, hat mich das bisher nicht ausreichend gestört, um Zeit in die Fehlersuche zu investieren. Hänger innerhalb eines Programms habe ich noch nie gehabt. Beide Probleme sehe ich aber nicht in der Konfiguration des IGMP-Proxy. Grund: Wenn da ein Netz fehlen sollte, dann dürften bestimmte Kanäle gar nicht funktionieren. Es ist vorstellbar, daß IGMP-Nachrichten sporadisch ausfallen, ich wüßte aber nicht, woher das kommen sollte. Du könntest mal ein trace der IGMP-Pakete mitlaufen lassen und schauen, was vor einem Ausfall passiert ist. Bei einem Hänger also sofort auf die Ur schauen, damit man das nachher zuordnen kann. Das Volumen eines solchen trace ist auch über einen längeren Zeitraum überschaubar, wenn man vernünftig filtert. -flo-

LAN ist nur allow all. Ich habe das Problem zwischenzeitlich gelöst. Eine falsch gesetzte MTU war der Fehlerteufel.

Hallo, erst mal sorry, dass ich mich erst so spät wieder melde. Das Problem mit der Blacklist ist gelöst! In unserem Fall hatten wir die nano/embedded Version auf einer SD Karte. Diese kopiert die Ordner var und tmp als read only in den RAM Speicher. Dadurch lassen sich nicht alle Packages installieren und die Blacklist geht auch nicht. Wir haben jetzt eine 30 GB Intel mSATA disc eingesetzt und dann das normale pf Sense Image installiert. Jetzt klappt alles.

Hallo Genau so ein Problem hatte ich auch…hast du bei deiner WG x750e auch PS/2 Tastaturanschluss und VGA ? ... bei meiner ist das nachgerüstet wurden ... alle Stecker sind auf den Motherboard schon vorhanden - sogar USB. Wenn ja - schließe mal einen Monitor an - wo bleibt die genau stehen? Oder kommst du mit Web Adresse z.b bei mir 192.168.1.1 noch / schon drauf? Du könntest auch mit Nullmodem - Kabel und z.b.Putty dich drauf schalten und mal sehen wo es Hackt. Womit startet die WG ? mit CF oder HD. Wenn du in Hamburg Wohnst können wir uns auch mal Treffen und das Testen.

Du kannst alternativ das Logging deaktivieren indem Du bei LAN Interface den Haken "Block private networks" rausnimmst und eine neue Regel für das Lan erstellst mit block UDP und alles any außer Destination port 67.

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

Eventuell nicht genügend freie IP's die der DHCP verteilen darf? Schau doch mal in die DHCP Logs.

Hi David, vielen Dank für den Hinweis….und sorry für das delay.... mit den Befehlen hab ich einen Ansatz eine genau Anleitung zu ergooglen.... Gruß Dirk

Hi rubinho, etwas verspätet aber besser spät als nie :). Ja es war Squidguard. Sobald er die Blacklist heruntergeladen hat, war der Speicher sofort voll. Habe ich es ausgelassen, lief der Speicher nach 30min direkt voll. Habe die Ext. Festplatte Ex4 formatiert und in die fstab eingetragen. Eine sehr lange Fehlersuche hatte ich damit, die Log Dateien auf die festplatte zu bringen. Abspeichern in der GUI ging nicht und in den config Files wurde diese sofort wieder überschrieben. nach langem Suchen fand ich das das Problem bei den .inc Dateien liegt der Pakete. Danach habe ich die SquidGuard.inc und Squid.inc angepasst und zwar überall wo ein /tmp/ zu finden war. zu finden unter:  /usr/local/pkg/ Jetzt läuft es stabil!

Wie hast du es gelöst ? Ich gehe von Firewall Regeln aus ?

Hi BeNe Vielen Dank für deine Antwort. Ich selbst betriebe keinen FTP Server. Das Problem ist, dass ich nicht mit meinem Client auf einen fremden FTP Server laden kann. Respektive der Upload startet immer und es kann auch immer eine unterschiedliche Anzahl an Dateien hochgeladen werden. Nach einer gewissen Zeit kommt dann aber die Meldung: PHP Warning:  ftp_put(): Idle timeout (50 seconds): closing control connection in Ich nutze für den Upload ein PHP Skript mit der Funktion ftp_put, damit beliefere ich verschiedene FTP Server mit Daten. Das Problem ist, dass die einen den aktiven und die anderen nur den passiv Modus unterstützen. Alle Ports von meinem Client nach aussen sind offen, sprich dieser kommt auf jeden Fall raus. Merkwüridgerweise geht es immer unterschiedlich lang, bis der Upload abbricht. Kann mir jemand weiterhelfen? Herzlichen Dank und liebe Grüsse Lars

Zäher Seitenaufbau = Browserwechsel mal probieren. Hatte das erst gestern bei einem Freund kernel: arpresolve: can't allocate llinfo for = routing mal kontrolieren Leider kann ich sonst beim Hauptproblem nicht weiterhelfen, sorry.

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. [image: wifi.png] [image: wifi.png_thumb]

Hallo Harry Vielen Dank für deine ausführliche Antwort und die Inputs. Ich habe es aber nun relativ einfach gelöst, indem ich für die einzelnen Gateways Routen erstellt habe. Respektve habe ich die LAN Schnittstellen auch als Gateways definiert und dort unter "Routes" die einzelnen Clients definiert, welche über welche Schnittstelle wieder wieder zurück ins LAN kommen sollten. Herzlichen Dank nochmals und ein schönes Wochenende. Liebe Grüsse Lars

Alles klar danke sehr. Werde mir diese Adapter mal bestellen, wenn es soweit ist schreibe ich dann hier nochmal ob es geklappt hat. Ja (noch) haben wir ISDN wird wohl Anfang nächsten Jahres umgestellt -.-

@JeGr Danke für die Info. Ich habe jetzt mal noch eine Einstellung gefunden die nach einem Update umgestellt hat. System -> Advanced -> Miscellaneous -> Gateway Monitoring -> State Killing on Gateway Failure Hier habe ich nun den Marker entfernt.