[OpenWRT] Ervaringen & Discussie

[Borromini]

Op main zouden die issues opgelost moeten zijn, misschien dat die nog spelen op 25.12, maar dat kan ik niet bevestigen, dat is een testapparaat hier. Sowieso is main momenteel de beste keuze voor die SoCs. Er is zoveel aangepast aan die code dat dat niet zomaar te backporten is naar 25.12 (laat staan 24.10).

[InjecTioN]

Borromini schreef op zaterdag 23 mei 2026 @ 08:49:
Op main zouden die issues opgelost moeten zijn, misschien dat die nog spelen op 25.12, maar dat kan ik niet bevestigen, dat is een testapparaat hier. Sowieso is main momenteel de beste keuze voor die SoCs. Er is zoveel aangepast aan die code dat dat niet zomaar te backporten is naar 25.12 (laat staan 24.10).

Ik zie het inderdaad! https://git.openwrt.org/openwrt/openwrt/log/?qt=grep&q=xgs1250

Ik heb zelfs de A1 variant die blijkbaar sinds 24.10 al support blijkt te hebben voor o.a. SFP+ (aldus https://openwrt.org/toh/zyxel/xgs1250-12)

10GbE is supposed to work, SFP+ works in 24.10

Ergens in de aankomende tijd eens een moment zien te nemen om ook deze ZyXEL te gaan voorzien van OpenWrt dan. Die originele firmware is imo helaas echt vergelijkbaar met de UI van een aardappel (en momenteel ook nog niet consistent met de rest van mijn OpenWrt devices). Aan de hobby dan maar!

[_JGC_]

Net de U6 voorzien van OpenWRT. Dat had ik veel eerder mogen doen...

Eerst al een hel om uit te zoeken waar ik de SSH credentials in de controller instel, dat verandert blijkbaar bij elke versie, hadden ze nu achter een uitschuif menu verstopt. Login, firmware dd'en, rebooten, laptop IP aanpassen, firmware flashen en klaar. Daarna DHCP server uit, IP goed instellen en wifi netwerken opnieuw aanmaken en klaar.
Morgen de US-8-60W omwisselen voor de GS1900-10HP en dan kan de Unifi controller weg.

Wel grappig dat mijn ESP32 in de warmtepompcontroller met slecht signaal de hele tijd de verbinding dropt en uiteindelijk niet meer wil verbinden, en vanaf het moment dat ik het SSID instel op OpenWRT komt dat ding weer online zonder drops. SNR is ook een stuk beter dan met de stock firmware.

[Borromini]

InjecTioN schreef op zaterdag 23 mei 2026 @ 15:13:
[...]

Ik zie het inderdaad! https://git.openwrt.org/openwrt/openwrt/log/?qt=grep&q=xgs1250

Ik heb zelfs de A1 variant die blijkbaar sinds 24.10 al support blijkt te hebben voor o.a. SFP+ (aldus https://openwrt.org/toh/zyxel/xgs1250-12)

Klopt, ik heb ook de A1. En ik heb die info destijds op de wiki gezet, maar toen was de ondersteuning nog heel pril. Die lijkt ondertussen niet meer te zijn bijgewerkt om de huidige status te reflecteren .

[amarok]

Davema schreef op vrijdag 22 mei 2026 @ 14:13:
Zijn er meer mensen die last hebben om Odido glasvezel werkend te houden op de nieuwe Openwrt 25.12, waar dit met Openwrt 24.10 direct prima ging? Zonder instellen van clientID krijg ik geen IPV4 meer. Na instellen werkt het wel voor ca. 1 week.

https://forum.openwrt.org/t/problem-with-dhcp-client-and-forced-clientid-in-v25-12/247164

Nee, dat herken ik niet. Draai hier laatste versie van OpenWrt 25.12. Voor Odido maak ik geen gebruik van clientid. Verbinding is al weken stabiel en ook sinds laatste reboot in verband met firmware update. Dat is acht dagen geleden.

Odido wordt hier (Rotterdam) geleverd over ODF.

Configuratie:

option hostname ‘*’ —> do not send hostname during dhcp request.

[ Voor 21% gewijzigd door amarok op 27-05-2026 15:28 ]

[Davema]

amarok schreef op woensdag 27 mei 2026 @ 15:05:
[...]

Nee, dat herken ik niet. Draai hier laatste versie van OpenWrt 25.12. Voor Odido maak ik geen gebruik van clientid. Verbinding is al weken stabiel en ook sinds laatste reboot in verband met firmware update. Dat is acht dagen geleden.

Odido wordt hier (Rotterdam) geleverd over ODF.

Configuratie:

[Afbeelding] option hostname ‘*’ —> do not send hostname during dhcp request.

Top, hiermee werkt het inderdaad nu ook en heb ik geen client ID meer nodig. Ik heb nu in de laatste Openwrt 25.12.4 mijn /etc/config/network aangepast. Hierbij was de clientid 01 gevolgd door mijn WAN MAC adress (hier beetje aangepast). Ik krijg met de aangepast setting ook direct een IPV4 van Odido en hoop dat het nu wel langer dan een week blijft werken. (reboot van NT was niet nodig). Bedankt!

Aangepast van:

code: /etc/config/network

config interface 'wan'
        option device 'eth1.300'
        option proto 'dhcp'
        option clientid '014568D5B318G6'
        option multipath 'off'

Naar:

code: /etc/config/network

config interface 'wan'
        option device 'eth1.300'
        option proto 'dhcp'
        option delegate '0'
        option hostname '*'

Openwrt wiki ook maar gelijk even aangepast, want hier liep ik zelf behoorlijk tegenaan. https://openwrt.org/docs/guide-user/network/wan/isp-configurations#odido

[ Voor 7% gewijzigd door Davema op 27-05-2026 21:12 ]

[_JGC_]

Switch en Unifi U6 Lite over op OpenWRT, controller kan weg... geen data meer naar de USA

Ben benieuwd wat vannacht mijn sluipverbruik wordt. De US-8-60W die ik uit de meterkast viste kan je een ei op bakken, de Zyxel GS1900-10HP wordt nauwelijks warm.

[Davema]

Na 8 dagen online kan ik ook bevestigen dat option hostname '*' toevoegen inderdaad de oplosing is om Odido werkend te houden met IPv4.

[Borromini]

_JGC_ schreef op vrijdag 29 mei 2026 @ 17:28:
Ben benieuwd wat vannacht mijn sluipverbruik wordt. De US-8-60W die ik uit de meterkast viste kan je een ei op bakken, de Zyxel GS1900-10HP wordt nauwelijks warm.

Als ik zie wat voor een joekel van een heatsink er in die US-8-60W zit... En dan heeft de GS1900-10HP nog 'ns twee SFP-poorten ook .

Heel tevreden van mijn GS1900-10HP hier (en heel blij dat er OpenWrt op draait ).

[_JGC_]

Borromini schreef op donderdag 4 juni 2026 @ 23:39:
[...]

Als ik zie wat voor een joekel van een heatsink er in die US-8-60W zit... En dan heeft de GS1900-10HP nog 'ns twee SFP-poorten ook .

Heel tevreden van mijn GS1900-10HP hier (en heel blij dat er OpenWrt op draait ).

Scheelde een watt of 15... en die SFPs gebruik ik niet overigens, misschien ooit, maar voor nu niet.

De US-8-60W kon je een ei op bakken.

Heb tegelijk de controller afgesloten, dus een deel van de besparing zit ook op CPU verbruik en netwerkverkeer vanwege de controller.

[Zenix]

Borromini schreef op donderdag 4 juni 2026 @ 23:39:
[...]

Als ik zie wat voor een joekel van een heatsink er in die US-8-60W zit... En dan heeft de GS1900-10HP nog 'ns twee SFP-poorten ook .

Heel tevreden van mijn GS1900-10HP hier (en heel blij dat er OpenWrt op draait ).

Ik heb die switch ook, werkt LACP en de SFP poorten ook?

[_JGC_]

Zenix schreef op vrijdag 5 juni 2026 @ 19:00:
[...]

Ik heb die switch ook, werkt LACP en de SFP poorten ook?

SFP zou moeten werken, LACP vrijwel zeker niet.

[Borromini]

SFP werkt idd gewoon. Link aggregation tot op zekere hoogte, zie:

https://forum.openwrt.org/t/support-for-rtl838x-and-rtl93xx-based-managed-switches/57875/4284

Moet je wel main snapshots installeren, SFP werkt op 25.12 maar bonding lijkt me twijfelachtig.

[ Voor 14% gewijzigd door Borromini op 06-06-2026 11:11 ]

[Chris.nl]

https://openwrt.org/releases/25.12/notes-25.12.5 komt eraan.

This release fixes several remotely triggerable vulnerabilities in core network services that are enabled by default. Updating is strongly recommended.

-edit- inmiddels aangekondigd

[ Voor 6% gewijzigd door Chris.nl op 01-07-2026 13:35 ]

[Brent]

Ik heb al een tijd een issue met OpenWRT routers. Ik had eerst de welbekende Archer maar omdat die het euvel kreeg opgestapt naar een (set) D-Link M32's. Zelfde.

Wat er gebeurd is dat het internet wegvalt, en hiermee ook het LAN. Soms. Reboot is altijd herstel, maar ook alleen een reboot helpt. Sowieso, zonder internet, lijkt hij geen LAN in stand te houden: apparaten krijgen geen DHCP lease meer en zien elkaar niet.

Eigenlijk een supervanilla config: hij hangt achter de router van KPN en heeft Wifi uiteraard ingesteld. Wat kan het zijn, gezien het feit dat het op verschillende hardware lijkt voor te komen?

[sweetdude]

Brent schreef op maandag 6 juli 2026 @ 15:46:
Ik heb al een tijd een issue met OpenWRT routers. Ik had eerst de welbekende Archer maar omdat die het euvel kreeg opgestapt naar een (set) D-Link M32's. Zelfde.

Wat er gebeurd is dat het internet wegvalt, en hiermee ook het LAN. Soms. Reboot is altijd herstel, maar ook alleen een reboot helpt. Sowieso, zonder internet, lijkt hij geen LAN in stand te houden: apparaten krijgen geen DHCP lease meer en zien elkaar niet.

Eigenlijk een supervanilla config: hij hangt achter de router van KPN en heeft Wifi uiteraard ingesteld. Wat kan het zijn, gezien het feit dat het op verschillende hardware lijkt voor te komen?

is een reboot het enige wat het oplost?
of is een herstart van de Lan / en of Wan verbinding ook voldoende?

[Muis666]

Brent schreef op maandag 6 juli 2026 @ 15:46:
Ik heb al een tijd een issue met OpenWRT routers. Ik had eerst de welbekende Archer maar omdat die het euvel kreeg opgestapt naar een (set) D-Link M32's. Zelfde.

Wat er gebeurd is dat het internet wegvalt, en hiermee ook het LAN. Soms. Reboot is altijd herstel, maar ook alleen een reboot helpt. Sowieso, zonder internet, lijkt hij geen LAN in stand te houden: apparaten krijgen geen DHCP lease meer en zien elkaar niet.

Eigenlijk een supervanilla config: hij hangt achter de router van KPN en heeft Wifi uiteraard ingesteld. Wat kan het zijn, gezien het feit dat het op verschillende hardware lijkt voor te komen?

Verkeerde configuratie? Je geeft niet aan of je de OpenWRT router als router gebruikt (aangesloten op WAN en met andere range dan 192.168.2.xxx) en dus met dubbele NAT of als switch/accespoint (aangesloten op LAN poort) en dus wel op range 192.168.2.xxx.

[Brent]

sweetdude schreef op maandag 6 juli 2026 @ 15:51:
[...]

is een reboot het enige wat het oplost?
of is een herstart van de Lan / en of Wan verbinding ook voldoende?

Zeker weet ik het niet, want ik kom er niet meer in, wegens wegvallen verbinding. Ik geloof dat ik eens wel verbinding heb gehouden (op 1 apparaat), en toen kon ik er wel in, maar denk dat ik hem toen in het controlepaneel gewoon reboot heb.

[Brent]

Muis666 schreef op maandag 6 juli 2026 @ 15:56:
[...]

Verkeerde configuratie? Je geeft niet aan of je de OpenWRT router als router gebruikt (aangesloten op WAN en met andere range dan 192.168.2.xxx) en dus met dubbele NAT of als switch/accespoint (aangesloten op LAN poort) en dus wel op range 192.168.2.xxx.

Dubbel NAT. Als switch ook gehad, maar ik wilde graag OpenWRT de leases laten uitgeven, zodat ik enkelen ervan kan vastzetten (server, iot).

[Muis666]

Brent schreef op maandag 6 juli 2026 @ 15:58:
[...]

Dubbel NAT. Als switch ook gehad, maar ik wilde graag OpenWRT de leases laten uitgeven, zodat ik enkelen ervan kan vastzetten (server, iot).

Post eens je /etc/config/network. En je aanname dat OpenWRT geen LAN in stand houdt bij geen Internet klopt niet. Bij mij viel vorige week Internet weg door een omprikactie in de centrale maar mijn LAN draaide vrolijk door...

[D-Three]

Ik heb ook dubbele NAT, werkt probleemloos. Ben je zeker dat beide toestellen op een verschillende IP-range zitten? De modem van mijn provider heeft intern een 10.0.0.0 adres, en dus ook de WAN van de de OpenWRT router. De rest van mijn netwerk zit dan in de 192.168.0.0 range.

[Brent]

Router van KPN: 192.168.2.x, mijne router de default 192.168.1.x.

@Muis666 Ik weet dat het aan OpenWrt ligt want bijv mijn linux server kent zichzelf een loopback (169.xxx) adres toe.

Enige details:

ubus call system board

code:

{
        "kernel": "6.12.87",
        "hostname": "OpenWrt",
        "system": "ARMv8 Processor rev 4",
        "model": "D-Link EAGLE PRO AI M32 A1",
        "board_name": "dlink,eagle-pro-ai-m32-a1",
        "rootfs_type": "squashfs",
        "release": {
                "distribution": "OpenWrt",
                "version": "25.12.4",
                "firmware_url": "https://downloads.openwrt.org/",
                "revision": "r32933-4ccb782af7",
                "target": "mediatek/mt7622",
                "description": "OpenWrt 25.12.4 r32933-4ccb782af7",
                "builddate": "1778712129"
        }
}

cat /etc/config/network

code:

{
        "kernel": "6.12.87",
        "hostname": "OpenWrt",
        "system": "ARMv8 Processor rev 4",
        "model": "D-Link EAGLE PRO AI M32 A1",
        "board_name": "dlink,eagle-pro-ai-m32-a1",
        "rootfs_type": "squashfs",
        "release": {
                "distribution": "OpenWrt",
                "version": "25.12.4",
                "firmware_url": "https://downloads.openwrt.org/",
                "revision": "r32933-4ccb782af7",
                "target": "mediatek/mt7622",
                "description": "OpenWrt 25.12.4 r32933-4ccb782af7",
                "builddate": "1778712129"
        }
}
root@OpenWrt:~# cat /etc/config/network

config interface 'loopback'
        option device 'lo'
        option proto 'static'
        list ipaddr '127.0.0.1/8'

config globals 'globals'
        option dhcp_default_duid '0004cecce475ee7b48419fb0cdbf124d6ae4'
        option ula_prefix 'fdcc:c7f0:bb42::/48'
        option packet_steering '1'

config device
        option name 'br-lan'
        option type 'bridge'
        list ports 'lan1'
        list ports 'lan2'

config interface 'lan'
        option device 'br-lan'
        option proto 'static'
        list ipaddr '192.168.1.1/24'
        option ip6assign '60'

config interface 'wan'
        option device 'wan'
        option proto 'dhcp'

config interface 'wan6'
        option device 'wan'
        option proto 'dhcpv6'
        option reqaddress 'try'
        option reqprefix 'auto'
        option norelease '1'
        option peerdns '0'
        list dns '2a13:1001::86:54:11:11'
        list dns '2620:fe::fe'
        option multipath 'off'

cat /etc/config/wireless

code:

config wifi-device 'radio0'
        option type 'mac80211'
        option phy 'wl0'
        option band '2g'
        option channel '1'
        option htmode 'HT20'
        option cell_density '0'

config wifi-iface 'default_radio0'
        option device 'radio0'
        option network 'lan'
        option mode 'ap'
        option ssid '***'
        option encryption 'psk2'
        option key '***'

config wifi-device 'radio1'
        option type 'mac80211'
        option phy 'wl1'
        option band '5g'
        option channel '36'
        option htmode 'HE80'
        option cell_density '0'

config wifi-iface 'default_radio1'
        option device 'radio1'
        option network 'lan'
        option mode 'ap'
        option ssid '***'
        option encryption 'psk2'
        option key '***'

cat /etc/config/dhcp

code:

config dnsmasq
        option domainneeded '1'
        option boguspriv '1'
        option filterwin2k '0'
        option localise_queries '1'
        option rebind_protection '1'
        option rebind_localhost '1'
        option local '/lan/'
        option domain 'lan'
        option expandhosts '1'
        option nonegcache '0'
        option cachesize '1000'
        option authoritative '1'
        option readethers '1'
        option leasefile '/tmp/dhcp.leases'
        option resolvfile '/tmp/resolv.conf.d/resolv.conf.auto'
        option nonwildcard '1'
        option localservice '1'
        option ednspacket_max '1232'
        option filter_aaaa '0'
        option filter_a '0'
        option serversfile '/var/run/adblock-fast/dnsmasq.servers'

config dhcp 'lan'
        option interface 'lan'
        option start '100'
        option limit '150'
        option leasetime '12h'
        option dhcpv4 'server'
        option dhcpv6 'server'
        option ra 'server'
        option ra_slaac '1'
        list ra_flags 'managed-config'
        list ra_flags 'other-config'

config dhcp 'wan'
        option interface 'wan'
        option ignore '1'
        option leasetime '12h'
        option start '100'
        option limit '150'

config odhcpd 'odhcpd'
        option maindhcp '0'
        option leasefile '/tmp/odhcpd.leases'
        option leasetrigger '/usr/sbin/odhcpd-update'
        option loglevel '4'
        option piodir '/tmp/odhcpd-piodir'
        option hostsdir '/tmp/hosts'

config host
        option name 'ESP-P1'
        option ip '192.168.1.168'
        list mac 'a4:cf:12:be:cf:c6'

config host
        option name 'AWAIR-ELEM-16337C'
        option ip '192.168.1.112'
        list mac '70:88:6b:16:33:7c'

config host
        option name 'servitor'
        option ip '192.168.1.171'
        list mac '40:b0:76:41:a8:5a'

config host
        option name 'OpenWrt'
        option ip '192.168.1.229'
        list mac '88:76:b9:b5:16:69'

config host
        option name 'CIC-edaba96b-84a1-5f0c-96af-aad6d3487e4e'
        option ip '192.168.1.170'
        list mac '1c:50:1e:4d:88:61'

cat /etc/config/firewall

code:

config defaults
        option syn_flood        1
        option input            REJECT
        option output           ACCEPT
        option forward          REJECT
# Uncomment this line to disable ipv6 rules
#       option disable_ipv6     1

config zone
        option name             lan
        list   network          'lan'
        option input            ACCEPT
        option output           ACCEPT
        option forward          ACCEPT

config zone
        option name             wan
        list   network          'wan'
        list   network          'wan6'
        option input            REJECT
        option output           ACCEPT
        option forward          DROP
        option masq             1
        option mtu_fix          1

config forwarding
        option src              lan
        option dest             wan

# We need to accept udp packets on port 68,
# see https://dev.openwrt.org/ticket/4108
config rule
        option name             Allow-DHCP-Renew
        option src              wan
        option proto            udp
        option dest_port        68
        option target           ACCEPT
        option family           ipv4

# Allow IPv4 ping
config rule
        option name             Allow-Ping
        option src              wan
        option proto            icmp
        option icmp_type        echo-request
        option family           ipv4
        option target           ACCEPT

config rule
        option name             Allow-IGMP
        option src              wan
        option proto            igmp
        option family           ipv4
        option target           ACCEPT

# Allow DHCPv6 replies
# see https://github.com/openwrt/openwrt/issues/5066
config rule
        option name             Allow-DHCPv6
        option src              wan
        option proto            udp
        option dest_port        546
        option family           ipv6
        option target           ACCEPT

config rule
        option name             Allow-MLD
        option src              wan
        option proto            icmp
        option src_ip           fe80::/10
        list icmp_type          '130/0'
        list icmp_type          '131/0'
        list icmp_type          '132/0'
        list icmp_type          '143/0'
        option family           ipv6
        option target           ACCEPT

# Allow essential incoming IPv6 ICMP traffic
config rule
        option name             Allow-ICMPv6-Input
        option src              wan
        option proto    icmp
        list icmp_type          echo-request
        list icmp_type          echo-reply
        list icmp_type          destination-unreachable
        list icmp_type          packet-too-big
        list icmp_type          time-exceeded
        list icmp_type          bad-header
        list icmp_type          unknown-header-type
        list icmp_type          router-solicitation
        list icmp_type          neighbour-solicitation
        list icmp_type          router-advertisement
        list icmp_type          neighbour-advertisement
        option limit            1000/sec
        option family           ipv6
        option target           ACCEPT

# Allow essential forwarded IPv6 ICMP traffic
config rule
        option name             Allow-ICMPv6-Forward
        option src              wan
        option dest             *
        option proto            icmp
        list icmp_type          echo-request
        list icmp_type          echo-reply
        list icmp_type          destination-unreachable
        list icmp_type          packet-too-big
        list icmp_type          time-exceeded
        list icmp_type          bad-header
        list icmp_type          unknown-header-type
        option limit            1000/sec
        option family           ipv6
        option target           ACCEPT

config rule
        option name             Allow-IPSec-ESP
        option src              wan
        option dest             lan
        option proto            esp
        option target           ACCEPT

config rule
        option name             Allow-ISAKMP
        option src              wan
        option dest             lan
        option dest_port        500
        option proto            udp
        option target           ACCEPT


### EXAMPLE CONFIG SECTIONS
# do not allow a specific ip to access wan
#config rule
#       option src              lan
#       option src_ip   192.168.45.2
#       option dest             wan
#       option proto    tcp
#       option target   REJECT

# block a specific mac on wan
#config rule
#       option dest             wan
#       option src_mac  00:11:22:33:44:66
#       option target   REJECT

# block incoming ICMP traffic on a zone
#config rule
#       option src              lan
#       option proto    ICMP
#       option target   DROP

# port redirect port coming in on wan to lan
#config redirect
#       option src                      wan
#       option src_dport        80
#       option dest                     lan
#       option dest_ip          192.168.16.235
#       option dest_port        80
#       option proto            tcp

# port redirect of remapped ssh port (22001) on wan
#config redirect
#       option src              wan
#       option src_dport        22001
#       option dest             lan
#       option dest_port        22
#       option proto            tcp

### FULL CONFIG SECTIONS
#config rule
#       option src              lan
#       option src_ip   192.168.45.2
#       option src_mac  00:11:22:33:44:55
#       option src_port 80
#       option dest             wan
#       option dest_ip  194.25.2.129
#       option dest_port        120
#       option proto    tcp
#       option target   REJECT

#config redirect
#       option src              lan
#       option src_ip   192.168.45.2
#       option src_mac  00:11:22:33:44:55
#       option src_port         1024
#       option src_dport        80
#       option dest_ip  194.25.2.129
#       option dest_port        120
#       option proto    tcp

[Muis666]

Brent schreef op maandag 6 juli 2026 @ 18:55:
Router van KPN: 192.168.2.x, mijne router de default 192.168.1.x.

@Muis666 Ik weet dat het aan OpenWrt ligt want bijv mijn linux server kent zichzelf een loopback (169.xxx) adres toe.

Enige details:

...

Ik zie zo snel niets vreemds. Het door jou vermelde gedrag doet mij vermoeden dat de dhcp server eruit vliegt. Ik zou dus een machine met static adres configureren en van daaruit in je router inloggen als het probleem optreedt en dan de logging bekijken.

[Brent]

Muis666 schreef op dinsdag 7 juli 2026 @ 09:07:
[...]
Ik zou dus een machine met static adres configureren en van daaruit in je router inloggen als het probleem optreedt en dan de logging bekijken.

Welke logging specifiek?

[Muis666]

Brent schreef op dinsdag 7 juli 2026 @ 15:21:
[...]

Welke logging specifiek?

Eerst eens logread en dmesg en kijken of je daarin iets vreemds ziet. Je kunt ook checken of de dhcp processen nog draaien met

ps | grep dhcp

[Tom Paris]

Brent schreef op maandag 6 juli 2026 @ 18:55:
Router van KPN: 192.168.2.x, mijne router de default 192.168.1.x.

@Muis666 Ik weet dat het aan OpenWrt ligt want bijv mijn linux server kent zichzelf een loopback (169.xxx) adres toe.

Enige details:

ubus call system board

Ik zou het een tijdje proberen zonder adblock-fast. Het probleem klinkt als een issue met de DHCP server (dnsmasq). Als tijdens een reload van de filters oid door adblock-fast een fout optreedt, kan dnsmasq crashen of niet meer opstarten. Misschien dat je teveel / te grote filterlijsten gebruikt voor je device, of een bug in adblock-fast.

[Brent]

Tom Paris schreef op dinsdag 7 juli 2026 @ 18:03:
[...]


Ik zou het een tijdje proberen zonder adblock-fast. Het probleem klinkt als een issue met de DHCP server (dnsmasq). Als tijdens een reload van de filters oid door adblock-fast een fout optreedt, kan dnsmasq crashen of niet meer opstarten. Misschien dat je teveel / te grote filterlijsten gebruikt voor je device, of een bug in adblock-fast.

Ik had het ook zonder adblock-fast.

Kan het evt nog dhcpv6 zijn? De truuk ipv6 uit te zetten lees ik wel vaker.

[ Voor 7% gewijzigd door Brent op 07-07-2026 19:55 ]

[Zenix]

Brent schreef op dinsdag 7 juli 2026 @ 19:53:
[...]


Ik had het ook zonder adblock-fast.

Kan het evt nog dhcpv6 zijn? De truuk ipv6 uit te zetten lees ik wel vaker.

Het heeft geen zin om van alles te proberen, als je niet weet wat het probleem is. Je kan bij DHCP daemon ook extra logging aanzetten. Zet loglevel maar eens op 7 https://openwrt.org/docs/techref/odhcpd

En dan die log eens bekijken als het met static IP als dat wel goed werkt. Maar persoonlijk snap ik niet waarom je OpenWRT achter de KPN router gebruikt.

[Chris.nl]

@Brent je netwerk config ziet er anders uit als omschreven op https://openwrt.org/docs/..._12_modem_legacy_firmware

Ik zou het in die hoek zoeken. Zou kunnen dat je huidige config wel werkt, maar een andere/betere ook blijft werken.

Vooral

code:

config interface 'wan'
        option device 'wan'

vind ik nu erg kort door de bocht. Je kan bij device ook verwijzen naar 'eth0' (waar ie meestal fysiek op zit).

[ Voor 22% gewijzigd door Chris.nl op 07-07-2026 21:07 ]

[Zenix]

Chris.nl schreef op dinsdag 7 juli 2026 @ 21:04:
@Brent je netwerk config ziet er anders uit als omschreven op https://openwrt.org/docs/..._12_modem_legacy_firmware

Ik zou het in die hoek zoeken. Zou kunnen dat je huidige config wel werkt, maar een andere/betere ook blijft werken.

Vooral

code:

config interface 'wan'
        option device 'wan'

vind ik nu erg kort door de bocht. Je kan bij device ook verwijzen naar 'eth0' (waar ie meestal fysiek op zit).

Dat is afhankelijk van het apparaat. Bij mijn rockchip device is de standaard juist veranderd naar wan en lan in plaats van eth0 en eth1.

[InjecTioN]

Zenix schreef op dinsdag 7 juli 2026 @ 20:25:
[...]

Het heeft geen zin om van alles te proberen, als je niet weet wat het probleem is. Je kan bij DHCP daemon ook extra logging aanzetten. Zet loglevel maar eens op 7 https://openwrt.org/docs/techref/odhcpd

En dan die log eens bekijken als het met static IP als dat wel goed werkt. Maar persoonlijk snap ik niet waarom je OpenWRT achter de KPN router gebruikt.

Een aantal KPN modems hebben helaas geen bridge mode support. Een OpenWrt router in een DMZ plaatsen is dan imho de beste methode.

Overigens lijkt mij inderdaad het statisch IP instellen op een cliënt device wel de beste poging tot slagen te hebben. Op die manier kan je in ieder geval testen of de router überhaupt nog iets doet op die LAN interfaces, wanneer de rest problemen ervaart.

Je kan als eerste kijken of de luci interface te benaderen is, of direct door gaan naar SSH, om met “ps | grep dhcp” (zonder quotes) te zien of de dhcp service nog draait (zoals eerder aangegeven door @Muis666 ). Controleer de output ook eerst even in de werkende situatie, zodat je weet waar je naar zoekt.

Verder inderdaad dhcpv6 met rust laten en absoluut die logs bekijken. Die zijn cruciaal. Mits je er inderdaad nog op kan.

Eerst stap voor stap wat dingen uitsluiten.

[Zenix]

InjecTioN schreef op dinsdag 7 juli 2026 @ 21:22:
[...]

Een aantal KPN modems hebben helaas geen bridge mode support. Een OpenWrt router in een DMZ plaatsen is dan imho de beste methode.

Overigens lijkt mij inderdaad het statisch IP instellen op een cliënt device wel de beste poging tot slagen te hebben. Op die manier kan je in ieder geval testen of de router überhaupt nog iets doet op die LAN interfaces, wanneer de rest problemen ervaart.

Je kan als eerste kijken of de luci interface te benaderen is, of direct door gaan naar SSH, om met “ps | grep dhcp” (zonder quotes) te zien of de dhcp service nog draait (zoals eerder aangegeven door @Muis666 ). Controleer de output ook eerst even in de werkende situatie, zodat je weet waar je naar zoekt.

Verder inderdaad dhcpv6 met rust laten en absoluut die logs bekijken. Die zijn cruciaal. Mits je er inderdaad nog op kan.

Eerst stap voor stap wat dingen uitsluiten.

Modem is wat anders, alleen met DSL zal die een modem hebben. Zie ik persoonlijk geen reden om de KPN router te blijven gebruiken.

Maar verder is troubleshooting een proces van eliminatie, dus stap voor stap verder gaan en niet van alles proberen. Dat heeft geen zin.

[ Voor 8% gewijzigd door Zenix op 07-07-2026 21:42 ]

[InjecTioN]

Zenix schreef op dinsdag 7 juli 2026 @ 21:38:
[...]

Modem is wat anders dan een router, tenzij die DSL heeft, zie ik persoonlijk geen reden om het KPN apparaat te blijven gebruiken.

Correct. Dat heb ik verzuimd op te helderen/heb ik me in versprokenvertypt. Bij DSL spreekt men namelijk wel altijd van een Modem-Router, omdat er bij DSL expliciet spraken is van modulatie en demodulatie.

DSL is inderdaad ook de enige reden om bij KPN de experiabox te gebruiken. Echter kan je die ook vervangen voor een losse DSL modem.

[Tom Paris]

Brent schreef op dinsdag 7 juli 2026 @ 19:53:
[...]


Ik had het ook zonder adblock-fast.

Je dnsmasq config heeft:

code:

option serversfile '/var/run/adblock-fast/dnsmasq.servers'

Dus je vertelt dnsmasq om een externe lijst met domeinen en redirects op te halen. Als die lijst een fout bevat, te groot is, etc. valt dnsmasq om. Daarom eens met de andere adviezen: statisch IP op één client instellen, waarschijnlijk kun je dan gewoon inloggen de logs uitlezen.

[Brent]

Er is sprake van DSL hier. Ik zal adblock dan toch maar uitzetten. Ik heb inmiddels 1 machine op vast ip gezet, nu afwachten op een fout. Helaas zit er soms weken tussen, en soms een paar keer per dag

[Brent]

Een andere vraag. Ik worstel enorm met het opzetten van een iot netwerk met eigen geisoleerde LAN. Heb succesvol een apart SSID, ook een zone die LAN en WAN niet in mag (en LAN wel de IOT zone in), maar apparaten krijgen geen IP adres. Iets gaat niet goed met DHCP dus...

Is een andere, simpelere optie misschien het volgende: geen aparte zone, en ook geen aparte DHCP server (wel een SSID zodat ik wachtwoorden apart kan roteren), maar een heel eenvoudige firewall regel per IOT apparaat:

code:

config rule
    option  name        'IOT web block'
    option  src_mac     '00:11:22:33:44:55'
    option  dest            'wan'
    option  target      'REJECT'

Ik weet nog niet welk IOT device uberhaupt nog goed werkt als ik ze isoleer, dus mogelijk moet ik toch per device weer toegang gaan geven. Bovenstaande is simpel en schaalbaar iig. Is deze regel genoeg? Heb nooit eerder zelf regels geschreven.

[Muis666]

Brent schreef op woensdag 22 juli 2026 @ 09:30:
Een andere vraag. Ik worstel enorm met het opzetten van een iot netwerk met eigen geisoleerde LAN. Heb succesvol een apart SSID, ook een zone die LAN en WAN niet in mag (en LAN wel de IOT zone in), maar apparaten krijgen geen IP adres. Iets gaat niet goed met DHCP dus...

Als je een aparte zone maakt, moet je die ook toevoegen aan /etc/config/dhcp, anders deelt hij daar geen ip adressen uit

[ Voor 5% gewijzigd door Muis666 op 22-07-2026 13:36 ]

[Brent]

Brent schreef op woensdag 22 juli 2026 @ 09:30:
Ik weet nog niet welk IOT device uberhaupt nog goed werkt als ik ze isoleer, dus mogelijk moet ik toch per device weer toegang gaan geven. Bovenstaande is simpel en schaalbaar iig. Is deze regel genoeg? Heb nooit eerder zelf regels geschreven.

Ik heb inmiddels de regel toegevoegd via de GUI. Om heel precies te zijn levert dat het volgen op in /etc/config/firewall:

code:

config rule
        option src '*'
        option dest 'wan'
        list src_mac '00:11:22:33:44:55'
        option target 'REJECT'
        option name 'testblok'
        option enabled '1'

Dit lijkt deels te werken. Met een browser kom ik nergens meer, maar ping 8.8.8.8, 9.9.9.9, 1.1.1.1 en elk extern IP dat ik test werkt wel. Weet iemand wat hier gebeurd?

[Chris.nl]

Brent schreef op vrijdag 24 juli 2026 @ 21:36:
[...]

Ik heb inmiddels de regel toegevoegd via de GUI. Om heel precies te zijn levert dat het volgen op in /etc/config/firewall:

code:

config rule
        option src '*'
        option dest 'wan'
        list src_mac '00:11:22:33:44:55'
        option target 'REJECT'
        option name 'testblok'
        option enabled '1'

Dit lijkt deels te werken. Met een browser kom ik nergens meer, maar ping 8.8.8.8, 9.9.9.9, 1.1.1.1 en elk extern IP dat ik test werkt wel. Weet iemand wat hier gebeurd?

Je hebt geen protocol gedefinieerd? Ik zou ze allemaal gewoon blokkeren door onderstaand regeltje toe te voegen.

code:

list proto 'all'

Daarnaast kan IPv6 verkeer er nu nog door, maar als je alleen een IPv4 wan hebt, lijkt ie me zo waterdicht.

[ Voor 7% gewijzigd door Chris.nl op 25-07-2026 10:13 ]

[Brent]

Chris.nl schreef op zaterdag 25 juli 2026 @ 06:20:
[...]

Je hebt geen protocol gedefinieerd? Ik zou ze allemaal gewoon blokkeren door onderstaand regeltje toe te voegen.

code:

list proto 'all'

Daarnaast kan IPv6 verkeer er nu nog door, maar als je alleen een IPv4 wan hebt, lijkt ie me zo waterdicht.

Dat was m inderdaad, dank!

Hmm, ik heb ook een IPv6 WAN. Wat moet ik er extra voor doen? 'wan' verwijst hier volgens mij (in Luci) naar de WAN bridge waaraan ook wan6 hangt.

[Chris.nl]

Brent schreef op zaterdag 25 juli 2026 @ 08:59:
[...]
Dat was m inderdaad, dank!

Hmm, ik heb ook een IPv6 WAN. Wat moet ik er extra voor doen? 'wan' verwijst hier volgens mij (in Luci) naar de WAN bridge waaraan ook wan6 hangt.

Mijn foutje, je zit idd zo goed. Hier pakt Luci wan en wan6 idd ook als één.

[RudolfR]

Op OpenWRT blokkeer ik advertenties via adblock-fast, maar Hagezi Pro lijst geeft soms problemen:

Deze:
https://cdn.jsdelivr.net/...ts@latest/domains/pro.txt

Toont de melding:
"Package size exceeded the configured limit of 150 MB. Try https://github.com/hagezi...215.56065/domains/pro.txt instead."

Echter die URL geeft geen resultaat.
Kan ik bijv. dit als URL opgeven, of gaat github dan moelijk doen?
https://raw.githubusercon...eads/main/dnsmasq/pro.txt

[Audione0]

Ik weet niet of het al gedeeld is maar ik kwam deze tegen. OpenWRT ondersteuning voor de Asus Zenwifi BT8:
https://openwrt.org/toh/asus/zenwifi_bt8

[ Voor 14% gewijzigd door Audione0 op 07-08-2026 12:49 ]

[Brent]

RudolfR schreef op maandag 3 augustus 2026 @ 20:10:

Echter die URL geeft geen resultaat.
Kan ik bijv. dit als URL opgeven, of gaat github dan moelijk doen?
https://raw.githubusercon...eads/main/dnsmasq/pro.txt

Zou niet weten waarom, er zijn meer scripts die via raw files ophalen. Niet elke 5 minuten checken en lijkt me OK.

[Brent]

Wat is een goede manier om een gasten-SSID/interface in bandbreedte in te perken? Ik zie eigenlijk alleen maar oplossingen die oud zijn op neerkomen op een specifiek ip-adres of mac-adres limitten. Ik wil gewoon alles wat via dat SSID/interface gaat beperken.

[Chris.nl]

Brent schreef op zaterdag 8 augustus 2026 @ 08:23:
Wat is een goede manier om een gasten-SSID/interface in bandbreedte in te perken? Ik zie eigenlijk alleen maar oplossingen die oud zijn op neerkomen op een specifiek ip-adres of mac-adres limitten. Ik wil gewoon alles wat via dat SSID/interface gaat beperken.

Er zijn vast meerdere rivieren die naar de zee stromen, maar hier één manier om 't te doen.

Ik weet niet of je al SQM toepast, doe je dit niet dan zou je dit op de interface die je voor gasten gebruikt kunnen doen.

In onderstaande screenshot pas ik het zelf toe op de PPPoE-wan interface


Hier info over het installeren en instellen.

[Piet91]

Ik dacht vandaag; laat ik eens m'n OpenWRT accesspoints updaten; deze 3: uitvoering: ZyXEL Multy M1 AX1800 (3-pack)

#1. Stond blijkbaar geen Attended Sysupgrade op (raar, maar goed; geÍnstalleerd. Update gedaan en doet weer prima.
#2. Attended Sysupgrade gedaan, die brak af want "OPKG not found" (als ik mij goed herinner). Dom genoeg die in de lijst uitgevinkt en toen leek update goed te gaan, maar hij bleef hangen op "Installing the sysupgrade. Do not unpower device!"
#3 Gaf met Attended Sysupgrade aan dat huidige 23.05.0 de meest recente firmware was. Met Attended Sysupgrade configuration kon ik deze wel updaten. Maar deze gaf daarna zelfde probleem als #2.

#1 is prima bruikbaar, maar #2 en #3 zijn onbereikbaar. Ook via SSH niet (connection timed out).
Ze functioneren wel prima, want er zijn apparaten via wifi mee verbonden en een tweetal camera's die via deze AP's verbonden zijn (deels wifi) streamen ook prima door.

[borft]

Piet91 schreef op dinsdag 18 augustus 2026 @ 16:49:
Ik dacht vandaag; laat ik eens m'n OpenWRT accesspoints updaten; deze 3: uitvoering: ZyXEL Multy M1 AX1800 (3-pack)

#1. Stond blijkbaar geen Attended Sysupgrade op (raar, maar goed; geÍnstalleerd. Update gedaan en doet weer prima.
#2. Attended Sysupgrade gedaan, die brak af want "OPKG not found" (als ik mij goed herinner). Dom genoeg die in de lijst uitgevinkt en toen leek update goed te gaan, maar hij bleef hangen op "Installing the sysupgrade. Do not unpower device!"
#3 Gaf met Attended Sysupgrade aan dat huidige 23.05.0 de meest recente firmware was. Met Attended Sysupgrade configuration kon ik deze wel updaten. Maar deze gaf daarna zelfde probleem als #2.

#1 is prima bruikbaar, maar #2 en #3 zijn onbereikbaar. Ook via SSH niet (connection timed out).
Ze functioneren wel prima, want er zijn apparaten via wifi mee verbonden en een tweetal camera's die via deze AP's verbonden zijn (deels wifi) streamen ook prima door.

de nieuwste openWRT gebruikt geen opkg meer, maar apk. Het advies is, volgens mij, ook een reinstall.

[Piet91]

borft schreef op vrijdag 28 augustus 2026 @ 14:16:
de nieuwste openWRT gebruikt geen opkg meer, maar apk.

Ik hou het niet echt allemaal bij, ook qua updates e.d. niet. Eens in de zoveel tijd kijk ik er eens naar en doe ik een eventuele update. Maar ik lees nu ook hierover inderdaad.

Het advies is, volgens mij, ook een reinstall.

Dat is het punt een beetje; 2 zijn totaal onbereikbaar. Geen webinterface en niet via SSH.
Verder functioneren zoals gezegd prima.

Ik zie dat ik dit probleem eerder heb gehad (Piet91 in "[OpenWRT] Ervaringen & Discussie"), maar geen idee wat ik toen heb gedaan.
I.i.g. geen IP-conflict, want in m'n router hebben ze alledrie hun eigen (vast) IP-adres.

Wanneer ik tijd/zin heb, maar weer eens naar kijken.

[ Voor 9% gewijzigd door Piet91 op 28-08-2026 22:09 ]

[Step5]

Piet91 schreef op vrijdag 28 augustus 2026 @ 21:40:
[...]

Ik hou het niet echt allemaal bij, ook qua updates e.d. niet. Eens in de zoveel tijd kijk ik er eens naar en doe ik een eventuele update. Maar ik lees nu ook hierover inderdaad.

[...]

Dat is het punt een beetje; 2 zijn totaal onbereikbaar. Geen webinterface en niet via SSH.
Verder functioneren zoals gezegd prima.

Ik zie dat ik dit probleem eerder heb gehad (Piet91 in "[OpenWRT] Ervaringen & Discussie"), maar geen idee wat ik toen heb gedaan.
I.i.g. geen IP-conflict, want in m'n router hebben ze alledrie hun eigen (vast) IP-adres.

Wanneer ik tijd/zin heb, maar weer eens naar kijken.

Hoe zijn ze met je router verbonden? Bekabeld of via wifi. Kun je ze pingen? Kun je in de router zien of de dhcp lease wel recent is? Zomaar wat zaken die me te binnen schieten om naar te kijken. Hoe doe je de ssh? Heb je geprobeerd te ssh-en naar je router en vandaar nog een keer ssh naar de AP's?

Ik zou die dingen (sowieso netwerk apparaten) ook een vast IP adres geven op het apparaat zelf en niet op router via dhcp. Maar daar heb je nu niet zo veel aan.

[Piet91]

Step5 schreef op zaterdag 29 augustus 2026 @ 00:03:
Hoe zijn ze met je router verbonden? Bekabeld of via wifi.

AP #1 en #2 zijn bekabeld verbonden, de derde hangt via mesh aan #2.

Kun je ze pingen?

Ja.

Kun je in de router zien of de dhcp lease wel recent is?

In m'n TP-Link staat niet hoe recent, alleen dat het permanent is.

Zomaar wat zaken die me te binnen schieten om naar te kijken. Hoe doe je de ssh?

Zowel via Putty als Command Prompt.

Heb je geprobeerd te ssh-en naar je router en vandaar nog een keer ssh naar de AP's?

Die volg ik niet helemaal.

Ik zou die dingen (sowieso netwerk apparaten) ook een vast IP adres geven op het apparaat zelf en niet op router via dhcp. Maar daar heb je nu niet zo veel aan.

Mijn voorkeur is altijd bij de router te doen; dan heb ik immers alle vaste IP adressen bij elkaar staan.

Maar goed; vanmiddag even voor gaan zitten en ik ben iets verder gekomen.
AP #2 heb ik in failsafe gekregen en uiteindelijk een via firmware selecter upgrade gegeven.
Betekende wel dat ik alles opnieuw moest instellen maar het werkt i.i.g. weer.
Zelfs het verborgen netwerk/SSID en bijbehorend wachtwoord die de mesh tussen #2 en #3 verzorgd heb ik goed gegokt. Dus de camera's die achter #3 hangen zijn ook weer zichtbaar want #3 verbond weer automatisch met #2.

Op dezelfde manier ergens de komende tijd #3 ook maar behandelen en #1 ook maar doen.
Want tijdenlang niet naar omgekeken of updates gedaan, dus schone firmware/update is misschien wel zo handig.

Maar doet me wel meer twijfelen of ik niet wat anders ga zoeken voor het netwerk.
OpenWRT was leuk omdat het elke willekeurige router dezelfde Openwrt UI kon geven, maar ik denk dat het toch iets to much is voor mij. Heb eigenlijk geen zin om elk (half) jaar weer te moeten leren hoe alles ook alweer werkt.
Denk dat ik voor iets eenvoudigers (een of andere meshkit) of meer streamlined wil gaan. (Unifi)

EDIT: nou, alledrie lijken weer goed te werken. Ik denk het probleem ergens met updates en/of firewall te maken had, want dat laatste had ik nu ook een enkele keer last van.

[ Voor 7% gewijzigd door Piet91 op 01-09-2026 19:43 ]

[Step5]

Piet91 schreef op maandag 31 augustus 2026 @ 22:10:
[...]

AP #1 en #2 zijn bekabeld verbonden, de derde hangt via mesh aan #2.

[...]

Ja.

[...]

In m'n TP-Link staat niet hoe recent, alleen dat het permanent is.

[...]

Zowel via Putty als Command Prompt.

[...]

Die volg ik niet helemaal.

[...]

Mijn voorkeur is altijd bij de router te doen; dan heb ik immers alle vaste IP adressen bij elkaar staan.

Maar goed; vanmiddag even voor gaan zitten en ik ben iets verder gekomen.
AP #2 heb ik in failsafe gekregen en uiteindelijk een via firmware selecter upgrade gegeven.
Betekende wel dat ik alles opnieuw moest instellen maar het werkt i.i.g. weer.
Zelfs het verborgen netwerk/SSID en bijbehorend wachtwoord die de mesh tussen #2 en #3 verzorgd heb ik goed gegokt. Dus de camera's die achter #3 hangen zijn ook weer zichtbaar want #3 verbond weer automatisch met #2.

Op dezelfde manier ergens de komende tijd #3 ook maar behandelen en #1 ook maar doen.
Want tijdenlang niet naar omgekeken of updates gedaan, dus schone firmware/update is misschien wel zo handig.

Maar doet me wel meer twijfelen of ik niet wat anders ga zoeken voor het netwerk.
OpenWRT was leuk omdat het elke willekeurige router dezelfde Openwrt UI kon geven, maar ik denk dat het toch iets to much is voor mij. Heb eigenlijk geen zin om elk (half) jaar weer te moeten leren hoe alles ook alweer werkt.
Denk dat ik voor iets eenvoudigers (een of andere meshkit) of meer streamlined wil gaan. (Unifi)

EDIT: nou, alledrie lijken weer goed te werken. Ik denk het probleem ergens met updates en/of firewall te maken had, want dat laatste had ik nu ook een enkele keer last van.

Mooi dat het weer werkt. Aan de dhcp zal het wel niet liggen als pingen wel werkt. Blijft die firewall over of dat heel de webserver niet draaide of luci niet geinstalleerd was. Heb een tijd terug wel gehad bij een bepaalde router als ik die een update gaf dan moest ik daarna handmatig luci installeren omdat die niet in het updatebestand zat.

Ssh via-via: stel je hoofdrouter is 192.168.1.1 en je ap 192.168.1.2, dan ga je met ssh naar je router

ssh root@192.168.1.1

En vanuit de prompt daar doe je nog een keer ssh

ssh root@192.168.1.2

Als dat wel werkt en directe verbinding niet, dan houd je router dat tegen.

Jammer dat je begint te balen van openwrt, ik ben steeds meer fan en zoek m'n apparaten er op uit. Het probleem is denk ik wel een beetje dat het ene apparaat beter ondersteund is dan de andere.

Binnenkort eens naar openwisp kijken... als ik weer wat hobbytijd heb...

[Piet91]

Step5 schreef op zaterdag 5 september 2026 @ 23:05:
[...]

Mooi dat het weer werkt. Aan de dhcp zal het wel niet liggen als pingen wel werkt. Blijft die firewall over of dat heel de webserver niet draaide of luci niet geinstalleerd was. Heb een tijd terug wel gehad bij een bepaalde router als ik die een update gaf dan moest ik daarna handmatig luci installeren omdat die niet in het updatebestand zat.

Ssh via-via: stel je hoofdrouter is 192.168.1.1 en je ap 192.168.1.2, dan ga je met ssh naar je router

ssh root@192.168.1.1

En vanuit de prompt daar doe je nog een keer ssh

ssh root@192.168.1.2

Als dat wel werkt en directe verbinding niet, dan houd je router dat tegen.

Vergeten te melden dat mijn router een TP-Link C7 V4 is, met stock firmware.
Voor een access points durf ik nog wel met OpenWRT te werken, voor router niet echt.
Hoewel die TP-Link ook al jaren geen (firmware)updates heeft gehad...

Jammer dat je begint te balen van openwrt, ik ben steeds meer fan en zoek m'n apparaten er op uit. Het probleem is denk ik wel een beetje dat het ene apparaat beter ondersteund is dan de andere.

Binnenkort eens naar openwisp kijken... als ik weer wat hobbytijd heb...

Ik vind het eigenlijk te technisch voor wat simpel instelwerk. Ik doe eigenlijk niets meer dan wat Wifi-netwerken opzetten (en een mesh tussen 2) en that's it. Al die opties van OpenWRT is voor mij eigenlijk overbodig en maakt het alleen maar lastig.
En als je 3 apparaten hebt moet je op elk apparaat apart inloggen en settings wijzigen i.p.v. alle in 1 controller zoals met bijvoorbeeld Ubiquiti kan.

Maar goed; het werkt weer dus ik zing het wel weer een tijd uit.

[Thomas H]

Step5 schreef op zaterdag 5 september 2026 @ 23:05:
[...]

Binnenkort eens naar openwisp kijken... als ik weer wat hobbytijd heb...

Tip: OpenSOHO. Werkt hier heel leuk, waar ik OpenWISP nooit werkend heb gekregen. Gebruikt technisch dezelfde backend maar... in mijn geval werkt het WEL :)

[Step5]

Thomas H schreef op woensdag 9 september 2026 @ 13:59:
[...]

Tip: OpenSOHO. Werkt hier heel leuk, waar ik OpenWISP nooit werkend heb gekregen. Gebruikt technisch dezelfde backend maar... in mijn geval werkt het WEL :)

