La Fibre
Datacenter et équipements réseaux => Équipements réseaux => 
Matériel informatique (réseaux domestiques) => Discussion démarrée par: nouknouk le 27 septembre 2020 à 11:28:20
-
Bonjour,
J'aimerais vos conseils sur une évolution de mon réseau domestique et les possibilités qui me seraient offertes.
ce que j'ai actuellement:
J'ai une petite installation réseau à la maison.
Le détail est dispo dans mon wiki (https://github.com/nouknouk/ma-domotique/wiki/armoire-r%C3%A9seau (https://github.com/nouknouk/ma-domotique/wiki/armoire-r%C3%A9seau)), ça se résume globalement à:
- une freebox revolution server, dans une zone fibrée par Orange, avec un ONT séparé.
- un switch 16 ports manageable, TP-Link TL-SG1016DE
- un serveur (celeron J4105) qui sert essentiellement de serveur 'nas/àtoutfaire' (debian, what else)
- un second serveur qui sert de box domotique home made (debian, forever)
Tout ça dans une armoire réseau avec onduleur, et différents équipements connectés dont certains alimentés en PoE passif (caméras, AP WiFi, ...)
+ un point d'accès WiFi (Xiaomi Mi router 3), déporté au milieu de la maison ; il expose actuellement deux réseaux WiFi: un pour la domotique (N), l'autre pour les utilisation domestiques (AC): smartphones, laptop, ...
+ différents équipements, connectés en filaire (desktops, tv android), et en WiFi (laptops, smartphones, 1 cam sur 5, des ESP32 utilisés pour de la domotique, ...)
Tout ce qui concerne l'accès WAN, le DHCP, le routing, etc... est actuellement géré par la freebox serveur.
ce que je voudrais:
Avant tout supprimer complètement la freebox révolution serveur (le player étant déjà retourné dans son carton).
et puis:
- rendre étanche les deux sous-réseaux: domotique (critique en cas de piratage) vs. domestique (smartphones, laptops, ...) à quelques exceptions près, bien scopées. VLANs ?
- exposer un troisième réseau Wifi, dédié à l'accès au net pour les enfants (avec protections parentales, ...)
- garder un accès VPN à mon/mes réseaux internes depuis l'extérieur (actuellement la fbx serveur s'en charge + openVPN)
- quelque chose de suffisamment puissant pour ne pas brider les debits (accès au WAN à 1Gb notamment)
- minimiser la conso électrique de l'ensemble (c'est une des raisons de l'envie de dégager la freebox serveur)
quelles options pour mon projet ?
Actuellement, je vois plusieurs solutions 'high level', à affiner par la suite:
1. réutiliser mon serveur 'nas/àtoutfaire' comme point central du réseau, pour gérer l'accès au WAN, VPN, firewall, routing, controle parental, ...
=> J'aime pas trop cette approche SPOF: si ce serveur tombe, tout tombe dans la maison.
2. un troisième mini-serveur dédié à ces tâches ?
=> quelle config nécessaire pour toutes ces fonctionnalités (dont VPN,firewall, routing, ...), le Gb du WAN
=> quelle consommation électrique ?
=> quels efforts de setup + maintenance ?
3. un routeur dédié ?
=> un truc avec une cage SFP intégrée pour dégager l'ONT au passage ?
=> j'ai lu des noms: Netgear MS510TX, Microtik RB4011iGS+RM, franchement, je suis paumé.
=> avec suffisamment de port il pourrait même venir en remplacement de mon switch actuel ?
=> quelle consommation électrique ?
4. remplacer mon AP WiFi par un vrai routeur Wifi, pour assurer à la fois le WiFi et tout le reste (firewall, routing, ...)
=> Cet équipement, critique, serait quand même déporté physiquement de mon armoire réseau :-\
=> Je veux de l'open et du bidouillable, openWrt ?
=> quelle conso ?
=> quels modèles ?
en bonus: remplacer ma fbx révo par une freebox pop server ?
=> je reste dépendant de Free
=> je m'asseois sur le routing avancé, firewall, etc...
=> mais facilité de setup/maintenance ++ ?
=> quelle conso elle fait, la pop server ?
Voilà, beaucoup plus de questions que de réponses à mon niveau ; si vous avez des conseils, je suis preneur ;D
Merci d'avance.
-
J'aime pas trop cette approche SPOF: si ce serveur tombe, tout tombe dans la maison.
D'un côté, si ta box tombe aujourd'hui, plus rien ne fonctionne non plus ?
J'aurais quelque chose de similaire à faire, je partirai sur l'option 2. Serveur que tu mets en DMZ et qui potentiellement sera le premier et seul à bouffer.
Tu as pas mal de posts au sujet du remplacement de l'ONT par un routeur avec le SFP à l'intérieur. Globalement, ça semble plus ou moins compliqué en fonction du type de fibre que tu as. Tu as déjà gratté la dessus ?
-
salut,
tout d'abord merci pour ta réponse.
D'un côté, si ta box tombe aujourd'hui, plus rien ne fonctionne non plus ?
L'accès WAN, le DHCP, oui.
Mais le réseau local + le WiFi continue de fonctionner à peu près normalement (je pense).
La solution finale sera sûrement un 'SPOF': je ne vais pas dédoubler pour un risque finalement très faible (combinaison de "le routeur tombe + je suis physiquement loin de mon domicile pour intervenir").
je partirai sur l'option 2. Serveur que tu mets en DMZ et qui potentiellement sera le premier et seul à bouffer.
Mais il faut que ça marche en permanence "hors panne matérielle" ; c'est pourquoi j'aime moins l'option 'vrai serveur'. Car un serveur c'est un truc qu'on installe, qu'on update, etc... bref qu'on maintient ; un truc qui -par expérience- a plus de downtime qu'une boite dédiée, style un switch, un routeur
Et c'est plus complexe, plus la 'surface d'attaque / de failure' est grande. Exemples:
- c'est la raison qui a fait que j'ai dédoublé mes deux serveurs (un mini pour la domotique, uptime max, un autre pour 'le reste', qui aurait pourtant pu assumer les deux d'un coup)
- pour l'asservissement de la sirène de mon alarme: un arduino plutôt qu'un relais branché sur mon serveur domotique: un serveur peut planter (et laisser la sirène allumée 24h/24 pendant une semaine ? :'( ), un arduino, plus basique, beaucoup moins de chances.
Tu as pas mal de posts au sujet du remplacement de l'ONT par un routeur avec le SFP à l'intérieur. ça semble plus ou moins compliqué en fonction du type de fibre que tu as. Tu as déjà gratté la dessus ?
J'ai juste commencé à regarder ; j'y ai compris que ma situation (ZMD, fibrée par orange, ONT séparé) n'est pas forcément la même qu'une ligne FTTH fibrée par Free. (et que je suis même pas sûr que je pourrais facilement extraire le SFP de l'ONT fourni par Free pour le mettre dans un routeur perso).
Maintenant, j'ai une grosse somme de choses à apprendre ; je le ferai, mais c'est l'objet de ce thread: commencer par cibler la/les solutions potentielles pour éviter de me perdre d'emblée.
A ce propos, j'ai encore vu une solution supplémentaire, intermédiaire entre le serveur et le routeur 'acheté tout fait': le Banana PI R64 (https://www.minimachines.net/actu/banana-pi-bpi-r64-81820), pour une solution 'home made' (sur openWrt ?)
-
Quelques mois plus tard,
- j'ai acheté un TPLink MC220L pour connecter l'ONT de mon abonnement free fibre (ZMD 10G EPON) en direct
- vers un futur routeur à base de NanoPi R4S (https://wiki.friendlyarm.com/wiki/index.php/NanoPi_R4S) + OpenWrt.
Ce que j'ai fait pour le moment:
1- j'ai compris que chez Free on est soit:
* dans une situation Free fibre en ZMD (mon cas), on a une connectivité IPv6 de base + encapsulation des paquets IPv4 dans l'IPv6 = 4rd.
* soit avec un setup 'inverse' en ZTD (pas mon cas): une connectivité IPv4 de base + encapsulation des paquets IPv6 dans l'IPv4 = 6rd (?)
2- j'ai découvert OpenWrt avec l'image FriendlyWrt proposée sur friendlyarm.com (https://wiki.friendlyarm.com/wiki/index.php/NanoPi_R4S#Work_with_FriendlyWrt)
3- j'ai lu avec attention le post ici-même de clecle26 (https://lafibre.info/remplacer-freebox/tuto-free-zmd-ipv4-fullstack-14-ipv4-plage-60-ipv6/msg839336/#msg839336) (merci à lui) pour un setup openWrt sans freebox, avec une IP (full stack) + 0.25 IP
* + l'article de son blog: https://liberty.noknow.ovh/article/NoBox-Free (https://liberty.noknow.ovh/article/NoBox-Free)
* perso, mon objectif n'est d'avoir que l'IP full-stack, ça me suffira
3b- même lecture attentive du tuto pour Ubuquity: Tuto: Remplacer sa freebox (non Delta) par un routeur Ubiquiti en ZMD (10G-EPON) (https://lafibre.info/remplacer-freebox/tuto-remplacer-sa-freebox-par-un-routeur-ubuiquity-en-zmd-10g-epon/)
4- j'ai compris qu'il me faudrait comme infos:
* mon IPv4 full stack (visible dans l'interface "mafreebox.freebox.fr > Etat de la box" et/ou dans mon compte abonné sur free.fr)
* de mon adresse MAC ; pas trouvé d'étiquette sur ma freebox, la seule que je connaisse est celle visible dans l'interface "mafreebox.freebox.fr > Etat de la box" (F4:CA:XX:XX:XX:XX)
* de mon prefixe IPv6 (2a01:xxxx:xx:xxxx::/64)
* d'une IP locale, forgée avec mon préfixe IPv6 + suffixe ":0:ffff:ffff:0"
* l'IPv6 du border router côté free ? il vaut apparemment toujours "2a01:e00:29:200a::fffd"
5- pour OpenWrt, j'ai compris qu'il me faudrait installer le package 'map' pour le 4rd (besoin only pour l'IPv4 ou pour l'IPv6 aussi ?)
* or l'image FriendlyWrt fournie ne contient pas les dépendance nécessaires => besoin de compiler mon propre OpenWrt.
* sur le forum OpenWrt le 'work in progress' pour le support du NanoPi R4S dans OpenWrt (https://forum.openwrt.org/t/nanopi-r4s-rk3399-4g-is-a-great-new-openwrt-device/79143)
7- j'ai buildé mon image openWrt pour le NanoPI R4S
* le fork d'openWrt incluant le WiP pour le NanoPi R4S: https://github.com/1715173329/openwrt-official/tree/nanopi-r4s (https://github.com/1715173329/openwrt-official/tree/nanopi-r4s) (en attente de PR)
* j'ai donc compilé mon image et je l'ai installée sur mon nanoPi R4S, en incluant le packet "Network ---> map"
* (pas bloquant mais) il faudra que je "use r8168-8.048.03 realtek kernel module(much better than r8169)" + repo GitHub pour le module kernel openwrt-r8168 (https://github.com/BROBIRD/openwrt-r8168),
=> je ne sais pas encore comment on intègre ça au moment du build (si quelqu'un a un tuto / l'explication, je prends).
* j'ai fait un premier setup de base pour mon LAN (= remplacer le DHCPv4 fourni jusqu'ici par la freebox server par celui sur l'interface lan de mon openWrt)
8- j'ai fait une première tentative de setup du wan juste pour l'IPv6 déjà
* j'ai compris que côté wan, il faudrait passer par le VLAN 836
* il me faudrait donc définir une nouvelle interface eth0.836 et la mettre en 'client DHCPv6'
* pour que la requête DHCP soit acceptée, besoin de MAC spoofing avec la MAC de la freebox ci-dessus
MAIS ma config ne marche pas en l'état :'( (EDIT: ça a changé, cf ci-après)
- je vois quelques paquets RX et TX dans LuCi, et un root@openwrt:~# ping6 google.com plante.
- le tuto de clecle26 parle de modifier dans /etc/config/network une "config switch_vlan" existante mais la section 'switch_vlan' n'existe pas du tout chez moi ; la page 'Switch' dans LuCi non plus
=> est-ce parce que je n'ai pas un "VLAN-enabled switch hardware" (https://openwrt.org/docs/guide-user/network/vlan/switch_configuration#creating_driver-level_vlans) ?
=> si je définis simplement mon interface en "eth0.836", ça devrait passer crème ? Quelque chose dans ce style ?
config interface 'wan6'
option ifname 'eth0.836'
option proto 'dhcpv6'
option reqprefix 'auto'
option reqaddress 'try'
option macaddr 'F4:CA:XX:XX:XX:XX'
option mtu '1700'
list dns '2001:4860:4860::8888'
option peerdns '0'
=> avec quoi en plus / en moins ?
=> on est d'accord qu'au stade 'stack IPv6 only', on n'a pas (encore) besoin de 'map', qui sert à l'encapsulation IPv4 dans IPv6 (4rd) ? EDIT: oui
=> suis-je censé renseigner où l'IPv6 du border router côté free ? où ça ? EDIT: non, pas besoin
=> suis-je censé renseigner quelque part mon IPv6 locale, forgée avec mon préfixe IPv6 + suffixe ":0:ffff:ffff:0" ? EDIT: non, pas besoin
Bref, beaucoup d'interrogations à ce stade, je suis un peu paumé, toute aide serait la bienvenue.
-
Quelques compléments d'infos:
- les logs me ressortent ça lors d'un restart de wan6:
root@OpenWrt:~# logread
Sun Feb 21 18:28:57 2021 daemon.notice netifd: Interface 'wan6' is now down
Sun Feb 21 18:28:57 2021 daemon.notice netifd: Interface 'wan6' is disabled
Sun Feb 21 18:28:57 2021 kern.info kernel: [ 2489.045174] rk_gmac-dwmac fe300000.ethernet eth0: PHY [stmmac-0:01] driver [RTL8211E Gigabit Ethernet]
Sun Feb 21 18:28:57 2021 kern.info kernel: [ 2489.058499] rk_gmac-dwmac fe300000.ethernet eth0: No Safety Features support found
Sun Feb 21 18:28:57 2021 kern.warn kernel: [ 2489.059196] rk_gmac-dwmac fe300000.ethernet eth0: PTP not supported by HW
Sun Feb 21 18:28:57 2021 kern.info kernel: [ 2489.059810] rk_gmac-dwmac fe300000.ethernet eth0: configuring for phy/rgmii link mode
Sun Feb 21 18:28:57 2021 daemon.notice netifd: Interface 'wan6' is enabled
Sun Feb 21 18:29:00 2021 kern.info kernel: [ 2492.464898] rk_gmac-dwmac fe300000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx
Sun Feb 21 18:29:00 2021 kern.info kernel: [ 2492.465738] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
Sun Feb 21 18:29:00 2021 daemon.notice netifd: Network device 'eth0' link is up
Sun Feb 21 18:29:00 2021 daemon.notice netifd: VLAN 'eth0.836' link is up
Sun Feb 21 18:29:00 2021 daemon.notice netifd: Interface 'wan6' has link connectivity
Sun Feb 21 18:29:00 2021 daemon.notice netifd: Interface 'wan6' is setting up now
Sun Feb 21 18:29:00 2021 kern.info kernel: [ 2492.467137] IPv6: ADDRCONF(NETDEV_CHANGE): eth0.836: link becomes ready
Sun Feb 21 18:29:00 2021 daemon.err odhcp6c[5786]: Failed to send RS (Address not available)
Sun Feb 21 18:29:00 2021 daemon.err odhcp6c[5786]: Failed to send SOLICIT message to ff02::1:2 (Address not available)
Sun Feb 21 18:29:01 2021 daemon.debug dnsmasq[1819]: listening on eth0.836(#15): fe80::f6ca:e5ff:fexx:xxxx%eth0.836 port 53
Sun Feb 21 18:29:02 2021 daemon.debug dnsmasq[1819]: listening on eth0(#2): fe80::691:62ff:fexx:xxxx%eth0 port 53
Niveau interface, j'ai le mac spoofing qui semble ok pour eth0.836, et le link local créé:
root@OpenWrt:~# ip address show eth0.836
9: eth0.836@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000
link/ether f4:ca:e5:xx:xx:xx brd ff:ff:ff:ff:ff:ff
inet6 fe80::f6ca:e5ff:fexx:xxxx/64 scope link
valid_lft forever preferred_lft forever
côté eth0 (sans vlan), je récupère la MAC d'origine de l'interface du R4S, ce qui me semble logique:
root@OpenWrt:~# ip address show eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
link/ether 04:91:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
inet6 fe80::691:62ff:fexx:xxxx/64 scope link
valid_lft forever preferred_lft forever
Après un restart, j'ai quelques paquets échangés dans les deux sens sur l'interface wan6:
- RX: 6 pkts
- TX: 22 pkts
-
Bon ... ça marche maintenant ... mais je ne sais pas pourquoi ;D
J'ai fini par recompiler une nouvelle image incluant tcpdump pour faire du wireshark en remote ssh (depuis mon desktop).
Je lance alors une session wireshark, et là surprise: je vois plein de traffic !
Un refresh de la page LuCi lus tard, et à ma grande surprise: wan6 a enfin attrappé une IPv6 et j'ai mes deux nouvelles interfaces de map:
- WAN6_4_ (eth0.836)
- WAN6_4 (map-wan6_4) qui a attrappé une IPv4 'shared' 91.161.x.y
Il semblerait que l'activation du mode promiscuous quand je lance la session wireshark soit à l'origine de la solution.
Quelques tests plus tard, et effectivement: il me suffit d'activer le promiscuous sur eth0 pour que tout démarre comme par magie:
root@OpenWrt:~# ifconfig eth0 promisc
J'ai trouvé sur le forum d'openWrt un post relatant le même problème, sans qu'aucune explication ni solution ne soit fournie: IPv6 works only with wan in promiscuous mode (https://forum.openwrt.org/t/ipv6-works-only-with-wan-in-promiscuous-mode/490/6)
Bref, j'ai une connectivité IPv6 + IPv4 (partagée) qui fonctionne, je ne sais pas vraiment ni pourquoi ni comment.
Le souci initial serait-il dû à un problème de driver (cf. le "use r8168-8.048.03 realtek kernel module(much better than r8169)" de mon post précédent) ?
Un premier bench avec ce NanoPI R4S + un iperf3 donne:
iperf3 -c ping6.online.net -p 5200 -i 0 -t 60
Connecting to host ping6.online.net, port 5200
[ 5] local 2a01:e0a:69:xxxx:xxxx:xxxx:xxxx:xxxx port 48306 connected to 2001:bc8:1::40 port 5200
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-60.00 sec 2.90 GBytes 415 Mbits/sec 290 453 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-60.00 sec 2.90 GBytes 415 Mbits/sec 290 sender
[ 5] 0.00-60.00 sec 2.89 GBytes 414 Mbits/sec receiver
Sur les 6 cores du Rockchip 3399, les n°5 et 6 (les deux seuls à monter en charge) se stabilisaient aux alentours de 50% pour le premier, 55% pour le second.
-
Salut,
J’arrive trop tard de toute évidence, mais pour le VLAN: je sais pas le pourquoi du comment exactement, mais le VLAN logiciel n’est pas toujours présent par défaut. Je sais pas si c’est un paquet ou une dépendance à installer, mais elle n’est pas sur toutes les configurations même les « stock » du site Openwrt. :'(
C’est d’ailleurs pour cela que je suis allé chercher une ROM modifiée de la Xiaomi Mi 4A, car par défaut il n’y avait pas de VLAN sur la ROM stock. :-\
Tu as finalement réussi à accrocher l’IP full-stack?
-
merci pour ton feedback.
J’arrive trop tard de toute évidence, mais pour le VLAN: je sais pas le pourquoi du comment exactement, mais le VLAN logiciel n’est pas toujours présent par défaut.
Ma compréhension de l'histoire du switch_vlan (en tant que noob) semble bien reliée aux capacités du hardware sous jacent: certains matériels intègrent du hardware capable de jouer le rôle de switch entre différents ports physiques ; cela sans doute pour décharger le CPU principal de cette charge de travail (et donc avoir un routeur avec un CPU minuscule capable pourtant de switcher du Gb/s).
J'imagine que ce genre de 'switch' hardware se trouve dans du matos 'spécialisé' pour gérer du trafic réseau (un routeur/AP WiFi, genre le Xiaomi). (*)
Dans ce cas de 'switching géré en hardware', il faut bien informer le hard sous-jacent que tel ou tel port doit tagger/détagger tel ou tel VLAN, d'où, j'imagine, la config additionnelle que tu présentes dans ton billet. Dans mon cas, avec le nanoPI, on est plutôt sur du hardware type 'ordi à vocation généraliste', donc sans ce genre de switching hardwareintégré.
Et donc avec mon nanopi, je n'ai pas eu ce besoin de configurer un 'switch hardware' qui n'existe pas ; eth0.836 dans mon wan6 + mon firmware compilé avec 'map' inclus ont suffit pour faire fonctionner l'IPv6 + l'IPv4 partagée (modulo mon souci de promiscuous mode à set manuellement).
Tu as finalement réussi à accrocher l’IP full-stack?
J'ai fait une première tentative avec le patch de map.sh que tu as partagé (seconde version, pour la full stack only = celle qui fait un 'exit 1' sur le cas "::ffff")
J'ai manifestement un souci avec cette config: le CPU est à 30% en IDLE (<1% normalement) et j'ai eu la vague impression en faisant un htop que le script map.sh était ré-exécuté sans cesse.
Un rapide bench m'a alors confirmé qu'il y avait un souci, avec un download intermittent, et <3Mb/s de débit (là où j'ai 500Mb/s avec l'IP partagée).
Il était tard hier, j'ai fini par capituler, mais ce n'est que partie remise.
Si tu as une piste à explorer, je suis preneur.
(*) EDIT: ceci (https://openwrt.org/docs/guide-user/network/vlan/switch_configuration#is_there_a_vlan-capable_hardware_switch_integrated_in_your_device) corrobore mon assertion: "Many embedded devices with more than 1 port contain a VLAN-capable switch (all routers with a WAN port have a VLAN-capable switch for example). Single-port devices and devices where there is an ethernet controller for each port (like for example PCEngines boards or most PC hardware in general) will have VLAN managed by OS drivers."
-
J’ai manifestement un souci avec cette config: le CPU est à 30% en IDLE (<1% normalement) et j’ai eu la vague impression en faisant un htop que le script map.sh était ré-exécuté sans cesse.
Un rapide bench m'a alors confirmé qu'il y avait un souci, avec un download intermittent, et <3Mb/s de débit (là où j'ai 500Mb/s avec l'IP partagée).
… AH (comme dirait Denis Brogniart) …
Alors c’est normal que le script soit ré-exécute sans cesse, car Free renvoie les informations du tunnel de manière régulière (toutes les secondes au tout début, lors de l’accrochage IPv6 puis toutes les 30 secondes au bout de 10min. environ)
Mais mon IDLE est passé de 1% à 2% … Ce qui m’a paru extrêmement négligeable comme différence de consommation CPU… c’est pour ça que j’ai laissé tel quel.
Dans cette situation tu as 2 choix:
– soit tu supprime la ligne
[ -z "${RULE_DATA##*2a01:e00:29:200a::ffff*}" ] && exit 1et tu essayes de trouver une solution en faisant du NAT ou mwan3 (ce que j’ai pas réussi à faire, du coup je suis preneur si tu trouves la solution)
– soit tu termine le script BIEN PLUS en amont, pour éviter qu’il fasse des calculs inutiles (avec mapcalc) avec genre ce code:
[ -z "${peeraddr##*2a01:e00:29:200a::ffff*}" ] && exit 1à la ligne 35.
Normalement tu devrais presque plus avoir de problème CPU avec la 2ᵉ option (enfin je dis ça au doigt mouillé)
-
Un début de réponse: logread me sort les 3 lignes suivantes en boucle 20x par seconde:
Mon Feb 22 19:25:35 2021 daemon.notice netifd: Interface 'wan6_4' is setting up now
Mon Feb 22 19:25:35 2021 daemon.notice netifd: wan6_4 (31467): Interface wan6_4_ not found
Mon Feb 22 19:25:35 2021 daemon.notice netifd: Interface 'wan6_4' is now down
avec:
1) l'ajout dans map.sh:
[ -z "${RULE_DATA##*2a01:e00:29:200a::fffd*}" ] && sed -i "s/RULE_1_IPV6ADDR=.*/RULE_1_IPV6ADDR=${ip6prefix%?}0:ffff:ffff:0/" /tmp/map-$cfg.rules
[ -z "${RULE_DATA##*2a01:e00:29:200a::ffff*}" ] && exit 1
RULE_DATA=`cat "/tmp/map-$cfg.rules"`
2) mon /etc/config/network:
config interface 'lan'
option type 'bridge'
option ifname 'eth1'
option proto 'static'
option ip6assign '60'
list dns '8.8.8.8'
list dns '8.8.4.4'
list dns '9.9.9.9'
option ipaddr '192.168.0.254'
option netmask '255.255.255.0'
config device 'lan_eth1_dev'
option name 'eth1'
option macaddr YY:YY:YY:YY:YY:YY'
config interface 'wan'
option ifname 'eth0.836' # L'interface sur laquel le tunnel va communiquer
option delegate '0' # On desactive l'integration de l'IPv6 automatique sur cette interface, car on est en IPv4
option tunlink 'wan6' # On remet l'interface sur laquel il communique
option proto 'map' # Le protocole
option type 'map-e' # Le sous-protocole (map-e pour nous, pas lw6over4)
option peeraddr '2a01:e00:29:200a::fffd' # L'adresse du tunnel cote serveur
option ipaddr '82.xx.xx.xx' # L'ip full stack qui vous a ete attribue et qui se trouve sur votre espace client
option ip4prefixlen '32' # Le prefixe de l'IP
option ip6prefix '2a01:xxxx:xxxx:xxxx::' # la plage/prefix IPv6 fournie par Free
option ip6prefixlen '60' # La longueur du prefix
option mtu '1500' # 1500, pour etre en dessous de l'IPv6 a 1700
option encaplimit 'ignore' # pas d'encapsulation limit
option defaultroute '1' # definir comme route par defaut
# defini, le nombre de port attribues, rang, etc... ici pour du full-stack.
option ealen '32'
option psidlen '1'
option offset '16'
option psid '65535'
config interface 'wan6_4'
option delegate '0' # Pas d'IPv6
option defaultroute '0' # On ne definit pas comme route par defaut
option proto 'static' # On lui dit que c'est une adresse static(le protocole map s'occupera de faire le lien)
option force_link '0' # pas besoin de forcer le lien
list ipaddr '91.yy.yy.yy/32' # Votre adresse IP ephemere.
config interface 'wan6'
option ifname 'eth0.836' # Correspond au num..ro de l'interface dans le routeur g..n..ralement 0 pour le WAN, parfois 1 suivi du vlan de Free.
option proto 'dhcpv6' # correspond au protocole. Ici, du dhcpv6 standard.
option reqprefix 'auto' # On le laisse demander la plage IPv6 obtenu (normalement un /60)
option reqaddress 'try' # On laisse en try pas besoin de forcer la requete
option macaddr 'XX:XX:XX:XX:XX:XX' # On change l...adresse MAC du routeur pour celui de la freebox
option mtu '1700' # On augmente le mtu standard, pour avoir un tunnel plus grand en IPv4
list dns '2001:4860:4860::8888' # On attribue les dns IPv6 de google. (optionnel), c...est juste le temps d'avoir un internet fonctionnel le temps de hijacking le dns (si vous le souhaitez)
option peerdns '0' # On refuse les dns proposer par Free (il pue un peu la m****e), mais vous pouvez toujours les autoriser si vous le souhaiter.
Les interfaces dans LuCi ressemblent au screenshot ci-après en configuration avec 'wan6' seulement, et pas de path de 'map' (donc avec l'ip shared only):
(http://intf.png)
-
Je suis relativement perplexe ???
On a exactement la même configuration et pourtant j’ai bien l’IPv4 full-stack
…
– est-ce que tu as un fichier qui apparait des fois, qui s’appelle /tmp/map-wan.rules ?
– est-ce que tu as plus d’info avec ip a? (l’interfaces graphique n’affiche pas toujours tout s’il y a des bugs)
Tu es bien avec la version 19.07 de openwrt ?
---------
Pour ce qui est des logs netifd, j’ai la même. Il me log ça aussi un nombre incalculable de fois, mais mon CPU reste bien à 2% (j’ai pas encore trouvé où taper pour lui faire fermer sa g****e :-X)
-
Quelques tests faits ce soir:
- j'ai recompilé la version FriendlyWrt pour le nanopi 4s (https://wiki.friendlyarm.com/wiki/index.php/How_to_Build_FriendlyWrt#User_Name_.26_Password) avec le support de map (et kernel 5.10)
- pas la moindre amélioration concernant mon interface WAN qui ne voit pas les paquets taggués VLAN 836 tant que je ne passe pas eth0 en mode 'promiscuous'
J'arrive à accrocher mon IP full stack, mais ça semble dans les mêmes conditions qu'avec openWrt:
* toujours les même logs incessants de netifd, qui semble setup puis kill 'wan_6_4' en boucle, faute de trouver 'WAN6_4_'
* une charge CPU élevée en idle, c'est bien netifd qui mange le temps CPU (cf screenshots d'un htop ci-dessous: en haut avec netifd ; en bas avec netifd killed).
* j'atteins avec mon IPv4 Free full stack (82.x) les 600mb/s sans trop sourciller sur un iperf3 vers un de mes serveurs dédiés (51.x).
Accepted connection from 82.xx.xx.xx, port 54322
[ 5] local 51.xx.xx.xx port 5201 connected to 82.xx.xx.xx port 54324
[ ID] Interval Transfer Bitrate
[ 5] 0.00-1.00 sec 59.0 MBytes 495 Mbits/sec
[ 5] 1.00-2.00 sec 69.8 MBytes 585 Mbits/sec
[ 5] 2.00-3.00 sec 69.9 MBytes 586 Mbits/sec
[ 5] 3.00-4.00 sec 70.1 MBytes 588 Mbits/sec
A noter que si je supprime le patch dans map.sh (je n'ai plus possibilité d'avoir ma full stack mais) je n'ai plus les logs incessants.
il y a peut-être quelque chose à améliorer de ce côté là ?
[ -z "${RULE_DATA##*2a01:e00:29:200a::fffd*}" ] && sed -i "s/RULE_1_IPV6ADDR=.*/RULE_1_IPV6ADDR=${ip6prefix%?}0:ffff:ffff:0/" /tmp/map-$cfg.rules
[ -z "${RULE_DATA##*2a01:e00:29:200a::ffff*}" ] && exit 1
RULE_DATA=`cat "/tmp/map-$cfg.rules"`
- Le 'exit 1' du patch ne serait-il pas trop brutal pour netifd ?
- N'y aurait-il pas possibilité de le laisser aller jusqu'au bout du map pour l'IP shared, quitte à lui rajouter une option pour la forcer en down ?
-
remarque du soir, bonsoir : j'ai un Switch (tp-link 24 ports) manageable.
Si je l'intercale entre mon MC 220L et le port WAN de mon nanopi, est-ce que je pourrais m'en servir pour 'détagguer' le vlan 836 et résoudre mon souci de promiscuous mode ?
-
C’est bon j’ai trouvé ^^
à la ligne 130, tu remplaces
proto_add_ipv4_route "0.0.0.0" 0par
[ ! -z "${RULE_DATA##*2a01:e00:29:200a::ffff*}" ] && proto_add_ipv4_route "0.0.0.0" 0
C'est le code pour rajouter la route par défaut.
Du coup, il crée l’interface, mais ne se route pas dessus lorsqu’il s’agit de l’interface 1/4 d’IP^^ (et les logs ont cessé aussi)
Tu supprimes aussi [ -z "${RULE_DATA##*2a01:e00:29:200a::ffff*}" ] && exit 1 du coup.
-
Ca fonctionne comme un charme ! ;D
IPv full stack en place, débit ok et CPU en idle qui se tourne les pouces.
Il me reste mon souci de besoin du promiscuous mode sur l'interface WAN, sur lequel je vais me concentrer désormais:
- les NIC côté WAN et LAN sont deux modèles différents sur le NanoPI R4S ; je vais tenter d'intervertir LAN et WAN pour voir si c'est bien le support du chip ethernet côté WAN qui pose problème (ou si c'est autre chose).
- ou il faudra sans doute que je creuse l'idée de dé-tag le vlan 836 grâce à mon switch manageable
- et dans le pire des cas, en dernier ressort, il me reste le workaround d'activer le promiscuous mode au démarrage du routeur.
Merci beaucopu en attendant pour ta patience et ton aide préciseuse !
-
je ne résiste pas à un petit screenshot qui montre la conso électrique de mon armoire réseau :
- avant, avec la Freebox révolution
- après, avec le nanopi r4s + le TPLink MC-220L
-
T'as gagné 25W à peu près c'est ça ? Pas mal ^^
-
A la grosse louche, oui.
Je dirais plutôt dans les 20w.
(my life ON)
Le nanopi en a clairement encore sous la pédale.
Mon petit bench perso à sa réception, c'est un truc classique que je tente a chaque nouveau matos qui arrive à la maison: j'installe le logiciel 'motion' (détection de mouvement sur flux vidéo), je lui envoie le flux de mes 5 caméras FullHD (de surveillance de la maison), et je regarde la charge CPU.
J'ai de l'atom z8530, du rpi3, 4, etc... qui sont passés à la casserole. Le nanopi r4s est un des rares à s'en sortir sans rougir, le tout pour moins de 5w de diff idle/charge quand mon J4105 (serveur a tout faire de référence dans la baie) prend plus de 10w pour ma même chose.
Bref, la phase 2 c'est ajouter les services et config 'réseau': wireguard, upnp, ... Que la Freebox gérait jusque là.
Phase 2b, ajouter le services qui me manquent encore: splitting du réseau maison en vlan (+ AP Xiaomi wifi sous openwrt), dnsd, ntpd, mails pour mon domaine, contrôle parental sur les subnets des enfants, ...
Phase 3, c'est finir de déporter les services restants sur ce nanopi (ou un frère jumeau), suffisamment pour pouvoir laisser eteint mon j4105 'principal' 95% du temps et gagner encore 15-20w de conso.
Le reste niveau conso ne pourra pas descendre plus bas: AP WiFi et les cams alimentés depuis la baie en PoE, Switch, ...
(my life OFF)
-
Mon routeur NanoPi R4S + openwrt tourne désormais depuis plusieurs jours à la maison.
Je fais face à un problème persistant pour du surf HTTP(s):
- j'ouvre un site 'nouveau' (=domaine pas visité récemment) dans mon navigateur => la page ne charge jamais (status reste bloqué en 'opening socket' sous w3m)
- un simple 'F5' pour relancer le chargement => le site se charge bien.
- tant que je continue à naviguer sur ce site ou que j'y accède à intervalles réguliers, tout es ok.
- si je ne vais plus sur ce site pendant un certain temps (plusieurs minutes) et que j'y retourne => rebelote
- si je suis sur le site (ok), je reboote openwrt, je retente dans la foulée (= sans attendre plusieurs minutes) => le problème réapparaît.
J'ai fait des captures wireshark dans les deux cas (success / failure) avec un setup:
- machine desktop (192.168.0.2) qui est celle qui fait tourner wireshark
- la machine desktop browse (via w3m) https://developpez.com (87.98.130.52)
- la machine desktop est derrière mon nanoPI qui fait le NAT + routing (LAN=192.168.0.254) vers le WAN.
- en cas de failure (= la page ne se charge jamais), je vois passer, cf. screenshot #1
* une requête DNS pour résoudre developpez.com + sa réponse
* une ouverture du canal TCP pour le HTTPS
* un 'client Hello' (handshake SSL ?) + l'ACK TCP
* puis du "TCP previous segment not captured]", puis plus rien.
- en cas de succès (= la page se charge bien), je vois passer, cf. screenshot #2
* une requête DNS pour résoudre developpez.com + sa réponse
* une ouverture du canal TCP pour le HTTPS
* un 'client Hello' (handshake SSL ?) + l'ACK TCP
* le 'Server Hello', et le tout le reste qui déroule normalement.
=> une idée de l'origine du souci ?
-
… Bizarre… le premier truc qui me saute aux yeux, c’est la différence de protocole TLS… TLSv1 quand ça marche pas et TLSv1.3 quand ça marche…
Aujourd’hui c’est très rare les sites qui accepte du TLSv1 (et ça continue de disparaitre presque totalement)
– Tu as testé/remarqué le même genre de problème sur les sites en HTTP only? (monip.org)
Car je trouve ça bizarre que le routeur soit fautif étant donné qu’il ne fait que router les paquets (à moins qu’il y a ait un MITM dans ton réseau).
Et le TLSv1 me fait penser à une tentative de downgrade de la sécurité par un MITM … mais sur un réseau familial, c’est plutôt rare (et c’est un euphémisme)…
De plus, pour de ce que tu décris du problème: On est pas sur un cas de problème DNS. On est vraiment sur un cas où tant que la session TLS est active, pas de problème, mais la renégociation de clé poserai problème... ...???
Mais par contre... la session TLS ne devrait pas être influencer par un reboot du routeur... ... ... du, coup ....??? :-\
-
Re,
merci pour ton retour.
On est vraiment sur un cas où tant que la session TLS est active, pas de problème, mais la renégociation de clé poserai problème... ...???
Je me suis sans doute mal exprimé, mais mon souci n'est pas: "je me connecte au site, ça fonctionne quelque temps et au bout d'un moment, connexion perdue" ; le souci se pose en début de connexion vers le site.
Plusieurs essais plus tard, il semblerait que j'ai quelque chose qui fonctionne en baissant le MTU de mes deux interfaces wan6 & wan (cf. screenshot #1)
config interface 'wan'
option ifname 'eth0.836'
option tunlink 'wan6'
option proto 'map'
...
option mtu '1200' # au lieu de 1500 précédemment
...
config interface 'wan6'
option ifname 'eth0.836'
...
option mtu '1460' # au lieu de 1700 précédemment
...
Ca me donne ça (eth0 = WAN ; eth1 = LAN):
root@OpenWrt:~# ip addr | grep mtu
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
2: eth0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
3: ip6tnl0@NONE: <NOARP> mtu 1452 qdisc noop state DOWN group default qlen 1000
4: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master br-lan state UP group default qlen 1000
5: br-lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
6: eth0.836@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1460 qdisc noqueue state UP group default qlen 1000
7: map-wan@eth0.836: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1200 qdisc noqueue state UNKNOWN group default qlen 1000
8: map-wan6_4@eth0.836: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1280 qdisc noqueue state UNKNOWN group default qlen 1000
J'ai testé la baisse du MTU sans conviction en voyant passer le flag TCP don't fragment dans la réponse "Server Hello" d'une connexion qui fonctionnait (cf. screenshot #2).
Je manque de connaissances à ce niveau pour comprendre le pourquoi du comment et encore plus faire le tour de la question.
- est-ce bien un souci de config de MTU ?
- dans ce cas, pourquoi ça ne marcherait pas à la première tentative et ça serait ok la seconde ?
- 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) ?
- et si c'est bien la root cause, quelles seraient les meilleurs valeurs à adopter ?
- enfin le TLSv1 auquel je n'ai pas de réponse non plus (ou 1ère tentative en TLS 1.3 et seconde en 1.0 ?)
Bref, encore beaucoup de flou, et j'avoue que je n'aime pas trop ne pas comprendre ce qui se trame derrière tout ça...
EDIT: le TLS dans le cas d'une connexion qui fail semble être du 1.2 (cf. screensho #3) (je ne sais pas si ça change grand chose)
-
Si c’est le MTU, tu peux aussi débloquer la valeur (les enlevé dans la config) et laisser faire le routeur.
Il y a juste un risque que le débit soit un peu plus faible pour l’IPv4, car le MTU du tunnel sera toujours plus faible que le MTU du lien IPv6.
Et comme par défaut openwrt, mets le MTU à 1500. tu auras un MTU d’IPv4 inférieur à 1500.
Mais un problème de MTU trop grand.... c’est rare... (c’est plutôt l’inverse en général)
Mais si c’est le problème du mode de promiscuité, je sais pas.
EDIT:Ouai non du coup, ça n’a rien à voir avec TLS... c’est juste Wireshark qui affiche pas la bonne valeur dans la liste des paquets, mais il semble pas avoir quoi que se soit de bizarre en soi.
-
Je pense que je l'ai: le MTU à 1700 de ma config ne semble pas être pris en compte ; il reste à 1500 ; et avec 1500 également côté IPv4, j'imagine que ça fait 'paf le chien'
En remettant la config 1700/1500 (et en reproduisant le souci direct après un reboot, btw), j'ai:
6: eth0.836@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
(en entier ça donne)
root@OpenWrt:~# ip addr | grep mtu
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
2: eth0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
3: ip6tnl0@NONE: <NOARP> mtu 1452 qdisc noop state DOWN group default qlen 1000
4: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master br-lan state UP group default qlen 1000
5: br-lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
6: eth0.836@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
7: map-wan@eth0.836: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000
8: map-wan6_4@eth0.836: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1280 qdisc noqueue state UNKNOWN group default qlen 1000
=> conclusion ?
- encore un souci de mon driver côté WAN qui prend pas en compte le "set MTU" ? (*)
- et pourquoi ça raterait à la première tentative de connexion, mais ça fonctionnerait à la deuxième ?
(*) ou il faudrait que je fasse le changement de MTU sur eth0 plutôt que eth0.836 ? J'ai bien tenté:
ifconfig eth0.836 down && ifconfig eth0 down && ifconfig eth0 mtu 1700
mais j'ai une erreur: "ifconfig: SIOCSIFMTU: Invalid argument"
-
T'as gagné 25W à peu près c'est ça ? Pas mal ^^
Petit retour d'xp après quelques jours:
- avant, avec la freebox révolution: ma baie consommait 2.11 kWh par jour
- désormais, avec le nanopi R4S + openwrt: ma baie consomme 1.55 kWh par jour
Soit une différence de conso de 23 Watts entre la freebox révo serveur et le nanoPi R4S (très exactement ;D)
-
Pour ton problème en https, quelles sont tes règles iptables pour le NAT ?
-
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 (https://github.com/MichaIng/DietPi/issues/2028)
- 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 (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8a469ee35606ba65448d54e5a2a23302f7e79e3c)
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 ?
-
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.
-
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
-
Il faut utiliser
ping -M do
Pour forcer le flag DF, sinon il va fragmenter
-
pour info, j'ai fait un petit test de débit (via les infos fournies sur https://testdebit.info/ (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 (http://www.orangepi.org/Orange%20Pi%20R1%20Plus/) (à base de Rockchip 3328 ; 25€-30€ sur Aliexpress (https://www.aliexpress.com/item/1005001845364289.html?spm=a2g0o.productlist.0.0.54091193z3ccbI&algo_pvid=fbab64d8-d3a7-466a-ab68-72a98d3a7bf0&algo_expid=fbab64d8-d3a7-466a-ab68-72a98d3a7bf0-1&btsid=0b0a556616158268357308707e9acf&ws_ab_test=searchweb0_0,searchweb201602_,searchweb201603_)) ; 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 (https://free.fr/freebox/freebox-revolution/), qui sont passés entre temps à 1.0Gb/s down et 600Mb/s up
-
J'ai par ailleurs acheté un OrangePi R1 Plus (http://www.orangepi.org/Orange%20Pi%20R1%20Plus/) (à 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 (https://www.thingiverse.com/thing:4796633) et imprimé total à l'arrache,
- quelques radiateurs collés
- recompilé la version modifiée par OrangePi d'OpenWrt pour le R1 plus (https://github.com/orangepi-xunlong/openwrt) (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)
(https://i.ibb.co/1XbT2b5/r1plus-case.jpg)
-
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
-
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
-
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?
-
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