Auteur Sujet: Dégager la freebox serveur: routeur, wifi,firewall, ... que me conseillez-vous ?  (Lu 13603 fois)

0 Membres et 1 Invité sur ce sujet

kazyor

  • Expert des Télécoms
  • Expert
  • *
  • Messages: 1 334
  • Lyon 7ème (69)
Dégager la freebox serveur: routeur, wifi,firewall, ... que me conseillez-vous ?
« Réponse #24 le: 27 février 2021 à 19:53:21 »
Pour ton problème en https, quelles sont tes règles iptables pour le NAT ?

nouknouk

  • Abonné Free fibre
  • *
  • Messages: 38
  • yutz 57
    • Wiki ma domotique
Dégager la freebox serveur: routeur, wifi,firewall, ... que me conseillez-vous ?
« Réponse #25 le: 28 février 2021 à 01:32:57 »
il semblerait que j'ai quelque chose qui fonctionne en baissant le MTU
...
- si de ton côté ça passe bien avec 1700 / 1500, dois-je en déduire que la vraie root cause serait du côté d'un second souci avec le driver de mon interface WAN (en plus de l'histoire du promiscuous mode que je dois forcer) ?

Peut-être un début d'explication:

- des users qui remontent lors de gros tranferts avec le chip ethernet du RK3399
- un workaround proposé: désactiver le checksum offload sur l'interface. Mais ça ne résout pas le souci chez moi quand je laisse le MTU de l'IPv6 à 1700.
- un peu plus de détail technique dans patch dans le kernel linux

Citer
Some rockchip SoCs like the RK3399 and RK3328 exhibit an issue
where tx checksumming does not work with packets larger than 1498.

Ceci ajouté au problème du vlan font que je me pose de plus en plus de questions concernant le bon support de linux de ce chip ethernet intégré au RK3399.  :'(
En l'état ça fonctionne bien, mais j'aime pas trop une config basée sur des workarounds, ça fait pas super propre.

Pour ton problème en https, quelles sont tes règles iptables pour le NAT ?
Elles sont strictement identiques à la config par défaut. Aucun ajout/suppression modification.
Je me trompe peut-être, mais j'imagine que si c'était un souci d'iptables ou NAT, le problème ne devrait pas disparaître pas à la deuxième tentative. Pas plus qu'en baissant le MTU ? si ?

doctorrock

  • Abonné Orange Fibre
  • *
  • Messages: 931
  • Draguignan 83
Ton souci est le syndrome d'un problème de MTU.
Tu auras le même en ouvrant un accès SSH vers un serveur, puis en téléchargeant un gros fichier. L'ouverture SSH va fonctionner, toutes les commandes qui nécessitent des "petits" paquets vont fonctionner, et dès que tu vas passer à des paquets au dessus de la MTU, ça va se figer.
Le grand classique d'un problème de MTU avec le flag IPV4 DontFragment à On (ce que SSH et TLS utilisent, justement).

Tu peux tester avec des paquets ICMP de différentes tailles voir ce qui passe, ou pas.
Simplement avec ping ou fping.
Regarde les logs de la couche réseau, le message à chercher est du genre "Fragmentation needed but DF set". C'est ICMP type 3 / code 4.

Si les paquets sont à destination de l'Internet, il doivent avoir une MTU de 1500, ni plus, ni moins.

nouknouk

  • Abonné Free fibre
  • *
  • Messages: 38
  • yutz 57
    • Wiki ma domotique
Ton souci est le syndrome d'un problème de MTU.

Merci pour ton retour.
Je penche effectivement pour un souci de MTU. Plus exactement le fait que l'augmentation de la MTU pour l'IPv6 (qui encapsule l'IPv4) ne fonctionne pas, j'imagine à cause du driver de mon interface réseau WAN (rk_gmac-dwmac fe300000.ethernet). Bien que Free l'autorise (cf. le retour d'xp de clecle26).

J'ai finalement laissé les MTU par défaut, je me retrouve avec:
- 1500 pour la MTU du canal IPv6
- 1280 (!) pour la MTU du canal 4rd (IPv4 qui est encapsulé dans les paquets IPv6).

Le tout fonctionne au poil.
SSH y compris (backups rsync toutes les nuits).

Ca fait baisser un peu les perfs. Mais bon, dans la "vraie vie", je suis loin de voir une différence au quotidien.