Interessant, was ik nog niet tegengekomen maar is nog vrij nieuw ook zo te zien. Ga ik zeker proberen, tnx

[sweetdude]

Piet91 schreef op maandag 7 september 2026 @ 21:14:
[...]

Vergeten te melden dat mijn router een TP-Link C7 V4 is, met stock firmware.
Voor een access points durf ik nog wel met OpenWRT te werken, voor router niet echt.
Hoewel die TP-Link ook al jaren geen (firmware)updates heeft gehad...

[...]

Ik vind het eigenlijk te technisch voor wat simpel instelwerk. Ik doe eigenlijk niets meer dan wat Wifi-netwerken opzetten (en een mesh tussen 2) en that's it. Al die opties van OpenWRT is voor mij eigenlijk overbodig en maakt het alleen maar lastig.
En als je 3 apparaten hebt moet je op elk apparaat apart inloggen en settings wijzigen i.p.v. alle in 1 controller zoals met bijvoorbeeld Ubiquiti kan.

Maar goed; het werkt weer dus ik zing het wel weer een tijd uit.

Zelf maak ik gebruik van een OpenWRT router, eerst linksys wrt-32x. nu een GliNet flint 2, wel met stock OpenWRT erop. Maar van beide heb ik de WiFi uitgeschakeld. Voor de WiFi heb ik een TP-Link mesh set, eerst een M5 (wifi 5 setje) en ondertussen een XE750Pro in accespointmodus.

