Router verliert Verbindung zum Internet & dhclient startet nicht automatisch

Errorsmith

Kompiliertier
Hi

Ich habe hier einen FreeBSD Router stehen, der als Gateway zum Internet fungiert. Ich habe das Ding am Wochenende von DSL2000 auf Kabelinternet umgestellt. Anbindung ist nun ein 50/2MBit Kabelmodem an einer vr0 auf der externen Seite, auf der internen Seite ist eine em0 / Gigabit verbaut.

Mein Hauptproblem sieht nun so aus, das die Kiste nach einigen Stunden die Verbindung zum Internet verliert. Oder nahezu verliert. Seitenaufrufe funktionieren nur noch sporadisch, meist schlägt DNS fehl. Wenn ich ein Ping an eine IP Adresse sende, gehen die ersten 20 - 30 Pakete verloren, danach läuft das Ping sauber mit normalen Latenzzeiten durch. Breche ich Ping ab und starte es neu, dauert es wieder ca 20 Pakete bis es läuft. Dabei ist es egal ob ich nur mein Gateway anpinge oder irgendeine IP "draussen" wie die von heise oder 8.8.8.8. Lokale Aufrufe funktionieren einwandfrei, auch wenn sie durch den Router laufen (z.B. WLAN <--> LAN)

Starte ich nun den Router oder das Kabelmodem neu, funktioniert alles wie es soll. Für einige Stunden, dann geht der Spaß von vorne los. Solange es läuft sind sowohl Latenzzeiten als auch die Datenrate im grünen Bereich.
In den Logs tauchen keine Fehler bezüglich Netzwerk auf, lediglich wenn ich das Kabelmodem neu starte bekomme ich einige Hinweise auf einen Reset der vr0 durch den Treiber. Sonst nichts weiter.


Mein anderes Problem ist, das der dhclient nicht automatisch gestartet wird. Ich habe in der rc.conf eingetragen:
Code:
ifconfig_vr0="DHCP"

Ich muss den dhclient dennoch nach jedem Neustart händisch starten mit /etc/rc.d/dhclient start vr0 . Danach läuft er problemlos.

Die Hardware:
- ein "Igel" Thinclient, umgebaut zum Router (VIA 800MHz, 512MB RAM, 8GB CF Karte readonly gemountet)
- vr0 100MBit Karte onboard, em0 PCI Steckkarte
- Kabelmodem von Hitron (Das Standardteil von Kabel-Deutschland)

Die Software:
- FreeBSD 9.1
- pf mit altq
- vlan auf der em0 Karte
- dhclient auf der vr0 Karte

Hat jemand eine Idee woran das liegen könnte?

Grüße,
errorsmith
 
Eigentlich nicht wirklich eine Idee aber ich hatte genau dieses Problem mal mit Linux. Schlussendlich war die MTU Size auf dem Interface für das Modem mit 1500 zu gross. Ich habe sie dann auf "1442" gesetzt und hatte keine Probleme mehr. In den Logs ist nichts zu finden?
 
Nein, wie gesagt keine Fehler im Log
Das einzige was in /var/log/messages auftaucht sind die Meldungen vom dhclient wenn er seine lease erneuert. Manchmal trifft dies mit dem geschilderten Problem zusammen, allerdings konnte ich es noch nicht in direkten Zusammenhang damit bringen. Da es nur alle paar Stunden auftritt, ist es auch schwierig zu beobachten.

Was die MTU betrifft:
Man möge mich korrigieren, aber soweit ich weiß, betrifft das nur DSL (PPPoE) Verbindungen. Bei Kabel sollte ich die normale MTU von 1500 benutzen können. Außerdem müsste das Internet dann zumindest teilweise funktionieren, da nur "große" Datenpakete betroffen sind. DNS sind ja eher kleine Paketchen, die müssten auch bei falscher MTU durchkommen.

