voila le dmesg


En fait faudrait voir les logs quand ca ne marche pas...

ok, donc ce serait une histoire de mauvais timing qui empecherait le port de fonctionner ? c'est bizarre que ca marche tout le temps avec le wan alors...

Regarde les timings dans le dmesg : à priori l'initialisation se fait dans l'ordre lan2, lan3, lan4, wan.
Si lan2 est limite, la probabilité que wan soit affecté par le problème est bien plus faible.

comment je vois ca sur le port wan ??

Avec les traces kernel (dmesg), ou "readlink  /sys/class/net/wan/phydev/driver".

l'installer de hurrian m'a mis un recovery en kernel 6.18, alors que le firmware de Fanboy est en 6.12 chez moi. je ne sais pas si ca a un impact...

Aucun impact (c'est une build ubi2, et la recovery ne fait rien tant qu'on ne la lance pas), le 6.18 est juste en cours de pré-intégration côté OpenWrt, mais tous les patchs des custom builds ne sont pas forcément portés.

haaa et cette fois-ci le message est différent lors du down/up:

Citer

root@OpenWrt:~# ip link set dev lan2 down
ip link set dev lan2 up
[ 1189.793746] br-lan: port 1(lan2) entered disabled state
root@OpenWrt:~# ip link set dev lan2 up
[ 1190.013459] Realtek RTL8261N mt7530_dsa-0:05: rtkphy_config_init:80 [RTL8261N/RTL8264/RTL826XB] phy_id: 0x1CCAF3 PHYAD:5
[ 1190.310214] airoha_eth 1fb50000.ethernet lan2: PHY [mt7530_dsa-0:05] driver [Realtek RTL8261N] (irq=POLL)
[ 1190.319838] airoha_eth 1fb50000.ethernet lan2: configuring for phy/usxgmii link mode

C'est peut-être aléatoire, il me semble avoir vu un bug créé côté OpenWrt pour ça.
Le driver rtl8261n est en module, alors que le driver générique est probablement built-in (dans le kernel), donc si l'initialisation se fait trop tôt (avant que le rootfs soit monté) il n'y a que le driver générique qui est présent.

au passage, j'avais oublié d'activer l'offloading dans la partie Firewall...mon speedtest était bloqué a 500Mbps...le CPU est vraiment une daube sans l'offloading c'est fou...il n'atteind meme pas 1Gbps avec ses 4 coeurs 

Si absolument aucun offloading (même pas la version software) n'est activé, ça charge beaucoup le CPU (et d'autant plus s'il y a beaucoup de règles de firewall).
Les 4 cœurs ne sont pas forcément utilisés, ça dépend des drivers et/ou paramètres, et il faut que le test soit fait avec plusieurs connexions (avec une seule, au mieux 2 cœurs pourraient être utilisés : un pour la réception et un pour l'envoi).

Vous avez-vu que Firefox intègre maintenant un VPN gratuit, qu'il est possible de le configurer pour qu'il ne fonctionne que sur des noms de domaine précis.

Dans les paramètres, c'est plutôt actif pour tous les sites web sauf exception, mais il me semble qu'ils ont prévu un mode où on pourra faire l'inverse.
Au départ, l'IP restait localisée dans le pays d'origine (tout comme Cloudflare Warp), là je viens de voir qu'on peut choisir Allemagne / Canada / Etats-Unis / France / Royaume-Uni, mais il y a une erreur de connexion.

S'ils exigent que les fournisseurs de VPN vérifient que leurs clients sont majeurs, ça risque surtout de nuire à ceux qui sont européens.
Et ensuite, l'étape suivante serait de demander aux FAI de bloquer l'accès aux VPN non-européens qui ne feraient pas la vérification d'âge, mais c'est une bataille qui risque d'être sans fin...

Même Apple commence à être affectée :

Le Mac mini d’entrée de gamme disparaît complètement, quand les autres modèles voient les délais rallonger

https://www.macg.co/mac/2026/05/le-mac-mini-dentree-de-gamme-disparait-completement-quand-les-autres-modeles-voient-les-delais-rallonger-308371

Passage de 699€ à 949€ pour la version de base.
Le MacBook Neo est affiché avec 3 semaines de livraison, et 2 mois pour le Mac Studio (la variante avec le plus de RAM étant affichée "indisponible").