The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header.
To mitigate this problem, the original message has been wrapped automatically by the mailing list software.
--- Begin Message ---Hi, > Would you provide a proper Tested-by? Sure, you can add "Tested-by: Filip Moc <[email protected]>" line as needed. > We will definitely have to use ucidef_set_led_switch here. Are you sure about > the port mask? Yes I checked. 0x2 = LAN1, 0x4 = LAN3, 0x8 = LAN2 so 0x2 | 0x4 | 0x8 = 0xE > What about the port order? Can you please verify the assignment of external > port number vs. internal ports (just stupidly connect a cable and check with > swconfig which port it is attached to)? Matches ordering above. switch0 Port 0 = SoC switch0 Port 1 = External LAN1 switch0 Port 2 = External LAN3 switch0 Port 3 = External LAN2 switch0 Port 4 = always down > Can you provide a detailed explanation of what you observe (what do you use > for visualization of "link status detection")? Simply type "ip link show dev eth0". When there is a link on any port of switch it should be UP with carrier (not saying "NO-CARRIER"). When there is no link on any external switch port it should say "NO-CARRIER". This works fine on ar71xx. On ath79 it never says "NO-CARRIER" on eth0 even when there's no cable connected to switch at all. Another way to check for carrier is "cat /sys/class/net/eth0/carrier". This is always 1 on ath79. This causes some problems such as LED not showing link status with netdev trigger and device won't behave optimally in many obvious network situations. And of course also breaks user scripts relying on eth0 link detection. Also when you're remotely troubleshooting some network issues one of first things you do after you ssh to the device is usually typing "ip a". It can save you a lot of time when you see NO-CARRIER on eth0 when it shouldn't be there. This way it's confusingly telling the opposite. > Do you refer to something specific in the boot process when you say > "unreliable boot", or is this just backed up by the observation of the > non-working LTE module? At the moment, this sounds to me like we could just > put it in "Known issues". Can you provide a short piece of text for that (to > be put in the commit message)? Sometimes after boot LTE module is not working (not visible as USB device at all). Relevant lines in dmesg: [ 5.662821] usb 1-1: new high-speed USB device number 2 using ehci-platform [ 10.884716] usb 1-1: device descriptor read/64, error -145 [ 16.244841] usb 1-1: device descriptor read/64, error -71 [ 16.574819] usb 1-1: new high-speed USB device number 3 using ehci-platform [ 21.799081] usb 1-1: device descriptor read/64, error -145 [ 27.174820] usb 1-1: device descriptor read/64, error -71 [ 27.294901] usb usb1-port1: attempt power cycle [ 28.116145] usb 1-1: new high-speed USB device number 4 using ehci-platform [ 33.574719] usb 1-1: device not accepting address 4, error -71 [ 33.724710] usb 1-1: new high-speed USB device number 5 using ehci-platform [ 39.174715] usb 1-1: device not accepting address 5, error -71 [ 39.180824] usb usb1-port1: unable to enumerate USB device Possible workaround is to check whether LTE module is available after boot. E.g. interface usb0 is present, 'adb devices' shows the device, relevant symlinks are present in /sys/bus/usb/devices/. When LTE module is not available power-cycle it. E.g by running this command: (cd /sys/class/gpio/tp-link\:power\:lte/ && echo 0 > value && sleep 1 && echo 1 > value) > Are there bug report/discussions to link? Enrico mentioned it earlier in this thread and also reported it to me few years ago (on ar71xx). He also did some research on why it does work on stock firmware. Though he didn't seem to find any obvious workaround used by stock firmware. Maybe Enrico could post his findings here. I don't recall anyone else who reported this but I doubt there won't be anyone else affected. Since I have this problem only on ath79 and Enrico has this problem also on ar71xx it is also possible that there are in fact two different problems. > And does the device have a MAC address printed on it? I would assume the one > from WiFi? wlan0 has exact match with mac address printed on the label. eth0 is -1 and eth1 is +1 relative to wlan0. Filip On Thu, Jan 16, 2020 at 12:25:58PM +0100, Adrian Schmutzler wrote: > Hi, > > thanks for your feedback. > > I currently consider merging this (considering your reply on my questions > below) and would include the few minor remaining issues as "Known issues" in > the commit message. > > Would you provide a proper Tested-by? > > > -----Original Message----- > > From: Filip Moc [mailto:[email protected]] > > Sent: Donnerstag, 16. Januar 2020 09:31 > > To: [email protected] > > Cc: 'Enrico Mioso' <[email protected]>; [email protected] > > Subject: Re: [OpenWrt-Devel] [PATCH] ath79: add support for TP-Link > > TL-MR6400 > > > > Hi Adrian, > > > > thanks a lot for patch. > > > > I tested it on current trunk (bda6b6144d) and I can confirm that: > > 1. Works as expected, LTE can be turned off/on and value works as expected > > (0=off,1=on). > > 2. Works as expected. LTE module's httpd is started after boot and LTE > > module's > > web interface is available. > > 3. Seems to be working just fine. eth0 is still connected to switch (ports > > LAN1 to > > LAN3) while eth1 is connected to LAN4/WAN. > > What about the port order? Can you please verify the assignment of external > port number vs. internal ports (just stupidly connect a cable and check with > swconfig which port it is attached to)? > > > 4. Interfaces are working just fine. Except for obvious problem with eth0 > > which > > has no link status detection. > > Can you provide a detailed explanation of what you observe (what do you use > for visualization of "link status detection")? > > > 5. Seems to be working just right. Even LAN LED turns off when I manually > > set > > eth0 interface down from shell. > > > > I also tested buttons which still work fine. > > > > Problem with link detection on eth0 which always reports interface as UP > > with > > carrier even when there's nothing connected to switch remains unresolved. > > I'd be willing to help with link detection but there already seems to be > > some > > specific solution expected and I don't know what exactly is the expected > > way to > > solve it. > > So far ucidef_set_led_switch with port mask 0x0E can at least be used as a > > workaround to make LAN LED show link detection on LAN ports (though this > > also > > has negative impact on link activity visualisation). > > We will definitely have to use ucidef_set_led_switch here. Are you sure about > the port mask? > > I will update my staging tree with the current value. > > > > > Also the problem with unreliable boot causing LTE module to not always work > > after boot is still present. This can be workarounded by turning LTE module > > off > > and on again. I don't have this problem on ar71xx where LTE module always > > realiably works just fine after boot. Though Enrico reported that he has > > this > > problem even on ar71xx. > > Do you refer to something specific in the boot process when you say > "unreliable boot", or is this just backed up by the observation of the > non-working LTE module? At the moment, this sounds to me like we could just > put it in "Known issues". Can you provide a short piece of text for that (to > be put in the commit message)? Are there bug report/discussions to link? > > Best > > Adrian > > > > > Anyway good progress, thanks for your work. > > > > Filip > > > > > > On Mon, Jan 06, 2020 at 01:23:22AM +0100, [email protected] wrote: > > > Hi Enrico, > > > > > > > -----Original Message----- > > > > From: Enrico Mioso [mailto:[email protected]] > > > > Sent: Dienstag, 17. September 2019 19:59 > > > > To: [email protected] > > > > Cc: Filip Moc <[email protected]>; [email protected] > > > > Subject: RE: [OpenWrt-Devel] [PATCH] ath79: add support for TP-Link TL- > > > > MR6400 > > > > > > > > Thanks! I'll take a look now. > > > > Still, something should be interestingly wrong here: > > > > > > > > root@OpenWrt:/# swconfig dev switch0 show|grep -i link > > > > link: port:0 link:up speed:1000baseT full-duplex txflow rxflow > > > > link: port:1 link:up speed:100baseT full-duplex auto > > > > link: port:2 link:down > > > > link: port:3 link:down > > > > link: port:4 link:down > > > > root@OpenWrt:/# > > > > > > I've just unearthed this topic in my mailbox and tried a port myself > > > based on > > your V2 patch. > > > > > > You will find the updated version in a branch of my staging repo here: > > > > > https://git.openwrt.org/?p=openwrt/staging/adrian.git;a=shortlog;h=refs/heads > > /mr6400 > > > > > > (Most recent patch there.) > > > > > > Despite several minor issues (sorting, rebase, etc.) I've also addressed > > > the > > following major issues: > > > 1. Use gpio-export again instead of gpio-hog, so LTE can be switched > > > on/off > > > 2. Added adb-enablemodem > > > 3. Removed the phy-swap in DTS. This is not present in the mach-file for > > mr6400, only in the one for the fritzbox 4020 you took as blueprint. > > > 4. Adjusted ports 2 vs. 3 in 02_network based on your assessment. This > > > will > > most probably be wrong again now, as this might be influenced by the > > phy-swap. > > > 5. LAN/WAN LEDs still won't work properly, as at least one will need to be > > changed to ucidef_set_led_switch, and I cannot check that without the > > device. > > > > > > Best > > > > > > Adrian > >
--- End Message ---
_______________________________________________ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
