Differences
This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision | ||
soc:2011:pcmattman:journal:week6 [2011/06/30 05:11] pcmattman day 4 log |
soc:2011:pcmattman:journal:week6 [2011/07/02 22:14] (current) pcmattman day 7 log |
||
---|---|---|---|
Line 20: | Line 20: | ||
Finally figured out how dhcp.c actually transmits DISCOVER packets on the network to kick off the state machine. This is the final piece of the puzzle of understanding the architecture of DHCPv4 in gPXE, which means I can now emulate it in DHCPv6. The RFC has proven to be very straightforward as well and I feel confident about implementing this protocol now. I prefer it over trying to learn a protocol as I'm implementing it, as that often ends up creating code that is truly ugly in the end. Looking back at my first TCP implementation proves this :). | Finally figured out how dhcp.c actually transmits DISCOVER packets on the network to kick off the state machine. This is the final piece of the puzzle of understanding the architecture of DHCPv4 in gPXE, which means I can now emulate it in DHCPv6. The RFC has proven to be very straightforward as well and I feel confident about implementing this protocol now. I prefer it over trying to learn a protocol as I'm implementing it, as that often ends up creating code that is truly ugly in the end. Looking back at my first TCP implementation proves this :). | ||
+ | |||
+ | ==== Day 5 and 6 (July 1, July 2) ==== | ||
+ | |||
+ | I was once again busy with real-world commitments today. I did however manage to do some more reading and I have determined that, architecturally, it would be simpler to implement new support code for IPv6 instead of attempting to copy or modify the existing DHCPv4 implementation. This is because the fundamental protocol is completely different - rather than a new protocol tacked onto BOOTP (DHCPv4), it's been done "right" from the very beginning. Packet manipulation and working with options is not necessarily something that needs a full C file worth of code (dhcppkt.c). | ||
+ | |||
+ | ==== Day 7 (July 3) ==== | ||
+ | |||
+ | Working this weekend on gPXE to make up for lost time. | ||
+ | |||
+ | I managed to finally TX a DHCP6 solicit and get an ADVERTISE response. This is a good start, even if the code to transmit the solicit is totally hacked together. It's much simpler to implement compared to DHCPv4 as well. I don't know if it'll get more complex as I support more options, but I'm happy with progress so far! | ||
+ | |||
+ | I plan on using DHCP6 rapid commits so that on supported DHCP6 servers/configurations we can minimise the DHCP6 network traffic and speed up the boot process. | ||
+ | |||
+ | Experimentation with this has shown that I can actually get DNS nameservers and such without needing to perform a full transaction; I should just be able to send an Information-Request packet and get a response containing the information. This makes sense, because there is no need to "commit" an address to the DHCP6 server. I intend to use this if SLAAC gets a usable globally routable address to try and get IPv6-based nameservers from the network. | ||
+ | |||
+ | I have yet to explore the network boot properties (ie, filenames and servers) of DHCP6. |