Ich habe im Moment drei Möglichkeiten im Verdacht:
- Das Kabelmodem hat ne Macke (unwahrscheinlich, da es funktioniert wenn ich einen einzelnen PC dran hab)
- pf / dhclient kommen mit irgendwas nicht klar
- die vr0 Karte bzw. die Verbindung der vr0 Karte mit dem Ethernetport vom Modem klappen nicht richtig (Das sollte aber im log auftauchen denke ich)



Grüße,
errorsmith
 
Versuchs doch mal ohne ALTQ.
Achso: wenn das nächste Mal das Netz wieder nicht richtig funktioniert, speicher dir mal die Ausgabe von netstat -m auf dem Router.

Rob
 
- die vr0 Karte bzw. die Verbindung der vr0 Karte mit dem Ethernetport vom Modem klappen nicht richtig (Das sollte aber im log auftauchen denke ich)

Hmmm ich denke nicht das sowas automatisch im LOG auftaucht. Bei unseren Igeln (Mit dem normalen Igel-Linux-Image) hatten wirs z.B. öfter mal das die mit bestimmten Switchen nur 10mbit machen, wärend der Switch felsenfest von einer anderen Geschwindigkeit ausgeht - hier half dann beiderseitig die gleiche Geschwindigkeit fest einzustellen. Wobei wir denke ich eine neuere Igel Version haben, bei 800Mhz ist das vermutlich noch eher son "Rechteckiger" im Metallgehäuse?

Evtl. könntest du mal im fehlerfall mal einen dump o.ä. aufnehmen auf vr0.
 
Danke für eure Antworten.
Ich werde beide Ausgaben posten sobald der Fehler wieder auftritt.

Zu altq: Ich habe es bereits ohne altq versucht (queue regeln aus der pf.conf entfernt), das Problem tritt trotzdem auf. Einen Kernel ohne altq habe ich nicht versucht, das kompilieren dauert auf der Maschine recht lang und schrubbt mir zuviel auf der CF Karte rum.

Was den Igel betrifft: Es handelt sich um ein älteres Modell, ähnlich dem http://www.ebay.de/itm/Igel-Thin-Cl...-256MB-RAM-128MB-Flash-Winestra-/261035394223 (hoffe ebay Link ist okay). Der dort beworbene unterscheidet sich nur durch Takt und RAM von dem, den ich benutze. Laut ifconfig hält der die 100MBit auch wenn das Problem auftritt. Ich hatte zunächste nach Problemen in dieser Hinsicht gesucht, da ich der Onboardkarte nicht so recht vertraut habe. Die scheint aber in Ordnung zu sein.

Grüße,
errorsmith
 
Ich habe mehrere solche Igel Büchsen (nur mit etwas schnellerer CPU, die ich aber runtergetaktet habe) seit Jahren problemlos im Einsatz. Auch einige mit dual Ethernet (intel 100Mb). Einige davon auch mit pfSense (FreeBSD firewall).

