|
|
|
|
having something like this in the dhcpd.conf file for DHCPv6:
on commit {
if exists dhcp6.ia-na {
log(debug,
concat( "LEASED,",
"IPTIME,",binary-to-ascii(10, 32, "", substring(option dhcp6.ia-na,36,4)),","
)
);
} }
Will produce a value for IPTIME that is equal to the time requested by the client instead of what was given by the server.
For example:
Client (Redhat Enterprise Linux 7 - ISC DHCP 4.2.5) sends a Renew for an IPv6 address via DHCPv6 requesting the following times (As seen in wireshark capture):
T1: 3600 T2: 5400 Preferred Lifetime: 7200 Valid Lifetime: 7500
Server (generic Linux - ISC DHCP 4.3.3) is configured with this time setting in the pool6 {} statement:
default-lease-time 600;
Server responds with times like this (as seen in wireshark capture):
T1: 0 T2: 0 Preferred Lifetime: 375 Valid Lifetime: 600
What is logged in the log file is 7500 not 600.
The client lease file shows the following times:
Renew: 0 Rebind: 0 Preferred Lifetime: 375 Valid Lifetime: 600
So, it seems that the dhcp options available in on commit {} are what the client sent in instead of those the server sent in response? Is that a bug? Or do I not understand how on commit {} works? I assumed that on commit {} would have access to the options as set by the server that were sent back to the client. _______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
|
I use (IPv6):
log (
info,
concat (
" Lease:", pick-first-value(binary-to-ascii(10, 32, "",
config-option server.default-lease-time), "<none>")
.
.
Bill
On 12/22/2016 10:41 AM, perl-list
wrote:
having something like this in the
dhcpd.conf file for DHCPv6:
on commit {
if exists dhcp6.ia-na {
log(debug,
concat(
"LEASED,",
"IPTIME,",binary-to-ascii(10,
32, "", substring(option dhcp6.ia-na,36,4)),","
)
);
}
}
Will produce a value for IPTIME that
is equal to the time requested by the client instead of
what was given by the server.
For example:
Client (Redhat Enterprise Linux 7 -
ISC DHCP 4.2.5) sends a Renew for an IPv6 address via
DHCPv6 requesting the following times (As seen in
wireshark capture):
T1: 3600
T2: 5400
Preferred Lifetime: 7200
Valid Lifetime: 7500
Server (generic Linux - ISC DHCP
4.3.3) is configured with this time setting in the pool6
{} statement:
default-lease-time
600;
Server
responds with times like this (as seen in wireshark
capture):
T1: 0
T2: 0
Preferred
Lifetime: 375
Valid
Lifetime: 600
What is logged
in the log file is 7500 not 600.
The client
lease file shows the following times:
Renew: 0
Rebind: 0
Preferred
Lifetime: 375
Valid
Lifetime: 600
So, it seems
that the dhcp options available in on commit {} are what the
client sent in instead of those the server sent in response?
Is that a bug? Or do I not understand how on commit {}
works? I assumed that on commit {} would have access to the
options as set by the server that were sent back to the
client.
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
|
Bill,
Thank you for the response.
That wouldn't necessarily give you the actual lease time, however, would it? It seems like it would give you the setting that you have in the pool6 {} statement.
For example, if the client asked for a 3600 second lease but the server was configured for 28800 second lease, the server would give the client the 3600 second lease right? At least that was how it worked in IPv4/DHCPv4. So then you would log that the lease was 28800 when it was actually 3600 yes? Or is the server the absolute authority on lease times in DHCPv6?
From: "Bill Shirley" <[hidden email]>
To: [hidden email]
Sent: Thursday, December 22, 2016 11:42:25 PM
Subject: Re: bug in DHCPv6 option parse for on commit {} ?
I use (IPv6):
log (
info,
concat (
" Lease:", pick-first-value(binary-to-ascii(10, 32, "",
config-option server.default-lease-time), "<none>")
.
.
Bill
On 12/22/2016 10:41 AM, perl-list
wrote:
having something like this in the
dhcpd.conf file for DHCPv6:
on commit {
if exists dhcp6.ia-na {
log(debug,
concat(
"LEASED,",
"IPTIME,",binary-to-ascii(10,
32, "", substring(option dhcp6.ia-na,36,4)),","
)
);
}
}
Will produce a value for IPTIME that
is equal to the time requested by the client instead of
what was given by the server.
For example:
Client (Redhat Enterprise Linux 7 -
ISC DHCP 4.2.5) sends a Renew for an IPv6 address via
DHCPv6 requesting the following times (As seen in
wireshark capture):
T1: 3600
T2: 5400
Preferred Lifetime: 7200
Valid Lifetime: 7500
Server (generic Linux - ISC DHCP
4.3.3) is configured with this time setting in the pool6
{} statement:
default-lease-time
600;
Server
responds with times like this (as seen in wireshark
capture):
T1: 0
T2: 0
Preferred
Lifetime: 375
Valid
Lifetime: 600
What is logged
in the log file is 7500 not 600.
The client
lease file shows the following times:
Renew: 0
Rebind: 0
Preferred
Lifetime: 375
Valid
Lifetime: 600
So, it seems
that the dhcp options available in on commit {} are what the
client sent in instead of those the server sent in response?
Is that a bug? Or do I not understand how on commit {}
works? I assumed that on commit {} would have access to the
options as set by the server that were sent back to the
client.
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
|
I don't know what DHCP sends if you ask for 3600 second lease and
the default is higher.
Wireshark might answer that for you. I haven't messed with DHCPv6
for a while but at some
point I also tried:
# data: leased_lease: not available: ,"
Lease: ",
pick-first-value(binary-to-ascii(10,32,"",encode-int(lease-time,32)),
"<none>")
# ," Lease:", pick-first-value(binary-to-ascii(10,
32, "", config-option dhcp6.clt-time), "<none>")
and commented them out.
Currently there are some DHCPv6 options that don't work as expected.
dhcp6.fqdn is one.
The docs say it works just like fqdn.fqdn
but it throws an error message. I'm thinking
lease-time should work just
like DHCPv4 but I don't think it does.
Bill
On 12/23/2016 8:54 AM, perl-list wrote:
Bill,
Thank you for the response.
That wouldn't necessarily give you the actual lease time,
however, would it? It seems like it would give you the
setting that you have in the pool6 {} statement.
For example, if the client asked for a 3600 second lease
but the server was configured for 28800 second lease, the
server would give the client the 3600 second lease right? At
least that was how it worked in IPv4/DHCPv4. So then you
would log that the lease was 28800 when it was actually 3600
yes? Or is the server the absolute authority on lease times
in DHCPv6?
From: "Bill Shirley"
[hidden email]
To: [hidden email]
Sent: Thursday, December 22, 2016 11:42:25 PM
Subject: Re: bug in DHCPv6 option parse for on
commit {} ?
I use (IPv6):
log (
info,
concat (
" Lease:", pick-first-value(binary-to-ascii(10,
32, "", config-option server.default-lease-time),
"<none>")
.
.
Bill
On 12/22/2016 10:41 AM,
perl-list wrote:
having something like this
in the dhcpd.conf file for DHCPv6:
on commit {
if exists
dhcp6.ia-na {
log(debug,
concat( "LEASED,",
"IPTIME,",binary-to-ascii(10, 32,
"", substring(option dhcp6.ia-na,36,4)),","
)
);
}
}
Will produce a value for
IPTIME that is equal to the time requested by
the client instead of what was given by the
server.
For example:
Client (Redhat Enterprise
Linux 7 - ISC DHCP 4.2.5) sends a Renew for an
IPv6 address via DHCPv6 requesting the following
times (As seen in wireshark capture):
T1: 3600
T2: 5400
Preferred Lifetime: 7200
Valid Lifetime: 7500
Server (generic Linux -
ISC DHCP 4.3.3) is configured with this time
setting in the pool6 {} statement:
default-lease-time 600;
Server responds with times like this (as
seen in wireshark capture):
T1: 0
T2: 0
Preferred Lifetime: 375
Valid Lifetime: 600
What is logged in the log file is 7500 not
600.
The client lease file shows the following
times:
Renew: 0
Rebind: 0
Preferred Lifetime: 375
Valid Lifetime: 600
So, it seems that the dhcp options
available in on commit {} are what the client sent
in instead of those the server sent in response?
Is that a bug? Or do I not understand how on
commit {} works? I assumed that on commit {}
would have access to the options as set by the
server that were sent back to the client.
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
|
perl-list < [hidden email]> wrote:
> For example, if the client asked for a 3600 second lease but the server was configured for 28800 second lease, the server would give the client the 3600 second lease right? At least that was how it worked in IPv4/DHCPv4.
There are THREE options you can set (in teh DHCPv4 server at least) - MIN, MAX, and DEFAULT lease times.
The default lease time is the time that's given if the client doesn't ask for something different.
Min and max set the lower and upper bounds on the lease time that's given out.
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
|
I've been thinking about this. There are actually 4 settings in DHCPv6:
#min-lease-time 600; #preferred-lifetime 600; default-lease-time 600; #max-lease-time 600;
I presently have the other three commented out. So, it SHOULD be giving the client the 4500 second lease time that was included in the ia-na from the client. Instead, it is sending back 600. The client is setting 600 second lease as well. So there might be two bugs here or they might be related somehow. Should I submit this as a bug report?
From: "Simon Hobson" <[hidden email]>
To: "Users of ISC DHCP" <[hidden email]>
Sent: Saturday, December 24, 2016 4:06:04 PM
Subject: Re: bug in DHCPv6 option parse for on commit {} ?
perl-list <[hidden email]> wrote:
> For example, if the client asked for a 3600 second lease but the server was configured for 28800 second lease, the server would give the client the 3600 second lease right? At least that was how it worked in IPv4/DHCPv4.
There are THREE options you can set (in teh DHCPv4 server at least) - MIN, MAX, and DEFAULT lease times.
The default lease time is the time that's given if the client doesn't ask for something different.
Min and max set the lower and upper bounds on the lease time that's given out.
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
|
I'll go ahead and report this as a bug.
From: "Darren Ankney" <[hidden email]>
To: "Users of ISC DHCP" <[hidden email]>
Sent: Friday, December 30, 2016 8:17:51 AM
Subject: Re: bug in DHCPv6 option parse for on commit {} ?
I've been thinking about this. There are actually 4 settings in DHCPv6: #min-lease-time 600; #preferred-lifetime 600; default-lease-time 600; #max-lease-time 600;
I presently have the other three commented out. So, it SHOULD be giving the client the 4500 second lease time that was included in the ia-na from the client. Instead, it is sending back 600. The client is setting 600 second lease as well. So there might be two bugs here or they might be related somehow. Should I submit this as a bug report?
From: "Simon Hobson" <[hidden email]>
To: "Users of ISC DHCP" <[hidden email]>
Sent: Saturday, December 24, 2016 4:06:04 PM
Subject: Re: bug in DHCPv6 option parse for on commit {} ?
perl-list <[hidden email]> wrote:
> For example, if the client asked for a 3600 second lease but the server was configured for 28800 second lease, the server would give the client the 3600 second lease right? At least that was how it worked in IPv4/DHCPv4.
There are THREE options you can set (in teh DHCPv4 server at least) - MIN, MAX, and DEFAULT lease times.
The default lease time is the time that's given if the client doesn't ask for something different.
Min and max set the lower and upper bounds on the lease time that's given out.
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
Locked
