WAN Mode only: Values in Option 60 and Option 61 set in WebUI are not saved at all

[mackonsti]

Firmware Version Affected 384.16_0-gnuton1

Is this bug present in upstream Merlin releases too? I cannot know, but it seems in previous versions this issue was not present (according to an older guide)

Describe the bug Without a DSL line present, I decided to test out the DSL-AC68U with its WAN feature. So after updating the firmware and resetting to factory defaults, I followed the guide in another forum and after enabling "Ethernet WAN" it seems that in the WAN > Basic Config tab, neither Manual clientid (Option 61) value nor Manual vendor class (Option 60) value are saved after "Apply".

To Reproduce Steps to reproduce the behavior:

1. Update with current gnuton firmware 384.16_0-gnuton1;
2. Peform reset to factory defaults;
3. Upon reboot, do a quick config (skip WLAN) by selecting admin/password;
4. Set the DSL-AC68U to WAN mode and select "Ethernet WAN" and "LAN Port 4" for example;
5. Go to WAN > Basic Config tab, leave all as they are by default;
6. Enter a value in Manual vendor class (Option 60) then click APPLY;
7. Alternatively enter a value in Manual clientid (Option 61) and click APPLY.

Expected behavior The value entered on either Manual clientid (Option 61) or Manual vendor class (Option 60) should remain there after APPLY and be taken into consideration in the settings of the modem/router. It seems this is not the case.

Screenshots This is the expected visual result on a RT-AC88U from the solution provided in another forum, more than a year ago:

Extra Notes Ciao @gnuton thank you for your great work on this modem/router, I hope you are well and safe. I got a used DSL-AC68U recently and after updating to latest official Asus firmware v3.0.0.4.384_81981, I did a factory reset, then applied your current firmware release a few days ago version 384.16_0-gnuton1

Until I take this DSL-AC68U to my home town (to use with VDSL via phone line) I decided to use it on my current fibre setup by enabling the WAN feature. Whilst searching the parameters needed for my Internet Provider, I found this forum thread that provides the solution: Just add the vendor class neufbox6 in the WAN configuration: https://lafibre.info/remplacer-sfr/ftth-sfr-1gb-remplacer-la-nb6vac-par-un-routeur-asus-rt-ac88u/

This setting seems to have worked in September 2018 for the Merlin firmware release of RT-AC88U according to the posts and thread title.

I do not know where to look via ssh to confirm if the value is saved or not (or NVRAM? not sure) and whether it's the WebUI not showing only, due to some e.g. spelling mistake of the interface. Thanks for guiding me through, I am a power user but rather new in Merlin and AsusWRT. Grazie mille.

UPDATE: After Googling, I found out some basic commands via ssh and here is the output, hope it helps. I am not sure a) which variable is linked to WebUI and b) how to set it in NVRAM to check if it is shown in WebUI and also if it works with my WAN connection to the Fiber ONT (the optical to LAN converter). Thanks

admin@DSL-AC68U:/# nvram show | grep -i wan | grep -i vendor
size: 57802 bytes (7734 left)
dsl_wan_vendorid=
wan_vendorid=
none_wan_vendorid=
wan0_vendorid=
wan1_vendorid=
admin@DSL-AC68U-B330:/#

[mackonsti]

UPDATE: I have done some further research and found a thread that talks about the same ISP as mine, where another user back in 2018 fixed this with NVRAM parameters so I did the same

nvram set wan_vendorid="neufbox6" nvram set wan0_vendorid="neufbox6" nvram commit reboot

So I logged in as "admin" with the same WebUI password, and set the wan_vendorid but the WebUI did not show anything upon refresh. Then I set wan0_vendorid and the WebUI showed my value, finally. I did commit at each nvram command.

But when I rebooted (via SSH) the parameters were not saved... Is this normal that "nvram" loses the values upon each reboot? Are these values saved to some script that runs upon reboot? Do we need "JFFS custom scripts and configs" enabled?

After a few efforts, I rebooted and upon reboot one of both parameters was saved: wan_vendorid and not wan0_vendorid at all. On another occasion, I set only wan0_vendorid and upon commit and reboot, the system shows it now in wan_vendorid instead... Nevertheless, setting both parameters and waiting idle for some time (i.e. no reboot) did not produce results. The ONT-WAN wasn't talking to the DSL-AC68U and I don't know how to check this in Terminal (SSH on macOS)...

Thank you

[gnuton]

Hi, Thanks reporting this issue in such a detailed way.

I checked the code and: options 61 reads the value "wan_clientid" from NVRAM option 60 reads wan_vendorid from NVRAM