In principe heb je daar weinig omkijken naar. De TP-link app is erg summier in accespoint mode. Voeg je een node toe aan het mesh, dan neemt deze de instellingen automatisch over. Dus voor upgrades is het handig om deze eerst toe te voegen en daarna de oude eruit te halen.

En alle belangrijke netwerkzaken zoals DHCP/ adblock etc etc. kun je op de router instellen.

[Piet91]

sweetdude schreef op donderdag 10 september 2026 @ 09:43:
[...]

Zelf maak ik gebruik van een OpenWRT router, eerst linksys wrt-32x. nu een GliNet flint 2, wel met stock OpenWRT erop. Maar van beide heb ik de WiFi uitgeschakeld. Voor de WiFi heb ik een TP-Link mesh set, eerst een M5 (wifi 5 setje) en ondertussen een XE750Pro in accespointmodus.

In principe heb je daar weinig omkijken naar. De TP-link app is erg summier in accespoint mode. Voeg je een node toe aan het mesh, dan neemt deze de instellingen automatisch over. Dus voor upgrades is het handig om deze eerst toe te voegen en daarna de oude eruit te halen.

En alle belangrijke netwerkzaken zoals DHCP/ adblock etc etc. kun je op de router instellen.

Ik neig eerder naar een Ubiquiti Cloud Gateway Ultra en evt. wat bijbehorende AP's. (alles desnoods 2e-hands).
Of een mesh-set van Asus, naar mijn weten een van de zeer weinige merken die nog gewoon een webinterface heeft en niet alles in een app stopt.

