What's new

Dnsmasq and SSID

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

xiaodoudou

New Around Here
Hi,

I would like to make the DHCP server serve a specific gateway for a specific SSID.

I did try exploring the following way:
  • add interface wl0.2 (my virtual wifi interface) and do some rules with it:
The issue on that way that dnsmasq doesn't tag the dhcp query coming from wl0.2, the only tag are "lan" and "br0". It does mean even if we do some tweaking to the config, it will never this the queries coming from wl0.2 (or I am missing something)

Example of configuration:
File: /jffs/scripts/dnsmasq.postconf (with chmod +xxx) :
Code:
#!/bin/sh
CONFIG=$1
source /usr/sbin/helper.sh
pc_append "
log-dhcp
interface=wl0.2
dhcp-range=wl0.2,172.30.20.2,172.30.20.254,255.255.255.0,86400s
dhcp-option=wl0.2,3,172.30.20.254
dhcp-option=wl0.2,6,172.30.20.254,0.0.0.0
dhcp-option=wl0.2,252,"\n"
" /tmp/etc/dnsmasq.conf

  • create a bridge (br1) and integrate wl0.2 to it
I did try various configuration by searching what have been done on the forum, but it seems that the issue I encounter is even before any DHCP request, like the Ethernet layer is never mount (maybe link to the WPA2 encryption that is linked to br0 and not br1?)

That is pity that we can't have dnsmasq adding more tags to put all interfaces instead on the bridge one.

If you have any idea let me know ! :)

Thank you,
Cheers,
 
I think you almost got everything correct and ready. But seems to me you might have put in the wrong file. Have you checked the finished /tmp/etc/dnsmasq.conf? Everything looks right there..?

I would put your essential lines in /jffs/configs/dnsmasq.conf.add. That'll append your lines to /tmp/etc/dnsmasq.conf once the system finishes generating its own stuff.

I'm rarely a fan of postconf scripts. A line or two might be okay. More than that looks like a huge surgery. If such need comes, I would rather put the complete conf in /jffs/configs (that's what i did to my /jffs/configs/smb.conf and /jffs/configs/minidlna.conf*)

*But beware of minidlna.conf. There is a bug in asuswrt-merlin.
 
When I do:
Code:
service restart_dnsmasq

The file /tmp/etc/dnsmasq.conf does contain the tweaked configuration.

Even more, thanks to the config "log-dhcp" I do see the extra information like that on the log:
Code:
Sep 14 22:02:02 dnsmasq-dhcp[8926]: 3646455329 available DHCP range: 172.30.20.2 -- 172.30.20.254
Sep 14 22:02:02 dnsmasq-dhcp[8926]: 3646455329 available DHCP range: 172.30.20.2 -- 172.30.20.254
Sep 14 22:02:02 dnsmasq-dhcp[8926]: 3646455329 client provides name: Edouards-iPad
Sep 14 22:02:02 dnsmasq-dhcp[8926]: 3646455329 DHCPREQUEST(br0) 172.30.20.98 84:8e:0c:9c:48:4f 
Sep 14 22:02:02 dnsmasq-dhcp[8926]: 3646455329 tags: lan, br0
Sep 14 22:02:02 dnsmasq-dhcp[8926]: 3646455329 DHCPACK(br0) 172.30.20.98 84:8e:0c:9c:48:4f Edouards-iPad
Sep 14 22:02:02 dnsmasq-dhcp[8926]: 3646455329 requested options: 1:netmask, 3:router, 6:dns-server, 15:domain-name, 
Sep 14 22:02:02 dnsmasq-dhcp[8926]: 3646455329 requested options: 119:domain-search, 252
Sep 14 22:02:02 dnsmasq-dhcp[8926]: 3646455329 next server: 172.30.20.1
Sep 14 22:02:02 dnsmasq-dhcp[8926]: 3646455329 sent size:  1 option: 53 message-type  5
Sep 14 22:02:02 dnsmasq-dhcp[8926]: 3646455329 sent size:  4 option: 54 server-identifier  172.30.20.1
Sep 14 22:02:02 dnsmasq-dhcp[8926]: 3646455329 sent size:  4 option: 51 lease-time  1d
Sep 14 22:02:02 dnsmasq-dhcp[8926]: 3646455329 sent size:  4 option: 58 T1  11h13s
Sep 14 22:02:02 dnsmasq-dhcp[8926]: 3646455329 sent size:  4 option: 59 T2  20h13s
Sep 14 22:02:02 dnsmasq-dhcp[8926]: 3646455329 sent size:  4 option:  1 netmask  255.255.255.0
Sep 14 22:02:02 dnsmasq-dhcp[8926]: 3646455329 sent size:  4 option: 28 broadcast  172.30.20.255
Sep 14 22:02:02 dnsmasq-dhcp[8926]: 3646455329 sent size:  1 option:252   0a
Sep 14 22:02:02 dnsmasq-dhcp[8926]: 3646455329 sent size:  8 option:  6 dns-server  172.30.20.1, 172.30.20.1
Sep 14 22:02:02 dnsmasq-dhcp[8926]: 3646455329 sent size:  4 option:  3 router  172.30.20.1