Setting them manually works admin@DSL-AC68U-CC88:/tmp/home/root# nvram set wan_vendorid="vendorid" admin@DSL-AC68U-CC88:/tmp/home/root# nvram get wan_vendorid vendorid admin@DSL-AC68U-CC88:/tmp/home/root# nvram set wan_clientid="clientid" admin@DSL-AC68U-CC88:/tmp/home/root# nvram get wan_clientid clientid

but when you re-load the UI the values are reset.

I checked where those values are used in the code and it looks like, they are not actually used at all. I dunno the reason yet. You may try to kill and start udhcpc with the settings you want to and see if it works

        char *dhcp_argv[] = { "/sbin/udhcpc",
                "-i", wan_ifname,
                "-p", (snprintf(pid, sizeof(pid), "/var/run/udhcpc%d.pid", unit), pid),
                "-s", "/tmp/udhcpc",
                NULL,           /* -t2 */
                NULL,           /* -T5 */
                NULL,           /* -A120 */
                NULL,           /* -b */
                NULL, NULL,     /* -H/-F wan_hostname */
                NULL,           /* -Oroutes */
                NULL,           /* -Ostaticroutes */
                NULL,           /* -Omsstaticroutes */
#ifdef RTCONFIG_IPV6
                NULL,           /* -Oip6rd rfc */
                NULL,           /* -Oip6rd comcast */
#endif
                NULL, NULL,     /* -x 61:wan_clientid */
                NULL, NULL,     /* -V wan_vendorid */
#ifdef RTCONFIG_TR069
                NULL,           /* -O43 */
#ifdef RTCONFIG_TR181
                NULL, NULL,     /* -x 125:vivopts */
#endif
#endif
                NULL, NULL,     /* -x 61:wan_clientid (non-DSL) */
                NULL };

Btw I may be wrong, since there are a few things which are not clear yet, like:

1. i see udhcpc running with more arguments that the one here, which means it get started somewhere else too
2. nvram setting are cleared and I dunno yet why

More investigation is needed

[mackonsti]

Hi and thanks for your reply, I appreciate. Is this a bug on the original Merlin you think? I was puzzled to see that not only are these values "gone" when you reset the UI but also even if you do nvram commit they are lost upon reboot :-(

I am not even sure why would the modem support 3 values in nvram i.e. wan_vendorid, wan0_vendorid and wan1_vendorid; could it be that WAN eventually doesn't work?

Would it make sense to ask you to report this problem to the original Merlin development members? I have no access there.

Also, I am not very familiar with the platform or Merlin, so I apologise but I have no understanding of your suggestion "You may try to kill and start udhcpc with the settings you want to and see if it works" :-) Any quick help on how to kill it on this modem and set the values? I am not sure it has a man page on the ssh session?

Is there any danger to revert to the original Asus last firmware, test to see if these values work via ssh and reboot a few times to see if they stick around in nvram? Another article I found later was talking about "stock firmware"...

Thank you.

[gnuton]

Hi, The router is pretty much unbrickable unless you play with the bootloader. So please feel free to switch back to stock firmware and test it out. Remember only to reset nvram once you are on the new firmware. As for merlin, you can submit bugs to upstream by creating an issue here: https://github.com/RMerl/asuswrt-merlin.ng/issues but I will wait to do that until it's not clear what's the problem is.

As for wan0_vendorid I'm not sure about that code works well yet, I need to sit down and really take a look at it. The wan0 e wan1 I think are for dual wan (DSL + Ethernet) that will run the dhcp client on both interfaces

[mackonsti]

Hi again @gnuton thanks for your reply, last night I spent some time battling with this and I came to some useful results before I give up, as I am not sure I can be more helpful as my technical knowledge on this (and Merlin) is limited, so I rely on your kind assistance.

1. So I reverted to the previous (latest) official firmware DSL_AC68U_3.0.0.4_384_81981 and then when it rebooted I did Factory Defaults and ticked to "remove all settings and data" etc. Hope this was enough to erase NVRAM.