Maar voorlopig blijft het gewoon bij het oude.

[Brent]

Ik wil graag een DoH DNS op mijn router instellen ipv een unencrypted 'ouderwetse' DNS, en kwam daarbij https-dns-proxy tegen. Ik wil een niet built-in DoH server gebruiken, maar helaas krijg ik resolve fouten (niets werkt). Gek genoeg kan ik ook helemaal geen DoH url invullen, alleen bootstrap ip's. Ik heb het idee dat een een UI bug is. Iemand ervaring mee?

[Captain Obvious]

Ik ben opzoek naar een budget OpenWRT-routertje. Ik kan lokaal een Zyxel EX5601 voor rond de 60 euro krijgen of een van de Cudy WR3000(S/H/E) varianten. Hardware is natuurlijk beter op de Zyxel maar vroeg me toch af of iemand ervaring heeft met de Cudy en specifiek of er veel verschil tussen die varianten zit? Weet alleen dat de H op papier meer ram etc. heeft en 2,5gbit WAN.

[Falco]

Captain Obvious schreef op vrijdag 18 september 2026 @ 09:45:
Ik ben opzoek naar een budget OpenWRT-routertje. Ik kan lokaal een Zyxel EX5601 voor rond de 60 euro krijgen of een van de Cudy WR3000(S/H/E) varianten. Hardware is natuurlijk beter op de Zyxel maar vroeg me toch af of iemand ervaring heeft met de Cudy en specifiek of er veel verschil tussen die varianten zit? Weet alleen dat de H op papier meer ram etc. heeft en 2,5gbit WAN.