Even if I connect to the wl0.2, the tags stay lan and br0.
I will try with the file "/jffs/configs/dnsmasq.conf.add" but as you can see on the previous log, dnsmasq does see two ranges (does mean it consider my second range link to wl0.2).

Thank you,
 
I have in my /jffs/configs/dnsmasq.conf.add
Code:
interface=wl1.1
dhcp-range=wl1.1,192.168.2.2,192.168.2.254,255.255.255.0,86400s
dhcp-option=wl1.1,3,192.168.2.1
dhcp-option=wl1.1,6,192.168.1.1

192.168.2.1 is the default gateway if memory serves me right. 192.168.1.1 is where dns runs. I used to run a SSID for VPN connection from above but I no longer do that for many months.

Worth a cross check between the option lines..
 
I have already check your post and try to reproduce it many times without any success :-(...

It may be a bug on the build 378.55 (RT-AC87U) then?

The DHCP lease doesn't care about the specific configurations; do you mind to test on your end to see if that still working?

Thanks,
 
It is definitely not a bug but just some missing configs.. :)

I did succeed to move forward by doing so:
File: /jffs/scripts/dnsmasq.postconf (with chmod +xxx) :
Code:
#!/bin/sh
CONFIG=$1
source /usr/sbin/helper.sh
logger "dnsmasq-dhcp: Configure wl0.2 to have special DHCP"
ifconfig wl0.2 172.30.20.2 netmask 255.255.255.0
iptables -D INPUT -i wl0.2 -j ACCEPT
iptables -I INPUT -i wl0.2 -j ACCEPT
ebtables -t broute -D BROUTING -i wl0.2 -p ipv4 -j DROP
ebtables -t broute -I BROUTING -i wl0.2 -p ipv4 -j DROP
pc_append "
log-dhcp
interface=wl0.2
dhcp-option=wl0.2,3,172.30.20.1
dhcp-option=wl0.2,6,8.8.8.8,8.8.4.4
" /tmp/etc/dnsmasq.conf

Note for people trying to replicate what I am doing:
  • it is important for the interface to have an IP to be listen by dnsmasq otherwise it won't deliver any lease
  • if you test with an iOS device, if the gateway doesn't respond to ping, it will take time to accept the lease (for testing purpose, do just a simple change on DNS before moving forward on more specific option)
  • the trick is thanks to ebtables and iptables
  • the iptables and ebtables that target delete (-D) are here to avoid duplicate in case a dnmasq reboot

Credits to @kvic to have documented his previous tweaks that help me to move forward on that.

The only thing that doesn't work right now that I do have to restart dnsmasq (service restart_dnsmasq) after the router stack is fully booted (I think it is link to the wifi layer)

I got to create the following script: /jffs/scripts/services-start (chmod +xxx)
Code:
#!/bin/sh
service restart_dnsmasq
 
Last edited:
Great to hear you get it working.

You're right we need the iptables & eatables rules. I still have some left over. I just gave it a try and my setup no longer works. dnsmasq can't receive MAC address in the request packet... LOL (That's fine..out of sight out of mind for something I no longer need)

It's a pleasant exchange of minds.

I pass on a left over piece for ebtables...for whom might find it helpful.
Code:
$ cat scripts/ebtables_isolate_vpnif.sh
#!/bin/sh

# Variables from source:
# tag, vpn_if
source /jffs/scripts/global.sh

# lan.c: any iface change state i.e. up <> down will flush ebtables
# hence, we need to check and add the rules

EBT_BRULE1="-p ipv4 -i $vpn_if -j DROP"
EBT_BRULE2="-p arp -i $vpn_if -j DROP"

#
logger -t $tag "Check $vpn_if isolation from br0"

if [ -n "$EBT_BRULE1" ] && [ `/usr/sbin/ebtables -t broute -L | grep -ice "$EBT_BRULE1"` != 1 ]; then
    cmd="/usr/sbin/ebtables -t broute -I BROUTING $EBT_BRULE1"
#    logger -t "$tag" "$cmd"
    `$cmd`
fi
if [ -n "$EBT_BRULE2" ] && [ `/usr/sbin/ebtables -t broute -L | grep -ice "$EBT_BRULE2"` != 1 ]; then
    cmd="/usr/sbin/ebtables -t broute -I BROUTING $EBT_BRULE2"
#    logger -t "$tag" "$cmd"
    `$cmd`
fi

logger -t $tag "done"
 
On my side the rule regarding ebtables and arp does break the ability to speak to the network.

In fact, when I do arp -a to check what is going on I do have the mac address of the device set to unknown on br0.
Are you sure this rule is needed? I do think the ipv4 layer with your iptables rules will ensure to be isolated. Maybe that you want to make sure the L2 is also isolated?

Anyway, thanks again :)
 

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top