Für dhcp brauchst du vorher noch einen Eintrag, der den client startet (wg. ext. IP vom Kabelmodem, vermute ich). Irgendwas mit ...dhclient="YES" (sorry, hab's nicht auswendig im Kopf).
Ich selbst verwende für solche Situationen für das interne Netz übrigens dnsmasq und bin damit sehr gut gefahren.

Wie sieht's mit dem Speicher (RAM) aus? Ist da ein nennenswerter Unterschied festzustellen zwischen "grade neu, alles läuft" und "2 Stunden sind rum. router spinnt wieder."? Grund: Sowas gab mir schon gelegentlich Hinweise in ähnlichen "läuft nur x Zeit, spinnt dann" Situationen.

Ansonsten: Tricks in der firewall? Das wäre der nächste Punkt, den ich mir genauer ansehen würde.

Anmerkung: Der vr0 ist nicht gerade das Feinste, aber er lief bei mir in etlichen Igel Kisten immer problemlos und zuverlässig. Zumal sich ja die Belastung stark in Grenzen hält.
 
Möglicherweise hilft:
Code:
SYNCDHCP
anstatt:
Code:
DHCP
Und gestartet werden möchte der dhclient auch noch in der /etc/rc.conf:
Code:
background_dhclient="YES"
 
Hi

Das mit dem DHCP irritiert mich nun ein bißchen, ich hab hier einige Clients rumstehen, bei keinem davon habe ich meines Wissens nach die Zeile dhclient_enable="YES" oder ähnliches in der rc.conf. Der Eintrag für das jeweilige Interface reichte üblicherweise aus. Daher kam ich vernagelterweise auch nicht auf die Idee den zusätzlich zu starten... Ich hab das mal eingetragen und werd beim nächsten reboot mal schauen. Danke hierfür erstmal.
Und ja, du hattest recht: Der braucht das für die externe IP vom Modem. Das Teil läuft im "Bridgemodus" und ich bekomme meine IP direkt via DHCP vom Provider.

Zu dem Igel:
Ich habe das Ding seit knapp zwei Jahren im Einsatz und nie Probleme gehabt, insbesondere mit der vr0 nicht. Allerdings natürlich mit der 2Mbit DSL Leitung. Was die Belastung angeht: Selbst unter Vollast sollte die 50MBit Kabelverbindung das Teil nicht an seine Grenzen bringen. Die CPU Last steht auch nicht gerade am Anschlag wenn ich die Leitung ausnutze. Dazu kommt: Das Problem tritt (auch und meistens) auf wenn die Kiste relativ wenig zu tun hat. Zuletzt heute Vormittag irgendwann. Da war keiner zu Hause und das Ding hat irgendwann aufgehört auf Zugriffe von außen zu reagieren.

Speicher: Kein Unterschied der mir aufgefallen wäre. Aber ich achte beim nächsten mal daruf und poste die Werte.

Firewall-Tricks: Was für Tricks meinst du? Ich wüßte nicht das ich da was "verbogen" hätte, das exotischste ist eigentlich das altq, ansonsten einige Portweiterleitungen und ein redirect von http auf einen transparenten Proxy. Es ist auch dieselbe Konfiguration die ich vorher benutzt habe, es gibt nur zwei Änderungen: Anpassung der Queues an die neue Bandbreite und erlauben von DHCP (port 67 & 68 udp, tcp) auf dem externen Interface.

Grüße,
errorsmith
 
Ich kann das nicht mehr bearbeiten, sonst hätte ich es in den letzten Beitrag eingefügt...
CPU & Speicher laut top nachdem es einige Stunden lief:
Code:
CPU:  2.5% user,  0.0% nice,  5.1% system,  0.7% interrupt, 91.7% idle
Mem: 67M Active, 148M Inact, 151M Wired, 59M Buf, 114M Free

Beim letzten mal als das Problem auftrat habe ich der Einfachheit halber das Modem neu gestartet.
Daher: up 1 day, 21:26, 3 users,


Grüße,
errorsmith
 
Möglicherweise hilft:
Code:
DHCP
Und gestartet werden möchte der dhclient auch noch in der /etc/rc.conf:
Code:
background_dhclient="YES"

Yep, genau das war's, "background" muss vor "_dhclient".

Hi

Das mit dem DHCP irritiert mich nun ein bißchen, ich hab hier einige Clients rumstehen, bei keinem davon habe ich meines Wissens nach die Zeile dhclient_enable="YES" oder ähnliches in der rc.conf. Der Eintrag für das jeweilige Interface reichte üblicherweise aus. Daher kam ich vernagelterweise auch nicht auf die Idee den zusätzlich zu starten... Ich hab das mal eingetragen und werd beim nächsten reboot mal schauen. Danke hierfür erstmal.

Finde ich nur logisch. interface="DHCP" sagt "Adresse bitte via DHCP". Dazu muss natürlich DHCP erst mal enabled sein.

Aber ich meine mich zu entsinnen, dass ich das früher auch mal so hatte wie du (ohne DHCP eigens zu enablen); das kann schon möglich sein. Aber dann würde FreeBSD lediglich großzügig erkennen, was du meinst und einfach ohne zu murren im Hintergrund den DHCP client starten. Nö, dann lieber aussdrücklich rein geschrieben, weil: Vermeide Deduktion seitens OS, sag lieber klar, was du willst.

Ich habe das Ding seit knapp zwei Jahren im Einsatz und nie Probleme gehabt, insbesondere mit der vr0 nicht. Allerdings natürlich mit der 2Mbit DSL Leitung. Was die Belastung angeht: Selbst unter Vollast sollte die 50MBit Kabelverbindung das Teil nicht an seine Grenzen bringen. Die CPU Last steht auch nicht gerade am Anschlag wenn ich die Leitung ausnutze. Dazu kommt: Das Problem tritt (auch und meistens) auf wenn die Kiste relativ wenig zu tun hat. Zuletzt heute Vormittag irgendwann. Da war keiner zu Hause und das Ding hat irgendwann aufgehört auf Zugriffe von außen zu reagieren.

Interessant. Und mies. Wenn das Luder unter satter Last aussteigen würde, wäre das ja noch eher verständlich. Aber hat auch sein Gutes, weil es ein Hinweis ist, dass es nix mit Last zu tun hat und nix mit Speicher sondern anscheinend ziemlich Zeit-abhängig ist.

Firewall-Tricks: Was für Tricks meinst du? Ich wüßte nicht das ich da was "verbogen" hätte, das exotischste ist eigentlich das altq, ansonsten einige Portweiterleitungen und ein redirect von http auf einen transparenten Proxy. Es ist auch dieselbe Konfiguration die ich vorher benutzt habe, es gibt nur zwei Änderungen: Anpassung der Queues an die neue Bandbreite und erlauben von DHCP (port 67 & 68 udp, tcp) auf dem externen Interface.
(Hervorhebung von mir)

Das z.B. Auch sagtest du ja, lokale Aufrufe (ausser ping) liefen einwandfrei. Ich würde mal ein Ermittlungsverfahren gegen altq einleiten.
 
Zu lokal:
Alle Aufrufe lokal funktionieren, auch Ping. Nur Ping --> extern klappt micht richtig

Zu altq:
Wie gesagt. Bis zur Umstellung auf Kabel lief das in dieser Konfiguration ohne Zicken.

Zunächste meine altq Konfiguration:
Code:
####################### queing
# Priorisierung und Limitierung kann nur in AUSGEHENDER Richtung beeinflusst werden.
# daher 2 queues, eine intern, eine extern

# bandbreite fuer fuer kabel: 50400000 / 2000000

# intern --> extern
# master queue mit 99% max bw um sicherzustellen das das queueing auch greift
altq on $if_wan cbq bandwidth 1990Kb queue { real, fast, default, bulk, service }
queue real on $if_wan  bandwidth 25%  priority 7 cbq(borrow)
queue fast on $if_wan  bandwidth 25%  priority 6 cbq(borrow)
queue default on $if_wan  bandwidth 25%  priority 4 cbq(default,borrow)
queue bulk on $if_wan  bandwidth 10%  priority 2 cbq(borrow)
queue service on $if_wan  bandwidth 10%  priority 1 cbq(borrow)

# "upload" ins LAN fuer downloads
# download queue
# in 2 queues aufteilen:
# 1. fuer intern <--> intern (950Mbit)
# 2. von extern --> intern
altq on $if_lan cbq bandwidth 1000Mb queue {d_internal, d_external}
queue d_external bandwidth 49Mb cbq(borrow) { real, fast, default, bulk, service }
  queue real on $if_lan  bandwidth 5% priority 7 cbq(borrow)
  queue fast on $if_lan  bandwidth 5% priority 6 cbq(borrow)
  queue default on $if_lan  bandwidth 10% priority 4 cbq(borrow,default)
  queue bulk on $if_lan  bandwidth 70% priority 2 cbq(borrow)
  queue service on $if_lan  bandwidth 10% priority 1 cbq(borrow)
queue d_internal bandwidth 950Mb

In den nachfolgenden Regeln sind dann die Zuweisungen, zusammengefasst
- Telefon, Onlinespiele: Queue 'real'
- ssh, syn & ack: Queue 'fast'
- http, ftp etc: Queue 'bulk'
- Dinge auf die von außen zugegriffen werden kann: Queue 'service'
- Zusätzlich: Wenn Quelle und Ziel innerhalb des LAN liegen: Queue d_internal

Anpassungen der Regeln erfolgte bei den Parametern die die Bandbreite der Verbindung definieren, hier stand vorher 438Kb (upstream) bzw 3456Kb) Downstream. Beim Umschalten auf die neue Verbindung habe ich das temporär abgeschaltet (Queues und Zuweisungen aus der pf.conf entfernt). Da hatte ich das Problem auch schon einmal, es aber erstmal nicht für voll genommen. Ohne aktiviertes altq trat es also auch schon auf.


