Custom names list

[maghuro]

I posted this inside the 388.2 thread, but I'll post it in a new thread to bring the attention needed.

The NVRAM var "custom_clientlist" gets bugged after a reboot.



The correct syntax is:

custom_clientlist=<NAME>MA:CA:DD:RE:SS>0>0>>>><NAME2>MA:CA:DD:RE:SS>0>0>>>>

And whenever I reboot the router, the first entry (only the first one) is saved without the opening "<":

custom_clientlist=NAME>MA:CA:DD:RE:SS>0>0>>>><NAME2>MA:CA:DD:RE:SS>0>0>>>>

The Asus router deals correctly with it, displaying that device name correctly.

However, some third party services like NextDNS, which rely on the correct syntax, don't process correctly the custom names and doesn't show them in their page, because of that bug.



The solution is change one device NAME to another one, and then change it back.

But after a reboot, that var trims again the first <

I'm using a GT-AX6000. Happens on both regular and rog firmware.

Anyone facing the same issue?
Thanks.

 

[ColinTaylor]

I've noticed this with various nvram variables since the 2021 386.x releases. I don't think of this as a bug particularly because the firmware itself seems to cope with both formats.

 

[maghuro]

I've noticed this with various nvram variables since the 2021 386.x releases. I don't think of this as a bug particularly because the firmware itself seems to cope with both formats.

It worked well on my ol' Rt-ac86u, never noticed that trimm. And NextDNS always worked correctly

 

[Jonnny]

Here also appears this "bug". I always come across when exporting/importing my device list. But the truth is that it works even if the "<" disappears at the beginning...

 

[maghuro]

Here also appears this "bug". I always come across when exporting/importing my device list. But the truth is that it works even if the "<" disappears at the beginning...

Except for third-party services that rely on that specific syntax

 

[maghuro]

Just submited a PR on NextDNS Github to bypass this "feature"

Fix missing '<' on custom_clientlist by maghuro · Pull Request #843 · nextdns/nextdns

On new firmwares, after reboot, the '<' char in the beginning of the string is removed (not a bug?). This fix attemps to add it if non present. This fixes #839

github.com

 

[Martinski]

I posted this inside the 388.2 thread, but I'll post it in a new thread to bring the attention needed.

The NVRAM var "custom_clientlist" gets bugged after a reboot.

The correct syntax is:

custom_clientlist=<NAME>MA:CA:DD:RE:SS>0>0>>>><NAME2>MA:CA:DD:RE:SS>0>0>>>>

And whenever I reboot the router, the first entry (only the first one) is saved without the opening "<":

custom_clientlist=NAME>MA:CA:DD:RE:SS>0>0>>>><NAME2>MA:CA:DD:RE:SS>0>0>>>>

The Asus router deals correctly with it, displaying that device name correctly.

However, some third party services like NextDNS, which rely on the correct syntax, don't process correctly the custom names and doesn't show them in their page, because of that bug.

...

I'm using a GT-AX6000. Happens on both regular and rog firmware.

Thank you for bringing this to our attention. As you said, this could become a problem for some 3rd-party s/w that currently parse the affected NVRAM vars based on one specific syntax form.

I have added/modified code in YazDHCP to be able to account for such scenarios. A GitHub PR has already been submitted.

 

[maghuro]

Thank you for bringing this to our attention. As you said, this could become a problem for some 3rd-party s/w that currently parse the affected NVRAM vars based on one specific syntax form.

I have added/modified code in YazDHCP to be able to account for such scenarios. A GitHub PR has already been submitted.

Thanks!

As I'm not familiar with Asus code, I sent a fix directly for NextDNS which uses go.

Just have some attention regarding all NVRAM cars you use on YazDhcp - @ColinTaylor said he noticed the same issue with some other vars also.

 

[maxbraketorque]

Somewhat unrelated, but is there a reason for quantity of closing ">" symbols?

 

[ColinTaylor]

Somewhat unrelated, but is there a reason for quantity of closing ">" symbols?

Yes. Each record has a fixed number of fields, and ">" is the field separator.

 

[maxbraketorque]

Yes. Each record has a fixed number of fields, and ">" is the field separator.

Thanks. Some of mine in /jffs/nvram/custom_clientlist end with 5 ">" and some with 2 ">". None end with 4 ">".

 

[ColinTaylor]

Since this thread was created subsequent firmware updates have increased the number of fields to nine. I don't use this feature myself so I don't know how many of those fields contain data in practice.

https://github.com/RMerl/asuswrt-merlin.ng/blob/b02b0c2377f75d18e6b21e793fbedda897a75819/release/src/router/shared/misc.c#L6610

 

