DD-WRT administration interface not rendered properly. javascript issues too

[saivert]

DD-WRT is a nice third-party firmware interface for a host of cheap wireless routers, most prominently Broadcom based routers like Linksys WRT54G. It has a nice web based administration interface, but this interface is not rendered properly in WebPositive build hrev488 on Haiku r1alpha2.

Provided is screenshot with BeZillaBrowser used as reference since it renders the interface properly and also handles the JavaScript used on the page.

[saivert]

screenshot for comparison

[michaelvoliveira]

Please report this bug at

​http://mmlr.dyndns.org/timeline

Someone please set it to invalid

[stippi]

It's ok to report WebPositive issues here.

But from the screenshot, I don't see what the big problem is. Some frames are missing, but the interface looks functional. For all I know, it could be a problem in the page and not WebPositive. Also, could you explain what is non-functional about the Javascript? How about other WebKit browsers, do they all render this interface "correctly"?

[saivert]

Chrome, Opera and Internet Explorer handles the DD-WRT web interface ok. Everything works.

The page has some CSS for the FIELDSET tags (the groupbox like elements on the page) which only looks as it is supposed to on Firefox/BeZillaBrowser.

Following JavaScript snippet is the function that is called by the "Add" button on the page. This sets some form (identified by F) values then submits the form.

function forward_add_submit(F) {
F.change_action.value="gozila_cgi";
F.submit_type.value = "add_forward_spec";
apply(F);
}

This is the "apply" function:

function apply(form, text, delay) {
	form.submit();
	for (i = 0; i < form.elements.length; i++) {
		if(defined(form.elements[i].disabled)) 
			form.elements[i].disabled = true;
	}
	if (form.contents) document.getElementById("contents").style.color = '#999999';
}

so it seems like WebPositive's handling of the form submit from javascript is the culprit here. When that is executed it comes with an error message:

Error loading ​http://192.168.1.1/apply.cgi Server returned norhing (no headers, no data)

The other browser happily submit the form when called from javascript.

[saivert]

This bug is still present in build hrev515.

[mmadia]

Hi. Our WebKit port (and thus WebPositive) was updated in July. Could you retest this in a new nightly image and report back? ​http://www.haiku-files.org/haiku/development Thanks!

[pulkomandy]

Our WebKit port was updated again last week. Could you retest this in a new nightly image and report back? ​​http://www.haiku-files.org/haiku/development Thanks!

[anevilyak]

Will check tonight, my router runs this as well. Since it was primarily AJAX issues similar to those seen with GMail, I suspect this is likely to be resolved though.

[anevilyak]

The interface renders properly from a visual standpoint, but something's still wrong as far as actually handling it goes. Clicking any of its tabs to go to the corresponding configuration subsection triggers the appropriate http digest authentication dialog, but after one enters credentials, Web+ simply sits there waiting, seemingly for a response, until finally failing with a network read error several minutes later.

[pulkomandy]

There may be bugs in our http auth code. It was only tested with dev.haiku-os.org so far.

[pulkomandy]

Does hrev47543 improve the situation?

[saivert]

I have no immediate way to verify this as I no longer use DD-WRT.

[anevilyak]

Will give it a try after work.

[anevilyak]

Seems there's still an issue with this one: while browsing through the interface generally works, attempting to apply/save settings winds up hitting the interface's apply.cgi and then stopping dead without actually executing it properly. Tested with hrev47561 and DD-WRT v24.

[pulkomandy]

Does hrev47586 (and especially a1cce97) help with this remaining issue? I'm only guessing here, but this fixed some other cases of stalling requests.

[anevilyak]

Doesn't appear to have made a difference, unfortunately. Web+ does indicate that the apply.cgi request finished both before and after that change, but simply stops there. Is there any network traffic tracing that could be enabled or whatnot, that might yield a better picture of what's going on?

[pulkomandy]

Yes, building the network kit in debug mode will make the HTTP code trace all requests to the standard output. This may provide more hints as to what is going on.

[pulkomandy]

Hi, If this is still a problem, a capture of HTTP requests as suggested in the previous comment would be helpful.

[AGMS]

Still have graphic glitches on a router web interface, this time Merlin. Some things don't render, tabs like the WiFi Hz only show when you wave the mouse over them.

[AGMS]

And here's what the Merlin interface looks like in Firefox.

[sneaky]

​http://demoui.asus.com/ has a merlin UX set up. Not at haiku box right now but I think it was glitching where there's an iframe and a bunch of fancy css3 or maybe 2.1 stuff (corners, shadows, lots of heavy bits).

[sneaky]

Tried to attach a DD-WRT VirtualBox VM but it was larger than 5MB size limit. I made it with an x86 or x86_64 public vga image that you can get from their website, in any event: ​https://dd-wrt.com/support/other-downloads/?path=betas%2F2019%2F04-25-2019-r39654%2Fx86%2F

[pulkomandy]

shadows are known to be missing and there is a separate ticket for that. The asus page seems to render ok on first display but glitches when scrolling, this is probably because it uses transforms, which are not handled properly in some cases and confuse the update rectangle (see also a possibly related ticket about HTML buttons not showing properly in some cases).

The javascript issues mentionned seems gone now? However I think the http authentication is currently broken, which may be a problem on real routers if they use it (and not some custom login method)