Ik kan niet veel zeggen over de Cudy WR3000*, maar ik heb twee Cudy apparaten de TR3000 en een AP3000, deze doen het uitstekend. Eenvoudig te flashen ook, wat volgens mij bij de Zyxel wat lastiger is.

Die AP3000 is mijn zolder access point en die is erg snel en krachtig met OpenWRT. Ik zie twee verdiepingen naar beneden nog altijd 2-3 streepjes qua signaal.

[Captain Obvious]

Falco schreef op vrijdag 18 september 2026 @ 10:05:
[...]

Ik kan niet veel zeggen over de Cudy WR3000*, maar ik heb twee Cudy apparaten de TR3000 en een AP3000, deze doen het uitstekend. Eenvoudig te flashen ook, wat volgens mij bij de Zyxel wat lastiger is.

Die AP3000 is mijn zolder access point en die is erg snel en krachtig met OpenWRT. Ik zie twee verdiepingen naar beneden nog altijd 2-3 streepjes qua signaal.

Dat is fijn om te horen! De TR3000 is ook een interessant apparaat omdat die eventueel op de plek geplaatst kan worden waar al mijn kabels binnenkomen. Is een vrij ondiep kastje dus past geen moderne router in helaas. En er moet er natuurlijk wel nog een switch naast. Denk je dat die krachtig genoeg is voor een appartement van ongeveer 55m2 van WiFi te voorzien of gebruik je hem uitsluitend op reis?

