Modify

Opened 6 years ago

Closed 5 years ago

Last modified 4 years ago

#10880 closed defect (wontfix)

DIR-825-Bx: Luci switch port names are wrong

Reported by: jb-debbugs@… Owned by:
Priority: normal Milestone: Chaos Calmer 15.05
Component: luci Version: 10.03.1
Keywords: switch label dir-825 Cc:

Description

According to the wiki

<http://wiki.openwrt.org/doc/techref/internal.layout>

and confirmed by experimentation, DIR-825 has physical Port 4 on rtl8366s port 0, Port 3 on port 1 etc. But the Luci interface show those labels backwards as Port 1 on port 0, Port 2 on port 1 etc. This is a bit confusing and obviously a bug.

Table for clarity:

rtl8366s port Physical label Luci wrong label
(in config/network)

port 0 Port 4 Port 1
port 1 Port 3 Port 2
port 2 Port 2 Port 3
port 3 Port 1 Port 4
port 4 (unused) (unused)
port 5 CPU CPU

Attachments (0)

Change History (10)

comment:1 Changed 6 years ago by jow

  • Resolution set to wontfix
  • Status changed from new to closed

LuCI has no concept of case labels and there is no way to programmatically retrieve the information.

comment:2 Changed 6 years ago by jb-debbugs@…

  • Resolution wontfix deleted
  • Status changed from closed to reopened

Who said anything about "case labels"?

This is about the text strings that are embedded in the LuCI UI at build time.

The current strings are correct for some devices and completely wrong for others. If it is infeasible to build that part of the UI differently for different models, at least use texts that are device neutral, such as the chip port numbers (0-based).

Mapping 0-based chip port numbers to 1-based text labels should be done correctly or not at all. The preferred solution would be to put the names in /etc/defconfig/${boardname}/network or in a general /usr/lib/luci/somedir/${boardname}/bord.lua .

But if that is too difficult, just sticking to the raw chip port numbers (0, 1, 2, 3, 4, 5) would at least make it obvious that these do not correspond directly to the physical labels that say (1, 2, 3, 4). In other words, remove the off variable in model/cbi/admin_network/vlan.lua, so all labels (except CPU) become translatef("Port %d", pt).

comment:3 Changed 6 years ago by jow

  • Resolution set to wontfix
  • Status changed from reopened to closed

Yes as you've noticed they're correct for one half and wrong for the other, making it zero based to satisfy your wishes merely reversed the situation. As the maintainer of LuCI I have no intention to change set as long as there is no board info available, sorry.

comment:4 Changed 5 years ago by bwmetcalfe+LuCI@…

  • Resolution wontfix deleted
  • Status changed from closed to reopened

Just found the similar behaviour on a TP-Link TL-WR841N/ND v8.0. The bin file:

http://downloads.openwrt.org/attitude_adjustment/12.09-beta2/ar71xx/generic/openwrt-ar71xx-generic-tl-wr841n-v8-squashfs-factory.bin

...contains a LuCI web-gui page:
/usr/lib/lua/luci/view/admin_network/switch_status.htm

...that reports the unit's switch ports in numeric order, as reported by "swconfig dev switch0 show" from function:
function switch_status(dev)

...contained in:

/usr/lib/luci/tools/status.lua

This differs from their physical position on the router's case, which confused me for a few minutes, so I hacked the switch_status.htm script as follows (alterations in bold-face):

