YazDHCP - alpha - Extended DHCP management script

[SomeWhereOverTheRainBow]

how many characters do your hostnames and staticlist take up?

currently 5130 but i don't have all devices listed in dhcp. I would like to at some point because I use a traffic monitor that works better with static ip and hostnames defined.

 

[JGrana]

I would love to test your script but I stopped using nvram for DHCP assignments years ago.
What is in the optionslist file? I presently just have hosts.add and dnsmasq.conf.add.
I do like your idea about having the list in a separate file read by dnsmasq.conf
As far as non-HND - hopefully by next week ;-)

 

[Jack Yaz]

As far as non-HND - hopefully by next week ;-)

indeed!

I would love to test your script but I stopped using nvram for DHCP assignments years ago.
What is in the optionslist file? I presently just have hosts.add and dnsmasq.conf.add.

options file is for if you specify a DNS server for a given host

 

[Jack Yaz]

I would love to test your script but I stopped using nvram for DHCP assignments years ago.
What is in the optionslist file? I presently just have hosts.add and dnsmasq.conf.add.
I do like your idea about having the list in a separate file read by dnsmasq.conf
As far as non-HND - hopefully by next week ;-)

You could always migrate your config into YazDHCP and then you get GUI editing back? Assuming you're not using over 6500 characters in what is/was the nvram format:

<MAC>IP>HOSTNAME>DNS>

Per host. If no DNS specified (i.e. "Default"), each host becomes

<MAC>IP>HOSTNAME>

 

[SomeWhereOverTheRainBow]

 

[dave14305]

Since you’re potentially using up to 6500 bytes of the custom_settings limit of 8192, it would be a good idea to check the total length of the stringified custom_settings before submitting. Otherwise, bytes past 8192 may be lost, either from YazDHCP or other addons.

I did something similar in FlexQoS. I should probably rewrite so I only call .stringify once.

if (JSON.stringify(custom_settings).length < 8192) {
    document.getElementById('amng_custom').value = JSON.stringify(custom_settings);
    document.form.action_script.value = "restart_qos";
    document.form.submit();
}
else
    alert("Settings for all addons exceeds 8K limit! Cannot save!");
}

 

[Jack Yaz]

Since you’re potentially using up to 6500 bytes of the custom_settings limit of 8192, it would be a good idea to check the total length of the stringified custom_settings before submitting. Otherwise, bytes past 8192 may be lost, either from YazDHCP or other addons.

I did something similar in FlexQoS. I should probably rewrite so I only call .stringify once.

if (JSON.stringify(custom_settings).length < 8192) {
    document.getElementById('amng_custom').value = JSON.stringify(custom_settings);
    document.form.action_script.value = "restart_qos";
    document.form.submit();
}
else
    alert("Settings for all addons exceeds 8K limit! Cannot save!");
}

you could test after assigning it to amng_custom, something like.

document.getElementById('amng_custom').value = JSON.stringify(custom_settings);
if (document.getElementById('amng_custom').value > 8192) {
    alert("Settings for all addons exceeds 8K limit! Cannot save!");
    return false;
}

 

[dave14305]

you could test after assigning it to amng_custom, something like.

document.getElementById('amng_custom').value = JSON.stringify(custom_settings);
if (document.getElementById('amng_custom').value > 8192) {
    alert("Settings for all addons exceeds 8K limit! Cannot save!");
    return false;
}

Yes, but using .length instead of .value.

 

[Jack Yaz]

Yes, but using .length instead of .value.

hurriedly copy/pasting while cooking dinner, oops!

 

[L&LD]

Above: two giants (among many), script authors discussing technical script details of how stuff should work.

L&LD: What's for dinner!



Thank you, gentlemen! All of you. What would the rest of us do here without you!

 

[heysoundude]

Thank you, gentlemen! All of you. What would the rest of us do here without you!

Agreed! thumbs up. This Is The Way.

 

[Swinson]

Above: two giants (among many), script authors discussing technical script details of how stuff should work.

L&LD: What's for dinner!



Thank you, gentlemen! All of you. What would the rest of us do here without you!

Haha

No What you want is this (sizeof(x.value.length) * 2) to get the value in nibbles

But really fantastic work. I’ve had the script installed for a few days now and so far nothing has broken that I’ve noticed. Thanks for all your hard work.

 

[Jack Yaz]

Haha

No What you want is this (sizeof(x.value.length) * 2) to get the value in nibbles

But really fantastic work. I’ve had the script installed for a few days now and so far nothing has broken that I’ve noticed. Thanks for all your hard work.

haha! and that's what i like to hear
overall there isn't much "wow" factor to it since it's under the hood changes.
if i get bored i'll add a new section for hostname editing separate to DHCP

 

[L&LD]

Haha

