No support for classless static route options about staticdhcpd

[GoogleCodeExporter]

I was able to achieve this just by hardcoding things, so this is would just be 
a handy feature to have.  I used:

    packet.setOption('classless_static_route',
        [0] + packet.getOption("router")
        + [16, 169, 254, 0, 0, 0, 0]
    )

Original comment by [email protected] on 12 Sep 2014 at 8:02

[GoogleCodeExporter]

Thanks for reporting yet another thing!

Gmail flagged this as spam, so it went unnoticed (sorry!), but I'll reflect on 
this and get an implementation in place as soon as I've got time to go over the 
code.

-Neil

Original comment by red.hamsterx on 22 Sep 2014 at 6:00

[GoogleCodeExporter]

Yeah, this definitely seems like it could be useful.

Allowing people to hack things is why it's classified as BYTE_PLUS (one or more 
bytes, unchecked), but I'll build an RFC handler for it and get that updated.

Original comment by red.hamsterx on 9 Oct 2014 at 1:17

• Changed state: Accepted

[GoogleCodeExporter]

I'm afraid that, while the RFC seems to make sense and the encoding seems 
simple enough, I'm having trouble mapping it to the example you provided.

I get that 169.254.0.0/16 should go out over the default gateway, but the 
leading '0' seems redundant, and I'm not sure what 'router' value would satisfy 
the encoding. (Unless the leading '0' was actually a '32' or something)


It's a good opportunity to add CIDR evaluation to the IPv4 type either way, 
though, even if I don't integrate that into anything beyond this feature at 
this point. I should have time to tack it, hopefully, on Friday.

Original comment by red.hamsterx on 9 Oct 2014 at 1:32

[GoogleCodeExporter]

The leading 0 there indicates it's the default route.  Basically, that 
translates to '0.0.0.0/0', which would match any IP address.

Since routing is usually done by the most exact match (I think there's a better 
description here, but I can't recall it right now), it has the effect of 
sending all the 169.254.0.0/16 packets out the network interface, but routing 
everything else to the default router.

Original comment by [email protected] on 9 Oct 2014 at 1:35

[GoogleCodeExporter]

Oh, yes, that makes sense: you have two route definitions there.

Thanks for clarifying it!

Original comment by red.hamsterx on 9 Oct 2014 at 2:40

[GoogleCodeExporter]

r786 has an rfc3442_121 type that handles this with clearer-looking syntax.

Like the other RFC types, though, setting bytes directly bypasses the 
validation mechanisms, so the code you've implemented should continue to work 
without modification.

Original comment by red.hamsterx on 21 Mar 2015 at 5:25

• Changed state: Started