Send kea-dev mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.isc.org/mailman/listinfo/kea-dev
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of kea-dev digest..."
Today's Topics:
1. Re: Requirements for the Logging and Diagnostics in Kea
(Marcin Siodelski)
2. RSOO bug in 0.9.1 (Templin, Fred L)
----------------------------------------------------------------------
Message: 1
Date: Fri, 10 Apr 2015 19:15:18 +0200
From: Marcin Siodelski <[email protected]>
To: Shawn Routhier <[email protected]>
Cc: [email protected]
Subject: Re: [kea-dev] Requirements for the Logging and Diagnostics in
Kea
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
On 09.04.2015 18:27, Shawn Routhier wrote:
>
>> On Apr 9, 2015, at 9:09 AM, Marcin Siodelski <[email protected]> wrote:
>>
>>
>>
>> On 09.04.2015 13:16, Stephen Morris wrote:
>>>
>
> <snip>
>
>>
>>> 4) I suggest that we include requirements to dump the contents of
>>> incoming and outgoing packets (if requested) to a file in binary format.
>>> This will be outside the normal logging mechanism, but a packet trace
>>> could be useful in some diagnoses.
>>>
>>
>> I agree that this is a useful one. But, do we really want to include it for
>> 0.9.2 as a requirement? Perhaps tag it as SHOULD, rather than MUST, and
>> treat it as a stretch goal?
>>
>> Marcin
>> _______________________________________________
>> kea-dev mailing list
>> [email protected]
>> https://lists.isc.org/mailman/listinfo/kea-dev
>
> One other item we may want to consider is an actual trace option in the code.
> In ISC DHCP we have an option to have the server save all the input and output
> information in a binary file. This allows a user to send us a trace file
> that we
> can replay on a system that is similar to the users. This can be quite
> useful to
> see what is happening but it does require a fair amount of work to figure out
> what all the inputs and outputs are and to save them as appropriate.
>
I have moved the ticket #3788 to review. I think that the document
sufficiently addresses the comments that I had received from Stephen and
Tomek. There is a valid point about the possible performance
implications but since the requirements for logging performance are
rather vague right now, it is probably good to keep in mind the comments
but I don't see anything I could add to the doc in that respect.
There is a discussion we're having with Shawn right now. I am not
certain if there is anything more that I should include as a result of
this discussion?
If there is something that must be fixed in this document in your
opinion, please state so. If there is nothing glaring, I'd want to
finalize it on Monday and close the ticket.
Marcin
------------------------------
Message: 2
Date: Fri, 10 Apr 2015 22:44:42 +0000
From: "Templin, Fred L" <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [kea-dev] RSOO bug in 0.9.1
Message-ID:
<2134f8430051b64f815c691a62d9831832e44...@xch-blv-504.nw.nos.boeing.com>
Content-Type: text/plain; charset="us-ascii"
Hello,
I am trying to use the new RFC6422 Relay Supplied Options Option (RSOO)
facility.
My RFC6221 relay inserts a Vendor-Specific Information Option (option #17) in
the
Relay-forward message that will be sent to the kea server. The option has length
26 decimal. But, when the kea server does the RFC6422 transformation it
truncates
the VSIO to only include the option header and the 4-byte enterprise number. The
VSIO is then inserted into the DHCPv6 Reply message, but loses the 22 bytes that
follow the enterprise number.
See attached for the kea log. It does not show anything about the Relay-forward
or Relay-reply messages, but does show how the server inserts the VSIO with
length 4. Please let me know if any further information is needed.
Fred Templin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kea-debug.log
Type: application/octet-stream
Size: 23730 bytes
Desc: kea-debug.log
URL:
<https://lists.isc.org/pipermail/kea-dev/attachments/20150410/81b1582b/attachment.obj>
------------------------------
_______________________________________________
kea-dev mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/kea-dev
End of kea-dev Digest, Vol 13, Issue 6
**************************************