[easyriider]

Heb naast een Asus AX59U als router thuis die met OpenWrt draait ook een TR3000 voor gebruik tijdens reizen, die draait echter nog met de Cudy firmware wat overigens ook een gewijzigde oude OpenWrt versie is.

[Falco]

Captain Obvious schreef op vrijdag 18 september 2026 @ 10:19:
[...]

Dat is fijn om te horen! De TR3000 is ook een interessant apparaat omdat die eventueel op de plek geplaatst kan worden waar al mijn kabels binnenkomen. Is een vrij ondiep kastje dus past geen moderne router in helaas. En er moet er natuurlijk wel nog een switch naast. Denk je dat die krachtig genoeg is voor een appartement van ongeveer 55m2 van WiFi te voorzien of gebruik je hem uitsluitend op reis?

Ik gebruik de TR3000 alleen op reis en af en toe als test wifi. Maar zal uiteindelijk afhangen van type/aantal muren en vloeren denk ik. En natuurlijk aantal gebruikers.

[UUDIBUUDI]

Captain Obvious schreef op vrijdag 18 september 2026 @ 09:45:
Ik ben opzoek naar een budget OpenWRT-routertje. Ik kan lokaal een Zyxel EX5601 voor rond de 60 euro krijgen of een van de Cudy WR3000(S/H/E) varianten. Hardware is natuurlijk beter op de Zyxel maar vroeg me toch af of iemand ervaring heeft met de Cudy en specifiek of er veel verschil tussen die varianten zit? Weet alleen dat de H op papier meer ram etc. heeft en 2,5gbit WAN.

Ik gebruik nu een jaar 2x Cudy WR3000 (gbit lan) en ben er qua prijs/verbruik/bereik/stabiliteit dik tevreden mee; zelf Openwrt erop gezet (de stock Openwrt firmware is best goed, maar ik wil gewoon geen verrassingen en een domme AP) en geen omkijken naar gehad. Ik woon vrijstaand dus kan weinig zeggen over interferentie. Heb ze gekocht als vervanger van 2xTP-Link Archer C7, dus dat is in dezelfde prijsklasse een 1 op 1 upgrade. Ben geen heavy user maar wel een kudde kids met tablets rondlopen. De meerwaarde van 2.5gbit variant zag ik niet (ietsje meer verbruik, destijds ook wat duurder).

[acermoi]

Ik blijf, hardleers, opkg tikken, help! Wel binnenkort een 10Gb poort nodig....

[jwvdst]

Captain Obvious schreef op vrijdag 18 september 2026 @ 09:45:
Ik ben opzoek naar een budget OpenWRT-routertje. Ik kan lokaal een Zyxel EX5601 voor rond de 60 euro krijgen of een van de Cudy WR3000(S/H/E) varianten. Hardware is natuurlijk beter op de Zyxel maar vroeg me toch af of iemand ervaring heeft met de Cudy en specifiek of er veel verschil tussen die varianten zit? Weet alleen dat de H op papier meer ram etc. heeft en 2,5gbit WAN.

let op dat er van de wr3000 en wr3000e nu ook een v2 is en deze is niet compatible met openwrt
let hier even goed op bij het bestellen

New model 2.0 is using a different dual-core CPU known as TRIDuctor clocked at 1.2 Ghz instead of 1.3 Ghz. OpenWRT is NOT supported on the new WR3000 v2.0 revision ! See Device Page for more info. aldus openwrt

[FPSUsername]

Ik lees veel over dat de Zyxel T56 twee varianten kent, waaronder een met Odido firmware. Hoe zit het met Simpel? Of heeft Simpel exact dezelfde firmware als Odido (omdat ze daar alles inkopen)?

En een vraag in het algemeen, “koop een van marktplaats als je een in bruikleen hebt”, hoe komen mensen aan zo'n systeem om op marktplaats te verkopen? Zover ik weet zijn alle modems in bruikleen. Niemand gaat toch een zyxel router kopen voor een eigen netwerk? Lijkt me dat er veel betere opties zijn.

[_JGC_]

FPSUsername schreef op zaterdag 10 oktober 2026 @ 15:52:
Ik lees veel over dat de Zyxel T56 twee varianten kent, waaronder een met Odido firmware. Hoe zit het met Simpel? Of heeft Simpel exact dezelfde firmware als Odido (omdat ze daar alles inkopen)?

En een vraag in het algemeen, “koop een van marktplaats als je een in bruikleen hebt”, hoe komen mensen aan zo'n systeem om op marktplaats te verkopen? Zover ik weet zijn alle modems in bruikleen. Niemand gaat toch een zyxel router kopen voor een eigen netwerk? Lijkt me dat er veel betere opties zijn.

Als je te laat bent met terugsturen wordt de router gewoon in rekening gebracht en mag je 'm houden.

Verder verwacht ik dat er weinig verschil zit in deze router tussen Odido en Simpel.

[Muis666]

FPSUsername schreef op zaterdag 10 oktober 2026 @ 15:52:
Niemand gaat toch een zyxel router kopen voor een eigen netwerk? Lijkt me dat er veel betere opties zijn.

Als je er OpenWRT op flasht, dan krijg je opeens heel veel router voor relatief weinig geld (< EUR 30 tweedehands).

[Chris.nl]

Voor wie 't boeit, OpenWRT 25.12.6 komt eraan.

Snel geteld meer dan 70 CVE's in de changelog, dus imo 't updaten waard. Buildbot is nog niet klaar om alle images te maken, gok dat ie rond dinsdag officiëel aangekondigd wordt.

Voor deze release is ook een testronde geweest,

Major changes

Many security fixes
mac80211 from 6.18.55
Linux 6.12.112
many mt76 fixes

Wifi WPA3 configuration closer to OpenWrt 24.10.
DHCP client ID is configurable
Wifi Clients connection problems to an AP running OpenWrt 25.12 with sae should be fixed now. All Wifi clients which worked together with an AP running OpenWrt 24.10 should work now again. The sae-compat mode is available too, but should not be needed.

The DHCP client ID is configurable now. It is possible to configure the DHCP client ID like OpenWrt 24.10 did it, to allow connecting to broken ISPs. The default did not change.

[Videopac]

Chris.nl schreef op zondag 18 oktober 2026 @ 11:11:
Voor wie 't boeit, OpenWRT 25.12.6 komt eraan.

Snel geteld meer dan 70 CVE's in de changelog, dus imo 't updaten waard. Buildbot is nog niet klaar om alle images te maken, gok dat ie rond dinsdag officiëel aangekondigd wordt.

Voor deze release is ook een testronde geweest,
[...]

En hij is vrijgegeven!
Tenminste: ik krijg hem aangeboden in mijn MT6000's en MT3000.
De OpenWrt.org site is nogal traag, maar ik zie hem daar nog niet op de openingspagina staan.

Edit: als ik een sysupgrade wil doen vind ie hem niet: of hij is terug getrokken, of de notificatie dat de update beschikbaar is wordt eerder vrijgegeven dan de update zelf.

Even geduld nog...

[ Voor 16% gewijzigd door Videopac op 18-10-2026 15:16 ]

[sweetdude]

Videopac schreef op zondag 18 oktober 2026 @ 15:13:
[...]

En hij is vrijgegeven!
Tenminste: ik krijg hem aangeboden in mijn MT6000's en MT3000.
De OpenWrt.org site is nogal traag, maar ik zie hem daar nog niet op de openingspagina staan.

Edit: als ik een sysupgrade wil doen vind ie hem niet: of hij is terug getrokken, of de notificatie dat de update beschikbaar is wordt eerder vrijgegeven dan de update zelf.

Even geduld nog...

De attended sysupgrade geeft hem bij mij wel aan. Maar met de volgende melding...
Server response: Unsupported target: mediatek/filogic. The requested target was either dropped, is still being built or is not supported by the selected version. Please check the forums or try again later.

Denk dat de robot nog druk bezig is om de pakketjes bij elkaar te zoeken en klaar te zetten.

[Chris.nl]

sweetdude schreef op zondag 18 oktober 2026 @ 19:37:
[...]

De attended sysupgrade geeft hem bij mij wel aan. Maar met de volgende melding...
Server response: Unsupported target: mediatek/filogic. The requested target was either dropped, is still being built or is not supported by the selected version. Please check the forums or try again later.

Denk dat de robot nog druk bezig is om de pakketjes bij elkaar te zoeken en klaar te zetten.

Jup, best is afwachten totdat een release gewoon aangekondigd wordt in het announcements deel van het openwrt forum. Kan altijd zijn dat er tussen nu en release nog een bug/issue gevonden wordt door vroege testers.

Je kan je eventueel aanmelden voor een maillijst om bij elke update ook een mailtje te krijgen.

'k Heb zelf 25.12.6 met enkele packages inmiddels draaien op m'n NanoPi, 't lijkt hier prima/stabiel. En weer door tot de volgende update...

-edit

Inmiddels aangekondigd, sneller dan ik dacht

[ Voor 6% gewijzigd door Chris.nl op 19-10-2026 04:26 ]