EDIT: merci pour le tip, je viens de tester avec un ping. Le plus gros que j'arrive à passer en IPv4 semble être 1454 bytes. Au delà, je ne reçois plus de réponse.

root@OpenWrt:~# ping -s 1446 badaboum.fr
PING badaboum.fr (5.39.38.43) 1446(1474) bytes of data.
1454 bytes from uk34907-1344.fast-mage.com (5.39.38.43): icmp_seq=1 ttl=56 time=12.8 ms

doctorrock

  • Abonné Orange Fibre
  • *
  • Messages: 931
  • Draguignan 83
Il faut utiliser ping -M do
Pour forcer le flag DF, sinon il va fragmenter

nouknouk

  • Abonné Free fibre
  • *
  • Messages: 38
  • yutz 57
    • Wiki ma domotique
pour info, j'ai fait un petit test de débit (via les infos fournies sur https://testdebit.info/), depuis une machine de mon LAN vers l'extérieur, pour tester le débit "traversant" le routeur (qui occupe donc ses deux interfaces, WAN et LAN).

J'arrive à toucher sans souci:
- le max proposé par mon abonnement Freebox Révolution en down, ici 948Mb/s
- pour l'upload: 587Mb/s atteints, soit plus que prévu par l'abonnement, donné pour 400Mb/s en up. (*)

Le tout avec mon interface WAN bancale (en promiscuous pour le VLAN Free + le MTU faiblard en IPv4).

J'ai par ailleurs acheté un OrangePi R1 Plus (à base de Rockchip 3328 ; 25€-30€ sur Aliexpress) ; moins de puissance, USB 2.0 only mais quand même deux ports ethernet Gb/s. Je tenterai le même genre de test à l'occasion.

Si les résultats - in situ - sont bons également avec le R1 plus, je pourrais bien finalement opter pour ce R1 plus comme routeur, et garder le nanopi R4S pour d'autres usages plus 'gourmands'.
L'idée est de remiser définitivement de mon serveur x86 (Celeron J4105) plus gourmand en énergie. Pour ça, le nanopi R4S a quelques atouts:
- l'USB3 (pour mettre un SSD en USB et partage NFS/SMB sur le LAN)
- plus de puissance CPU disponible pour de la détection de mouvement de mes 5 caméras domotique fullHD (via le soft 'motion').
 

(*) EDIT: non en fait, c'est parfaitement en ligne avec les débits annoncés de l'abonnement freebox révolution, qui sont passés entre temps à 1.0Gb/s down et 600Mb/s up

nouknouk

  • Abonné Free fibre
  • *
  • Messages: 38
  • yutz 57
    • Wiki ma domotique
J'ai par ailleurs acheté un OrangePi R1 Plus (à base de Rockchip 3328) ... Je tenterai le même genre de test à l'occasion.

Je me suis un peu amusé aujourdhui:
- un mini boitier conçu en 3D avec FreeCAD et imprimé total à l'arrache,
- quelques radiateurs collés
- recompilé la version modifiée par OrangePi d'OpenWrt pour le R1 plus (les saligaud, z'auraient au moins pu faire un fork propre)
- et fait quelques tests de perfs (du pur routing LAN entre les deux ports, sans VLAN, etc...)

Résultat: on est un cran en dessous du nanoPi R4S:
- en download / upload, on plafonne aux alentours de 650 - 600Mb/s, quand le R4S tient le Gb/s.
- mais conso moindre aussi pour ce R1 plus: entre 1.3Watt (idle) et 3.0Watts (transfert WAN <=> LAN) (contre 1.6Watt / 5.0Watt pour le R4S)


darkel

  • Abonné Free adsl
  • *
  • Messages: 2
  • Strasbourg 67
Bonjour ici,
Je voulais tout d'abord remercier Nouknouk pour ce partage au sujet d'OpenWRT sur nanopi r4s,
Voulant moi même remplacer ma freebox par quelque chose de moins intrusif (je n'aime pas avoir du matos "inconnu" chez moi), j'ai rapidement trouvé la référence du nanopi r4s qui est petit, dispose de 2 ports ethernets gigabit, léger en consommation et du coup ça a été le coup de foudre pour moi. C'est bien ce matos qui était voué à remplacer ma box :D Ensuite, il me fallait bien sur le software (plus la configuration) et c'est grâce à ce thread que j'ai pu arriver à mes fins.

Je tenais à l'occasion, partager mon témoignage et une petite contribution.

Au niveau Openwrt, de mon côté je me suis appuyé sur ce repository github:
https://github.com/anaelorlinski/OpenWrt-NanoPi-R2S-R4S-Builds
En ce jour du 31/01/2022, il est encore régulièrement mis à jour, la dernière release date d'il y a 2 jours.
Avec ce code, je n'ai pas eu besoin de modifier le programme map.sh, par contre j'utilise bien le paquet map d'origine qui fonctionne très bien.
J'ai la même configuration que toi, une adresse IPv6 récupéré chez free en spoofant la mac adresse de l'interface wan du nanopi et j'ai bien configuré une adresse ipv4 fullstack (que j'avais réclamé au préalable dans mon espace client free).