2. Upon reboot, created admin password and went straight into SSH to enable it. Then I went to WAN page and enabled basic "Ethernet WAN" to "Port 1" i.e. to use only WAN (not DSL) and not dual WAN (it's disabled). That is in TAB No.2 of the section.

3. The stock firmware of course has no option in the WAN page to add "Option 60" and "Option 61" for vendor and client IDs so I added it manually via SSH:

nvram show | grep -i vendorid
nvram set wan_vendorid="neufbox6"
nvram commit

BUT! I got lucky because I did this in SSH before entering the WebUI... and I discovered that the moment I clicked on the Asus router's page to check WAN, the parameter got erased! I tried like 5-6 times; at each time I put in SSH before accessing any WAN browser page, the nvram commit is holding! But when the page is visited, values are erased!

This means that both in original and your firmware, there is a (JS?) code that REMOVES any value from:

wan_vendorid
wan0_vendorid
wan1_vendorid
wan_clientid
wan0_clientid
wan1_clientid

That is why you also could not see it upon refresh. So this is the first thing to check.

4. After discovering this, I stopped visiting the WAN page of the Merlin firmware and played on SSH. I keep the basic "Ethernet WAN on Port 1" setting (changed later to Port 4 but same bad results) and I tested the following:

nvram set wan_vendorid="neufbox6"
nvram set wan0_vendorid="neufbox6"
nvram commit
reboot

Upon reboot and SSH, I discovered that the system only kept wan_vendorid value and removed wan0_vendorid value. Logic dictates that there is some check mechanism when rebooting and the firmware checks the type of WAN selected by user and removes other values on purpose:

• wan_vendorid is likely used only in situations where only the fixed "Ethernet WAN" is used only (no USB or DSL)
• wan0_vendorid and wan1_vendorid are likely used with Dual-WAN where you'd have DSL/USB and "Ethernet WAN" for example (like load-balancing or fall-back).

However, setting my needed value "neufbox6" to all three or just two parameters, did not produce results i.e. the optical fibre ONT device wasn't giving DHCP to the DSL-AC68U from the operator's network...

7. So this is my final point. After searching through the internet, people report success with this simple action but on the RT-AC68U instead, which is not a DSL modem but only a WAN router. Perhaps the Asus firmware is buggy but I cannot use any WAN (single or dual) at all. Something's messed up with either the binding as they call it or routing etc. I have no deeper knowledge. All I know in System Logs that there was an interface vlan2 created that had a self-assigned IP when I ran ifconfig on SSH console.

8. Please kindly confirm that you do merge the latest Asus Merlin firmware and follow the same release versioning as found in https://www.asuswrt-merlin.net/changelog-382 yes? I ask because they mention of many WAN fixes but in the recent versions.

Since you have access to that Merlin repo and could contact the team (because our modem is not part of their official releases, hence if I send a support request, it could be totally ignored, but you do pulls so perhaps they will answer) I would rely on your kind help.

First of all, the WAN page has 2 mistakes:

• Erases the values from NVRAM for no reason.
• Doesn't check which value is needed, depending on WAN scenario. It is not correct to put wan0_vendorid maybe or wan1_vendorid from the text box, perhaps an IF-ELSE check to be added if we need just wan_vendorid or both (for a dual WAN scenario).

Once we solve this, perhaps we can see how WAN works on our router in single/dual WAN modes. I tried both and at the end I just set USB/LAN for dual WAN to test but that also didn't get me to access the Internet provider (no DHCP obtained).

Thank you for your time (sorry for the long report, I do that at work LOL) let me know if I can be of further help.

[gnuton]

HI, Thanks a lot for the long report. I love to have details, that helps me a lot to understand the problem. This firmware is based on Merlin and it has all its changes as long as they are in the mainline (the branch which works for all router models).

BTW I will come back to you when I have concrete answers and maybe a solution. In the meanwhile, if you do not use DSL, I think you may try to flash the RT-AC68U firmware, I guess it should work and you should be able to test what you have found on the internet. Please let me know if that works out. Thanks again!

[mackonsti]

Hi @gnuton thanks for your reply! You really mean that? Flash the DSL modem with the RT one? But is the hardware not different? They don't have the same rear ports, the DSL has RJ11 for phone, the RT has WAN-RJ45... not sure how the firmware will handle them, nor if our modem will accept the .trx file LOL... you have done that, can it be done?

What do you believe is worth testing? The nvram parameters being saved & kept for example, upon reboot or WebUI visit of WAN pages? I cannot see anything more that can be tested :-)

Grazie/Thanks/Merci/Gracias/Ευχαριστώ

[gnuton]

Flashing the RT version you will not take advantage of some of the stuff you have in the DSL counterpart... but since the kernel is built for the same SoC you should be fine and it should boot. In case you brick it, just reflash the original firmware and start over. I bricked my a few times while developing this firmware. You can always recover. You should be able to test even openwrt on it.

What to test, you asked.... Just try to see if the instructions on the internet work for you for your issue. My feeling is that you should have the same experience you have with the DSL firmware.

[mackonsti]

Hi @gnuton I hope you are well and safe. I hesitate flashing the RT-AC68U firmware, as on www.snbforums.com I found someone who did the same and had hardware issues, most notably with USB etc. so I am not sure if I can risk it (nor experienced enough in flashing back etc.)

