[OpenWRT] Ervaringen & Discussie

[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?