[technique] ZBT, OpenWRT by Mediatek / ralink

Ludovic Pouzenc ludovic at pouzenc.fr
Sam 22 Sep 13:23:26 CEST 2018


Merci Matthieu pour ta réponse,

> Tu es vraiment sur que tu vois le même bug sur 2 routeurs ?
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.

J'ai fais des captures en suivant cette doc 
<https://wiki.openwrt.org/doc/devel/debugging#wireless> 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.

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).

> 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.
Tout à fait.

> 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.
Bien d'accord. J'ai manqué de donner mon cheminement de pensée.

Loin de moi l'idée d'essayer de maintenir un fork d'une distro ou une 
verrue avec driver proprio leakés.
J'ai demandé du support à ZBT et en très très résumé :
L: avec OpenWRT 18.06.1 le wifi déconne pour moi
Z: utilises le firmware fourni
L: Oui mais non je veux imagebuilder et une release maintenue
Z: tiens le lien du SDK MediaTek qu'on a utilisé
L: Oui mais non j'ai besoin "maintenu", pas un .tar.gz de 2015
Z: tiens le lien du SDK Mediatek le plus récent qu'on a
L: #pleasewait
Z: on peut faire du teamviewer
L: j'ai du temps le soir mais pour vous c'est la nuit
Z: un matin ? (ven 21/09)
[...] A suivre :)

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.

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.

Ludo

Le 20/09/2018 à 23:16, Matthieu Herrb a écrit :
> On Thu, Sep 20, 2018 at 10:11:09PM +0200, Ludovic Pouzenc via technique wrote:
>> 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à : http://www.chd.sx/cgit/mtk-20170518/log/
>> 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.
> 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.
>
>> 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é.
> 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.
>
>
-- 
Ludovic Pouzenc
www.pouzenc.fr

This is GNU/Linux land. In silent nights you can hear the Windows machines rebooting.

-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.tetaneutral.net/pipermail/technique/attachments/20180922/11ce1c42/attachment.htm>


Plus d'informations sur la liste de diffusion technique