Can I ask you to have a look at the WAN page on the Web UI of the modem/router and see what is possibly going on with these values and why they get reset when we revisit the page? I refer to the HTML page fields of Manual vendor class (Option 60) and in Manual clientid (Option 61) that aren't saved, as you saw.

Thank you again for your time spent.

[gnuton]

I will have a better look and I will come back to you.

[mackonsti]

Hi @gnuton I hope you are well and safe. I see you released a new build, any chance that you had investigated the issue found above? Just to know what to expect :-) Grazie mille

[gnuton]

Hi, Please do not test the new alpha builds yet since they could brick your device. I will check this issue again once the new version is out since it will have a lot of changes.

On Sun, Jul 12, 2020 at 1:06 PM MacKonsti notifications@github.com wrote:

Hi @gnuton https://github.com/gnuton I hope you are well and safe. I see you released a new build, any chance that you had investigated the issue found above? Just to know what to expect :-) Grazie mille

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/gnuton/asuswrt-merlin.ng/issues/36#issuecomment-657206968, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAEMYRA2NOG6XXCYCRYV3JLR3GKK5ANCNFSM4MLMFQIA .

[gnuton]

Hi, the new 386 builds may have fixed his issue.

[mackonsti]

Hi @gnuton and thank you for your continuous efforts. I have no longer this router using an optical fibre terminal as I moved it few weeks ago to a normal VDSL setup in a different household. If I manage to buy the same one second-hand and at a good price, I will try the build and the parameter setting to confirm if the reported issue is solved indeed. Many thanks for remembering this topic/ticket. Warm regards, stay safe.

[Rad0van]

@gnuton I know this is closed but allow me a question. I have switched from VDSL to optical line but unfortunately it is limited to the devices from provider (shitty Huawei or Sagemcom). But there is an option to ask them to switch the device into bridge mode. The question is: could I use my existing DSL-AC68U (or even DSL-AC56U) in WAN mode for this?

BTW, thanx a million for working on AssuWRT Merlin for DSL devices!

[gnuton]

You should be able to do that. Look at answers answer marked in green at https://superuser.com/questions/1471601/how-to-configure-the-router-when-the-gateway-is-in-bridge-mode

On Mon, Dec 21, 2020, 20:02 Radovan Skolnik notifications@github.com wrote:

@gnuton https://github.com/gnuton I know this is closed but allow me a question. I have switched from VDSL to optical line but unfortunately it is limited to the devices from provider (shitty Huawei or Sagemcom). But there is an option to ask them to switch the device into bridge mode. The question is: could I use my existing DSL-AC68U (or even DSL-AC56U) in WAN mode for this?

BTW, thanx a million for working on AssuWRT Merlin for DSL devices!

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/gnuton/asuswrt-merlin.ng/issues/36#issuecomment-749140382, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAEMYRH4AYPCEQAV723O6TDSV6LSPANCNFSM4MLMFQIA .

[Rad0van]

You should be able to do that. Look at answers answer marked in green at https://superuser.com/questions/1471601/how-to-configure-the-router-when-the-gateway-is-in-bridge-mode

Thanx for answer. But just to be sure I go tthe description right (seems what you posted is switched in a different direction): I need to use Huawei as a ONT/GPON to connect to optical network on one side and in bridging mode to my Asus. Then I need to configure Asus DSL-AC68U as a router where WAN port is one of the LAN ports (connected to Huawei). Sorry to bother but is this really doable? Should I use any special software or yours will do?

[Rad0van]

@gnuton I have never got to doing this but now it seems I should (for various reasons). However I am reluctant to ask the provider to switch the ONT/GPON router to bridge mode unless I am sure that my current router can handle that. So let me please ask this once again (and sorry for bothering). I need something like this to be functional:

--optical_line-->[opt port]:[Huawei HG8145V5 in bridging mode]:[WAN port]--ethernet_cable-->[LAN port]:[DSL-AC68-U]:[other LAN ports/ WiFi]

So DSL-AC68-U would create WAN connection over the LAN port and still be routing to other LAN ports and WiFi. Is that possible? Or should I just look for RT router instead? Thank you again...

[gnuton]

Hi, That's defintely possible, just put your DSL-AC68U in WAN Ethernet mode. :D BTW I am happy to help you but if possible let's not use ticket issues (even if closed) as support ticket for other issues. Please use the forum for asking support. You will get tons of answers and support in less time. Thanks!

[Rad0van]

Thanx a lot. Will do next time if needed.