[easyriider]

Na enkele mislukte pogingen vandaag verliep attended sysupgrade vlekkeloos en na een queue van zo'n 50 wachtenden voor me draait m'n Asus AX59U inmiddels met 25.12.6.

[Zenix]

easyriider schreef op zondag 18 oktober 2026 @ 20:59:
Na enkele mislukte pogingen vandaag verliep attended sysupgrade vlekkeloos en na een queue van zo'n 50 wachtenden voor me draait m'n Asus AX59U inmiddels met 25.12.6.

Ik had er zelfs 200 met mijn Radxa EC52C. Maar ging weer vlekkeloos. Belangrijke update met zoveel security fixes.

[sweetdude]

Het dashboard voor die gene die hem niet hebben "luci-mod-dashboard" is ook gemoderniseerd. Dat ziet er gelijk een stuk moderner en professioneler uit dan voorheen.

[easyriider]

@sweetdude Dat kende ik nog niet dus zojuist even geïnstalleerd. Het geeft een veel duidelijker en mooier overzicht dan het Status/Overview scherm van Luci.

[supayoshi]

iemand een screenshot?

[sweetdude]

supayoshi schreef op woensdag 21 oktober 2026 @ 16:48:
iemand een screenshot?

meer info hier. (een beetje googlen kon natuurlijk ook geen kwaad)

https://forum.openwrt.org/t/luci-mod-dashboard-a-modernized-ui-rewrite/253559

[Borromini]

Tijd voor een 26.xx branch zou ik zeggen .

[Brent]

Ik heb twee (identieke) OpenWRT routers. De hoofdrouter heeft een kabel in de WAN poort en daarmee internet, en 2 SSID's: 1 extra die alleen WAN op mag en van LAN is geisoleerd. De tweede router zit op een LAN poort van de eerste en os geconfigged als DHCP client van de eerste, oftewel, alle clienten van router 2 zitten op het LAN.

Vraag: hoe kan ik ook via de twede router een WAN-only SSID aanmaken? Naast de bestaande SSID natuurlijk.

[InjecTioN]

Brent schreef op maandag 2 november 2026 @ 16:01:
Ik heb twee (identieke) OpenWRT routers. De hoofdrouter heeft een kabel in de WAN poort en daarmee internet, en 2 SSID's: 1 extra die alleen WAN op mag en van LAN is geisoleerd. De tweede router zit op een LAN poort van de eerste en os geconfigged als DHCP client van de eerste, oftewel, alle clienten van router 2 zitten op het LAN.

Vraag: hoe kan ik ook via de twede router een WAN-only SSID aanmaken? Naast de bestaande SSID natuurlijk.

Je maakt een tagged VLAN aan over het LAN poortje van de primaire router dat naar de secundaire router gaat. Uit mijn hoofd heet dat een VLAN Bridge. Laten we zeggen VLAN 5. Hierna raad ik je aan om op de secundaire router simpelweg DHCP uit te schakelen, het IP te wijzigen naar iets dat past in je netwerk en nog niet bezet is.

Je dient vervolgens ook op de secundaire router een (wederom uit mijn hoofd) VLAN bridge aan te maken met dezelfde VLAN 5 op de netwerkpoort die aangesloten staat aan de primaire router. Dus op beide routers zijn de poortjes identiek ingesteld.

Vervolgens kan je de VLAN Bridge die VLAN 5 representeert nu koppelen aan een SSID.

Overigens is 2 routers prima, maar je wilt niet 2 routers achter elkaar (dubbele NAT) of 2 routers in hetzelfde netwerk (dat gaat irritant worden met o.a. DHCP en routing).

[Brent]

InjecTioN schreef op maandag 2 november 2026 @ 16:25:
[...]

Je maakt een tagged VLAN aan over het LAN poortje van de primaire router dat naar de secundaire router gaat. Uit mijn hoofd heet dat een VLAN Bridge. Laten we zeggen VLAN 5. Hierna raad ik je aan om op de secundaire router simpelweg DHCP uit te schakelen, het IP te wijzigen naar iets dat past in je netwerk en nog niet bezet is.

Je dient vervolgens ook op de secundaire router een (wederom uit mijn hoofd) VLAN bridge aan te maken met dezelfde VLAN 5 op de netwerkpoort die aangesloten staat aan de primaire router. Dus op beide routers zijn de poortjes identiek ingesteld.

Vervolgens kan je de VLAN Bridge die VLAN 5 representeert nu koppelen aan een SSID.

Overigens is 2 routers prima, maar je wilt niet 2 routers achter elkaar (dubbele NAT) of 2 routers in hetzelfde netwerk (dat gaat irritant worden met o.a. DHCP en routing).

Punt is dat ik (net als op de eerste) 2 SSID's wil, 1 met enkel WAN toegang, 1 met ook LAN toegang. Ik heb de tweede router al niet als DHCP server staan (maar als DHCP client, elk device krijgt dus z'n lease van router 1). Mijn probleem is dat ik niet weer hoe ik tegelijk 2 verschillende SSID's naar 2 verschillende DHCP servers doorlus (of hoe OpenWRT dat dan ook doet op router 1, ik heb idd twee verschillende reeksen IP-adressen voor de twee SSIDs waarmee ik meteen zie welk apparaat WAN-only is en welke niet). NAT-op-NAT is idd niet de bedoeling (want ik wil 1x LAN hebben).

Als ik je goed begrijp heb ik met je voorstel wat ik nu al heb: router 2 functioneert als doorgeefluik naar de DHCP server op router 1, waarbij alles LAN toegang heeft (omdat ik ik ze bedraad heb aangesloten op een LAN-poort op router 1).

[ Voor 6% gewijzigd door Brent op 02-11-2026 16:30 ]

[UUDIBUUDI]

Ik heb zelf een pfsense firewall die fungeert als DNS/DHCP server voor alle clients op mijn 2 OpenWRT routers. Ik heb op beide OpenWRT routers meerdere SSID's aangemaakt die elk aan een eigen VLAN hangen. Op de pfSense bak wordt dan dus bepaald dat het SSID Guest c.q. de VLAN Guest alleen het internet op mag (middels firewall rules op de Guest netwerkinterface van pfsense). De OpenWRT routers zijn in deze setup volledig identiek en uitwisselbaar.

Voor die setup in jouw situatie zal de OpenWRT router die de WAN connectie heeft, de dhcp/dns rol op zich moeten nemen. Dan moet je met VLANs aan de gang en je moet de DNS/DHCP server bewegen om te doen wat je wil. Aansluitend moet je firewall rules maken op de OpenWRT Router die de WAN connectie heeft. Ik zou daar zelf niet zo snel aan beginnen (niet heel eenvoudig en ik ben zelf goed bekend met pfsense, OpenWRT houd ik daarom liever eenvoudig), dus dat advies zal ik niet gaan geven ook :-).

Wat je misschien wel kan doen is isolatie middels firewall rules. Op de WAN router kun je dan verkeer vanaf Guest naar LAN blokkeren en op de tweede router moet je dan alleen het verkeer vanaf Guest richting de WAN router toestaan (dat verkeer gaat dan over je LAN, maar alleen als het verkeer zodanig geadresseerd is dat het richting WAN loopt). Wellicht iets minder robuust qua isolatie, maar ook wat makkelijker om via trial-and-error aan de praat te krijgen.

[Brent]

UUDIBUUDI schreef op maandag 2 november 2026 @ 16:51:

Voor die setup in jouw situatie zal de OpenWRT router die de WAN connectie heeft, de dhcp/dns rol op zich moeten nemen.

Dat heeft ie dus al. En het tweede WAN-only SSID op de eerste router werkt dmv een 'interface', welke een aparte IP-reeks heeft.

Dan moet je met VLANs aan de gang en je moet de DNS/DHCP server bewegen om te doen wat je wil. Aansluitend moet je firewall rules maken op de OpenWRT Router die de WAN connectie heeft. Ik zou daar zelf niet zo snel aan beginnen (niet heel eenvoudig en ik ben zelf goed bekend met pfsense, OpenWRT houd ik daarom liever eenvoudig), dus dat advies zal ik niet gaan geven ook :-).

Daar dacht ik aan, maar hoe kan ik in router 1 selecteren op SSID op router 2?

Wat je misschien wel kan doen is isolatie middels firewall rules. Op de WAN router kun je dan verkeer vanaf Guest naar LAN blokkeren en op de tweede router moet je dan alleen het verkeer vanaf Guest richting de WAN router toestaan (dat verkeer gaat dan over je LAN, maar alleen als het verkeer zodanig geadresseerd is dat het richting WAN loopt). Wellicht iets minder robuust qua isolatie, maar ook wat makkelijker om via trial-and-error aan de praat te krijgen.

De vraag blijft volgens mij: wat kan ik op router 1 doen om SSID op router 2 te zien? En evt zou ik best een aparte DHCP server op router 2 voor de het WAN-only SSID willen draaien, maar probleem blijft: hoe kan de ene router via een LAN-poort discrimineren op eigenschappen die eigenlijk alleen op de tweede router aanwezig zijn? Een VLAN is ook router-local, toch?

[UUDIBUUDI]

Brent schreef op maandag 2 november 2026 @ 17:50:
[...]
Dat heeft ie dus al. En het tweede WAN-only SSID op de eerste router werkt dmv een 'interface', welke een aparte IP-reeks heeft.

[...]

Daar dacht ik aan, maar hoe kan ik in router 1 selecteren op SSID op router 2?

Zonder VLANs zou dat kunnen middels firewalling op router 2. Als je router 2 zodanig instelt dat deze vanaf het WAN-only SSID alleen netwerkverkeer doorlaat als dat richting het internet gaat (dus if (verkeer gericht aan lokaal LAN) then DENY) else ALLOW) en als je ook NAT toepast (al het verkeer vanaf WAN-ONLY op router2 lijkt dan voor router1 afkomstig vanaf het LAN ip van router2) dan hoef je op router 1 niks in te stellen; dan is router2 gewoon een client die het internet op mag.

[...]

De vraag blijft volgens mij: wat kan ik op router 1 doen om SSID op router 2 te zien? En evt zou ik best een aparte DHCP server op router 2 voor de het WAN-only SSID willen draaien, maar probleem blijft: hoe kan de ene router via een LAN-poort discrimineren op eigenschappen die eigenlijk alleen op de tweede router aanwezig zijn? Een VLAN is ook router-local, toch?

Router 1 kun je even vergeten (het bovenstaande verhaal werkt overal). Als Router 1 een standaard Ziggo of KPN kastje was waar je niks aan kon sleutelen, zou je hetzelfde kunnen bewerkstelligen (netwerktechnisch is router 1 dus irrelevant, zolang ie maar als internet gateway fungeert).

Voor een VLAN wordt er vooraan elk netwerkpakketje een paar bytes toegevoegd met daar het VLAN nummer. Je kan dus verkeer vanaf een SSID op router 2 voorzien van VLAN tags die dan op router 1 kunnen worden herkend (situatie zoals in mijn vorige post). Zolang de netwerkswitch VLAN pakketjes ondersteunt (gewoon dom doorsturen is in dit geval prima, openwrt doet het werk) kun je dus eigenlijk met software doen wat je anders zou moeten doen met meerdere fysieke switches/kabels.

