Re: [OpenWrt-Devel] Link detection - TP-Link Archer C7 v2
Am 27.05.2015 um 20:57 schrieb Gert Doering: (Which is how certain commercial platforms handle this - if all L2 ports in a given VLAN go down, the L3 routing interface will also go down, and I found that usually to be what I expect and want to happen) This would totally match my usecase. I like this solution. Best Christian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Link detection - TP-Link Archer C7 v2
Am 26.05.2015 um 22:48 schrieb Richard Clark: https://dev.openwrt.org/ticket/17674 (set to closed / duplicate) but no reference Any thoughts, suggestions, or can someone give me some pointers on where I can be digging in the openwrt kernel code for where that Ethernet driver 'link status' get filled in ? ps.. This all works on a different Atheros generic device (GL-Inet), so it is TP-Link specific. Hi Richard, I had this problem a moth ago with this board: http://wiki.openwrt.org/toh/compex/wpj344 Ref: https://lists.openwrt.org/pipermail/openwrt-devel/2015-April/032786.html I found no solution so far... Best Christian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Link detection - TP-Link Archer C7 v2
Christian Mehlis christ...@m3hlis.de wrote: Am 26.05.2015 um 22:48 schrieb Richard Clark: https://dev.openwrt.org/ticket/17674 (set to closed / duplicate) but no reference Any thoughts, suggestions, or can someone give me some pointers on where I can be digging in the openwrt kernel code for where that Ethernet driver 'link status' get filled in ? ps.. This all works on a different Atheros generic device (GL-Inet), so it is TP-Link specific. You don't happen to have force_link set on the interface in question in your UCI config do you? Cheers, Karl Palsson___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Link detection - TP-Link Archer C7 v2
Hi Richard, the link status is not propagated to the netdev because there's an external switch chip between the CPU and the RJ45 plug on the outside. There currently is no mechanism to propagate switch port states to Linux netdev link states as such an mechanism has various implications. For example: consider a switch port group containing five ports, 4 external RJ45 ports and one internal connected to the SoC - when would you consider that interface down? When no port except the CPU one has a link? Whenever a cable is plugged into one of the four ports? Strictly speaking the missing link detection on wan is not a bug but by design because the link between the CPU and the switch is always established, it never goes down - its just a trace on the PCB. Currently the WAN port link state detection only works on boards that have a dedicated phy for their WAN and no intermediate programmable switch. If you would want to work on that you'd need to propagate the swconfig link state information to the connected netdev, but that already is a problem since there is no programmatic way to relate a given netdev to a switch device (e.g. is it eth0 or eth1 connected to switch0?). Such information needs to be hardcoded per model, maybe encoded in the board config code. ~ Jow ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Link detection - TP-Link Archer C7 v2
On 05/27/2015 05:31 AM, Karl Palsson wrote: You don't happen to have force_link set on the interface in question in your UCI config do you? No. It IS set on the LAN interface, but if I am reading the option correct that is to force a static assignment by netifd even if no link is detected (make sense for LAN I think). Tried it anyway by forcing it to 0 on the LAN config (was there by default install), and also added it to the WAN interface (under DHCP). No change in handling :( Since ethtool doesn't even notice the link change state I think it might be a network driver issue. Thanks, Richard ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Link detection - TP-Link Archer C7 v2
On 05/27/2015 03:59 AM, Christian Mehlis wrote: Hi Richard, I had this problem a moth ago with this board: I found no solution so far... Christian For now I have added a little script in the background that just watches for the link status using swconfig swconfig dev ag71xx-mdio.0 port 1 get link | grep -q up or swconfig dev ag71xx-mdio.0 port 1 get link | grep -q down Test the return for success/fail, then issue ifconfig eth0 up/down as appropriate, and netifd goes about doing what it should have done with the cable was yanked. Just an endless loop testing for link up first, since an extra ifconfig up on an already up IF will do nothing anyway, and I can't assume that it is going to be 'up' when the script first runs in the init process -Richard ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Link detection - TP-Link Archer C7 v2
On 05/27/2015 05:41 AM, Jo-Philipp Wich wrote: Hi Richard, the link status is not propagated to the netdev because there's an external switch chip between the CPU and the RJ45 plug on the outside. There currently is no mechanism to propagate switch port states to Linux netdev link states as such an mechanism has various implications. Ok, that makes sense. Just my dumb luck that the little portable GL-Inet I was developing on happens to not have an internal switch, so everything was fine there. So currently it looks like good chunk of routers seem to follow the same block diagram as the original WRT54g and are going to have the same issue. All the netifd handling to start/stop services on link state never gets used. I have worked around it for now by making a daemon to watch the switch status events and manually up/down the interface in userspace. Thanks for the info! -Richard ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Link detection - TP-Link Archer C7 v2
Michael Richardson m...@sandelman.ca wrote: So, just to realize that you probably want active DNA[1] anyway, as even on a device that has directly connected ports, plugging in a dumb switch will give you link, yet there is really nothing beyond it. [1]- https://tools.ietf.org/wg/dna/ Detecting Network Attachment As a dumb user, I _expect_ to get a link light when I have dumb switch connected, though I'm sure fancy network admins might like DNA. What I don't see any purpose in [1] is getting told I have link just because the non-removable cable (pcb traces) between two parts of the board inside my dumb box is in place. While I appreciate the design that makes this not working already, when there _is_ a fixed port, I _do_ expect this to work. Sincerely, Karl Palsson [1] I'm sure it's very useful for the hw eng bringing up the board mind you :)___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Link detection - TP-Link Archer C7 v2
Hi, On Wed, May 27, 2015 at 02:41:31PM +0200, Jo-Philipp Wich wrote: For example: consider a switch port group containing five ports, 4 external RJ45 ports and one internal connected to the SoC - when would you consider that interface down? When no port except the CPU one has a link? Whenever a cable is plugged into one of the four ports? I'd consider no external link at all to be sufficient criteria to signal link down internally. (Which is how certain commercial platforms handle this - if all L2 ports in a given VLAN go down, the L3 routing interface will also go down, and I found that usually to be what I expect and want to happen) Now, I'm not saying that this would be trivial to do, but tremendously useful :-) gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025g...@net.informatik.tu-muenchen.de pgpfIEgajtTyK.pgp Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Link detection - TP-Link Archer C7 v2
Richard Clark rich...@kerkhofftech.ca wrote: Hi Richard, the link status is not propagated to the netdev because there's an external switch chip between the CPU and the RJ45 plug on the outside. There currently is no mechanism to propagate switch port states to Linux netdev link states as such an mechanism has various implications. Ok, that makes sense. Just my dumb luck that the little portable GL-Inet I was developing on happens to not have an internal switch, so everything was fine there. So currently it looks like good chunk of routers seem to follow the same block diagram as the original WRT54g and are going to have the same issue. All the netifd handling to start/stop services on link state never gets used. So, just to realize that you probably want active DNA[1] anyway, as even on a device that has directly connected ports, plugging in a dumb switch will give you link, yet there is really nothing beyond it. [1]- https://tools.ietf.org/wg/dna/ Detecting Network Attachment ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Link detection - TP-Link Archer C7 v2
I am having some problems with link detection on eth0 / WAN on the TP-Link Archer C7 V2 router. Removing the network cable from the WAN port does not change the link status, so when it is added back in, various scripts never kick off to get new DHCP, restart the firewall, etc. This was on a self compiled 14.07 with various mods, but then reflashed with the stock 14.07, same effect. Pulled down and flashed with 15.05rc1 (OpenWrt Chaos Calmer 15.05-rc1 / LuCI Master (git-15.126.50380-7a54785) and still same effect. The MDIO code seems to notice the change (on 15.05, nothing on 14.07): Tue May 26 19:45:04 2015 kern.info kernel: [ 139.98] Atheros AR8216/AR8236/AR8316 ag71xx-mdio.0:00: Port 1 is down Tue May 26 19:45:28 2015 kern.info kernel: [ 163.99] Atheros AR8216/AR8236/AR8316 ag71xx-mdio.0:00: Port 1 is up This does not translate down to the link state on the device - ethtool, ifconfig, ip all continue to show the link as up. Loading up the mii module and using mii-tool works though (BB + CC): root@OpenWrt:~# mii-tool -w eth0 20:15:31 eth0: no link 20:15:37 eth0: negotiated 1000baseT-FD flow-control, link ok 20:15:50 eth0: no link 20:15:58 eth0: negotiated 1000baseT-FD flow-control, link ok Also, swconfig tracks the status proper as well (BB + CC) swconfig dev ag71xx-mdio.0 port 1 get link Looking for 'link' issues on a 'TP-Link' router is a bit challenging and have not been able to find existing bug reports other than: https://dev.openwrt.org/ticket/17674 (set to closed / duplicate) but no reference Any thoughts, suggestions, or can someone give me some pointers on where I can be digging in the openwrt kernel code for where that Ethernet driver 'link status' get filled in ? ps.. This all works on a different Atheros generic device (GL-Inet), so it is TP-Link specific. Thanks, -- Richard C ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
