Re: [Dnsmasq-discuss] DNSMASQ DHCP Options for CAPPORT or RFC8908 [PATCH]

[Florian Baaske via Dnsmasq-discuss]

Hi Simon,

thanks for your reply.

The mac address is required by the CAPPORT implementation I would like to
use. I will not say that the mac address is always required when using
CAPPORT but for the selected implementation (Aruba ClearPass) it is
required.

Many thanks,
Florian



On Fri, May 26, 2023 at 6:21 PM Simon Kelley 
wrote:

> What I can't get from a quick reading of the RFCs it how the
> captive-portal URI is derived from the client characteristics. The RFCs
> imply that the final, encoded part of the URI is an opaque identifier
> that's returned by the DHCP part of the captive portal and then accepted
> by the http part. It's not even clear to me that it needs to be unique
> to a client. Enlightenment on this matter would be appreciated.
>
> One thing that should be done and it very easy is to add the RA option
> in the same way that others are just derived from the corresponding
> DHCPv6 option.
>
> Simon.
>
>
>
> On 26/05/2023 13:20, Florian Baaske via Dnsmasq-discuss wrote:
> > Hi Pert,
> >
> > thanks for the help. Much appreciated.
> >
> > I found something in regards to ISC as the DHCP server and thought that
> > DNSMASQ might have the same feature.
> >
> > BR
> > Florian
> >
> > On Fri, May 26, 2023 at 12:26 PM Petr Menšík  > > wrote:
> >
> > Added captive-portal DHCP option to database.
> >
> > But I am afraid dnsmasq can serve different URLs only for explicitly
> > registered clients with separate options. It cannot make the url
> > dynamically based on incoming request. There is no script able to
> > customize offered options online.
> >
> > On 5/26/23 09:16, Florian Baaske via Dnsmasq-discuss wrote:
> >>
> >> Hi,
> >> I would like to setup a Guest network with DNSMASQ. For that Guest
> >> network, I would like to use CAPPORT or RFC8908.
> >> To make this work, the DHCP server needs to send option 114, which
> >> should not be a problem, but option 114 should have the URL to the
> >> CAPPORT server including the MAC address of the client.
> >> So, my questions would be, is it possible to include the clients
> >> MAC address in the DHCP response?
> >> I have found a solution for ISC DHCP but was not able to find
> >> anything for DNSMASQ. If someone could help, this would be much
> >> appreciated.
> >>
> >> BR
> >> Florian
> >>
> >>
> >> ___
> >> Dnsmasq-discuss mailing list
> >> Dnsmasq-discuss@lists.thekelleys.org.uk   Dnsmasq-discuss@lists.thekelleys.org.uk>
> >>
> https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
> 
> >
> > --
> > Petr Menšík
> > Software Engineer, RHEL
> > Red Hat,https://www.redhat.com/  
> > PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
> >
> > ___
> > Dnsmasq-discuss mailing list
> > Dnsmasq-discuss@lists.thekelleys.org.uk
> > 
> >
> https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss <
> 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 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

Re: [Dnsmasq-discuss] [PATCH] TCP client timeout setting

[Simon Kelley]

On 26/05/2023 17:19, Simon Kelley wrote:

The long delay awaiting a connection from a non-responsive server may be 
improved by reducing the value of the TCP_SYNCNT socket option, at least 
on Linux.




Setting TCP_SYNCNT to 2 limits the delay for a non responsive address to 
about 8 seconds, which is mouch more sensible.


Simon.


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

Re: [Dnsmasq-discuss] [PATCH] TCP client timeout setting

[Simon Kelley]

On 25/05/2023 20:32, Petr Menšík wrote:
This problem is best tested by an example, taken from [2] but a bit 
modified.


Let's create hepothetical network issue with one forwarder, which worked 
fine a while ago.


$ sudo iptables -I INPUT -i lo -d 127.0.0.255 -j DROP

Now start dnsmasq and send tcp query to it

$ dnsmasq -d --log-queries --port 2053 --no-resolv --conf-file=/dev/null 
--server=127.0.0.255 --server=127.0.0.1

$ dig +tcp @localhost -p 2053 test

;; communications error to ::1#2053: timed out
;; communications error to ::1#2053: timed out
;; communications error to ::1#2053: timed out
;; communications error to 127.0.0.1#2053: timed out

; <<>> DiG 9.18.15 <<>> +tcp @localhost -p 2053 test
; (2 servers found)
;; global options: +cmd
;; no servers could be reached

Because dig waits much shorter time than dnsmasq does, it never receives 
any reply. Even when the other server is responding just fine. That is 
main advantage of having local cache running, isn't it? It should 
improve things!


Now lets be persistent and keep trying:

$ time for TRY in {1..6}; do dig +tcp @localhost -p 2053 test; done

After few timeouts, it will finally notice something is wrong and tries 
also the second server, which will answer fast. However this works only 
with dnsmasq -d, which is not used in production. If I replace it with 
dnsmasq -k, it will not answer at all!


