✎ soc:2011:pcmattman:journal:week8

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== Week 8 (July 11 to July 17) ======

==== Day 1 (July 11) ====

I began reworking the DHCPv6 code today to implement the necessary infrastructure for passing through the state machine. This will be quite similar to DHCPv4's state machine, with generic functions containing logic for transmission and receive that is the same across all states.

As part of these changes, I removed a lot of old testing solicit code and re-implemented it into the new infrastructure. This has worked well, with the DHCPv6 server sending ADVERTISE packets in response to the SOLICIT packet. I just have to set the right options to request an address (an IA_{NA|TA} option, for example).

At some point I will also need to modify the "settings" (gpxe/settings.h) code in gPXE to handle IPv6 addresses as well as IPv4 addresses. This will be useful for setting DNS nameservers and such, and I think I may also need to bring some of the settings changes into my stateless autoconfiguration code so that the IPv6 address of the network device is accessible.

I am now on a part time contract, so I have a bit more time in the day to work on gPXE code.

==== Day 2 (July 12) ====

I spent a fair bit of time today reading the RFCs for DHCPv6, trying to wrap my head around temporary and non-temporary addresses, and the IA_TA/IA_NA options in DHCPv6. This understanding is critical to being able to implement these features in gPXE properly.

I also implemented more of the SOLICIT state handling today. I can now send a request for an address, with the rapid commit option, and get an immediate reply from the DHCPv6 server. I managed to implement handling of this reply (generically, so there is no code duplication for a 4-way handshake transaction) but without the gpxe/settings.h changes I mentioned in yesterday's entry, I'm a bit stuck. So I'll be adding a few TODO comments in the code, and then continuing to implement the rest of the state machine. This way I can test each aspect of the DHCPv6 code and then sort out the settings changes later.

At some point I also need to install the ISC dhcpd, so I can test my DHCPv6 code with more than one server. At the moment I'm using WIDE's DHCPv6 server, which should work fine for this initial implementation phase.

==== Day 3 (July 13) ====

I managed to clean up some of the DHCPv6 option handling this evening, which makes reading through the code a bit nicer. This also came as a result of wanting to separate traversing the option list from actually using data in those options - another readability thing.

I'm fairly happy with how DHCPv6 is at with respect to rapid commits. It easily handles a transaction with a rapid commit and can get to the stage where I would set IP addresses and nameservers quite quickly. Tonight, though, I worked on the 4-way handshake (SOLICIT, ADVERTISE, REQUEST, REPLY). This has gone very well, with the code in place to send a REQUEST in response to an ADVERTISE - which means I'm now at the same stage here as with rapid commits (needing to set IP addresses and such). I do need to write a lot more code for the REPLY and ADVERTISE handling however - we need to confirm the response is actually for our own client ID, and that the server does not change between an advertisement and a reply. But everything is in place now to make that work.

Still haven't really looked into the gpxe/settings.h changes yet. Once DHCPv6 is cleaned up a bit and slightly more spec-friendly, I might have a look at this.
Trace: • week9 • week6 • week6 • week8 • week10 • week10 • dverkamp • week9 • week9 • week12 • week12
Navigation

Search

Toolbox

QR Code