<script type="text/javascript">//<![CDATA[
        var tb;
        var ths = document.getElementsByTagName('th');
        for (var i = 0; i < ths.length; i++)
                if (ths[i].className = 'cbi-section-table-cell' && !ths[i].innerHTML)
                {
                        ths[i].innerHTML = '<%:Port status:%>';
                        tb = ths[i].parentNode;
                        break;
                }

        if (tb)
        {
            var realPorts = ['n/a','4','1','2','3'];    //Note: This port assignment hack has been tested only 
                                                        //on TP-Link TL-WR841N/ND v8.0 International hardware.
                XHR.poll(5, '<%=luci.dispatcher.build_url("admin", "network", "switch_status", self.switch)%>', null,
                        function(x, st)
                        {
                                if (st && st.length)
                                {
                                        for (var i = 0; i < st.length; i++)
                                        {
                                                var th = tb.childNodes[i+1];

                                                if (st[i].link)
                                                {
                                                        th.innerHTML = String.format(
                                                                '<small>Case Port ' + realPorts[i] + '<br /><br /><img src="<%=resource%>/icons/port_up.png" />' +
                                                                '<br />%d<%:baseT%><br />%s</small>',
                                                                st[i].speed, st[i].duplex
                                                                        ? '<%:full-duplex%>' : '<%:half-duplex%>'
                                                        );
                                                            //alert(Object.keys(st[0]));
                                                }
                                                else
                                                {
                                                        th.innerHTML = String.format(
                                                                '<small>Case Port ' + realPorts[i] + '<br /><br /><img src="<%=resource%>/icons/port_down.png" />' +
                                                                '<br /><%:no link%></small>'
                                                        );
                                                }
                                        }
                                }
                        }
                );
        }
//]]></script>

The marked case ports map to the swconfig-reported ports as follows:

Physical ::: swconfig / LuCI

4 ::: 1
3 ::: 4
2 ::: 3
1 ::: 2

Hope this is some use. If there's a more elegant way of achieving this in the existing codebase, please let me know. (Still learning).

If not, I'd suggest letting users create a simple text config file via the LuCI gui that contains the Physical ::: swconfig / LuCI mapping, and give them a simple, easy path to upload it to a central repo.

I'd find it interesting to work this up if you think it could be of use.

-Ben.

comment:5 Changed 5 years ago by jow

  • Resolution set to wontfix
  • Status changed from reopened to closed

And as I explained multiple times already, as long as there is no way to query such information at runtime it is a wontfix. I'm not going to add huge hardware quirk lists to the code.

comment:6 Changed 5 years ago by bwmetcalfe+LuCI@…

I'm proposing a user-generated / moderated fix that adds very little to the complexity of LuCI's code, and I'm offering to script the page myself in line with whatever reasonable standards you require.

Workflow:
A user downloads an openwrt .bin file for router (as they do at the moment).
The user logs on to their router's LuCI GUI.
If the LuCI gui has no local definition text file / database entry, it searches for a database entry exactly matching the router's firmware / hardware version online, via e.g a JSON get to annoyinghardwarelayouts.openwrt.org.
If LuCI *finds a matching definition*, it gets loaded into a local definition text file / database entry (optionally prompting the user to check and confirm the downloaded defs match reality).
If LuCI *doesn't find a matching definition* in annoyinghardwarelayouts.openwrt.org, it asks the user to check the swconfig-reported port definitions against the case markings on the page, correct any mis-match, and submit the information to annoyinghardwarelayouts.openwrt.org automagically.
Moderation of existing definitions could be achieved in the same way.

The overall admin load (moderating moderations) should be small. Again; I'll help.

Think of the savings in magic markers and Dymo label tape around the world.
All the router cases that *won't* be defaced needlessly.

-Ben.

comment:7 Changed 5 years ago by jow

This proposal is kludge that doesn't solve the underlying problem. It makes more sense to embed such information in device trees, until those are implemented in ar71xx it is a wontfix.

comment:8 Changed 5 years ago by bwmetcalfe+LuCI@…

Very definitely a kludge.
However: What's the estimated timescale for implementing device trees in ar71xx, and once device trees *are* implemented, why not use the kludge-generated database to populate them? Further, use the kludge infrastructure (with a couple of trivial alterations) to moderate the accuracy of the device tree's information regarding the port layouts?

I'm assuming that for many/most cheap routers the information will *have* to be user-generated anyway; that there's no way for a chip to tell where it ports are physically located *if* such information hasn't been stored somehow by the hardware designer during manufacture?

comment:9 Changed 5 years ago by bwmetcalfe+LuCI@…

"where its ports", clrly.

comment:10 Changed 4 years ago by jow

  • Milestone changed from Backfire 10.03.2 to Chaos Calmer (trunk)

Milestone Backfire 10.03.2 deleted

Add Comment

Modify Ticket

Action
as closed .
The resolution will be deleted. Next status will be 'reopened'.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.