$ dnsmasq -k --log-queries --port 2053 --no-resolv --conf-file=/dev/null 
--server=127.0.0.255 --server=127.0.0.1

$ time for TRY in {1..8}; do dig +tcp @localhost -p 2053 test; done

...
;; communications error to ::1#2053: timed out
;; communications error to ::1#2053: timed out
;; communications error to ::1#2053: timed out
;; communications error to 127.0.0.1#2053: timed out

; <<>> DiG 9.18.15 <<>> +tcp @localhost -p 2053 test
; (2 servers found)
;; global options: +cmd
;; no servers could be reached


real    5m20,602s
user    0m0,094s
sys    0m0,115s

This is because with -k it spawns tcp workers, which start always with 
whatever last_server prepared by last UDP. And until any UDP query 
arrives to save the day, it will stubbornly try non-responding server 
first. Even when the other one answers in miliseconds. Notice it have 
been trying 5 minutes without success.


I think this has to be fixed somehow. This is corner case, because TCP 
queries are usually caused by UDP queries with TC bit set. But there 
exist real-world examples, where TCP only query makes sense. But dnsmasq 
does not handle them well. Summarized this at [3].


My proposal would be sending UDP query + EDNS0 header in case sending 
query failed to the main process, which can then trigger forwarders 
responsiveness and change the last_server to a working one. So 
subsequent attempts do not fall into the blackhole again and again. 
EDNS0 header would be there to increase chance for a positive reply from 
upstream, which can be cached.


Would you have other ideas, how to solve this problem?

Cheers,
Petr




The long delay awaiting a connection from a non-responsive server may be 
improved by reducing the value of the TCP_SYNCNT socket option, at least 
on Linux.



I think it's pretty easy to pass back the identity of a server which is 
responding to TCP connections to the main process using the same 
mechanism that passes back cache entries. The only wrinkle is if the 
list of servers changes between forking the child process and is sending 
back data about which server worked, for instance is the srever list 
gets reconfigured. Detecting that just needs an "epoch" counter to be 
included. It's rare, so just rejecting a "use this server" update from a 
child that was spawned in a different epoch from the current one should 
avoid problems. Provided the epoch is the same, indices into the 
server[] array are valid to send across the pipe.


I like the idea of using a different valid server for TCP and UDP.

Note that the TCP code does try to pick a good server. It's not 
currently much good with long connection delays, but it does cope with 
ignoring a server which accepts connections and then immediately closes 
them. I guess that must have been a real-world problem sometime.


Cheers,

Simon.

[2] https://bugzilla.redhat.com/show_bug.cgi?id=2160466#c6
[3] https://bugzilla.redhat.com/show_bug.cgi?id=2160466#c13

On 19. 05. 23 13:40, Petr Menšík wrote:
When analysing report [1] for non-responding queries over TCP, I have 
found forwarded TCP connections have quite high timeout. If for 
whatever reason the forwarder currently set as a last used forwarder 
is dropping packets without reject, the TCP will timeout for about 120 
seconds on my system. That is way too much, I think any TCP clients 
will give up far before that. This is just quick workaround to improve 
the situation, not final fix.


...

[1] https://bugzilla.redhat.com/show_bug.cgi?id=2160466


___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.o

Re: [Dnsmasq-discuss] DNSMASQ DHCP Options for CAPPORT or RFC8908 [PATCH]

[Simon Kelley]

What I can't get from a quick reading of the RFCs it how the 
captive-portal URI is derived from the client characteristics. The RFCs 
imply that the final, encoded part of the URI is an opaque identifier 
that's returned by the DHCP part of the captive portal and then accepted 
by the http part. It's not even clear to me that it needs to be unique 
to a client. Enlightenment on this matter would be appreciated.


One thing that should be done and it very easy is to add the RA option 
in the same way that others are just derived from the corresponding 
DHCPv6 option.


Simon.



On 26/05/2023 13:20, Florian Baaske via Dnsmasq-discuss wrote:

Hi Pert,

thanks for the help. Much appreciated.

I found something in regards to ISC as the DHCP server and thought that 
DNSMASQ might have the same feature.


BR
Florian

On Fri, May 26, 2023 at 12:26 PM Petr Menšík > wrote:


Added captive-portal DHCP option to database.

But I am afraid dnsmasq can serve different URLs only for explicitly
registered clients with separate options. It cannot make the url
dynamically based on incoming request. There is no script able to
customize offered options online.

On 5/26/23 09:16, Florian Baaske via Dnsmasq-discuss wrote:


Hi,
I would like to setup a Guest network with DNSMASQ. For that Guest
network, I would like to use CAPPORT or RFC8908.
To make this work, the DHCP server needs to send option 114, which
should not be a problem, but option 114 should have the URL to the
CAPPORT server including the MAC address of the client.
So, my questions would be, is it possible to include the clients
MAC address in the DHCP response?
I have found a solution for ISC DHCP but was not able to find
anything for DNSMASQ. If someone could help, this would be much
appreciated.

BR
Florian


___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk  

https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss  



-- 
Petr Menšík

Software Engineer, RHEL
Red Hat,https://www.redhat.com/  
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB

