✎ soc:2011:pcmattman:journal:week9

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.

====== Week 9 (July 18 to July 24) ======

==== Day 1 (July 18) ====

I mainly used today to do some "maintenance" coding.

The most important fix of the day was to rework NDP Neighbour Advertisement handling to properly parse the option list in the packet, instead of assuming the packet is laid out in a particular way. I also reworked router advertisement handling to use the iobuf manipulation functions (eg, iob_pull) to take data from the iobuf rather than keeping an offset integer around and doing pointer math.

Whilst I was at it, I also added strings to the monojob_wait calls in ip6mgmt.c, so that a user can identify which stage of IPv6-enabling gPXE is at.

Next up - renaming the "ipv6" command to something more useful, and IPv6 extension headers!

==== Day 2 (July 19) ====

Reworked extension header parsing today for receiving IPv6 packets. This will only really be useful for networks that gPXE runs on where extension headers are in use; in all my testing so far I haven't seen any yet.

This is also the key to getting IPv6 fragmentation working, which I will do tomorrow.

==== Day 3 (July 20) ====

Began implementing IPv6 fragmentation. This is relatively simple as it just involves copying IPv4's fragment reassembly code and adjusting it as necessary to handle the unique requirements of IPv6. In particular, we'll need to pass the Next Header.

I've also found that checksum calculation is broken for fragmentation, as the payload length in the psuedo-header is wrong. I'll see what I can do to fix this.

==== Day 4 (July 21) ====

Implemented an alternative method to calculate IPv6 checksums, in addition to the existing method, that takes specific values instead of an iobuf containing an IPv6 packet header. By integrating this with fragment reassembly I have managed to get fragmented packets passed to the correct upper layer protocol, where they pass checksum checks.

This is essentially the last feature that I explicitly labelled on my project plan.

What remains now is:
  * Check endianness across all the code - will there be issues with big-endian systems?
  * I want to check for a valid destination address in ipv6_rx, to avoid all the processing that might take place on a packet that isn't actually targeted to the gPXE host.
  * It may be still necessary to implement the "Authentication" and "Encapsulated Security Payload" headers. I think it might be worth seeing how many people run into this as a problem and work from there.

==== Day 5 (July 22) ====

I didn't manage to get much coding done today, but I did look into the potential endian issues - in particular, looking at code in gPXE and noting the architectures which it supports.

Trace: • week3 • oremanj • week2 • project_plan • packages • notes • errors • project_plan • qemupxeknife • week10 • holger • pxekniferomomatic • journal • derekpryor • alanshieh • nikhilcrao • dverkamp