Messages

Was APs angeht kann ich Aruba Instant On (https://www.arubainstanton.com/de) empfehlen. Habe die AP22er (26 St.) und AP17er (2 St.) seit etlichen Jahren an insgesamt sieben Standorten im Einsatz (in Verbindung mit 1930er/1960er Switches). Bisher absolut zufrieden / keine Probleme. 6 AP22 laufen in einem Club bei recht sportlichen Temperaturen.

PS: Stromversorgung per POE oder Netzteil (Indoor-Modelle).

Ohe - alles zusammengenommen "spornt" das nicht gerade zu einem solchen Umstieg an, auch wenn "technisch" sicherlich eine bessere Lösung als Doppel-NAT wegen einer Vorgeschalteten FRITZ!Box.

Mit der Vodafone Station im Bridge-Mode hat man ja kein doppeltes NAT - ist dann quasi einfach nur ein Modem.

Hi,

I have Internet via Vodafone cable and use the Vodafone station in bridge mode. From time to time there is a WAN failure and the Internet connection in the Opnsense was automatically restored after the WAN connection in the modem was restored. Since one of the last updates - presumably to 24.1.9_x - this no longer works. I have to restart either the modem or the Opnsense to re-establish the connection. Until then, the log is flooded in an endless loop with entries like these:

Code Select Expand

2024-06-28T08:17:59 Notice opnsense /usr/local/etc/rc.newwanip: Failed to detect IP for interface wan
2024-06-28T08:17:58 Notice dhclient dhclient-script: Reason FAIL on igb0 executing
2024-06-28T08:17:57 Notice dhclient dhclient-script: New Routers (igb0): 88.134.72.254
2024-06-28T08:17:56 Notice dhclient dhclient-script: New Routers (igb0): 88.134.72.254
2024-06-28T08:17:56 Notice dhclient dhclient-script: New Broadcast Address (igb0): 88.134.72.255
2024-06-28T08:17:56 Notice dhclient dhclient-script: New Subnet Mask (igb0): 255.255.255.0
2024-06-28T08:17:56 Notice dhclient dhclient-script: New IP Address (igb0): xx.xxx.xx.xx
2024-06-28T08:17:56 Notice dhclient dhclient-script: Reason TIMEOUT on igb0 executing
2024-06-28T08:17:49 Notice kernel arprequest_internal: cannot find matching address
2024-06-28T08:17:38 Notice kernel arprequest_internal: cannot find matching address
2024-06-28T08:17:19 Notice kernel arprequest_internal: cannot find matching address
2024-06-28T08:17:06 Notice kernel arprequest_internal: cannot find matching address
2024-06-28T08:17:01 Notice kernel arprequest_internal: cannot find matching address
2024-06-28T08:16:59 Notice kernel arprequest_internal: cannot find matching address
2024-06-28T08:16:58 Notice kernel arprequest_internal: cannot find matching address
2024-06-28T08:16:43 Notice opnsense /usr/local/etc/rc.newwanip: Failed to detect IP for interface wan
2024-06-28T08:16:43 Notice dhclient dhclient-script: Reason FAIL on igb0 executing
2024-06-28T08:16:41 Notice dhclient dhclient-script: New Routers (igb0): 88.134.72.254
2024-06-28T08:16:40 Notice dhclient dhclient-script: New Routers (igb0): 88.134.72.254
2024-06-28T08:16:40 Notice dhclient dhclient-script: New Broadcast Address (igb0): 88.134.72.255
2024-06-28T08:16:40 Notice dhclient dhclient-script: New Subnet Mask (igb0): 255.255.255.0
2024-06-28T08:16:40 Notice dhclient dhclient-script: New IP Address (igb0): xx.xxx.xx.xx
2024-06-28T08:16:40 Notice dhclient dhclient-script: Reason TIMEOUT on igb0 executing
2024-06-28T08:16:23 Notice kernel arprequest_internal: cannot find matching address
2024-06-28T08:16:03 Notice kernel arprequest_internal: cannot find matching address
2024-06-28T08:15:53 Notice kernel arprequest_internal: cannot find matching address
2024-06-28T08:15:47 Notice kernel arprequest_internal: cannot find matching address
2024-06-28T08:15:43 Notice kernel arprequest_internal: cannot find matching address
2024-06-28T08:15:42 Notice kernel arprequest_internal: cannot find matching address

Does anyone have any ideas?

I replaced my Fritz! box at home with a DEC740 a few years ago. There was a significant improvement in latency here, but I no longer have any exact data from that time. The busier the network was here at home, the greater the advantage of the DEC740.

Here is a screenshot (quality/WAN) of our DEC3850 from the data center. Monitoring goes to the ISP gateway.

In der Vodafone-Station wird sowohl Hardware von Arris als auch von Technicolor verbaut. Mit den Arris-Geräten hatte ich in der Vergangenheit viele Probleme, habe mir beim letzten Tausch extra eine mit Technicolor-Innenleben zusenden lassen. Läuft jetzt seit ca. 1.5 Jahren weitgehend unauffällig im Bridge-Mode.

EDIT: Gerade gesehen, dass es auch welche von Commscope gibt.

Von einem selbst gekauften Modem würde ich bei Vodafone abraten, da die dann quasi keinen Support mehr leisten, so lange dein eigenes Gerät angeschlossen ist.

We use "generic" modules in all our DECs without any problems.

My DEC740 is completely original - nothing has been modified. Connected to the switch via 10G DAC cable and via 1G LAN to the cable modem (Vodafone 1000/50).

Hey,

my DEC740 is located in a network cabinet in the basement. It runs a household with three people including two home office workstations, traffic shaping, OpenVPN and various VLANs. It's currently 16°C in the basement and the temperature of the DEC740 fluctuates somewhere between 33 and 35°C throughout the day with a bandwidth used of between 1 and 50 Mbps.

Thanks @meyergru - that pointed me to the right direction. There were several devices in my IOT vlan spamming the firewall logs with ntp requests to a not reachable host. A restart of these devices solved this problem - and now also the ARC size seems to be under control again.

Yes, I know that ZFS uses free memory for caching, but I find it unusual that
the ARC size is growing till most available memory is used - then dropping nearly
all used RAM and starting to grow again. In an endless loop, producing sawtooth
graphs. The DEC740 is running in my home - idling most time.

The two DEC3850 running in our company (opnsense business) don't show this
behavior - both with a quite stable ARC size around 2 GB.

Small update - the ARC size just dropped down to 113 MB and starts growing again.

Hey,

I'm currently running 23.7.8_1 on a DEC740 and noted, that the ARC size is growing continuously. I don't know after which update that started exactly - I think it was 23.7.6, but I may be wrong. After a reboot it looks "normal" with about 300 MB ARC size, but then it starts growing. Yesterday it was around 2050 MB, just now I see 2385 MB. So currently the total RAM usage is 3263 MB (82%).

Is this expected or it here something going wrong?

The health check looks ok.

Code Select Expand

***GOT REQUEST TO AUDIT HEALTH***
Currently running OPNsense 23.7.8_1 at Wed Nov 15 16:28:09 CET 2023
>>> Root file system: zroot/ROOT/default
>>> Check installed kernel version
Version 23.7.8 is correct.
>>> Check for missing or altered kernel files
No problems detected.
>>> Check installed base version
Version 23.7.8 is correct.
>>> Check for missing or altered base files
No problems detected.
>>> Check installed repositories
OPNsense
>>> Check installed plugins
os-ddclient 1.16_2
os-mdns-repeater 1.1_1
>>> Check locked packages
No locks found.
>>> Check for missing package dependencies
Checking all packages: .......... done
>>> Check for missing or altered package files
Checking all packages: .......... done
>>> Check for core packages consistency
Core package "opnsense" has 69 dependencies to check.
Checking packages: ...................................................................... done
***DONE***

Super, danke für den schnellen Fix!

Hey Franco,

danke für die Info.

Ich bin schon auf 23.7 - also immer noch aktuell das Problem.

Moin,

ich nutze Duck DNS.

In der Konfiguration als Service 'Duck DNS' auswählen, als Benutzernamen deine E-Mail Adresse und als Passwort deinen Duck DNS Token, der nach dem Login oben bei Duck DNS angezeigt wird. Dann noch das entsprechende Interface fürs Monitoring auswählen - bei mir 'WAN'.

Allerdings scheint der ddclient aktuell nicht richtig mit Duck DNS zu funktionieren. Das Log sagt...

Code Select Expand

FAILED: updating xxx.duckdns.org: Server said: '0'