2GB is plenty for all that. Won't affect SQM performance which is almost all based on CPU.
this build uses the typical dnsmasq by default which supports most dhcp options...
dnsmasq isn't used to send DHCP option 61 - from my understanding, someone may want DHCP Option 61 sent as part of the WAN DHCP request (some internet providers apparently require this)
1 Like
roger that... in this case it would be;
uci set network.wan.clientid=ABC
uci commit network
so yes... supported...
1 Like
If you mean on WAN, sent to the ISP, then it's standard OpenWRT
Look in the Advanced Tab of the WAN interface
Client ID to send when requesting DHCP
That's the value to be sent as DHCP option 61
1 Like
I am unable to access my modem. But I can ping modem IP from within openwrt. Something to do with banIP?
I have tried and created new interface but still unable to access my modem.
PING 192.168.10.1 (192.168.10.1): 56 data bytes
64 bytes from 192.168.10.1: seq=0 ttl=64 time=1.885 ms
64 bytes from 192.168.10.1: seq=1 ttl=64 time=0.750 ms
64 bytes from 192.168.10.1: seq=2 ttl=64 time=0.728 ms
64 bytes from 192.168.10.1: seq=3 ttl=64 time=0.746 ms
64 bytes from 192.168.10.1: seq=4 ttl=64 time=0.757 ms
--- 192.168.10.1 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 0.728/0.973/1.885 ms
cat /etc/config/network
config interface 'loopback'
option device 'lo'
option proto 'static'
option ipaddr '127.0.0.1'
option netmask '255.0.0.0'
config globals 'globals'
option packet_steering '1'
config device
option name 'br-lan'
option type 'bridge'
list ports 'eth0'
config interface 'lan'
option device 'br-lan'
option proto 'static'
option netmask '255.255.255.0'
option ip6assign '60'
option ipaddr '192.168.1.2'
option igmp_snooping '1'
option delegate '0'
config interface 'wan'
option proto 'pppoe'
option device 'eth1'
option username
option password
option ipv6 'auto'
option hostname 'router'
option peerdns '0'
list dns '8.8.8.8'
config interface 'IPTV'
option device 'eth1'
option proto 'static'
option ipaddr '10.10.10.1'
option netmask '255.255.255.0'
config interface 'guest'
option proto 'static'
option device 'br-guest'
option ipaddr '192.168.3.1'
option netmask '255.255.255.0'
option delegate '0'
config device
option name 'br-guest'
option type 'bridge'
list ports 'dummy0'
config interface 'accessmodem'
option proto 'static'
option ipaddr '192.168.10.5'
option netmask '255.255.255.0'
option device 'eth1'
cat /etc/config/firewall
config defaults
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'REJECT'
option synflood_protect '1'
config zone
option name 'lan'
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'ACCEPT'
list network 'lan'
config zone
option name 'wan'
option input 'REJECT'
option output 'ACCEPT'
option forward 'REJECT'
option masq '1'
option mtu_fix '1'
list network 'wan'
list network 'wan6'
list network 'IPTV'
list network 'accessmodem'
config forwarding
option src 'lan'
option dest 'wan'
config rule
option name 'Allow-DHCP-Renew'
option src 'wan'
option proto 'udp'
option dest_port '68'
option target 'ACCEPT'
option family 'ipv4'
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 proto 'igmp'
option family 'ipv4'
option target 'ACCEPT'
option src 'wan'
config rule
option name 'Allow-DHCPv6'
option src 'wan'
option proto 'udp'
option src_ip 'fc00::/6'
option dest_ip 'fc00::/6'
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'
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'
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'
config rule
option name 'Support-UDP-Traceroute'
option src 'wan'
option dest_port '33434:33689'
option proto 'udp'
option family 'ipv4'
option target 'REJECT'
option enabled '0'
config include
option path '/etc/firewall.user'
option reload '1'
config zone
option name 'Guest'
option input 'REJECT'
option output 'ACCEPT'
option forward 'REJECT'
list network 'guest'
config forwarding
option src 'Guest'
option dest 'wan'
config rule
option name 'Guest DHCP and DNS'
option src 'Guest'
option target 'ACCEPT'
list proto 'udp'
option dest_port '53 67 '
config rule
option name 'block'
option src 'lan'
option dest 'wan'
option target 'REJECT'
list src_mac '*********************'
list src_mac '*********************'
list src_mac '*********************'
list src_mac '*********************'
list src_mac '*********************'
list src_mac '*********************'
list src_mac '*********************'
list src_mac '*********************'
list src_mac '*********************'
list src_mac '*********************'
list src_mac '*********************'
1 Like
when did it last work?
what has changed since then?
1 Like
It was working fine 2 days ago.
I changed nothing.
is this a bad paste (or you just removed the macs and it looks odd)?
config rule
option name 'block'
option src 'lan'
option dest 'wan'
option target 'REJECT'
list src_mac
this line seems incomplete
was it added in the last two days?
1 Like
I removed mac addresses I added in block list. Let me post it here again.
I noticed this change after power failure. It is not working since then. I am unable to access modem. Before it was working fine.
option name 'block'
option src 'lan'
option dest 'wan'
option target 'REJECT'
list src_mac '*********************'
list src_mac '*********************'
list src_mac '*********************'
list src_mac '*********************'
list src_mac '*********************'
list src_mac '*********************'
list src_mac '*********************'
list src_mac '*********************'
list src_mac '*********************'
list src_mac '*********************'
list src_mac '*********************'
if nothing changed... not too sure where to start looking...
it's highly unusual / unlikely that something like this would just stop without anything at all changing...
unless maybe the ISP has the ability to update the modem firmware?
maybe try to open the modem web page again then check;
conntrack -L | grep '192.168.10.5'
1 Like
conntrack -L | grep '192.168.10.5'
conntrack v1.4.6 (conntrack-tools): 143 flow entries have been shown.
1 Like
If you plug in a PC directly on the ISP modem, can you access it?
2 Likes
yes, I can access it when directly connected via Lan cable.
how many days ago did you enable banip?
maybe try;
ipset add whitelist_4 192.168.10.0/24
( and if it works... add it to the banip whitelist properly services>banip [edit whitelist] )
1 Like
hahahahaha 
thank you. Tried same old method of unplugging everything and plugging back, and now it is working fine.
1 Like
it stopped again after rebooting pi4 and now it is working after adding it to banIP whitelist
luci > services > banIP > edit whitelist
1 Like
I think I might have just discovered a bug. I wanted to test my VPN killswitch config, so I looked at the packets reaching the WAN eth device in the Pi. While connected to the VPN, everything is fine, but after disconnecting, plaintext DNS queries are sent to 10.143.0.1 [ edit - it varies, so it's being randomly assigned every time the VPN tunnel is created, I think? Latest one is 10.171.0.1 ]. I captured the upstream packets, and they are indeed leaving the device, though to my knowledge, this is supposed to be a local-only private IP.
The killswitch is properly configured to forbid anything being forwarded from my LAN. If I send queries before connecting to the VPN, they aren't being leaked. But this seems to be OpenWRT leaking some internal dummy device's innards once the tunnel is unexpectedly shut down? Adding a firewall entry forbidding DNS requests originating from the Pi fixes the issue (but it's obviously just a fiddly band-aid, as it breaks everything including connecting to the VPN, you need to toggle it off and on depending on the situation)
(Tested on both the latest version and one from months ago, so it's not version-dependent)
thanks for the report...
the thing is... kill switches are not a default part of openwrt or this build...
so any behavior you are seeing is likely due to something you have or have not done...
I am open to integrating a good killswitch script... I stress integrating... as networks vary alot... this may or may not be feasable... but is dependant on;
- someone capable providing the source and one or two other people
- needing it
- testing it under various conditions
in any event, you haven't provided;
- the source for your killswitch
- how its triggered
- detailed diagnostics (other than mentioning verbally tcpdump) including an assessment of where in the code/os things are misfunctioning
it's probably best to have a separate thread for your issue... then once resolved... hit me up if you want something like this integrated... (or maybe some hooks that your script can interact with)
this is indeed a valid observation of the default openwrt behavior... there are several ways to address this...
the one that comes to the top of my head is bcp38 so installing this via opkg should resolve your issue...
afaik banip may also have (automajik) code to address this...
I'm a bit confused here 
I essentially just set the firewall zones as per the official guide. Is this non-standard / unsupported?