Opened 5 years ago

Closed 5 years ago

#3659 closed defect (fixed)

Malformed packets returned by Kea (involving option 81)

Reported by: nicolas.chaigneau Owned by: tomek
Priority: medium Milestone: Kea0.9.1
Component: Unclassified Version: git
Keywords: Cc:
CVSS Scoring: Parent Tickets:
Sensitive: no Defect Severity: N/A
Sub-Project: DHCP Feature Depending on Ticket:
Estimated Difficulty: 0 Add Hours to Ticket: 0
Total Hours: 0 Internal?: no

Description

I've found other cases in which I have a "malformed packet" (as displayed by Wireshark).
This can happen in ACK or NACK replies.

It occurred on the following attributes:
Option 50 (Requested IP address): 0x 32 01 1f
Option 51 (IP Address lease time): 0x 33 01 20 (the packet actually contains two options 51, the first one is correct).
Option 49 (X Window System Display Manager): 0x 31 01 1e
Option 48, 45... etc.
(there may be more, I didn't check all packets yet, but possibly they are all related).

Each time, the badly encoded "option" appears after option 81 (Client Fully Qualified Domain Name).

There is also an option 81 in packet, but with a different value.
In the response it seems a string is appended (always the same: ".example.com.R"), I don't know where that comes from.

For example:

  • Received packet contains:

Option 81

Length: 15
Flags: 0x00
A-RR result: 0
PTR-RR result: 0
Client name: PC-de-AADENA

  • And (malformed) response packet contains:

Option 81

Length: 29
Flags: 0x08
A-RR result: 0
PTR-RR result: 0
Client name: PC-de-AADENA.example.com.R

And immediately following, we have "0x 32 01 1f" which is interpreted as option 50 (Requested IP Address), with length = 1, value = 1f.

Subtickets

Attachments (2)

trace-20141219-extr1_0xe6d0fd22.pcap (847 bytes) - added by nicolas.chaigneau 5 years ago.
trace-20141219-extr8_0x4b536d72.pcap (1.6 KB) - added by nicolas.chaigneau 5 years ago.

Download all attachments as: .zip

Change History (12)

Changed 5 years ago by nicolas.chaigneau

Changed 5 years ago by nicolas.chaigneau

comment:1 Changed 5 years ago by marcin

The part of the problem seems to be the issue raised in the http://kea.isc.org/ticket/3624 which caused in valid calculation of the Client FQDN option. This ticket has been resolved and the fix is available on the master branch in Kea repo.

Can you please use the latest version of Kea from the git repo and verify if the problem persists?

comment:2 follow-up: Changed 5 years ago by nicolas.chaigneau

Alright, I've tested with latest version from GitHub.
There is no malformed packet anymore.

But there still is something odd: in the response, the Client FQDN is appended with the string ".example.com.".

There is no "example.com", neither in the request nor anywhere in my configuration.

comment:3 in reply to: ↑ 2 Changed 5 years ago by marcin

Replying to nicolas.chaigneau:

Alright, I've tested with latest version from GitHub.
There is no malformed packet anymore.

But there still is something odd: in the response, the Client FQDN is appended with the string ".example.com.".

There is no "example.com", neither in the request nor anywhere in my configuration.

Please see this ticket http://kea.isc.org/ticket/3632

The qualifying_suffix parameter defaults to "example.com." if it is not specified. If you want to not append the default value you should explicitly set qualifying_suffix to an empty value.

See http://kea.isc.org/docs/kea-guide.html#dhcp4-ddns-config for details on use of the qualifying_suffix parameter.

comment:4 Changed 5 years ago by nicolas.chaigneau

Thank you Marcin.

So I've configured: "qualifying-suffix": "".
There still is a dot appended. I don't really care though, since I'm not handling DDNS.

That said, I think it would be better to have qualifying-suffix default value set to "" instead of "example.com" (as proposed in ticket #3632). Currently there is a set of configuration items that are entirely optional (and of which I was unaware), but still have an influence on how the server will respond to clients.

Last edited 5 years ago by nicolas.chaigneau (previous) (diff)

comment:5 Changed 5 years ago by tomek

  • Milestone changed from Kea-proposed to Kea0.9.1

As discussed on 2015-01-07 meeting, we'll move this to 0.9.1, but that's mostly for bookkeeping purposes. This issue will be addressed completely with #3632, so we'll close this ticket once #3632 is done.

comment:6 Changed 5 years ago by fdupont

#3632 under review.

comment:7 Changed 5 years ago by fdupont

  • Milestone changed from Kea0.9.1beta to Kea0.9.1

The code part of #3632 was accepted. Should we ask for a test of this when it will be merged or can we close the ticket?

comment:8 Changed 5 years ago by fdupont

  • Owner set to tomek
  • Status changed from new to reviewing

#3632 was committed, choices are:

  • close this ticket.
  • ask the reporter to check if his concern was fixed.
  • add a new test from this report.

(I am in favour of the first option).

comment:9 Changed 5 years ago by nicolas.chaigneau

As far as I'm concerned, you can close the ticket. I will test this again anyway (but probably not before 0.9.1 beta), if I see anything wrong I'll let you know.
Thanks.

comment:10 Changed 5 years ago by fdupont

  • Resolution set to fixed
  • Status changed from reviewing to closed

Closing per customer.

Note: See TracTickets for help on using tickets.