Inwieweit kann altq zum beschriebenen Problem führen?
Vor allem bei wenig oder keiner Belastung greift die Priorisierung / Bandbreitenlimiterung doch garnicht?

Wie kann ich testen ob ein Zusammenhang besteht (möglichst ohne einen neuen Kernel zu bauen)

Grüße,
errorsmith
 
Ich würde das queuing temporär deaktivieren, einfach weil ich auf Fehlersuche möglichst viele Faktoren ausgrenzen will.

Zu der Anmerkung, dass das vorher problemlos lief (und du sonst nichts geändert hast, unterstelle ich mal), ist das natürlich als Hinweis zu nehmen. Augenscheinlich beisst sich da etwas mit dem neuen Modem. Einen ersten Verdacht/Hinweis hattest du ja schon, nämlich mtu. Mein nächster Schritt wäre es, mir nochmal mal genau das Modem anzusehen. Also mtu, eventuelle Protokoll Eigenheiten, etc. Allerdings kann ich da leider nicht mit Erfahrung dienen, weil ich noch nicht mit einem Kabelmodem gearbeitet habe. Vielleicht mag es auch einfach kein bridging sondern eine 0815 Konfiguration. Das sind ja keine Profibüchsen sondern Zeug, das für die typische Home Situation gedacht ist.
 
