tlvparse() Doesn't Account for Vendor-specific Options

[psychomario]

Vendor specific options can be nested.

See line 208 of dhcpd.py for an example.

[mmattioli]

To clarify, are you saying that the current implementation of tlvparse() in dhcpd.py supports only non-nested vendor-specific options and if they become nested then that's an issue?

[psychomario]

The current implementation of tlvparse only supports non-nested options. If a vendor specific option is there, I know we send them and I believe we receive some too, then the whole vendor specific region will be stored as a binary chunk in the options dict.

This isn't a issue as such, but nesting would remove the opacity of dhcpd L208, which is a nested vendor specific option.

[mmattioli]

Understood, just wasn't sure if it was more of a bug or an enhancement (like you have labeled). This is interesting...

[psychomario]

It would be nice to have, but it's not necessary, and may increase both the encode and decode function complexity when a simple comment by L208 would suffice.

[icb-]

Which options would we recur into? iPXE uses option 175 for vendor-specific options, and encodes it using the same TLV format, so we could easily call the same tlvparse on it. Options 43 and 60 are encoded slightly differently per RFC2132 §8.4 and §9.13.

[psychomario]

I know that we're using 43, and that acts identically to just nested values. I think 60 is the one separated by colons, so is treated differently, and I've not come across 175

[icb-]

RFC2132 says option 43 SHOULD be encoded as specified in §8.4 (essentially the same as the enclosing options), but there's no guarantee by the RFC that is will be. If we inspect option 60 first, we may be able to safely parse option 43 if it's a vendor extension we know about.

Option 175 is sent by iPXE to signal what features it was built with (e.g. whether it supports HTTP, or just tftp) and can be used to signal things like whether to wait for a Proxy DHCP reply. If you turn on DHCP debugging, you'll see a dict printed out of the parsed options. If the request was from iPXE, you'll see option 175 included. You can call the same tlvparse on the string from that.

For example, I get this when I dhcp my VirtualBox VM

{50: ['\xc0\xa8\x02d'],
 53: ['\x03'],
 54: ['\xc0\xa8\x02\x02'],
 55: ['\x01\x03\x06\x07\x0c\x0f\x11+<BCw\x80\x81\x82\x83\x84\x85\x86\x87\xaf\xcb'],
 57: ['\x05\xc0'],
 60: ['PXEClient:Arch:00000:UNDI:002001'],
 61: ["\x01\x08\x00'>\xd2\xd8"],
 77: ['iPXE'],
 93: ['\x00\x00'],
 94: ['\x01\x02\x01'],
 97: ['\x00\xf2=\xb8\xbf\xcaq\x91N\x8f\x06\x90\xa0\x1c\x9f\x93\x87'],
 175: ['\xb1\x05\x01\x80\x86\x10\x0e\xeb\x03\x01\x00\x00\x18\x01\x01"\x01\x01\x19\x01\x01!\x01\x01\x10\x01\x02\x13\x01\x01\x11\x01\x01\x17\x01\x01\x15\x01\x01\'\x01\x01\x12\x01\x01\x1b\x01\x01']}

Further parsing option 175 gives:

{16: ['\x02'],
 17: ['\x01'],
 18: ['\x01'],
 19: ['\x01'],
 21: ['\x01'],
 23: ['\x01'],
 24: ['\x01'],
 25: ['\x01'],
 27: ['\x01'],
 33: ['\x01'],
 34: ['\x01'],
 39: ['\x01'],
 177: ['\x01\x80\x86\x10\x0e'],
 235: ['\x01\x00\x00']}

[psychomario]

Wouldn't we need some big lookup table for known extensions we can parse?
I'm starting to think I cut way too many corners during my initial implementation.

[mmattioli]

@psychomario I think it depends on how complex we really want PyPXE to be. As of right now, I haven't played around with iPXE too much but TFTP, DHCP, and HTTP work pretty well (aside from the TFTP file size issue noted in #35).

I think we need to figure out where we draw the line between 'lightweight/easy to use' and 'reinventing the wheel'. A little polishing here and there and we have a fantastic product. Once we start going down the path of implementing some complex features I feel like we're setting ourselves up for trouble. This is a lot of development for a DHCP server that, in most cases, is a convenience feature. I'm not trying to minimize it's use or importance (I think it's awesome) but I think we need to keep ourselves grounded and remember that 'reinventing the wheel' isn't always a good idea.

Don't get me wrong, it's not that I'm up for the challenge or anything like that but I just feel like all of that development/time/effort will be underappreciated and only complicate the the simplicity of PyPXE.

[psychomario]

My initial idea for the project was to reinvent the wheel somewhat. I didn't like the generally-done way of PXE booting with ISC dhcpd and tftpd-hpa becuase of the config files and relevant paths all over the place. This project was meant to integrate everything together and have everything in one place. The lightweight aspect was purely a coincidence.

I never really expected the project to be used for proper cases, just playing around really and learning protocols/programming.

I'd planned on looking into adding an NFS module after my holiday to complete the package.

[numbnuts]

now that you mention it, I recall reading NFS being a solution for fixing
the squashfs load problem. I didn't have time, at the time, to get involved
in working that out, which is why I never got it sorted...

On Sun, Jul 13, 2014 at 8:13 AM, psychomario notifications@github.com
wrote:

My initial idea for the project was to reinvent the wheel somewhat. I
didn't like the generally-done way of PXE booting with ISC dhcpd and
tftpd-hpa becuase of the config files and relevant paths all over the
place. This project was meant to integrate everything together and have
everything in one place. The lightweight aspect was purely a coincidence.

I never really expected the project to be used for proper cases, just
playing around really and learning protocols/programming.

I'd planned on looking into adding an NFS module after my holiday to
complete the package.

—
Reply to this email directly or view it on GitHub
#33 (comment).

[psychomario]

It won't fix it as such, it just uses a different method for the rootfs, so it works around the problem.

[mmattioli]

@psychomario while I think playing around and learning is a great use for this project, I do think it has the potential to be a rock-solid yet lightweight solution for PXE that can be widely used. That's why I feel like the less wheel reinventing we do and the more we focus on shipping something that's reliable and lightweight the better.

Again, I'm not against wheel reinventing but just feel that stuff that's really out there (like the nested options and lookup table) should maybe be things we work on in a 'dev' or 'unstable' branch. Things, like NFS, that do require a certain level of re-engineering I agree with but not to the point where we go deeper than we really have to.

Apologies if I'm coming off as stubborn, I just want to make sure you understand where I'm coming from and my reasoning.

[psychomario]

Just to clarify, do you think NFS is a good idea to implement, or is that a little too much?

I fully agree with your stance. I think it would be great if we became the go-to project for all PXE booting needs, but youre right, we will need to be rock solid for that.