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 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. 4. Interfaces are working just fine. Except for obvious problem with eth0 which has no 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). 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. 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
