[Dnsmasq-discuss] Monthly Posting
Hi, "How To Ask Questions The Smart Way" has immediately after the introduction an advice on before you ask. http://www.catb.org/esr/faqs/smart-questions.html#before Following that advice is still no guarantee for a (good) response. So when you are still stuck with something that you think it is dnsmasq related, you have to make more effort. Greatest challenge is most likely being persistent in solving the problem. ( Not being persistent in demanding an answer. ) The dnsmasq manual page is feature complete. And known as "hard to read" for those who are new to it. But still do read it and try to understand it. Reading it again is known being effective for getting better understanding. Find a copy of it in source code of dnsmasq and read it by `man man/dnsmasq.8`, or when installed by `man dnsmasq` or at https://dnsmasq.org/docs/dnsmasq-man.html Pattern seen on the mailing list is unawareness of network-server-client-model. Expressing such problems is indeed hard, but also the road to a solution. Know that you are the main stake holder of the problem that you are facing. The highest reward for finding a solution goes to you. Keep the eco system that you are consulting healthy by sharing also your success stories. Avoid "DNS doesn't work", make it "My DNS client gets odd replies from dnsmasq", "My DNS requests don't get forwarded" or another non-generic issue. Use real DNS client tools like `dig` or `host` (instead of `ping`). Set the configuration --log-queries. That will allow you to see if the queries are getting to dnsmasq, and it will give you a full dump of the DNS cache (including DHCP derived names) if you send the dnsmasq process SIGUSR1. Both of these will help in diagnosing the problem. For non-biased views is networksniffing recommented. When `tcpdump` or `wireshark` is used for such examinations, provide the mailinglist with an URL to `.pcap`-file. Karma bonus points for providing an URL that can be `wget`. So prevent that your community members get exposed to websites that scream advertisements or the need for JavaScript. Text version output of network sniffs don't show up well after being put in an email. Please take the pain of uploading an .pcap file insteadof multipling the pain of malformed netsniffer output. In case of got stuck in finding a solution, describe also the original problem you wanted to solve. ( See also https://xyproblem.info/ which starts with: The XY problem is asking about your attempted solution rather than your actual problem. This leads to enormous amounts of wasted time and energy, both on the part of people asking for help, and on the part of those providing help. ) Dnsmasq is a mature project, meaning not often a release. However we constantly want to improve. Yes, patches welcome. Patches are not always reviewed within three days. Retransmit of your review request after four days is not too pushy. Aim for common interest. If you find it here, fine. If you cannot find it here, you might found a clue for looking elsewhere on "common interest". Do know there are real humans behind the email addresses. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] dnsmasq is offering ip from different pool
On Sun, Aug 06, 2023 at 01:24:02AM +0300, 0zl wrote: > On 8/4/23 09:24, shashikumar Shashi wrote: > > Hi, > > > > Observing that dnsmasq is offering DHCP IP to the client } } Observing that dnsmasq is offering DHCP IP-address to the client > > from a vlan pool which is in DOWN state. > > > > E.g. If there are 3 dhcp pools > > > > vlan9 (State UP) : Range: 192.168.9.1-192.168.9.254 > > vlan19 (State UP): Range: 192.168.19.1-192.168.19.254 > > vlan99 (State DOWN): Range: 192.168.99.1-192.168.99.254 > > > > 1) Client on vlan9 gets IP from vlan9 pool > > 2) Client moves to vlan19, releases IP Acknowledge on "Client moves". The 'releases IP' is probably something like "I'm unaware that IP stands for Internet Protocol and want to try how far I can get by being vague how the release of the DHCP lease was done" > > 3) Client on vlan19 requests IP --> dnsmasq offers IP 192.168.99.xx from > >vlan99 pool (incorrect pool), instead of vlan19 pool. > > > > If the vlan99 is in UP state, then dnsmasq offers the IP from the vlan19 > > pool (the correct pool). > > > > Has anyone come across such an issue? > > > I've encountered this issue as well, The issue of moving clients, the issue of interfaces go down and come up, the issue of moving clients AND flipping interfaces? > I ended up working around it by creating bridges that have those vlans > as their bridge port. This way the bridge stays up to dnsmasq even > when I take one of these vlans down. That deals only with keeping interfaces present to dnsmasq. Nothing about a moving client. Thing is that poor problem descriptions do not contribute to improvement. Not your mom ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
[Dnsmasq-discuss] dhcp-script: environment var DNSMASQ_INTERFACE not always set
Hello hackers,
according to 'man dnsmasq' the var DNSMASQ_INTERFACE stores the name
of the interface on which the request arrived; this is not set for "old"
actions when dnsmasq restarts.
all this in done in src/helper.c:
my_setenv("DNSMASQ_INTERFACE", strlen(data.interface) != 0 ? data.interface :
NULL, &err);
With my (up-to-date) OpenWRT setup this seems sometimes not the case.
Ontop of my dhcp-script.sh[1] i do (something like):
#!/bin/sh
MODE="$1"
MAC="$2"
IP="$3"
HOST="$4"
if [ -n "$DNSMASQ_INTERFACE" ]; then
log "provided dev: $DNSMASQ_INTERFACE mode: $MODE mac: $MAC ip: $IP host:
$HOST"
else
DEV="$( guess_dev "$IP" )"
log "guessed dev: $DEV mode: $MODE mac: $MAC ip: $IP host: $HOST"
fi
Here the log output, when env-var DNSMASQ_INTERFACE is empty/unset and MODE is
arp-add/add(!):
There are 2 interesting lines - both from the same client (linux, under my
control):
provided dev: br-mastergate mode: old mac: e4:f8:9c:73:8b:1f ip: 100.66.19.131
host: filmforecast
guessed dev: br-mastergate mode: add mac: e4:f8:9c:73:8b:1f ip: 100.66.19.131
host: unset
root@box:~ logread | grep e4:f8:9c:73:8b:1f
Sun Aug 6 21:12:38 2023 daemon.info kalua: /usr/lib/dnsmasq/dhcp-sc:
dhcp_script() provided dev: br-mastergate mode: old mac: e4:f8:9c:73:8b:1f ip:
100.66.19.131 host: filmforecast
Sun Aug 6 21:12:38 2023 daemon.info kalua: /usr/lib/dnsmasq/dhcp-sc:
dhcp_old() 'e4:f8:9c:73:8b:1f' is from 'br-mastergate' = roaming-DEV HOST:
filmforecast
Sun Aug 6 21:16:01 2023 daemon.info hostapd: phy1-ap0: STA e4:f8:9c:73:8b:1f
IEEE 802.11: authenticated
Sun Aug 6 21:16:01 2023 daemon.info kalua: /usr/sbin/cron.wireless_: iwevent()
EVENT 6993: 'phy1-ap0: new station e4:f8:9c:73:8b:1f'
Sun Aug 6 21:16:01 2023 daemon.info hostapd: phy1-ap0: STA e4:f8:9c:73:8b:1f
IEEE 802.11: associated (aid 3)
Sun Aug 6 21:16:01 2023 daemon.notice hostapd: phy1-ap0: AP-STA-CONNECTED
e4:f8:9c:73:8b:1f auth_alg=open
Sun Aug 6 21:16:01 2023 daemon.info dnsmasq-dhcp[19331]:
DHCPREQUEST(br-mastergate) 100.65.42.131 e4:f8:9c:73:8b:1f
Sun Aug 6 21:16:01 2023 daemon.info dnsmasq-dhcp[19331]:
DHCPNAK(br-mastergate) 100.65.42.131 e4:f8:9c:73:8b:1f wrong address
Sun Aug 6 21:16:01 2023 daemon.info kalua: /usr/sbin/cron.wireless_:
wifi_signal_get() dev: phy1-ap0 mac: e4:f8:9c:73:8b:1f try: 3 signal: -64 file:
''
Sun Aug 6 21:16:01 2023 daemon.info kalua: /usr/sbin/cron.wireless_: iwevent()
worker(7175) dev:phy1-ap0 ch:5 MODE: new MAC: e4:f8:9c:73:8b:1f - signal: '-64'
border: '-73' try: 4
Sun Aug 6 21:16:01 2023 daemon.info kalua: /usr/sbin/cron.wireless_: iwevent()
mac2ipv4(20) grabbed ip from arp: e4:f8:9c:73:8b:1f -> 100.65.42.131
Sun Aug 6 21:16:01 2023 daemon.info kalua: /usr/sbin/cron.wireless_: iwevent()
worker(7175) dev:phy1-ap0 ch:5 MODE: new MAC: e4:f8:9c:73:8b:1f - ip:
'100.65.42.131' signal: '-64' (is_good)
Sun Aug 6 21:16:01 2023 daemon.info dnsmasq-dhcp[19331]:
DHCPDISCOVER(br-mastergate) 100.65.42.131 e4:f8:9c:73:8b:1f
Sun Aug 6 21:16:01 2023 daemon.info dnsmasq-dhcp[19331]:
DHCPOFFER(br-mastergate) 100.66.19.131 e4:f8:9c:73:8b:1f
Sun Aug 6 21:16:01 2023 daemon.info dnsmasq-dhcp[19331]:
DHCPREQUEST(br-mastergate) 100.66.19.131 e4:f8:9c:73:8b:1f
Sun Aug 6 21:16:01 2023 daemon.info dnsmasq-dhcp[19331]:
DHCPACK(br-mastergate) 100.66.19.131 e4:f8:9c:73:8b:1f filmforecast
Sun Aug 6 21:16:01 2023 daemon.info kalua: /usr/lib/dnsmasq/dhcp-sc:
dhcp_script() provided dev: br-mastergate mode: old mac: e4:f8:9c:73:8b:1f ip:
100.66.19.131 host: filmforecast
Sun Aug 6 21:16:01 2023 daemon.info kalua: /usr/lib/dnsmasq/dhcp-sc:
dhcp_old() 'e4:f8:9c:73:8b:1f' is from 'br-mastergate' = roaming-DEV HOST:
filmforecast
Sun Aug 6 21:17:11 2023 daemon.info kalua: /usr/lib/dnsmasq/dhcp-sc:
dhcp_script() guessed dev: br-mastergate mode: add mac: e4:f8:9c:73:8b:1f ip:
100.66.19.131 host: unset
Sun Aug 6 21:17:11 2023 daemon.info kalua: /usr/lib/dnsmasq/dhcp-sc:
dhcp_add() 'e4:f8:9c:73:8b:1f' is from 'br-mastergate' = roaming-DEV HOST: unset
Sun Aug 6 21:17:11 2023 daemon.info kalua: /usr/lib/dnsmasq/dhcp-sc:
F36-stube_dhcp-add() [OK] _weblogin login_check e4:f8:9c:73:8b:1f
the environment during the "guessed dev" call (without DNSMASQ_INTERFACE set)
was written ontop of the dhcp-script with:
{
echo "# $@"
set
} >>"/tmp/dhcp-$2-$1-$3"
root@F36-stube:~ cat /tmp/dhcp-e4:f8:9c:73:8b:1f-arp-add-100.66.19.131
# arp-add e4:f8:9c:73:8b:1f 100.66.19.131
FUNCNAME=''
HOME='/'
HOSTNAME='F36-stube'
IFS='
'
LINENO=''
OPTIND='1'
PATH='/usr/sbin:/usr/bin:/sbin:/bin'
PPID='19337'
PS1='\w \$ '
PS2='> '
PS4='+ '
PWD='/'
SHLVL='1'
TERM='linux'
USER_DHCPSCRIPT='/etc/dhcp-script.d/10dhcpscript'
root@F36-stube:~ dnsmasq --version
Dnsmasq version 2.89 Copyright (c) 2000-2022 Simon Kelley
...
Maybe somebody has an idea why this can happen, looking through the
source it is not obvious and *should not happen* 8-) => except 'data.interface'
is unknown.
This happens on different CPU architectures, at least: mips, arm