___
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 mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] DNSMASQ DHCP Options for CAPPORT or RFC8908 [PATCH]

[Florian Baaske via Dnsmasq-discuss]

Hi Pert,

thanks for the help. Much appreciated.

I found something in regards to ISC as the DHCP server and thought that
DNSMASQ might have the same feature.

BR
Florian

On Fri, May 26, 2023 at 12:26 PM Petr Menšík  wrote:

> Added captive-portal DHCP option to database.
>
> But I am afraid dnsmasq can serve different URLs only for explicitly
> registered clients with separate options. It cannot make the url
> dynamically based on incoming request. There is no script able to customize
> offered options online.
> On 5/26/23 09:16, Florian Baaske via Dnsmasq-discuss wrote:
>
> Hi,
> I would like to setup a Guest network with DNSMASQ. For that Guest
> network, I would like to use CAPPORT or RFC8908.
> To make this work, the DHCP server needs to send option 114, which should
> not be a problem, but option 114 should have the URL to the CAPPORT server
> including the MAC address of the client.
> So, my questions would be, is it possible to include the clients MAC
> address in the DHCP response?
> I have found a solution for ISC DHCP but was not able to find anything for
> DNSMASQ. If someone could help, this would be much appreciated.
>
> BR
> Florian
>
> ___
> Dnsmasq-discuss mailing 
> listdnsmasq-disc...@lists.thekelleys.org.ukhttps://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
>
> --
> Petr Menšík
> Software Engineer, RHEL
> Red Hat, https://www.redhat.com/
> PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
>
> ___
> 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

Re: [Dnsmasq-discuss] DNSMASQ DHCP Options for CAPPORT or RFC8908 [PATCH]

[Petr Menšík]

Added captive-portal DHCP option to database.

But I am afraid dnsmasq can serve different URLs only for explicitly 
registered clients with separate options. It cannot make the url 
dynamically based on incoming request. There is no script able to 
customize offered options online.


On 5/26/23 09:16, Florian Baaske via Dnsmasq-discuss wrote:


Hi,
I would like to setup a Guest network with DNSMASQ. For that Guest 
network, I would like to use CAPPORT or RFC8908.
To make this work, the DHCP server needs to send option 114, which 
should not be a problem, but option 114 should have the URL to the 
CAPPORT server including the MAC address of the client.
So, my questions would be, is it possible to include the clients MAC 
address in the DHCP response?
I have found a solution for ISC DHCP but was not able to find anything 
for DNSMASQ. If someone could help, this would be much appreciated.


BR
Florian


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


--
Petr Menšík
Software Engineer, RHEL
Red Hat,https://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
From e0674d8ae1737f00e89bf9fbb87a1369174f5751 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20Men=C5=A1=C3=ADk?= 
Date: Fri, 26 May 2023 11:31:12 +0200
Subject: [PATCH] Add captive-portal DHCP options entry

Defined by RFC 8910 it adds string defining URL with the information
about captive portal.

RA option is not defined.
---
 src/dhcp-common.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/src/dhcp-common.c b/src/dhcp-common.c
index b004e40..c3b978b 100644
--- a/src/dhcp-common.c
+++ b/src/dhcp-common.c
@@ -685,7 +685,8 @@ static const struct opttab_t {
   { "client-machine-id", 97, 0 },
   { "posix-timezone", 100, OT_NAME }, /* RFC 4833, Sec. 2 */
   { "tzdb-timezone", 101, OT_NAME }, /* RFC 4833, Sec. 2 */
-  { "ipv6-only", 108, 4 | OT_DEC },  /* RFC 8925 */ 
+  { "ipv6-only", 108, 4 | OT_DEC },  /* RFC 8925 */
+  { "captive-portal", 114, OT_NAME }, /* RFC 8910 */
   { "subnet-select", 118, OT_INTERNAL },
   { "domain-search", 119, OT_RFC1035_NAME },
   { "sip-server", 120, 0 },
@@ -727,6 +728,7 @@ static const struct opttab_t opttab6[] = {
   { "ntp-server", 56, 0 /* OT_ADDR_LIST | OT_RFC1035_NAME */ },
   { "bootfile-url", 59, OT_NAME },
   { "bootfile-param", 60, OT_CSTRING },
+  { "captive-portal", 103, OT_NAME }, /* RFC 8910 */
   { NULL, 0, 0 }
 };
 #endif
-- 
2.40.1

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

[Dnsmasq-discuss] DNSMASQ DHCP Options for CAPPORT or RFC8908

[Florian Baaske via Dnsmasq-discuss]

Hi,
I would like to setup a Guest network with DNSMASQ. For that Guest network,
I would like to use CAPPORT or RFC8908.
To make this work, the DHCP server needs to send option 114, which should
not be a problem, but option 114 should have the URL to the CAPPORT server
including the MAC address of the client.
So, my questions would be, is it possible to include the clients MAC
address in the DHCP response?
I have found a solution for ISC DHCP but was not able to find anything for
DNSMASQ. If someone could help, this would be much appreciated.

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