Hi

Ich werde bis zum nächsten Auftreten des Fehlers nichts ändern und danach das Queueing deaktivieren. Bis dahin möchte ich nichts ändern um die eventuellen Ausgaben nicht zu beeinflussen.

Zum Modem:
Von der Sache her ist das ganze aus Sicht meines Routers eine normale Ethernetverbindung. Das Modem funktioniert so gesehen eher wie ein Medienwandler. Keine Tricks mit gekapselten Protokollen, keine Würgerei mit MTU oder ähnlichem. Ich hänge mit meinem Rechner in einem ganz normalen Netzwerk:
Code:
root@igel:~ # ifconfig vr0
vr0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
  options=82808<VLAN_MTU,WOL_UCAST,WOL_MAGIC,LINKSTATE>
  ether 00:e0:c5:4e:79:c3
  inet AA.BB.CC.DDD netmask 0xfffff800 broadcast AA.BB.CC.255
  nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
  media: Ethernet autoselect (100baseTX <full-duplex>)
  status: active

Ich habe, bevor ich das an mein LAN gehängt habe, das Modem ca zwei Tage mit einem einzelnen PC getestet. Dort trat beschriebenes Problem nicht auf. Weder im normalen Betrieb (0815 Endkunden-Setup mit Modem als "Router-Firewall") noch im Bridgemodus. Ich vermute allerdings auch das es ein Problem mit pf und/oder dhcp gibt. Der Testrechner war von einer LiveCD gestartet ohne Firewall im Netz.

