Asus RT-AC68U 380.62_beta1-g7d0d688 problem with name of units

[hispanico957]

Before this problem not happened, but after upgrade to 380.62 all name of units connect are not show:



also if in lan under servr-dhcp i set the name of units connect.

Also in guest wireless its impossible set a password



Thank
Hispa

 

[john9527]

Before this problem not happened, but after upgrade to 380.62 all name of units connect are not show:

You have to wait for the networkmap scan to complete after reboot to fully populate the pulldown. It can take up to 10 minutes after a reboot.

Also in guest wireless its impossible set a password

The yellow background is Chrome jumping in and doing auto-fill (Chrome ignores the html directives to not do autofill). Turn off autofill or use a different browser.

@RMerlin - I put a work around for the Chrome autofill in my fork...basically you need to set the field read-only until you click on it. It's the only thing out of many I tried that works.

 

[RMerlin]

@RMerlin - I put a work around for the Chrome autofill in my fork...basically you need to set the field read-only until you click on it. It's the only thing out of many I tried that works.

Thanks for the hint, I'll give it some thought for a future release. I constantly run into that problem myself while on the DDNS page.

Did you check if there wouldn't be an HTML5 attribute that might also resolve the issue without requiring a JS hack (or, maybe even a Chrome-specific attribute since it seems to be Chrome-specific)?

 

[hispanico957]

You have to wait for the networkmap scan to complete after reboot to fully populate the pulldown. It can take up to 10 minutes after a reboot.


The yellow background is Chrome jumping in and doing auto-fill (Chrome ignores the html directives to not do autofill). Turn off autofill or use a different browser.

@RMerlin - I put a work around for the Chrome autofill in my fork...basically you need to set the field read-only until you click on it. It's the only thing out of many I tried that works.

Thank big Merlin i follow your suggestions but using Edge in guest wireless



is not possibile set password..

Hispa

 

[john9527]

Did you check if there wouldn't be an HTML5 attribute that might also resolve the issue without requiring a JS hack (or, maybe even a Chrome-specific attribute since it seems to be Chrome-specific)?

I must have tried every possible workaround I could find on the net....including specific combinations of the html attributes. Chrome is just stubborn and ignores everything (and apparently has changed over time to circumvent the workarounds).

 

[RMerlin]

Thank big Merlin i follow your suggestions but using Edge in guest wireless

is not possibile set password..

Hispa

Can you try switching the router to English? Sometimes, bugs exist only with specific languages. That would help narrowing down the cause.

 

[RMerlin]

I must have tried every possible workaround I could find on the net....including specific combinations of the html attributes. Chrome is just stubborn and ignores everything (and apparently has changed over time to circumvent the workarounds).

Oh well. I'll take a look at my HTML5 reference book at home to see if maybe anything could pop up. I'll also poke at my contacts who work in webapps development.

 

[john9527]

Oh well. I'll take a look at my HTML5 reference book at home to see if maybe anything could pop up. I'll also poke at my contacts who work in webapps development.

If you find something....you could make good money charging for the answer

 

[RMerlin]

If you find something....you could make good money charging for the answer

LOL

I just spoke with my contact, he never had to deal with this particular issue, but pointed me at some resources both from Chromium's bug tracket and the W3G that look interesting. I have a lot of reading to do first, I'll keep you informed.

 

[hispanico957]

Can you try switching the router to English? Sometimes, bugs exist only with specific languages. That would help narrowing down the cause.

Also in english same problem ..

Hispa

 

[RMerlin]

Also in english same problem ..

Hispa

Odd, pretty sure it was working last time I tested something with Guest Mode a few weeks ago. I'll have to try it out again.

 

[hispanico957]

Odd, pretty sure it was working last time I tested something with Guest Mode a few weeks ago. I'll have to try it out again.

Thank mate

Hispa

 

[RMerlin]

Thank mate

Hispa

You can't edit it because you have it set to WPA2-Entreprise, which uses Radius for authentication. Switch it to WPA2-Personal.

 

[RMerlin]

If you find something....you could make good money charging for the answer

Reading the specs, I see two things:

1) Google ignores the autocomplete="off" despite the fact that it should, based on the https://html.spec.whatwg.org/multipage/forms.html#autofill-expectation-mantle specs (when the field type is not hidden, it should observe the "autofill-expectation-mantle" - which it clearly doesn't

2) Some additional documentation on Google's site seem to imply that autofill behaviour can depend on other fields set before or after the current field, not just on the state of the current field. (I couldn't wrap my brain around their explanation, but them I'm fairly tired tonight, so...)

Since we are effectively asking a user to provide a new password (it's new from the router's point of view, you aren't providing the router with a password it already knows), using autocomplete="new-password" is accurate, and does work properly for me with the DDNS page where I just tested it. I would recommend applying this to any field where the type is set to "password", and you aren't logging in. It seems closer to the specifications outlined above than relying on the read-only hack (which I did find in my searches).

 

[john9527]

Reading the specs, I see two things:

1) Google ignores the autocomplete="off" despite the fact that it should, based on the https://html.spec.whatwg.org/multipage/forms.html#autofill-expectation-mantle specs (when the field type is not hidden, it should observe the "autofill-expectation-mantle" - which it clearly doesn't

2) Some additional documentation on Google's site seem to imply that autofill behaviour can depend on other fields set before or after the current field, not just on the state of the current field. (I couldn't wrap my brain around their explanation, but them I'm fairly tired tonight, so...)

I remember I tried some of the suggestions such as adding some dummy hidden fields to 'break' the autofill....didn't work.

Since we are effectively asking a user to provide a new password (it's new from the router's point of view, you aren't providing the router with a password it already knows), using autocomplete="new-password" is accurate, and does work properly for me with the DDNS page where I just tested it. I would recommend applying this to any field where the type is set to "password", and you aren't logging in. It seems closer to the specifications outlined above than relying on the read-only hack (which I did find in my searches).

I never found 'new-password' as a parm for autocomplete.....nice detective work. But, I'm going to stick with the read-only change. I think it's probably more bulletproof long term since all the browsers seem to be be playing with their own interpretation of autocomplete (and I've already implemented it across all the pages )

 

[hispanico957]

You can't edit it because you have it set to WPA2-Entreprise, which uses Radius for authentication. Switch it to WPA2-Personal.

Yessssssssss is true

Thank
Hispa