La release que l'on trouve dans le repo github que j'ai utilisé n'embarque pas le paquet map. Sinon, ça serait trop facile ;)
Comme moi j'ai galéré à compiler la version Openwrt dédié au nanopi r4s, je me propose de vous partager la manipulation:

Comment réaliser la compilation d'Openwrt pour le nanopi r4s avec make sous linux:
Mode recette de cuisine ON
Les grandes lignes des manipulations à effectuer sont en fait décrites dans le fichier github-action du repo, à savoir dans le répertoire .github/workflows mais n'étant pas initié à cet outil, je n'ai pas eu le reflexe d'aller visualiser le fichier (NanoPi-r2s-21.02.yml)

On commence par cloner le repo:
git clone https://github.com/anaelorlinski/OpenWrt-NanoPi-R2S-R4S-Builds.git
Puis à la racine du répertoire créé (normalement ~./OpenWrt-NanoPi-R2S-R4S-Builds/, executer les scripts:
/bin/bash ./steps/01_clone_openwrt_2102.sh
/bin/bash ./steps/01_clone_immortalwrt_2102.sh
/bin/bash ./steps/02_prepare_openwrt_folder_2102.sh
/bin/bash ./steps/r2s/03_patch_openwrt_2102.sh
/bin/bash ./steps/04-prepare_package.sh
/bin/bash ./steps/05-create_luci_acl.sh
/bin/bash ./steps/06-create_config_from_seed.sh

Après execution des scripts, vous verrez un repertoire build/ qui a été créé, à l'intérieur c'est le répertoire openwrt qui nous intéresse :
cd build/openwrt
A présent il faut modifier le menuconfig pour ajouter le paquage map :
make menuconfigDans le menu, il faut se rendre dans Network, puis descendre dans le menu jusqu'a trouver "map" et sélectionner <*> map

Avant de compiler, on télécharge toutes les dépendances :
make download -j128
find dl -size -1024c -exec ls -l {} \;
find dl -size -1024c -exec rm -f {} \;

On compile en utilisant tous les cores à disposition :
let make_process=$(nproc)+1
make -j${make_process} V=s || make -j${make_process} V=s

A la fin vous aurez un répertoire ~bin/targets/rockchip/armv8 avec normalement les fichiers issus de la compilation :-rw-r--r--. 1 rainy rainy 94968912 Jan 26 10:59 openwrt-rockchip-armv8-friendlyarm_nanopi-r2s-ext4-sysupgrade.img.gz
-rw-r--r--. 1 rainy rainy 72920701 Jan 26 11:00 openwrt-rockchip-armv8-friendlyarm_nanopi-r2s-squashfs-sysupgrade.img.gz
-rw-r--r--. 1 rainy rainy 95030406 Jan 26 10:59 openwrt-rockchip-armv8-friendlyarm_nanopi-r4s-ext4-sysupgrade.img.gz
-rw-r--r--. 1 rainy rainy 72978583 Jan 26 11:00 openwrt-rockchip-armv8-friendlyarm_nanopi-r4s-squashfs-sysupgrade.img.gz

Ensuite il n'y a plus qu'à prendre l'image qui vous intéresse (la différence entre ext4 et squashfs se situe au niveau du filesystem utilisé) et la charger dans une carte mini-sd.
Pour ce faire, personnellement j'utilise rufus sous Windows.

Comme toi Nouknouk, je suis obligé d'activer le mode promisc pour que cela fonctionne,
j'ai donc ajouté son activation au démarrage du system, dans le fichier /etc/rc.local
# Put your custom commands here that should be executed once
# the system init finished. By default this file does nothing.

ifconfig eth0 promisc

exit 0

J'en suis à moins d'une semaine d'utilisation, pour le moment tout fonctionne "comme un charme".
Le cpu ne dépasse pas 2%, la dissipation thermique entre 58.5 et 59.5, j'ai des petits heatpipe sur le cpu, la ram (j'ai la version 1gb) et une troisième composant (le gpu?) mais pas de ventilateur ni de boitier pour le moment. Je dois me rendre chez un ami pour me faire faire un boitier imprimé 3d ;) La deadline c'est le début de l'été.

