Re: [Dnsmasq-discuss] [PATCH] fix the source address of dhcpv6 relay-forward packets

2022-09-06 Thread Simon Kelley 



On 02/09/2022 14:03, Luis Thomas wrote:

Hi everyone,

We are using both dnsmasq and isc dhcrelay as dhcp-relays for dhcpv6
only.

we launch dnsmasq like this:

dnsmasq -d \
--conf-file=/dev/null \
--dhcp-relay fd12:3456::b6e3:f9ff:fea5:fa5b,2020:abcd::1 \
--except-interface=lo \
--interface=tun0,eno2 \
--port 0

and isc dhcrelay like this:

dhcrelay -d -6 -l tun0 -u 2020:abcd::1%eno2 --no-pid

tun0 address is fd12:3456::b6e3:f9ff:fea5:fa5b.
eno2 address is 2020:abcd::2.

With dnsmasq the source address of the relay-forward packets is the
address of tun0.
With dhcrelay the source address of the relay-forward packets is the
address of eno2.

We don't really understand why it so on dnsmasq (or dhcrelay for that
matter), could someone explain it to us ? RFC 3315 section 20. Relay
Agent Behavior says nothing about the source address.

In our use case it makes more sense that the source address of the
relay-forward packet is the address of eno2 since it's the outbound
interface (and the one that will receive the replies).

Nevertheless the attached patch fixes this issue as it sets the source
address of relay-forward packets to be the address of the "upper"
interface.

We've also attached two filtered pcap files of a wireshark capture
showing the difference before and after the patch on the machine
hosting the dhcp server and the machine hosting the dhcp_relay.

Regards,




Hmm,

Looking at the code, I obviously intended the current behaviour: there's 
a comment to that effect /* source address == relay address */ and the 
code goes to the effort of setting up the source address and calling 
send_from() which supplies that to the kernel.


The question, therefore, is why? I think this probably a carry-over from 
DHCPv4, where the "giaddr" field is overloaded to specify the subnet on 
which the client resides, and the global address of the relay. It's also 
the case that a configured V4 client communicates directly with the 
server, bypassing the relay , so the server has to have a route to the 
client-side subnet of the relay in all cases.


DHCPv6 is not the same: the relay is always involved in client-server 
communication; it's actually a proxy, not a relay, so the need for the 
server to have a route to the client-side is no longer there and it 
makes more sense for the server to use the server-side address to return 
messages to the client.


You're right that RFC3315 is silent on this, and so is RFC8415, as far 
as I can see. Googling did find 
https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst9500/software/release/16-8/configuration_guide/sec/b_168_sec_9500_cg/b_168_sec_9500_cg_chapter_0101000.pdf 
and 
https://techhub.hpe.com/eginfolib/networking/docs/switches/5710/5200-4993_l3-ip-svcs_cr/content/517706420.htm 
both of which state that the default is the server-side interface 
address. Of course, the behaviour of ISC code is a strong push in the 
same direction.



TLDR; I think the behaviour change you want is correct. I understand why 
the patch you submitted went for minimal-change, but I'd like to go for 
maximum-simplification instead, removing the calculation of the address 
on "from" and the call to send_from(). I will push that in the next day 
or two.



Cheers.

Simon.



___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss


___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss

[Dnsmasq-discuss] 'dnsmasq_client_id' not always present on dhcp-scripts

2022-09-06 Thread Taylor Fox 
Hello,
 I am trying to write a script for logging & notification whenever a
new DHCP lease is issued, and I currently have a script that uses the
`dnsmasq_client_id` environment variable to get the MAC address of the
device that the lease was issued, but I have had an issue where on some
device that variable is not present and causes the script to fail. Could
anyone shed a light on why this is not working? Otherwise, any better way
of finding the MAC address other than diffing /etc/dhcp.leases.


Thanks in advance.
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss

[Dnsmasq-discuss] Monthly posting

2022-09-06 Thread 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 quick 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 man 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 and the need for JavaScript.

Text version output of network sniffs don't show well after being put
in an email. Please take the pain of uploading an .pcap file insteadof
multipling the pain of malformed netsniffer output.


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 eight 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

[Dnsmasq-discuss] Fwd: Monthly posting

2022-09-06 Thread john doe 

For the sake of clarity, the maintainer of this project has nothing to
do with this.
The below e-mail is actually from someone else.

 Forwarded Message 