Grüße,
errorsmith
 
Hi

Es lief fast einen Tag stabil, heute morgen war es dann wieder soweit. :-(
Dafür kann ich nun ein bisschen Ausgaben / Infos posten.
Als ich nachgeshen habe, hatte die vr0 keine IP mehr:
Code:
root@igel:~ # 
ifconfig vr0   
vr0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500   
  options=82808<VLAN_MTU,WOL_UCAST,WOL_MAGIC,LINKSTATE>   
  ether 00:e0:c5:4e:79:c3
  inet 0.0.0.0 netmask 0xff000000 broadcast 255.255.255.255
  nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
  media: Ethernet autoselect (100baseTX <full-duplex>)
  status: active

Das war sonst anders. Da hatte die noch eine IP. Dementsprechend funktionierte diesmal auch ping überhaupt nicht mehr im Gegensatz zu sonst.

Die Routingtabelle sah ähnlich traurig aus:
Code:
Internet:
Destination  Gateway  Flags  Refs  Use  Netif Expire
0.0.0.0/8  link#7  U  0  0  vr0
127.0.0.1  link#10  UH  0  2125  lo0
192.168.41.0/24  link#13  U  0  542444 vlan40
192.168.41.1  link#13  UHS  0  0  lo0
192.168.60.0/24  link#15  U  0 15677062 vlan60
192.168.60.1  link#15  UHS  0  8  lo0
192.168.80.0/24  192.168.200.2  UGS  0  0 vlan20
192.168.81.0/24  192.168.200.2  UGS  0  2228988 vlan20
192.168.82.0/24  192.168.200.2  UGS  0  0 vlan20
192.168.200.0/24  link#12  U  0  6372 vlan20
192.168.200.1  link#12  UHS  0  9  lo0

Die gewünschte Ausgabe von netstat -m:
Code:
root@igel:~ # netstat -m
388/2312/2700 mbufs in use (current/cache/total)
385/1545/1930/16704 mbuf clusters in use (current/cache/total/max)
385/1535 mbuf+clusters out of packet secondary zone in use (current/cache)
1/486/487/8352 4k (page size) jumbo clusters in use (current/cache/total/max)
0/0/0/4176 9k jumbo clusters in use (current/cache/total/max)
0/0/0/2088 16k jumbo clusters in use (current/cache/total/max)
871K/5612K/6483K bytes allocated to network (current/cache/total)
0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters)
0/0/0 requests for mbufs delayed (mbufs/clusters/mbuf+clusters)
0/0/0 requests for jumbo clusters delayed (4k/9k/16k)
0/0/0 requests for jumbo clusters denied (4k/9k/16k)
0/7/4432 sfbufs in use (current/peak/max)
0 requests for sfbufs denied
0 requests for sfbufs delayed
0 requests for I/O initiated by sendfile
0 calls to protocol drain routines

/var/log/messages war unverändert seit gestern Nachmittag, keine weiteren Einträge seit dem Eintrag als ich mich eingeloggt habe und einer Erneuerung der IP von irgendwann am morgen. (Aber längere Zeit bevor der Ausfall begann).

Aus irgendeinem Grund hat der dhclient keine IP mehr bekommen. Der Prozeß lief noch.
Ich habe den dann neu gestartet. Er hat dann 6 mal versucht eine IP zu bekommen, damit ist er gescheitert. Auch nach mehreren Versuchen den neu zu starten änderte sich daran nichts.
Um eine pf Regel auszuschließen, habe ich ein tcpdump auf pflog0 gemacht. Dort tauchte aber nichts auf. Wäre auch merkwürdig, ich habe das ja explizit freigegeben. Zumal es ja nach dem Modemneustart funktioniert.

