[dev] Alternative webif. LuCI + uhttpd?

[geekgirl]

As I recall, the webif is largely closed source. From a quick look: /usr/www/cgi-bin/(webcm|firmwarecfg)

Would there be interest in the development of an alternative webif, possibly based on LuCI + uhttpd (replacing mini_httpd)?

And if so, is there a list, or separate download, for the other non-GPL parts which are not included in the release sources?

Thanks

[thechief]

As I recall, the webif is largely closed source. From a quick look: /usr/www/cgi-bin/(webcm|firmwarecfg)

Yes. You also need to add the core logic (cm_logic) to that equation. This is the "master brain" behind the whole of the web interface and the firmware's entire operation.

Would there be interest in the development of an alternative webif, possibly based on LuCI + uhttpd (replacing mini_httpd)?

Not from our end. Getting rid of cm_logic is not going to be a trivial exercise. At the moment, if the core logic crashes, everything to do with ADSL, wireless, etc., dies. The kernel may still be running, but little can be done with that. Can LuCI replace the core logic? It would have to control the web interface, the config section of the mtd3 partition, all the internal communications (including with the closed source modem and wireless drivers), flash reads/writes, etc. I am sure it can be done - but how long would it take, and would it be worth the effort?

is there a list, or separate download, for the other non-GPL parts which are not included in the release sources?

No. What specifically are you referring to?

[geekgirl]

I was aware of /usr/bin/cm_* , as I used at least cm_cli before, and know that the webif interfaces with cm_logic.
I wasn't actually implying replacing cm_logic, but now come to think of it, given its size of 1.2MB, it would be desirable. But yeah.. Reverse engineering that could take unplannedly long time.

Never mind then

[thechief]

I wasn't actually implying replacing cm_logic

Makes sense. I don't think it is easily replaceable (if at all). It is so tightly bound with the TI reference code that selectively replacing it is not a viable proposition (one would be better off junking the entire TI code and starting all over). Trying to interface with it, when its interface is not documented, would be just as interesting. Just have a look at the spaghetti html and javascript code of the webif. Adding anything new to the webif can be an absolute nightmare.

It may be possible however, if you can unravel the internal communications protocols between the web browser/server and the core logic. If you can design an entirely new web interface based on clear, sensible, and portable html and javascript that makes no assumptions about the web server, then all you need do is to communicate the results to the core logic, so that it can execute the results. This sounds easier than it really is. But what you need to do with each screen is this:

a. populate all controls with data retrieved from the live config
b. validate user input
c. save the results to the live config, and
d. run any other commands that may be necessary.

Step "a" involves telling the core logic to retrieve the data from the live config, and then inserting it into the appropriate place on the form.
Step "b" can be done by yourself
Step "c" involves telling the core logic to write the data to the live config
Step "d" involves communicating with the core logic or an external program, to run the relevant command, with the necessary parameters - you need to know who is going to run the command.

These steps can be done by sending the appropriate xml-encoded streams to the core logic, either directly, or via cm_cli*. This is where the real problem lies. Of course, there are many ways of looking at the background communications between the web server and the core logic, and therefore learning what is being sent and how it is encoded. I think I have given enough information for you to know whether you fancy the task!

[geekgirl]

Trying to interface with it, when its interface is not documented, would be just as interesting. Just have a look at the spaghetti html and javascript code of the webif. Adding anything new to the webif can be an absolute nightmare.

Darn.. Is it undocumented at all? Back when I used it, I remember skimming through a pdf documenting.. cm_cli I think?

These steps can be done by sending the appropriate xml-encoded streams to the core logic, either directly, or via cm_cli*. This is where the real problem lies. Of course, there are many ways of looking at the background communications between the web server and the core logic, and therefore learning what is being sent and how it is encoded.

Disassembling, setting up environment for debugging, `strace -i', etc. Probably would take a considerable amount of time. :/

I think I have given enough information for you to know whether you fancy the task!

You've always been generous. Thank you.

Unfortunately, the task seems beyond me.

BTW, way back I was working on porting the AMD6966M driver from the D-Link 2640T GPL'ed firmware, for routertech. I remember I was stuck at one last conceptual issue (before actually building to test), and finally lost interest.

Recently, I realized someone contributed a patch (about 17 months ago) to add 802.1Q VLAN support for ADM6996M/ADM6996FC in OpenWRT.
Specifically changeset 26865
Just thought I'd mention it, in case there's interest to add/port to Routertech in a future release.

Thanks again

[thechief]

Darn.. Is it undocumented at all? Back when I used it, I remember skimming through a pdf documenting.. cm_cli I think?

Yes, that is still there in the RT firmware docs. It is the result of what we have been able to figure out and thereafter reduce to something straightforward. There are actually a number of very good examples in the GPL sources for the 1350A wireless firmwares. If you extract the tarball, look in the "nsp/src/cfgmgr/src/msg/scripts/" directory. The scripts show how to communicate various things to the core logic via cm_cli. I think you will find them quite straightforward to understand.

Disassembling, setting up environment for debugging, `strace -i', etc. Probably would take a considerable amount of time. :/

There are tools that you can run on your PC that will sniff all that is going on. It might not take a long time at all to see what is happening. But I say no more.

Recently, I realized someone contributed a patch (about 17 months ago) to add 802.1Q VLAN support for ADM6996M/ADM6996FC in OpenWRT.
Specifically changeset 26865
Just thought I'd mention it, in case there's interest to add/port to Routertech in a future release.

Thanks. Yes, we are aware of openwrt patches. Unfortunately, their kernel code base is different enough to make their patches of very little help to us.