Het kan dus ook zonder VLANs (je WAN-only clients worden achter het LAN ip van router 2 verborgen net zoals al je LAN clients achter het WAN ip van router 1 worden verborgen).

[Brent]

UUDIBUUDI schreef op maandag 2 november 2026 @ 18:13:
[...]

Zonder VLANs zou dat kunnen middels firewalling op router 2. Als je router 2 zodanig instelt dat deze vanaf het WAN-only SSID alleen netwerkverkeer doorlaat als dat richting het internet gaat (dus if (verkeer gericht aan lokaal LAN) then DENY) else ALLOW) en als je ook NAT toepast (al het verkeer vanaf WAN-ONLY op router2 lijkt dan voor router1 afkomstig vanaf het LAN ip van router2) dan hoef je op router 1 niks in te stellen; dan is router2 gewoon een client die het internet op mag.

Op router 2 is geen WAN-poort (in gebruik), dus hoe kun je daar iets mee? Er is maar 1 kabel naar router 1, en wel op de LAN poort (bij beide). Zou hem natuurlijk op de WAN poort (van router 2) kunnen zetten, maar dat lijkt me dan een alles of niets situatie: op router 1 kan ik op basis van poort WAN-only instellen maar dan kan er dus ook niets meer het LAN op via de LAN SSID.

[...]

Router 1 kun je even vergeten (het bovenstaande verhaal werkt overal). Als Router 1 een standaard Ziggo of KPN kastje was waar je niks aan kon sleutelen, zou je hetzelfde kunnen bewerkstelligen (netwerktechnisch is router 1 dus irrelevant, zolang ie maar als internet gateway fungeert).

Voor een VLAN wordt er vooraan elk netwerkpakketje een paar bytes toegevoegd met daar het VLAN nummer. Je kan dus verkeer vanaf een SSID op router 2 voorzien van VLAN tags die dan op router 1 kunnen worden herkend (situatie zoals in mijn vorige post). Zolang de netwerkswitch VLAN pakketjes ondersteunt (gewoon dom doorsturen is in dit geval prima, openwrt doet het werk) kun je dus eigenlijk met software doen wat je anders zou moeten doen met meerdere fysieke switches/kabels.

Aha, dus een WLAN gemaakt op de ene router, kan ik herkennen en dus sturen op de tweede? Deze routers en Openwrt ondersteunen dit, dus moet kunnen. Dan moet ik op router 1 deze dus aan een interface toevoegen? (Openwrt documentatie voor VLAN is niet geweldig.)

[UUDIBUUDI]

Brent schreef op maandag 2 november 2026 @ 18:29:
[...]

Op router 2 is geen WAN-poort (in gebruik), dus hoe kun je daar iets mee? Er is maar 1 kabel naar router 1, en wel op de LAN poort (bij beide). Zou hem natuurlijk op de WAN poort (van router 2) kunnen zetten, maar dat lijkt me dan een alles of niets situatie: op router 1 kan ik op basis van poort WAN-only instellen maar dan kan er dus ook niets meer het LAN op via de LAN SSID.

[...]

Het kan zonder wan op router 2. Je kan een interface maken op router2 met een eigen ip range en een eigen firewall zone. Router2 doet dhcp voor het nieuwe guest ssid en dns kun je forwarden naar router1. In de firewall op router2 moet je dan instelllen (o.a.):

- allow * from guest to router2:67 (udp) (dhcp)

- allow * from guezt to router1:53(udp) (dns)

- deny * from guest to <ip range van LAN op router1>

- allow * from guest to any (internet) (hier moet NAT worden toegepast)

Aha, dus een WLAN gemaakt op de ene router, kan ik herkennen en dus sturen op de tweede? Deze routers en Openwrt ondersteunen dit, dus moet kunnen. Dan moet ik op router 1 deze dus aan een interface toevoegen? (Openwrt documentatie voor VLAN is niet geweldig.)

Ja en nee. Router1 hoeft van niks te weten (die ziet alleen maar verkeer komen vanaf router2). Router2 doet al het werk om het te scheiden. Wat ik hierboven schrijf is eigenlijk wat er (met factory settings) gebeurt als je router2 met de wan poort aansluit op router1. Dat willen we niet, omdat je dan niet meer 1 groot lan hebt en omdat we alleen het nieuwe ssid willen afscheiden, daarom dus met de lan poort.

[Brent]

Op deze manier zitten clients van het LAN-SSID op router 1 en 2 in verschillende LANs echter, niet?

[UUDIBUUDI]

Nee, enkel het Guest SSID komt in een ander subnet (dat niet verder strekt dan router2).

Stel dat je nog zo'n ding had (router3) waar je het Guest SSID op configureert. Als je dan router3 met de wan poort inprikt op een LAN poort van router2 (mag ook op een LAN poort op router1, dat maakt nul verschil), dan zouden je huidige LAN-SSID's daar geen hinder van ondervinden. Je zou dan nog wel moeten zorgen dat router3 firewall rules toepast om verkeer richting het LAN subnet te blokkeren. Per saldo heb je dan precies dezelfde situatie die ik in mijn vorige bericht schetste (maar dan zonder een extra router3).

[ Voor 7% gewijzigd door UUDIBUUDI op 02-11-2026 21:49 ]

[Brent]

Volgens mij kun je niet een DHCP server draaien voor 1 SSID/interface. Het is voor alles of niets.

[Muis666]

Brent schreef op dinsdag 3 november 2026 @ 09:17:
Volgens mij kun je niet een DHCP server draaien voor 1 SSID/interface. Het is voor alles of niets.

Er draait 1 DHCP server op OpenWRT maar daarin kun je wel per interface verschillende opties meegeven. Mijn DHCP server geeft adressen uit op een 192.168.2.x segment en op een seperaat 192.168.5.x segment. (Komt omdat ik nog een 10 Mbit VOIP telefoon heb die ik niet op mijn normale LAN wilde hebben)

[Brent]

Muis666 schreef op dinsdag 3 november 2026 @ 09:24:
[...]

Er draait 1 DHCP server op OpenWRT maar daarin kun je wel per interface verschillende opties meegeven. Mijn DHCP server geeft adressen uit op een 192.168.2.x segment en op een seperaat 192.168.5.x segment. (Komt omdat ik nog een 10 Mbit VOIP telefoon heb die ik niet op mijn normale LAN wilde hebben)

Ik kan wel twee servers addressen op hetzelfde segment laten uitgeven, maar daarmee zitten ze nog niet op hetzelfde LAN. Die zijn (als het goed is!) geisoleerd, ook als je wederzijds toegang toestaat in de firewalls. Multicast/Bonjour/HomeKit/mDNS werken dan niet. Of gaat dat vanzelf goed cq kan ik iets in de firewall veranderen en zijn meerdere DHCP servers op een subnet kennelijk mogelijk zonder conflicten?

[Muis666]

Brent schreef op dinsdag 3 november 2026 @ 09:29:
[...]

Ik kan wel twee servers addressen op hetzelfde segment laten uitgeven, maar daarmee zitten ze nog niet op hetzelfde LAN. Die zijn (als het goed is!) geisoleerd, ook als je wederzijds toegang toestaat in de firewalls. Multicast/Bonjour/HomeKit/mDNS werken dan niet. Of gaat dat vanzelf goed cq kan ik iets in de firewall veranderen en zijn meerdere DHCP servers op een subnet kennelijk mogelijk zonder conflicten?

Waar zeg ik dat je twee servers op hetzelfde segment moet laten uitgeven? Dat is juist een van de meest gemaakte fouten die altijd tot onvoorspelbaar gedrag leidt.

[Brent]

Muis666 schreef op dinsdag 3 november 2026 @ 10:32:
[...]

Waar zeg ik dat je twee servers op hetzelfde segment moet laten uitgeven? Dat is juist een van de meest gemaakte fouten die altijd tot onvoorspelbaar gedrag leidt.

Ik heb verkeerd gequote, zie de reactie erboven. Idd, hoe jij het beschrijft is hoe ik het nu al heb op router 1: 1 range voor LAN+WAN en 1 range voor WAN-only.

[Muis666]

Brent schreef op dinsdag 3 november 2026 @ 10:58:
[...]

Ik heb verkeerd gequote, zie de reactie erboven. Idd, hoe jij het beschrijft is hoe ik het nu al heb op router 1: 1 range voor LAN+WAN en 1 range voor WAN-only.

Dat klinkt al beter. Dan kun je voor de oplossing van @UUDIBUUDI gaan, maar daarmee kunnen clienten op je WAN-SSID nog wel al het netwerkverkeer op je LAN sniffen. Ik zou dus toch voor een VLAN oplossing gaan, daarmee kun je het verkeer echt segmenteren.

[krijn1985]

@Brent Dit kan je dus oplossen met VLANS (heb ik zelf thuis ook). Even korte beschrijving (acties onder openwrt weet ik even niet uit mijn hoofd): Op je hoofdrouter maak je meerder VLANs aan. eentje voor je gewone LAN (die dus ook internet heeft) en een VLAN voor je apparaten die internettoegang nodig hebben maar niet je lokale netwerk helemaal hoeven te zien, laten we die even IOT noemen. Dan heb je op je router dus een VLAN LAN en VLAN IOT met elk hun eigen DHCP server. Dan hang je de SSID voor je LAN aan het VLAN LAN en SSID van de andere aan je VLAN IOT. Op je tweede router moet je dus dezelfde VLANS aanmaken en kun op een van de interfaces (je LAN VLAN bijvoorbeeld) aangeven dat die daar een statisch (of dynamisch) ip adres heeft zodat je die router ookt kunt bereiken. HIer hang je weer de SSID's aan betreffende VLANs. Met deze inrichting moet je wel even zorgen dat je de poort op beide routers waarmee ze met elkaar verbonden zijn beide VLAN's getagged doorstuurt en alle andere poorten moet je untagged op het VLAN zetten waarop je ze wilt hebben. Werkt hier al een aantal jaar prima.

[Brent]

@krijn1985 Als ik dus een VLAN op beide routers aanmaak, met dezelfde naam/id, dan matchen de tags dus onderling vanzelf? Top, dit is wat ik zocht, denk dat ik er zo wel uitkom met de documentatie.

[krijn1985]

Brent schreef op dinsdag 3 november 2026 @ 16:37:
@krijn1985 Als ik dus een VLAN op beide routers aanmaak, met dezelfde naam/id, dan matchen de tags dus onderling vanzelf? Top, dit is wat ik zocht, denk dat ik er zo wel uitkom met de documentatie.

Yep zelfde ID is voor je vlan van belang. Namen die je geeft is volgens mij vooral voor jezelf, maar zou dat ook het zelfde houden om in ieder geval het voor jezelf duidelijk te maken. Mocht je tegen specifieke dingen aanlopen laat het vooral weten.

[Brent]

Nou, het kostte wat tijd maar het lijkt gelukt! Het is geschreven voor een wat oudere OpenWRT versie (23, maar beter dan de officiele wiki die nog van 21 uit gaat): https://fabianlee.org/202...dsa-isolated-guest-wi-fi/

(Ik doe IoT isolatie op mac basis, dus helemaal los hiervan. Ik had dus maar 2 VLANs nodig.)