[maxbraketorque]

Interesting to see 9 fields. I'm only seeing 4 fields (388.7 on an RT-AX86U Pro), and my file is missing the leading "<" as maghuro described. It seems to be working, but perhaps I'll try cleaning up the syntax to see if that does anything.

 

[ColinTaylor]

Can you post your current file. Like I said, I don't use this feature so I'm only going by what's in the source code. My assumption was that the old, shorter format would be converted to the new format using the code I linked to. Maybe that's not the case.

EDIT: I've just added a custom client through the GUI and it created the nvram variable with only six fields (like the 386.x firmware used). After rebooting the router it had changed it to have nine fields.

 

[maxbraketorque]

Here is my current file after adding a few entries via the command line:

WCAMRE>58:03:FB:80:F9:54>0>5>>>>><WCAMRW>C0:6D:ED:5D:7C:C5>0>5>>>>><AMTOCEiPad23-24>4E:28:8D:01:8D:8F>0>21>>>>><WYXPS15>AC:74:B1:87:52:8F>0>35>>>>><Alarm>B0:09:DA:71:EE:0D>0>71>>>>><Hydra>BC:D0:74:0B:CA:99>0>6>>>>><Ghidorah2016>78:4F:43:7F:79:90>0>6>>>>><WaterPumpTSwMain>2C:F4:32:23:5E:43>0>68>>>>><WCAMFE>F8:4D:FC:5D:E9:70>0>5>>>>><WCAMFW>F8:4D:FC:D8:90:39>0>5>>>>><WCAMFD>84:9A:40:B8:10:BB>0>5>>>>><AMTAWatch>28:C5:38:08:A3:11>0>64>>>>><WRHWLevel>00:1E:C0:D3:05:BF>0>25>>>>><WCAMH2O>2C:A5:9C:14:AC:52>0>5>>>>><WCAMRG>24:0F:9B:5D:FB:33>0>5>>>>><WCAMCabinet>7C:DD:90:A4:DF:16>0>5>>>>><WaterPumpTSwBk>C4:82:E1:4D:3A:9F>0>68>>>>><WYF3>B0:4A:6A:2E:2E:24>0>9>>>>><WRHRXM>08:BF:B8:CB:13:90>0>2>>>>><MBTS22U>78:F2:38:09:B3:C4>0>9>>>>><Ghidorah2019>A4:83:E7:74:0D:7A>0>6>>>>><AMTOCEiPad23-24b>88:E9:FE:0E:AD:DF>0>21>>>>><AMTKindle>DC:91:BF:3A:E3:BF>0>20>>>>><WRHHWH>A0:CC:2B:6B:C2:C3>0>58>>>>><WCAMWZFD>80:48:2C:02:90:B6>0>5>>>>><WCAMWZFE>2C:AA:8E:E2:28:31>0>5>>>>><UtilRoomWaterTSw>D8:BF:C0:54:A0:69>0>68>>>>><UtilRoomAirTSw>BC:FF:4D:2F:12:61>0>68>>>>><WRHDoorLock>F8:36:9B:7D:4A:8B>0>63>>>>><WRHTStat>BC:DD:C2:33:AA:19>0>49>>>>><RoboVacCabin>BC:DD:C2:56:1C:80>0>61>>>>><CabinetTSw>2C:F4:32:23:5E:5E>0>68>>

Note that the final entry ends with 2 ">". Before I added the custom entries on the command line, the last several entries ended with 2 ">". I suspect that if I add a leading "<" to the beginning of file, and change all the endings to ">>>>", the router will leave it as-is, or maybe it change everything to nine fields like it did for you.

 

[ColinTaylor]

Interesting. So after adding your new entries it's changed them all to have nine fields apart from the last entry. So if you reboot I expect it to "correct" that last entry.

I don't know why you had multiple shorter entries before, unless you're using some sort of script to keep it updated.

 

[maxbraketorque]

Interesting. So after adding your new entries it's changed them all to have nine fields apart from the last entry. So if you reboot I expect it to "correct" that last entry.

I don't know why you had multiple shorter entries before, unless you're using some sort of script to keep it updated.

I was also surprised to see the last couple entries ending with ">>". Before I started adding items on the command line, I rebooted a few times, and that had no effect. No scripts for the client list, and overall pretty minimal installation. This router is serving as an AP.

 

[maxbraketorque]

Well, changing to the correct syntax didn't do much. Upon reboot, the leading "<" was again removed, and all the entries now end with five ">" again, except the last which still has four.