Return-Path: 
Authentication-Results: mail.com; dkim=none
Received: from thekelleys.org.uk ([85.119.82.65]) by mx.mail.com
(mxgmxus008 [74.208.5.22]) with ESMTPS (Nemesis) id
0LiDfJ-1p8Inr0Ay3-00nN34 for ; Tue, 06 Sep 2022
19:25:44 +0200
Received: from localhost ([127.0.0.1] helo=thekelleys.org.uk) by
thekelleys.org.uk with esmtp (Exim 4.92) (envelope-from
) id 1oVc8H-0008Vm-MC
for johndoe65...@mail.com; Tue, 06 Sep 2022 17:13:05 +
Received: from hop.stappers.nl ([141.105.120.46]) by thekelleys.org.uk
with esmtp (Exim 4.92) (envelope-from ) id
1oVc8F-0008Vg-J1 for dnsmasq-discuss@lists.thekelleys.org.uk; Tue, 06
Sep 2022 17:13:03 +
Received: from gpm.stappers.nl (gpm.stappers.nl
[IPv6:2a02:a46d:659e:1::696e:626f]) by hop.stappers.nl (Postfix) with
ESMTP id 0F08D200F9 for ; Tue,
6 Sep 2022 17:13:03 + (UTC)
Received: by gpm.stappers.nl (Postfix, from userid 1000) id B36BA304049;
Tue,  6 Sep 2022 19:13:02 +0200 (CEST)
Date: Tue, 6 Sep 2022 19:13:02 +0200
From: Monthly posting 
To: dnsmasq-discuss@lists.thekelleys.org.uk
Message-ID: <20220906171301.266tq4j47fc6b...@gpm.stappers.nl>
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: NeoMutt/20170113 (1.7.2)
Subject: [Dnsmasq-discuss] Monthly posting
X-BeenThere: dnsmasq-discuss@lists.thekelleys.org.uk
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Dnsmasq discussion 
List-Unsubscribe:
,


List-Archive: 
List-Post: 
List-Help:

