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
[dev] Alternative webif. LuCI + uhttpd?
- thechief
- RouterTech Team
- Posts: 12067
- Joined: Wed Feb 01, 2006 10:22 pm
- Location: England, the Centre of Africa
- Contact:
Re: [dev] Alternative webif. LuCI + uhttpd?
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.geekgirl wrote:As I recall, the webif is largely closed source. From a quick look: /usr/www/cgi-bin/(webcm|firmwarecfg)
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?geekgirl wrote:Would there be interest in the development of an alternative webif, possibly based on LuCI + uhttpd (replacing mini_httpd)?
No. What specifically are you referring to?geekgirl wrote:is there a list, or separate download, for the other non-GPL parts which are not included in the release sources?
The Chief: Be sure to read the Firmware FAQ and do a Forum Search before posting!
No support via PM. Ask all questions on the open forum.
No support via PM. Ask all questions on the open forum.
Re: [dev] Alternative webif. LuCI + uhttpd?
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
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
- RouterTech Team
- Posts: 12067
- Joined: Wed Feb 01, 2006 10:22 pm
- Location: England, the Centre of Africa
- Contact:
Re: [dev] Alternative webif. LuCI + uhttpd?
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.geekgirl wrote:I wasn't actually implying replacing cm_logic
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!
The Chief: Be sure to read the Firmware FAQ and do a Forum Search before posting!
No support via PM. Ask all questions on the open forum.
No support via PM. Ask all questions on the open forum.
Re: [dev] Alternative webif. LuCI + uhttpd?
Darn.. Is it undocumented at all? Back when I used it, I remember skimming through a pdf documenting.. cm_cli I think?thechief wrote: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.
Disassembling, setting up environment for debugging, `strace -i', etc. Probably would take a considerable amount of time. :/thechief wrote: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.
You've always been generous. Thank you.thechief wrote:I think I have given enough information for you to know whether you fancy the task!
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
- RouterTech Team
- Posts: 12067
- Joined: Wed Feb 01, 2006 10:22 pm
- Location: England, the Centre of Africa
- Contact:
Re: [dev] Alternative webif. LuCI + uhttpd?
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.geekgirl wrote:Darn.. Is it undocumented at all? Back when I used it, I remember skimming through a pdf documenting.. cm_cli I think?
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.geekgirl wrote:Disassembling, setting up environment for debugging, `strace -i', etc. Probably would take a considerable amount of time. :/
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.geekgirl wrote: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.
The Chief: Be sure to read the Firmware FAQ and do a Forum Search before posting!
No support via PM. Ask all questions on the open forum.
No support via PM. Ask all questions on the open forum.