Re: [OpenWrt-Devel] Moving the mailing lists

2018-05-26 Thread Daniel F. Dickinson 

On 2018-05-26 05:17 AM, Bjørn Mork wrote:

"Daniel F. Dickinson"  writes:


1) How many people have their own mail server and can do *server-side*
mail filtering


You do not need your own mail server to do server-side
filtering.  Any mail service worth caring about will offer some sort of
end user configurable server-side filter.  Mail is pretty useless
without it.



Sadly finding decently priced mail hosting for my particular needs has 
been a challenge.  It's proven to be better to host my own than to try 
and find a for-fee service that does what I want.


Google is not too helpful for that search from when I tried.

Anyway I realized it's irrelevant because there are the forums and the 
ability to do GitHub PR's so there really shouldn't be an issue with 
folks needing the list who can't filter on List-Id server-side.


Regards,

Daniel


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
http://lists.infradead.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] mvebu: fix broken console on WRT32X (venom)

2018-05-26 Thread Michael Gray 
On 25 May 2018 at 03:40, Michael Gray 
wrote:
> The console bootarg is being corrupted on boot, causing various issues
including broken sysupgrade.
> Utilising the bootargs mangle patch from other targets, hardcode the
console arguments and fetch the rootfs from the bootloader.
>
> Kernel command line: console=ttyS0,115200 root=/dev/mtdblock8
>
> Bootloader command line (ignored): console= root=/dev/mtdblock8
>
> Please cherry pick to 18.06 too

Community have flagged this as broken on devices that aren't Venom.
Investigating further. Please hold fire on this one for now.

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
http://lists.infradead.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCHv2] ramips: Use generic board detect for GnuBee devices

2018-05-26 Thread Rosen Penev 
This is a port of an old commit from mkresin's tree:

09260cdf3e9332978c2a474a58e93a6f2b55f4a8

This has the potential to break sysupgrade but it should be fine as
there is no stable release of LEDE or OpenWrt that support these devices.

Signed-off-by: Rosen Penev 
---
v2: Change the GB-PC1 stuff only.
 target/linux/ramips/base-files/etc/board.d/01_leds | 2 +-
 target/linux/ramips/base-files/etc/board.d/02_network  | 2 +-
 target/linux/ramips/base-files/etc/diag.sh | 2 +-
 target/linux/ramips/base-files/lib/ramips.sh   | 3 ---
 target/linux/ramips/base-files/lib/upgrade/platform.sh | 2 +-
 target/linux/ramips/image/mt7621.mk| 4 ++--
 6 files changed, 6 insertions(+), 9 deletions(-)

diff --git a/target/linux/ramips/base-files/etc/board.d/01_leds 
b/target/linux/ramips/base-files/etc/board.d/01_leds
index 88e4c2b7fe..ae5ac77b5e 100755
--- a/target/linux/ramips/base-files/etc/board.d/01_leds
+++ b/target/linux/ramips/base-files/etc/board.d/01_leds
@@ -196,7 +196,7 @@ fonera20n)
set_usb_led "$boardname:orange:usb"
set_wifi_led "$boardname:orange:wifi"
;;
-gb-pc1|\
+gnubee,gb-pc1|\
 gnubee,gb-pc2)
ucidef_set_led_switch "lan1" "lan1" "$boardname:green:lan1" "switch0" 
"0x01"
ucidef_set_led_switch "lan2" "lan2" "$boardname:green:lan2" "switch0" 
"0x10"
diff --git a/target/linux/ramips/base-files/etc/board.d/02_network 
b/target/linux/ramips/base-files/etc/board.d/02_network
index 3fc5e55df1..3a744bda0c 100755
--- a/target/linux/ramips/base-files/etc/board.d/02_network
+++ b/target/linux/ramips/base-files/etc/board.d/02_network
@@ -228,7 +228,7 @@ ramips_setup_interfaces()
ucidef_add_switch "switch0" \
"1:lan:4" "2:lan:3" "3:lan:2" "4:lan:1" "0:wan" "6@eth0"
;;
-   gb-pc1|\
+   gnubee,gb-pc1|\
gnubee,gb-pc2)
ucidef_add_switch "switch0" \
"0:lan" "4:lan" "6@eth0"
diff --git a/target/linux/ramips/base-files/etc/diag.sh 
b/target/linux/ramips/base-files/etc/diag.sh
index 6a51778726..b4118358b4 100644
--- a/target/linux/ramips/base-files/etc/diag.sh
+++ b/target/linux/ramips/base-files/etc/diag.sh
@@ -95,7 +95,7 @@ get_status_led() {
dir-620-d1|\
dwr-512-b|\
dlink,dwr-116-a1|\
-   gb-pc1|\
+   gnubee,gb-pc1|\
gnubee,gb-pc2|\
hpm|\
hw550-3g|\
diff --git a/target/linux/ramips/base-files/lib/ramips.sh 
b/target/linux/ramips/base-files/lib/ramips.sh
index edccfcd4a8..5741cbd2ee 100755
--- a/target/linux/ramips/base-files/lib/ramips.sh
+++ b/target/linux/ramips/base-files/lib/ramips.sh
@@ -205,9 +205,6 @@ ramips_board_detect() {
*"FreeStation5")
name="freestation5"
;;
-   *"GB-PC1")
-   name="gb-pc1"
-   ;;
*"GL-MT300A")
name="gl-mt300a"
;;
diff --git a/target/linux/ramips/base-files/lib/upgrade/platform.sh 
b/target/linux/ramips/base-files/lib/upgrade/platform.sh
index 7aa14770ca..95cb7c33a9 100755
--- a/target/linux/ramips/base-files/lib/upgrade/platform.sh
+++ b/target/linux/ramips/base-files/lib/upgrade/platform.sh
@@ -62,7 +62,7 @@ platform_check_image() {
firewrt|\
fonera20n|\
freestation5|\
-   gb-pc1|\
+   gnubee,gb-pc1|\
gnubee,gb-pc2|\
gl-mt300a|\
gl-mt300n|\
diff --git a/target/linux/ramips/image/mt7621.mk 
b/target/linux/ramips/image/mt7621.mk
index b84b74a5b0..b20f35976b 100644
--- a/target/linux/ramips/image/mt7621.mk
+++ b/target/linux/ramips/image/mt7621.mk
@@ -83,13 +83,13 @@ define Device/firewrt
 endef
 TARGET_DEVICES += firewrt
 
-define Device/gb-pc1
+define Device/gnubee_gb-pc1
   DTS := GB-PC1
   DEVICE_TITLE := GnuBee Personal Cloud One
   DEVICE_PACKAGES := kmod-ata-core kmod-ata-ahci kmod-usb3 kmod-sdhci-mt7620
   IMAGE_SIZE := $(ralink_default_fw_size_32M)
 endef
-TARGET_DEVICES += gb-pc1
+TARGET_DEVICES += gnubee_gb-pc1
 
 define Device/gnubee_gb-pc2
   DTS := GB-PC2
-- 
2.17.0


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
http://lists.infradead.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] RT5350F WiFi interface performance issue

2018-05-26 Thread Zoltan Gyarmati 

On 27.05.2018 01:26, Koen Vandeputte wrote:



On 27-05-18 01:08, Zoltan Gyarmati wrote:

On 27.05.2018 00:29, Koen Vandeputte wrote::07, Zoltan Gyarmati wrote:

Dear Koen

On 25.05.2018 14:33, Zoltan Gyarmati wrote:

On 25.05.2018 14:03, Koen Vandeputte wrote:



On 2018-05-25 13:30, Zoltan Gyarmati wrote:

Dear All,

 I'm testing the current OpenWrt  (master/HEAD) on RT5350F 
Olinuxino. Unfortunately the WiFi interface doesn't seem to work 
properly in client mode. `iwinfo wlan0 scan` runs successfully 
and shows my AP, but when i configure the interface as client 
and try to connect, the authentication seems to be successful 
(according to dmesg), but the wlan0 interface never gets IP 
address, even if i explicitly call udhcpc. If i set a static IP 
address for wlan0, and ping my AP, i have around 88% packet 
loss. There is no any relevant message in dmesg which could give 
a hint about the reason.


As a counter-check, i flashed the an old OpenWrt image from the 
HW vendor with kernel 3.18, and with that one the WiFi interface 
works properly.
Does anyone else experience similar issues (either on this or 
any other RT5350F board)? Do you have any advice what to look 
into to sort this out?



Thanks,



Hi,

When you build master, did it already contain commit "hostapd: 
update to git HEAD of 2018-05-21, allow build against wolfssl" ?
Could you also try to build the 18.06 which does not contain this 
one and compare?


You never know..


No, it didn't have that commit yet. Now i build an image with this 
new hostapd version and  I'll report. Thanks for the hint!


It's the same behavior with the newer hostapd version as well. It 
seems I'll have to look into how to debug WiFi performance issues...



Hi Zoltan,

When the issue appears, could you run following commands please and 
share the output?




My untrained eyes didn't spot anything unusual, but here are the 
outputs:

- iw phy0 info

https://pastebin.com/2hQ5wbng



- iw wlan0 info

https://pastebin.com/NPZZ1dBL



- iwinfo

https://pastebin.com/RHuJuYYu



- dmesg (just to be sure)

https://pastebin.com/1kTUY9t4



Thanks for the dumps.

Well, thanks for looking into this!

I see you are connected using channel 13 and HT40, but channel 12 and 
channel 14 next to it are marked as "No IR"


Could you try 1 more thing please?
Please put the AP manually on channel 1 and retry.

Just tried it, no change...

In the meantime i also tried with an other AP, without security enabled, 
but got the same behavior.





Thanks,

Koen





Thanks,

Koen







Koen

[1] 
https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=69f544937f8498e856690f9809a016f0d7f5f68b








Regards,

Zoltan Gyarmati
https://zgyarmati.de






Zoltan Gyarmati
https://zgyarmati.de






Zoltan Gyarmati
https://zgyarmati.de


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
http://lists.infradead.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] RT5350F WiFi interface performance issue

2018-05-26 Thread Koen Vandeputte 



On 27-05-18 01:08, Zoltan Gyarmati wrote:

On 27.05.2018 00:29, Koen Vandeputte wrote::07, Zoltan Gyarmati wrote:

Dear Koen

On 25.05.2018 14:33, Zoltan Gyarmati wrote:

On 25.05.2018 14:03, Koen Vandeputte wrote:



On 2018-05-25 13:30, Zoltan Gyarmati wrote:

Dear All,

 I'm testing the current OpenWrt  (master/HEAD) on RT5350F 
Olinuxino. Unfortunately the WiFi interface doesn't seem to work 
properly in client mode. `iwinfo wlan0 scan` runs successfully 
and shows my AP, but when i configure the interface as client and 
try to connect, the authentication seems to be successful 
(according to dmesg), but the wlan0 interface never gets IP 
address, even if i explicitly call udhcpc. If i set a static IP 
address for wlan0, and ping my AP, i have around 88% packet loss. 
There is no any relevant message in dmesg which could give a hint 
about the reason.


As a counter-check, i flashed the an old OpenWrt image from the 
HW vendor with kernel 3.18, and with that one the WiFi interface 
works properly.
Does anyone else experience similar issues (either on this or any 
other RT5350F board)? Do you have any advice what to look into to 
sort this out?



Thanks,



Hi,

When you build master, did it already contain commit "hostapd: 
update to git HEAD of 2018-05-21, allow build against wolfssl" ?
Could you also try to build the 18.06 which does not contain this 
one and compare?


You never know..


No, it didn't have that commit yet. Now i build an image with this 
new hostapd version and  I'll report. Thanks for the hint!


It's the same behavior with the newer hostapd version as well. It 
seems I'll have to look into how to debug WiFi performance issues...



Hi Zoltan,

When the issue appears, could you run following commands please and 
share the output?




My untrained eyes didn't spot anything unusual, but here are the outputs:

- iw phy0 info

https://pastebin.com/2hQ5wbng



- iw wlan0 info

https://pastebin.com/NPZZ1dBL



- iwinfo

https://pastebin.com/RHuJuYYu



- dmesg (just to be sure)

https://pastebin.com/1kTUY9t4



Thanks for the dumps.
I see you are connected using channel 13 and HT40, but channel 12 and 
channel 14 next to it are marked as "No IR"


Could you try 1 more thing please?
Please put the AP manually on channel 1 and retry.

Thanks,

Koen





Thanks,

Koen







Koen

[1] 
https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=69f544937f8498e856690f9809a016f0d7f5f68b








Regards,

Zoltan Gyarmati
https://zgyarmati.de






Zoltan Gyarmati
https://zgyarmati.de




___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
http://lists.infradead.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] RT5350F WiFi interface performance issue

2018-05-26 Thread Zoltan Gyarmati 

On 27.05.2018 00:29, Koen Vandeputte wrote::07, Zoltan Gyarmati wrote:

Dear Koen

On 25.05.2018 14:33, Zoltan Gyarmati wrote:

On 25.05.2018 14:03, Koen Vandeputte wrote:



On 2018-05-25 13:30, Zoltan Gyarmati wrote:

Dear All,

 I'm testing the current OpenWrt  (master/HEAD) on RT5350F 
Olinuxino. Unfortunately the WiFi interface doesn't seem to work 
properly in client mode. `iwinfo wlan0 scan` runs successfully and 
shows my AP, but when i configure the interface as client and try 
to connect, the authentication seems to be successful (according 
to dmesg), but the wlan0 interface never gets IP address, even if 
i explicitly call udhcpc. If i set a static IP address for wlan0, 
and ping my AP, i have around 88% packet loss. There is no any 
relevant message in dmesg which could give a hint about the reason.


As a counter-check, i flashed the an old OpenWrt image from the HW 
vendor with kernel 3.18, and with that one the WiFi interface 
works properly.
Does anyone else experience similar issues (either on this or any 
other RT5350F board)? Do you have any advice what to look into to 
sort this out?



Thanks,



Hi,

When you build master, did it already contain commit "hostapd: 
update to git HEAD of 2018-05-21, allow build against wolfssl" ?
Could you also try to build the 18.06 which does not contain this 
one and compare?


You never know..


No, it didn't have that commit yet. Now i build an image with this 
new hostapd version and  I'll report. Thanks for the hint!


It's the same behavior with the newer hostapd version as well. It 
seems I'll have to look into how to debug WiFi performance issues...



Hi Zoltan,

When the issue appears, could you run following commands please and 
share the output?




My untrained eyes didn't spot anything unusual, but here are the outputs:

- iw phy0 info

https://pastebin.com/2hQ5wbng



- iw wlan0 info

https://pastebin.com/NPZZ1dBL



- iwinfo

https://pastebin.com/RHuJuYYu



- dmesg (just to be sure)

https://pastebin.com/1kTUY9t4






Thanks,

Koen







Koen

[1] 
https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=69f544937f8498e856690f9809a016f0d7f5f68b








Regards,

Zoltan Gyarmati
https://zgyarmati.de






Zoltan Gyarmati
https://zgyarmati.de


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
http://lists.infradead.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] RT5350F WiFi interface performance issue

2018-05-26 Thread Koen Vandeputte 



On 27-05-18 00:07, Zoltan Gyarmati wrote:

Dear Koen

On 25.05.2018 14:33, Zoltan Gyarmati wrote:

On 25.05.2018 14:03, Koen Vandeputte wrote:



On 2018-05-25 13:30, Zoltan Gyarmati wrote:

Dear All,

 I'm testing the current OpenWrt  (master/HEAD) on RT5350F 
Olinuxino. Unfortunately the WiFi interface doesn't seem to work 
properly in client mode. `iwinfo wlan0 scan` runs successfully and 
shows my AP, but when i configure the interface as client and try 
to connect, the authentication seems to be successful (according to 
dmesg), but the wlan0 interface never gets IP address, even if i 
explicitly call udhcpc. If i set a static IP address for wlan0, and 
ping my AP, i have around 88% packet loss. There is no any relevant 
message in dmesg which could give a hint about the reason.


As a counter-check, i flashed the an old OpenWrt image from the HW 
vendor with kernel 3.18, and with that one the WiFi interface works 
properly.
Does anyone else experience similar issues (either on this or any 
other RT5350F board)? Do you have any advice what to look into to 
sort this out?



Thanks,



Hi,

When you build master, did it already contain commit "hostapd: 
update to git HEAD of 2018-05-21, allow build against wolfssl" ?
Could you also try to build the 18.06 which does not contain this 
one and compare?


You never know..


No, it didn't have that commit yet. Now i build an image with this 
new hostapd version and  I'll report. Thanks for the hint!


It's the same behavior with the newer hostapd version as well. It 
seems I'll have to look into how to debug WiFi performance issues...



Hi Zoltan,

When the issue appears, could you run following commands please and 
share the output?


- iw phy0 info
- iw wlan0 info
- iwinfo
- dmesg (just to be sure)



Thanks,

Koen







Koen

[1] 
https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=69f544937f8498e856690f9809a016f0d7f5f68b








Regards,

Zoltan Gyarmati
https://zgyarmati.de




___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
http://lists.infradead.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] RT5350F WiFi interface performance issue

2018-05-26 Thread Zoltan Gyarmati 

Dear Koen

On 25.05.2018 14:33, Zoltan Gyarmati wrote:

On 25.05.2018 14:03, Koen Vandeputte wrote:



On 2018-05-25 13:30, Zoltan Gyarmati wrote:

Dear All,

 I'm testing the current OpenWrt  (master/HEAD) on RT5350F 
Olinuxino. Unfortunately the WiFi interface doesn't seem to work 
properly in client mode. `iwinfo wlan0 scan` runs successfully and 
shows my AP, but when i configure the interface as client and try to 
connect, the authentication seems to be successful (according to 
dmesg), but the wlan0 interface never gets IP address, even if i 
explicitly call udhcpc. If i set a static IP address for wlan0, and 
ping my AP, i have around 88% packet loss. There is no any relevant 
message in dmesg which could give a hint about the reason.


As a counter-check, i flashed the an old OpenWrt image from the HW 
vendor with kernel 3.18, and with that one the WiFi interface works 
properly.
Does anyone else experience similar issues (either on this or any 
other RT5350F board)? Do you have any advice what to look into to 
sort this out?



Thanks,



Hi,

When you build master, did it already contain commit "hostapd: update 
to git HEAD of 2018-05-21, allow build against wolfssl" ?
Could you also try to build the 18.06 which does not contain this one 
and compare?


You never know..


No, it didn't have that commit yet. Now i build an image with this new 
hostapd version and  I'll report. Thanks for the hint!


It's the same behavior with the newer hostapd version as well. It seems 
I'll have to look into how to debug WiFi performance issues...








Koen

[1] 
https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=69f544937f8498e856690f9809a016f0d7f5f68b








Regards,

Zoltan Gyarmati
https://zgyarmati.de


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
http://lists.infradead.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] wifi dropouts; regression since 2015 still not fixed

2018-05-26 Thread Luke Dashjr 
On Saturday 26 May 2018 17:11:56 you wrote:
> On Sat, May 26, 2018 at 12:34:30PM +, Luke Dashjr wrote:
> > Half a year ago, I went to the trouble to identify the exact cause of the
> > regression since 2015 where Openwrt/LEDE would drop off wifi every few
> > hours:
> >
> > https://bugs.openwrt.org/index.php?do=details_id=1180
> >
> > There's even a clear and obvious solution: just remove the broken patch.
>
> Thank you for bringing this up. I haven't been aware of the ticket on
> the bugtracker and can confirm this or a very similar problem on all
> ath9k devices.
> So do I get right that you can also confirm the problem exists and have
> tried significantly hard to make sure that removing patch
> 355-ath9k-limit-retries-for-powersave-response-frames.patch
> and/or completely disabling power-management resolves it?
> If so, please share in more detail what exactly you have tested, on
> which exact hardware and in which way(s) you can reproduce that the
> problem does exist for sure or doesn't exist for sure.

My personal setup for testing is as follows:

Two Nest thermostats, which upon connecting to my network, I shut off the 
NestLabs application (which sets up the wifi, among the thermostats' primary 
controls) and launch my own (which doesn't handle wifi). The relevance of 
these is limited only to detecting the bad wifi conditions - they could 
presumably be replaced with any other device that connects once and does not 
reconnect when the network fails.

Buffalo WZR-600DHP router. Until 6 months ago, I ran Attitude Adjustment for 
years with no issues. Due to exploits (I forget which), I tried upgrading to 
LEDE, and found the wifi would drop out after a few hours. I tolerated this 
problem for a few weeks before going to the effort to do an exhaustive git 
bisect, building new firmware images to try after confirming stability for a 
few days (or instability usually within a day).

Last November, after isolating the problematic commit to 
b30e092de65ca7be7cb277f934016484137d924c, and the problematic patch to (at 
the time) 305-ath9k-limit-retries-for-powersave-response-frames.patch, I 
checked out 6b6578feec74dfe1f5767c573d75ba08cc57c885 (HEAD of the lede-17.01 
branch at the time, I believe) and created the following patch:

--- 
a/package/kernel/mac80211/patches/305-ath9k-limit-retries-for-powersave-response-frames.patch
+++ 
b/package/kernel/mac80211/patches/305-ath9k-limit-retries-for-powersave-response-frames.patch
@@ -20,7 +20,7 @@ Signed-off-by: Felix Fietkau 
 -struct ath_buf *bf)
 +struct ath_buf *bf, bool ps)
  {
-+  struct ieee80211_tx_info *info = IEEE80211_SKB_CB(bf->bf_mpdu);
++  struct ieee80211_tx_info *info = IEEE80211_SKB_CB(bf->bf_mpdu); 
ps=false;
 +
 +  if (ps) {
 +  /* Clear the first rate to avoid using a sample rate for PS 
frames */

I ran this build on my router from November until February. In February, I 
merged it into 92ea65b36aa783f28accd01fa4850f3640d2c6b6 and upgraded my 
router, and have been running that ever since.

I can't say wifi has been 100% reliable since November, but drop-outs are 
maybe monthly instead of every few hours.

> > Yet still it's been 6 months with nothing done... not even an
> > acknowledgement that the bug report was seen by a human.
>
> Probably due to the bug description which makes it look like if it was
> a device-specific problem and you could only reproduce it on those
> specific Buffalo boxes...

Don't have anything else to test on :)

> > I even emailed nbd (who added the broken patch) back in November, and
> > heard nothing back from him either.
> >
> > Is Openwrt even being maintained at this point? Has everyone moved on to
> > yet another project or something?
>
> nah. LEDE has merged back with OpenWrt, as you can see in the git
> history, we have been very active in the recent past and a new release
> is coming up very soon (18.06). It's kinda true that currently nobody
> feels too responsible for ath9k, because most people developing code
> for new hardware have moved on to mt76, ath10k and so on.
> I agree that this is not a very desirable situation and as a community-
> driven project with most contributions being unpaid for, there is not
> much we can do about it. In that sense, you just did something valuable
> by bringing up the culprit patch responsible for all our ath9k problems
> and hopefully someone with that hardware around will find the time to
> come up with a good solution.

Somewhat off-topic, but... is there any company today that financially 
supports the work/development of Openwrt? As noticed, my router is a bit out 
of date, and when I upgrade, I'd prefer to support a company that supports 
the free software firmware community. :)

Luke

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
http://lists.infradead.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] wifi dropouts; regression since 2015 still not fixed

2018-05-26 Thread Daniel Golle 
Hi Luke,

On Sat, May 26, 2018 at 12:34:30PM +, Luke Dashjr wrote:
> Half a year ago, I went to the trouble to identify the exact cause of the 
> regression since 2015 where Openwrt/LEDE would drop off wifi every few hours:
> 
> https://bugs.openwrt.org/index.php?do=details_id=1180
> 
> There's even a clear and obvious solution: just remove the broken patch.

Thank you for bringing this up. I haven't been aware of the ticket on
the bugtracker and can confirm this or a very similar problem on all
ath9k devices.
So do I get right that you can also confirm the problem exists and have
tried significantly hard to make sure that removing patch
355-ath9k-limit-retries-for-powersave-response-frames.patch
and/or completely disabling power-management resolves it?
If so, please share in more detail what exactly you have tested, on
which exact hardware and in which way(s) you can reproduce that the
problem does exist for sure or doesn't exist for sure.

> 
> Yet still it's been 6 months with nothing done... not even an acknowledgement 
> that the bug report was seen by a human.

Probably due to the bug description which makes it look like if it was
a device-specific problem and you could only reproduce it on those
specific Buffalo boxes...

> 
> I even emailed nbd (who added the broken patch) back in November, and heard 
> nothing back from him either.
> 
> Is Openwrt even being maintained at this point? Has everyone moved on to yet 
> another project or something?

nah. LEDE has merged back with OpenWrt, as you can see in the git
history, we have been very active in the recent past and a new release
is coming up very soon (18.06). It's kinda true that currently nobody
feels too responsible for ath9k, because most people developing code
for new hardware have moved on to mt76, ath10k and so on.
I agree that this is not a very desirable situation and as a community-
driven project with most contributions being unpaid for, there is not
much we can do about it. In that sense, you just did something valuable
by bringing up the culprit patch responsible for all our ath9k problems
and hopefully someone with that hardware around will find the time to
come up with a good solution.


Cheers


Daniel

> 
> Luke
> 
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> http://lists.infradead.org/mailman/listinfo/openwrt-devel

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
http://lists.infradead.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] wifi dropouts; regression since 2015 still not fixed

2018-05-26 Thread Luke Dashjr 
Half a year ago, I went to the trouble to identify the exact cause of the 
regression since 2015 where Openwrt/LEDE would drop off wifi every few hours:

https://bugs.openwrt.org/index.php?do=details_id=1180

There's even a clear and obvious solution: just remove the broken patch.

Yet still it's been 6 months with nothing done... not even an acknowledgement 
that the bug report was seen by a human.

I even emailed nbd (who added the broken patch) back in November, and heard 
nothing back from him either.

Is Openwrt even being maintained at this point? Has everyone moved on to yet 
another project or something?

Luke

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
http://lists.infradead.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Bug: HW Flow Offload + Wireguard Bug

2018-05-26 Thread Lucian Cristian 

On 22.05.2018 13:53, Jaap Buurman wrote:

Dear Felix & others,

I am currently running a 18.06 snapshot image to start testing the
stability of the firmware and new features, including the lovely
hardware flow offload. While it is working extremely well (I am
finally able to max out my connection, but with hardly any CPU load!),
pushing data through Wireguard instantly crashes my router whenever hw
flow offload is enabled. There is another report of this issue on the
forum, including a call trace:
https://forum.lede-project.org/t/netfilter-flow-offload-hw-nat/10237/44?u=mushoz

If you need any additional information or require my help testing,
please do not hesitate to contact me.

Yours sincerely,

Jaap Buurman

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
http://lists.infradead.org/mailman/listinfo/openwrt-devel


but did you tried on wireguard mailinglist ?

Jason usually tries to fix all the scenarios


Regards


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
http://lists.infradead.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Moving the mailing lists

2018-05-26 Thread Bjørn Mork 
"Daniel F. Dickinson"  writes:

> 1) How many people have their own mail server and can do *server-side*
> mail filtering

You do not need your own mail server to do server-side
filtering.  Any mail service worth caring about will offer some sort of
end user configurable server-side filter.  Mail is pretty useless
without it.


Bjørn

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
http://lists.infradead.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] 18.06 Bug: Baby Jumbo Frames on mt7621

2018-05-26 Thread Kristian Evensen 
Hi,

(Accidentally hit send)

On Fri, May 25, 2018 at 7:06 PM, Kristian Evensen
 wrote:
>> I know how to fix the issue by recovery, however, from the responses
>> in the topic on the Lede forum it seems more people are running into
>> this issue. This definitely needs to be fixed before a 18.06 release.
>> Is there someone with a mt7621 device that can reproduce the problem,
>> and that has serial access? We might be able to figure out what is
>> going wrong.

I kept looking into this and instrumented /lib/upgrade/stage2. I added
some output showing which processes were left for each iteration of
the loop, as well as when "Failed to kill ..." hits. It seems that
hostapd, for some reason, takes unexpectedly long to die:

Sending TERM to remaining processes ... loop limit 10
logd
rpcd
netifd
odhcpd
crond
ntpd
nginx
nginx
ubusd
dnsmasq
sh
sh
sh
sshd
sleep
sh
hostapd
hostapd
rsync
ssh
sleep

[  115.583843] device wlan0 left promiscuous mode
[  115.588436] br-lan: port 3(wlan0) entered disabled state
[  115.594261] device wlan1 left promiscuous mode
[  115.598798] br-lan: port 2(wlan1) entered disabled state
Sending KILL to remaining processes ... loop limit 10
hostapd
loop limit 9
hostapd
loop limit 8
hostapd
loop limit 7
hostapd
loop limit 6
hostapd
loop limit 5
hostapd
loop limit 4
hostapd
loop limit 3
hostapd
loop limit 2
hostapd
loop limit 1

Failed to kill all processes.
  PID USER   VSZ STAT COMMAND
1 root   992 S/sbin/upgraded /tmp/firmware.bin . /lib/functions.sh
2 root 0 SW   [kthreadd]
3 root 0 IW   [kworker/0:0]
4 root 0 IW<  [kworker/0:0H]
5 root 0 IW   [kworker/u8:0]
6 root 0 IW<  [mm_percpu_wq]
7 root 0 SW   [ksoftirqd/0]
8 root 0 IW   [rcu_sched]
9 root 0 IW   [rcu_bh]
   10 root 0 SW   [migration/0]
   11 root 0 SW   [cpuhp/0]
   12 root 0 SW   [cpuhp/1]
   13 root 0 SW   [migration/1]
   14 root 0 SW   [ksoftirqd/1]
   15 root 0 IW   [kworker/1:0]
   16 root 0 IW<  [kworker/1:0H]
   17 root 0 SW   [cpuhp/2]
   18 root 0 SW   [migration/2]
   19 root 0 SW   [ksoftirqd/2]
   20 root 0 IW   [kworker/2:0]
   21 root 0 IW<  [kworker/2:0H]
   22 root 0 SW   [cpuhp/3]
   23 root 0 SW   [migration/3]
   24 root 0 SW   [ksoftirqd/3]
   25 root 0 IW   [kworker/3:0]
   26 root 0 IW<  [kworker/3:0H]
   27 root 0 IW   [kworker/u8:1]
   34 root 0 IW   [kworker/u8:2]
   65 root 0 IW   [kworker/0:1]
   66 root 0 IW   [kworker/3:1]
   67 root 0 IW   [kworker/2:1]
  136 root 0 IW   [kworker/1:1]
  137 root 0 SW   [oom_reaper]
  138 root 0 IW<  [writeback]
  140 root 0 IW<  [crypto]
  142 root 0 IW<  [kblockd]
  157 root 0 IW   [kworker/u8:3]
  177 root 0 IW<  [watchdogd]
  201 root 0 SW   [kswapd0]
  233 root 0 IW<  [pencrypt]
  262 root 0 IW<  [pdecrypt]
  295 root 0 SW   [spi0]
  353 root 0 IW<  [ipv6_addrconf]
  362 root 0 IW<  [kworker/1:1H]
  363 root 0 IW<  [kworker/0:1H]
  365 root 0 IW<  [kworker/3:1H]
  366 root 0 IW<  [kworker/2:1H]
  416 root 0 IW   [kworker/1:2]
  417 root 0 IW   [kworker/0:2]
  457 root 0 SWN  [jffs2_gcd_mtd6]
  575 root 0 IW   [kworker/2:2]
  869 root 0 IW<  [cfg80211]
 1842 root 0 IW   [kworker/3:2]
 7535 root  1328 S/bin/sh /lib/upgrade/stage2 /tmp/firmware.bin . /lib
 7547 root  1184 R/bin/ps
sysupgrade abort[  124.152193] reboot: Restarting system
ed with return code: 256

With a working update, KILL usually looks like this:
Sending KILL to remaining processes ... loop limit 10
hostapd
hostapd
celerway_wd
loop limit 9
hostapd
hostapd
loop limit 8
hostapd
hostapd
loop limit 7
hostapd
hostapd
loop limit 6
hostapd
hostapd
loop limit 5
hostapd
hostapd
loop limit 4
hostapd
loop limit 3

BR,
Kristian

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
http://lists.infradead.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] 18.06 Bug: Baby Jumbo Frames on mt7621

2018-05-26 Thread Kristian Evensen 
Hi,

On Fri, May 25, 2018 at 7:06 PM, Kristian Evensen
 wrote:
>> I know how to fix the issue by recovery, however, from the responses
>> in the topic on the Lede forum it seems more people are running into
>> this issue. This definitely needs to be fixed before a 18.06 release.
>> Is there someone with a mt7621 device that can reproduce the problem,
>> and that has serial access? We might be able to figure out what is
>> going wrong.

I kept looking into this and instrumented /lib/upgrade/stage2. I added
some output showing which processes were left for each iteration of
the loop, as well as when "Failed to kill ..." hits. It seems that
hostapd, for some time, takes unexpectedly long to close:

Sending TERM to remaining processes ... loop limit 10
logd
rpcd
netifd
odhcpd
crond
ntpd
nginx
nginx
ubusd
dnsmasq
sh
sh
sh
sshd
sleep
sh
hostapd
hostapd
rsync
ssh
sleep

[  115.583843] device wlan0 left promiscuous mode
[  115.588436] br-lan: port 3(wlan0) entered disabled state
[  115.594261] device wlan1 left promiscuous mode
[  115.598798] br-lan: port 2(wlan1) entered disabled state
Sending KILL to remaining processes ... loop limit 10
hostapd
loop limit 9
hostapd
loop limit 8
hostapd
loop limit 7
hostapd
loop limit 6
hostapd
loop limit 5
hostapd
loop limit 4
hostapd
loop limit 3
hostapd
loop limit 2
hostapd
loop limit 1

Failed to kill all processes.
  PID USER   VSZ STAT COMMAND
1 root   992 S/sbin/upgraded /tmp/firmware.bin . /lib/functions.sh
2 root 0 SW   [kthreadd]
3 root 0 IW   [kworker/0:0]
4 root 0 IW<  [kworker/0:0H]
5 root 0 IW   [kworker/u8:0]
6 root 0 IW<  [mm_percpu_wq]
7 root 0 SW   [ksoftirqd/0]
8 root 0 IW   [rcu_sched]
9 root 0 IW   [rcu_bh]
   10 root 0 SW   [migration/0]
   11 root 0 SW   [cpuhp/0]
   12 root 0 SW   [cpuhp/1]
   13 root 0 SW   [migration/1]
   14 root 0 SW   [ksoftirqd/1]
   15 root 0 IW   [kworker/1:0]
   16 root 0 IW<  [kworker/1:0H]
   17 root 0 SW   [cpuhp/2]
   18 root 0 SW   [migration/2]
   19 root 0 SW   [ksoftirqd/2]
   20 root 0 IW   [kworker/2:0]
   21 root 0 IW<  [kworker/2:0H]
   22 root 0 SW   [cpuhp/3]
   23 root 0 SW   [migration/3]
   24 root 0 SW   [ksoftirqd/3]
   25 root 0 IW   [kworker/3:0]
   26 root 0 IW<  [kworker/3:0H]
   27 root 0 IW   [kworker/u8:1]
   34 root 0 IW   [kworker/u8:2]
   65 root 0 IW   [kworker/0:1]
   66 root 0 IW   [kworker/3:1]
   67 root 0 IW   [kworker/2:1]
  136 root 0 IW   [kworker/1:1]
  137 root 0 SW   [oom_reaper]
  138 root 0 IW<  [writeback]
  140 root 0 IW<  [crypto]
  142 root 0 IW<  [kblockd]
  157 root 0 IW   [kworker/u8:3]
  177 root 0 IW<  [watchdogd]
  201 root 0 SW   [kswapd0]
  233 root 0 IW<  [pencrypt]
  262 root 0 IW<  [pdecrypt]
  295 root 0 SW   [spi0]
  353 root 0 IW<  [ipv6_addrconf]
  362 root 0 IW<  [kworker/1:1H]
  363 root 0 IW<  [kworker/0:1H]
  365 root 0 IW<  [kworker/3:1H]
  366 root 0 IW<  [kworker/2:1H]
  416 root 0 IW   [kworker/1:2]
  417 root 0 IW   [kworker/0:2]
  457 root 0 SWN  [jffs2_gcd_mtd6]
  575 root 0 IW   [kworker/2:2]
  869 root 0 IW<  [cfg80211]
 1842 root 0 IW   [kworker/3:2]
 7535 root  1328 S/bin/sh /lib/upgrade/stage2 /tmp/firmware.bin . /lib
 7547 root  1184 R/bin/ps
sysupgrade abort[  124.152193] reboot: Restarting system
ed with return code: 256

With a working update, KILL usually looks like this:


BR,
Kristian

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
http://lists.infradead.org/mailman/listinfo/openwrt-devel