<html>
<head>
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-15">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>Merci Matthieu pour ta réponse,</p>
<p>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">Tu es vraiment sur que tu vois le même bug sur 2 routeurs ? </pre>
</blockquote>
Je n'en suis pas 100% sûr, mais ce qui est sûr ce que les 2 ont
clairement une expérience utilisateur très dégradée à propos du
wifi alors qu'ils avaient aucun pb juste avant de swapper leurs
841N par les ZBT.<br>
</p>
J'ai fais des captures en suivant <a moz-do-not-send="true"
href="https://wiki.openwrt.org/doc/devel/debugging#wireless">cette
doc</a> sur le routeur chez ngz et ce dernier a rebooté alors que
j'allais lancer le scp pour ramasser le résultat (en tmpfs).
J'espère aller plus loin bientôt.
<p> Je sais aussi que ces 2 routeurs là chez moi, connecté l'un à
l'autre en 5 Ghz n'ont jamais rien perdu lors de mes tests iperf
et cie, ni rien perdu pendant mes jours d'utilisation normale
d'internet (j'avais connecté ma box aDSL sur un, mon PC fixe sur
l'autre et configuré un ZBT en AP et l'autre en STA sur le 5Ghz).<br>
</p>
<p>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">De toutes façons s'il faut un effort non négligeable pour avoir un
truc qui marche pour tout·es, c'est pas ce ZBT la solution d'avenir.</pre>
</blockquote>
Tout à fait.<br>
</p>
<p>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">Si ca ne marche que pour moi, soit on remonte les bugs à OpenWRT et on
teste les snapshots, soit on laisse béton. On ne va pas essayer de
greffer un driver non libre sur OpenWRT 18.06.</pre>
</blockquote>
Bien d'accord. J'ai manqué de donner mon cheminement de pensée.<br>
</p>
<p>Loin de moi l'idée d'essayer de maintenir un fork d'une distro ou
une verrue avec driver proprio leakés.<br>
J'ai demandé du support à ZBT et en très très résumé :<br>
L: avec OpenWRT 18.06.1 le wifi déconne pour moi<br>
Z: utilises le firmware fourni<br>
L: Oui mais non je veux imagebuilder et une release maintenue<br>
Z: tiens le lien du SDK MediaTek qu'on a utilisé<br>
L: Oui mais non j'ai besoin "maintenu", pas un .tar.gz de 2015<br>
Z: tiens le lien du SDK Mediatek le plus récent qu'on a<br>
L: #pleasewait<br>
Z: on peut faire du teamviewer<br>
L: j'ai du temps le soir mais pour vous c'est la nuit<br>
Z: un matin ? (ven 21/09)<br>
[...] A suivre :)<br>
</p>
<p>Du coup je suis parti sur l'idée mesurer un peu les différences
entre le MTK et le trunk d'OpenWRT et de grouper ça pour prendre
le risque de trouver un fix important dans 80211mac qui n'aurai
jamais eu dans le trunk OpenWRT par exemple. Ou bien trouver des
girolles, enfin, je ne savais pas trop bien.<br>
</p>
<p>Je n'ai pas croisé ça de manière évidente (mais j'ai pas tout vu
c'est sûr). Par contre j'ai vu à quel point ils avaient fait
n'importe quoi :o) Et je suis venu partager ça ici.<br>
</p>
<p>Ludo<br>
</p>
<div class="moz-cite-prefix">Le 20/09/2018 à 23:16, Matthieu Herrb a
écrit :<br>
</div>
<blockquote type="cite"
cite="mid:20180920211605.txlbd7pmmrrb7id5@nebraska.herrb.net">
<pre class="moz-quote-pre" wrap="">On Thu, Sep 20, 2018 at 10:11:09PM +0200, Ludovic Pouzenc via technique wrote:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">J'ai croisé dans un module kernel bricolé par MediaTek inclus dans les
firmware d'origine des ZBT3526, aka MTK (MediaTek SDK ?):
case TCP:
th = (struct tcphdr *)(ptr);
if ((ntohs(th->source) == 80) ||
(ntohs(th->dest) == 80) ||
(ntohs(th->source) == 5000) ||
(ntohs(th->dest) == 5000))
{
#if 0
WF_FWD_PRINT(WF_DEBUG_TRACE, ("Forward - tcp source port: %d, dest port: %d\n", ntohs(th->source), ntohs(th->dest)));
#endif
if (!WIFI_FWD_TEST_FLAG(fOP_WIFI_FWD_ACCESS_SCHED_ACTIVE))
return TRUE;
}
break;
Si le paquet matche, le forwarde directement sans passer par iptables.
Moi aussi j'aime les standards, la neutralité, les fichiers de
configuration, les <please insert whatever barely normal here>...
J'ai un peu découpé les différences entre le fork mediatek/ralink de OpenWRT
et le dépôt officiel.
C'est là : <a class="moz-txt-link-freetext" href="http://www.chd.sx/cgit/mtk-20170518/log/">http://www.chd.sx/cgit/mtk-20170518/log/</a>
A lire à jeun sous peine de gros pb de nausées.
-> les tags sont ceux du tree de OpenWRT, ne pas s'en servir. L'intérêt
c'est les commits reconstitués de la branche mtk-20170518
Ludo
PS : je tente de gratter de l'assistance à ZBT. Ils ont un ingé qui peut
peut-être aider a fixer le bug de wifi qu'on a croisé et qui semble assez
bloquant. Peut-être que je rêve un peu, mais je tente.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
Tu es vraiment sur que tu vois le même bug sur 2 routeurs ? De mon
coté j'en ai testé 2 en tant que point d'accès chez moi (18.06.1 +
kmod-nft-offload et activation dans la config) et sur les 2 le wifi
est stable : débits similaires au TP-Link 1043ND que j'avais avant pas
de trace d'erreurs dans dmesg sur 40h ou plus.
J'ai un mix d'Android, MacOS, Linux et OpenBSD comme clients, à cheval
sur les 2 bandes de fréquence et un mélange de N et de AC.
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">PS2 : je ne pense pas qu'on puisse compiler le MTK sans violer les licences
des bouts de code des drivers wifi qu'ils ont embarqué.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
De toutes façons s'il faut un effort non négligeable pour avoir un
truc qui marche pour tout·es, c'est pas ce ZBT la solution d'avenir.
Si ca ne marche que pour moi, soit on remonte les bugs à OpenWRT et on
teste les snapshots, soit on laisse béton. On ne va pas essayer de
greffer un driver non libre sur OpenWRT 18.06.
En attachment le /etc/config d'un de mes AP. Chez moi il est utilisé
uniquement en bridge (filaire sur ports jaune + wifi), le wan n'est
pas utilisé et le serveur DHCP est sur mon routeur OpenBSD.
</pre>
</blockquote>
<pre class="moz-signature" cols="72">--
Ludovic Pouzenc
<a class="moz-txt-link-abbreviated" href="http://www.pouzenc.fr">www.pouzenc.fr</a>
This is GNU/Linux land. In silent nights you can hear the Windows machines rebooting.
</pre>
</body>
</html>