No What you want is this (sizeof(x.value.length) * 2) to get the value in nibbles

But really fantastic work. I’ve had the script installed for a few days now and so far nothing has broken that I’ve noticed. Thanks for all your hard work.

When I entered that in PuTTY at the router's prompt, it also suggested 1KG of Spaghetti! These are some mad voodoo coding skills our members have here!

 

[Swinson]

When I entered that in PuTTY at the router's prompt, it also suggested 1KG of Spaghetti! These are some mad voodoo coding skills our members have here!

lol I’m pretty sure if that was made syntactically correct you would get like sizeof(long int) assuming length would return something of type int but nonsense code is fun.
But do be careful with length members they sometimes don’t count control characters like the null string termination character so strlen(x) might return 10 but you are really using 11 bytes including the null char

 

[L&LD]

L&LD: ducks (just barely) as code and understanding flies past at warp speed over his head.

With a straight face: @Swinson, thanks! I'll keep that in mind for my next coding session.

(L&LD changes his avatar to 'almost a coder', soon).

 

[elorimer]

A suggestion. It might help along the way if you corrected the mistranslation on the page of "around the DHCP list" to "within the DHCP scope". https://www.snbforums.com/threads/a...p-static-list-after-reboots.64884/post-597191

Or better: "to be supplied by the DHCP server".

 

[heysoundude]

L&LD: ducks (just barely) as code and understanding flies past at warp speed over his head.

In opposite directions, no less! which shiny thing to pay attention to first before they both disappear? <lol>

 

[elorimer]

Or better: "to be supplied by the DHCP server".

I see the change to " Manually Assigned IP addresses in the DHCP IP Pool " Here's the thing, if I understand it correctly.

If the DHCP pool starts at, say 100 and ends at 200, the server will hand out on request an address it picks in that range. If you have a manually assigned address in that range, it won't hand that address out to anything else. I think we generally use "pool" and "range" with the same meaning, don't we?

You can also give a device a static address without a request to the DHCP server, in which case, if the static address is in the range, you run the risk of it being handed out by the DHCP to a different device. That's why it is thought to be good practice to only do static assignments outside the DHCP pool.

You can, however, manually assign an address that is not in that range (but I think must be in the same subnet as the router, at the very least so that it works). If a device makes a DHCP request of the DHCP server and the MAC matches, it will give it that address, even though it isn't in the range. While it always gets the same address, the address is not a "static" address but a "manually assigned" address. As an alternative, one can manually assign any static address within the DHCP server (even if it isn't in the range and even if it will never be requested by the static device) so it isn't handed out to any other device. I think this is good also, because one can then use the page to keep track of all the addresses (including manual and static) and assign hostnames and icons to them.

So my point is that manually assigned addresses don't need to be in the DHCP pool, as they can also be outside the pool. The mistranslation of "around the pool" led noobs like me to think a manually assigned address had to be outside the pool.

I set this out so folks can correct me. Maybe it should be just "Reserved addresses" and leave it at that.

Also, I think the FAQ link should be https://www.asus.com/support/FAQ/1000906, not that it is much help.

 

[Jack Yaz]

I see the change to " Manually Assigned IP addresses in the DHCP IP Pool " Here's the thing, if I understand it correctly.

If the DHCP pool starts at, say 100 and ends at 200, the server will hand out on request an address it picks in that range. If you have a manually assigned address in that range, it won't hand that address out to anything else. I think we generally use "pool" and "range" with the same meaning, don't we?

You can also give a device a static address without a request to the DHCP server, in which case, if the static address is in the range, you run the risk of it being handed out by the DHCP to a different device. That's why it is thought to be good practice to only do static assignments outside the DHCP pool.

You can, however, manually assign an address that is not in that range (but I think must be in the same subnet as the router, at the very least so that it works). If a device makes a DHCP request of the DHCP server and the MAC matches, it will give it that address, even though it isn't in the range. While it always gets the same address, the address is not a "static" address but a "manually assigned" address. As an alternative, one can manually assign any static address within the DHCP server (even if it isn't in the range and even if it will never be requested by the static device) so it isn't handed out to any other device. I think this is good also, because one can then use the page to keep track of all the addresses (including manual and static) and assign hostnames and icons to them.

So my point is that manually assigned addresses don't need to be in the DHCP pool, as they can also be outside the pool. The mistranslation of "around the pool" led noobs like me to think a manually assigned address had to be outside the pool.

I set this out so folks can correct me. Maybe it should be just "Reserved addresses" and leave it at that.

Also, I think the FAQ link should be https://www.asus.com/support/FAQ/1000906, not that it is much help.

while you can assign an IP outside the pool, strictly speaking, you shouldn't. at least, that's my understanding. you're effectively reserving a DHCP address for a client