Einen dump auf der vr0 habe ich auch laufen lassen. Das ist aber "zuviel Zeug", das kann ich hier nicht posten. Ich stelle es aber auf Wunsch gern online. Außer einer Menge ARP Requests von anderen Teilnehmern meines Subnetzes habe ich ein wenig IPv6 Traffic dadrauf und meine DHCP Requests. Diese werden aber nicht beantwortet, bzw sie kommen nicht an.

Queueing ist übrigens mittlerweile deaktiviert.

Weiß einer da was? Fehlt eine Info?

Nach dem Modemneustart hat dhclient sofort eine IP bekommen und es läuft seitdem. Aber das ist ja nicht so recht der Plan...
Woran kann sowas liegen? Das Interface als solches scheint ja noch zu funktionieren, ich kann ja im dump die Pakete mitlesen. Was ist nach einem Reset des Modems anders als sonst? Die Karte hängt auch direkt am Kabelmodem, da ist kein Switch zwischen oder ähnliches.


Grüße,
errorsmith
 
IMHO hat das Modem ein Ding weg.

Rob

Jep, das denke ich auch. Wenn ich mir ansehe, wie viele Igel seit Jahren brav ihren Dienst tun und wieviele Modems mit Hirnfrass, Temperaturzickerein, Spannungsversorgungs-Divaallüren, etc. ich schon erlebt habe, Dann traue ich dem Igel ziemlich weitgehend und dem Modem herzlich wenig. Dazu noch lustige Macken mit mtu, gesperrten Protokollen, seltsamen Netzwerkstacks ...

Also, MTU auf 1200 runter, Strippe checken, normaler router mode + statische IP setzen, etc ... der ganz normale "Ich traue meinem Modem nicht mehr" Wahnsinn halt.
Mein Verdacht: Wenn du nicht mehr bridgest sondern artig eine Fritzbox ("klassischer Haushalts Router in klassischer Otto Normal Config (router)") simulierst, dann tut das Kabelmodem auch wieder (Faustregel: Behandle ein Modem, als ob's maximal dämlich, empfindlich und unfähig, dafür aber zickig wäre).
 
Ich hatte auch das Modem im Verdacht. Und ich teile moe's Ansicht was die Igel betrifft. Ich habe den damals als Firewallrechner ausgewählt weil ich die Dinger auch als maximal zuverlässig kenne. Das mit den Modems kann ich nicht so ganz nachvollziehen, da hab ich nur gute Erfahrungen gemacht. (D-Link, AVM, US Robotics)

Aber zum Thema: Ihr habt recht und mein Verdacht scheint sich zu bestätigen: Da ich aus den Ausgaben keinen Fehler ersehen konnte, hab ich parallel im KD Forum gepostet und dort die Aussage bekommen das ich ne kaputte Firmware habe (wie viele andere User auch), KD sich aber weigert das zuzugeben, zu ändern oder auch nur das Rollout zu stoppen. (Bei mir kam das Firmwareupdate am Wochenende.)
Allerdings betrifft es nicht nur Leute mir Bridgemode sondern alle User die diese Firmware bekommen haben. Gnaah.

Da kein FreeBSD Thema mehr, kann das nun als erledigt betrachtet werden. Der Rest ist dann wohl eher was fürs Kundenforum von Kabel Deutschland.

Vielen Dank für eure Tips. Ich habe hier, wie immer kompetente Hilfe bekommen!

Grüße,
errorsmith
 
Man hatte mir am Wochenende ohne weiteren Hinweis die alte FW eingespielt. Ich hab es nur mitbekommen weil ich mal (wieder) auf die interne Webseite des Modems geguckt hatte. Seitdem läuft es stabil...
Danke für den Hinweis, der Artikel war mir irgendwie entgangen. Allerdings glaube ich nicht das es eine "niedrige zweistellige" Zahl an Usern ist die diese Probleme haben. Desweiteren ist auch der Routermodus betroffen, da läuft es etwas stabiler aber unter LAst stirbt das Teil dann auch irgendwann.

Grüße,
errorsmith
 
Back
Top