Posts Tagged ‘DHCP’

Samstag, 14. Juni 2025

Ein ZTE MF79U 4G USB-Modem unter Debian zum Laufen bringen

Ich habe mir kürzlich über Amazon ein ZTE MF79U 4G Mobilfunkmodem gekauft. Zusätzlich dazu noch eine Digitec IoT SIM mit 0.4 MBit/s (Anbieter: digital republic), welche im Jahr mit 44 CHF zu buche schlägt.

Einsatzzweck: Out-of-band (OOB) Lösung an einem WLAN-Travelrouter einer Bekannten. Der Router verbindet sich als WLAN-Client mit einem WLAN-Netzwerk eines Drittanbieters (analog zu einem Gäste-WiFi in einem Hotel), welches quartalsweise ein neues WLAN-Passwort erhält (ja, der Anbieter ist noch nicht auf die Idee gekommen, das WLAN zu öffnen und stattdessen mit Portal-Technologie zu arbeiten, welche einzelne Clients mit Benutzernamen und Passwort authentifziert).

Ich möchte damit künftig vermeiden, dass ich vor Ort das WiFi-Kennwort anpassen gehen muss, damit sich der WLAN-Travelrouter wieder mit dem WLAN-Netzwerk der Institution verbindet.

Der Plan ist, dass künftig auf dem Travelrouter basierend auf OpenWRT über das 4G-Interface ein Reverse SSH Tunnel zu einem meiner Server geöffnet wird, über welchen ich dann aus der Ferne auf den Router und das Web-Interface zugreifen kann (meines Wissens könnte ich das Kennwort vermutlich auch auf der Kommandozeile wechseln, aber soweit bin ich noch nicht).

Gestern habe ich den USB-Stick an einem Debian-Server in Betrieb genommen. Was ich dabei gelernt habe:

Das Teil findet man sofort nach Anschluss mittels lsusb:

# lsusb
...
Bus 001 Device 006: ID 19d2:1405 ZTE WCDMA Technologies MSM ZTE Mobile Boardband

Die Bedeutung der Produkt-ID 1405 ist hier dokumentiert: ZTE MF 823 (Megafon M100-3) 4G Modem

1405

A communication mode in which the device has a wikipedia:USB communications device class interface in addition to the card reader interface. Communications Device Class (CDC) should work in Linux. The cdc_ether kernel module is required. This mode will be the one usb_modeswitch will switch the device into.

Der Stick stellt auch ein Block-Device (Speicher) zur Verfügung; das ist nur unter Windows nützlich, weil sich auf dem Datenträger die Treiber für den Stick finden. Clever!

# lsblk
NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
...
sr0     11:0    1   6.8M  0 rom
# blkid
...
/dev/sr0: BLOCK_SIZE="2048" UUID="2022-06-21-14-31-58-00" LABEL="ZTEMODEM" TYPE="iso9660" PTTYPE="mac"

Der USB-Stick spannt ein eigenes WLAN-Netzwerk auf, sobald er Strom hat. IP-Adressbereich ist 192.168.0.1/24. Die SSID und das Kennwort findet man unter der Abdeckung des Sticks, welche einem Zugang zum physischen SIM-Slot erlaubt.

Der Stick hat eine Weboberfläche unter http://192.168.0.1/, mit welcher man alle möglichen Einstellungen vornehmen kann. Das admin-Kennwort ist ebenfalls unter der Abdeckung aufgedruckt.

Ich musste meines Wissens eine Runde in der Web-Oberfläche drehen und die (bereits aktivierte) SIM-Karte einschalten, sonst hätte sich der Stick nicht mit dem Internet verbunden.

Der Clou: Verbindet man Geräte mit dem WiFi des USB-Sticks, können alle Geräte über die Mobilfunkverbindung ins Internet. Gemäss Web-Oberfläche ist die Zahl der Clients auf 10 beschränkt, diese Zahl scheint aber anpassbar zu sein.

