La Fibre
Fournisseurs d'accès à Internet fixe en France métropolitaine => 
K-Net => Opérateurs grand public alternatifs => Espace technique internet K-Net => Discussion démarrée par: bolemo le 15 avril 2022 à 15:47:51
-
Bonjour,
Avec les problèmes récurrents sur des Icotera, certains se posent la question de passer sur un routeur perso, comme un bon nombre d'entre nous.
Le but de ce post, est d'avoir un retour d'expérience sur votre satisfaction avec votre routeur, sa facilité d'utilisation, sa fiabilité, etc…
Merci donc, si vous le souhaitez, de poster succinctement votre modèle de routeur perso, sa facilité d'utilisation, la qualité de votre connexion et votre satisfaction, ainsi que votre département (pour savoir quel OI et quel type de bail DHCP…)
Pour ma part, je suis dans le 14 et j'ai un routeur Netgear R7800, avec le firmware Voxel.
J'ai configuré pas mal de choses à la main, car au tout début, j'avais des microcoupures toutes les 5 minutes (le routeur n'aimait pas le bail DHCP de 5 minutes). Depuis que j'ai réglé tout ça il y a presque 4 ans maintenant, j'ai une connexion très stable, et malgré les soucis récents de K-Net, je n'ai subi qu'une coupure d'une demi-journée en janvier.
-
D’ailleurs question :
Si j’achète un routeur perso, je clone juste l’adresse Mac de l’Icotera sur le nouveau routeur et ça repart direct ou il faut faire plus de paramètre ?
Merci
-
Oui, c'est tout ce qu'il y a à configurer.
Il suffit de mettre le routeur en adresse IP automatique (DHCP client) coté WAN, et de nater.
Sur mon vieux DSL-AC52U d'Asus, la page de configuration WAN.
Il tient le Gbps.
Covage74 : Bail DHCP de 5minutes
-
Top merci.
J’achèterais ça semaine prochaine
-
Jusqu'à mon départ de K-Net, un truc fait maison : APU 1c4 (www.pcengines.ch), linux slackware 14.2.
Coût : env. 150 EUR avant que les prix ne prennent l'ascenseur (board + SSD + boîtier + alim).
Pour l'IPv4, client DHCP avec option -C resolv.conf et -C ntp.conf : j'ai toujours eu mes propres resolvers et mon NTP. Le DHCP sur un réseau FTTH est une cochonnerie qui sert à reset le DHCP snooping, on en a pas déjà causé.
Pour l'IPv6 (à l'époque où ça marchait chez K-Net), config "à la main" : ip addr add, ip route add, Jack m'avait donné les paramètres quand je me suis abonné.
J'utilise beaucoup les VLAN sur mon réseau, donc pas mal de vconfig sur les interfaces internes. dhcpd (ISC) et radvd là où c'était nécessaire.
À part ça, les configs se limitaient au routage (statique), NAT, règles iptables/ip6tables pour le filtrage.
Cette machine a tourné non-stop pendant 6 ans sans aucun problème et avec à peu près zero maintenance, elle n'a redémarré que lors des quelques pannes de courant qui dépassaient l'autonomie de mon UPS.
J'avais mis une deuxième APU pour mes VPN, j'avais un peu peur côté perfs mais en fait j'aurais pu tout mettre sur la même machine.
Merci donc, si vous le souhaitez, de poster succinctement votre modèle de routeur perso, sa facilité d'utilisation, la qualité de votre connexion et votre satisfaction, ainsi que votre département (pour savoir quel OI et quel type de bail DHCP…)
Département 01 - SIEA
Facilité d'utilisation : c'est sûr que c'est loin d'être une solution clé en mains, mais comme ça fait 20 ans que je configure du réseau sur slackware, c'est plus simple que d'apprendre à me battre contre utiliser un autre truc.
J'aime bien savoir ce que je fais, et je préfère me battre contre mon propre code que contre celui des autres.
Extrêmement fiable. Chaque fois que j'ai eu des problèmes et que j'ai soupçonné cette petite machine, la couille était chez K-Net ou chez le SIEA.
-
pour moi un TpLink Archer AX50 (wifi 6) : fonctionne nickel _ rien à configurer
juste donner la Mac internet à K-net pour être référencé dans leur base
réseau : covage ( seine-essonne )
https://www.tp-link.com/fr/home-networking/wifi-router/archer-ax50/v1/ (https://www.tp-link.com/fr/home-networking/wifi-router/archer-ax50/v1/)
on le trouve à moins de 90 euros.
(https://i.ibb.co/JxWYQ62/2022-04-17-00-27-27.jpg) (https://imgbb.com/)
-
Comment vous gérez ce bail dhcp de 5 min du coup ?
Je me renseigne en amont comme ça, une fois reçu, ça sera configuré super rapidement.
J’ai regardé plusieurs tests et je vais prendre un Asus Zenwifi XT8 je pense. Quitte à en ajouter un second en mesh dans quelques temps.
Et en espérant surtout que ça résolve mon soucis de coupures régulières que je subis, au moment même où j’écris ça…
-
Comment vous gérez ce bail dhcp de 5 min du coup ?
Je me renseigne en amont comme ça, une fois reçu, ça sera configuré super rapidement.
J’ai regardé plusieurs tests et je vais prendre un Asus Zenwifi XT8 je pense. Quitte à en ajouter un second en mesh dans quelques temps.
Et en espérant surtout que ça résolve mon soucis de coupures régulières que je subis, au moment même où j’écris ça…
En principe, ça se gère tout seul :)
Un bail DHCP de 5 minutes ne devrait pas poser de problème techniquement.
Le problème que j'avais avec mon modèle et ma version à l'époque, c'est d'une part le client DHCP qui était ancien, et ne renouvelait pas son bail à mi-bail (il attendait la fin des 5 minutes), et d'autre part les scripts Netgear qui à chaque renouvellement de bail côté WAN (client) forçait un renouvellement côté LAN (serveur) en faisant un reset physique de l'interface ethernet. Du coup les clients sur le LAN perdaient la connexion pensant quelques secondes (genre une ou deux secondes) toutes les 5 minutes.
J'aurais peut-être pu résoudre ça en ajustant quelques paramètres, mais comme patrick_01, j'aime bien savoir ce qu'il se passe et maîtriser tout ça, donc j'ai changé les scripts du routeur, je suis passé en une configuration fixe pour le routeur, et un serveur DHCP paramétré à la main côté LAN, et j'ai développé un petit utilitaire en C pour conserver mon adresse IP autorisée (ACL) en simulant un dialogue DHCP avec le relais Covage.
Steph avec son modèle Netgear n'a pas ce problème, gigi avec son TP-Link non plus… Bref, tu ne devrais pas avoir de problème.
Après, si pour je ne sais quelle raison cela devait t'arriver, la communauté ici pourra t'aider ;)
Avec le routeur perso, tu seras épargné des bogues Icotera (fuite GPON/LAN) dont tu es peut-être victime.
Enfin, pour la MAC, il y a deux solutions :
La plus simple (au départ en tous cas) : tu n'indiques pas de changement à K-Net, et dans ton nouveau routeur, tu copie la MAC de ta K-Box sur l'interface ethernet côté WAN et c'est tout :)
Avec cette solution, tu peux garder ta K-Box sous le coude comme solution de secours.
L'autre solution plus définitive est de donner la MAC native de ton nouveau routeur à K-Net, et de retourner la K-Box (et récupérer ta caution).
Conseil : commence simplement avec la première solution (clonage MAC) pour vérifier que tout fonctionne bien. Si après quelques temps tout est impeccable, alors rien ne t'empêchera d'appliquer la solution 2. Si au contraire au bout de quelques jours tu réalises que le modèle de routeur que tu as choisi venait à poser des problèmes, tu peux aisément le retourner et en choisir un autre ;)
-
Merci boléro, je vais faire comme ça !
-
J'avais mis en place pendant quelques semaines avec un TP-Link Archer AX55 v1.0 (ou aussi AX3000) sur Covage-MEL (MEL = Métropole Européenne de Lille et devenu XP-Fibre) sans soucis entre début février et mis Mars... J'avais remis l'Icotera pour essayer de retrouver le téléphone, sans succès d'ailleurs. Je n'avais plus les montée de ping / traceroute toutes les 15/16 heures du à l'Icotera qui a toujours son Wi-Fi à OFF car c'est le AX55 qui fait AP du coup.
-
OpenWRT sur n'importe quel matériel supporté. Ça marche tout seul et ça fait le café. 1000x mieux que n'importe quelle box ;)
-
OpenWRT sur n'importe quel matériel supporté. Ça marche tout seul et ça fait le café. 1000x mieux que n'importe quelle box ;)
Aucun routeur / blackbox en WiFi 6 en OpenWRT. Autant, je peux comprendre qu'on pousse ça en 2019/2020... Mais plus en 2022 à moins de mettre en plus un AP WiFi 6 à coté.
-
Aucun routeur / blackbox en WiFi 6 en OpenWRT. Autant, je peux comprendre qu'on pousse ça en 2019/2020... Mais plus en 2022 à moins de mettre en plus un AP WiFi 6 à coté.
Heu... https://openwrt.org/toh/views/toh_available_16128_ax-wifi
Perso j'en ai rien à carer j'ai aucun client qui supporte le 802.11ax, et le Saint Spaghetti (cat5e ou 6) reste mon unique dieu ;D
-
Bon, c'est pas vraiment un retour d'expérience vu que je l'ai installé il y a 5h, mais je suis passé d'une KBOX Icotera à un Asus Zenwifi XT8.
Une interface super complète, une appli qui permet de piloter à distance, un routeur "user friendly", un wifi 6 puissant (j'ai même pu supprimer un point d'accès Ethernet devenu inutile vu la couverture du machin), la possibilité de le coupler avec un copain pour faire un système mesh si besoin (dans mon cas, pas utile pour l'instant. On verra plus tard quand les gamins auront besoin de + de bande passante...).
Pour l'instant, pas de micro coupures détectées. Est ce que c'est un hasard, l'avenir me le dira.
Mais à l'instant T, je suis content de mon achat. 8)
Je le laisse tourner 2-3 semaines et si d'ici la RAS, je rend la KBOX et je fais changer la MAC par le support KNET (clonée actuellement)
-
Heu... https://openwrt.org/toh/views/toh_available_16128_ax-wifi
Perso j'en ai rien à carer j'ai aucun client qui supporte le 802.11ax, et le Saint Spaghetti (cat5e ou 6) reste mon unique dieu ;D
Alors vu les routeurs (et AP donc eux 0 intérêt) dans la liste autant dire qu'il n'y a rien de bien fameux, rien que pour le Xiaomi AX3200 et AX6S, c'est la loterie des puces (une fois Broadcomm, une fois Mediatek, etc etc).... Il y a bien Ubiquity, enfin pour ceux qui leur font encore confiance après le fiasco de l'an dernier.
Bon, c'est pas vraiment un retour d'expérience vu que je l'ai installé il y a 5h, mais je suis passé d'une KBOX Icotera à un Asus Zenwifi XT8.
Une interface super complète, une appli qui permet de piloter à distance, un routeur "user friendly", un wifi 6 puissant (j'ai même pu supprimer un point d'accès Ethernet devenu inutile vu la couverture du machin), la possibilité de le coupler avec un copain pour faire un système mesh si besoin (dans mon cas, pas utile pour l'instant. On verra plus tard quand les gamins auront besoin de + de bande passante...).
Pour l'instant, pas de micro coupures détectées. Est ce que c'est un hasard, l'avenir me le dira.
Mais à l'instant T, je suis content de mon achat. 8)
Je le laisse tourner 2-3 semaines et si d'ici la RAS, je rend la KBOX et je fais changer la MAC par le support KNET (clonée actuellement)
Le soucis avec les Asus serait ne non support de l'IPv6 dans certains cas. Est-ce un soucis ici ?
-
Bon, c'est pas vraiment un retour d'expérience vu que je l'ai installé il y a 5h, mais je suis passé d'une KBOX Icotera à un Asus Zenwifi XT8.
Une interface super complète, une appli qui permet de piloter à distance, un routeur "user friendly", un wifi 6 puissant (j'ai même pu supprimer un point d'accès Ethernet devenu inutile vu la couverture du machin), la possibilité de le coupler avec un copain pour faire un système mesh si besoin (dans mon cas, pas utile pour l'instant. On verra plus tard quand les gamins auront besoin de + de bande passante...).
Pour l'instant, pas de micro coupures détectées. Est ce que c'est un hasard, l'avenir me le dira.
Mais à l'instant T, je suis content de mon achat. 8)
Je le laisse tourner 2-3 semaines et si d'ici la RAS, je rend la KBOX et je fais changer la MAC par le support KNET (clonée actuellement)
Il y a eu un incident de boucle spammeuse DHCPv6 ce matin (entre 4h et 12h) sur le 14 et 91. As-tu été affecté, ou ton routeur t'en a-t'il protégé ?
J'imagine que tu n'as même pas réalisé qu'il y avait un souci ;)
-
Alors vu les routeurs (et AP donc eux 0 intérêt) dans la liste autant dire qu'il n'y a rien de bien fameux, rien que pour le Xiaomi AX3200 et AX6S, c'est la loterie des puces (une fois Broadcomm, une fois Mediatek, etc etc).... Il y a bien Ubiquity, enfin pour ceux qui leur font encore confiance après le fiasco de l'an dernier.
Si tu préfères acheter une usine à gaz qui sera supportée par le constructeur au mieux quelques mois, plutôt qu'utiliser un système tenu à jour dans la durée et qui te permet d'évoluer facilement dans le temps (parce que une fois ta config openwrt en place, rien de plus simple que de la migrer sur un hardware plus récent), libre à toi.
Comme je disais, le 802.11ax perso j'en ai strictement rien à faire. Mais rien ne vaut le marketing du "j'ai la plus grosse" pour continuer à remplir les décharges avec du matériel presque neuf, n'est-ce pas? ;)
-
Si tu préfères acheter une usine à gaz qui sera supportée par le constructeur au mieux quelques mois, plutôt qu'utiliser un système tenu à jour dans la durée et qui te permet d'évoluer facilement dans le temps (parce que une fois ta config openwrt en place, rien de plus simple que de la migrer sur un hardware plus récent), libre à toi.
Comme je disais, le 802.11ax perso j'en ai strictement rien à faire. Mais rien ne vaut le marketing du "j'ai la plus grosse" pour continuer à remplir les décharges avec du matériel presque neuf, n'est-ce pas? ;)
OpenWRT est bien, mais il faut vérifier qu'il exploite bien les fonctionnalités matérielles du routeur sur lequel il est installé.
Je ne l'utilise pas personellement, car il n'utilise pas l'accélération matérielle sur mon routeur (Netgear R7800). En revanche j'utilise un firmware modifié (l'excellent firmware Voxel), basé sur le firmware officiel, qui utilise donc l'accélération matérielle, mais apporte aussi ne nombreux avantages du genre de ceux proposés par OpenWRT.
Je suis 100% pour un système ouvert, et l'initiative OpenWRT est très bien.
Mon routeur n'est pas AX, mais il tient très très bien le gigabit, et le WiFi permet un débit de 650 Mbps… largement suffisant. Mes serveurs sont en ethernet bien sûr.
-
OpenWRT est bien, mais il faut vérifier qu'il exploite bien les fonctionnalités matérielles du routeur sur lequel il est installé.
Je ne l'utilise pas personellement, car il n'utilise pas l'accélération matérielle sur mon routeur (Netgear R7800). En revanche j'utilise un firmware modifié (l'excellent firmware Voxel), basé sur le firmware officiel, qui utilise donc l'accélération matérielle, mais apporte aussi ne nombreux avantages du genre de ceux proposés par OpenWRT.
Pour moi aucune accélération matérielle ne justifie d'utiliser un firmware vérolé par d'innombrables CVEs kernel (les firmwares "officiels" tournent sur des versions noyau antédiluviennes abondamment patchées - dans le cas du R9000 on doit être sur un 3.10 du siècle dernier si ma mémoire est bonne).
Après chacun ses priorités, moi c'est la sécurité.
-
Pour moi aucune accélération matérielle ne justifie d'utiliser un firmware vérolé par d'innombrables CVEs kernel (les firmwares "officiels" tournent sur des versions noyau antédiluviennes abondamment patchées - dans le cas du R9000 on doit être sur un 3.10 du siècle dernier si ma mémoire est bonne).
Après chacun ses priorités, moi c'est la sécurité.
Ah mais absolument, on est d'accord !
J'utilise le firmware Voxel justement parce qu'il est mis-à-jour très régulièrement avec les dernières mises-à-jour de sécurité (tous les mois au moins). Ce firmware utilise à la fois l'accélération matérielle, l'ouverture à la OpenWRT, et surtout les mises-à-jours des failles.
Voxel est devenu un ami à moi (je suis assez actif sur le forum SNB sous le nom hELLO_WORLD). Il a beaucoup de mal car il vit en Russie (il est Russe, sa mère Ukrainienne…), et est très affecté par le conflit (culpabilité de sa nationalité, et effet des sanctions économiques)… Je suis en contact régulier avec lui par des moyens sécurisés, et je suis un des dépositaires de son code si quelque chose devait lui arriver. Je l'aide aussi avec d'autres à trouver un job hors de Russie… il y aura peut-être quelque chose de très prometteur pour les routeurs Netgear qui sortira de cela, mais il est bien trop encore pour savoir si ça aboutira…
Sur SNB, j'ai aussi développé le firewall Aegis pour R7800, R9000 et Orbi (sur firmware Voxel), un genre de FireHOL maison pour ces routeurs qui filtre des million d'IP indésirables…
-
Il y a eu un incident de boucle spammeuse DHCPv6 ce matin (entre 4h et 12h) sur le 14 et 91. As-tu été affecté, ou ton routeur t'en a-t'il protégé ?
J'imagine que tu n'as même pas réalisé qu'il y avait un souci ;)
Nope rien vu. S’il y avait eu un problème, même au taff, j’aurais eu des échos (pas de Fortnite le Mercredi ! Un drame national !)
Donc RAS pour moi.
-
Nope rien vu. S’il y avait eu un problème, même au taff, j’aurais eu des échos (pas de Fortnite le Mercredi ! Un drame national !)
Donc RAS pour moi.
CQFD
Que tu aies été victime de la fuite Icotera ou non, ta k-box semble avoir été à l'origine de tes soucis.
Je pense que les choses vont devenir beaucoup plus sereines pour toi 🙂
-
Si tu préfères acheter une usine à gaz qui sera supportée par le constructeur au mieux quelques mois, plutôt qu'utiliser un système tenu à jour dans la durée et qui te permet d'évoluer facilement dans le temps (parce que une fois ta config openwrt en place, rien de plus simple que de la migrer sur un hardware plus récent), libre à toi.
Comme je disais, le 802.11ax perso j'en ai strictement rien à faire. Mais rien ne vaut le marketing du "j'ai la plus grosse" pour continuer à remplir les décharges avec du matériel presque neuf, n'est-ce pas? ;)
C'est pas mal comme jugement péremptoire ! En gardant mes smartphones 5 ans minimum, mon dernier PC fixe 10 ans et j'en passe, évite de me mettre dans une case où je ne suis pas.
Pour moi aucune accélération matérielle ne justifie d'utiliser un firmware vérolé par d'innombrables CVEs kernel (les firmwares "officiels" tournent sur des versions noyau antédiluviennes abondamment patchées - dans le cas du R9000 on doit être sur un 3.10 du siècle dernier si ma mémoire est bonne).
Après chacun ses priorités, moi c'est la sécurité.
Il y a des CVE niveau kernel, il y en a à la pelle... Encore faut-il qu'elles soient exploitables, car si il faut déjà être utilisateur "lambda" sur le routeur, il faut souvent un prérequis de faille userland... On est d'accord qu'un constructeur grand public ne fait des mises à jour que lorsqu'il en a envie. Mais de là au tous les mettre dans le même panier... c'est un raccourci que je ne prendrai pas. Et OpenWRT, avec tout le respect que j'ai pour ce super projet, il eu aussi des CVE dont une à 10 (et c'est très moche ça).
Personnellement, mes routeurs il y a 15 ans, étaient en BSD avec pf (bien mieux que iptables, heureusement remplacé par nftables) lorsque j'avais de l'ADSL... mais avec la fibre, et les débit qui vont biens, je n'ai pas encore refait de routeur home-made sauce pfsense ou totalement "from scratch". A voir avec les appliances Netgate du coup !
-
CQFD
Que tu aies été victime de la fuite Icotera ou non, ta k-box semble avoir été à l'origine de tes soucis.
Je pense que les choses vont devenir beaucoup plus sereines pour toi 🙂
J’espère !
En tout cas merci pour ton suivi et tes conseils 8)
Bon, ça m’a coûté 200 euros le problème de box mais si ça me permet d’avoir une connexion stable…
-
Ah mais absolument, on est d'accord !
J'utilise le firmware Voxel justement parce qu'il est mis-à-jour très régulièrement avec les dernières mises-à-jour de sécurité (tous les mois au moins). Ce firmware utilise à la fois l'accélération matérielle, l'ouverture à la OpenWRT, et surtout les mises-à-jours des failles.
Tu peux me dire la version de noyau utilisée?
Parce qu'à moins d'un petit miracle, impossible d'utiliser un noyau récent ET l'accélération matérielle qui requiert des modules closed source qui ne tournent qu'avec le noyau fournit sur le firmware d'origine. Donc je m'attends à quelque chose comme une 3.10.X, pour lequel bon nombre de CVE exploitables et exploitées en remote existent. Donc une superbe passoire. Gênant pour un routeur...
-
Tu peux me dire la version de noyau utilisée?
Parce qu'à moins d'un petit miracle, impossible d'utiliser un noyau récent ET l'accélération matérielle qui requiert des modules closed source qui ne tournent qu'avec le noyau fournit sur le firmware d'origine. Donc je m'attends à quelque chose comme une 3.10.X, pour lequel bon nombre de CVE exploitables et exploitées en remote existent. Donc une superbe passoire. Gênant pour un routeur...
Sur le R7800, c'est le très vieux noyau 3.4.103 qui en effet est nécessaire pour l'accélération matérielle (merci Netgear >:( )
La bonne nouvelle est que le noyau étant Open Source, les failles ont été à ma connaissance patchées sur cette version (Voxel est très pointu dans les CVE et la sécurité, je ne suis qu'un amateur à côté, il pourrait en parler en détail, pas moi…)
-
Sur le R7800, c'est le très vieux noyau 3.4.103 qui en effet est nécessaire pour l'accélération matérielle (merci Netgear >:( )
Comme je disais. CQFD.
La bonne nouvelle est que le noyau étant Open Source, les failles ont été à ma connaissance patchées sur cette version (Voxel est très pointu dans les CVE et la sécurité, je ne suis qu'un amateur à côté, il pourrait en parler en détail, pas moi…)
Impossible: si tu touches au kernel d'origine, les modules propriétaires ne se chargeront plus (le hash du kernel change).
Ensuite je vois bien le bonhomme seul s'atteler à backporter l'ensemble des fixs CVE des kernels récents dont l'API a tellement changée qu'elle n'a plus rien à voir avec un 3.4.
Il y a une raison pour laquelle les vieux noyaux sont "EOL" et ne reçoivent plus de mise à jours. Le support 3.4 a pris fin en octobre 2016!
Pardonne-moi d'être un peu brutal mais tu es en plein rêve là: tu utilises une passoire. Libre à toi, mais ne va pas t'imaginer que tu es sur une plateforme sécurisée. Et ce serait judicieux d'éviter de prendre tes rêves pour des réalités en disant que "les failles ont été patchées" alors que c'est strictement impossible: tu induis potentiellement d'autres utilisateurs en erreur.
J'ajoute accessoirement que nulle part sur son README il n'indique qu'il touche au kernel, ce qui ne m'étonne pas comme expliqué ci-dessus, et son github ici https://github.com/SVoxel/R7800/ montre bien qu'il se contente de mettre à jour quelques utilitaires.
Non vraiment, on est bien sur une passoire atomique, à fuir absolument ;P
-
Comme je disais. CQFD.
Impossible: si tu touches au kernel d'origine, les modules propriétaires ne se chargeront plus (le hash du kernel change).
Ensuite je vois bien le bonhomme seul s'atteler à backporter l'ensemble des fixs CVE des kernels récents dont l'API a tellement changée qu'elle n'a plus rien à voir avec un 3.4.
Il y a une raison pour laquelle les vieux noyaux sont "EOL" et ne reçoivent plus de mise à jours. Le support 3.4 a pris fin en octobre 2016!
Pardonne-moi d'être un peu brutal mais tu es en plein rêve là: tu utilises une passoire. Libre à toi, mais ne va pas t'imaginer que tu es sur une plateforme sécurisée. Et ce serait judicieux d'éviter de prendre tes rêves pour des réalités en disant que "les failles ont été patchées" alors que c'est strictement impossible: tu induis potentiellement d'autres utilisateurs en erreur.
J'ajoute accessoirement que nulle part sur son README il n'indique qu'il touche au kernel, ce qui ne m'étonne pas comme expliqué ci-dessus, et son github ici https://github.com/SVoxel/R7800/ montre bien qu'il se contente de mettre à jour quelques utilitaires.
Non vraiment, on est bien sur une passoire atomique, à fuir absolument ;P
Non mais des CVE EXPLOITABLES en remote, y'en pas non plus tous les jours. Pour un routeur il faut que ça touche ce qui est Ethernet / IP / TCP|UDP... car la plupart des CVE sont des "local privilege escalation" donc il faut DÉJÀ un accès non-privilégié sur la machine, donc mettre à jour le userland permet de se prémunir de la très grosse majorité des soucis en réduisant drastiquement la surface d'attaque possible. Bref, ce nc'est pas pour rien qu'il y a des score au CVE aussi hein..
-
Non mais des CVE EXPLOITABLES en remote, y'en pas non plus tous les jours. Pour un routeur il faut que ça touche ce qui est Ethernet / IP / TCP|UDP... car la plupart des CVE sont des "local privilege escalation" donc il faut DÉJÀ un accès non-privilégié sur la machine, donc mettre à jour le userland permet de se prémunir de la très grosse majorité des soucis en réduisant drastiquement la surface d'attaque possible. Bref, ce nc'est pas pour rien qu'il y a des score au CVE aussi hein..
T'as bien raison. En v'la 3-4 score 10, remote, complexité "low", parfaitement exploitables et qui affectent le noyau 3.4, et qui concernent directement l'utilisation type d'un routeur. Juste pour rire.
https://www.cvedetails.com/cve/CVE-2016-10229/
https://www.cvedetails.com/cve/CVE-2015-8787/
https://www.cvedetails.com/cve/CVE-2016-7117/
https://www.cvedetails.com/cve/CVE-2017-18017/
Aller une petite dernière en IPv6, pour la route: https://www.cvedetails.com/cve/CVE-2018-5703/
Je pourrais continuer la liste est longue.
Après on peut se mettre la tête dans le sable et se dire que ça sert à rien d'avoir un kernel à jour, et que personne va s'amuser à attaquer un pékin moyen. C'est une approche. En général c'est comme ça que les botnets sont exploités :P
-
De ce que je comprends, le EOL du kernel n'est pas à cause des CVE, mais à cause des nouvelles fonctionnalités dans les noyaux suivants… (bref, c'est logique qu'à un moment, de son ancienneté un noyau ne soit plus supporté).
Le noyau du firmware n'est pas le kernel 3.4.103 d'origine, mais une version modifiée et supportée par QCA avec des correctifs apportés par QCA jusqu'à au moins 2019.
Enfin, Voxel m'a confirmé avoir ajouté lui-même les correctifs CVE à sa version (c'est dans son log). Par exemple:
1.0.2.68SF:
1. Kernel vulnerability: CVE-2019-11477, CVE-2019-11478, CVE-2019-11479 are fixed.
https://nvd.nist.gov/vuln/detail/CVE-2019-11477
https://nvd.nist.gov/vuln/detail/CVE-2019-11478
https://nvd.nist.gov/vuln/detail/CVE-2019-11479
Donc ce n'est pas forcément plus vulnérable qu'OpenWRT où le noyau 5.10 est utilisé pour le R7800 (CVEs pour ce noyau 5.10: https://vulmon.com/searchpage?q=linux+linux+kernel+5.10 ).
Enfin, comme le précise Ralph, les failles doivent être exploitables, demandant un accès direct au terminal (donc accès telnet ou ssh…), et certaines sont sans effet sur le routeur, comme une vulnérabilité du module x86/x64 pour les instructions AES ou sur un pilote de cd-rom…
Après, je n'ai rien contre OpenWRT, mais l'absence d'accélération matérielle est vraiment dommage… C'est pour moi perdre une grosse fonctionnalité du routeur.
Je ne vais pas critiquer ton choix, que je comprends parfaitement et respecte. On se rejoint sur le fait que la sécurité et un accès au routeur sont importants ; après, il faudrait comparer point par point tous les CVE etc… pour savoir quelle solution est la plus sécuritaire.
La honte, c'est les firmwares officiels, qui eux sont ouvertsaux failles, et sont de loin les plus utilisés…
N'oublions pas enfin que je monitor régulièrement mon routeur (processus, cpu, mémoire, traffic, IRQ, etc…), donc si son comportement venait à changer (botnet), je le vois. L'accès au terminal du routeur est très sécurisé : aucun accès distant depuis internet, même pour moi, aucun accès telnet, seulement SSH avec obligatoirement avec une clé… Mon LAN est protégé aussi, port knockers etc…
C'est en faisant du monitoring justement que j'ai repéré le problème DHCPv6 d'ailleurs… L'activité SoftIRQ et CPU du routeur étaient un peu plus élevés… J'ai du coup vérifié aussi le monitoring de mon ONT (que je check aussi régulièrement de toute façon) et j'ai vu cette charge anormale de paquets multicast… Un tcpdump sur le routeur m'a montré le problème.
EDIT (ajout) :
Après avoir échangé avec Voxel, il m'indique (assez logiquement) que les vulnérabilités du noyau les plus dangereuses sont celles où l'attaquant peut attaquer via le port WAN sans besoin d'être connecté au terminal du routeur : buffer overflow, DDoS… Et d'autant qu'il le sache toutes ces failles ont été fixées dans ses firmwares.
Il rappel que la règle d'or est de ne pas autoriser d'accès au routeur via HTTPS, de ne pas activer ReadyCLOUD, ni miniupndp, et si besoin d'accès à distance de n'utiliser que SSH depuis le WAN.
Ce qui est le plus vulnérable dans le firmware natif et le sien, c'est ReadyCLOUD/Kwilt (CVEs OpenSSL 1.0.2), une vieille version de miniupnpd (pas de code source pour le corriger), l'accès par https (CVEs OpenSSL 1.0.2).
Ainsi que ReadySHARE (si l'attaquant a accès depuis le LAN), ce qui est identique pour OpenWRT.
Sur mon routeur, j'ai déjà tout cela désactivé, et tout ce qui appel à la maison de Netgear ou Amazon Cloud ou autre… Et je n'autorise même pas un accès SSH au routeur depuis le WAN.
-
T'as bien raison. En v'la 3-4 score 10, remote, complexité "low", parfaitement exploitables et qui affectent le noyau 3.4, et qui concernent directement l'utilisation type d'un routeur. Juste pour rire.
https://www.cvedetails.com/cve/CVE-2016-10229/
https://www.cvedetails.com/cve/CVE-2015-8787/
https://www.cvedetails.com/cve/CVE-2016-7117/
https://www.cvedetails.com/cve/CVE-2017-18017/
Aller une petite dernière en IPv6, pour la route: https://www.cvedetails.com/cve/CVE-2018-5703/
Je pourrais continuer la liste est longue.
Après on peut se mettre la tête dans le sable et se dire que ça sert à rien d'avoir un kernel à jour, et que personne va s'amuser à attaquer un pékin moyen. C'est une approche. En général c'est comme ça que les botnets sont exploités :P
C'est cool, je sais aussi faire une recherche de CVE rank 10, mais quand tu vois que par exemple pour la CVE-2017-18017 il faut "presence of xt_TCPMSS in an iptables action", on peut pas dire que ça soit la configuration classique... Surtout que les correctifs de toutes les CVE remontées sont assez triviaux : le git diff fait pas plus d'une page. Donc pas besoin avoir une 5.17.4 pour se sentir en sécurité, les backports peuvent se faire facilement (et c'est pas comme si j'en avait pas fait dans ma "jeunesse" sur un kernel concurrent). Après, un routeur qui laisserait entrer de l'UDP non sollicité (pour la CVE-2016-10229) c'est clair qu'il doit finir à la poubelle.
Et bon, généralement suite à ce genre de CVE, tu as quand même des mises à jours chez certains constructeurs. Il y a 807 patchs sur le Kernel 3.12 utilisé sur un Archer AX50 par exemple, avec des noms très explicites. D’ailleurs il y a du code openwtr aussi dedans :D
Sinon, les botnets, c'est pas franchement les routeurs qui les compose mais des machines PC avec des malwares et de l'IoT, caméra de surveillance et autres objets connectés 100 fois moins sécurisés qu'un routeur du reste.
-
C'est cool, je sais aussi faire une recherche de CVE rank 10, mais quand tu vois que par exemple pour la CVE-2017-18017 il faut "presence of xt_TCPMSS in an iptables action", on peut pas dire que ça soit la configuration classique...
Faux. C'est une configuration très classique. Google "TCP MSS Clamping".
Surtout que les correctifs de toutes les CVE remontées sont assez triviaux : le git diff fait pas plus d'une page. Donc pas besoin avoir une 5.17.4
pour se sentir en sécurité, les backports peuvent se faire facilement (et c'est pas comme si j'en avait pas fait dans ma "jeunesse" sur un kernel concurrent).
Encore faux. Quand les API concernées ont changé d'une version à l'autre, il peut devenir très difficile voir quasiment impossible de backporter certains fixes. Ou alors avec le risque d'introduire d'autres bugs quand une adaptation trop importante est faite sans contrôle.
Après, un routeur qui laisserait entrer de l'UDP non sollicité (pour la CVE-2016-10229) c'est clair qu'il doit finir à la poubelle.
Oui parce que c'est bien connu, la plupart des configs par défaut des routeurs commerciaux sont toujours bien ficelées :)
Et bon, généralement suite à ce genre de CVE, tu as quand même des mises à jours chez certains constructeurs. Il y a 807 patchs sur le Kernel 3.12 utilisé sur un Archer AX50 par exemple, avec des noms très explicites. D’ailleurs il y a du code openwtr aussi dedans :D
Oui. Certains constructeurs patchent ce qu'ils peuvent, quand ils le veulent bien (quand ils le veulent pas, l'utilisateur final l'a dans l'os). Le 3.12 a été maintenu à jour 1 an de plus que le 3.4 mentionné par bolemo.
Mais curieusement, j'ai plus tendance à faire confiance à un OS complètement opensource avec une équipe dédiée qui suit les alertes de sécurité de près et publie les patchs rapidement et en communiquant correctement dessus, qu'à un OS tenu à bout de bras par un gars tout seul dans son coin. Je dois être biaisé :)
De ce que je comprends, le EOL du kernel n'est pas à cause des CVE, mais à cause des nouvelles fonctionnalités dans les noyaux suivants… (bref, c'est logique qu'à un moment, de son ancienneté un noyau ne soit plus supporté).
C'est exactement ça, et c'est exactement ce qui rend la maintenance des vieux kernels difficile. L'ajout de "nouvelles fonctionnalités", ça peut être aussi des changements d'API, des modifications dans la structure du code, qui font qu'un fix qui fonctionne sur un kernel récent peut ne pas être applicable ou ne pas fonctionner sur un vieux kernel. Donc au bout d'un moment, les mainteneurs estiment qu'il est temps de passer à autre chose, ce qui est logique.
Le noyau du firmware n'est pas le kernel 3.4.103 d'origine, mais une version modifiée et supportée par QCA avec des correctifs apportés par QCA jusqu'à au moins 2019.
Donc plus mis à jour depuis bientôt 3 ans. Securitas maximus. Et qui te dit que QCA a pu traiter toutes les CVEs si par exemple certaines ne bénéficient pas d'un patch proposé par les devs kernel (les kernels EOL ne reçoivent précisément plus ces patchs)?
Enfin, Voxel m'a confirmé avoir ajouté lui-même les correctifs CVE à sa version (c'est dans son log). Par exemple:
Intéressant. On peut voir le source code de ces correctifs?
Donc ce n'est pas forcément plus vulnérable qu'OpenWRT où le noyau 5.10 est utilisé pour le R7800 (CVEs pour ce noyau 5.10: https://vulmon.com/searchpage?q=linux+linux+kernel+5.10 ).
T'as pas du bien comprendre le concept: le 5.10 utilisé par OpenWRT, il est maintenu par les devs kernel jusqu'en décembre 2026 (décembre 2025 pour le 5.4 sur OpenWRT 21.02), et la version fournie par OpenWRT est une des dernières disponibles au moment de la release: donc le kernel proposé contient tous les fixs disponibles pour toutes les CVEs connues à date de release.
J'ajoute que pour les drivers wifi, ils vont même plus loin puisque typiquement ils backportent les drivers de kernels plus récents pour bénéficier du meilleur support et des meilleures performances possibles ET de la sécurité.
Enfin, comme le précise Ralph, les failles doivent être exploitables, demandant un accès direct au terminal (donc accès telnet ou ssh…), et certaines sont sans effet sur le routeur, comme une vulnérabilité du module x86/x64 pour les instructions AES ou sur un pilote de cd-rom…
Oui je te remercie de donner des exemples absurdes. Les CVE que j'ai listée sont exploitables dès lors qu'il y a un échange réseau quel qu'il soit entre une machine malicieuse et une autre machine. Sur un routeur, certaines failles sont exploitables dès lors que le routeur voit simplement _passer_ ce traffic. Les CVE que j'ai indiquées et celles que tu mentionnes sont dans ce cas.
Après, je n'ai rien contre OpenWRT, mais l'absence d'accélération matérielle est vraiment dommage… C'est pour moi perdre une grosse fonctionnalité du routeur.
ça dépend ce que tu as comme lien derrière, et ça dépend du routeur. Une nanopi R2S n'a pas besoin d'accélération matérielle pour saturer un lien giga par exemple. (c'est pas un routeur wifi, mais c'est pour illustrer).
Je ne vais pas critiquer ton choix, que je comprends parfaitement et respecte. On se rejoint sur le fait que la sécurité et un accès au routeur sont importants ; après, il faudrait comparer point par point tous les CVE etc… pour savoir quelle solution est la plus sécuritaire.
La honte, c'est les firmwares officiels, qui eux sont ouvertsaux failles, et sont de loin les plus utilisés…
N'oublions pas enfin que je monitor régulièrement mon routeur (processus, cpu, mémoire, traffic, IRQ, etc…), donc si son comportement venait à changer (botnet), je le vois. L'accès au terminal du routeur est très sécurisé : aucun accès distant depuis internet, même pour moi, aucun accès telnet, seulement SSH avec obligatoirement avec une clé… Mon LAN est protégé aussi, port knockers etc…
C'est en faisant du monitoring justement que j'ai repéré le problème DHCPv6 d'ailleurs… L'activité SoftIRQ et CPU du routeur étaient un peu plus élevés… J'ai du coup vérifié aussi le monitoring de mon ONT (que je check aussi régulièrement de toute façon) et j'ai vu cette charge anormale de paquets multicast… Un tcpdump sur le routeur m'a montré le problème.
C'est très bien. Tu es un poweruser et tu fais attention. Mais quand tu encourages des utilisateurs lambda à utiliser du matériel et un firmware "bof bof" pour le dire poliment (accessoirement utiliser un firmware maintenu par un seul gugus - a priori sans peer review en plus? - c'est pas franchement une solution très robuste si le gugus passe à autre chose pour X raison) tu ne pars j'espère pas du principe qu'ils vont passer autant de temps que toi à surveiller leur routeur comme le lait sur le feu?
Pour info moi j'aime bien quand je branche, ça tourne et je l'oublie. La vie est trop courte pour se farcir un monitoring quotidien d'un truc aussi simple et sans intérêt qu'un routeur ;P
EDIT (ajout) :
Après avoir échangé avec Voxel, il m'indique (assez logiquement) que les vulnérabilités du noyau les plus dangereuses sont celles où l'attaquant peut attaquer via le port WAN sans besoin d'être connecté au terminal du routeur : buffer overflow, DDoS… Et d'autant qu'il le sache toutes ces failles ont été fixées dans ses firmwares.
"D'autant qu'il sache". Nous voila bien rassurés :)
Il rappel que la règle d'or est de ne pas autoriser d'accès au routeur via HTTPS, de ne pas activer ReadyCLOUD, ni miniupndp, et si besoin d'accès à distance de n'utiliser que SSH depuis le WAN.
Again, les CVEs mentionnées plus haut affectent n'importe quel noyau qui fait du traffic réseau de base. Pas besoin de port ouvert!
Aller, j'en reste là, j'ai exposé mes arguments, libre à chacun de faire ce qu'il veut. Bisous.
PS: pour le contexte: je suis actuellement contributeur OpenWRT, et j'ai été pendant pas mal d'années contributeur du noyau Linux (même si je suis moins actif, il y a encore pas mal de code à moi dedans, drivers, support d'architectures exotiques, etc). Juste pour dire que j'ai une petite idée de quoi je parle quand j'en parle 8)
-
Faux. C'est une configuration très classique. Google "TCP MSS Clamping".
Pourquoi j'ai une configuration de MTU hors iptable ? Parce que ça peut se faire sans (et dans 99% des cas du reste). oui c'est pas le plus optimale car TOUT ce que passe par l'interface à MTU réduite perd un peu en efficacité, mais au moins pas besoin d'iptable. C'est dans ce deuxième cas qu'il y a la faille.
Encore faux. Quand les API concernées ont changé d'une version à l'autre, il peut devenir très difficile voir quasiment impossible de backporter certains fixes. Ou alors avec le risque d'introduire d'autres bugs quand une adaptation trop importante est faite sans contrôle.
Bon, en gros tu es entrain de me dire que parce que ça a été super modifié, on ne peut plus backporter... Tu ne te demandes pas si il y a eu autant de modifications, est-ce que la vulnérabilité est encore là ? Bon, j'ai bien compris que tu n'avais jamais du toucher une ligne de code à ce niveau, car disons que des backport sur des kernels, c'était un peu mon boulot il y a 15 ans, donc ce que tu me racontes, c'est pas comme si je ne l'avais pas connu sur du BSD et plus récemment sur Linux (à titre personnel cette fois). Bref...
Et au passage, tu es au courant que légalement tous les constructeurs doivent mettre à disposition les patchs du kernel car en GPLv2... Certains jouent le jeu, d'autres pas en effet. Mais bon, c'est pas aussi moche que les FAI en France.
PS: en tout cas, ce n'est pas tout ça qui me rendra le téléphone chez K-Net :D
-
Je vois qu'on affute les couteaux ! ;D :o
Je ne vais certainement pas entrer dans les accusations… Je ne vous connais ni l'un ni l'autre, et je ne peux que considérer que vous êtes tous les deux sincères dans vos propos.
Au final, concernant les firmwares, je pense qu'on est tous d'accord sur le principe que :
– la sécurité est importante et trop souvent négligée (par les fabricants de routeurs grand public) ou méconnue (du grand public),
– les projets opensource comme OpenWRT, avec de nombreux contributeurs et vérificateurs, sont une très bonne chose, et on aimerait dans l'idéal que les constructeurs permettent un accès à toutes leurs spécifications pour permettre l'accélération matérielle et l'accès à toutes les ressources et possibilités qu'offre la machine.
Je trouve personnellement l'initiative de Voxel très louable. Son code est ouvert, on peut le compiler soi-même (je l'ai fait), et son objectif est triple : 1) augmenter la sécurité, 2) optimiser, 3) offrir un accès au routeur (ssh, Entware…)
Oui, il est seul, mais comme précisé, son code est ouvert. Il compile avec les derniers toolchains et compilateurs, avec des options pointues spécifique au processeur que même Netgear n'utilise pas, il surveille les publications CVE et met à jour en fonction… Bref, pour un gars tout seul, c'est honorable et impressionnant même, on ne va pas lui cracher dessus quand même…
Il offre un firmware amélioré qui donne accès à toute la puissance de ce qu'offre le routeur, est plus sécurisé et permet d'y accéder.
Même des personnes chez Netgear recommandent officieusement d'utiliser son firmware, car l'officiel est assez honteux…
Il y a toute une communauté sur SNB qui utilise son firmware, pose des questions, et il y a un support qui est ainsi fait… D'autre y proposent des utilitaires comme Kamoj avec un adon bien foutu ou moi avec Aegis.
Est-ce parfait ? Non, évidemment non… OpenWRT ne l'est pas non plus, et pas ou peu de routeurs récent n'est compatible (pas la faute d'OpenWRT).
Si on parlait d'entreprise et non d'un petit LAN perso sans vraie donnée sensible, alors oui, la sécurité maximale et garantie (autant que possible) serait de mise, et le routeur ne serait probablement pas un truc grand public…
Le jour où je devrai changer de routeur, je chercherai une solution 100% Open ; peut-être avec Pfsense ou quelque chose comme ça, ou un routeur 100% supporté par OpenWRT (accélération incluse).
-
Bon, en gros tu es entrain de me dire que parce que ça a été super modifié, on ne peut plus backporter... Tu ne te demandes pas si il y a eu autant de modifications, est-ce que la vulnérabilité est encore là ? Bon, j'ai bien compris que tu n'avais jamais du toucher une ligne de code à ce niveau, car disons que des backport sur des kernels, c'était un peu mon boulot il y a 15 ans, donc ce que tu me racontes, c'est pas comme si je ne l'avais pas connu sur du BSD et plus récemment sur Linux (à titre personnel cette fois). Bref...
T'es mignon mais tu comprends pas ce que je dis. Cet article est un excellent exemple par l'absurde du problème:
https://blog.qiqitori.com/2018/02/backporting-security-fixes-to-old-versions-of-the-linux-kernel-meltdown-to-2-6-18-part-1/ (https://blog.qiqitori.com/2018/02/backporting-security-fixes-to-old-versions-of-the-linux-kernel-meltdown-to-2-6-18-part-1/)
J'espère que tu peux lire l'anglais. Le point le plus important est à la fin:
It’s a lot of work, and if you do not include the time it takes to read through the Meltdown papers and the news to get a good overview of what needs to be done, it took me about two to three weeks to get a still-broken patch that causes the system to panic
Voilà, j'insiste pas, si là c'est toujours pas clair c'est pas la peine de se fatiguer.
Et je te remercie de me prendre pour un c**, moi je ne me le suis pas permis mais maintenant ça va probablement changer :)
Donc juste pour ton info toi t'as peut-être fait du backport de quelques patchs kernel, moi j'ai participé au portage du kernel sur une arch. From scratch, y compris bootstrap toolchain etc. Si tu sais pas ce que c'est, c'est quand tu démarres à poil avec juste la doc sur l'ISA de la machine. Donc je sais pas à quel "niveau" tu places ça mais la mienne est plus grosse je pense. ;D
Le jour où je devrai changer de routeur, je chercherai une solution 100% Open ; peut-être avec Pfsense ou quelque chose comme ça, ou un routeur 100% supporté par OpenWRT (accélération incluse).
Un conseil: oublie pfsense ;)
Des bisous.
-
Un conseil: oublie pfsense ;)
Merci du conseil.
Quel est d'après toi le meilleur système récent, totalement ouvert, avec accélération matérielle ?
Non pas que j'ai besoin de changer de routeur, le miens remplis amplement mes besoins, mais j'aimerais avoir une idée d'où regarder pour le jour où (ou en cas de panne soudaine), et commencer à me renseigner.
-
Merci du conseil.
Quel est d'après toi le meilleur système récent, totalement ouvert, avec accélération matérielle ?
Non pas que j'ai besoin de changer de routeur, le miens remplis amplement mes besoins, mais j'aimerais avoir une idée d'où regarder pour le jour où (ou en cas de panne soudaine), et commencer à me renseigner.
Je crois que je me suis déjà exprimé sur le sujet?
Et je ne vois pas l'intérêt de se focaliser sur l'accélération matérielle qui n'a aucun sens sur un home router.
À mes yeux une bonne gestion de la latence est bien plus importante, en utilisant par exemple CAKE ou fq_codel, ce qui est incompatible avec l'accélération matérielle.
Enfin si c'est une case à cocher pour toi, il faut regarder dans la famille des MT76xx.
-
Hello,
Ça fait 3 ans que je suis sur mon ERX et tout fonctionne parfaitement. Réseau Covage 77
-
T'es mignon mais tu comprends pas ce que je dis. Cet article est un excellent exemple par l'absurde du problème:
https://blog.qiqitori.com/2018/02/backporting-security-fixes-to-old-versions-of-the-linux-kernel-meltdown-to-2-6-18-part-1/ (https://blog.qiqitori.com/2018/02/backporting-security-fixes-to-old-versions-of-the-linux-kernel-meltdown-to-2-6-18-part-1/)
J'espère que tu peux lire l'anglais. Le point le plus important est à la fin:
Voilà, j'insiste pas, si là c'est toujours pas clair c'est pas la peine de se fatiguer.
Et je te remercie de me prendre pour un c**, moi je ne me le suis pas permis mais maintenant ça va probablement changer :)
Donc juste pour ton info toi t'as peut-être fait du backport de quelques patchs kernel, moi j'ai participé au portage du kernel sur une arch. From scratch, y compris bootstrap toolchain etc. Si tu sais pas ce que c'est, c'est quand tu démarres à poil avec juste la doc sur l'ISA de la machine. Donc je sais pas à quel "niveau" tu places ça mais la mienne est plus grosse je pense. ;D
Un conseil: oublie pfsense ;)
Des bisous.
Sortie du noyau Linux 2.6.18, 20 sept. 2006 .... Meldown + Spectre ont été rendus public le 3 janvier 2018. Alors Ok, la branche 2.6 a eu une longue vie, mais 11 ans... surtout pour un backport ttrrrèèès loin d'être un vulnérabilité d'erreur de code : on parle de rattraper un soucis de conception hardware, donc j'ai connu mieux comme "exemple".
Et curieux de savoir sur quelle archi le portage à été fait.
Sans compter que le "oublie pfsense" sans argument, ça serait bien d'expliquer pourquoi.
-
Bon, je reviens ici après un peu plus de recul sur l’achat d’un routeur perso vs la KBox Icotera que j’avais auparavant, sur les conseils de bolemo.
Et c’est juste parfait. Je n’ai plus aucune coupure, la connexion fonctionne parfaitement à présent et les micro deco ne sont plus qu’un mauvais souvenir.
Et au passage, mon wifi est plus puissant et plus stable aussi.
Bref, merci bolemo et je vais renvoyer la KBox asap.
Je reste épaté par la compétence technique de la communauté KNet qui a réussi à isoler l’origine du problème, un des rares points très positifs restant à ce FAI (qui devrait en tirer les enseignements au plus vite du reste. Peut être de l’ingé réseau à recruter en urgence ?).
-
Bon, je reviens ici après un peu plus de recul sur l’achat d’un routeur perso vs la KBox Icotera que j’avais auparavant, sur les conseils de bolemo.
Et c’est juste parfait. Je n’ai plus aucune coupure, la connexion fonctionne parfaitement à présent et les micro deco ne sont plus qu’un mauvais souvenir.
Et au passage, mon wifi est plus puissant et plus stable aussi.
Bref, merci bolemo et je vais renvoyer la KBox asap.
Je reste épaté par la compétence technique de la communauté KNet qui a réussi à isoler l’origine du problème, un des rares points très positifs restant à ce FAI (qui devrait en tirer les enseignements au plus vite du reste. Peut être de l’ingé réseau à recruter en urgence ?).
Merci Coucouyou pour ton retour.
Ça fait plaisir de voir quelque chose qui fonctionne parfaitement :)
K-Net est un G-Nest (G pour geek) ;)