La Fibre
Datacenter et équipements réseaux => Routeurs => 
OpenWrt => Discussion démarrée par: mirtouf le 06 septembre 2022 à 15:04:38
-
Bonjour,
ça y est OpenWRT 24.10 est disponible:
https://openwrt.org/releases/24.10/notes-24.10.0
Le noyau passe en version 6.6 et il faudra encore attendre pour utiliser apk en lieu et place d'opkg.
20 ans !
https://forum.openwrt.org/t/openwrt-one-celebrating-20-years-of-openwrt/183684
-
Je pleure pour comprendre comment nftables est foutu...
1. J'ai des règles à transformer qui ne fonctionnent pas avec iptables-nft:
iptables -A input_wan_rule -p tcp --dport 22 -m conntrack --ctstate NEW -m recent --set
iptables -A input_wan_rule -p tcp --dport 22 -m conntrack --ctstate NEW -m recent --update --seconds 30 --hitcount 5 -j DROP
2. J'aimerai que ces règles soient appliquées en même temps que les modifications du firewall (comme firewall.user avant).
3. J'ai aussi des règles ebtables (remplacés aussi par nftables).
J'arrive bien à les appliquer à la main, mais pareil que 2., je ne sais pas comment faire pour les reappliquer à chaque fois que j'update le firewall, voir tout simplement au boot.
Bref, j'aimerai bien basculer sur le 22.03 (ne serait-ce que pour un espérer driver ath10k plus récent supportant 160MHz avec moins de bugs), mais sans firewall.user je pleure....
-
L'ICMP en IPv6 a aussi des problèmes, je n'arrive pas à joindre les serveurs DHCPv6 avec les règles par défaut...
-
Bref, j'aimerai bien basculer sur le 22.03 (ne serait-ce que pour un espérer driver ath10k plus récent supportant 160MHz avec moins de bugs), mais sans firewall.user je pleure....
ben tu peux...
avec le firmware selector https://firmware-selector.openwrt.org/
tu te positionnes sur le firmware de ton routeur, ensuite tu cliques sur "Personnaliser les paquets installés", et tu remplaces les paquets NFTables par les paquets IPTables. et firewall4 par firewall3
j'ai pas testé, j'avoue, mais ca me semble faisable.
donc :
firewall4 --> firewall
kmod-nft-offload --> kmod-ipt-offload
nftables --> iptables + ip6tables
-
Je vais faire comme avec la 21... je vais attendre au moins la version .1 pour le mettre en production chez moi. En attendant je vais me faire la main dessus et trouver le moyen de résoudre mes problèmes sur un routeur offline.
-
ben tu peux...
avec le firmware selector https://firmware-selector.openwrt.org/
tu te positionnes sur le firmware de ton routeur, ensuite tu cliques sur "Personnaliser les paquets installés", et tu remplaces les paquets NFTables par les paquets IPTables. et firewall4 par firewall3
j'ai pas testé, j'avoue, mais ca me semble faisable.
Je ne pense pas que ça résoudra l'absence de firewall.user. Déjà ce fichier n'est plus sauvegardé en cas de sysupgrade.
Mais en tout cas cépakon, je vais tester si j'ai le temps. Merci.
-
Je ne pense pas que ça résoudra l'absence de firewall.user. Déjà ce fichier n'est plus sauvegardé en cas de sysupgrade.
Mais en tout cas cépakon, je vais tester si j'ai le temps. Merci.
et en passant par cette astuce: https://lafibre.info/remplacer-livebox/remplacement-de-la-livebox-par-un-routeur-openwrt-18-dhcp-v4v6-tv/msg967299/#msg967299
-
Bon, finalement une fois que l'on se rend compte que la doc openwrt sur le firewall a été mis à jour, que l'on a compris la nouvelle structure des includes de snippets, et que l'on prend un peu de temps pour comprendre comment on peut bien utiliser nftables, bah finalement c'est pas si compliqué.
Je trouve juste dommage de ne pas avoir intégré dans luci un éditeur de snippets comme remplaçants du firewall.user: en gros avoir la liste de tables + chain, un pre/post/append à chaque niveau + choix script/nftables, cliquer dessus, et pouvoir y ajouter directement les règles que l'on souhaite.
Je vais migrer bientôt d'abord ma ligne free (avec j'espère le 160MHz de fonctionnel), tester rapidement, puis ma ligne orange. Je suis d'abord obligé de recompiler en local un openwrt pour pouvoir patcher le driver bnx2x pour le support du 2.5 chez orange. J'espère ne rien casser chez free vu que ce sera à distance (je ne pourrais pas tester les 160MHz mais tant pis).
Je ferais un copié coller de mes snippets ici une fois validé de mon côté.
-
Après avoir passé un peu de temps sur la version 22.03, je dirais que:
- il vaut mieux repartir sur une base vierge pour le fw et ajouter au fur et à mesure ses règles,
- certains paquets dépendent encore d'iptables, il faut en tenir compte (map par exemple),
- l'interface web a encore des bugs, je pense notamment à miniupnpd qui n'affiche rien alors que les règles sont bien créées (cela vient d'être patché !).
-
OpenWRT 22.03 étant maintenant sur son rythme de croisière, OpenWRT 23.05 est disponible avec une RC1.
-
La RC2 est là ! 8)
-
La version 23.05.0 est là !
-
@mirtouf: petite typo dans le titre
Premier test d'openWRT 23.05 sur un R7800 derrière une freebox: semble OK.
Je n'ai pas encore testé si le 160MHz (wifi 5 wave 2) fonctionne correctement. La version précédente était moins performant en 160MHz qu'en 80MHz malgré un DFS qui dit que tout va bien.
Apparemment il y a un des commit de mbizon sur le sujet entre les 2 releases. Je comprend car apparemment le R7800 a le même chipset wifi que la delta wifi 5E (pas wifi6). Du coup j'aimerai bien savoir si le 160MHz fonctionne bien avec la delta si on configure le routeur sur 36 (+160VHT) + intel AX200. Chez moi avec la 22.03 sur le R7800 l'intel detecte bien 160MHz mais en perf j'ai 100Mbps de moins qu'en 80MHz. Je pourrais refaire des tests que pendant ces vacances.
-
Bonjour !
A t'on une meilleure conception du micrologiciel en le construisant avec OpenWrt Buildroot ?
Je m'explique !
Embarqué par Gentoo, j'ai finalement été vraiment déçu car je n'arrivais pas à me mettre au niveau. Je me suis attelé à Buildroot par alternative.
Parce qu'en pratique, je souhaitais élaborer par moi-même (pour simplifier l'administration) le micrologiciel dédié à mon serveur Raspberry Pi.
J'y suis parvenu au bout d'un certain temps, non sans mal, et de façon plutôt minime. Donc, cela n'a pas été la réussite attendue. Néanmoins,
comme je progresse, j'en arrive à capitaliser sur ce que je fais pour éviter de capituler (continuer de progresser sans avoir perdu tous ses efforts).
C'est aussi difficile à plafonner. Je connais donc assez bien Buildroot. Est-ce que cela pourrait me permettre d'avoir une meilleure perspective en vue
d'installer adéquatement OpenWrt sur mon routeur Open Hardware Banana Pi BPI R3 ? Pour que les choses se mettent en place comme il faut.
-
Salut Basilix,
quel problème as-tu avec ton BPI-R3 qui te pousse a vouloir créer ta propre image openwrt ?
Quand il n'y avait pas de version stable j'avais du compiler mon propre firmware pour y ajouter quelques patch afin que le BPI-R3 reconnaisse mes modules SFP, maintenant ce n'est plus necessaire avec la version stable. Mon routeur tourne comme une horloge, du coup je m'interroge, que souhaites-tu changer ou améliorer en compilant ta propre image ?
-
Hello rooot!
C'est une bonne question !
Ce qui me pose problème c'est la documentation et l'agencement des choses. C'est difficile d'avoir une vue d'ensemble. Donc, j'aurais voulu
me rabattre sur ce que je connaissais le mieux. Définir un système GNU / Linux personnalisé en imbriquant des fonctionnalités mais basé sur
OpenWrt. Passer les choses en revue quand on débute c'est compliqué. À noter qu'on peut rajouter des fonctionnalités via des paquets ou
construire une image personnalisée facilement grâce au sélecteur de micrologiciel OpenWrt. Mais comme c'est abstrait et volumineux,
dans l'idée, j'aurais préféré reconnaître les choses en les retirant. Ce n'est pas pour optimiser mais pour mieux cerner.
Remarque : c'est peut-être un ressenti transitoire. Mais actuellement, cela me donne l'impression de fouiller dans la documentation.
-
Re : Un fil de discussion Reddit (dont l'intitulé a été retiré) confirme ce que je pensais déjà à propos de OpenWrt.
C'est à chacun de faire les choses. Sauf que c'est éventuellement variable en fonction de l'installation. Il faut nécessairement s'informer en faisant des recherches,
en parcourant la documentation, mais surtout, solliciter des compétences en administration système et réseau.
À mon avis, on peut installer OpenWrt sans préalable. Sauf qu'il y aurait aussi une absence totale de garantie que cela fonctionne comme souhaité.
[Fin de l'histoire]
Sources
- https://www.reddit.com/r/openwrt/comments/vsywpz/deleted_by_user/ (https://www.reddit.com/r/openwrt/comments/vsywpz/deleted_by_user/)
- [OpenWrt Wiki] Security Guide for the Paranoid (https://openwrt.org/docs/guide-user/security/security_guide_for_the_paranoid)
-
Déjà 20 ans...
https://forum.openwrt.org/t/openwrt-one-celebrating-20-years-of-openwrt/183684
-
@rooot: J'ai trouvé un usage nécessitant de générer sa propre image.
$ uci export dhcp | nl -b a
1 package dhcp
2
3 config dnsmasq
4 option domainneeded '1'
5 option boguspriv '1'
6 option filterwin2k '0'
7 option localise_queries '1'
8 option rebind_protection '1'
9 option rebind_localhost '1'
10 option local '/lan/'
11 option domain 'lan'
12 option expandhosts '1'
13 option nonegcache '0'
14 option cachesize '1000'
15 option authoritative '1'
16 option readethers '1'
17 option leasefile '/tmp/dhcp.leases'
18 option resolvfile '/tmp/resolv.conf.d/resolv.conf.auto'
19 option nonwildcard '1'
20 option localservice '1'
21 option ednspacket_max '1232'
22 option filter_aaaa '0'
23 option filter_a '0'
24
25 config dhcp 'lan'
26 option interface 'lan'
27 option start '100'
28 option limit '150'
29 option leasetime '12h'
30 option dhcpv4 'server'
31 option dhcpv6 'server'
32 option ra 'server'
33 option ra_slaac '1'
34 list ra_flags 'managed-config'
35 list ra_flags 'other-config'
36
37 config dhcp 'wan'
38 option interface 'wan'
39 option ignore '1'
40
41 config odhcpd 'odhcpd'
42 option maindhcp '0'
43 option leasefile '/tmp/hosts/odhcpd'
44 option leasetrigger '/usr/sbin/odhcpd-update'
45 option loglevel '4'
46
J'adore...
$ uci export dhcp | awk 'NR==25, NR==35 { print }'
config dhcp 'lan'
option interface 'lan'
option start '100'
option limit '150'
option leasetime '12h'
option dhcpv4 'server'
option dhcpv6 'server'
option ra 'server'
option ra_slaac '1'
list ra_flags 'managed-config'
list ra_flags 'other-config'
il a juste fallu activer l'option BUSYBOX_CONFIG_NL [=y] pour la compilation (make nconfig).
-
j'ai pas bien compris...ça fait quoi de plus que :
cat /etc/config/network
cat /etc/config/dhcp
?
-
@rooot: Cela permet de n'afficher que les informations qu'on recherche pour gagner en clarté.
-
@rooot: Cela permet de n'afficher que les informations qu'on recherche pour gagner en clarté.
ha !
mais tu es sur que tu as besoin de faire une compilation custom pour ça ?
-
@rooot: Ouai.
J'ai une station de travail relativement puissante. Je peux ainsi redéfinir comment le micrologiciel du routeur est pré-configuré et l'adapter si nécessaire.
Il faut dire que à la base OpenWrt n'est pas totalement configuré. Ce n'est pas le routeur fourni par un opérateur ou FAI. Par contre, comme souvent
dans le logiciel libre (ouvert), c'est modulaire mais il faut connaître. Donc, je trouve que pouvoir adapter son logiciel (après tant d'effort fourni), c'est
encore mieux.
-
Note : Vérifiez les fonctionnalités activées si vous choisissez de générer une image personnalisée par compilation.
Il est mentionné que l'on peut reprendre la configuration officielle pour un routeur supporté par OpenWrt [1].
La génération de l'image pour mon système prenait beaucoup de temps, de façon assez surprenante.
CONFIG_ALL_KMODS=y
CONFIG_ALL_NONSHARED=y
CONFIG_AUTOREMOVE=y
CONFIG_BUILDBOT=y
CONFIG_SDK=y
Avec la configuration officielle, tous les modules noyaux étaient compilés, ainsi que les paquets spécifiques au routeur.
Il me semble également qu'à chaque génération d'image, plusieurs paquets étaient recompilés (sans modification).
[1] https://openwrt.org/docs/guide-developer/toolchain/use-buildsystem#using_official_build_config
-
https://openwrt.org/releases/24.10/notes-24.10.0
General changes
Upgrades of many components to new versions like the Linux kernel from version 5.15 to 6.6
TLS 1.3 support in default images
mbedtls was updated to version 3.6 which includes support for TLS 1.3
Activate POSIX Access Control Lists and file system security attributes for all file systems on devices with big flash sizes. This is needed by docker nowadays.
This is activated for all targets which do not have the small_flash feature flag. small_flash is set for the ath79/tiny, bcm47xx/legacy, lantiq/ase, lantiq/xrx200_legacy, lantiq/xway_legacy, ramips/mt76x8, ramips/rt288x, ramips/rt305x and ramips/rt3883 targets.
Activate kernel support for Multipath TCP on devices with big flash sizes.
Improved support for WiFi6 (802.11ax) and initial support for WiFi7 (802.11be)
Not many Wifi7 devices are supported by OpenWrt yet
Improved Link Layer Discovery Protocol (LLDP) support
OpenWrt 24.10 uses OPKG only, APK packages are *not* supported. Only main branch was changed to APK.
-
Achtung!
Des gros bugs au niveau multicast (igmpproxy, noyau) sont apparus et cela empêche de recevoir les flux correctement (perte de paquets dès un certain débit). Bien sûr, tout fonctionne correctement avec OpenWRT 23.05.
Sans en être sûr, les modifications noyaux et un logiciel plus très souvent mis à jour ne sont pas un gage de fiabilité.
-
Achtung!
Des gros bugs au niveau multicast (igmpproxy, noyau) sont apparus et cela empêche de recevoir les flux correctement (perte de paquets dès un certain débit). Bien sûr, tout fonctionne correctement avec OpenWRT 23.05.
Sans en être sûr, les modifications noyaux et un logiciel plus très souvent mis à jour ne sont pas un gage de fiabilité.
heureusement qu'il y a eu 7 Release candidate avant...
-
Ca ne serait pas dû à des modifications de règles de firewall ?
-
Pas de mon côté, je vais devoir regarder les règles insérées par les paquets.
-
@mirtouf tu as un lien pour suivre l'avancement de ce bug ?
je suis passé a la 24.10 et je rencontre des problemes de paquets sur mes flux TV multicast...
-
Je n'avais rien vu niveau logiciel qui soit évident, je n'avais pas ouvert de bug.
A priori, de façon déconcertante, les paquets sont réordonnés ce qui fout le dawa dans les flux UDP multicast: https://github.com/openwrt/openwrt/issues/18214
Cela semble cohérent avec mes observations: les flux multicast à faible débit arrivent encore à avoir leurs paquets réordonnés sans perte alors que les flux à débit plus élevés n'ont pas cette chance.
-
de mon coté le problème est contourné en utilisant udpxy plutot qu'igmpproxy, ca marche nickel.
-
Depuis le passage à la 24.10 il y a des mises a jour de Luci tous les 3 jours environ, c'est quoi cette histoire ???
-
Pour en revenir à mes problèmes de flux pixelisés, c'était lié à un GRO malveillant, un coup de ethtool -K eth1 gro off a résolu mon problème mais cela aurait pu faire l'objet d'un avertissement dans la release, depuis des années cela ne posait aucun problème mais visiblement, les modifications noyau ont créé ce problème.
-
Du coup ca doit me concerner aussi, bien que mon probleme soit réglé suite au passage a udpxy. je vais tester en rentrant.
-
On pourrait même utiliser une option:
https://github.com/openwrt/netifd/pull/14
uci set network.@device[2].gro='0'
uci commitLe device dépendant de chez vous mais vous pouvez le vérifier avec
uci show network
Le problème pourrait venir de là:
https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=b5c53848c3792355a2dd4ff0e06bf4d230e1f5fb
-
Les aventures du GRO ne sont pas finies:
https://github.com/openwrt/openwrt/issues/18901
La documentation du noyau sur le sujet est pour initiés. ;D
https://docs.kernel.org/networking/segmentation-offloads.html
-
On pourrait même utiliser une option:
https://github.com/openwrt/netifd/pull/14
uci set network.@device[2].gro='0'
uci commitLe device dépendant de chez vous mais vous pouvez le vérifier avec
uci show network
Nickel ! Ca marche chez moi, donc plus besoin d'udpxy. ;) Merci Mirtouf!!
Dans /etc/config/network ca correspond à ça sur mon BPI-R3 :
config device
option name 'eth1'
option macaddr 'ce:a4:39:xx:xx:xx'
option gro '0'
-
Le bug GRO a son ticket:
https://github.com/openwrt/openwrt/issues/18901
-
Ce qui me gene c'est qu'il y a un target "ramips/mt7621" alors qu'on est impacté sur du Filogic. Je viens d'ajouter un commentaire.
-
C'est logique, quand on ouvre un ticket on doit préciser quelle plate-forme est affectée afin de vérifier mais la reproductibilité du bug qui me semble de toute façon impacter toutes les architectures.
-
Ce bug est intéressant pour comprendre le mécanisme sous-jacent:
https://github.com/openwrt/openwrt/issues/15623
ou celui-ci:
https://github.com/openwrt/openwrt/issues/18387
-
Le patch pour corriger le bug GRO est arrivé dans nightly, on verra quand le backport sera actif:
https://github.com/openwrt/openwrt/commit/604355e8c4d18dda22aeb618c1489c5369860418