[Solved] Questions about DNSmasq and IPv6 Link Local Adresses

If I look into "ip a" I get (stripped):

1: eth0:
    inet6 fe80::6830:f96c:ada3:b2de/64 scope link stable-privacy 
3: eth1:
    inet6 fe80::6830:f96c:ada3:b2de/64 scope link stable-privacy 
9: br-lan:
    inet6 fe80::6830:f96c:ada3:b2de/64 scope link stable-privacy
12: br-guest:
    inet6 fe80::6830:f96c:ada3:b2de/64 scope link stable-privacy 
14: eth0.2@eth0: 
    inet6 fe80::6830:f96c:ada3:b2de/64 scope link stable-privacy
18: wlan1:
    inet6 fe80::bc99:420b:e93a:c585/64 scope link stable-privacy
19: wlan1-1:
    inet6 fe80::bc99:420b:e93a:c585/64 scope link stable-privacy

For netstat I can see that dnsmasq is listening (running two instances with "list interfaces") to:

fe80::6830:f96c:ada3:b2de:53 :::*                    LISTEN      3059/dnsmasq
fe80::6830:f96c:ada3:b2de:53 :::*                    LISTEN      3060/dnsmasq

My questions are:

  • Can I restrict dnsmasq to certain addresses within OpenWrt? Like with "listen-address=::1,," for dnsmasq config. In the Wiki I didn't find similar.
  • Why is the fe80 address for eth0 the same as for eth1 and for wlan1 different? Is this because how it is done in hardware SoC (device here is Zyxel NBG6817).
  • Does it have side-effects if dnsmasq is listening to the same fe80 address for different interfaces or is this "just normal"? I just deleted fe80 addresses and recognized no difference (just a short test).