List-Subscribe:
,
 
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: dnsmasq-discuss-boun...@lists.thekelleys.org.uk
Sender: "Dnsmasq-discuss" 
Envelope-To: 
X-GMX-Antispam: 0 (Mail was not recognized as spam); Detail=V3;
X-Spam-Flag: NO
X-UI-Filterresults:
notjunk:1;V03:K0:v62ZRdLR71I=:NA/YTvprDeD1M5h47DefebcUUV
UXz9CRK5IKFlyd1/JJ+cIwRAyzdrXQb5UDvf1ZQxethR7unvGXg29OkL+0MfV94pteoejLMBf
Z3nXoN1SzxaBwX62qoeVNNCb+XUW5ltej5AlpHWX8eVfJa16NgAmB56AagInnU3vQg6ABF3AK
rmyuwh+ji07DTZ0y0jQoHDokCk8I6GgcKUVtpxfXIOcES9/BYCgb6YmVuEkcvg21bjrSrRdFD
cN6OAvY62jKvVAwIwZWzm3Ct6z4PufTezjOdhnKC3y/IK0oD4kUhy+BtuVbAesE/4fmLxYBai
WNBO61IFsID/Q0PEhoMztQCVfDQFhZ/8r9SIkx/bMxjec9gXec1w0+QRTpBu3MjstrZctRmri
AKncx1GB872BpLjQ7aLjlxSVW9GN8reHSZv4Ka9XW0Q4OYbjSsPmAaNZLtkErR05bc857xvoa
7H6GCdn0ntjX26ROxT7lDyYcPcde7ZA0/+I/8INiPd7rIJzwaNHMTgy7P8rBChDuzbWHwOXZB
TwkUFDcu5zB7IdPDMUQY2Sgb1BdXhmEUkDtHzjsWySAjTVTTM5UhvkcDjkXI/MTlGpmCDkSvk
5VMBolMI++QZXM3YUnwi39vbcrrnS/n8B5i4rhv1Zy6MwmjzvMzSihIxWkiWP30CNUy6DTM+U
NBmKkXcMCxocqgqC96LPKPlaPN6L6hPRl528Ii/cZCSzQFsmWPvw8Iamu3JPR0htJu1v85gVE
+jair+qdEdP1YCoSHxqF3piMemfe4JDu/swCvqxPQlUuSN21vm2QPZB6NosUVYygbdX0jQ/tg
kaMAZTKgV4T08KFQoRN5TrvEfC+7cg4TACgG7xgwGmdonbR3cqvgZVoNahnOmFFI0vg07F1D7
MwH/Z8Eu6ybbu7LY6jyFtbts6TRc79nb0cSg9PKo+hR19OEDQbDPkM89dGDUST7ZQt8Z8Bd8y
ehQgSwM1AN5hAQNYneBCiF/X72lrxXy+PTI2UP/XmbGb405FHWpxnfVvMPOUK201H6G7i0+2Q
e0vN9aX7hf2F5aNxDNWhjledbtp0PJLMHB8TfO1PWq+n66bNweOonwXbLKvjgOK8WydIsanst
vAReU2s+AiguKzGDfL67Mxm7PLYsZIlDoelLiRpH6w3t2GHfFERn/IAlms0VMbP03BLWfpqdO
7iIWbVXKuT6BLwEsu1Ez858Lfcuv5gHuNNupKE04Wjo7kiCOC43h32qnGIvoF95G3P0RI64jb
c0+FATUoERLCvMy+czunShGwH8Q/b/kdDAh0Bo2KjfZ43VJy8DcrcXRFI1IEZcF/fjqDrBvUf
b9od0/GARM6+BajgYhQdSSq09l6pZTRZLSgjcyAXBUQNwX0+db+YKO1wFtctHc7937Es4i/Oc
nRa7TeqrXOeR+9jfSQCnznNEII8NE0vs111z9N3/AnQNPHdb39qy8crjpYQ9F1LZirZRCOi9V
KNb3ICVLeQxyPybseHot5xY9qrE0q8GDwEQ59WQr/QZPBnLji6C3xtmg9YAYkSzkCcsU5sO0m
ecDlUkC7sTxGA8UgZEDIDukp7C7NpxyWB1+N1dYUn/H5gq6goMDV5YkIbGm6dUY8pjfbBJinV
EFrznsufpC4taZ+K3kJmQoG6ZLwMlRngA/qog9baCdwb++bvCxpg3sKUQJagMNIK4ksZs0AyU
YCPOlvaj8wRefATJUh5a5ttrJ8MR+HslJTWCsq6+FfJbl74jzGx3mmWGIXMnKAoCO1GdJOzh7
a6jooHoXvWVAKs9WHqHI5/s4vR9BKysFtqxZDCl6uYcLTDTgvLotAQzT+kwwolnklnpcfYIm4
9guWWqCJFsk9PYqX4s1EBbXoOHtp4b2nvlT4ysFEi262mwbuWau4XeKPcLFhspR4ka0Z5Y0gg
le11edjtQ/pZm8CBEVbD9xKvoiOuDfRN/FDN6Qzl10YoF5j9zhflCeqTP5Xhtlq1InAg2ACpH
nBeB7K4g73SO2Cd3LgMmrzIMmH6g77l+krnflYYkwX2oRGv5KysKivzhMwZQjH6Laptbfa7T6
hwSlhG4YGKzL4E4PpEhxpILPy7L6VqSIakNrDGxcDPo3P2XlOOw5o/SNB3nr2i2MD5xASuZ4m
zTymEIUPcauipIHhFFi1D1MfRW72VCauu6HsXVGDLn5PV8KYo3RJOJuBpcA8A4g1lCSM3TpV2
J1nS1hK661nxsAqz14a/EDH+gXRE5eXCe4RypiAtkvnCzgIevtnjy4Oh7Gv+nCdtWuSl4j3JU
NMek5mFWQSsJ+nLo/v7XURMjdPrKGqohVj4eC7LMc7YEC7M4iK45mXS4mEfbZuo5SOQm3Llu9
umqRjKPXTJZFzglNU61u6n1mJAdwAEIBprdRExQHMPtXVXWI6MNhCMGTv4O4qR9kkbPy2dVs/
+juj7nPhGWIE89aHBnprZcGGAdjqdR5+OM5+LL6oOYh+KrHiNl31LNP8QB63s2BnJnDs3FifN
enbFT3mb2oUCKYbKz2lRI98IEgrfCBRS66LRfB+saoQzYUhR/p8RD/5fGr9uUu/lxB

Re: [Dnsmasq-discuss] 'dnsmasq_client_id' not always present on dhcp-scripts

2022-09-06 Thread Simon Kelley 



On 06/09/2022 17:23, Taylor Fox wrote:

Hello,
  I am trying to write a script for logging & notification whenever 
a new DHCP lease is issued, and I currently have a script that uses the 
`dnsmasq_client_id` environment variable to get the MAC address of the 
device that the lease was issued, but I have had an issue where on some 
device that variable is not present and causes the script to fail. Could 
anyone shed a light on why this is not working? Otherwise, any better 
way of finding the MAC address other than diffing /etc/dhcp.leases.





Some DHCP clients don't provide a client-id. If the client doesn't 
provide a client-id, the variable will not be set. If you look in 
/etc/dhcp.leases, if the fifth and final field on a line is "*" then no 
client-id was provided.


extracting the MAC address from a client-id is risky: client-ids may be 
constructed in other ways.


The MAC address is always provided (at least for DHCPv4) as the second 
argument of the script, does that solve the problem?



Simon.




Thanks in advance.

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss


___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss