libremesh / lime-packages

LibreMesh packages configuring OpenWrt for wireless mesh networking
https://libremesh.org/
GNU Affero General Public License v3.0
277 stars 96 forks source link

Include Simon's patch that fixes wifi bug in LEDE 17.01.1 #130

Closed nicopace closed 7 years ago

ilario commented 7 years ago

Eh? Link?

nicopace commented 7 years ago

I guess @p4u has more info about this

nicopace commented 7 years ago

This was part of the dump of what was the list of tasks for the librerouter project, that i loaded here

nicoechaniz commented 7 years ago

I believe this is the relevant patch: https://patchwork.kernel.org/patch/9433621/

ilario commented 7 years ago

And also these ones? http://lists.infradead.org/pipermail/lede-dev/2017-May/007738.html

p4u commented 7 years ago

It would be nice if this patch can be included on LEDE 17.01.2, let's include @dangowrt to this discussion.

dangowrt commented 7 years ago

@nicoechaniz commented:

I believe this is the relevant patch: https://patchwork.kernel.org/patch/9433621/

I can't even figure out for sure whether this or an equivalent work-around has even been applied to LEDE git HEAD. Because that would have to go first, then get some testing and then get cherry-picked into the lede-17.01 branch...

p4u commented 7 years ago

We might apply it then to lime-cooker as standalone patch snippet and see. @nicoechaniz is experiencing very serious problems on the mesh network deployed in Argentina and if that patch solves something, he will notice.

On 25/05/17 22:28, Daniel Golle wrote:

nicoechaniz commented:

I believe this is the relevant patch: https://patchwork.kernel.org/patch/9433621/

I can't even figure out for sure whether this or an equivalent work-around has even been applied to LEDE git HEAD. Because that would have to go first, then get some testing and then get cherry-picked into the lede-17.01 branch...

-- ./p4u

FreifunkUFO commented 7 years ago

is it the similiar bug/fix as mentioned here (hidden workaround script)? seems to be that "wifi-wont-work-til-a-wifi-scan"?

https://github.com/libremesh/network-profiles/blob/master/quintanalibre.org.ar/comun/usr/sbin/reset_deaf_phys.sh

FreifunkUFO commented 7 years ago

ping @simonwundlich and @ecsv

FreifunkUFO commented 7 years ago

ping @simonwunderlich

ecsv commented 7 years ago

Could be that the script is doing a similar thing. The scan will reset parts of the wifi chip state and fix the deaf state. The kernel implementation uses the RX interrupt counters instead of checking the number of associated stations. I cannot say for sure which is the better workaround.

Regarding the upstreaming of the patch(es). @nbd168 reimplemented the patch as part of https://git.lede-project.org/?p=source.git;a=commit;h=b94177e10fc72f9309eae7459c3570e5c080e960. But it was removed again in https://git.lede-project.org/?p=source.git;a=commit;h=33a840a3ff4cc15b45cf3fb47c772b5a44ecfe5c after @simonwunderlich pointed out that Felix's implementation maybe resets the chip too often.

PS: Simon's patch used 30 second check intervals. The worker for this interval was implemented in https://patchwork.kernel.org/patch/9433619/

nicoechaniz commented 7 years ago

@FreifunkUFO they are indeed the same bug.

@p4u, @dangowrt If we include this patch in a LiMe release I can test it extensively in our network where we are already logging occurrences of this bug.

FreifunkUFO commented 7 years ago

about the title of this issue: simons patch doesnt really "fix" that wifi bug, but it make it visible and "fix" it only for that moment/occurrence

FreifunkUFO commented 7 years ago

but, nice to see that MCS may produce that bug instead of ANI :-o

ilario commented 7 years ago

Can we close this issue or update the title if it's still open?