Je n'ai fait aucun paramétrage pour le MTU.

Au niveau des perfs, je ne vois pas de différence avec "la box", j'arrive à faire des piques a 600mbits/s dans les deux sens. Mais j'ai remarqué que chez Free aux heures de pointes, genre vers 20h (je suis en immeuble), qu'il pouvait y a voir des baisses significatives de débit, je vais voir avec la nanopi si cela change quelque chose.

Ravi de partager cela  ;D

nouknouk

  • Abonné Free fibre
  • *
  • Messages: 38
  • yutz 57
    • Wiki ma domotique
salut,

un grand merci pour le retour d'XP.

J'ajoute deux points pour la compilation au passage.

1- ne compilez pas les sources sur un point de montage chiffré (genre votre home folder chiffré par défaut il me semble sur une ubuntu) ; vous allez finir avec des erreurs incompréhensibles, style "uglic++ compilation failed" (et perdre potentiellement bcp de temps)

2- séparer les deux make, un pour la rule download, un second ensuite pour la 'vraie' compile. Ex:
make -j13 download && make -j13 worldsi encore des erreurs de compil, essayer avec -j1 (monothread), ça peut se passer mieux.

Et tant qu'à faire, je publie l'ensemble de mes notes prises pendant mes essais, au cas où ça puisse servir: https://github.com/nouknouk/ma-domotique/wiki/remplacer-la-freebox-par-nanopi-r4s

darkel

  • Abonné Free adsl
  • *
  • Messages: 2
  • Strasbourg 67
Hello,

Je reviens sur ce thread après 2 ans d'utilisation.

Je remonte deux points :
Mon premier: souci de resolution DNS. Certains noms de domaines ne sont pas résolus. par exemple : https://www.fandom.com/
Etrangement lorsque je change ma config DNS openwrt, cela fonctionne pendant plusieurs minutes puis a nouveau cela ne fonctionne plus.
J'ai juste a cocher ou decocher cela, pour que cela fonctionne 5mn :
Network> DHCP & DNS> Advanced settings
[]Strict order
[]All Servers
[/s]
--> Problème résolu, en fait cela venait de ma configuration BANIP. Elle doit être trop stricte (j'ai laissé par défaut), et finalement je rajoute en whitelist les ip des services web qui m'intéressent.

Autre point d'attention, j'ai remarqué cette connexion permanente (ci-dessous), j'ai cru comprendre que c'etait un tunnel obligatoire jusqu'a chez Free?

Network Protocol Source Destination Transfer
IPV6 IPENCAP [2a01:XXX:XXX:XXXX:X:XXXX:XXXX:X] [2a01:e00:29:200a::fff9] 81.06 MiB (291292 Pkts.)

L'ip Source correspond à :
inet6 2a01:XXX:XXX:XXXX:X:XXXX:XXXX:X/128 scope global
link/tunnel6 2a01:XXX:XXX:XXXX:X:XXXX:XXXX:X peer 2a01:e00:29:200a::fff9

J'ai cru comprendre dans ce thread, qu'il fallait autoriser le protocole IPENCAP au niveau du firewall. Est-ce vraiment nécessaire? Je ne l'ai pas fait.
https://lafibre.info/remplacer-freebox/tuto-free-zmd-ipv4-fullstack-14-ipv4-plage-60-ipv6/24/

Bonus,
Je "m'amuse" (plutot rire jaune) de voir ma nintendo switch se connecter sur compute.amazonaws.com même quand cette dernière est en "veille". La console est systématiquement tiède. Un nouveau business model?
« Modifié: 23 janvier 2024 à 12:11:10 par darkel »

Kana-chan

  • Abonné Orange Fibre
  • *
  • Messages: 507
  • Antibes (06)
Bonus,
Je "m'amuse" (plutot rire jaune) de voir ma nintendo switch se connecter sur compute.amazonaws.com même quand cette dernière est en "veille". La console est systématiquement tiède. Un nouveau business model?
Un réchauffe-mains ?
Comme on est en hiver ... :D