Re: [OpenWrt-Devel] Link detection - TP-Link Archer C7 v2

2015-05-27 Thread Christian Mehlis
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.

Re: [OpenWrt-Devel] Link detection - TP-Link Archer C7 v2

2015-05-27 Thread Karl Palsson
Michael Richardson 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 N

Re: [OpenWrt-Devel] Link detection - TP-Link Archer C7 v2

2015-05-27 Thread Michael Richardson
Richard Clark 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 >> netd

Re: [OpenWrt-Devel] Link detection - TP-Link Archer C7 v2

2015-05-27 Thread Gert Doering
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? Whene

Re: [OpenWrt-Devel] Link detection - TP-Link Archer C7 v2

2015-05-27 Thread Richard Clark
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 s

Re: [OpenWrt-Devel] Link detection - TP-Link Archer C7 v2

2015-05-27 Thread Richard Clark
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 p

Re: [OpenWrt-Devel] Link detection - TP-Link Archer C7 v2

2015-05-27 Thread Richard Clark
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 (ma

Re: [OpenWrt-Devel] Link detection - TP-Link Archer C7 v2

2015-05-27 Thread Jo-Philipp Wich
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 exa

Re: [OpenWrt-Devel] Link detection - TP-Link Archer C7 v2

2015-05-27 Thread Karl Palsson
Christian Mehlis 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 wh

Re: [OpenWrt-Devel] Link detection - TP-Link Archer C7 v2

2015-05-27 Thread Christian Mehlis
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 fi

[OpenWrt-Devel] Link detection - TP-Link Archer C7 v2

2015-05-26 Thread Richard Clark
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