Unter Debian wird der Stick problemlos auch als USB-basiertes Ethernet-Interface erkannt (Treiber: cdc_ether:

# lsmod | grep -i ether
cdc_ether              24576  0
usbnet                 57344  1 cdc_ether
usbcore               348160  8 ehci_pci,usbnet,usb_storage,uvcvideo,ehci_hcd,cdc_ether,uas,uhci_hcd

# ip a
...
5: enx344b50000000:  mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 34:4b:50:00:00:00 brd ff:ff:ff:ff:ff:ff

Damit man den Laptop über dieses Interface mit dem Internet verbinden kann, muss folgendes geschehen:

  • Interface hochbringen: ip link set enx344b50000000 up
  • IP-Adresse beziehen: dhclient enx344b50000000 -v
# dhclient enx344b50000000 -v
Internet Systems Consortium DHCP Client 4.4.1
Copyright 2004-2018 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Listening on LPF/enx344b50000000/34:4b:50:00:00:00
Sending on   LPF/enx344b50000000/34:4b:50:00:00:00
Sending on   Socket/fallback
DHCPDISCOVER on enx344b50000000 to 255.255.255.255 port 67 interval 7
DHCPOFFER of 192.168.0.169 from 192.168.0.1
DHCPREQUEST for 192.168.0.169 on enx344b50000000 to 255.255.255.255 port 67
DHCPACK of 192.168.0.169 from 192.168.0.1
bound to 192.168.0.169 -- renewal in 38135 seconds.

Sobald der Server eine IP in der 192.168.0.1/24-Range besitzt, sollte man über dieses Interface ins Internet rauspingen können:

# ping -I enx344b50000000 1.1.1.1
PING 1.1.1.1 (1.1.1.1) from 192.168.0.169 enx344b50000000: 56(84) bytes of data.
64 bytes from 1.1.1.1: icmp_seq=1 ttl=54 time=177 ms
64 bytes from 1.1.1.1: icmp_seq=2 ttl=54 time=18.2 ms
^C
--- 1.1.1.1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 18.203/97.527/176.851/79.324 ms

Die Frage ist nun, ob diese Schritte an einem OpenWRT-Router automatisiert werden kann.

Nachteil: Der Stick selber macht NAT, und somit kann man in Double-NAT-Situationen landen. Einige Sticks scheinen einen Bridge-Mode zu besitzen, doch diese Option habe ich bei meinem Stick nicht gefunden.

Nachtrag

Ich habe unter Linux beim rumpröbeln einige Pakete installiert, weiss aber nicht, ob das nötig gewesen wäre:

  • usb-modeswitch
  • ppp
  • libnss-myhostname
  • libnss-resolve
  • modemmanager

Tags: , , , , , , , ,
Labels: IT, Linux

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 8. September 2024

Hybrid7 mit Zyxel PM7300 und ZyWALL VPN100: Tips zum Debuggen

Gestern wurde ich zu einem Bekannten gerufen, um ihm bei der Installation seiner neuen Glasfaser-Verbindung zu helfen.

Ich hatte ihm Fiber7 wärmstens empfohlen, und er war meinem Ratschlag gefolgt. So konnte ich die Anfrage schlecht ausschlagen, aber im Grunde reizte es mich ungemein, ihm dabei zu helfen. Aber eigentlich hatte er auch keine grosse Wahl, da er seine bestehende Firewall weiterverwenden wollte, und das ist meines Wissens mit Swisscom als Glasfaser-ISP nicht möglich.

Leider ist seine Liegenschaft (wie auch die unsere) von Swisscom nur durch P2MP erschlossen worden. Zwar sind auf dieser Infrastruktur nun offenbar auch Drittanbieter erlaubt. Doch die Installation des Glasfaser-Anschluss ist nicht so einfach wie seinerzeit bei uns in Bern, wo unsere Mietwohnung mit vier Fasern erschlossen war, man das Glasfaserkabel in den richtigen Anschluss einsteckte, mit der Optik verband, dem Router die PPPoE-Zugangsdaten mitgab, und schon war man online.

Nach dem (glücklicherweise) schlussendlich erfolgreichen Installationsprozedere hat sich der Gedanke bei mir festgesetzt, dass der Monopolist das Onboarding absichtlich extrem kompliziert, dementsprechend fehleranfällig und langsam gestaltet hat, um die Konkurrenz auszuschalten. Aber wie gesagt, das ist nur eine Vermutung — vielleicht ist diese Technologie einfach deutlich komplizierter, und Swisscom hat das Beste daraus gemacht …

Auf jeden Fall schaffte es der Bekannte nicht, die von Fiber7 gelieferte Zyxel PM7300-Bridge an seiner ZyWall VPN100 zum Laufen zu bringen. Die Bridge zeigte zwar an, dass „Licht“ bei ihr ankommt, doch die sogenannte Splash Page wollte sich einfach nicht im Browser öffnen.

Als erstes suchte ich nach Installationsanleitungen für diese Gerätekombination, und wurde folgendermassen fündig:

Hier meine Erkenntnisse:

Keine VLAN-Konfiguration auf der Bridge nötig

Nach viel pröbeln am Vortag hatte sich der Bekannte auf die Bridge eingeloggt, und auch dort die VLAN-Konfiguration (VLAN10) vorgenommen.

Da in der Fiber7-Anleitung nichts davon stand, bat ich den Bekannten, die Bridge komplett zurückzusetzen, und es mit der Vanilla-Konfiguration zu probieren. Dies erwies sich im Grossen und Ganzen als guter Entscheid. Nach dem Zurücksetzen konnte sich die Bridge nicht mehr mit der Gegenstelle verbinden, doch nachdem wir einen einmaligen Kaltstart forcierten, klappte es dann wieder. Keine Ahnung was da los war.

Noch ein Hinweis zu den LEDs:

  • POWER: Muss konstant grün leuchten
  • Hexagon (PON): Muss grün leuchten (blinkend: Verbindungsaufbau)
  • Alarmglocke (LOS): Darf nicht leuchten/blinken (wenn sie rot leuchtet/blinkt, stimmt etwas nicht)
  • 10GE: Leuchtet grün wenn am anderen Ende des Ethernetkabels ein Netzwerkgerät dranhängt. Blinkt wenn Daten übertragen werden

Betriebssysteme und VLANs

Bevor wir die ZyWALL mit der Bridge verbanden, insistierte ich, einen Laptop an den Ethernet-Port der Bridge anzuschliessen um zu schauen was passiert.

Der HP-Laptop mit Windows konnten wir problemlos anschliessen, doch der Laptop erhielt keine IP zugewiesen. Ich wollte darauf hin VLAN10 konfigurieren, doch der Netzwerktreiber (Realtek irgendwas) scheint diese Option nicht anzubieten. Rasch gab ich auf, da ich mit Windows seit mehr als 10 Jahren nichts mehr am Hut habe.

Stattdessen schlossen wir nun ein MacBook Pro an die Bridge an. Hierzu verwendeten wir ein USB-C Dock mit Gigabit-Ethernet-Anschluss. Auch hier dasselbe Bild: macOS erhielt keine IP.

Nach einer kurzen Internet-Recherche fand ich einen offiziellen Apple Knowledgebase-Artikel, wie man unter macOS einen virtuellen VLAN-Adapter einrichtet: Set up a VLAN on Mac. Wie üblich deutlich einfacher als es unter dem Windows-Gefrickel je sein könnte.

Eingerichtet, und schwupp-di-wupp, der Mac erhielt via DHCP eine IP-Adresse und Netzwerkkonfiguration.

Swisscom DHCP-Infos

Der Mac erhielt folgende DHCP-Infos ausgehändigt:

IP address 100.95.137.141
Subnet mask 255.255.255.128
Router 100.95.137.129
DNS Server 1 195.186.1.162
DNS Server 2 195.186.4.162

IPv6 war Fehlanzeige, aber das störte uns ja nicht sonderlich.

Pingen, Surfen: Fehlanzeige

Auf dem MacBook versuchte ich dann, das Gateway (Router) zu pingen, Fehlanzeige. Auch die DNS-Server reagierten auf keine Pings. Ins Internet gelangte ich sowieso nicht. Auch das Ansurfen von Web-Sites wie bspw. www.spiegel.de oder www.admin.ch funktionierte nicht — elend lange Ladezeiten, um am Schluss mit einem Timeout zu enden. Egal mit welchem Browser ich es probierte — Safari, Firefox und Chrome.

Was aber funktionierte: Auf der Kommandozeile konnte ich mittels $ host www.spiegel.de tatsächlich DNS-Abfragen ausführen, und erhielt die korrekte aufgelösten IPs zurück.

Software-Firewall Gedöns ist des Teufels

Was das Debugging zu diesem Zeitpunkt verkomplizierte war die Little Snitch-Firewall, die der Bekannte auf seinem MacBook Pro installiert hatte. Obwohl wir sie deaktivierten, hatte ich das Gefühl, dass sie trotzdem weiterhin interferierte.

Zum Glück hatte ich mein MacBook Air ohne Firewall-Gedöns mit dabei, und wir wechselten kurzerhand auf dieses Gerät.

Swisscom Splash Page URL

Ich weiss nicht, was genau wir anstellten, aber auf meinem MacBook Air versuchte ich erneut www.spiegel.de aufzurufen. Ich setzte das Safari-Fenster in den Hintergrund, und als ich es wieder hervorholte erschien zwar nicht SPIEGEL Online, aber eine Safari Fehlermeldung „Safari Can’t Open the Page“. Und siehe da, als Adresse stand:

www.swisscom.ch/splashpage/guest/app/AccessId

Manueller Aufruf über Browser, und wget — Fehlanzeige!

Nun hatten wir also die URL der Splash Page, und natürlich versuchte ich sofort, diese direkt anzusurfen. Ewig lange Ladezeiten, und anfänglich ohne Erfolg. Schlussendlich aber lud etwas, aber nicht das, was ich erwartete:

Ich versuchte auch, die URL via wget herunterzuladen, aber das klappte im Gegensatz zum Browser überhaupt nicht — ich erhielt immer eine Timeout-Fehlermeldung.

Die IP des Swisscom Web-Servers lautet übrigens 195.186.210.170, aber nicht als wäre das irgendwie von Nutzen gewesen.

Zwischenfazit

Dank all diesen Erkentnissen war zumindest klar, dass der Glasfaser-Uplink funktionierte — Geräte erhielten via DHCP eine gültige IP und DNS-Informationen, und Swisscoms Server antworteten (wenn auch extrem langsam).

Wechsel auf ZyWALL und Windows

Jetzt fand ich den Zeitpunkt gekommen, um die Bridge an WAN2 der ZyWALL anzuschliessen. Allenfalls würde es ja damit besser klappen. WAN1 (an welchem derzeit noch ein Sunrise/upc Kabelmodem hängt) deaktivierten wir. Auch legte ich ein Augenmerk darauf, dass nur anfänglich die VLAN10 Konfiguration auf der ZyWALL aktiv war, und die VLAN11 Konfiguration (mit den PPPoE-Zugangsdaten) ebenfalls deaktiviert war.

VLAN10 erhielt wie zuvor die MacBooks im Keller eine IP-Adresse zugewiesen. Und siehe da: Noch bevor wir die Adresse des Splash Page manuell eingeben konnten, erschien auf Edge … wie von Geisterhand … die Splash Page!!! Heureka!

Ich glaube wir hatten zu dem Zeitpunkt bereits versucht, die Swisscom-Homepage anzusurfen, und ich weiss nicht, ob das die Anzeige der Splash Page ausgelöst, oder zumindest beschleunigt hat.

Registration über Splash Page

Ins Formular der Splash Page mussten nun drei Informationen eingetragen werden:

  • Die ID der OTO-Dose
  • Ein einmaliger Access Code, den der Bekannte von Fiber7 via Email erhalten hatte
  • (vergessen)

Obwohl in der Anleitung von Fiber7 stand, dass man nach dem Versand des Formulars ruhig einen Kaffee trinken gehen könnte, da die Registration bis zu 30 Minuten dauern würde, hatten wir gefühlt nach maximal 10 Minuten die Antwort: Anschluss aufgeschaltet!

Letzte Schritte

Als letzte Aktion deaktivierten wir nun VLAN10 auf der ZyWALL, und aktivierten VLAN11. Anschliessend löste der Bekannte über das ZyWALL Web-Interface die PPPoE-Einwahl aus, und tada, die Weltkugel leuchtete kurz darauf in Grün, und der Bekannte konnte im Internet surfen.

ifconfig.co

Um sicher zu gehen dass wir tatsächlich über Fiber7 ins Internet gelangten, rief ich ifconfig.co auf — und dort stand schwarz-auf-weiss: Init7. Heureka!

Obligatorisch: Speedtest

Schlussendlich lösten wir auch noch einen Speedtest aus:

Tags: , , , , , , , ,
Labels: IT

Keine Kommentare | neuen Kommentar verfassen

Mittwoch, 4. September 2024

UniFi-Geräten über den UniFi Controller eine fixe IP zuweisen (DHCP Static Lease)

Gestern habe ich das Heimnetzwerk eines Bekannten komplett neu aufgebaut: Kabelmodem in den Bridge/Modem-Modus gesetzt, den dahinter installierten Asus-Router rausgerissen, und die zwei Orbi Mesh Access Points entfernt.

Stattdessen läuft in der Wohnung nun ein UCG-Ultra der direkt am Kabelmodem hängt, gefolgt von einem USW-Ultra-60W, welcher unter anderem drei U6-Mesh über PoE mit Daten und Strom versorgt.

Obwohl nicht zwingend wollte ich den UniFi-Netzwerkkomponente eine fixe IP zuweisen. Das ist im UniFi Controller gar nicht so einfach wie für Netzwerkclients wie Laptops und andere Geräte.

Die folgende Anleitung von Marc Schabacker funktioniert tadellos, und ich habe sie mit der gestrigen Installation bereits an zwei Standorten erfolgreich verwendet:

Static DHCP Reservations for Unifi Devices

Tags: , , , , , , , , ,
Labels: IT

Keine Kommentare | neuen Kommentar verfassen

Mittwoch, 23. Februar 2022

dhcpd: Unable to add forward map from X to 1.2.3.4: SERVFAIL

Ich habe meine lokalen DHCP-Server so konfiguriert, dass Geräte mit ihrem lokalen DNS-Namen auch in named (BIND9) registriert werden.

Gelegentlich treffe ich folgendes Problem an:

Feb 23 01:15:15 SERVER dhcpd[2746174]: Unable to add forward map from apple-tv.domain.tld. to 10.1.2.3: SERVFAIL

Wie ich mittlerweile nach unzähligen verbratenen Stunden herausgefunden habe hängt dies mit diesem beschissenen AppArmor zusammen. Obwohl ich es jeweils deinstalliere, taucht es nach Updates wieder im System auf.

Die Lösung:

# apt-get remove apparmor
# systemctl stop apparmor
# systemctl disable apparmor

Quelle: How to disable and remove AppArmor in Ubuntu and Debian

Je nach Tageslaune ist dann auch noch ein Reboot nötig.

Mittlerweile habe ich eine monit-Regel eingerichtet, die mich alarmiert, wenn ein solcher Log-Event in /var/log/dhcp.log auftaucht.

(Auf meiner Todo-Liste steht, die Installation mittels apt zu verbieten)

Tags: , , , , , , ,
Labels: IT

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 30. Juni 2019

Irgendwas ist am UniFi Firmware 4.0.42.10433 nicht ganz koscher

Bis vor wenigen Wochen hatte ich nie irgendwelche Probleme mit Firmware-Upgrades für UniFi-Produkte. Das hat sich mit Version 4.0.42.10433 geändert: Ich verzeichne mindestens zwei Probleme mit diesem Upgrade.

DHCP funktioniert mit gewissen Geräten nicht mehr

Bei mir macht dieses Update auf einem UniFi AP-AC-Mesh wie auch auf einem UniFi AP-AC-LR im Zusammenspiel mit DHCP-Anfragen Probleme. Das Resultat: Die Geräte sind zwar im Controller sichtbar, können aber keine IP beziehen.

In der Controller-App für iOS sieht man bei solchen Geräten die Warnung:

„DHCP Timeout. Please check that your DHCP server is accessible and properly configured“

Die meisten Geräte wie Laptops, Smartphones und Tablets können mit DHCP IPs beziehen; Probleme haben derzeit nur zwei Geräte(typen) gemacht: Ein Canon Selphy sowie ein Industrieboard für einen Wechselrichter. Meine derzeitige Vermutung: Auf diesen Dingern läuft eine ältere Linux-Version und ein älterer DHCP-Client, der irgendwie nicht (mehr) mit Antworten des DHCP-Servers über UniFi-Komponenten klarkommt, oder UniFi blockiert Antworten auf DHCP-Requests dieser Clients aus irgendeinem Grund.

Das zeigt sich daran, dass in den DHCP-Server-Logs unzählige folgende Meldungen auftauchen:

...
Jun 30 18:16:31 DHCPSERVER dhcpd[19637]: DHCPOFFER on 10.1.2.225 to 00:00:00:00:00:00 (SELPHY_DHCP_INSTANCE_0) via eth0
Jun 30 18:17:36 DHCPSERVER dhcpd[19637]: DHCPDISCOVER from 00:00:00:00:00:00 (SELPHY_DHCP_INSTANCE_0) via eth0
Jun 30 18:17:37 DHCPSERVER dhcpd[19637]: DHCPOFFER on 10.1.2.225 to 00:00:00:00:00:00 (SELPHY_DHCP_INSTANCE_0) via eth0
Jun 30 18:18:42 DHCPSERVER dhcpd[19637]: DHCPDISCOVER from 00:00:00:00:00:00 (SELPHY_DHCP_INSTANCE_0) via eth0
Jun 30 18:18:43 DHCPSERVER dhcpd[19637]: DHCPOFFER on 10.1.2.225 to 00:00:00:00:00:00 (SELPHY_DHCP_INSTANCE_0) via eth0
Jun 30 18:19:48 DHCPSERVER dhcpd[19637]: DHCPDISCOVER from 00:00:00:00:00:00 (SELPHY_DHCP_INSTANCE_0) via eth0
Jun 30 18:19:49 DHCPSERVER dhcpd[19637]: DHCPOFFER on 10.1.2.225 to 00:00:00:00:00:00 (SELPHY_DHCP_INSTANCE_0) via eth0
Jun 30 18:20:54 DHCPSERVER dhcpd[19637]: DHCPDISCOVER from 00:00:00:00:00:00 (SELPHY_DHCP_INSTANCE_0) via eth0
Jun 30 18:20:55 DHCPSERVER dhcpd[19637]: DHCPOFFER on 10.1.2.225 to 00:00:00:00:00:00 (SELPHY_DHCP_INSTANCE_0) via eth0
Jun 30 18:22:00 DHCPSERVER dhcpd[19637]: DHCPDISCOVER from 00:00:00:00:00:00 (SELPHY_DHCP_INSTANCE_0) via eth0
Jun 30 18:22:01 DHCPSERVER dhcpd[19637]: DHCPOFFER on 10.1.2.225 to 00:00:00:00:00:00 (SELPHY_DHCP_INSTANCE_0) via eth0
Jun 30 18:23:06 DHCPSERVER dhcpd[19637]: DHCPDISCOVER from 00:00:00:00:00:00 (SELPHY_DHCP_INSTANCE_0) via eth0
Jun 30 18:23:07 DHCPSERVER dhcpd[19637]: DHCPOFFER on 10.1.2.225 to 00:00:00:00:00:00 (SELPHY_DHCP_INSTANCE_0) via eth0
Jun 30 18:24:12 DHCPSERVER dhcpd[19637]: DHCPDISCOVER from 00:00:00:00:00:00 (SELPHY_DHCP_INSTANCE_0) via eth0
Jun 30 18:24:13 DHCPSERVER dhcpd[19637]: DHCPOFFER on 10.1.2.225 to 00:00:00:00:00:00 (SELPHY_DHCP_INSTANCE_0) via eth0
Jun 30 18:25:18 DHCPSERVER dhcpd[19637]: DHCPDISCOVER from 00:00:00:00:00:00 (SELPHY_DHCP_INSTANCE_0) via eth0
Jun 30 18:25:19 DHCPSERVER dhcpd[19637]: DHCPOFFER on 10.1.2.225 to 00:00:00:00:00:00 (SELPHY_DHCP_INSTANCE_0) via eth0
Jun 30 18:26:24 DHCPSERVER dhcpd[19637]: DHCPDISCOVER from 00:00:00:00:00:00 (SELPHY_DHCP_INSTANCE_0) via eth0
...

Syslog geflutet

Der UniFi AP-AC-Mesh an einem Standort brachte meinen ELK-Cluster für das Sammeln von Syslog-Meldungen aus allen Sites fast zum Glühen, nachdem die neue Firmware installiert war und der Access Point neu gebootet hatte.

Das Gerät sendete folgende Meldung 29 Mal pro Sekunde an den Syslog-Server:

<4> Jun 10 16:00:00 unifi.site.domain.local U7MSH,788a20263e00,v4.0.42.10433 kernel: [103146.842183] [wifi1] FWLOG: [105639111] VDEV_MGR_DEBID_DEFINITION_START ( 0x3, 0x40, 0x1, 0x6 )

Sobald ich wieder die alte Firmware (4.0.21.9965) installiert hatte, hörte die Log-Flut auf.

In Kibana ist die Flutwelle gut ersichtlich …

… welche sich auch in der CPU-Auslastung wiederspiegelt:

Auch Smokeping zeigt, dass das Gerät mit dem neuen Firmware eine deutlich höhere Latenz bei ICMP Ping Requests aufweist:

Ein anderer Benutzer hatte dieses Phänomen bereits im März 2019 beobachtet und dies in einem Beitrag im offiziellen Support-Forum kundgetan: WAL_DBGID_SECURITY_ALLOW_DATA and VDEV_MGR_DEBID_DEFINITION_START — leider ohne Lösung.

Um das Problem ohne Downgrade des Firmwares zu beheben, habe ich meine rsyslog-Konfiguration, welche die Meldungen lokal in Empfang nimmt und an ELK weiterleitet, folgendermassen angepasst:

/etc/rsyslog.conf

...
# EMERGENCY 2019-06-10
if $msg contains 'VDEV_MGR_DEBID_DEFINITION_START' then {
    /dev/null
    stop
}

# Send all logs to ELK server
*.* @10.1.2.3:514
...

Tags: , , , , , ,
Labels: IT

1 Kommentar | neuen Kommentar verfassen

Sonntag, 15. Mai 2016

Synologys Diskstation, nmbd und 100 Prozent CPU-Auslastung

Gestern musste ich feststellen, dass meine Synology Diskstation seit ein paar Wochen eine extrem hohe CPU-Auslastung und Linux Load Average aufwies. Cacti ist für eine Analyse sehr nützlich, da die Werte historisiert und in Graphen ausgegeben werden können:

Synology Diskstation CPU Usage Cacti

Synology Diskstation Load Average Cacti

Wieso sich diese Änderung urplötzlich ergeben hat, konnte ich bis jetzt nicht eruieren.

Über SSH und mit Hilfe von top stellte ich rasch fest, dass der Prozess /usr/bin/nmbd -D permanent alle verfügbare CPU-Kapazität auffrass. Was zum Teufel?

Ein Blick in /var/log/samba/log.nmbd, welches mehrere MBs umfasst, zeigte die Ursache des Übels: Die Log-Datei war voller Einträge in der folgenden Form, und mehrmals pro Sekunde kamen neue identische Einträge dazu:

...
../source3/nmbd/nmbd_incomingrequests.c:213: [2016/05/15 01:00:37.670697, all 0, pid=18689] process_name_registration_request
  process_name_registration_request: unicast name registration request received for name XEROX PHASER 32<20> from IP 10.1.2.3 on subnet UNICAST_SUBNET. Error - should be sent to WINS server
...

Die NetBIOS-Komponente in unserem Xerox Phaser 3250DN muss von wahrlichen Profis programmiert worden sein …

Sobald ich den Drucker ausschaltete, beruhigte sich die Diskstation sofort und die CPU-Auslastung wie auch die Load Average sanken auf den langfristig tiefen Wert.

Das Problem löste ich mit folgenden Kniffen:

Samba installieren und als WINS-Server konfigurieren

Auf einem Intel NUC, der mir hier als Linux-Server dient (Beispiel-IP: 10.1.2.4), installierte ich Samba und konfigurierte es folgendermassen, damit Samba sich neu als WINS-Server im Netzwerk anpreist:

/etc/smb.conf

...
[global]
   netbios name = SERVERNAME
   server string = Samba %v on (%L)
   workgroup = WORKGROUP
   wins support = yes
   dns proxy = no
   local master = yes
   os level = 34
   preferred master = yes
...

Quelle: Chapter 7. Name Resolution and Browsing sowie Using Samba: 4.4 Server Configuration

WINS-Server mit DHCP bekanntgeben

/etc/dhcp/dhcpd.conf

...
option netbios-name-servers 10.1.2.4;
...

Anschliessend musste der DHCP-Server noch frisch gestartet werden:

# systemctl stop isc-dhcp-server
# systemctl start isc-dhcp-server

Die Desktop-Clients erhielten den neuen WINS-Server mittels eines „Renew DHCP Lease“ frisch über; beim Drucker führte ich einen Kaltstart durch, um auf Nummer sicher zu gehen.

WINS-Server auf Synology DiskStation einstellen

  1. Synology DiskStation Admin-Oberfläche im Browser öffnen
  2. Control Panel
  3. File Services
  4. Advanced Settings
  5. WINS Server: 10.1.2.4

Tags: , , , , , , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Dienstag, 20. Mai 2014

Unter DD-WRT DNS-Server per DHCP an die Clients weitergeben

Dies erledigt man folgendermassen:

  1. Services
  2. Services
  3. DNSMasq
  4. Additional DNSMasq options
dhcp-option=6, 10.0.1.10, 195.186.4.111

DD-WRT - Services - Services - DNSMasq

Quelle: ISP DNS-Servers

10.0.1.10 ist mein lokaler DNS-Server, welche bestimmte Adressen intern anders auflöst als aus dem Internet. Bei 195.186.4.111 handelt es sich um einen DNS-Server von Swisscom (ex-Bluewin) und ist als Fallback gedacht, wenn 10.0.1.10 nicht reagieren sollte (10.0.1.10 leitet DNS-Anfragen, für welche er keine Authorität hat, transparent an denselben DNS-Server weiter).

Tags: , , , ,
Labels: IT

Keine Kommentare | neuen Kommentar verfassen