Another thing what is not related with LLA. (Probably because I'm using two instances?) But I just ask here. If I look into logread/dnsmasq I see (after a reboot) a lot of lines with

daemon.debug dnsmasq: listening on eth0.2(#14): fe80::6830:f96c:ada3:b2de%eth0.2 port 53
daemon.warn dnsmasq: failed to create listening socket for fe80::6830:f96c:ada3:b2de%eth0.2: Address in use

For all other addresses (ula, gua, ipv4) and devices (eth1,wlanX) it is the same. If I restart dnsmasq there are no errors about listening sockets anymore.

Some of those interfaces should not have L3 addresses:
But it looks like no one cares until some nasty vulnerability is discovered.

In addition, interface/socket binding may result in another problem:
LuCi HTTPS not working after upgrade to 19.7.4

1 Like

I was wondering about that br-lan (vlan1) and br-zguest (vlan10) have same LLA addresses. Same for eth0 (which is wan) and eth1 (which is lan switch). (Normally) if you want to seperate (v)lans you want control where services are listening to. But this is rendered useless if any interface is getting same LLA. That's why I was asking about "listen-address" for DNSmasq. But it seems this option is not available for OpenWrt. (If i understand it right) I would need to start dnsmasq via commandline to pass this option. Which makes configuration more complex. -.-

Is it an issue if I just delete fe80 address and set a different address? Or just delete it completley from other vlans beside the main? Probably not a good idea. :smiley: ... But I don't know for what LLA is all used.

Y, that I've solved already by binding uhttpd to main vlan ip only (and restricted access by firewall ofc). This is working. But ofc I don't know what you can do with LLA ...

1 Like

Ah, O.K. Thanks. Will try it. I was looking at only (not updated):

1 Like

LLA is created based on the interface mac address. It is not a problem to have similar LLAs in different segments, as its scope is link local. LLA is essential for IPv6 operation and cannot be removed.

1 Like

It seems the parameter is not passed. If I look into "/var/etc/dnsmasq.conf.lan_dns" there is no IP list nor a parameter which looks like listen addresses.

I've verifyed it by removing (list interfaces; although it should play together) and just adding one IPv4 address. Its then using all IPv6 addresses including wireguard IP's and LLA ofc although I've given only one address.

        option listen_address ''

Should be right? I'm using dnsmasq-full (btw.).

Is it then a problem if I delete LLA from br-zguest and assign just a new different/random one? Or is its MAC address included used for anything relevant?

I did already a:

ip addr del fe80::6830:f96c:ada3:b2de/64 dev br-zguest0
ip addr add fe80::6830:f96c:ada3:b2aa/64 dev br-zguest0

It seemed it has no effect in terms of networking. But it was just a short test.


root@RoadWarrior:~# netstat -lnp | grep dnsmasq
tcp        0      0  *               LISTEN      4549/dnsmasq
tcp        0      0   *               LISTEN      4549/dnsmasq
tcp        0      0 ::1:53                  :::*                    LISTEN      4549/dnsmasq
udp        0      0  *                           4549/dnsmasq
udp        0      0   *                           4549/dnsmasq
udp        0      0 ::1:53                  :::*                                4549/dnsmasq

I don't think it matters. However leaving the default makes it easier to connect to a device which for some reason has not acquired a LLA or GUA, just by knowing the mac address.

It would be easier to just change the interface mac.

1 Like

That's what I have/had. As each device has same LLA each dnsmasq instance is listen to same LLA. I thought if I pass listen_address it is restricted by address in addition. But the IPs are not passed.

Funny fact aside. Each device has already different MAC. "ip a" is confirming that. But I think it is using original MAC. Thats why it is the same address.

NET_ADDR="$(uci get network.lan.ipaddr)"
uci -q delete dhcp.@dnsmasq[0].listen_address
uci add_list dhcp.@dnsmasq[0].listen_address="${NET_ADDR}"
/etc/init.d/dnsmasq restart
netstat -l -n -p | grep -e dnsmasq
1 Like
root@ZNBG6817:~# NET_ADDR="$(uci get network.lan.ipaddr)"
root@ZNBG6817:~# uci -q delete dhcp.@dnsmasq[0].listen_address
root@ZNBG6817:~# uci add_list dhcp.@dnsmasq[0].listen_address="${NET_ADDR}"
root@ZNBG6817:~# /etc/init.d/dnsmasq restart

root@ZNBG6817:~# netstat -l -n -p | grep -e dnsmasq
tcp        0      0*               LISTEN      10744/dnsmasq
tcp        0      0  *               LISTEN      10745/dnsmasq
tcp        0      0  *               LISTEN      10745/dnsmasq
tcp        0      0*               LISTEN      10745/dnsmasq
tcp        0      0 fd09:4f8:9663:0:02e0:4473:bf63:5b89:53 :::*                    LISTEN      10744/dnsmasq
tcp        0      0 fd09:4f8:9663:0:1b86:4b28:b93f:370a:53 :::*                    LISTEN      10744/dnsmasq
tcp        0      0 fe80::2c12:c74a:9557:b677:53 :::*                    LISTEN      10744/dnsmasq
tcp        0      0 ::1:53                  :::*                    LISTEN      10745/dnsmasq
tcp        0      0 fe80::1:53              :::*                    LISTEN      10745/dnsmasq
tcp        0      0 fe80::2c12:c74a:9557:b677:53 :::*                    LISTEN      10745/dnsmasq
tcp        0      0 fd09:4f8:9663:1:d15e:b13f:d6c8:3654:53 :::*                    LISTEN      10745/dnsmasq
tcp        0      0 fd09:4f8:9663:1:5721:f868:1939:6e75:53 :::*                    LISTEN      10745/dnsmasq
tcp        0      0 fe80::6830:f96c:ada3:b2de:53 :::*                    LISTEN      10745/dnsmasq
udp        0      0  *                           10744/dnsmasq
udp        0      0*                           10744/dnsmasq
udp        0      0  *                           10745/dnsmasq
udp        0      0  *                           10745/dnsmasq
udp        0      0*                           10745/dnsmasq
udp        0      0    *                           10744/dnsmasq
udp        0      0    *                           10745/dnsmasq
udp        0      0 ::1:53                  :::*                                10744/dnsmasq
udp        0      0 fd09:4f8:9663:0:02e0:4473:bf63:5b89:53 :::*                                10744/dnsmasq
udp        0      0 fd09:4f8:9663:0:1b86:4b28:b93f:370a:53 :::*                                10744/dnsmasq
udp        0      0 fe80::2c12:c74a:9557:b677:53 :::*                                10744/dnsmasq
udp        0      0 ::1:53                  :::*                                10745/dnsmasq
udp        0      0 fe80::1:53              :::*                                10745/dnsmasq
udp        0      0 fe80::2c12:c74a:9557:b677:53 :::*                                10745/dnsmasq
udp        0      0 fd09:4f8:9663:1:d15e:b13f:d6c8:3654:53 :::*                                10745/dnsmasq
udp        0      0 fd09:4f8:9663:1:5721:f868:1939:6e75:53 :::*                                10745/dnsmasq
udp        0      0 fe80::6830:f96c:ada3:b2de:53 :::*                                10745/dnsmasq

I've disabled IPv6 on WAN for the moment to tighten things and to avoid to redact to much.
lo is missing for 10556 cause I've blacklisted it for testing before.

To be clear, it works for me:

# netstat -l -n -p | grep -e dnsmasq
tcp        0      0*               LISTEN      17819/dnsmasq
udp        0      0*                           17819/dnsmasq
udp        0      0    *                           17819/dnsmasq

# grep -e ^listen-address= /tmp/etc/dnsmasq.*

# uci show dhcp.@dnsmasq[0]

# opkg list-installed dnsmasq
dnsmasq - 2.80-16.1

# ubus call system board
	"kernel": "4.14.195",
	"hostname": "openwrt",
	"system": "Intel(R) Core(TM) i7-7700HQ CPU @ 2.80GHz",
	"model": "QEMU Standard PC (i440FX + PIIX, 1996)",
	"board_name": "qemu-standard-pc-i440fx-piix-1996",
	"release": {
		"distribution": "OpenWrt",
		"version": "19.07.4",
		"revision": "r11208-ce6496d796",
		"target": "x86/64",
		"description": "OpenWrt 19.07.4 r11208-ce6496d796"
1 Like

I think I have to reset and start over with fresh setup. I tried already to much today it looks like.
I will report back if things are working as on your setup. :slight_smile: Thx so far @vgaetera and @trendy


The fe80... Address is not a complete address by itself because it's got link local scope a full address looks like


And specifies the link on which the address lives. It's totally normal to have the same numerical part on different links, and it doesn't mean they have "the same address" because the scope is different.

Routers NEVER forward link local addressed packets.


For me too now. [s]It turned out that if I restrict dnsmasq to an certain interface it is not possible to restrict to a certain IP in addition. After I've removed interface section it is bound to the given IP.

The manpage is telling that both at same time is possible. Or lets say it is not quite clear worded (or my english is to weak :smiley: ):[/s]

EDIT: It turned out that I'm d***. I had a conflicting entry left in my config. Now it is working with both entries. (strike out is not working it seems).

-a, --listen-address=
Listen on the given IP address(es). Both --interface and --listen-address options may be given, in which case the set of both interfaces and addresses is used. Note that if no --interface option is given, but --listen-address is, dnsmasq will not automatically listen on the loopback interface. To achieve this, its IP address,, must be explicitly given as a --listen-address option.

Thanks for pointing this out for me.

As there where multiple questions answered I will non't mark an explicit solution. Everything was helpful. :slight_smile:


See How to mark a topic as [Solved] step 6.

If however the solution can not be pinned to a single posting since the solution has been developed with input of multiple postings, a short summary of the solution steps is appreciated. You can then mark your own summary as the solution.


O. K. Here we go:


To restrict dnsmasq to a certain device:


uci set dhcp.@dnsmasq[0].nonwildcard='1'
uci set dhcp.@dnsmasq[0].interface='lan lo'

To restrict dnsmasq to certain IP address(es); here LAN only:


uci add_list dhcp.@dnsmasq[0].listen_address=",,::1,fdXX:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx"

For lo/loopback and LAN.

To verify:

LLA related stuff:

So I hope I didn't forgot anything relevant. :smiley:

1 Like

No need to define the localhost there, it is selected automatically too.

1 Like

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.