La Fibre
Datacenter et équipements réseaux => Routeurs => 
Remplacer la LiveBox par un routeur => Discussion démarrée par: ubune le 03 juillet 2018 à 09:17:47
-
<-- Tutoriel vous permettant de remplacer votre Livebox par un routeur avec système d'exploitation Linux Openwrt. -->
(https://i.ibb.co/m5bYPSk/github.png) (https://github.com/ubune/openwrt-livebox)
Edit 11/11/2022 : Fichiers et explication pour mise en service immédiate dispo sur Github => https://github.com/ubune/openwrt-livebox ;)
Edit 12/02/2023 : Astuce, comment utiliser imagebuilder pour générer votre .img qui contient tous vos packages et votre /etc fonctionnel ! => ici (https://lafibre.info/remplacer-livebox/remplacement-de-la-livebox-par-un-routeur-openwrt-18-dhcp-v4v6-tv/msg1002177/#msg1002177)
Edit 18/05/2023 : Attention, revérifiez votre fichier network, il y a eu beaucoup de changement sur les options envoyées (ipv4 ET ipv6) suite au nouveau durcissement de l'authentification auprès d'Orange.
Edit 20/10/2023 : Compatible avec la version 23.05 ;)
Info => https://openwrt.org/
Prerequis :
Avoir un ONT Orange ou un ONT perso bien connecté/auth avec l'OLT (voir section ont du forum), personnellement, j'ai celui-ci => Leox LXT-010H-D
Avoir récupéré ses identifiants FTI.
Un routeur compatible openwrt et avec assez de perf pour gérer les 2Gbps (sauf si abonnement sosh ^^').
Informations sur Openwrt =>
Pour récupérer votre version, il faut identifier le soc de votre routeur, exemple sur un ubiquiti edgerouterx => https://openwrt.org/toh/hwdata/ubiquiti/ubiquiti_edgerouter_x
On retrouve dans target : ramips et subtarget : mt7621.
Une fois ces éléments identifiés, on peut aller sur https://downloads.openwrt.org pour récupérer la version correspondante.
Présentation rapide de l'architecture Openwrt :
Sur Openwrt, vos fichiers de configurations se trouvent dans /etc/config, par exemple par défaut on retrouve :
/etc/config/network pour la configuration des interfaces réseau, des routes statiques...
/etc/config/Firewall pour la configuration du parefeu, du nat, des zones etc.
/etc/config/dhcp pour la config des serveurs dhcp/dhcpv6 et les annonces RA ipv6...).
Nativement, l'interface Wan est en dhcp (client) et l'interface Lan (ou br-lan) est configurée en 192.168.1.1/24 en dhcp (serveur) et avec annonce d'un préfixe ULA, le routeur est joignable en ssh/https
user root mdp vide.
PARTIE 1 : INTERNET
Récupérez votre login/pass FTI, et direction https://jsfiddle.net/kgersen/3mnsc6wy/ (Merci !) pour générer votre option 90.
Dans ce tuto, nous simulons le login suivant :
fti/qpq8888
12345622
Qui donne :
00000000000000000000001a090000055801034101116674692F6674692F717071383838383c1231323334353637383930313233343536031341302f6f2d83fc857d7829d65ddea775d7
Pour remplacer la livebox par votre propre routeur nous avons besoin :
- De votre option 90 générée grâce au script de kgersen.
- De configurer l'interface Wan en utilisant le VLAN 832 en dhcp => /etc/config/network
- D'envoyer les bonnes options dhcp permettant l'authentification auprès d'orange => /etc/config/network
- D'envoyer tout le flux qui ne passe pas par nftables en priorité L2 (802.1p) CS6 => /etc/config/network (egress mapping)
- Gérer les files pour éviter les pbs de débit (on remet bien notre traffic internet avec des priorités cohérentes) => nft rules
- De l'adresse mac de votre livebox (ou d'une adresse mac fixe, qui sera associé à l'interface vlan 832 et aux options "client ID" envoyées.
nano /etc/config/network
Dans le fichier network on doit retrouver :
Config Lan :
config interface 'lan'
option proto 'static'
option ipaddr '192.168.1.1'
option netmask '255.255.255.0'
option ip6assign '64'
option ip6ifaceid '::bad'
option device 'br-lan'
Config eth0.832 avec mapping :
Attention, n'hésitez pas à creer la sous interface wan "vlan832" depuis l'interface web (luci) et ensuite d'aller voir votre fichier network, car en fonction du modèle de routeur ce n'est pas exactement le même nom d'interface (intf physique).
Dans notre cas, le wan du routeur est "eth0", mais chez certains, il se nomme "wan" ou "eth1".
config device
option name 'eth0.832'
option type '8021q'
option ifname 'eth0'
option vid '832'
list egress_qos_mapping '1:0'
list egress_qos_mapping '0:6'
list egress_qos_mapping '6:6'
option macaddr 'A2:34:56:78:19:26' # Si vous voulez garder la même ip publique et préfixe que votre livebox lors du changement, remplacez A23456781926 par l'adresse mac de votre livebox, ne pas oublier le client id plus bas qui doit avoir la meme valeur que l'adresse mac de votre interface wan !
Config Wan ipv4 :
config interface 'wan4'
option proto 'dhcp'
option device 'eth0.832'
option hostname '*'
option broadcast '1'
option norelease '1' #si vous ne voulez pas changer d'ip publique à chaque reboot ;)
option vendorid 'sagem'
option reqopts '1 3 6 15 28 51 58 59 90 119 125'
option sendopts '77:2b46535644534c5f6c697665626f782e496e7465726e65742e736f66746174686f6d652e4c697665626f7836 90:00000000000000000000001a090000055801034101116674692F6674692F717071383838383c1231323334353637383930313233343536031341302f6f2d83fc857d7829d65ddea775d7'
option clientid '01A23456781926' # Doit correspondre à 01 + l'adresse mac sans les : de votre interface vlan 832 !
Config Wan ipv6
config interface 'wan6'
option proto 'dhcpv6'
option device 'eth0.832'
option reqprefix 'auto'
option reqaddress 'none'
option defaultreqopts '0'
option sendopts '11:00000000000000000000001a090000055801034101116674692F6674692F717071383838383c1231323334353637383930313233343536031341302f6f2d83fc857d7829d65ddea775d7 15:FSVDSL_livebox.Internet.softathome.Livebox6 16:0000040e0005736167656d 17:000005580006000e495056365f524551554553544544'
option reqopts '11 17 23 24'
option noclientfqdn '1'
option noacceptreconfig '1'
option clientid '00030001A23456781926' # Doit correspondre à 00030001 + l'adresse mac sans les : de votre interface vlan 832 !
NFT rules, on créé un fichier contenant nos règles (pour le remapping l2 des flux), qui sera lancé en même temps que le firewall
nano /etc/nftables.d/nft-prio6-rules.include
oifname "eth0.832" counter meta priority set 0:1
oifname "eth0.832" ip protocol icmp counter meta priority set 0:6
oifname "eth0.832" ip protocol igmp counter meta priority set 0:6
oifname "eth0.832" udp dport 67 counter meta priority set 0:6
oifname "eth0.832" udp dport 547 counter meta priority set 0:6
oifname "eth0.832" ip protocol icmpv6 counter meta priority set 0:6
nano /etc/config/firewall
config include 'orange_rules'
option enabled '1'
option type 'nftables'
option path '/etc/nftables.d/nft-prio6-rules.include'
option position 'chain-append'
option chain 'mangle_postrouting'
Zone Wan
config zone
option name 'wan'
option output 'ACCEPT'
option family 'ipv4' ## Zone ipv4 only pour ne pas mélanger les règles sur les deux mondes
list network 'wan4'
option forward 'DROP'
option masq '1' ## On remplace l'ip source "privée" des flux sortant sur internet par l'ip publique reçu sur le wan4.
option input 'DROP'
Zone Wan6
config zone
option name 'wan6'
option input 'DROP'
option output 'ACCEPT'
option forward 'DROP'
option family 'ipv6' ## Zone ipv6 only pour ne pas mélanger les règles sur les deux mondes
list network 'wan6'
list device 'eth0.832'
Config des Rules :
config rule
option name 'Allow-DHCP-Renew'
option src 'wan'
option proto 'udp'
option dest_port '68'
option target 'ACCEPT'
option family 'ipv4'
config rule
option name 'Allow-Ping'
option src 'wan'
option proto 'icmp'
option icmp_type 'echo-request'
option family 'ipv4'
option target 'ACCEPT'
config rule
option name 'Allow-IGMP'
option src 'wan'
option proto 'igmp'
option family 'ipv4'
option target 'ACCEPT'
config rule
option name 'Allow-DHCPv6'
option proto 'udp'
option dest_port '546'
option family 'ipv6'
option target 'ACCEPT'
option src 'wan6'
list src_ip 'fc00::/6'
list dest_ip 'fc00::/6'
config rule
option name 'Allow-MLD'
option proto 'icmp'
option family 'ipv6'
option target 'ACCEPT'
option src 'wan6'
list src_ip 'fe80::/10'
config rule
option name 'Allow-ICMPv6-Input'
option proto 'icmp'
option limit '1000/sec'
option family 'ipv6'
option target 'ACCEPT'
list icmp_type 'bad-header'
list icmp_type 'destination-unreachable'
list icmp_type 'echo-reply'
list icmp_type 'echo-request'
list icmp_type 'neighbour-advertisement'
list icmp_type 'neighbour-solicitation'
list icmp_type 'packet-too-big'
list icmp_type 'router-advertisement'
list icmp_type 'router-solicitation'
list icmp_type 'time-exceeded'
list icmp_type 'unknown-header-type'
option src 'wan6'
config rule
option name 'Allow-ICMPv6-Forward'
option dest '*'
option proto 'icmp'
option limit '1000/sec'
option family 'ipv6'
option target 'ACCEPT'
list icmp_type 'bad-header'
list icmp_type 'destination-unreachable'
list icmp_type 'echo-reply'
list icmp_type 'echo-request'
list icmp_type 'packet-too-big'
list icmp_type 'time-exceeded'
list icmp_type 'parameter-problem'
list icmp_type 'unknown-header-type'
option src 'wan6'
Config Forwarding :
config forwarding
option src 'lan'
option dest 'wan'
config forwarding
option src 'lan'
option dest 'wan6'
config forwarding #Attention, ici c'est en mode freebox, on autorise le flux wan6 to lan
option src 'wan6'
option dest 'lan'
DHCPv4 + RA (ipv6, Router Advertisement), pour le LAN
nano /etc/config/dhcp
Ici on ne fait pas de dhcpv6, uniquement du RA, on annonce le premier /64 du /56 au lan (pour l'autoconfiguration des machines) + serveur dhcpv4.
config dhcp 'lan'
option interface 'lan'
option start '100'
option limit '59'
option leasetime '12h'
option dhcpv4 'server'
option ra 'server'
list ra_flags 'none'
Une fois tout ceci fait, vous pouvez supprimer votre livebox et connecter directement votre nouveau routeur openwrt sur l'ont orange. Vous devriez recevoir votre ip publique ainsi que votre /56 sur l'eth0.832.
Commandes utiles pour vérifier tout ça :
ifstatus wan4
ifstatus wan6
Et voila ! Vous devriez être IPV6 Ready un test sur http://ipv6-test.com/ et vous obtiendrez un score de 19/20 (si vous avez la rule forward icmpv6 et que votre machine accepte l'icmpv6).
PARTIE 2 : TV VLAN 840
Installation d'igmp proxy :
opkg update && opkg install igmpproxy
On modifie le fichier /etc/config/igmpproxy
config igmpproxy
option quickleave 1
# option verbose [0-3](none, minimal[default], more, maximum)
config phyint
option network tvorange
option zone wanTV # 18.06.02
option direction upstream
list altnet "0.0.0.0/0"
config phyint lan
option network lan
option zone lan # 18.06.02
option direction downstream
On modifie le fichier /etc/config/network pour créer l'interface vlan 840, et ajouter l'igmp snooping sur le lan.
config device
option name 'eth0.840'
option type '8021q'
option ifname 'eth0'
option vid '840'
list egress_qos_mapping '0:5'
list egress_qos_mapping '1:5'
list egress_qos_mapping '2:5'
list egress_qos_mapping '3:5'
list egress_qos_mapping '4:5'
list egress_qos_mapping '5:5'
list egress_qos_mapping '6:5'
list egress_qos_mapping '7:5'
config interface 'tvorange'
option device 'eth0.840'
option proto 'static'
option ipaddr '192.168.255.254'
option netmask '255.255.255.255'
option delegate '0'
Toujours dans /etc/config/network
On ajoute à la conf lan la ligne suivante :
option igmp_snooping '1'
On modifie le fichier /etc/config/dhcp pour envoyer les dns d'orange, et l'option 125 :
Pour les "XX", convertissez votre numéro de serie de la livebox tv (ascii vers hex)
Exemple : IA2022323438110 devient 494132303232333233343338313130
Pour les "YY", on prend les 3 premiers octects de la mac, à convertir en Hex également.
Exemple : 08:87:C6:B2:D1:90 soit 0887C6 devient 303838374336
Cet exemple, donnerait : '125,00:00:0d:e9:24:04:06:30:38:38:37:43:36:05:0f:49:41:32:30:32:32:33:32:33:34:33:38:31:31:30:06:09:4c:69:76:65:62:6f:78:20:34'
config dhcp 'lan'
option interface 'lan'
option start '101'
option limit '150'
option leasetime '12h'
option dhcpv4 'server'
option ra 'server'
list ra_flags 'none'
list dhcp_option '6,81.253.149.10,80.10.246.3'
list dhcp_option '15,orange.fr'
list dhcp_option '125,00:00:0d:e9:24:04:06:YY:YY:YY:YY:YY:YY:05:0f:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:06:09:4c:69:76:65:62:6f:78:20:34'
Et pour finir, on modifie le fichier /etc/config/firewall pour créer la zone WanTV et les règles associées :
config zone
option name 'wanTV'
option output 'ACCEPT'
option masq '1'
option network 'tvorange'
option input 'DROP'
option forward 'DROP'
option family 'ipv4'
list device 'eth0.840'
config forwarding
option src 'lan'
option dest 'wanTV'
config rule
option target 'ACCEPT'
option name 'igmp'
option family 'ipv4'
option proto 'igmp'
option src 'wanTV'
config rule
option target 'ACCEPT'
option name 'multicast'
option family 'ipv4'
option proto 'udp'
option src 'wanTV'
option dest 'lan'
option dest_ip '224.0.0.0/4'
Bonus : Script check internet
J'utilise le script suivant, qui me permet de vérifier chaque heure que la connexion internet est ok, sinon mon routeur redemarre automatiquement :
nano /etc/checkinternet.sh
#!/bin/sh
ping -c5 1.1.1.1
if [ $? -eq 0 ]; then
echo "Internet ok le $(date)" > /root/checkinternet.txt
else
reboot
fi
Ensuite, on le rend executable et un petit crontab pour l'executer chaque heure :
chmod a+x /etc/checkinternet.sh
crontab -e00 * * * * /etc/checkinternet.sh
Bonus 2 : Script qui check si les rules sont bien chargées
nano /etc/checknftrules.sh
#!/bin/sh
var=$(nft list ruleset | grep "set 0:" | wc -l);
if [ $var -ne 0 ]; then
echo "nft rules ok le $(date)" > /root/checkrules.txt
else
echo "nft rules corrige par le script le $(date)" >> /root/error-rules.txt
nft add rule inet fw4 mangle_postrouting oifname "eth0.832" counter meta priority set 0:1
nft add rule inet fw4 mangle_postrouting oifname "eth0.832" ip protocol icmp counter meta priority set 0:6
nft add rule inet fw4 mangle_postrouting oifname "eth0.832" ip protocol igmp counter meta priority set 0:6
nft add rule inet fw4 mangle_postrouting oifname "eth0.832" udp dport 67 counter meta priority set 0:6
nft add rule inet fw4 mangle_postrouting oifname "eth0.832" udp dport 547 counter meta priority set 0:6
nft add rule inet fw4 mangle_postrouting oifname "eth0.832" ip protocol icmpv6 counter meta priority set 0:6
fi
chmod a+x /etc/checknftrules.sh
crontab -e
*/5 * * * * /etc/checknftrules.sh
Mon Setup :
- Routeur X86 N5105 4x2.5Gbps
- ONT Leox LXT-010H-D
-
<-- Tuto historique, pour version 19.07 et inférieur ! Afin de remplacer votre Livebox par un routeur tournant sous Openwrt 19.07.X -->
----------#Edit 22/08/20: Fichiers et explication pour mise en service immédiate dispo sur Github => https://github.com/ubune/openwrt-livebox ;) #----------
(https://i.goopics.net/W2Ajq.png) (https://openwrt.org)
Edit 27/09/18: Changement au niveau de l'authentification (option 90).
Edit 02/12/18: Changement eth0, ipv6 et igmpproxy préparation version 18.06.02.
Edit 31/01/19: Openwrt 18.06.2 est désormais disponible => https://downloads.openwrt.org/releases/18.06.2/
Edit 12/02/19: Maj du tuto pour la version 18.06 désormais, avec les fichiers en pièce jointe permettant une installation très rapide.
Edit 16/02/20: Tuto compatible avec la version 19.07 ;)
Info => https://openwrt.org/releases/19.07/start
Informations sur Openwrt =>
Dans ce tutoriel j'ai utilisé Openwrt 18.06.02, il est le fruit de nombreux échange sur le Topic LEDE (ex futur d'openwrt), merci à tous ceux qui ont contribué pour qu'on en arrive là. :)
Pour récupérer votre version, il faut identifier le soc de votre routeur, exemple sur un ubiquiti edgerouterx => https://openwrt.org/toh/hwdata/ubiquiti/ubiquiti_edgerouter_x
On retrouve dans target : ramips et subtarget : mt7621.
Une fois ces éléments identifiés, on peut aller sur https://downloads.openwrt.org pour récupérer la version correspondante.
Si vous êtes déja sur Lede ou Openwrt, vous pouvez utiliser en cli la commande sysupgrade pour passer en 19+, il suffit de copier en scp l'archive téléchargée sysupgradeXXX.tar (dans /tmp par exemple) et de faire la commande
sysupgrade chemindufichier.tar vous pouvez aussi mettre à jour via LUCI (l'interface web) si vous l'aviez installé.
Présentation rapide de l'architecture Openwrt :
Initialement, le routeur possède les interfaces suivantes :
wan (eth1.2)
br-lan (bridge de l'eth0.1 et de vos interfaces wifi).
(attention, certains routeurs n'ont qu'un seul eth, c'est le cas du edgerouterX par exemple, dans ce cas on reste sur eth0 pour le wan ET le lan (eth0.1 => vlan 1 => lan, eth0.2 vlan 2 => wan).
L'interface Wan est en dhcp client et l'interface Lan(ou br-lan si wifi) est configurée en 192.168.1.1/24 avec serveur dhcp actif, il est atteignable en ssh user root mdp vide.
Sur Openwrt, vos fichiers de configurations se retrouvent dans /etc/config, par exemple par défaut on retrouve :
/etc/config/network pour la configuration des interfaces réseau, des routes statiques et du Switch (gestion vlan).
/etc/config/Firewall pour la configuration du parefeu, du nat, des zones etc.
/etc/config/dhcp pour la config du serveur dhcp (RA ipv6...).
Si vous installez un nouveau package son fichier de configuration va donc apparaître dans /etc/config, pour luci ça sera /etc/config/uhttpd et pour igmpproxy ça sera le fichier /etc/config/igmpproxy par exemple.
PARTIE 1 : INTERNET V4+V6 =>
Préparation du Routeur :
Avant de débuter la configuration permettant de faire fonctionner votre routeur à la place de votre livebox, il faut ajouter certains packages :
Obligatoire :
iptables-mod-ipopt pour la gestion dscp d'iptables.
igmpproxy pour router le flux multicast (votre routeur agira comme proxy, afin de distribuer le flux multicast à votre livebox TV).
ip-full pour le script plus bas (mapping vlan).
tcpdump (pour tracer les flux si ça ne fonctionne pas).
Vivement Conseillé :
Luci => Interface web (luci-ssl si vous voulez être en https).
Nano => éditeur de fichier (que je trouve personnellement + facile que vi).
Utile :
xxd => Pour faire la conversion hexa de votre fti.
iperf => Pour faire des tests de débit depuis le Routeur <=> Serveur/MachineX.
iftop => Pour voir la consommation de flux en temps reel des machines (classé par utilisation, on visualise en cli).
luci-app-adblock => blocage des sites (ads, malware...) avec des listes maj par la communauté.
Pour installer ces packages, il faut que votre routeur ait accès à Internet, au départ vous pouvez mettre la patte wan du routeur derrière votre livebox (qui est en dhcp client par défaut), et donc pour les installer :
Votre pc sur l'interface lan du routeur puis : ssh root@192.168.1.1 (terminal linux/mac os, ou depuis le powershell sur windows 10, sinon putty).
opkg update
opkg install iptables-mod-ipopt igmpproxy ip-full luci-ssl tcpdump xxd
INTERNET IPV4 :
Pour pouvoir faire fonctionner le wan Orange nous avons besoin :
- De votre identifiant de connexion que l'on va mettre en hexa, dans l'exemple du tuto, on va utiliser (définit au hasard): fti/qpq8888
- De configurer l'interface Wan en utilisant le VLAN 832 en dhcp => /etc/config/network
- De configurer le "switch" pour taguer le vlan 832, il faut taguer sur l'interface wan ET sur le cpu qui correspond à l'ETH (détail plus bas). => /etc/config/network
- D'envoyer les bonnes options dhcp permettant l'authentification auprès d'orange => /etc/config/network
- D'envoyer tout le flux qui ne passe pas par iptables en priorité CS6 (en faite ça sera juste le dhcpV4) => /etc/vlanprio.sh
- Gérer les files pour éviter les pb de débit (on remet bien le flux normal avec des priorités cohérentes) => iptables custom rules dans le fichier /etc/firewall.user
Identifiant de connexion en héxa:
Depuis le routeur (package xxd précédemment installé) => vous pouvez exécuter la commande suivante en remplaçant 'fti/qpq8888' par votre identifiant :
Commande : echo -n 'fti/qpq8888' | xxd -p
Résultat : 6674692f71707138383838
Ou sinon sur : https://www.rapidtables.com/convert/number/ascii-to-hex.html
Exemple : fti/qpq8888 = 66 74 69 2f 71 70 71 38 38 38 38 (il faudra supprimer les espace dans le tuto).
Fichier /etc/config/network
Sur nos routeurs, nous avons (généralement) 2 interfaces Eth ayant chacune un CPU correspondant, l'un pour le lan (eth0.1 par défaut), l'autre pour le port wan (eth1.2 par défaut).
Ce qu'il faut comprendre, c'est que pour la gestion des vlan, il faut obligatoirement qu'un vlan associé à l'Eth en question soit aussi taggué vers son CPU.
Exemple le VLAN 832 qui est donc sur mon ETH1, doit être en taggué sur l'ETH1 mais AUSSI sur le CPU.
Dans le fichier network on doit retrouver :
La config Switch :
config switch_vlan
option device 'switch0'
option vlan '2' # index
option ports '4t 6t' # t pour tag, on tag sur le port 4 (qui est le port wan) et le 6 c'est mon cpu eth1.
option vid '832' # id du vlan
La gestion des VLANs est plus clair sur Luci => :
(https://image.noelshack.com/minis/2018/27/3/1530690963-switch.png) (https://www.noelshack.com/2018-27-3-1530690963-switch.png)
La config ETH1 :
config interface 'wan'
option ifname 'eth1.832' #eth1 vlan 832
option proto 'dhcp' # en dhcp client
option broadcast '1'
option vendorid 'sagem' # on envoi le vendor id sagem
option reqopts '1 15 28 51 58 59 90' # liste des options demandées
option sendopts '77:2b46535644534c5f6c697665626f782e496e7465726e65742e736f66746174686f6d652e4c697665626f7834 90:00000000000000000000001a0900000558010341010d6674692f71707138383838' # option 77 + 90 (fti)
Le script vlanprio.sh (il inclut aussi la partie TV qu'on verra + tard, il doit être exécuté à chaque démarrage du routeur ou changement sur une interface) :
On va le créer dans /etc, et lui ajouter le droit d’exécution.
nano /etc/vlanprio.sh (il faut copier le contenu en bleu qui suit).
chmod a+x /etc/vlanprio.sh
#!/bin/sh
set -x
for i in 0 1 2 3 4 5 6 7; do
ip link set eth1.832 type vlan egress $i:$i >/dev/null ## Chaque file devient en priorité $numdefile
ip link set eth1.840 type vlan egress $i:5 >/dev/null ## tout en prio 5 sur le vlan 840
done
ip link set eth1.832 type vlan egress 1:0 >/dev/null ## La file (1) était donc en prio 1 on la repasse à 0, ça deviendra (via IPTABLES) la nouvelle file par défaut.
ip link set eth1.832 type vlan egress 0:6 >/dev/null ## Tout le flux devient en prio 6 ! sauf le flux qui passera par IPTABLES (donc juste nos requêtes dhcp)
Pour qu'il se lance à chaque boot : on modifie nano /etc/rc.local =>
sleep 10
ifdown wan # J'ai eu besoin de faire ça pour être sûr d'éviter l'ip privée sur le wan, depuis la maj 18.02.
sh /etc/vlanprio.sh
ifup wan
exit 0
Fichier /etc/config/firewall
config zone
option name 'wan'
option output 'ACCEPT'
option masq '1' #masquerade, on nat le flux ipv4 sortant du wan par l'ip public reçu sur eth1.
option input 'DROP'
option forward 'DROP'
option network 'wan'
option family 'ipv4'
config rule
option name 'Allow-DHCP-Renew'
option src 'wan'
option proto 'udp'
option dest_port '68'
option target 'ACCEPT'
option family 'ipv4'
config include
option path '/etc/firewall.user'
iptables custom rules
Pour gérer les files correctement il faut lancer au démarrage : Chez moi si je laisse tout le flux en CS6, j'ai 14Mbps descendant et 0.8Mbps montant maximum, que ce soit en V4 ET en V6, (945/300 avec les rules).
Il faut ajouter ces règle dans le fichier /etc/firewall.user :
iptables -t mangle -A POSTROUTING -j CLASSIFY --set-class 0000:0001 ## En gros tout le flux sortant passe dans la file 1 qui est en prio 0
iptables -t mangle -A POSTROUTING -p icmp -j CLASSIFY --set-class 0000:0006 ##On passe le flux icmp dans la file 6 qui est en prio 6
iptables -t mangle -A POSTROUTING -p igmp -j CLASSIFY --set-class 0000:0006 ## On passe le flux igmp (celui qui part vers eth1.832) dans la file 6 qui est en prio 6
iptables -t mangle -A POSTROUTING -o eth1.832 -p udp --dport 67 -j CLASSIFY --set-class 0000:0006 ## On passe le flux dhcp dans la file 6 qui est en prio 6, necessaire pour le DHCP Renew
#la même chose en ipv6 (avec cette fois le dhcpv6)
ip6tables -t mangle -A POSTROUTING -j CLASSIFY --set-class 0000:0001
ip6tables -t mangle -A POSTROUTING -p ipv6-icmp -j CLASSIFY --set-class 0000:0006
ip6tables -t mangle -A POSTROUTING -p udp --dport 547 -j CLASSIFY --set-class 0000:0006
Une fois tout ceci fait, vous pouvez supprimer votre livebox et connecter directement votre nouveau routeur openwrt sur l'ont orange. Vous devriez recevoir votre ip publique sur l'eth1.832, la route par défaut et les dns Orange, et comme dans la config zone wan nous avions activé le nat, vous devriez avoir accès à internet depuis votre pc qui est raccordé sur le lan.
commande utile pour vérifier tout ça : ifstatus wan =>
(https://image.noelshack.com/minis/2018/28/1/1531115401-ifstatus-wan.png) (https://www.noelshack.com/2018-28-1-1531115401-ifstatus-wan.png)
- 1 = Votre ip WAN
- 2 = Votre route par défaut
- 3 = Dns d'orange
INTERNET + Firewall IPV6 :
Pour IPV6, après avoir envoyé les bonnes options vous recevez votre prefixe (un /56 donc 256 /64 possibles) et la passerelle par défaut (l'ip link local du prochain routeur Orange). Dhcpv6 sera uniquement utilisé pour recevoir le préfixe (IA_PD).
Pour recevoir le tout nous avons besoin (Merci à Simon Topic LEDE, ainsi que Sywolf pour l'intégration dans le fichier network) :
D'envoyer les options 11, 15 et 16 /etc/config/network
On demande les options 11,17,23 et 24 /etc/config/network
[On désactive l'envoi d'un hostname dans etc/config/network (Openwrt 18.06.02 obligatoire)
[On désactive le support de l'opcode reconfigure dans etc/config/network (Openwrt 18.06.02 obligatoire)
L'option 15 est l'user-class et doit contenir la même valeur que pour DHCPv4 cette fois elle est écrite en ASCII ici et non en hexa comme précédemment.
L'option 16 est le vendor id (sagem).
L'option 11 est notre identifiant (la seule chose que vous devez personnaliser).
Coté Firewall il faut aussi :
Autoriser dhcpv6 pour le wan6 (ATTENTION, si vous ne personnalisez pas la zone wan en family ipv4 uniquement, il faut l'autoriser sur le wan et non wan6.
Pour cela nous allons donc modifier notre fichier /etc/config/network
Pour rappel l'identifiant fti du tuto en hexa (la seule chose que vous devez personnaliser) : 6674692f71707138383838
------------------------------------------
Puis votre interface wan6 dans /etc/config/network =>
config interface 'wan6'
option ifname 'eth1.832'
option proto 'dhcpv6'
option reqprefix 'auto'
option reqaddress 'none'
option defaultreqopts '0'
option sendopts '11:00000000000000000000001a0900000558010341010d6674692f71707138383838 15:FSVDSL_livebox.Internet.softathome.livebox4 16:0000040e0005736167656d'
option reqopts '11 17 23 24'
option noclientfqdn '1' # OPENWRT 18.06.02 et plus récent
option noacceptreconfig '1'#OPENWRT 18.06.02 et plus récent
Votre Firewall doit avoir ce paramétrage des zones + ces règles :
config zone
option name 'wan'
option output 'ACCEPT'
option masq '1'
option input 'DROP'
option forward 'DROP'
option network 'wan'
option family 'ipv4'
config zone
option name 'wanipv6'
option network 'wan6'
option output 'ACCEPT'
option forward 'DROP'
option family 'ipv6'
option input 'DROP'
config rule
option name 'Allow-DHCPv6'
option proto 'udp'
option src_ip 'fc00::/6'
option dest_ip 'fc00::/6'
option dest_port '546'
option family 'ipv6'
option target 'ACCEPT'
option src 'wanipv6'
config rule
option name 'Allow-MLD'
option proto 'icmp'
option src_ip 'fe80::/10'
list icmp_type '130/0'
list icmp_type '131/0'
list icmp_type '132/0'
list icmp_type '143/0'
option family 'ipv6'
option target 'ACCEPT'
option src 'wanipv6'
config rule
option name 'Allow-ICMPv6-Input'
option proto 'icmp'
list icmp_type 'echo-request'
list icmp_type 'echo-reply'
list icmp_type 'destination-unreachable'
list icmp_type 'packet-too-big'
list icmp_type 'time-exceeded'
list icmp_type 'bad-header'
list icmp_type 'unknown-header-type'
list icmp_type 'router-solicitation'
list icmp_type 'neighbour-solicitation'
list icmp_type 'router-advertisement'
list icmp_type 'neighbour-advertisement'
option limit '1000/sec'
option family 'ipv6'
option target 'ACCEPT'
option src 'wanipv6'
config rule
option name 'Allow-ICMPv6-Forward'
option dest '*'
option proto 'icmp'
list icmp_type 'echo-request'
list icmp_type 'echo-reply'
list icmp_type 'destination-unreachable'
list icmp_type 'packet-too-big'
list icmp_type 'time-exceeded'
list icmp_type 'bad-header'
list icmp_type 'unknown-header-type'
option limit '1000/sec'
option family 'ipv6'
option target 'ACCEPT'
option src 'wanipv6'
Désormais, vous devriez recevoir votre préfixe ipv6 + route par défaut V6 :
La commande pour vérifier si c'est le cas : ifstatus wan6 =>
(https://image.noelshack.com/minis/2018/28/1/1531115401-ifstatus-wan6.png) (https://www.noelshack.com/2018-28-1-1531115401-ifstatus-wan6.png)
1 = Votre préfixe ipv6
2 = Votre route par défaut ipv6.
3 = Dns d'orange IPV6, ah ba non, Orange n'a toujours pas de dns IPV6 ::)
On peut distribuer le premier /64 du /56du préfixe obtenu au lan :
Dans le fichier /etc/config/dhcp :
config dhcp 'lan'
option interface 'lan'
option start '100'
option leasetime '4h'
option ra 'server'
list dhcp_option '6,192.168.1.1'
option limit '30'
Votre interface Lan dans /etc/config/network doit désormais ressembler à ça :
config interface 'lan'
option type 'bridge' #chez moi c'est un bridge car j'ai un SSID wifi + l'eth0
option proto 'static'
option ipaddr '192.168.1.1'
option netmask '255.255.255.0'
option delegate '0'
option mtu '1500'
option ifname 'eth0.1'
option ip6assign '64' # Pour que le routeur s'attribue une adresse du premier /64
Et voila ! Vous devriez être IPV6 Ready un test sur http://ipv6-test.com/ et vous obtiendrez un score de 19/20 (si vous avez laissez le forward icmpv6 et que votre machine accepte l'icmpv6).
(https://image.noelshack.com/minis/2018/27/3/1530691268-ipv6ok.png) (https://www.noelshack.com/2018-27-3-1530691268-ipv6ok.png)
Et voila, la partie Internet devrait désormais être pleinement opérationnelle, un petit speedtest =>
(https://www.speedtest.net/result/7523397751.png)
Pour les detenteurs de Raspberry, voir le post de bulle21 ici => https://lafibre.info/remplacer-livebox/remplacement-de-la-livebox-par-un-routeur-openwrt-18-dhcp-v4v6-tv/msg779570/#msg779570
-
Partie 2 : TV + REPLAY
Pour être sûr du fonctionnement de la suite, si vous commencez cette partie c'est que vous avez déjà configuré et rendu fonctionnel la partie 1, surtout vérifiez bien que vous avez l'interface eth1.840 dans le script vlanprio.sh
Pour faire simple, avec cette config vous devez brancher le décodeur TV sur le lan port 3 (en pvid vlan 19) et le lan port 4 sera utilisé pour envoyer les 2 vlan sur un autre Switch, dans ce cas on aura pas besoin de s’embêter avec l'igmp snooping.
Pour que cela fonctionne nous allons :
- Configurer une nouvelle interface coté (v)LAN avec serveur dhcp, qui enverra les dns d'orange et qui accueillera votre/vos décodeur TV, dans ma config c'est donc le vlan 19 ( vlantv ).
- Configurer l'interface eth1.840 sur laquelle arrivera le flux igmp, et qui sera routé vers l'interface vlantv (package igmpproxy).
- Configurer le firewall pour gerer (autoriser) ces flux, on va créer une zone wanTV qui contiendra l'eth1.840 et la zone lanTV qui contiendra uniquement l'interface eth0.19 vlanTV.
- Configurer le switch pour les vlan, on va tagguer le vlan 840 sur l'eth1 et le cpu eth1, on tag le vlan 19 sur eth0, et met ce vlan en untagged sur le port 3 pour brancher la box, la config du port 4 c'est pour un cas éventuel liaison vers un switch qui aura une box TV derrière aussi.
Les différents flux de votre box TV :
- Dialogue au travers de l'eth1.840 pour le flux igmp (qui sera routé entres ces interfaces grâce à votre routeur qui agira comme proxy).
- Dialogue au travers de l'eth1.832 pour divers flux (replay, ntp par exemple).
Configuration des nouvelles interfaces :
nano /etc/config/network =>
config interface 'vlantv'
option proto 'static'
option ipaddr '192.168.19.254' ## Adressage arbitraire mais j'aime bien la corrélation n°vlan/réseau.
option netmask '255.255.255.0'
option ifname 'eth0.19'
config interface 'tvorange'
option ifname 'eth1.840'
option proto 'static'
option ipaddr '192.168.255.254' #Adressage arbitraire
option netmask '255.255.255.255'
option delegate '0'
Configuration du serveur DHCP pour l'interface vlantv :
nano /etc/config/dhcp =>
config dhcp 'vlantv'
option leasetime '12h'
option interface 'vlantv'
option start '10'
option limit '10'
list dhcp_option '6,81.253.149.10,80.10.246.3'
list dhcp_option '15,orange.fr'
list dhcp_option '125,00:00:0d:e9:24:04:06:YY:YY:YY:YY:YY:YY:05:0f:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:06:09:4c:69:76:65:62:6f:78:20:34'
Nouveauté pour le nouveau décodeur TV5, l'option 125 est obligatoire, les Y en Orange c'est les 6 octets correspondant à l'adresse mac de votre livebox routeur, et il faut remplacer les XX:XX par votre numéro de série de livebox routeur, après l'avoir converti en Hexa.
Configuration du Firewall :
nano /etc/config/firewall =>
config zone
option name 'tv'
option output 'ACCEPT'
option network 'vlantv'
option input 'ACCEPT'
option forward 'ACCEPT'
option family 'ipv4'
config zone
option name 'wanTV'
option output 'ACCEPT'
option masq '1'
option network 'tvorange'
option input 'DROP'
option forward 'DROP'
option family 'ipv4'
config forwarding
option dest 'wanTV' #On autorise la box tv à sortir sur le wanTV.
option src 'tv'
config forwarding
option dest 'wan' #On autorise la box tv à atteindre le flux wan classique (Replay/ntp par exemple).
option src 'tv'
config rule
option target 'ACCEPT'
option name 'igmp' #On autorise le flux IGMP provenant du vlan 840 à destination du routeur.
option family 'ipv4'
option proto 'igmp'
option src 'wanTV'
config rule
option target 'ACCEPT'
option name 'multicast' #On autorise le flux multicast provenant du vlan 840 à destination de la zone tv (le vlan TV ou se trouvera le décodeur).
option family 'ipv4'
option proto 'udp'
option src 'wanTV'
option dest 'tv'
option dest_ip '224.0.0.0/4'
IGMPPROXY :
Pour installer et lancer automatiquement igmpproxy au démarrage =>
opkg update
opkg install igmpproxy
/etc/ini.d/igmpproxy enable
On va éditer le fichier de configuration d'igmpproxy, attention à bien respecter le nommages des interfaces (sensible à la casse) créés précédemment :
nano /etc/config/igmpproxy=>
config igmpproxy
option quickleave 1
config phyint
option network tvorange
option zone wanTV # 18.06.02
option direction upstream
list altnet "0.0.0.0/0"
config phyint lan
option network vlantv
option zone tv # 18.06.02
option direction downstream
Maintenant on le relance : /etc/init.d/igmpproxy restart
Désormais si on fait un more /etc/igmpproxy.conf on va retrouver :
quickleave
phyint eth1.840 upstream ratelimit 0 threshold 1
altnet 0.0.0.0/0
phyint eth0.19 downstream ratelimit 0 threshold 1
Et voilà, tout devrait fonctionner ;).
Alternatives :
(TV)
Si vous vouliez avoir la TV sur le LAN :
Changement Firewall :
config rule
option src wanTV
option proto igmp
option target ACCEPT
config rule
option src wanTV
option proto udp
option dest lan
option dest_ip 224.0.0.0/4
option target ACCEPT
option family ipv4
config forwarding
option dest 'lan'
option src 'wanTV'
Changement igmpproxy :
config igmpproxy
option quickleave 1
config phyint
option network tvorange
option direction upstream
option zone wanTV
list altnet "0.0.0.0/0"
config phyint lan
option network lan
option zone lan
option direction downstream
Changement network :
config interface 'lan'
option igmp_snooping 1
Changement Dns :
Il faut envoyer les dns d'orange sur le lan (ou que votre routeur relaye vers Orange).
Attention, si vous utilisez cette configuration et que votre décodeur est raccordé sur un switch derrière le routeur, il faudra gérer l'igmp snooping dessus (si vous ne voulez pas que le flux TV soit broadcasté).
(Telephone)
Livebox derrière le routeur (pour avoir le téléphone fonctionnel)
Voir les échanges et surtout le post récap de Rhon ici : https://lafibre.info/remplacer-livebox/remplacement-de-la-livebox-par-un-routeur-openwrt-18-dhcp-v4v6-tv/msg589599/#msg589599
Attention, pour les cas ou vous avez un seul eth, ou si vos deux eth ne sont pas isolés, on doit utiliser un switch pour sortir l'interface tel en untagged sur un vlan (exemple 199) et l'associer au vlan 832 sur lequel notre livebox routeur tag (grâce au switch administrable).
Voir mon post récap ici => https://lafibre.info/remplacer-livebox/remplacement-de-la-livebox-par-un-routeur-openwrt-18-dhcp-v4v6-tv/msg639732/#msg639732 (https://lafibre.info/remplacer-livebox/remplacement-de-la-livebox-par-un-routeur-openwrt-18-dhcp-v4v6-tv/msg639732/#msg639732)
-
Testé sur wrt3200acm / openwrt 18.06.0-rc2, ça fonctionne merveilleusement bien, et j'ai meme gagné en débit ! :)
Un grand merci pour ce tuto, je galerais avec les vlan / authentification, et la, ça s'est fait en 5 minutes chrono avec ce tuto !!
-
Testé sur wtr3200acm / openwrt 18.06.0-rc2, ça fonctionne merveilleusement bien, et j'ai meme gagné en débit ! :)
Un grand merci pour ce tuto, je galerais avec les vlan / authentification, et la, ça s'est fait en 5 minutes chrono avec ce tuto !!
Merci pour le retour et content que tout fonctionne :).
Dès que j'ai un peu de temps je compléterai la partie TV.
A+
-
Bonjour,
Êtes-vous sûr que les options DHCP v4 demandées (option reqopts) sont en hexa : 0x01 0x15 0x28 ... ?
Ça fait 1 (Subnet Mask) OK, 21 (Policy Filter), 40 (NIS Domain), 81 (Client FQDN), 88 (BCMCS Controller Domain Name list), 89 (BCMCS Controller IPv4 address option), 144 (GeoLoc) selon le registre de l'IANA
https://www.iana.org/assignments/bootp-dhcp-parameters/bootp-dhcp-parameters.xhtml (https://www.iana.org/assignments/bootp-dhcp-parameters/bootp-dhcp-parameters.xhtml)
-
merci pour le tuto. je l'ai mis dans l'index global (sujet épinglé).
-
Bien vu pour les options dhcp ipv4, ça mérite refléxion (mais à priori c'est issue du sniffage de ce que demande la livebox... c'est pas impossible qu'elle demande n'importe quoi)
Sinon j'avais commencé à regarder du coté dhcpv6 et du binaire odhcp6c sous jacent, et il semblerait qu'on puisse lui filer les options plus proprement qu'en modifiant une lib (c'est quand meme un peu crado de modifier une lib, sauf si c'est pour contribuer directement à openwrt ;) )
-x 15 gérable via odhcp6c via "userclass"
-x 16 gérable via odhcp6c via "vendorclass"
-x 11 => OPTION_AUTH => odhcp6c semble pouvoir le gérer via "sendopts:list(string)" (ainsi que les autres options -x, mais si on peut faire propre ;) )
-r sont gérables via "reqopts:list(uinteger)"
-Nnone gérable via "reqaddress"
-P0 gérable via "reqprefix"
-R gérable via "defaultreqopts"
-f non géré
-a non géré
Je n'ai pas encore trouvé comment bien les setter dans la config du network, mais ça va finir par se faire :D
-
Du coup, pour l'ipv6, tu peux simplifier un peu le tuto :)
Dans la config network, plutot que de la laisser vide, et tout modifier dans la lib :
config interface 'wan6'
option ifname 'eth1.832'
option proto 'dhcpv6'
option defaultreqopts '0'
option sendopts '11:00000000000000000000006674692f3XXXXXXXXXXXX 15:FSVDSL_livebox.Internet.softathome.livebox3 16:0000040e0005736167656d'
option reqopts '11 17 23 24'
option reqaddress 'none'
option reqprefix '0'
et dans /lib/netifd/proto/dhcpv6.sh, laisser le code d'origine et juste ajouter les options -f et -a.
proto_export "INTERFACE=$config"
proto_run_command "$config" odhcp6c \
-s /lib/netifd/dhcpv6.script \
$opts -f -a $iface
Apres avoir un peu lu le code de odhcp6c, on peut dire avec certitude que le -f correspond à DHCPV6_CLIENT_FQDN et -a à DHCPV6_ACCEPT_RECONFIGURE, et helas, ce ne sont pas des options (peut etre le client fqdn via l'option 39). On est donc pour le moment obligé de modifier la lib :/
repo de odhcp6c : https://github.com/openwrt/odhcp6c/blob/master/src/odhcp6c.c (https://github.com/openwrt/odhcp6c/blob/master/src/odhcp6c.c)
rfc diverse et variée de dhcpv6 : https://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xhtml (https://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xhtml)
A voir maintenant, si il existe des petites options qui seraient actives chez orange (je me suis fais ban temporerement à plusieurs reprises en faisant des essais :o)
Et peut etre en supprimer certaines pour l'ipv4.
-
Hello,
Si j'ai bien suivi le tuto, ça a l'air assez compliqué de remettre la box derrière le routeur, est ce exact ?
-
je me suis fais ban temporerement à plusieurs reprises en faisant des essais :o
Orange bloque la connexion quand on tente de bypasser leur box? :o
-
Merci pour le retour Sywolf, je fais un test ce soir et j'éditerai le tuto en conséquence, openwrt 18.06.0 est disponible :).
-
Orange bloque la connexion quand on tente de bypasser leur box? :o
J’ai jamais remarqué ça pendant les longues journées où on a essayé de comprendre comment tout fonctionnait au début du passage en DHCP...
-
Cette version améliore pas mal le NAT Offloading
ne pas hésiter à placer
option flow_offloading 1
option flow_offloading_hw 1
sur le /etc/config/firewall dans la section default pour permettre de dépasser les 300 Mbps avec des vieux routeurs OpenWRT tel que le Archer C7 v2
-
Merci pour le retour Sywolf, je fais un test ce soir et j'éditerai le tuto en conséquence, openwrt 18.06.0 est disponible :).
J'ai fais l'upgrade à l'instant, ça tourne :) (il faut toujours ajouter les options -f et -a, mais c'est tout :) ) (et pour le wrt3200acm, toujours virer la radio2 en supprimant les packages kmod-mwifiex-sdio mwifiex-sdio-firmware kmod-btmrvl pour etre dfs compliant)
J’ai jamais remarqué ça pendant les longues journées où on a essayé de comprendre comment tout fonctionnait au début du passage en DHCP...
Bah, je n'avais plus aucune paquet entrant sur le wan, donc pas d'authentification, ni en ipv4, ni ipv6. Donc pour valider ça, à chaque ban, j'ai rebranché la box orange, et elle mettait 5 bonnes minutes avant de pouvoir se reconnecter. (petite frayeur sur le coup :D )
-
J'ai mis à jour avec tes éléments (encore merci) et j'ai commencé la partie TV, c'est vraiment brut pour l'instant mais je ferai au propre avec des explications d'ici la fin de semaine.
-
Merci pour la partie TV.
J'ai une config un peu similaire avec un switch déporté et un trunk.
J'ai reussi à faire fonctionner la TV hier soir, mais j'avais un débit tout pourri (30/30 au lieu de 950/300), du coup j'ai désactivé pour le moment.
J'ai pas trop le temps de regarder plus en détail aujourd'hui, mais ça m'etonne, la priorité des paquets n'ayant pas de raison de changer comme ça.
-
Merci pour la partie TV.
J'ai une config un peu similaire avec un switch déporté et un trunk.
J'ai reussi à faire fonctionner la TV hier soir, mais j'avais un débit tout pourri (30/30 au lieu de 950/300), du coup j'ai désactivé pour le moment.
J'ai pas trop le temps de regarder plus en détail aujourd'hui, mais ça m'etonne, la priorité des paquets n'ayant pas de raison de changer comme ça.
Entre temps j'avais corrigé les custom rules iptables, as-tu vraiment ce qui est indiqué dans le tuto ?
Tiens moi au courant, en tout cas chez moi ça tourne impec avec TV (2 décodeurs), et débit en 945/300 que ce soit en V4 ou V6 (sur un wrt1900acs).
A+
-
Et bien tout fonctionne :)
J'ai repris ma config from scratch, et c'est bon ! ;D
(probablement un petit mélange au niveau du nommage des zones & interfaces)
-
Et bien tout fonctionne :)
J'ai repris ma config from scratch, et c'est bon ! ;D
(probablement un petit mélange au niveau du nommage des zones & interfaces)
Bonne nouvelle ça, j'ai commencé à mettre au propre la partie TV ;)
-
Cool :)
Pour la partie TV, j'ai une approche plus simple, en créant un bridge du vlan 838 et 840.
Ca permet d'avoir une seule interface visible dans luci => WAN_TV.
Du coup, ça simplifie aussi les zones, avec une approche similaire à celle du vlan 832.
Soit tu zones directement vers LAN (ce que fais la livebox/liveboxtv), soit vers un LAN_TV sur un vlan dédié.
Tu bloques l'input/forward, et tu autorises juste via 2 rules, l'input sur le protocole igmp, et le forward udp sur une adresse multicast dans ta zone lan.
Et tout fonctionne, sans que ce soit trop complexe :)
Si ça t'interesse, je peux faire un petit tuto alternatif.
-
Cool :)
Pour la partie TV, j'ai une approche plus simple, en créant un bridge du vlan 838 et 840.
Ca permet d'avoir une seule interface visible dans luci => WAN_TV.
Du coup, ça simplifie aussi les zones, avec une approche similaire à celle du vlan 832.
Soit tu zones directement vers LAN (ce que fais la livebox/liveboxtv), soit vers un LAN_TV sur un vlan dédié.
Tu bloques l'input/forward, et tu autorises juste via 2 rules, l'input sur le protocole igmp, et le forward udp sur une adresse multicast dans ta zone lan.
Et tout fonctionne, sans que ce soit trop complexe :)
Si ça t'interesse, je peux faire un petit tuto alternatif.
En faite si j'ai choisi de ne pas bridge c'est parce qu'avec d'autres outils je fais des statistiques de ces interfaces, ça permet de voir le flux consommé uniquement pour la tv, uniquement pour le replay/appli, de plus, puisque niveau Firewall la zone wanTV contient les deux interfaces, je trouve pas que ça complexifie grand chose (quelques lignes en + dans le fichier network, mwai).
Pour le forward vers le lan :
Je me place comme une personne lambda qui va lire le tuto et gérer la tv avec des vlans cela me semblait être le meilleur compromis, au moins si tu branches sur le routeur ça marche, si tu branches sur un switch déporté mais sans gérer les vlan ça marche pas, tu reviens sur le tuto, tu finis par comprendre et tu corrige (plutôt que ralentir le lan de la maison sans trop comprendre pourquoi). Peut-être que je me trompe, mais je trouve plus simple de gérer un vlan sur un switch que l'igmp snooping. Bon après tout le monde n'a pas sa box tv derrière un autre switch, dans ce cas oui le tuto pourrait être simplifié, mais au moins là dans l'état ça marche de partout.
Pour le Firewall :
J'avais en effet déjà mis dans le tuto l'igmp si tu bloques l'input, je vais rajouter le forward 224.0.0.0/4 udp si tu bloques le forward, oui c'est plus propre, mais il faut aussi voir l'intérêt, on parle du Wan Tv donc du flux qui vient directement et uniquement d'orange, sachant qu'en plus avec cette configuration ça peut atteindre uniquement tes décodeurs (l'avantage du vlantv).
A+ ;)
-
Bah, avec un bridge, tu peux monitorer tes interfaces sur les vlans spécifiques. C'est juste que seul le bridge aura une adresse ip.
L'avantage de balancer sur le lan la tv et la data, c'est que tu peux brancher ta box tv sur n'importe quel port du routeur ET sur n'importe quel port de n'importe quel switch branché sur le routeur (à la difference de la livebox ou tu ne peux brancher ta boxtv que sur un des ports de la livebox, ou d'une config avec des vlans, ou tu ne peux brancher ta box tv que sur les ports associé au vlan tv (donc de la config ...) ).
En revanche, il faut quand meme des switchs de niveau 3 qui gerent l'igmp snooping pour éviter de multicaster comme un cochon partout.
Netflix, deezer, la vod, le replay et tout le tralala fonctionnent avec ce setup.
-
Bah, avec un bridge, tu peux monitorer tes interfaces sur les vlans spécifiques. C'est juste que seul le bridge aura une adresse ip.
L'avantage de balancer sur le lan la tv et la data, c'est que tu peux brancher ta box tv sur n'importe quel port du routeur ET sur n'importe quel port de n'importe quel switch branché sur le routeur (à la difference de la livebox ou tu ne peux brancher ta boxtv que sur un des ports de la livebox, ou d'une config avec des vlans, ou tu ne peux brancher ta box tv que sur les ports associé au vlan tv (donc de la config ...) ).
En revanche, il faut quand meme des switchs de niveau 3 qui gerent l'igmp snooping pour éviter de multicaster comme un cochon partout.
Netflix, deezer, la vod, le replay et tout le tralala fonctionnent avec ce setup.
Pour le monitoring, pas avec nlbwon que j'utilise, mais de toute façon le bridge n'apporte rien hormis 2 lignes économisés sur le fichier network.
Un Switch L2 peut faire du snooping, et tu peux brancher la tv sur un Switch non administrable derrière ta livebox, ça va maLrcher.
Pour le reste Oui je suis d'accord avec toi, mais je suis toujours pas convaincu que simplifier la config permettra aux gens qui l'utiliseront (ça reste le but un tuto) de fonctionner mieux et plus facilement (sans oublier l'explication sur l'igmp snooping à gérer si l'on possède d'autre Switch sur lequel raccorder ta box) et on parle de fichier de configuration à copier coller à 90%.
Apres si vraiment ça choque de faire un vlan on peut mettre les deux possibilités (dans le tuto), mais ça risque (ça reste que mon avis hein, je suis ouvert) surtout d'embrouiller les moins expérimentés.
-
Bonjour,
pourquoi tu as supprimé cette règle iptable que l'on mettait précédemment (pour l'ipv4) ??
iptables -t mangle -A POSTROUTING -o eth1.832 -p udp --dport 67 -j CLASSIFY --set-class 0000:0006
Voie le post de bob62 ici : https://lafibre.info/remplacer-livebox/tuto-remplacer-la-livebox-par-un-routeur-dd-wrt-internet-tv/msg567007/#msg567007
-
Bonjour,
pourquoi tu as supprimé cette règle iptable que l'on mettait précédemment (pour l'ipv4) ??
Car en faite elle ne sert à rien car le dhcpv4 ne passe pas par iptables, c'est pour ça qu'on est obligé de mapper tout le flux en cs6, et ensuite on remet les priorités sur le flux qui passe par iptables, donc tout le reste :).
-
ha ?
et c'est idem sur du Chaos Calmer 15.1 ?
-
ha ?
et c'est idem sur du Chaos Calmer 15.1 ?
Yep, je suis sans et je n'en est pas eu besoin même pour renew à la fin de lease, et personne n'a encore remonté ce pb.
Tu es en train de passer sur openwrt 18.06 ? :)
-
non pas encore, mais j'aimerai utiliser mon DGA4130 sous Chaos Calmer 15.1 à la sauce Technicolor, on ne peut pas upgrader le firmware car il faut un certificat pour ca, sans parler des drivers Broadcom proprietaires.
-
Pour ceux qui ont des archer c7 sur le dépot de sources OpenWRT se trouve une cible ath79 non buildée automatiquement,
Un membre de la communauté la builde ici : https://forum.openwrt.org/t/ath79-builds-with-all-kmod-packages-through-opkg-flow-offloading/15897/169
Le hardware offload est supporté par le noyau linux 4.14 (sur le raspberry ça fait aussi des miracles :D)
OpenVPN tient à 15 Mbit/s avec un chiffrement AES-256-CBC.
Du coup je pense que je vais vendre mon ERLite à voir, j'y réflechi encore
-
Merci pour ce retour, ça fait plaisir là openwrt est clairement de retour, ça bosse dur ;).
Pour info la 18.06.01 est sorti semaine dernière, nouveautés :
Linux kernel updated to versions 4.9.120/4.14.63 (from 4.9.111/4.14.52 in v18.06.0)
Security fixes for Curl, Mbedtls, OpenSSL and the Linux kernel
Binary builds for the at91 and ath25 targets
Updated mwlwifi driver
Improved input validation for rpcd uci ubus calls
Crash fixes in libuci
Assorted bug fixes in netifd
Plus de détail :
https://openwrt.org/releases/18.06/changelog-18.06.1
Sywolf le driver wifi inclus dans la 18.06.01 est celui que tu dois utiliser sur ton wrt3200acm ?
-
(de retour de vacances)
Je viens de faire la mise à jour. No soucy.
Vi j'utilise mwlwifi pour 2 des 3 radios du wrt3200acm. Malheuresement, la 3e radio se base sur mwifiex et le pays est hardcodé USA (c'est pas exactement du hardcodage, mais en gros ça revient à ça).
Je suis donc toujours obligé de desinstaller les drivers de la 3e radio pour profiter des 2 autres radios sur des plages (les fameux canaux DFS) de 160mhz en 5ghz.
Apres, l'objectif de cette 3e radio etait non pas de fournir du wifi, mais de scanner l'utilisation des plages par d'autres réseaux wifi pour changer automatiquement les canaux... du coup c'est pas si grave (mais bon, c'est dommage).
-
Bien vu pour les options dhcp ipv4, ça mérite refléxion (mais à priori c'est issue du sniffage de ce que demande la livebox... c'est pas impossible qu'elle demande n'importe quoi)
Sinon j'avais commencé à regarder du coté dhcpv6 et du binaire odhcp6c sous jacent, et il semblerait qu'on puisse lui filer les options plus proprement qu'en modifiant une lib (c'est quand meme un peu crado de modifier une lib, sauf si c'est pour contribuer directement à openwrt ;) )
-x 15 gérable via odhcp6c via "userclass"
-x 16 gérable via odhcp6c via "vendorclass"
-x 11 => OPTION_AUTH => odhcp6c semble pouvoir le gérer via "sendopts:list(string)" (ainsi que les autres options -x, mais si on peut faire propre ;) )
-r sont gérables via "reqopts:list(uinteger)"
-Nnone gérable via "reqaddress"
-P0 gérable via "reqprefix"
-R gérable via "defaultreqopts"
-f non géré
-a non géré
Je n'ai pas encore trouvé comment bien les setter dans la config du network, mais ça va finir par se faire :D
Tada (https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=9e319b7ae268bc4546da0d42b95d700646b55f47). Il sera possible d'utiliser les options suivantes, probablement dès la prochaine version d'OpenWRT (v18.06.2) :
config interface 'wan6'
option noclientfqdn '1'
option noacceptreconfig '1'
# […]
-
Salut, je viens de tomber sur ce sujet qui est une aubaine pour moi qui cherche à remplacer ma LB3 par un WRT 1200AC(v1)
j'ai installé openWRT sans soucis (18.06.1) et j'ai un peu galéré à faire fonctionner le routeur pour se faire passer pour une LiveBox mais en suivant bien le tuto, ça a finit par passer.
par contre en IPv6, il me balance en boucle:
daemon.warn odhcp6c[3300]: Server returned IA_PD status 6 (No prefixes have been assigned)je comprend pas.
en faisant du tcpdump, je vois qu'il y a une requête Solicit suivi d'une réponse Advertise qui me donne bien mon préfixe, puis une requête request où il demande la délégation, je crois, et une réponse en erreur.
voici mes fichiers de conf:
config interface 'loopback'
option ifname 'lo'
option proto 'static'
option ipaddr '127.0.0.1'
option netmask '255.0.0.0'
config globals 'globals'
config interface 'wan'
option ifname 'eth1.832'
option proto 'dhcp'
option broadcast '1'
option vendorid 'sagem'
option macaddr 'A4:3E:xx:xx:xx:xx'
option reqopts '0x01 0x15 0x28 0x51 0x58 0x59 0x90'
option sendopts '0x4D:2b46535644534c5f6c697665626f782e496e7465726e65742e736f66746174686f6d652e4c697665626f7833 0x5a:00000000000000000000006674692fxxxx'
config interface 'wan6'
option ifname 'eth1.832'
option proto 'dhcpv6'
option reqprefix 'auto'
option reqaddress 'none'
option macaddr 'A4:3E:xx:xx:xx:xx'
option defaultreqopts '0'
option sendopts '11:00000000000000000000006674692fxxxx 15:FSVDSL_livebox.Internet.softathome.livebox3 16:0000040e0005736167656d'
option reqopts '11 17 23 24'
option auto '0'
config switch
option name 'switch0'
option reset '1'
option enable_vlan '1'
config switch_vlan
option device 'switch0'
option vlan '1'
option ports '0 1 2 3 5t'
option vid '1'
config switch_vlan
option device 'switch0'
option vlan '2'
option ports '4t 6t'
option vid '832'
config switch_vlan
option device 'switch0'
option vlan '3'
option ports '4t 6t'
option vid '838'
config switch_vlan
option device 'switch0'
option vlan '4'
option ports '4t 6t'
option vid '840'
config dnsmasq
option domainneeded '1'
option localise_queries '1'
option rebind_protection '1'
option rebind_localhost '1'
option local '/lan/'
option domain 'lan'
option expandhosts '1'
option readethers '1'
option leasefile '/tmp/dhcp.leases'
option resolvfile '/tmp/resolv.conf.auto'
option nonwildcard '1'
option localservice '1'
config dhcp 'lan'
option interface 'lan'
option start '100'
option limit '150'
option leasetime '12h'
option dhcpv6 'server'
option ra 'server'
option ra_management '1'
list dns '2a01:xxxx:xxxx:xxxx::1'
config dhcp 'wan'
option interface 'wan'
option ignore '1'
config odhcpd 'odhcpd'
option maindhcp '0'
option leasefile '/tmp/hosts/odhcpd'
option leasetrigger '/usr/sbin/odhcpd-update'
option loglevel '4'
est ce que vous voyez d'où vient le problème? est-ce un problème config que je n'arrive pas à voir?
edit: il semble que ce soit le spoof d'adresse mac qui pose problème (alors que j'aurais pensé l'inverse) du coup j'arrive à avoir mon préfixe il me reste maintenant à arriver à le distribuer correctement.
merci pour le tuto en tout cas, je pense que si on le suit vraiment à la lettre, il ne devrait pas y avoir de problème.
peut-être ajouter cette remarque: "ne pas modifier votre mac, ça bloquera l'IPv6" :D
-
Cool :)
Pour la partie TV, j'ai une approche plus simple, en créant un bridge du vlan 838 et 840.
Ca permet d'avoir une seule interface visible dans luci => WAN_TV.
Du coup, ça simplifie aussi les zones, avec une approche similaire à celle du vlan 832.
Soit tu zones directement vers LAN (ce que fais la livebox/liveboxtv), soit vers un LAN_TV sur un vlan dédié.
Tu bloques l'input/forward, et tu autorises juste via 2 rules, l'input sur le protocole igmp, et le forward udp sur une adresse multicast dans ta zone lan.
Et tout fonctionne, sans que ce soit trop complexe :)
Si ça t'interesse, je peux faire un petit tuto alternatif.
Est-ce que tu peux détailler cette configuration?
Est-ce que cela permettrait de regarder les flux de la TV (ceux sans DRM) sur VLC sur son PC?
-
Est-ce que tu peux détailler cette configuration?
Est-ce que cela permettrait de regarder les flux de la TV (ceux sans DRM) sur VLC sur son PC?
Si tu veux regarder la tv depuis vlc sur un pc de ton lan il faut juste ne pas utiliser le vlan19 pour la tv comme sur le tuto, mais envoyer le flux multicast sur le lan (en gros faire comme la livebox) :
Changement Firewall :
config rule
option src wanTV
option proto igmp
option target ACCEPT
config rule
option src wanTV
option proto udp
option dest lan
option dest_ip 224.0.0.0/4
option target ACCEPT
option family ipv4
config forwarding
option dest 'lan'
option src 'wanTV'
Changement igmpproxy :
config igmpproxy
option quickleave 1
config phyint
option network tvorange
option direction upstream
list altnet "0.0.0.0/0"
config phyint lan
option network lan
option direction downstream
Changement network :
config interface 'lan'
option igmp_snooping 1 # Attention à bien l'activer, et si tu utilises une box derrière un switch il faudra gérer l'igmp snooping dessus.
-
Tada (https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=9e319b7ae268bc4546da0d42b95d700646b55f47). Il sera possible d'utiliser les options suivantes, probablement dès la prochaine version d'OpenWRT (v18.06.2) :
config interface 'wan6'
option noclientfqdn '1'
option noacceptreconfig '1'
# […]
Cool ça ! J'ai hâte :)
-
Bonjour,
J'essaie de configurer un R7800
Le wan = eth0
Une question bête :
Firewall :
config zone
option name 'wan'
option output 'ACCEPT'
option masq '1' #masquerade, on nat le flux ipv4 sortant du wan par l'ip public reçu sur eth1.
option input 'DROP'
option forward 'DROP'
option network 'wan'
option family 'ipv4'
config rule
option name 'Allow-DHCP-Renew'
option src 'wan'
option proto 'udp'
option dest_port '68'
option target 'ACCEPT'
option family 'ipv4'
ça va dans /etc/config/firewall ?
Va falloir que je test avec :
option flow_offloading 1
option flow_offloading_hw 1
Car pour le moment j'ai un débit de moule asmathique +-50mb en down et -1mb en up
PS : Une partie des captures d'écran du tuto sont HS
-
Bonjour,
J'essaie de configurer un R7800
Le wan = eth0
Une question bête :
Firewall :
config zone
option name 'wan'
option output 'ACCEPT'
option masq '1' #masquerade, on nat le flux ipv4 sortant du wan par l'ip public reçu sur eth1.
option input 'DROP'
option forward 'DROP'
option network 'wan'
option family 'ipv4'
config rule
option name 'Allow-DHCP-Renew'
option src 'wan'
option proto 'udp'
option dest_port '68'
option target 'ACCEPT'
option family 'ipv4'
ça va dans /etc/config/firewall ?
Va falloir que je test avec :
option flow_offloading 1
option flow_offloading_hw 1
Car pour le moment j'ai un débit de moule asmathique +-50mb en down et -1mb en up
PS : Une partie des captures d'écran du tuto sont HS
Oui la config des zones c'est sur le Firewall.
Pour ton débit, es-tu sûr que tout ton flux n'est pas en cs6 ?
Tu as bien utilisé les règles iptables (partie "iptables custom rules" du tuto) ?
Je vais revérifier les captures,
A+
-
Oui dans LUCI
j'ai mis ceci dans firewall custom rules
#ipv4
iptables -t mangle -A POSTROUTING -j CLASSIFY --set-class 0000:0001 ## En gros tout le flux sortant passe dans la file 1 qui est en prio 0
iptables -t mangle -A POSTROUTING -p icmp -j CLASSIFY --set-class 0000:0006 ##On passe le flux icmp dans la file 6 qui est en prio 6
iptables -t mangle -A POSTROUTING -p igmp -j CLASSIFY --set-class 0000:0006 ## On passe le flux igmp dans la file 6 qui est en prio 6
#ipv6
ip6tables -t mangle -A POSTROUTING -j CLASSIFY --set-class 0000:0001
ip6tables -t mangle -A POSTROUTING -p ipv6-icmp -j CLASSIFY --set-class 0000:0006
ip6tables -t mangle -A POSTROUTING -o eth0.832 -p udp --dport 547 -j CLASSIFY --set-class 0000:0006
Je galère , tout fonctionne sauf le débit .........
-
As-tu essayé en précisant l'interface de sortie pour chaque ligne ?
Car chez moi ça fonctionne bien:
# ipv4:
iptables -t mangle -A POSTROUTING -o eth0.832 -j CLASSIFY --set-class 0000:0001
iptables -t mangle -A POSTROUTING -o eth0.832 -p igmp -j CLASSIFY --set-class 0000:0006
iptables -t mangle -A POSTROUTING -o eth0.832 -p icmp -j CLASSIFY --set-class 0000:0006
iptables -t mangle -A POSTROUTING -o eth0.832 -p udp -m udp --dport 67 -j CLASSIFY --set-class 0000:0006
#ipv6:
ip6tables -t mangle -A POSTROUTING -o eth0.832 -j CLASSIFY --set-class 0000:0001
ip6tables -t mangle -A POSTROUTING -o eth0.832 -p ipv6-icmp -j CLASSIFY --set-class 0000:0006
ip6tables -t mangle -A POSTROUTING -o eth0.832 -p udp --dport 547 -j CLASSIFY --set-class 0000:0006
-
J'ai trouvé une partie du problème , j'avais activé le Hardware Nat ..... en le désactivant j'obtiens 650Mb en Down et 303Mb en UP avec la Livebox j'ai 945/300......
Le R7800 est pourtant équipé d'un dual core 1.7GHz , je comprends pas pourquoi l'activation du hw nat pose un problème
-
@hj67 pas besoin de la spécifier partout, ça marche impec avec les règles du tuto.
L'offloading Nat d'openwrt (la case que tu vois dans firewall) est encore en beta, et est loin de fonctionner avec tous les chip (et n'est pas nécessaire sur une grande partie).
Pour le R7800, en cherchant un peu sur le net on voit en effet une baisse de perf en NAT sur ce modèle comparé au firmware stock, t'as tenté un speedtest en IPV6 ? Curieux de voir les résultats.
Sinon à ta place je tenterai de creuser voir si y'a pas un firmware snapshot qui a amélioré tout ça, tu peux prendre le dernier ici => https://downloads.openwrt.org/snapshots/targets/ipq806x/generic/
-
Soit.
Perso, je préfère appliquer des règles là ou c'est nécessaire uniquement.
-
Soit.
Perso, je préfère appliquer des règles là ou c'est nécessaire uniquement.
Dans ce cas Le dhcpV4 ne passe pas par iptables, et on a pas le pb du renew comme sur dd-wrt, donc tu pourrais l'enlever aussi ;).
Edit :
Tu viens de me faire tilter par rapport à la règle sur l'igmp.
Tu l'utilises sur l'eth0.832, je vois pas pourquoi (le flux igmp orange passe par l'eth0.840), et d'ailleurs dans le tuto je le met dans la file 6 mais au final ça n'a aucun intérêt car toutes les files du vlan 840 sont en prio 5 avec le script.
Hum, je m'en vais faire quelques tests x).
Edit 2 :
Ok c'est juste pour faire propre et avoir ces protocoles de couche réseau (nos 2 règles icmp et igmp), toujours en prio 6, donc pas lié à la TV du vlan 840, je repars me coucher...
-
@hj67 pas besoin de la spécifier partout, ça marche impec avec les règles du tuto.
L'offloading Nat d'openwrt (la case que tu vois dans firewall) est encore en beta, et est loin de fonctionner avec tous les chip (et n'est pas nécessaire sur une grande partie).
Pour le R7800, en cherchant un peu sur le net on voit en effet une baisse de perf en NAT sur ce modèle comparé au firmware stock, t'as tenté un speedtest en IPV6 ? Curieux de voir les résultats.
Sinon à ta place je tenterai de creuser voir si y'a pas un firmware snapshot qui a amélioré tout ça, tu peux prendre le dernier ici => https://downloads.openwrt.org/snapshots/targets/ipq806x/generic/
Merci beaucoup
Maintenant j'obtiens 913/301Mb
Bon faut que je regarde pourquoi j'ai une erreur L11-06 sur le décodeur mais tout ça c'est en bonne voie , j'ai uniquement le replay qui fonctionne
-
Merci beaucoup
Maintenant j'obtiens 913/301Mb
Bon faut que je regarde pourquoi j'ai une erreur L11-06 sur le décodeur mais tout ça c'est en bonne voie , j'ai uniquement le replay qui fonctionne
Ah ba génial pour le débit,
Tu es en config vlantv ? avec le décodeur sur le port 3 ?
Que donne un more /etc/igmpproxy.conf et un more /etc/sysctl.conf | grep igmp_version
Peux-tu envoyer ton fichier firewall ?
A+
-
J'ai mis à jour le tuto en changeant la chaine d'authentification pour correspondre à ce qui est désormais requis par Orange.
On a pas la chaine complète que renvoi la livebox, mais ça suffit pour obtenir notre ip, du moins pour l'instant.
Merci aux membres qui nous ont permis d'être prêt pour le changement :).
-
Merci.
J'ai mis un peu de temps à comprendre pourquoi je n'avais plus de connection ;)
-
Pareil. Par contre, l'heure n'aidant pas et mon daltonisme non plus, j'ai pas tout de suite pigé qu'il fallait modifier la chaîne avec son propre identifiant... :D
-
Bonjour, et merci pour ce tuto super instructif.
J'essaie d'adapter la conf pour mon vieux routeur Netgear WNDR3800 (v2) et je galère pour faire fonctionner le téléphone.
Côté Internet tout fonctionne, que ça soit en filaire ou en wifi.
Le switch présent dans mon routeur a un schéma particulier : je n'ai pas de port WAN sur le switch et un des ports n'est apparemment pas utilisé
https://wiki.openwrt.org/_media/media/netgear/wndr3700/wndr3700-c.png
Du coup j'ai utilisé la configuration suivante au niveau du switch (avec la Livebox branchée sur le port 1 du routeur (et qui correspond au port 3 du switch si j'en crois le schéma)) :
config switch
option name 'rtl8366s'
option reset '1'
option blinkrate '2'
option enable_vlan '1'
option enable_vlan4k '1'
option max_length '3'
config switch_vlan
option device 'rtl8366s'
option vlan '1'
option ports '0 1 2 5t'
option vid '1'
config switch_vlan
option device 'eth1.832'
option vlan '832'
option ports '3t 5t'
option vid '832'
config switch_port
option device 'rtl8366s'
option port '1'
option led '6'
config switch_port
option device 'rtl8366s'
option port '2'
option led '9'
config switch_port
option device 'rtl8366s'
option port '5'
option led '2'
Quand je démarre la Livebox, elle mouline avant d'afficher un avertissement indiquant que ni le réseau ni le téléphone ne sont disponibles.
J'ai sûrement fait des erreurs dans la conf, mais je n'arrive pas à trouver où.
Est ce que quelqu'un utilise ce routeur (je suis sous OpenWRT 18.06.1) ?
-
A l'aide de ce super fil (dont je remercie @ubune ainsi que tous les autres ayant contribué à obtenir ces informations), je viens de créer un dépôt sur GitHub permettant avec deux commandes d'avoir une configuration minimale pour obtenir une IPv4 et IPv6 sur un routeur OpenWRT : https://github.com/nagromc/openwrt-configuration-for-livebox
Pour l'instant, il fonctionne pour mes deux routeurs :
- Linksys WRT1900ac v2.0
- Linksys WRT610N v1.0
Je pense qu'il est possible de généraliser le script en fonction du type de routeur. Mais je ne suis pas spécialiste alors je préfère m'en remettrre à vous. N'hésitez pas à ouvrir une Pull Request si vous voulez l'améliorer !
Pour ceux que ça intéresse, il est même possible de l'intégrer dans un autre pour plus de customisation et d'automatisation. Par exemple : https://github.com/nagromc/openwrt-config
-
A l'aide de ce super fil (dont je remercie @ubune ainsi que tous les autres ayant contribué à obtenir ces informations), je viens de créer un dépôt sur GitHub permettant avec deux commandes d'avoir une configuration minimale pour obtenir une IPv4 et IPv6 sur un routeur OpenWRT : https://github.com/nagromc/openwrt-configuration-for-livebox
Pour l'instant, il fonctionne pour mes deux routeurs :
- Linksys WRT1900ac v2.0
- Linksys WRT610N v1.0
Je pense qu'il est possible de généraliser le script en fonction du type de routeur. Mais je ne suis pas spécialiste alors je préfère m'en remettrre à vous. N'hésitez pas à ouvrir une Pull Request si vous voulez l'améliorer !
Pour ceux que ça intéresse, il est même possible de l'intégrer dans un autre pour plus de customisation et d'automatisation. Par exemple : https://github.com/nagromc/openwrt-config
Super tout ça, oui ça serait top de l'avoir au moins pour les modèles les plus utilisés.
Y'a juste un hic, après l'installation d'openwrt il nous manque quelques packages, du coup l'objectif ultime serait l’exécution du script avec le routeur derrière la box, et à la fin du script on peut virer la box et mettre le routeur à la place ;).
J'ai pas beaucoup de temps en ce moment, mais j'essaierai de m'y pencher un jour.
@Rhon, le tuto est fait pour un remplacement de la livebox et pas de téléphonie possible dans ce cas.
-
Super tout ça, oui ça serait top de l'avoir au moins pour les modèles les plus utilisés.
Le problème c'est que je ne connais pas les autres modèles. Comme je disais, l'idéal serait d'avoir une configuration par type de routeur. Mais je ne m'y connais pas assez pour généraliser ça. Juste, j'ai cru comprendre qu'il existait des routeurs avec n CPU. Par exemple mon Linksys WRT1900ac en a deux, mais mon Linksys WRT610N n'en a qu'un seul.
Et peut-être que le nombre de CPU n'est pas la seule caractéristique non plus :-\ Si vous avez des infos, n'hésitez pas. Mais en attendant, n'hésitez pas à partager la config pour votre routeur.
Y'a juste un hic, après l'installation d'openwrt il nous manque quelques packages, du coup l'objectif ultime serait l’exécution du script avec le routeur derrière la box, et à la fin du script on peut virer la box et mettre le routeur à la place ;).
C'est pour ça que le dépôt nagromc/openwrt-configuration-for-livebox est une dépendance du dépôt nagromc/openwrt-config. L'objectif de nagromc/openwrt-configuration-for-livebox est d'avoir une configuration minimale permettant d'obtenir une IPv4 et une IPv6, et rien d'autre (i.e. pas de TV). Le dépôt nagromc/openwrt-config quant à lui installe tous les paquets dont j'ai besoin pour mon usage personnel (résolveurs DNS OpenNIC, règles de pare-feu, activation du Wi-Fi, serveur DLNA, etc.)
Ainsi, à aucun moment je n'ai besoin de la Livebox pour installer configurer mon routeur (d'ailleurs, elle est dans sa boîte quand je réinstalle OpenWRT sur mon routeur). Je branche mon routeur en filaire à ma machine. Je n'ai qu'à positionner le fti et lancer ./install wrt1900acv2 pour récupérer les IP, puis faire mon install custom.
Depuis un OpenWRT avec une config usine, le script install du dépôt nagromc/openwrt-config va :
- télécharger la dépendance nagromc/openwrt-configuration-for-livebox ;
- lancer l'install nagromc/openwrt-configuration-for-livebox ;
- redémarrer le routeur pour qu'il récupère les adresse IPv4 et IPv6 ;
- installer et configurer mes paquets pour mon usage personnel.
On peut envisager d'ajouter le fait de vouloir configurer en même temps la TV avec un paramètre à passer au script d'installation. Mais je n'ai pas l'option TV avec mon abonnement alors je ne peux pas faire le développement.
-
@Ubune : merci pour la précision, je n'avais pas compris que la partie téléphonie nécessitait impérativement la Livebox.
Du coup je cherche à placer la livebox derrière mon routeur pour pouvoir garder la fonctionnalité téléphonie.
J'ai poursuivi mes investigations et je suis tombé la dessus : https://lafibre.info/remplacer-livebox/le-guide-complet-internet-tv-et-telephone-sans-livebox-et-bien-plus-plus/msg406223/#msg406223
Ça devrait être adaptable pour OpenWRT non ? Je vais essayer de me pencher sur le sujet ce week-end.
-
Utiliser la box derrière un routeur pour la téléphonie, ça se fait aisèment dans la plupart des cas. Il suffit d'un VLAN 832 taggué coté LAN du routeur, et d'un serveur DHCP sur ce VLAN envoyant ce qu'il faut à la Livebox (notamment l'option 120 => adresse du serveur SIP d'Orange, l'option 90 dont la valeur est fixe, de même pour l'option 125). Le traffic issu du VLAN 832 coté LAN a juste à être "natté" comme le reste du traffic internet.
Chez moi, sur un ER4, ça donne (je pense que c'est suffisemment clair pour être adaptable):
interfaces {
ethernet eth0 {
duplex auto
speed auto
vif 832 {
address 192.168.10.1/24
description Livebox
}
}
}
service {
dhcp-server {
disabled false
global-parameters "option Vendor-specific code 125 = string;"
global-parameters "option rfc3118-auth code 90 = string;"
global-parameters "option SIP code 120 = string;"
hostfile-update disable
shared-network-name VLAN_LIVEBOX_DHCP {
authoritative enable
subnet 192.168.10.0/24 {
default-router 192.168.10.1
dns-server 80.10.246.3
dns-server 81.253.149.10
domain-name orange.fr
lease 172800
start 192.168.10.30 {
stop 192.168.10.50
}
subnet-parameters "option rfc3118-auth 00:00:00:00:00:00:00:00:00:00:00:64:68:63:70:6c:69:76:65:62:6f:78:66:72:32:35:30;"
subnet-parameters "option Vendor-specific 00:00:05:58:0c:01:0a:00:01:00:00:00:ff:ff:ff:ff:ff;"
subnet-parameters "option SIP 00:06:73:62:63:74:33:67:03:4e:49:43:06:61:63:63:65:73:73:11:6f:72:61:6e:67:65:2d:6d:75:6c:74:69:6d:65:64:69:61:03:6e:65:74:00;"
}
}
}
}
-
@zoc : merci beaucoup pour l'exemple.
J'essaie de l'adapter pour OpenWRT, et je suis arrivé à ça :
Fichier /etc/config/network :
config interface 'loopback'
option ifname 'lo'
option proto 'static'
option ipaddr '127.0.0.1'
option netmask '255.0.0.0'
config interface 'lan'
option type 'bridge'
option proto 'static'
option ipaddr '192.168.2.1'
option netmask '255.255.255.0'
option gateway '192.168.2.1'
option stp '1'
option _orig_ifname 'eth0.1'
option _orig_bridge 'true'
option ifname 'eth0.1'
config interface 'wan'
option ifname 'eth1.832'
option proto 'dhcp'
option broadcast '1'
option vendorid 'sagem'
option reqopts '0x01 0x15 0x28 0x51 0x58 0x59 0x90'
option sendopts '0x4D:2b46535644534c5f6c697665626f782e496e7465726e65742e736f66746174686f6d652e4c697665626f7833 0x5a:00000000000000000000001a0900000558010341010dXXXXXXX'
option peerdns '0'
config switch
option name 'rtl8366s'
option reset '1'
option blinkrate '2'
option enable_vlan '1'
option enable_vlan4k '1'
option max_length '3'
config switch_vlan
option device 'rtl8366s'
option vlan '1'
option ports '0 1 2 5t'
option vid '1'
config switch_vlan
option device 'rtl8366s'
option vlan '832'
option ports '3 5t'
option vid '832'
config switch_port
option device 'rtl8366s'
option port '1'
option led '6'
config switch_port
option device 'rtl8366s'
option port '2'
option led '6'
config switch_port
option device 'rtl8366s'
option port '3'
option pvid 832
option led '9'
config switch_port
option device 'rtl8366s'
option port '5'
option led '2'
config interface 'tel'
option ifname 'eth1.832'
option proto 'static'
option ipaddr '192.168.100.254'
option netmask '255.255.255.0'
La conf DHCP (/etc/config/dnsmasq) :
config dnsmasq
option domainneeded '1'
option boguspriv '1'
option localise_queries '1'
option rebind_protection '1'
option rebind_localhost '1'
option local '/lan/'
option expandhosts '1'
option authoritative '1'
option readethers '1'
option leasefile '/tmp/dhcp.leases'
option nonegcache '1'
option filterwin2k '1'
option resolvfile '/etc/resolv.dns'
option dnssec '1'
option dnsforwardmax '2000'
list server '192.168.2.254'
list server '80.67.169.12'
list server '80.67.169.40'
option sequential_ip '1'
option localservice '0'
option nonwildcard '0'
option serversfile '/tmp/adb_list.overall'
config dhcp 'lan'
option interface 'lan'
option start '100'
option limit '150'
option leasetime '12h'
config dhcp 'tel'
option interface 'tel'
option start '250'
option limit '1'
option leasetime '1d'
list server '81.253.149.10'
list server '80.10.246.3'
option domain 'orange.fr'
list dhcp_option '3,192.168.100.254'
list dhcp_option '90,0x0000000000000000000000646863706c697665626f786672323530'
list dhcp_option '120,0x0006736263743367034e494306616363657373116f72616e67652d6d756c74696d65646961036e657400'
list dhcp_option '125,0x000005580c010a0001000000ffffffffff'
config dhcp 'wan'
option interface 'wan'
option ignore '1'
Et ma config firewall (/etc/config/firewall) :
config defaults
option syn_flood '1'
option output 'ACCEPT'
option forward 'REJECT'
option drop_invalid '1'
option input 'DROP'
config zone
option name 'lan'
option network 'lan'
option input 'ACCEPT'
option output 'ACCEPT'
option family 'ipv4'
option log '1'
option forward 'REJECT'
config zone
option name 'wan'
option network 'wan'
option input 'DROP'
option output 'ACCEPT'
option forward 'REJECT'
option masq '1'
option mtu_fix '1'
config rule
option name 'Allow-DHCP-Renew'
option src 'wan'
option proto 'udp'
option dest_port '68'
option target 'ACCEPT'
option family 'ipv4'
config forwarding
option src 'lan'
option dest 'wan'
config rule
option name 'Allow-DHCP-Renew'
option proto 'udp'
option dest_port '68'
option target 'ACCEPT'
option family 'ipv4'
option src 'lan'
config rule
option name 'Allow-Ping'
option src 'wan'
option proto 'icmp'
option icmp_type 'echo-request'
option family 'ipv4'
option target 'ACCEPT'
config include
option path '/etc/firewall.user'
config zone
option name 'tel'
option input 'ACCEPT'
option forward 'REJECT'
option output 'ACCEPT'
option network 'tel'
option log '1'
config forwarding
option src 'tel'
option dest 'wan'
J'ai sûrement raté un truc, car lorsque je reboote sur cette config, le routeur freeze complètement (aucune connexion possible, que ce soit en filaire comme en wifi) et je suis obligé de passer en mode failsafe pour revenir sur la config précédente.
Une idée de ce qui cloche ?
-
T'as un port console sur ce routeur ?
C'est surement les interfaces qui montent pas plutot qu'un freeze général non ?
Sinon pour info je reçois mon décodeur TV5 aujourd'hui normalement, j'essaie de le faire fonctionner (dhcp option 125 sur le vlantv) et je mettrai à jour le tuto en conséquence.
A+
-
Non pas de port console, mon seul recours c'est le mode failsafe d'openwrt.
Faute de pouvoir faire fonctionner le bridge, je suis passé sur une conf légèrement différente pour bridger un port LAN et le port WAN du routeur, d'après ce que j'ai pu lire sur le wiki https://wiki.openwrt.org/toh/netgear/wndr3700#switch_ports_for_vlans (https://wiki.openwrt.org/toh/netgear/wndr3700#switch_ports_for_vlans)
Du coup j'ai cette conf :
config interface 'loopback'
option ifname 'lo'
option proto 'static'
option ipaddr '127.0.0.1'
option netmask '255.0.0.0'
config interface 'lan'
option type 'bridge'
option proto 'static'
option ipaddr '192.168.2.1'
option netmask '255.255.255.0'
option gateway '192.168.2.1'
option stp '1'
option ifname 'eth0.1'
config interface 'wan'
option proto 'dhcp'
option broadcast '1'
option vendorid 'sagem'
option reqopts '0x01 0x15 0x28 0x51 0x58 0x59 0x90'
option sendopts '0x4D:2b46535644534c5f6c697 [...]'
option peerdns '0'
option ifname 'eth1.832'
config interface 'tel'
option type 'bridge'
option ifname 'eth0.4 eth1.4'
option proto 'static'
option ipaddr '192.168.100.1'
option netmask '255.255.255.0'
option defaultroute '0'
config switch
option name 'rtl8366s'
option reset '1'
option blinkrate '2'
option enable_vlan '1'
option enable_vlan4k '1'
option max_length '3'
config switch_vlan
option device 'rtl8366s'
option vlan '1'
option ports '0 1 2 5t'
config switch_vlan
option device 'rtl8366s'
option vlan '4'
option ports '3 5t'
Si je mets un PC sur le port du routeur que j'ai bridgé avec le wan, ça fonctionne parfaitement : le pc obtient via DHCP une ip en 192.168.100.x et a bien accès au net.
J'ai vérifié avec wireshark, et mon serveur dhcp envoie bien les options attendues par la livebox (90 et 125).
Par contre ce que je ne m'explique pas, c'est que lorsque je branche la Livebox à la place du PC, il ne se passe absolument rien : on dirait qu'elle n'essaie même pas d'appeler le DHCP, un
tcpdump -vvnes0 -i br-tel port 67 or port 68
ne me renvoie absolument rien.
Je sèche complètement :-[
-
Par contre ce que je ne m'explique pas, c'est que lorsque je branche la Livebox à la place du PC, il ne se passe absolument rien : on dirait qu'elle n'essaie même pas d'appeler le DHCP, un
tcpdump -vvnes0 -i br-tel port 67 or port 68
ne me renvoie absolument rien.
Je sèche complètement :-[
c'est normal et confus vu ta conf.
tu bridge les vlan 4 de eth0 et eth1. ca ne sert a rien car la livebox attend un serveur dhcp sur le vlan 832.
t'as juste à mettre ton interface 'tel' dans eth0.832. edit: et ajouter le vlan 832 sur eth0 et un port physique sur lequel tu branche la livebox.
ps: si t'as qu'un port vers le cpu ca ne marchera , il te faut 2 ports CPU distincts pour faire cela. sinon y'aura collision vlan 832 entre lan et wan. fait nous une capture d'écran de la config switch de ton routeur ( http://192.168.2.1/cgi-bin/luci/admin/network/vlan )
edit: a priori t'as 2 ports CPU vu que tu as eth0 et eth1.
-
a me relire ce n'est pas clair pour le néophyte:
le truc c'est de bien comprendre le schema: https://wiki.openwrt.org/toh/netgear/wndr3700#switch_ports_for_vlans
c'est de bien comprendre qu'en interne tu as un routeur 2 ports (eth0 et eth1) relié a un switch 5 ports via le port eth0.
eth1 va directement sur un port physique (port wan) donc eth1.832 marche directement.
eth0 va sur le switch interne. Donc eth0.832 s'arrete au switch. pour qu'il entre/sorte du switch il faut aussi tag 832 au moins un des ports physiques du switch.
tout comme:
config switch_vlan
option device 'rtl8366s'
option vlan '1'
option ports '0 1 2 5t'
ceci relie les ports 0 1 2 avec eth0 sans vlan (vlan 1 = sans vlan).
il te faut donc ajouter:
config switch_vlan
option device 'rtl8366s'
option vlan '832'
option ports '3t 5t'
et le port 3 (port "1" sur le boitier) sera relié a eth0.832. on garde '3t' pour garder le tag 832 que la livebox attend.
tu peux ensuite utilisé eth0.832 dans ton inferface 'tel' sur laquelle il a y un serveur dhcp pour 192.168.100.x.
tu peux aussi mettre 832 sur tout les ports externes en plus du vlan par défault comme tu peux brancher le livebox ou tu veux.
-
Décodeur TV5 pleinement fonctionnel, il faut gérer l'option 125 dhcp sur le vlantv (à jour sur le tuto).
Sans l'option on obtient un message d'erreur indiquant que nous n'utilisons pas la bonne livebox, et qu'elle n'est pas compatible avec le décodeur (image d'une livebox pro barré).
J'ai juste adapté en prenant les infos du post de KalNightmare ici https://lafibre.info/remplacer-livebox/tuto-remplacer-la-livebox-par-un-routeur-dd-wrt-internet-tv/108/
Merci à eux :).
-
@kgersen : merci pour les explications, j'ai essayé de rectifier ma configuration de la façon suivante :
- /etc/config/network
config interface 'loopback'
option ifname 'lo'
option proto 'static'
option ipaddr '127.0.0.1'
option netmask '255.0.0.0'
config interface 'lan'
option type 'bridge'
option proto 'static'
option ipaddr '192.168.2.1'
option netmask '255.255.255.0'
option gateway '192.168.2.1'
option stp '1'
option ifname 'eth0.1'
config interface 'wan'
option proto 'dhcp'
option broadcast '1'
option vendorid 'sagem'
option reqopts '0x01 0x15 0x28 0x51 0x58 0x59 0x90'
option sendopts '0x4D:2b465[...] 0x5a:0000000000000000000000[...]'
option peerdns '0'
option ifname 'eth1.832'
config interface 'tel'
option ifname 'eth0.832'
option proto 'static'
option netmask '255.255.255.0'
option defaultroute '0'
option ipaddr '192.168.100.1'
config switch
option name 'rtl8366s'
option reset '1'
option blinkrate '2'
option enable_vlan '1'
option enable_vlan4k '1'
option max_length '3'
config switch_vlan
option device 'rtl8366s'
option vlan '1'
option ports '0 1 2 5t'
config switch_vlan
option device 'rtl8366s'
option vlan '832'
option ports '3t 5t'
Pour le dhcp, j'ai laissé :
config dhcp 'tel'
option leasetime '12h'
option domain 'orange.fr'
list server '80.10.246.3'
list server '81.253.149.10'
list dhcp_option '90,0x00067362637433670341554206616363657373116f72616e67652d6d756c74696d65646961036e657400'
list dhcp_option '125,0x000005580c010a0001000000ffffffffff'
option interface 'tel'
option start '2'
option limit '10'
Est ce que j'ai quelque chose à modifier à ce niveau là ? Parce que j'ai testé, et je n'ai toujours pas de DHCP sur le port 0 du routeur (celui identifié comme port n°3 au niveau de la config du switch d'après le schéma du wiki OpenWRT)
Quand je branche un PC à la place de la Livebox sur ce port, il ne récupère pas de DHCP non plus. Pourtant dans les logs du routeur je vois bien des DHCP offer partir, mais on dirait que le PC ne les reçoit pas.
Ci-joint une copie d'écran de ma conf switch dans l'interface web, il m'affiche 6 ports dont 2 que je n'arrive pas à identifier.
Physiquement, sur le switch, j'ai 5 ports : les ports numérotés 1 2 3 et 4 sur le boitier qui correspondent respectivement aux ports 4, 3, 2 et 1 dans la configuration OpenWRT, par contre le port WAN n'a pas l'air de remonter dans l'interface web, et à la place j'ai deux ports : un port CPU (eth0) et un 5e port qui n'a l'air connecté à rien.
Quand on parle de port "CPU" ça signifie quoi exactement ?
-
ton switch est mal reconnu par luci (il y a d'ailleurs un warning tout en haut de l'écran) mais ce n'est pas forcement un souci.
pour le port 4 dans l'interface quand tu branche quelque chose dessus (la livebox en principe) est-ce l'interface change et 'no-link' disparaît ?
Quand je branche un PC à la place de la Livebox sur ce port, il ne récupère pas de DHCP non plus. Pourtant dans les logs du routeur je vois bien des DHCP offer partir, mais on dirait que le PC ne les reçoit pas.
C'est normal on a configuré le dhcp pour qu'il sort sur le vlan 832 ce qu'un PC ne voit pas.
La livebox attend du traffic DHCP sur le vlan 832 -> on ne peut donc verifier le dhcp en utilisant un PC directement comme ca a moins de configurer ce PC pour fonctionner sur le vlan 832.
une solution pour tester est d'enlever le 't' de '3t' et ajouter option vid '832':
config switch_vlan
option device 'rtl8366s'
option vlan '832'
option ports '3 5t'
option vid '832'
Comme cela tu peux tester le dhcp avec un PC. mais pour la livebox il faut remettre le '3t ( le vid peut rester ce n'est pas gênant ).
Quand on parle de port "CPU" ça signifie quoi exactement ?
Ce sont les ports en interne dans le routeur. Tu en as 2 , eth0 et eth1.
C'est comme si tu avait dans le meme boitier un PC avec 2 cartes réseau et un switch avec 5 ports. Une des cartes réseau (eth0) est branché sur le switch et l'autre sort directement du boitier (eth1). Les 4 autres ports du switch sortent du boitier.
Il y a 3 numérotations différentes la:
- numéro physique écrit dehors sur le boitier ou port cpu interne
- numéro dans l'interface web (port 1, port 2, etc)
- numéro de port dans la config (option ports '0 1 2 5t' par exemple).
il faut bien faire la correspondance:
5 = port cpu = eth0
3 = port 4 dans l'interface = port 1 physique (d'apres ce que tu indique).
-
Un grand merci pour toutes ces explications !
Alors le port 4 (dans l'interface web) correspond au port numéroté comme 1 sur le boîtier du routeur. Il s'agit du port sur lequel je branche mon PC pour tester le DHCP et sur lequel à terme je vais laisser la Livebox branchée. Quand j'ai fait la copie d'écran il n'y avait rien de branché, mais l'état change bien quand je branche soit la Livebox, soit mon PC sur ce port.
J'ai détagué le port 3 et ajouté l'option vid '832' ce qui m'a permis de voir (avec un coup de wireshark sur le PC) que mon routeur, malgré ce qui est configuré, n'envoie pas les options dhcp 90 et 125.
Je vais potasser la doc et les forums OpenWRT pour essayer de comprendre pourquoi.
-
en ligne de commande, fait 'ps', regarde la ligne ou y'a dnsmasq. Note le chemin du fichier apres le -C:
en principe un truc du genre: "/var/etc/dnsmasq.conf.xxxxx"
affiche le contenu de ce fichier.
c'est la syntax de dnsmasq ( 8 ): https://linux.die.net/man/8/dnsmasq (voir -O)
les digits hexa doivent être en format avec ':' :
Data types allowed are comma separated dotted-quad IP addresses, a decimal number, colon-separated hex digits and a text string. If the optional network-ids are given then this option is only sent when all the network-ids are matched
par exemple:
dhcp-option=90,00:06:73:62....
-
Hello,
J'ai modifié le format des options pour ajouter les ":" et je retrouve bien ces options avec le format attendu dans le fichier /var/etc/dnsmasq.conf.cfg.01411c :
dhcp-option=tel,90,00:06:73:62:63:74:33:67:03:4e:49:43:06:61:63:63:65:73:73:11:6f:72:61:6e:67:65:2d:6d:75:6c:74:69:6d:65:64:69:61:03:6e:65:74:00
dhcp-option=tel,125,00:00:05:58:0c:01:0a:00:01:00:00:00:ff:ff:ff:ff:ff
dhcp-option=tel,6,80.10.246.3,81.253.149.10
Par contre je ne reçois toujours pas les options 90 et 125 en dhcp, alors que la 6 passe bien.
Les valeurs doivent obligatoirement être en hexa ? Est ce que dnsmasq ne préférerait pas des chaînes de caractères ? A priori c'est possible d'après la doc.
-
text aussi ca passe mais l'hex devrait passer non ?
y'a pas de log dnsmasq ?
-
ps: attention , le serveur dhcp n'envoi des options que si on lui demande. il faut utiliser "dhcp-option-force" (je doute que ton pc demande 90 et 125).
-
Effectivement, avec le dhcp-option-force je reçois bien les options sur le PC :D
Par contre il y a des trucs que je ne comprends toujours pas : je vois bien passer les requêtes DHCP du PC, que ce soit dans les logs dnsmasq ou via tcpdump avec
tcpdump -vnes0 -i eth0.832 port 67 or port 68
par contre quand je branche la livebox à la place du PC sur le même port, je ne vois jamais rien arriver ni dans les logs dnsmasq, ni via tcpdump. La livebox finit par afficher le message "Connexion perdue" au bout d'un moment.
Même si le PC ne demande pas les options 90 et 125, la livebox elle est censée les demander, et dnsmasq devrait donc les envoyer non ?
J'ai pensé a un problème de câble, du coup j'ai inversé le câble que j'utilisais pour le PC avec celui fourni avec la Livebox, mais le résultat est le même : le PC voit le dhcp, et la Livebox non. Je précise que je fais bien attention a taguer le port 3 sur le switch avant de rebrancher la Livebox.
Du coup j'ai aussi pensé que ma Livebox pouvait être défectueuse. Mais quand je la branche directement sur la prise fibre, elle se connecte sans souci.
Question bête, mais le port de la Livebox que je dois relier à mon routeur, c'est bien le port RJ45 marqué comme WAN sur la Livebox (a coté du port qui accueille le port fibre) ?
-
oui c'est bien le port WAN de la livebox qu'il faut brancher.
-
En désespoir de cause, j'ai fait un reset de la Livebox en utilisant le bouton derrière le boîtier, et je l'ai rebranchée directement sur la prise fibre murale.
Après avoir saisi mon identifiant dans l'interface web, et 3 reboots / mise à jour, j'ai vérifié que tout fonctionnait (internet / wifi / tél) puis je l'ai éteinte et rebranchée derrière mon routeur.
Et là surprise, j'ai enfin vu passer dans tcpdump des requêtes DHCP en provenance de la Livebox.
Du coup j'ai pu ajuster ma configuration, et cette fois le téléphone fonctionne comme attendu.
Je remet ma configuration définitive, au cas où ça puisse dépanner quelqu'un :
- Pré-requis : dérouler la partie Internet IPv4 du tuto
- Configuration du /etc/config/network : on sélectionne un port du switch que l'on va taguer avec le vlan 832 pour pouvoir brancher la Livebox, et on ajoutes une interface tel qui permettra d'avoir une instance dhcp dédiée pour la box :
config interface 'tel'
option ifname 'eth0.832'
option proto 'static'
option netmask '255.255.255.0'
option defaultroute '0'
option ipaddr '192.168.100.1'
config switch
option name 'rtl8366s'
option reset '1'
option blinkrate '2'
option enable_vlan '1'
option enable_vlan4k '1'
option max_length '3'
config switch_vlan
option device 'rtl8366s'
option vlan '1'
option ports '0 1 2 5t'
config switch_vlan
option device 'rtl8366s'
option vlan '832'
option ports '3t 5t'
option vid '832'
Remarque : l'option vid 832 est facultative, c'est pour pouvoir déboguer le DHCP en branchant un PC à la place de la Livebox. Dans ce cas là, ne pas oublier aussi de dé-taguer le port du switch sur le vlan 832 (3t à remplacer par 3 dans l'exemple), sinon le PC ne verra pas passer les trames.
- On configure ensuite le DHCP dans /etc/config/dhcp :
config dhcp 'tel'
option leasetime '12h'
option domain 'orange.fr'
option interface 'tel'
option start '1'
option limit '2'
list dhcp_option_force '90,00:00:00:00:00:00:00:00:00:00:00:64:68:63:70:6c:69:76:65:62:6f:78:66:72:32:35:30'
list dhcp_option_force '120,00:06:73:62:63:74:33:67:03:4e:49:43:06:61:63:63:65:73:73:11:6f:72:61:6e:67:65:2d:6d:75:6c:74:69:6d:65:64:69:61:03:6e:65:74:00'
list dhcp_option_force '125,00:00:05:58:0c:01:0a:00:01:00:00:00:ff:ff:ff:ff:ff'
list dhcp_option '6,80.10.246.3,81.253.149.10'
Le dhcp_option_force ne sert que pour le debug depuis un PC, il peut être remplacé par un dhcp_option car de toute façon la Livebox demande explicitement ces options au serveur DHCP.
- Pour terminer, on n'oublie pas de mettre à jour le firewall :
config zone
option name 'tel'
option network 'tel'
option output 'ACCEPT'
option log '1'
option family 'ipv4'
option input 'ACCEPT'
option forward 'REJECT'
config forwarding
option dest 'wan'
option src 'tel'
config rule
option src 'tel'
option dest_port '53'
option proto 'tcpudp'
option target 'ACCEPT'
option name 'DNS for Livebox'
config rule
option src 'tel'
option dest_port '67-68'
option proto 'udp'
option target 'ACCEPT'
option name 'DHCP for Livebox'
config rule
option name 'Allow-DHCP-Renew for Livebox'
option proto 'udp'
option dest_port '68'
option target 'ACCEPT'
option family 'ipv4'
option src 'tel'
Un grand merci à tous, et plus particulièrement à kgersen pour sa patience et ses explications !
-
cool que ca marche ! merci pour la synthèse 8)
-
Parfait, j'ai maj la partie "Alternatives" avec l'option livebox derrière le routeur et un lien vers ton post récap.
Bravo à vous ;).
A+
-
Orange bloque la connexion quand on tente de bypasser leur box? :o
Si c'est le cas autant dire que si je achete un routeur cisco á 2 mil balle bah j'espere bien que je puisse metre, parce que non sinon il vont etrê surpris de mon appele telephonic ça c'est sur ;D parce que si quelqun achete un routeur cisco avec fibre directement "Plugable" dedans orange devras de dem**** pour que je puisse meter le routeur operacionelle de mon cotê .
C'est juste un exemple pas un fait .
-
A partir du moment où les conditions générales d’utilisation des offres grand public indiquent que la Livebox est obligatoire pour accéder aux services, tu as donc le choix:
- De ne pas t’abonner chez eux si ces conditions ne te conviennent pas (mais encore faut-il prendre la peine de les lire)
- D’utiliser le matériel qu’ils fournissent
- D’utiliser un autre matériel à tes risques et périls mais tu ne pourras rien reprocher à Orange si ça ne fonctionne pas.
-
Bonjour à tous,
J'ai récemment basculé mon WRT1900ACS sur openwrt snapshot du 30/11/18.
Attention, sur mon Linksys, sur cette version snapshot si l'option vlan est validé sur le switch, le lan passe de eth0 à eth0.1 (soyez prudent si vous reprenez un ancien fichier network après maj vous perdez la main sur le routeur si vous envoyez un eth0 simple).
Pour l'ipv6, plus besoin de modifier la lib dhcpv6.sh, comme indiqué par Kéa en page 3 c'est désormais géré.
Il suffit donc d'ajouter les options dans le fichier network sur l'interface wan6:
option noclientfqdn '1'
option noacceptreconfig '1'
Igmpproxy a aussi un peu changé, le fichier de config prend désormais aussi la zone Firewall (en plus de l'interface).
Exemple de mon fichier de conf mtn =>
more /etc/config/igmpproxy
config igmpproxy
option quickleave 1
# option verbose [0-3](none, minimal[default], more, maximum)
config phyint
option network tvorange
option zone wanTV
option direction upstream
list altnet 0.0.0.0/0
config phyint
option network vlantv
option zone tv
option direction downstream
En tous cas tout fonctionne parfaitement chez moi, V4,V6 TV avec nouveau décodeur uhd.
J'ai mis à jour le tuto avec les indications dans le cas ou vous êtes en snapshot ou 18.01.02 (quand il sortira).
-
Merci pour ce super auto qui m'a permis de remplacer ma LiveBox par une VM sous OpenWRT... ...en ADSL!
En effet, je n'ai pas encore la fibre chez moi, même si ça ne devrait plus trop tarder. J'avais déjà réussi à utiliser OpenWRT pour me connecter en PPPoE, et je me suis inspiré de ce fil pour me connecter maintenant en DHCP. Du coup, l'IPv6 fonctionne!
Pour info, la config est sensiblement la même, mais pas besoin de jouer avec les VLAN : il faut mettre VPI/VCI en 8/32 sur le modem ADSL en mode bridge.
-
Merci pour ce super auto qui m'a permis de remplacer ma LiveBox par une VM sous OpenWRT... ...en ADSL!
En effet, je n'ai pas encore la fibre chez moi, même si ça ne devrait plus trop tarder. J'avais déjà réussi à utiliser OpenWRT pour me connecter en PPPoE, et je me suis inspiré de ce fil pour me connecter maintenant en DHCP. Du coup, l'IPv6 fonctionne!
Pour info, la config est sensiblement la même, mais pas besoin de jouer avec les VLAN : il faut mettre VPI/VCI en 8/32 sur le modem ADSL en mode bridge.
Ravi que ça t'aies aidé :), et oui la fibre à Valbonne a déjà commencé à faire son bout de chemin.
Par curiosité, pour ta VM openwrt, tu as récupéré quelle version ? tu l'as fait tourner sur quel d'hyperviseur ?
-
Ravi que ça t'aies aidé :), et oui la fibre à Valbonne a déjà commencé à faire son bout de chemin.
Par curiosité, pour ta VM openwrt, tu as récupéré quelle version ? tu l'as fait tourner sur quel d'hyperviseur ?
Pour ma VM OpenWRT, j'ai utilisé la dernière version stable, soit la 18.06.01. Pour l'hyperviseur, j'ai utilisé VirtualBox sur macOS Mojave. Ca marche très bien, mais pas très user friendly à redémarrer si ça plante quand je ne suis pas là!
Donc je l'ai remplacé temporairement par un raspberry pi B (1ère génération). Ca fait le job en ADSL avec mon pauvre débit actuel, même en y ajoutant de la QoS. Mais pour Noël, j'ai commandé un Netgear R7800 en prévision de la fibre ;)
-
Bonjour à tous,
J'ai récemment basculé mon WRT1900ACS sur openwrt snapshot du 30/11/18.
J'ai fait l'upgrade également il y a quelques jours (r9007-529c95c). Ca tourne nickel.
J'ai juste la tv qui a un peu galéré, avec des micro coupures. En debbugant, j'ai vu que je changeais en permanance d'adresse multicast (sans zapper)... avec des timeouts & co.
C'est rentré dans l'ordre tout seul, je n'ai pas d'explication, m'enfin, ça tourne :)
-
Bonjour à tous !
Tout d'abord, merci pour ce super tuto détaillé ;)
Malheureusement, bien que j'aie l'impression de l'avoir suivi à la lettre, je n'arrive pas à obtenir une IP côté WAN sur mon routeur R7800 avec openwrt.
En sniffant entre l'interface WAN du routeur et l'ONT d'orange, je vois des requêtes DHCP sur le vlan 832, ainsi qu'une réponse mais qui ne semble pas prise en compte.
Depuis le routeur, un tcpdump affiche également les dhcp-reply de mon opérateur, mais mon routeur semble les ignorer.
Voici ma configuration actuelle :
/etc/config/network
config interface 'loopback'
option ifname 'lo'
option proto 'static'
option ipaddr '127.0.0.1'
option netmask '255.0.0.0'
config globals 'globals'
option ula_prefix 'fdb4:5664:9ff1::/48'
config interface 'lan'
option type 'bridge'
option ifname 'eth1.1'
option proto 'static'
option netmask '255.255.255.0'
option ip6assign '60'
option delegate '0'
option ipaddr '10.20.0.1'
config interface 'wan'
option ifname 'eth0.832'
option proto 'dhcp'
option broadcast '1'
option vendorid 'sagem'
option reqopts '0x01 0x15 0x28 0x51 0x58 0x59 0x90'
option sendopts '0x4D:2b46535644534c5f6c697665626f782e496e7465726e65742e736f66746174686f6d652e4c697665626f7833 0x5a:00000000000000000000001a0900000558010341010dXXXXXXXXXXXXXXXXXXXXXX'
config switch
option name 'switch0'
option reset '1'
option enable_vlan '1'
config switch_vlan
option device 'switch0'
option vlan '1'
option ports '1 2 3 4 6t'
option vid '1'
config switch_vlan
option device 'switch0'
option vlan '2'
option ports '0t 5t'
option vid '832'
config switch_vlan
option device 'switch0'
option vlan '3'
option ports '0t 5t'
option vid '838'
config switch_vlan
option device 'switch0'
option vlan '4'
option ports '0t 5t'
option vid '840'
/etc/config/firewall
############ Defaults ###########
config defaults
option syn_flood '1'
option drop_invalid '1'
option input 'DROP'
option output 'DROP'
option forward 'DROP'
############ Zones ##############
config zone
option name 'lan'
option network 'lan'
option family 'ipv4'
option input 'REJECT'
option output 'ACCEPT'
option forward 'DROP'
config zone
option name 'wan'
option network 'wan'
option family 'ipv4'
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'DROP'
option masq '1'
option mtu_fix '1'
############ Forwarding #########
config forwarding
option src 'lan'
option dest 'wan'
option family 'ipv4'
############ Rules ##############
##### WAN #####
config rule
option name 'allow DHCP-renew'
option family 'ipv4'
option src 'wan'
option proto 'udp'
option dest_port '68'
option target 'ACCEPT'
##### LAN #####
config rule
option name 'lan admin'
option family 'ipv4'
option proto 'tcp'
option src 'lan'
option dest_ip '10.20.0.1'
option dest_port '22 80 443'
option target 'ACCEPT'
config rule
option name 'lan icmp'
option family 'ipv4'
option proto 'icmp'
option src 'lan'
option dest_ip '10.20.0.1'
option target 'ACCEPT'
############ DNAT ###############
config redirect
option name 'ssh'
option family 'ipv4'
option proto 'tcp'
option src 'wan'
option src_dport '443'
option dest 'lan'
option dest_ip '10.20.0.1'
option dest_port '22'
option target 'DNAT'
############ Specific ###########
config include
option path '/etc/firewall.user'
(le input 'ACCEPT' de la zone 'wan' est amené à passer en 'DROP' une fois la config fonctionnelle)
Merci d'avance pour votre aide ! :)
-
Je serais bien preneur aussi d'info pour le R7800 , j'ai pas réussi à faire fonctionner correctement Openwrt , j'avais un débit asthmatique avec la CS6 ou non
-
Problème règlé !
Pour une raison que j'ignore, les requêtes DHCP sortantes étaient tagguées en priorité 0, il faut bien faire attention à ce qu'elles sortent en priorité 6 sinon la réponse DHCP d'orange n'est pas correcte (bail dhcp avec IP privée)
Je serais bien preneur aussi d'info pour le R7800 , j'ai pas réussi à faire fonctionner correctement Openwrt , j'avais un débit asthmatique avec la CS6 ou non
Je n'ai qu'un débit de 300Mbps/300Mbps avec ma box en temps normal, mais j'ai remarqué qu'ajouter l'option
option flow_offloading 1
option flow_offloading_hw 1
descend mon débit à 50Mbps/0.25Mbps sur le R7800, peut être que ton problème vient de là ?
Bonne chance en tout cas.
-
Problème règlé !
Pour une raison que j'ignore, les requêtes DHCP sortantes étaient tagguées en priorité 0, il faut bien faire attention à ce qu'elles sortent en priorité 6 sinon la réponse DHCP d'orange n'est pas correcte (bail dhcp avec IP privée)
Je n'ai qu'un débit de 300Mbps/300Mbps avec ma box en temps normal, mais j'ai remarqué qu'ajouter l'option
option flow_offloading 1
option flow_offloading_hw 1
descend mon débit à 50Mbps/0.25Mbps sur le R7800, peut être que ton problème vient de là ?
Bonne chance en tout cas.
Bonjour et top si ça fonctionne ;)
Pour la prio cs6 : Malgrès l’exécution du script ta requête était toujours en cs0 ?
On m'avait parlé d'un cas ou il fallait relancer le wan après un démarrage (ifdown wan puis ifup wan) pour ce pb, toi si tu reboot ça fonctionne toujours ?
Pour le débit attention aux custom rules d'iptables, et bien sûr éviter l'offloading si pas nécessaire (dépend de votre soc).
-
Je m'insère dans la discussion pour aborder quelques questions :
1) Est-ce qu'une box sous OpenWRT est en mesure de supporter le NAT et le rourage de la fibre à 1Gbit/s ?
2) Peut-on connecter le décodeur TV UHD via WIFI ?
-
Je m'insère dans la discussion pour aborder quelques questions :
1) Est-ce qu'une box sous OpenWRT est en mesure de supporter le NAT et le rourage de la fibre à 1Gbit/s ?
2) Peut-on connecter le décodeur TV UHD via WIFI ?
Bonjour,
1- Si par "box" tu entends routeur, un EdgerouterX à 50 euros monte jusqu'à 700Mbps en nat et du 900mbps avec offloading actif, après sur des modèles un peu plus cher c'est très simple, un Linksys 1200ac tu routes le giga avec 15% d'utilisation cpu.
2- Oui il suffit que tu crées un ssid attaché au vlantv (si tu suis le tuto).
Edit : désolé j'avais loupé l'info, mais la TV5 doit obligatoirement s'associer en WPS..., donc il te faudra un AP qui sait gerer les vlan/ssid et avec cette fonction.
A+
-
Merci !
-
Openwrt 18.02 est disponible depuis le 31/01 :)
Nouveautés :
Linux kernel updated to versions 4.9.152/4.14.95 (from 4.9.120/4.14.63 in v18.06.1)
Security fixes for the Linux kernel, GNU patch, Glibc, BZip2, Grub, OpenSSL and MbedTLS
Build system bug fixes
IPv6 and network service fixes
Ce qui nous interesse pour l'ipv6 => 9e319b7 odhcp6c: add client fqdn and reconfigure options (+9,-3)
Plus de détail ici : https://openwrt.org/releases/18.06/changelog-18.06.2
J'ai pas encoré migré (je suis toujours en snapshot) mais je me tate à maj le tuto avec un exemple en 18.02 uniquement et sans la partie vlan 838 (qui n'est plus obligatoire), bien que mon routeur apprend toujours les routes associées à l'interface Replay.
-
Bonjour,
Un petit tuto avec le partage des fichiers etc/config/network, Firewall etc ... serait bienvenu ;) il y aurait "seulement" a ajouter nos identifiants :P
-
Bonjour,
Un petit tuto avec le partage des fichiers etc/config/network, Firewall etc ... serait bienvenu ;) il y aurait "seulement" a ajouter nos identifiants :P
J'ai maj le tuto pour la version 18.06.02 qui est donc désormais obligatoire si on suit le tuto.
J'ai fait du propre : eth1.838 éliminé, firewall optimisé etc. et avec les fichiers en pièce-jointe.
J'ai eu un pb avec l'interface wan au boot (en 18.06.02 snapshot), je fais un ifdown/ifup du wan après reboot (automatique via rc.local) et ça fonctionne.
Je n'ai pas encore testé la TV même si avec le tuto à jour ça devrait être opérationnel, je testerai ce week.
Si une âme charitable ayant un routeur sous openwrt 18.06.02 peut :
- installer les paquets => opkg update && opkg install iptables-mod-ipopt igmpproxy ip-full
- Activer le demarrage auto d'igmpproxy => /etc/init.d/igmpproxy enable
- importer le zip dans le routeur, personnaliser le fti (fichier network wan et wan6), reboot et me dire si tout est fonctionnel (en théorie ipv4 + ipv6 + tv !) ça serait top :)
A+
-
Bon gros problème, je vais surement revenir en arrière pour le tuto.
En passant à la 18.06.02 release, le script vlan prio ne fait plus effet, on envoi tous en CS0.
Le hic, c'est que oui comme d'hab on peut gerer le dscp via la table mangle :
iptables -t mangle -A POSTROUTING -p icmp -j DSCP --set-dscp-class CS6
iptables -t mangle -A POSTROUTING -p udp --dport 67 -j DSCP --set-dscp-class CS6
#la même chose en ipv6 (avec cette fois le dhcpv6)
ip6tables -t mangle -A POSTROUTING -j DSCP --set-dscp-class CS0
ip6tables -t mangle -A POSTROUTING -p ipv6-icmp -j DSCP --set-dscp-class CS6
ip6tables -t mangle -A POSTROUTING -p udp --dport 547 -j DSCP --set-dscp-class CS6
Sauf que la ligne en rouge, comme on le sait déja (le script était là pour ça) est inutile car ce flux ne passe pas par iptables.
Edit :
C'était un pb d'interface, le script fonctionne toujours bien comme prévu.
En revanche au démarrage du routeur je suis pour l'instant obligé de relancer les interfaces (ifdown wan && ifup wan) pour obtenir l'ip publique, je suis en train d'analyser les 2 discover/request (1er avec la réponse privée en 172.16) et le second qui est correct.
Edit 2 :
Problème résolu en temporisant l’exécution du script et relancement automatique de l'interface wan (l'interface wan6 n'était pas impactée car je gère le dscp directement via iptables (/etc/firewall.user)
Fichier /etc/rc.local
sleep 10
ifdown wan
sh /etc/vlanprio.sh
ifup wan
exit 0
J'ai mis à jour les fichiers, nouvelle archive sur le post initial du tuto, j'ai pu tester TV + le dual stack et les débits.
-
Edit 2 :
Problème résolu en temporisant l’exécution du script et relancement automatique de l'interface wan (l'interface wan6 n'était pas impactée car je gère le dscp directement via iptables (/etc/firewall.user)
Fichier /etc/rc.local
sleep 10
ifdown wan
sh /etc/vlanprio.sh
ifup wan
exit 0
J'ai mis à jour les fichiers, nouvelle archive sur le post initial du tuto, j'ai pu tester TV + le dual stack et les débits.
J'ai eu le même problème, mais la séquence proposée ne fonctionnait pas non plus chez moi.
Cela semble fonctionner avec :
sleep 1
# Default to CoS 6 on WAN for DHCP requests to be accepted
ip link set eth0.832 type vlan egress 0:6
# Queue 6 to CoS 6 on WAN
ip link set eth0.832 type vlan egress 6:6
# Everything else to CoS 0 on WAN, through iptables
ip link set eth0.832 type vlan egress 1:0
# workaround private ip address on WAN
ifdown wan && ifup wan
ifdown wan6 && ifup wan6
exit 0
-
J'ai eu le même problème, mais la séquence proposée ne fonctionnait pas non plus chez moi.
Cela semble fonctionner avec :
sleep 1
# Default to CoS 6 on WAN for DHCP requests to be accepted
ip link set eth0.832 type vlan egress 0:6
# Queue 6 to CoS 6 on WAN
ip link set eth0.832 type vlan egress 6:6
# Everything else to CoS 0 on WAN, through iptables
ip link set eth0.832 type vlan egress 1:0
# workaround private ip address on WAN
ifdown wan && ifup wan
ifdown wan6 && ifup wan6
exit 0
Merci pour le retour, bon ba ça risque de devoir se personnaliser par rapport à notre routeur.
En tous cas j'ai pu tester mon rc.local sur un Linksys 1200ac et 1900acs et ça fonctionne sur les deux, mais ils sont très proche niveau hardware donc...
-
Je suis en train de préparer une config toute faite pour un ubiquiti ErX, (quelques ajustements, eth0 uniquement, il faut ajouter le lan_dev et wan_dev dans le fichier network...).
Et la je suis choqué, en 18.06.02 pour l'instant en double nat (mon PC derrière l'ubiquiti qui est derrière mon Linksys) je suis à 925/300 sans offloading avec 50% utilisation CPU, et je sature mon lien (945 débit utile )avec l'offloading :o , Pour un petit routeur qu'on trouve à 36euros chez le grossiste c'est impressionnant, surtout qu'avec les 256mB de nand et de Ram on peut s'amuser derrière (Filtrage Url, portail captif...).
Edit :
J'ai fini la config que j'ai pu tester (sauf la partie TV mais y'a pas de raison), et ça fonctionne au poil avec le même rc.local que sur le tuto.
En revanche j'ai pu me rendre compte que si on active l'offloading, on passe de 920-925 à 945mbps en débit descendant en ipv4, par contre pour une raison que j'ignore les perfs en ipv6 deviennent catastrophique (30/40mbps).
Alors qu'avec offloading désactivé, on obtient 915-920mbps en ipv6,920-925mbps ipv4, l'offloading est à oublier du coup sur ce modèle sauf si vous voulez fonctionner en ipv4 uniquement (et encore que vu ce qu'on gagne...).
J'ai uploadé le fichier config180602_edgerouterX_ok.zip, sur ce modèle on doit gérer manuellement l'attribution d'adresse mac sur nos interfaces exemple :
config interface 'wan'
option ifname 'eth0.832'
option proto 'dhcp'
option broadcast '1'
option vendorid 'sagem'
option reqopts '1 15 28 51 58 59 90'
option sendopts '77:2b46535644534c5f6c697665626f782e496e7465726e65742e736f66746174686f6d652e4c697665626f7833 90:00000000000000000000001a0900000558010341010d6674692f71707138383838'
config device 'wan_dev'
option name 'eth0.832'
option macaddr 'fc:ec:da:7c:b8:32'
Et il n'y a que l'eth0.
Les fichiers network (interface, switch) et vlanprio.sh sont donc différents, mais même principe (port 3 pvid vlan TV pour le décodeur).
A+
-
Pour info je viens de faire l'upgrade vers la 18.06.2, j'ai restauré le backup généré juste avant l'upgrade, réinstallé les paquets et tout à fonctionné sans les modifications apparemment obligatoires pour cette version. J'ai un TP-Link Archer C7 v2.
J'ai quand même fait les modifications car rien de méchant mais je tenais juste à faire la remarque ^^
EDIT: Et un énorme merci au passage pour l'auteur sans qui je serais toujours avec un double NAT dégueu !
-
Pour info je viens de faire l'upgrade vers la 18.06.2, j'ai restauré le backup généré juste avant l'upgrade, réinstallé les paquets et tout à fonctionné sans les modifications apparemment obligatoires pour cette version. J'ai un TP-Link Archer C7 v2.
J'ai quand même fait les modifications car rien de méchant mais je tenais juste à faire la remarque ^^
EDIT: Et un énorme merci au passage pour l'auteur sans qui je serais toujours avec un double NAT dégueu !
Merci pour le retour :)
Oui bien sur ça marchait très bien avant la 18.06.02, c'est juste pour ceux qui commencent à suivre le tuto, certains éléments du fichier network ne seront interprétés que sur une version snapshot ou 18.06.02, donc j'ai préféré capitaliser dessus et ainsi évité de maintenir l'ancienne méthode, ça aurait fait brouillon.
Petite question, sur ton TP-Link as-tu du modifier ton fichier rc.local comme sur le tuto pour que ça fonctionne ?
A+
-
Petite question, sur ton TP-Link as-tu du modifier ton fichier rc.local comme sur le tuto pour que ça fonctionne ?
Il me semble que j'ai testé un coup sans down et up de l'interface WAN et que ça à fonctionné, j'avais bien une IP publique. En revanche je n'ai jamais testé sans le sleep de 10 secondes avant l’exécution de script.
-
Bonjour à toutes et à tous,
Je viens d'arriver parmi vous avec mon nouvel abonnement fibre Orange Livebox Play + ONT + TV UHD (donc 300 mbps /300 mbps)
Je suis nouveau donc sur la fibre, et je passe du coaxial/cable (RED SFR 100 mbpd/5 mbps) à la fibre.
Je me rends compte que j'ai sûrement été un peu vite à migrer compte tenu des besoins que j'avais avant de migrer.
Avec des amis, nous gérons un petit réseau de serveur Synology pour des associations sportives et culturelles.
J'héberge à la maison le serveur de backup de l'association sur lequel nous faisons les sauvegardes, plus un tas de services (mail, serveurs web, etc).
Du coup, besoin d'ip fixe, ce que Orange ne fournit pas en standard (18 € à priori par mois).
Par ailleurs je constate que le router ne fonctionne pas bien pour ce qui est des PAT/NAT venant du WAN vers le LAN.
Pas de loopback également, je l'ai découvert, du coup les adresses WAN ne peuvent pas être utiliser dans le LAN, ce qui est gênant pour administrer nos services.
Je vais devoir garder mon abonnement RED SFR en attendant de pouvoir migrer sur une solution performante sur Orange fibre.
Sauf mauvais lecture de ma part, je n'ai pas trouvé trace dans votre magnifique TUTO de description de votre infrastructure pour ne pas me planter.
J'ai déjà acquis un router Ubiquiti ERX4 a qui j'ai fait subir un flash de openwrt en version 18.2, ll me semble.
J'aurai besoin d'un peu d'aide pour m'aiguiller sur le how to de ce TUTO.
Ma première question :
Que prendre comme swith manageables pour segmenter le LAN en Vlan afin de respecter l'infrastructure logique nécessaire à l'utilisation de la livebox play.
Mon WAN arrive dans le garage, j'ai l'ONT à côté de la livebox, puis un premier switch sur lequel doivent être connectés les Synology (2).
Sur le switch j'ai également un CPL qui me permet d'aller dans le salon pour la partie TV (je me rends compte que ça ne marchera pas vu que je n'ai pas de trunk / vlan vers le salon pour la TV, mais c'est pas super urgent.
sur ce CPL j'ai également une borne AIRPORT wifi qui me permet de déporter le WIFI non utilisable dans le garage.
Je dois donc segmenter tout ça.
J'ai vu ce switch chez amazon :
https://www.amazon.fr/Netgear-GS105E-200PES-Manageable-GS105Ev2-Protection/dp/B00GWKN1Q2/ref=sr_1_3?__mk_fr_FR=%C3%85M%C3%85%C5%BD%C3%95%C3%91&keywords=netgear+manageable&qid=1552458353&s=gateway&sr=8-3
Il va m'en falloir deux.
Deuxième question :
Grace à ce TUTO, mes machines seront elles visibles et utilisables WAN/LAN et réciproquement ?, j'avoue que ma première expérience de configuration avec la Livebox play m'a laissé sur le carreau, ça ne passe pas, ça bug, faut redémarrer après chaque conf, je ne sais pas exactement ce qui passe, s'il faut supprimer le firewall de la la livebox ...
En clair, malgré le problème de l'IP fixe, vais je obtenir le même niveau de services après cela, je pense que oui, mais une confirmation me soulagerait et m'aiderait à me lancer plus en avant (dans les dépenses).
Restera le problème de l'IP fixe, que je dois pouvoir contourner avec les services DYNDNS de Synology, et une redirection chez mon fournisseur DNS (ionos / 1 and 1).
Merci de votre coup de main, nous avons 17 sections associatives et nous sommes tous bénévoles, avec certaines connaissances en informatiques mais pas nécessairement des pro quoi...
Dominique
-
je répond très vite, quelqu'un pourra me corriger ou détailler plus s'il le souhaite:
aucun switch manageable n'est nécessaire puisque tu vas dédier un (des) port(s) de ton routeur à une utilisation spécifique (si tu choisit la simplicité, sinon, oui il te faudra un switch manageable):
en général un port dédié pour la TV, le reste pour internet. du coup aucun vlan à configurer en dehors du routeur.
Les machines se voient très bien, tu peux configurer le NAT en ipv4 pour que tes services soient accessibles depuis l'extérieur sans trop de problème. Openwrt n'est pas très compliqué à prendre en main.
pour la partie loopback, j'ai contourné le problème en mettant une règle iptable sur le routeur: tout ce qui vient du LAN et qui demande mon IP WAN est redirigé vers l'IP locale de mon serveur.
l'IP est "fixe" sur la fibre. ça fait + de 6 mois que je suis en fibre, j'ai redémarré ma box un nombre incalculable de fois au début pour configurer openwrt et elle tient très bien. et tu peux demander un préfixe ipv6 qui est fixe aussi.
-
Bonjour et merci pour ta réponse,
bin je constate que j'ai pas de bol alors.
Mon ip n'est pas fixe sur un contrat Orange Livebox play (300/300), elle change même sans redémarrer la box, dès qu'une synchro se coince.
J'ai un Syno DS918+ avec des VM dedans, donc plein d'IP, un deuxième Syno pour les backups du Syno du bureau de l'Association. Mes VM hébergent le serveur de mail, les services web, etc. Je sais ça fait assez usine à gaz mais cela fonctionnait parfaitement chez SFR.
Pour les switchs, idem, je vais devois faire un trunck vers un switch qui me sert dans le salon au travers du CPL, pas le choix je peux pas passer de cable ethernet dans le salon, sur le switch du salon j'ai le déport de réseau sur lequel j'ai mis une borne Airport (en point d'accès), la box TV Orange (qui est sur un VLAN tv), et une box Android pour kodi (donc Vlan data si je ne m'abuse), la TV elle même qui est en IP.
Donc, j'ai repéré ce switch manageable chez Netgear, si tu as l'info, il semble ok pour ce que j'ai à faire.
Je viens de suspendre la résiliation de RED SFR sur le coaxial pour avoir un réseau opérationnel sur les deux, sans trop changer de chose dans mon LAN. Cela va me permettre de me pencher studieuse sur ce TUTO.
Merci pour les confirmations de Openwrt et ses capacités, je me doutais bien que cela fonctionnait correctement mais une confirmation me fait du bien (l'âge surement).
Merci en tout cas pour tes infos super intéressantes.
Cordialement.
Dominique
-
Noter les guillemets autour de « fixe ».
Avec la Livebox, l’IP change effectivement à chaque reboot, puisqu’elle libère explicitement son bail. Avec un routeur tiers ce n’est généralement pas le cas.
Mon IPv4 et mon préfixe IPv6 n’ont pas changé depuis plus de 12 mois, j’utilise un EdgeRouter 4 (et EdgeOS).
-
Merci beaucoup c'est super sympa de savoir ça, effectivement mon adresse ip ne changeait pas sur red sfr avec mon router Cisco.
-
Bonjour et merci pour ta réponse,
bin je constate que j'ai pas de bol alors.
Mon ip n'est pas fixe sur un contrat Orange Livebox play (300/300), elle change même sans redémarrer la box, dès qu'une synchro se coince.
J'ai un Syno DS918+ avec des VM dedans, donc plein d'IP, un deuxième Syno pour les backups du Syno du bureau de l'Association. Mes VM hébergent le serveur de mail, les services web, etc. Je sais ça fait assez usine à gaz mais cela fonctionnait parfaitement chez SFR.
Pour les switchs, idem, je vais devois faire un trunck vers un switch qui me sert dans le salon au travers du CPL, pas le choix je peux pas passer de cable ethernet dans le salon, sur le switch du salon j'ai le déport de réseau sur lequel j'ai mis une borne Airport (en point d'accès), la box TV Orange (qui est sur un VLAN tv), et une box Android pour kodi (donc Vlan data si je ne m'abuse), la TV elle même qui est en IP.
Donc, j'ai repéré ce switch manageable chez Netgear, si tu as l'info, il semble ok pour ce que j'ai à faire.
Je viens de suspendre la résiliation de RED SFR sur le coaxial pour avoir un réseau opérationnel sur les deux, sans trop changer de chose dans mon LAN. Cela va me permettre de me pencher studieuse sur ce TUTO.
Merci pour les confirmations de Openwrt et ses capacités, je me doutais bien que cela fonctionnait correctement mais une confirmation me fait du bien (l'âge surement).
Merci en tout cas pour tes infos super intéressantes.
Cordialement.
Dominique
Salut à toi,
Si tu suis la conf du tuto, ou si tu recupères directement les fichiers de conf, le port 3 de ton routeur sera en PVID 19, soit le vlan "lantv" du coup de manière native.
Et le port 4 sera le port à utiliser pour ton switch, en pvid 1 (le lan data) et Tagué 19.
Tu n'auras plus qu'à configurer sur ton switch le port CPL pour être en pvid 1 et tagué 19. Ensuite tu dédies un port en pvid 19 pour y raccorder ton boitier TV.
Si le switching ça te parle pas trop, en gros chaque port peut avoir un seul PVID (le vlan natif) et une multitude de vlan tagué (à autoriser).
Pour le Nat-loopback c'est parfaitement fonctionnel avec Openwrt, y'a même possibilité de le valider ou non sur la règle de PAT, voir screen en pj =>
A+ et bonne installation.
-
Merci infiniment.
Comme je l'ai dit plus haut je me débrouille à garder un temps le router câble.
Du coup j'ai une peu de temps pour apprendre tout ça 😅 je donne des nouvelles bientôt.
Merci encore pour toutes les informations.
Je vais commencer par mettre à jour mon erx pour être d'équerre avec ton tuto.
Merci professeur, tu vas sauver une association de 3500 sportifs.
Baseball, tir à l'arc, karaté, etc...
A bientôt.
Vous êtes supers chouettes
-
Bonjour Ubune,
J'ai commencé la configuration de mon router, je bute déjà.
Je cherche un descriptif pour comprendre de quoi je parle et je ne trouve pas.
Les appellations et0.1 eth0.2, etc, j'avoue que je ne sais pas donc je dois apprendre.
J'ai réussi à upgrader mon router ERX Ubiquiti en prenant la main dessus, mais pour charger les paquets je suis perdu dans les interfaces.
A priori mon lien terminal va sur eth4, mais où est le Wan, mon interface configurée par défaut est comme cela sous luci.
Si tu peux m'indiquer un how to pour comprendre le fonctionnement et les appellations, je suppose que eth0 c'est la première interface du router, et que eth0.1 c'est du linux tout craché, c'est la notion de vlan, je n'ai pas été jusque là, je mettais en place des infrastructures ethernet et fibre, wifi dans une grande entreprise, avant la retraite, donc je dois apprendre pour comprendre.
j'ai trouvé ce doc pour comprendre un peu, mais c'est quoi la correspondance physique sur mon router ?.
https://journaldunadminlinux.fr/creer-une-interface-virtuelle-sous-debian-et-centos/
J'ai essayé de connecter le premier port sur une patte de la livebox, ça monte pas, alors qu'à partir du deuxième port et1, eth2, eth3, eth4 ça monte, mais du coup je passe au travers et 192.168.1.1 me mène direct à l'interface de la livebox.
J'ai fixé l'adresse de ma machine en 192.168.1.110/24 et la gateway en 192.168.1.1, connectée directement en ethernet sur eth4.
Au début on est un boulet, et ensuite on apprend donc on peut transmettre à son tour ...
Je vais aller faire mon tour à pied pour faire travailler mes articulations, je verrai à continuer après avoir compris et appris.
Merci par avance de ton aide précieuse.
Dominique
-
eth0.1 c'est du linux tout craché, c'est la notion de vlan, je n'ai pas été jusque là
Si tu veux un tant sois peu comprendre comment ça marche, il va falloir pourtant se mettre aux VLANs: Orange livre la connexion internet dans le VLAN 832 sur le port WAN, et le flux TV dans le VLAN 840 sur le même port ;)
Donc déjà, l'interface WAN pour Internet sera forcèment nommée ethX.832
Après, concernant la question "quel port est le port WAN", j'aurais tendance à répondre "celui que tu veux", puisque sur l'ER-X tous les ports ont des fonctionnalités identiques. C'est la config qui fera que tel ou tel port devient le port WAN.
-
Merci de ta réponse, je n'ai pas dit bien au contraire que je ne voulais pas m'y mettre mais comprendre d'ou ma demande de documentation pour comprendre.
Dans l'exemple de Ubune, les port sont noté eth0,1 ...
Je souhaite comprendre cette appellation pour comprendre le tuto.
Comme dans tout apprentissage, l'important c'est le vocabulaire, hors là je ne le connais absolument pas, et je désire le comprendre car il en va de nos services pour nos associations.
J'ai mis une image écran de la configuration de mon erx après upgrade, je souhaite savoir où je branche le wan physiquement, par rapport à ma conf, si je dois modifier quelque chose, et comment voir seulement le erx pour ne pas passer au travers vu le br lan (bridge je suppose).
Merci par avance.
-
Merci de ta réponse, je n'ai pas dit bien au contraire que je ne voulais pas m'y mettre mais comprendre d'ou ma demande de documentation pour comprendre.
Dans l'exemple de Ubune, les port sont noté eth0,1 ...
Je souhaite comprendre cette appellation pour comprendre le tuto.
Comme dans tout apprentissage, l'important c'est le vocabulaire, hors là je ne le connais absolument pas, et je désire le comprendre car il en va de nos services pour nos associations.
J'ai mis une image écran de la configuration de mon erx après upgrade, je souhaite savoir où je branche le wan physiquement, par rapport à ma conf, si je dois modifier quelque chose, et comment voir seulement le erx pour ne pas passer au travers vu le br lan (bridge je suppose).
Merci par avance.
Salut, va dans la partie network/switch, fait nous un screen de ce que tu vois, et je t'aide à comprendre.
En gros eth0 représente tes 5 ports physiques, dans la partie switching on configure par port un vlan par défaut (untagged) et des vlan aware (tagged).
Dans la partie network/interface, tu crées les interfaces IP (L3) elle seront associées au bon vlan par rapport au nommage (exemple eth0.832).
Comme dit Zoc, orange nous oblige à utiliser les vlan 832 et 840 sur notre interface wan, donc tu vas retrouver facilement quel est le port wan.
Le vlan 1 = le vlan pour tes pc/equipement réseau
Le vlan 19 = le vlan pour ta box TV
A tout de suite,
-
Ok je comprends, dans le tuto, il manquerait ces explications, alors on ne part pas de la configuration après upgrade mais il faut configurer les VLAN pour pouvoir utiliser les ports taggués ou non pour donner un rôle à chaque prise eth, je comprends mieux.
Je fais ça tout de suite, juste le temps de redescendre dans le garage où se trouve ma petite baie...
Mieux je vais aller chercher le router et le ramener au premier pour le configurer / faire les hardcopy.
-
Ok je comprends, dans le tuto, il manquerait ces explications, alors on ne part pas de la configuration après upgrade mais il faut configurer les VLAN pour pouvoir utiliser les ports taggués ou non pour donner un rôle à chaque prise eth, je comprends mieux.
Je fais ça tout de suite, juste le temps de redescendre dans le garage où se trouve ma petite baie...
C'est ça, après pour être franc même sans comprendre si tu récupères l'archive et que tu remplaces les fichiers dans ton erx t'as juste 2 champs à personnaliser et tout fonctionne.
-
En effet, tu peux être franc, je suis pas très au point donc, oui, tu peux.
J'ai d'autres qualités, mais sur ce point je suis une bille.
En effet, si je remplace les fichiers de mon erx par l'archive je dois repartir.
Je vais relire ton tuto.
J'ai vu que parmi les particularités, il y avait les données de connexion propre à la livebox que doit faire le router erx fti/qjhbckjnc qu'il faut convertir.
En effet.
-
En effet, tu peux être franc, je suis pas très au point donc, oui, tu peux.
J'ai d'autres qualités, mais sur ce point je suis une bille.
En effet, si je remplace les fichiers de mon erx par l'archive je dois repartir.
Je vais relire ton tuto.
J'ai vu que parmi les particularités, il y avait les données de connexion propre à la livebox que doit faire le router erx fti/qjhbckjnc qu'il faut convertir.
En effet.
J'ai mis les info pour une installation direct dans le fichier info.txt présent dans l'archive (attention prend bien eth0 only).
Si tu as déja installé les paquets sur le routeur :
opkg update && opkg install nano tcpdump igmpproxy ip-full iptables-mod-ipopt luci-ssl
/etc/init.d/uhttpd start
/etc/init.d/igmpproxy start
/etc/init.d/igmpproxy enable
Tu edites le fichier /etc/config/network
tu remplaces deux fois 6674692f71707138383838 par ton fti converti en héxa (sur l'interface wan et sur l'interface wan6).
Tu places tes fichiers dans le routeurs,
tu reboot et c'est ok, port 4 pour ton switch/cpl
-
Bin non j'ai pas installé les paquets puisque je butte déjà sur le premier point, comment avoir le WAN et internet dans la configuration sans mettre les VLAN sur mes ports.
Là je passe au travers, c'est pas aussi trivial qu'il n'y parait.
Après je pense me débrouiller mais je ne comprends pas comment avoir le réseau sans ça, si je peux me permettre, il doit manquer un truc au début du TUTO, car si tu pars du router (flashé) puis que tu fais ton sysupgrade , le router n'a toujours pas de VLAN donc, pas de WAN où tu veux, donc je peux pas faire l'installation des paquets.
-
Bin non j'ai pas installé les paquets puisque je butte déjà sur le premier point, comment avoir le WAN et internet dans la configuration sans mettre les VLAN sur mes ports.
Là je passe au travers, c'est pas aussi trivial qu'il n'y parait.
Après je pense me débrouiller mais je ne comprends pas comment avoir le réseau sans ça, si je peux me permettre, il doit manquer un truc au début du TUTO, car si tu pars du router (flashé) puis que tu fais ton sysupgrade , le router n'a toujours pas de VLAN donc, pas de WAN où tu veux, donc je peux pas faire l'installation des paquets.
Ton routeur possède déja 2 vlan de manière implicite, c'est écrit au début du tuto, tu mets le routeur derriere ta box :
"Présentation rapide de l'architecture Openwrt :
Une fois installé le routeur possède par défaut les interfaces suivantes :
wan (eth1.2)
br-lan (bridge de l'eth0.1 et de vos interfaces wifi).
(attention, certains routeurs n'ont qu'un seul eth, c'est le cas du edgerouterX par exemple, dans ce cas on reste sur eth0 pour le wan ET le lan (eth0.1 => vlan 1 => lan, eth0.2 vlan 2 => wan)."
De mémoire le premier port est celui qui est en untagged 2, donc le wan.
-
Oui, Oui je l'ai bien vu, mais je ne comprends pas, du moins je l'ai pas essayé.
Cela signifie que le WAN est sur le eth1 (deuxième port) ? et que le BR-LAN est sur le 0 ?
donc je connecte le WAN sur la livebox et je connecte mon PC sur le port eth0 (premier port) ?.
Je sais ça parait bête mais un dessin est parfois meilleur que toutes les explications.
Non à priori je n'ai vraiment rien compris, sur le ERX le WAN et le LAN serait sur le eth0, donc le premier, mais alors comment on se connecte sur la console en terminal dans ce cas, il me manque une info.
-
Oui, Oui je l'ai bien vu, mais je ne comprends pas, du moins je l'ai pas essayé.
Cela signifie que le WAN est sur le eth1 (deuxième port) ? et que le BR-LAN est sur le 0 ?
donc je connecte le WAN sur la livebox et je connecte mon PC sur le port eth0 (premier port) ?.
Je sais ça parait bête mais un dessin est parfois meilleur que toutes les explications.
Je vais essayer.
WAN = eth0.2, donc le port qui est en vlan 2 untagged
LAN = eth0.1 = le reste car les autres ports sont en vlan 1 untagged.
Envoi le screen de ce que tu vois après sysupgrade dans network/switch sur l'interface web
-
Je dois jongler avec le WIFI et ma connexion local en ethernet pour te le donner, j'y vais.
-
Le voici, j'ai l'impression que ça va pas du tout.
-
Le voici, j'ai l'impression que ça va pas du tout.
Non c'est ça,
Le port 0 = wan
ensuite port 1 à 4 est affiché correctement (lan 1 à 4).
On voit que tu as raccordé uniquement le port 1
-
Bon ok,
donc, je mets la livebox sur le port 0 et je me connecte ou je veux pour mon pc en terminal, mais si je mets 192.168.1.1 je vais directement sur la livebox, je ne peux pas me mettre en ssh sur ERX, qu'est-ce que je fais pas bien ?
Je vais aller le reconnecter dans le garage.
-
Bon ok,
donc, je mets la livebox sur le port 0 et je me connecte ou je veux pour mon pc en terminal, mais si je mets 192.168.1.1 je vais directement sur la livebox, je ne peux pas me mettre en ssh sur ERX, qu'est-ce que je fais pas bien ?
Je vais aller le reconnecter dans le garage.
Le problème que tu remontes est logique, et en effet je devrais peut-être le signaler.
Quand tu mets ta box sur le port 0, le routeur fait une requete dhcp et obtient une ip en 192.168.1.x (attribué par ta livebox)
Sauf que ton interface br-lan a déja une ip dans ce réseau (192.168.1.1)
Le mieux est donc de changer l'adresse de ton interface lan (exemple 192.168.2.1/24).
Si tu édites le fichier vi /etc/config/network :
config interface 'lan'
option proto 'static'
option netmask '255.255.255.0'
option ipaddr '192.168.2.1'
option ifname 'eth0.1'
Ou depuis Luci si tu préferes l'interface web.
-
J'ai réussi à me connecter, mais il manque encore un truc car le WAN est monté mais je ne vois pas bien internet car j'ai un problème avec le téléchargement.
la mise à jour des paquets est failed car je ne dois pas passer correctement le réseau.
Je vais changer mes paramètres de connexion de mon PC comme tu me l'indiques.
-
ça fonctionne tout de suite mieux comme ça.
Je vais pouvoir continuer et le plus fort c'est que je vais pouvoir le faire depuis mon bureau sans avoir besoin d'être dans le garage.
La cerise sur le gâteau c'est que je suis handicapé physique (d'où la retraite anticipée), oui je sais en plus d'être handicapé mental (j'ai encore de l'humour avec la maladie).
donc, je serai mieux au chaud dans mon bureau.
Merci à Zoc et Ubune je vais pouvoir continuer je commence à comprendre mieux.
Add on :
Voilà j'ai réussi à mettre les packages, je vais pouvoir continuer en séquence
Correction :
Et bien non, je passe pas au travers de la livebox, forcement, j'ai pas de routage.
J'ai tiré un câble dans le salon, je vais travailler sur la table au chaud quand même.
-
Une fois que tu as installé tous les packages :
/etc/init.d/uhttpd start
/etc/init.d/igmpproxy start
/etc/init.d/igmpproxy enable
Tu récupères l'archive,
Tu edites le fichier /etc/config/network
tu remplaces deux fois 6674692f71707138383838 par ton fti converti en héxa (sur l'interface wan et sur l'interface wan6).
Tu places tes fichiers dans le routeurs,
tu reboot et :
Tu vires ta livebox, tu branches ton ont sur le port wan de l'ubiquiti
tes équipements sur les ports 1 et 2
ta premiere box tv (si tu as) sur le port 3
Ton switch sur le port 4.
Tu seras de nouveau dans le réseau 192.168.1.0/24 avec tes pc.
-
Je vais faire ça mais si je vire la livebox, je n'ai plus de téléphone, je verrai ça plus tard, j'ai vu quelque part que c'était possible.
Je m'y remet demain, et ce week end. je vais continuer à appliquer ton TUTO et je verrai bien ou je vais aller.
Ubune ton TUTO est le plus sérieux de tous, donc je vais aller jusqu'au bout, et je verrai comment réintroduire les fonctions de la livebox quand je maitriserai le sujet (c'est pas pour demain donc).
-
J'espère n'avoir froissé personne avec mes écrits.
Je cherche en effet un TUTO super explicite pour me permettre d'interfacer un autre router devant la box Orange, en gardant certains services.
Notamment le téléphone et la TV (encore que).
Ton TUTO Ubune est de loin, le plus détaillé et pro, il faudra que j'adapte certaines fonctionnalités pour aller à mon objectif.
Comme je garde mon abonnement SFR (10 €) je peux peut-être renvoyer mon téléphone Livebox vers SFR, mais je pourrais avoir des surprises.
Merci en tous cas.
Dominique
-
Bonjour à tous,
J'y suis presque.
J'ai bien fait comme indiqué, mais je n'obtiens pas d'adresse au niveau du WAN.
J'ai copié tous les fichiers dans /etc/config après avoir converti mon fti/xxxxxx par le mien à l'aide de l'adresse indiqué et enlevé les blancs.
J'ai remplacé la chaine de caractères de l'exemple par le mien en hexa, rebooté et supprimé ma livebox.
Cela ne fonctionne pas.
Voici les harcopy de interface et de switch dans luci.
Tout semble en ordre sauf que l'interface wan et wan6 n'ont pas d'adresse du réseau.
Je vois pas dans les données de connexion pppoe de trace de mdp c'est normal ?.
quand on convertit fti/xxxxx il y a pas un endroit où on met le mdp (converti également en hexa) ?.
Pour obtenir une adresse ip v4 ou ip v6, je vois que ces données de connexion sinon (comme d'hab) je sèche.
Il y a également dans l'archive les autres fichiers qui sont dans /etc, pas besoin de les reporter dans le router ?.
J'ai pas branché la TV sur le VLAN TV (port 3) pour l'instant, et je verrai plus tard pour la partie téléphone.
Sur le port 2 j'ai un onduleur / redresseur de panneau photovoltaïques qui est en 10Bt basique, uniquement pour transmettre les données PV vers un serveur de consommation/production.
Merci de votre aide
-
Si tu dois absolument tout copier de l'archive, en respectant l'arborescence, comme indiqué !
dans /etc/ tu as les fichiers rc.local, vlanprio.sh firewall.user
Si ils ne sont pas présent ça ne fonctionnera pas.
Plus que 3 fichiers à ajouter, et tout va fonctionner :).
Pour le mdp on fonctionne en DHCP, pas en pppoe donc c'est normal.
A+
-
Magnifique, merci ubune,
J'ai modifié le fichier rc.local selon le tuto.
Je vais transférer les deux autres fichiers selon le tutoriel.
OK pour le ppoe, c'est logique.
Je regarde ton information sur l'interfaçage de la livebox pour le téléphone plus tard.
Merci de ton aide je commence à voir un peu plus clair dans le paramétrage des vlan, il me manque un peu de vocabulaire pour maîtriser le truc.
A bientôt.
-
Voilà c'est super, le router Ubiquiti a remplacé la livebox.
ça fonctionne, mais comme j'avais mis la box tv Orange en Wifi elle ne retrouve plus ses petits sur le VLAN TVOrange.
Je vais la réinitialiser pour l'avoir au travers du port 3 sur le bon VLAN.
Je chercherai ensuite comment réintroduire la livebox pour le téléphone.
Merci encore.
Il me reste à approfondir le vocabulaire et la manipulation des VLAN mais ça comme à rentrer.
Mes NAS SYnology fonctionnent après avoir mis à jour les DNS chez mon fournisseur Ionos.
Le firewall est paramètré pour laisser entrer les flux du WAN vers le LAN et j'ai paramétré les ports forwarding pour translater les flux vers les bonnes machines.
Mon serveur de Mail fonctionne.
Mes NAS fonctionnent.
Mes serveurs WEB fonctionent.
Mon adresse IP est maintenant "fixe", le bail n'est pas réactualisé.
Il me reste à documenter un peu le travail à partir des différentes sources.
Merci énormèment pour votre travail, le backup des sauvegardes de nos associations fonctionne parfaitement.
Durablement Votre.
Dominique
-
Mon serveur de Mail fonctionne.
Même dans le sens sortant ? Orange bloque le port SMTP en sortie de telle sorte qu’il est impossible d’envoyer des mails sans passer par les serveur SMTP d’Orange.
-
Je passe par un autre SMTP que celui de Orange, et à priori ça passe bien.
Mon serveur MX est bien configuré sur mon provider, je n'ai pas de soucis, je vais approfondir ton information.
J'ai fait des tests dans tous les sens, Orange ne me bloque pas sur le service SMTP à priori.
De Gmail vers mon serveur (SMTP Gmail) ça passe.
De Gmail vers SFR (SMTP Gmail) ça passe.
De mon serveur vers mon serveur (SMTP mon serveur) ça passe, mais il y a des chances que malgré le loopback ça soit interne.
De mon serveur vers GMAIL (SMTP mon serveur) ça passe.
De mon serveur vers SFR (SMP mon serveur) ça passe.
J'ai collé toute la journalisation sur mon serveur SMTP depuis mon réseau Syno et ça passe aussi, pour l'ensemble du parc.
J'ai un peu de perte de message sur un seul compte mais je pense que j'ai un défaut de paramètrage sur les accusés.
J'utilise pas les ports classiques, car mes services est sur une debian 9 (en VM) et j'utilise Vesta CP pour la gestion global de mes services.
Donc les ports IMAP/POP et SMTP ne sont pas basiques mais en STARTTLS et authentifiés.
-
Je passe par un autre SMTP que celui de Orange, et à priori ça passe bien.
Pas sur le port TCP 25 alors.
-
Surtout pas, tout est en STARTTLS avec translation de ports, je suis un parano vu le nombre d'attaques sur les ports classiques.
-
Hey, parfait si tout fonctionne,
Pour le firewall tu peux laisser le forward wan=>lan en "drop", de toute façon le fait de créer une règle de forwarding (dnat) ça suffit à ouvrir spécifiquement le flux en question.
Et ne pas oublier IPV6 :), genre si t'as un /64 sur le site B, tu peux te faire une règle firewall "le /64 du site B peux accéder à n'importe quelle machine du site A (le /64 de chez toi). Et hop en 1 règle tu peux accéder à toutes tes machines sur tous les ports que tu veux (fin maintenant faut gérer le firewall sur les machines) depuis le site distant.
Au boulot on fournit des liens ipv6 ready, et quand tu dois aussi gérer la partie système.., c'est tellement simple d'avoir de base la règle "/64 du boulot peut accéder au /64 du client"...
A+
-
Merci Ubune, tu es un ange :o
Pour l'IPV6, je finirai mon apprentissage du VLAN avant de me noyer dans cette techno.
Tu sais j'ai commencé les télécom dans le X25 en 1844 !!
J'ai fait quelques cours TCP/IP mais j'étais un technicien expérimenté en câblage, donc faut aller doucement avec papy !!.
Je vais me pencher sur le cas de la TV quand j'aurai reçu mes switchs manageables, pour l'instant ça ne fonctionne plus.
Puis ensuite je regarderai le cas de la livebox comme c'est écrit dans ton TUTO, faut que je la remette sinon ma femme va me foutre dehors, tu te rends compte plus de TV, plus de téléphone, c'est un cas de divorce, à l'âge que j'ai faut pas pousser le bouchon.
Je viens de rajouter la support de la Qos sur Openwrt :
https://openwrt.org/docs/guide-user/network/traffic-shaping/sqm
Merci encore.
Dom
-
Oui ne t'inquiète pas, pour l'ipv6 même quand j'en parle à des "ingé" réseau, système etc j'ai une chance sur deux de passer pour un martien. C'est dommage mais c'est comme ça.
Attention faut pas me remercier, la box derrière le routeur pour la téléphonie c'est le boulot de Rhon et Kgersen !
-
Voilà le résultats de tes bons soins !
Sur un abonnement Livebox Play 300/300.
Il me reste un peu de boulot pour restaurer la TV, le téléphone mais voici (Tadaaaaaaaaa !!)
-
Petit message pour Ubune,
J'ai tenté de réinitialiser la TV HD de Orange en la rebranchant à la Livebox et replacer tout sur le WAN.
Je n'ai pas pensé que j'allais perdre mon adresse ip "fixe", coup de bol elle est restée correctement à sa place.
Par contre si j'ai bien récupéré la TV HD sur la livebox, impossible de l'avoir sur le routeur ERX4 sur le port 3 avec un câble direct.
La TV HD me dit que je n'ai pas la une Livebox compatible et me demande de rebrancher la livebox qui va avec ...
Qu'est-ce que je fais pas correctement ?. Le VLAN est pourtant le bon sur le port 3.
-
Petit message pour Ubune,
J'ai tenté de réinitialiser la TV HD de Orange en la rebranchant à la Livebox et replacer tout sur le WAN.
Je n'ai pas pensé que j'allais perdre mon adresse ip "fixe", coup de bol elle est restée correctement à sa place.
Par contre si j'ai bien récupéré la TV HD sur la livebox, impossible de l'avoir sur le routeur ERX4 sur le port 3 avec un câble direct.
La TV HD me dit que je n'ai pas la une Livebox compatible et me demande de rebrancher la livebox qui va avec ...
Qu'est-ce que je fais pas correctement ?. Le VLAN est pourtant le bon sur le port 3.
C'est le nouveau décodeur UHD (le petit carré) que tu as ?
Si oui il faut ajouter l'option 125, édite ton fichier /etc/config/dhcp y'a un exemple.
-
Bonjour Ubune,
Oui c'est bien celui là.
D'ailleurs, la configuration de ce réseau semble assez incompatible avec l'IPV6, j'ai testé les applications TV Orange sur mobile Android, tablettes ...
Tu essayes ça te met une erreur P531 si tu enlèves IPV6 de l'interface WAN (WAN6 disable) ça fonctionne.
Je vais chercher ce que tu me dit sur l'option 125 pour /etc/config/dhcp
Merci, c'est une belle chiotte cet opérateur, vivement que les autres opérateurs soient disponibles dans notre quartier, mais vu que maintenant j'ai un engagement de 12 mois avec frais de résiliation, je suis piégé.
Merci de tes bons soins.
-
Bonjour Ubune,
Oui c'est bien celui là.
D'ailleurs, la configuration de ce réseau semble assez incompatible avec l'IPV6, j'ai testé les applications TV Orange sur mobile Android, tablettes ...
Tu essayes ça te met une erreur P531 si tu enlèves IPV6 de l'interface WAN (WAN6 disable) ça fonctionne.
Je vais chercher ce que tu me dit sur l'option 125 pour /etc/config/dhcp
Merci, c'est une belle chiotte cet opérateur, vivement que les autres opérateurs soient disponibles dans notre quartier, mais vu que maintenant j'ai un engagement de 12 mois avec frais de résiliation, je suis piégé.
Merci de tes bons soins.
Surement une histoire de DNS? dans la config toute faite j'envoie les DNS cloudflare dans les RA du routeur, ce que tu décris me dit que c'est p-e pas une bonne idée. (si t'actives IPV6 tu résous pas sur ceux d'orange du coup).
Peux-tu supprimer les deux dernière ligne ici dans le fichier /etc/config/dhcp :
config dhcp 'lan'
option interface 'lan'
option start '100'
option leasetime '4h'
option ra 'server'
list dhcp_option '6,192.168.1.1'
option limit '30'
list dns '2606:4700:4700::1111'
list dns '2606:4700:4700::1001'
Et retester si derrière ça refonctionne sur la tablette même avec l'ipv6 d'activé (attention de bien relancer complétement le wifi).
Pour certaines personnes peut-être informés y'a des info sur du dnsV6 d'orange ?
Sinon pour l'option 125, c'est indiqué dans le fichier, faut convertir en hexa le numéro de serie de ta livebox routeur, et tu remplaces les "XXX" avec .
-
Ha ok en plus de le faire dans le fichier network faut aussi le faire dans dhcp ...
-
Ha ok en plus de le faire dans le fichier network faut aussi le faire dans dhcp ...
C'est pas la même chose, le fichier network tu configures tes interfaces, le fichier dhcp tu configures les options dhcp que tu envoies pour tes équipements.
-
Oui je me doute que c'est pas la même chose, mais cette identité des équipements en hexa est deux fois, ils ont bien verrouillé l'histoire.
Je mets en commentaire l'adresse IPV6 dans dhcp ...
Puis je me penche sur l'ID hexa de mon équipement.
-
Oui je me doute que c'est pas la même chose, mais cette identité des équipements en hexa est deux fois, ils ont bien verrouillé l'histoire.
Non, attention, ce n'est pas l'adresse mac, ni le fti/xxxxxx, c'est le numéro de série (avec des lettres et des chiffres). Un troisième truc, donc, qui n'est utilisé que par le décodeur TV.
En l'occurrence, l'option 125 doit contenir une partie de la mac + le numéro de série + la version de la box (3 ou 4).
-
Non, attention, ce n'est pas l'adresse mac, ni le fti/xxxxxx, c'est le numéro de série (avec des lettres et des chiffres). Un troisième truc, donc, qui n'est utilisé que par le décodeur TV.
En l'occurrence, l'option 125 doit contenir une partie de la mac + le numéro de série + la version de la box (3 ou 4).
La partie mac et version c'est réellement contrôlé par ce qu'on a chez soit ?
Dans mon cas j'ai pris un exemple et j'avais personnalisé juste le n° de série, et je me suis rendu compte plus tard que ma mac était différente (oui la partie constructeur) que celle de cette exemple, mais ça marche quand même.
-
Oui j'ai vu que je disais une connerie en l'écrivant.
En relisant ton message, j'ai vu les trois premier caractère de l'adresse mac en hexa.
Je peux les convertir avec le site conversion hexa https://www.rapidtables.com/convert/number/ascii-to-hex.html
ou ça marche sur l'interface Openwrt avec echo ?
echo -n 'xx:xx:xx' | xxd -p
Du coup faut-il mettre les : séparateurs hexa ?
Peux tu me donner un exemple
Mes trois premiers caractères sont : "A4:3E:51" c'est déjà de l'hexa ... puisque c'est une adresse mac
-
Je viens de relire, numéro de série en hexa ...
Putain je suis un boulet ...
Donc :
list dhcp_option '125,00:00:0d:e9:24:04:06:41:43:38:34:43:39:05:0f:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:06:09:4c:69:76:65:62:6f:78:20:34'
Nouveauté pour le nouveau décodeur TV5, l'option 125 est obligatoire, en Orange c'est les 3 premiers octet de la mac adress en hexadécimal et il faut remplacer les XX:XX par votre numéro de série de livebox routeur, après l'avoir converti en Hexa.
(Pour l'option 125 Je n'ai rien inventé, merci aux personnes du topic DD-WRT, j'ai juste adapté la conf).
La prise de tête
-
En plus des questions ci dessus comment je sais la version de la box, cette version c'est la livebox play ...
Je reprends les hostilités un peu plus tard, je vais m'occuper un peu de la maison, j'ai rien foutu mise à part de l'informatique.
Si tu m'as répondu je teste ça ce soir, ma femme va faire du théâtre le lundi.
Donc en résumé, ne dis-je pas de conneries avec mes conversions
1 - Mac adresse complète ou pas (contrairement au 3 premier caractères en hexa (je vois si octets traduits dans ton exemple)
2 - le numéro de série traduits te semble-t-il bon ?
3 - la version de la livebox play serait ? 3 ou 4 ou x.
-
En plus des questions ci dessus comment je sais la version de la box, cette version c'est la livebox play ...
Je reprends les hostilités un peu plus tard, je vais m'occuper un peu de la maison, j'ai rien foutu mise à part de l'informatique.
Si tu m'as répondu je teste ça ce soir, ma femme va faire du théâtre le lundi.
Donc en résumé, ne dis-je pas de conneries avec mes conversions
1 - Mac adresse complète ou pas (contrairement au 3 premier caractères en hexa (je vois si octets traduits dans ton exemple)
2 - le numéro de série traduits te semble-t-il bon ?
3 - la version de la livebox play serait ? 3 ou 4 ou x.
J'attends plus d'info parce que cette partie là j'avoue que j'ai jamais cherché à comprendre.
Mais pour moi, tu prends l'exemple tu remplaces les XXX par ton numéro de série convertit en hexa, et ça marche (c'est ce que j'ai fait et ça tourne depuis des mois).
-
Pour le numéro de série c'est ok, je teste ça mais pour le reste j'avoue que je ne pige pas (ça change).
Derrière la livebox j'ai une mac en hexa sur 6 caractères, ça colle pile poil avec ton exemple, 05:0F derrière ça ressemble à du LF line feed / CR carriage return ...
Et pour la version de la livebox play ??
Je vais chercher un exemple d'option 125
-
La partie mac et version c'est réellement contrôlé par ce qu'on a chez soit ?
Je ne pense pas, non (pour l’instant...).
-
Pour le numéro de série c'est ok, je teste ça mais pour le reste j'avoue que je ne pige pas (ça change).
Derrière la livebox j'ai une mac en hexa sur 6 caractères, ça colle pile poil avec ton exemple, 05:0F derrière ça ressemble à du LF line feed / CR carriage return ...
Et pour la version de la livebox play ??
Te prend pas le tête, prend l'exemple et change les XX tout simplement, test et tiens nous au jus, j'éclaircirai le tuto sur cette partie, pour que ce soit propre avec nos vrais valeurs, mais ça marche si tu suis l'exemple.
Y'a un post quelque part avec une explication détaillée de la chaine ?
-
Bien camarade ...
Je vais essayer, et si je trouve pour cette livebox play je vous informe.
-
Voici un site avec les explications détaillées de l'état de l'art chez Orange.
https://sebastien.warin.fr/2017/02/11/4284-fonctionnement-fibre-orange-remplacement-livebox-routeur-mikrotik-routeros/
Je comprends que ce sont bien les 6 caractères qu'il faut mettre, dans ton adaptation il y a bien les 6.
Je continue sur le serial, le décodage sur Ubiquiti c'est bien le serial traduit avec les : séparateurs.
Je cherche pour la version de livebox.
Passionnant ce site.
-
Je cherche pour la version de livebox.
PLAY = « 3 ».
-
La boîte carré tv avec l'adresse mac + le serial en hexa ça fonctionne nickel. J'ai plus qu'à mettre mes switchs avec vlan et le port 4 transformé en trunck pour passer vlan data + tv pour virer mon câble direct et ça roule. Je suis pas persuadé que la version soit contrôlée comme dit zoc car j'ai rien mis. J'ai bien mis les 6 caractères hexa de la mac.
-
Alternatives :
(TV)
Si vous vouliez avoir la TV sur le LAN :
Changement Firewall :
config rule
option src wanTV
option proto igmp
option target ACCEPT
config rule
option src wanTV
option proto udp
option dest lan
option dest_ip 224.0.0.0/4
option target ACCEPT
option family ipv4
config forwarding
option dest 'lan'
option src 'wanTV'
Changement igmpproxy :
config igmpproxy
option quickleave 1
config phyint
option network tvorange
option direction upstream
list altnet "0.0.0.0/0"
config phyint lan
option network lan
option direction downstream
Changement network :
config interface 'lan'
option igmp_snooping 1
Changement Dns :
Il faut envoyer les dns d'orange sur le lan (ou que votre routeur relaye vers Orange).
Attention, si vous utilisez cette configuration et que votre décodeur est raccordé sur un switch derrière le routeur, il faudra gérer l'igmp snooping dessus (si vous ne voulez pas que le flux TV soit broadcasté).
(Telephone)
Livebox derrière le routeur (pour avoir le téléphone fonctionnel)
Voir les échanges et surtout le post récap de Rhon ici : https://lafibre.info/remplacer-livebox/remplacement-de-la-livebox-par-un-routeur-openwrt-18-dhcp-v4v6-tv/msg589599/#msg589599
Je dois faire tout ça pour passer la TV dans le réseau sans avoir besoin de switch administrable ?.
rien d'autre et ça va marcher (sur le port 4).
je passe déjà le flux data pour le répéteur AIRPORT extrème wifi, ma nvidia shield, et la tv smartv (tout est de la data) en dhcp.
du coup le port 3 qui était dans le vlan tv sert plus à rien, que dois je modifier pour détagguer ??.
après je m'attaque au problème du téléphone.
-
Oui mais si c'est pas la config par défaut y'a une raison :p
Je te laisserai découvrir l'état de ton wifi quand t'auras la TV allumée sur le lan (avec tes switch non administrable).
Et faudra ajouter l'option 125 envoyé en dhcp sur l'interface lan du coup (fichier /etc/config/dhcp).
-
Petit résumé de l'avancement de mon projet :
La livebox play a été enlevée
Le router Ubiquiti (flashé avec Openwrt) est actif dans le garage sur l'ONT Orange (Fibre 300/300)
Le DHCP règle la fourniture d'adresse aux matériels sur adresse MAC dans le routeur Ubiquiti ERX4
Wan/Wan6 sur port 0
!
!-->> Obtention du réseau Orange IPV4 et IPV6
Mise en conformité de l'identification Orange (fti/xxxx)
Lan sur port 1 (garage)
!
!-->> Onduleur / Transformateur Panneaux Photovoltaïques
Lan sur port 2 (garage)
!
!-->> DHCP 192.168.1.0/24 Switch non manageable
!
!-->> Nas DS918+ et Nas DS214
LanTV sur port 3
!
!-->> fourniture en DHCP du serial et Mac adresse à TV UHD (la TV fonctionne en direct sur câble volant)
Lan sur port 4
!
!-->> Un switch non manageable derrière une jonction CPL avec Salon
!
!-->> Réseau DHCP 192.168.1.0/24 continuité du LAN général
! !
! !-->> PC Windows Spare pour expérimentation en LAN
!
!-->> Répéteur WIFI Airport Extrême (2,4 Ghz et 5 Ghz)
!
!-->> Réseau DHCP 192.168.1.0/24 continuité du LAN général
!
!-->> 2 MacBook Pro et Air (2,4 Ghz et 5 Ghz)
!-->> 2 Smartphone Nokia 6 (2,4 Ghz et 5 Ghz)
!-->> Nvidia Shield (2,4 Ghz et 5 Ghz)
!-->> LgTvWebOS (2,4 Ghz et 5 Ghz)
Reste à faire :
- Intégrer la TV dans le Lan pour supprimer le port 3 (idéal intégrer le flux dans le port 4)
- Réintégrer la livebox derrière le routeur ERX4 pour obtenir le téléphone.
- Mettre fin au réseau SFR sur câble qui est utilisé aujourd'hui en backup
-
J'ai répondu mon résumé avant de lire ta réponse ...
Merci en tout cas.
Sur le switch non manageable le WIFI se plante quand la TV fonctionne cela ne va donc pas.
Je n'ai pas essayé la configuration de ce point car je sens que ça va pas le faire, je pense qu'il faudrait un trunck (pour passer tous les VLAN) et de l'autre côté les re-séparer par port mais je redoute un problème de débit.
J'envisage de séparer le Vlan TV sur un autre lien depuis le port 3 pour ne plus toucher à la configuration de base.
Il faudrait que je trouve un point d'accès WIFI WPS pour synchroniser la TV UHD avec le router Ubiquiti ou passer en CPL j'ai testé ça fonctionne mais tout seul.
Mais j'ai un souci avec le CPL je vais pas en mettre deux dans la maison.
Ou alors je mets la Tv UHD sur le CPL et je passe tous les PC / MAC en WIFI faut que je vois cette option (cela ne fait plus qu'une jonction CPL avec Salon)
L'idéal serait de câbler la maison mais voilà je peux pas.
-
Bonsoir Ubune,
Je souhaiterai quelques explications pour ne pas me tromper sur le tuto de rhon par rapport au tien.
Dans le sien je trouve :
config interface 'tel'
option ifname 'eth0.832'
option proto 'static'
option netmask '255.255.255.0'
option defaultroute '0'
option ipaddr '192.168.100.1'
puis
config switch_vlan
option device 'rtl8366s'
option vlan '832'
option ports '3t 5t'
option vid '832'
Je suppose que le vlan téléphone est bien le 832 qu'il faut tagué sur un port dispo, à priori dans ta config il est sur les ports
config switch_vlan
option device 'switch0'
option vlan '2'
option ports '3t 6t'
option vid '832'
3 et 6 en mode débug ?
Si je veux l'affecter sur le port 2, je mets juste
option ports '2'
Pour dhcp je pense avoir compris que les données doivent passer sur le vlan 832
config dhcp 'tel'
option leasetime '12h'
option domain 'orange.fr'
option interface 'tel'
option start '1'
option limit '2'
list dhcp_option_force '90,00:00:00:00:00:00:00:00:00:00:00:64:68:63:70:6c:69:76:65:62:6f:78:66:72:32:35:30'
list dhcp_option_force '120,00:06:73:62:63:74:33:67:03:4e:49:43:06:61:63:63:65:73:73:11:6f:72:61:6e:67:65:2d:6d:75:6c:74:69:6d:65:64:69:61:03:6e:65:74:00'
list dhcp_option_force '125,00:00:05:58:0c:01:0a:00:01:00:00:00:ff:ff:ff:ff:ff'
list dhcp_option '6,80.10.246.3,81.253.149.10'
Idem pour le firewall
config zone
option name 'tel'
option network 'tel'
option output 'ACCEPT'
option log '1'
option family 'ipv4'
option input 'ACCEPT'
option forward 'REJECT'
config forwarding
option dest 'wan'
option src 'tel'
config rule
option src 'tel'
option dest_port '53'
option proto 'tcpudp'
option target 'ACCEPT'
option name 'DNS for Livebox'
config rule
option src 'tel'
option dest_port '67-68'
option proto 'udp'
option target 'ACCEPT'
option name 'DHCP for Livebox'
config rule
option name 'Allow-DHCP-Renew for Livebox'
option proto 'udp'
option dest_port '68'
option target 'ACCEPT'
option family 'ipv4'
option src 'tel'
Si j'ai tout compris en mettant cette configuration la livebox sur le port 2 reçoit du wan (port 0) le vlan 832 pour le téléphone et le route sur le port 3 pour transformer la livebox en une vulgaire base dect.
Merci pour ta confirmation, et merci à rhon pour son travail.
Avec ces confirmations par rapport à ta configuration, je vais pouvoir me passer de la box SFR.
Sur le port 0 il y a le wan
Sur le port 1 le Lan pour mes NAS en DHCP avec fourniture d'IP par mac adresse (garage).
Sur le port 2 il y aura le téléphone vers la livebox
Sur le port 3 il y a la TV (via un cpl dans le Salon)
Sur le port 4 le LAN je mets la borne Airport en répéteur WIFI puisque c'est du LAN en DHCP
(passe par un câble ethernet vers le salon mais en hauteur et pas suffisamment long pour atteindre les autres machines).
Toutes les autres machines DHCP de la maison reçoivent leur IP via fourniture par MAC adresse au travers du WIFI.
-
J'ai essayé, ça ne fonctionne pas.
Le WAN ne se relance pas, je n'obtiens pas d'IP ni en IPV4 ni en IPV6.
Je ne dois pas envoyer les bonnes infos pour m'authentifier, pourtant je n'ai pas supprimé ni le fti/xxx, ni le serial, ni la mac.
C'est donc que ce que je rajoute sur le dhcp au travers du port 2 ne lui convient pas.
Je vais me re-pencher la dessus.
-
Bonjour,
Tout d'abord, merci pour ce tuto, j'ai bien les parties IPV4/IPV6/TV qui fonctionnent parfaitement sur mon linksys wrt1900ac
J'en suis à l'étape Téléphone, et là, ça coince, ma livebox ne récupère jamais d'ip derrière mon linksys.
Voici mes fichiers de conf
/etc/config/network
config interface 'tel'
option ifname 'eth0.832'
option proto 'static'
option netmask '255.255.255.0'
option defaultroute '0'
option ipaddr '192.168.132.1'
config switch
option name 'switch0'
option reset '1'
option enable_vlan '1'
config switch_vlan
option device 'switch0'
option vlan '2'
option vid '832'
option ports '2t 4t 5t 6t'
/etc/config/dhcp
config dhcp 'tel'
option leasetime '12h'
option domain 'orange.fr'
option interface 'tel'
option start '1'
option limit '2'
list dhcp_option_force '90,00:00:00:00:00:00:00:00:00:00:00:64:68:63:70:6c:69:76:65:62:6f:78:66:72:32:35:30'
list dhcp_option_force '120,00:06:73:62:63:74:33:67:03:4e:49:43:06:61:63:63:65:73:73:11:6f:72:61:6e:67:65:2d:6d:75:6c:74:69:6d:65:64:69:61:03:6e:65:74:00'
list dhcp_option_force '125,00:00:05:58:0c:01:0a:00:01:00:00:00:ff:ff:ff:ff:ff'
list dhcp_option '6,80.10.246.3,81.253.149.10'
/etc/config/firewall
config zone
option name 'tel'
option network 'tel'
option output 'ACCEPT'
option log '1'
option family 'ipv4'
option input 'ACCEPT'
option forward 'REJECT'
config forwarding
option dest 'wan'
option src 'tel'
config rule
option src 'tel'
option dest_port '53'
option proto 'tcpudp'
option target 'ACCEPT'
option name 'DNS for Livebox'
config rule
option src 'tel'
option dest_port '67-68'
option proto 'udp'
option target 'ACCEPT'
option name 'DHCP for Livebox'
config rule
option name 'Allow-DHCP-Renew for Livebox'
option proto 'udp'
option dest_port '68'
option target 'ACCEPT'
option family 'ipv4'
option src 'tel'
Je vois passer régulièrement des request DHCP en faisant un tcpdump.
Si je mets un PC sur à la place de la livebox, en taggant son port ethernet en 832, je récupère immédiatement une IP dans mon pool local.
Auriez-vous une idée?
Merci d'avance
-
@Greener77176
Puisque l'ubiquiti n'a qu'un seul ETH, Tu ne peux avoir la livebox directement derrière, tu es obligé d'utiliser un switch gérant les vlan pour créer ton 2em vlan 832 jusqu'a la livebox.
Exemple :
Sur openwrt tu crées un vlan livebox id 199
Tu crées l'interface tel en eth0.199
Tu configures un port en pvid (vlan untagged) 199
Tu branches ce port sur ton switch qui gère les vlans.
Sur ce switch, tu configures ce port en pvid 832
Tu connectes la livebox sur le switch, sur un port avec le vlan 832 tagged autorisé.
Sans XP sur les vlans c'est pas simple à comprendre.
@f59
Tu as toujours le problème ?
-
@Ubune en tout cas merci de la tentative.
Je vais approfondir les VLANs et ton conseil sur un switch administrable.
Merci beaucoup.
-
@f59
Tu as toujours le problème ?
Bonjour ubune
Oui, toujours, le même souci, mais je m'en suis sorti avec ta proposition de le gérer via un vlan différent sur un switch.
Je ne comprends par contre pas pourquoi, sur mon wrt1900ac, qui a 2 interfaces, j'ai ce souci...
Dans tous les cas, merci pour la réponse et le tuto!
-
Ok, j'ai fait d'une pierre 2 coups avec le post alors... x)
Top si ça marche comme ça, si quelqu'un à les même soucis pour mettre la livebox derrière j'ajouterai l'info sur le tuto.
Après j'ai l'impression que la téléphonie fixe intéresse de moins en moins de monde.
Merci pour le retour en tout cas.
A une prochaine ;)
-
Merci pour ce tuto précis et complet 8)
Le remplacement de la Livebox par mon routeur TP-Link Archer C7 s'est déroulé sans le moindre accroc. ;D
Il me reste maintenant à configurer le routeur de sorte à pouvoir utiliser la Livebox derrière le routeur (et retrouver ainsi le téléphone).
J'ai suivi les étapes précisées par rhon (https://lafibre.info/remplacer-livebox/remplacement-de-la-livebox-par-un-routeur-openwrt-18-dhcp-v4v6-tv/msg589599/#msg589599), mais je me heurte à une difficulté.
Il est précisé qu'il faut configurer, sur le switch, un VLAN 832 tagué (dans mon cas entre ETH0 et le port LAN4, sur lequel est connecté la Livebox).
config switch_vlan
option device 'switch0'
option vlan '9'
option ports '5t 6t'
option vid '832'
Or, le VLAN 832 est déjà déclaré dans la première partie du tuto, pour le remplacement de la Livebox (VLAN Tagué, sur ETH1 + Port WAN)
config switch_vlan
option device 'switch0'
option vlan '6'
option ports '0t 1t'
option vid '832'
Si j'applique ce nouveau WLAN, je perds Internet (mais j'arrive à voir les requêtes DHCP qu'envoie la Livebox)
root@OpenWrt:~# tcpdump -i eth0.832 -vv
tcpdump: listening on eth0.832, link-type EN10MB (Ethernet), capture size 262144 bytes
13:11:37.534175 IP6 (class 0xc0, hlim 1, next-header UDP (17) payload length: 198) fe80::a63e:51ff:xxx:xxx.xxx> ff02::1:2.547: [udp sum ok] dhcp6 solicit (xid=ecaac6 (client-ID hwaddr type 1 a43e51704ec6) (option-request authentication vendor-specific-info DNS-server DNS-search-list) (elapsed-time 26685) (authentication proto: 0, alg: 0, RDM: mono, RD: 0000 0000 0000 0000 ??) (user-class) (vendor-class) (IA_PD IAID:1366314694 T1:3600 T2:5400))
...
Si je ne l'applique pas, bah forcèment le routeur ne voit pas les requêtes DHCP qu'envoie la Livebox sur le VLAN 832.
J'ai raté quelque chose ? ???
Merci !
-
Sur le TP-Link Archer C7, les 2 ports ETH1 et ETH0 arrivent tous les 2 sur le swith :
(https://openwrt.org/_media/media/tplink/tl-wdr7500/archerc7v2-switch-diagram.png)
C'est probablement pour cette raison que je n'arrive pas à faire fonctionner simultanèment :
- Le VLAN 832 Tagué ETH1 ~ WAN (relié au SFP Orange)
config switch_vlan
option device 'switch0'
option vlan '6'
option ports '0t 1t'
option vid '832'
- Avec un autre VLAN 832 Tagué ETH0 ~ LAN4 (relié à la Livebox)
config switch_vlan
option device 'switch0'
option vlan '9'
option ports '5t 6t'
option vid '832'
-> J'ai l'impression que c'est fichu pour brancher la Livebox au routeur, de la façon décrite par rhon (https://lafibre.info/remplacer-livebox/remplacement-de-la-livebox-par-un-routeur-openwrt-18-dhcp-v4v6-tv/msg589599/#msg589599) :-[
Je vais tenter de trouver une solution de contournement, me permettant de connecter la Livebox.
Je dispose au besoin d'un switch administrable TP-Link TL-SG1016DE, qui prend en charge les VLAN.
Toute suggestion sera la bienvenue :)
-
Salut !
tu as la solution sur mon post de la page précédente x)
Utiliser un autre vlan et un Switch (exemple avec le vlan 99)
-
@Greener77176
Puisque l'ubiquiti n'a qu'un seul ETH, Tu ne peux avoir la livebox directement derrière, tu es obligé d'utiliser un switch gérant les vlan pour créer ton 2em vlan 832 jusqu'a la livebox.
Exemple :
Sur openwrt tu crées un vlan livebox id 199
Tu crées l'interface tel en eth0.199
Tu configures un port en pvid (vlan untagged) 199
Tu branches ce port sur ton switch qui gère les vlans.
Sur ce switch, tu configures ce port en pvid 832
Tu connectes la livebox sur le switch, sur un port avec le vlan 832 tagged autorisé.
Sans XP sur les vlans c'est pas simple à comprendre.
@f59
Tu as toujours le problème ?
-
Nickel 8)
Merci pour l'aiguillage vers le bon post !
C'est effectivement ce que j'étais parti pour faire : sortir en non tagué, et retagué avec mon switch externe.
A suivre :)
-
Nickel 8)
Merci pour l'aiguillage vers le bon post !
C'est effectivement ce que j'étais parti pour faire : sortir en non tagué, et retagué avec mon switch externe.
A suivre :)
Top tiens nous au jus :)
-
C'est une affaire qui marche 8)
J'ai donc déclaré un VLAN != 832 pour le téléphone : 3
L'interface tel est en eth0.3 :
config interface 'TEL'
option proto 'static'
option ipaddr '10.10.12.1'
option netmask '255.255.255.0'
option defaultroute '0'
option ifname 'eth0.3'
Le VLAN est envoyé non tagué, à destination du switch TP-Link.
Cf. image 1.
config switch_vlan
option device 'switch0'
option vlan '9'
option vid '3'
option ports '2 6t'
Côté Switch TP-Link, j'applique l'ID 832 au trafic non tagué reçu du routeur (Port 1).
Cf. image 2.
Et j'envoie le VLAN 832 tagué à destination du port WAN de la Livebox (Port 15).
Cf. image 3.
Encore merci :D
-
Je viens d'en profiter pour compléter l'installation.
En plus du VLAN832 tagué (que j'envoie sur le port WAN de la Livebox), j'envoie désormais mon VLAN1 non tagué (= mon réseau domestique), sur un port LAN.
Ainsi, en plus de base téléphone DECT, la Livebox me fait désormais office de point d'accès WiFi pour l'étage (après désactivation du serveur DHCP de la Livebox).
En donnant les mêmes SSID aux réseaux WiFi du routeur et de la Livebox, les terminaux mobiles se connectent automatiquement au signal de plus fort des 2 8)
Le plus propre aurait été :
- soit de tirer 2 câbles vers la Livebox
- soit d'installer un 2ème switch avec prise en charge VLAN en amont de la Livebox, qui sépare les 2 VLAN.
Comme je n'en ai pas, ça sera un vulgaire switch non manageable, qui retransmets VLAN1 (non tagué) + VLAN832 (tagué) simultanèment sur les port LAN et WAN de la Livebox (lynchez moi ;D).
Note : j'ai essayé d'abord sans switch additionnel, en connectant un câble Ethernet entre le port WAN et l'un des port LAN de la Livebox. Ça ne fonctionne pas (la Livebox n'arrive plus à s'enregistrer sur le réseau Orange).
-
Bonjour,
je suis bloqué sur un autre site avec une build en ath79 de la branche 18.06 mais avec le kernel 4.14 (https://forum.openwrt.org/t/ath79-builds-with-all-kmod-packages-through-opkg-flow-offloading/15897/169)
Le mec est passé sur snapshot, parce que avec l'archer c7 c'est obligatoire d'être en ath79 pour des raisons de vitesse passthrouth entre WAN et LAN
Il avait fait un config.seed et d'autres fichiers pour avoir luci, et les packages du 18.06 avec le kernel du snapshot.
Est ce que quelqu'un ici aurait encore son dépot ?
Merci :)
-
Bonjour,
je me présente Jérémy 34 ans et j'habite en région Vendée. :)
Je bénéficie actuellement d'une connexion ADSL 12Mb/s chez Orange avec une livebox3.
Je voulais savoir si ce tuto s'applique seulement au client fibre ? ou bien l'ADSL ?
ps : désolé si ma question est bête ^_^
Cordialement,
-
Bonjour,
J’ai utilisé le même tuto en ADSL également. Le fonctionnement général est le même. La chose qui change, c’est la gestion des VLAN qui passe par les VPI/VCI de l’ADSL. Par contre, je n’ai fait que la partie Internet, la télé et le téléphone ne m’intéressant pas.
-
Très bien entendu c'est gentil pour votre réponse.
Car voilà je vous présente mon petit problème j'ai un routeur NETGEAR qui traîne chez moi WNR1000V2 j'ai essayé d'installé Openwrt mais je n'arrive pas à avoir ma connexion ADSL pourriez vous m'aider dans cette démarche svp ?
Merci.
-
Pour la partie internet, voici ce que j'ai tapé comme commandes (en remplaçant les xxxxxx comme le tutoiement l'indique) :
uci delete network.globals.ula_prefix
uci set network.wan.proto='dhcp'
uci set network.wan.broadcast='1'
uci set network.wan.vendorid='sagem'
uci set network.wan.reqopts='0x01 0x15 0x28 0x51 0x58 0x59 0x90'
uci set network.wan.sendopts='0x4D:2b46535644534c5f6c697665626f782e496e7465726e65742e736f66746174686f6d652e4c697665626f7833 0x5a:00000000000000000000001a0900000558010341010dxxxxxxxxxxxxxxxxxxxxxxx'
uci set network.wan6.proto='dhcpv6'
uci set network.wan6.reqaddress='none'
uci set network.wan6.reqprefix='auto'
uci set network.wan6.defaultreqopts='0'
uci set network.wan6.sendopts='11:00000000000000000000001a0900000558010341010dxxxxxxxxxxxxxxxxxxxxxxx 15:FSVDSL_livebox.Internet.softathome.livebox3 16:0000040e0005736167656d'
uci set network.wan6.reqopts='11 17 23 24'
uci commit network
Le modem ADSL quand à lui est branché sur le port WAN, et configuré comme suit :
1483 Bridged IP LLC
VPI : 8
VCI : 32
-
Merci MacJL pour toute ces informations ;)
De mon côté je suis en train de me renseigner sur le firmware d'Openwrt pour mon routeur car j'ai un souci je ne peux pas tag mon port Wan sur le Vlan 832 car il apparaît pas dans l'interface de Luci et donc je vois pas quel numéro il comporte dans le fichier de configuration network..
-
Pas besoin de la gestion des VLAN en ADSL. Toit se passe du côté de la configuration du modem.
-
D'accord mais pour la TV il faudra bien que je fasse du vlan non ?
-
En effet, pour la TV, je ne sais pas, car je ne l'utilise pas. Je trouve les solutions non lié à l'opérateur (Apple TV + Molotov par exemple) bien meilleures, et cela simplifie grandement les changements d'opérateurs internet. Mais je m'éloigne du sujet!
-
Bonsoir,
Bon j'ai mis mon modem en bridge et j'ai bien ma Syncronisation en ADSL2+ mais côté routeur sa fonctionne pas malgré que je suive bien le tuto.
Par contre je ne peux pas tag mon wan car il n’apparaît pas dans l'onglet switch.
Voici un screen (https://image.noelshack.com/minis/2019/19/5/1557515731-switch-no-port-wan.png) (https://www.noelshack.com/2019-19-5-1557515731-switch-no-port-wan.png)
-
je n'arrive pas à m'authentifier avec mon identifiant fti/XXXXX sur un hub5 en OpenWrt 18.06.2 r7676-cddd7b4c77
le routeur est RAZ puis je connecte mon pc en ethernet à un port jaune, la ligne adsl au port gris et la conf par défaut est une authentification en PPOE, ce qui me convient (pas de DHCP ici)
je rentre mon identifiant fti puis mon MDP, le modem se connecte (diode bleue sur le modem allumée) mais pas d’identification....
juste après la RAZ
(https://reho.st/self/163dc5b62c33d2bc6c723abcf6ea5cd46f84192c.png) (https://reho.st/view/self/163dc5b62c33d2bc6c723abcf6ea5cd46f84192c.png)
(https://reho.st/self/7bdff04d32c01bfa8ff46bef9cdae21ecb958211.png) (https://reho.st/view/self/7bdff04d32c01bfa8ff46bef9cdae21ecb958211.png)
(https://reho.st/self/7ffd7992f54b5a1399884d5b5cef8712ab0cea5e.png) (https://reho.st/view/self/7ffd7992f54b5a1399884d5b5cef8712ab0cea5e.png)
puis une fois l'ID et MDP mis
(https://reho.st/self/c8b13349cbb791476a219a84bdde5ec0e1d68c50.png) (https://reho.st/view/self/c8b13349cbb791476a219a84bdde5ec0e1d68c50.png)
(https://reho.st/self/8804e9f05e5610c82060c2586c8cdc8346761b15.png) (https://reho.st/view/self/8804e9f05e5610c82060c2586c8cdc8346761b15.png)
(https://reho.st/self/091da372a57282e12c53b375876a7d64c2202d78.png) (https://reho.st/view/self/091da372a57282e12c53b375876a7d64c2202d78.png)
voici le fichier network, après avoir mis mon FTi et MDP
config interface 'loopback'
option ifname 'lo'
option proto 'static'
option ipaddr '127.0.0.1'
option netmask '255.0.0.0'
config globals 'globals'
option ula_prefix 'fde0:7634:4c1e::/48'
config atm-bridge 'atm'
option vpi '1'
option vci '32'
option encaps 'llc'
option payload 'bridged'
option nameprefix 'dsl'
config dsl 'dsl'
option annex 'a'
option tone 'av'
config interface 'lan'
option type 'bridge'
option ifname 'eth0.1'
option proto 'static'
option ipaddr '192.168.1.1'
option netmask '255.255.255.0'
option ip6assign '60'
config device 'lan_dev'
option name 'eth0.1'
option macaddr '24:20:c7:79:b3:8c'
config interface 'wan'
option ifname 'dsl0'
option proto 'pppoe'
option ipv6 '1'
option username 'fti/XXXXXXXXXXXXXXXXXX'
option password 'XXXXXXXXXXXXXXXXXXXXXXXXXXX'
config device 'wan_dev'
option name 'dsl0'
option macaddr '24:20:c7:79:b3:8d'
config interface 'wan6'
option ifname '@wan'
option proto 'dhcpv6'
config switch
option name 'switch0'
option reset '1'
option enable_vlan '1'
config switch_vlan
option device 'switch0'
option vlan '1'
option ports '0 1 2 4 6t'
config switch_vlan
option device 'switch0'
option vlan '2'
option ports '5 6t'
J'ai aussi essayé PPPoA+VC-MUX et mm résultat , je veux juste l'adsl pour le moment.
J'ai aussi essayé de mettre le fichier config180602_eth0_version1.1 mais il n'y a même pas de connexion adsl...
..
est-ce que je peux installer manuellement les paquets ? si oui comment ?
-
Bonjour,
Il faut paramétrer le VPI/VC en 8/35
Par ailleurs, votre ligne a un problème vu les ES/SES
-
oui ça marche maintenant. l'icone de WAN reste rouge mais ça marche.
-
La ligne a toujours été mauvaise, mais là je suis 1mbit/s plus lent que sur mon vieux modem. il y a qch à changer sur la config pour améliorer les choses ?
Ça vaut le coup de ré-activer le DLM d'orange ?
Autre question, est-ce que DSLstats peut récupérer les infos avec openwrt ou bien il y a un paquet équivalent à DSLstats pour avoir directement un graphique sur plusieurs jours de la qualité de la ligne ?
-
Hey !
Juste pour info,
J'ai virtualisé openwrt sur mon Esxi, et ça marche du tonnerre :). Mon Linksys ne sert que d'AP du coup
- Pour le 10gb il faut juste ajouter kmod-vmxnet3 pour la gestion kernel du vmxnet3 de l'esx.
- Avec un switch distribué on peut gérer la cos.
Du coup je suis déjà au 10gb pour le flux intra VM, j'obtiens du 7-8 gbps sur du flux routé entre 2 vlans attachés à mon openwrt
VM-A@vlan100 <===> vmopenwrt <====> VM-B@vlan200
J'ai commandé un X520 DA2 à 170e sur Rakuten
Je réfléchis à passer chez Free pour en profiter coté WAN ^^
-
Salut,
merci Ubune pour ton super tuto et pour ton travail (difficile de faire plus exhaustif)
j'aurai une demande de précision en tant que bon néophyte...
Pour le fichier firewall.user dans le tuto il est indiqué :
#la même chose en ipv6 (avec cette fois le dhcpv6)
ip6tables -t mangle -A POSTROUTING -j CLASSIFY --set-class 0000:0001
ip6tables -t mangle -A POSTROUTING -p ipv6-icmp -j CLASSIFY --set-class 0000:0006
ip6tables -t mangle -A POSTROUTING -p udp --dport 547 -j CLASSIFY --set-class 0000:0006
et dans le fichier config en download
#la même chose en ipv6 (avec cette fois le dhcpv6)
ip6tables -t mangle -A POSTROUTING -j CLASSIFY --set-class 0000:0001
ip6tables -t mangle -A POSTROUTING -p ipv6-icmp -j CLASSIFY --set-class 0000:0006
ip6tables -t mangle -A POSTROUTING -o eth1.832 -p udp --dport 547 -j CLASSIFY --set-class 0000:0006
ip6tables -t mangle -A POSTROUTING -p udp --dport 547 -j DSCP --set-dscp-class CS6
lequel serai le plus indiqué ?
-
(Telephone)
Livebox derrière le routeur (pour avoir le téléphone fonctionnel)
Voir les échanges et surtout le post récap de Rhon ici : https://lafibre.info/remplacer-livebox/remplacement-de-la-livebox-par-un-routeur-openwrt-18-dhcp-v4v6-tv/msg589599/#msg589599
Depuis 2 jours, je n'avais plus le téléphone.
Il semble dorénavant nécessaire d'ajouter les options DHCP ci-dessous :
list dhcp_option '15,orange.fr'
list dhcp_option '119,REN.access.orange-multimedia.net' (à adapter selon l'emplacement géographique du serveur SIP)
Sans quoi la Livebox essaye de résoudre l'adresse "sbct3g.lan" en tant que serveur SIP, et non l'adresse "sbct3g.REN.access.orange-multimedia.net".
-
Salut,
merci Ubune pour ton super tuto et pour ton travail (difficile de faire plus exhaustif)
j'aurai une demande de précision en tant que bon néophyte...
Pour le fichier firewall.user dans le tuto il est indiqué :
#la même chose en ipv6 (avec cette fois le dhcpv6)
ip6tables -t mangle -A POSTROUTING -j CLASSIFY --set-class 0000:0001
ip6tables -t mangle -A POSTROUTING -p ipv6-icmp -j CLASSIFY --set-class 0000:0006
ip6tables -t mangle -A POSTROUTING -p udp --dport 547 -j CLASSIFY --set-class 0000:0006
et dans le fichier config en download
#la même chose en ipv6 (avec cette fois le dhcpv6)
ip6tables -t mangle -A POSTROUTING -j CLASSIFY --set-class 0000:0001
ip6tables -t mangle -A POSTROUTING -p ipv6-icmp -j CLASSIFY --set-class 0000:0006
ip6tables -t mangle -A POSTROUTING -o eth1.832 -p udp --dport 547 -j CLASSIFY --set-class 0000:0006
ip6tables -t mangle -A POSTROUTING -p udp --dport 547 -j DSCP --set-dscp-class CS6
lequel serai le plus indiqué ?
Bonjour et de rien, content d'avoir pu aider.
Les deux fonctionnent, mais si tu fais une trace de ta sortie wan, le deuxième sera plus "propre" tu retrouveras réellement la valeur CS6 dans le champs "traffic class" de l'entête ipv6 sur ton dhcp solicit, comme le fait la livebox.
En faite tant qu'a faire vu qu'en ipv6 iptables est capable de gerer ça (prio + marquage dhcpv6), autant utiliser les deux :).
Depuis 2 jours, je n'avais plus le téléphone.
Il semble dorénavant nécessaire d'ajouter les options DHCP ci-dessous :
list dhcp_option '15,orange.fr'
list dhcp_option '119,REN.access.orange-multimedia.net' (à adapter selon l'emplacement géographique du serveur SIP)
Sans quoi la Livebox essaye de résoudre l'adresse "sbct3g.lan" en tant que serveur SIP, et non l'adresse "sbct3g.REN.access.orange-multimedia.net".
Merci pour l'info, est-ce simple de retrouver le serveur SIP en rapport avec sa région ?
A+
-
Merci pour l'info, est-ce simple de retrouver le serveur SIP en rapport avec sa région ?
Tu peux capturer avec tcpdump, sur ton routeur, la réponse retournée par le serveur DHCP de chez Orange.
-
Tu peux capturer avec tcpdump, sur ton routeur, la réponse retournée par le serveur DHCP de chez Orange.
Ok mais je pensais qu'on avait p-e une sorte de bdd avec l'info, pour éviter de faire ça justement.
-
Bonjour et de rien, content d'avoir pu aider.
Les deux fonctionnent, mais si tu fais une trace de ta sortie wan, le deuxième sera plus "propre" tu retrouveras réellement la valeur CS6 dans le champs "traffic class" de l'entête ipv6 sur ton dhcp solicit, comme le fait la livebox.
En faite tant qu'a faire vu qu'en ipv6 iptables est capable de gerer ça (prio + marquage dhcpv6), autant utiliser les deux :).
Merci pour ton retour, je passe en "solution 2" :)
-
Bonjour, et un grand bravo pour tout ceux qui on contribué à ce tuto. En suivant le tuto, cela a fonctionné du premier coup.
J’avais une box de red by sfr en bridge avec un APU2C4 sous openwrt pour le routage. Puis je suis passé sur de la fibre avec un forfait sosh 300/300 le 4 juillet. Que dire sur la livebox 4: pas de mode bridge, pas de nat loopback, 10 min pour démarrer….
Donc un GRAND MERCI à vous tous qui m’ont permis de garder mon APU2C4 auquel j’ai ajouté le TPLINK MC220L pour le module fibre. Ainsi je peut continuer avec openwrt que j’utilise depuis des années maintenant ( openwrt a squatté avant sur tplink WDR3600, ArcherC7, et le netgear WNDR3800). Je précise que dans mon cas je n’ai pas eu besoin de faire un sleep/ifdown/ifup dans mon rc.local.
Je voulais vous remonter mon idées concernant les commandes du ‘/etc/rc.local’. Alors quand on démarre tout se passe bien mais j’ai poussé un peu plus loin avec un ‘/etc/init.d/network restart’ où un simple restart dans luci sur l’interface wan. On est obligé de relancer un ‘sh /etc/vlanprio.sh’. J’ai donc voulu voir si il était possible d’automatiser cela.
Donc un tour sur la doc de openwrt et me voila rassuré par ‘ hotplug’. En ssh j’envoie la commande ‘ls -l /etc/hotplug.d/iface/’ donc je trouve les 2 fichiers qui m’intéresse
00-netstate
20-firewall
Je retrouve bien des commande exécuté lorsque les interfaces sont redémarré où débranché puis rebranché
Alors je rajoute un fichier qui sera lu juste après celui du firewall :
cat << 'EOF' > /etc/hotplug.d/iface/21-vlanprio
sh /etc/vlanprio.sh
EOF
Test avec ‘/etc/init.d/network restart’ et pareil avec restart dans luci sur l’interface wan. J’ai même débranché puis rebranché la fibre à chaud. Résultat j’ai bien le script /etc/vlanprio.sh qui se lance tout seul à présent.
Je retire la commande ‘sh /etc/vlanprio.sh’ de mon ‘/etc/rc.local’ un reboot et le script ce lance aussi.
Alors pour que le système de sauvegarde d’openwrt prenne en compte ce fichier et tant qu’à faire le script vlanprio.sh. on ajoute les 2 ligne dans /etc/sysupgrade.conf :
/etc/hotplug.d/iface/21-vlanprio
/etc/vlanprio.sh
Comme cela lors d’un backup ou alors une mise à jour, vous retrouverai ces fichiers.
J’ai pas testé avec les lignes sleep/ifdown/ifup
-
Salut,
je vient d'essayer ta méthode et je récupère juste une ipv6 pas d'ipv4 (Openwrt 18.0.4 - wrt32x)
même en rajoutant les lignes sleep/ifdown/ifup
-
Salut,
je vient d'essayer ta méthode et je récupère juste une ipv6 pas d'ipv4 (Openwrt 18.0.4 - wrt32x)
même en rajoutant les lignes sleep/ifdown/ifup
Salut,
Avec la Méthode du tuto est que tu récupère ton ipv4 au reboot ?
Que donne les commandes manuel ?
Méthode 1 , celle qui reprend le rc.local du tuto :
/etc/init.d/network restart
/etc/init.d/firewall restart
sleep 10 # où bien patiente les 10 secondes
ifdown wan
sh /etc/vlanprio.sh
ifup wan
Méthode 2, sans les lignes sleep/ifdown/ifup :
/etc/init.d/network restart
/etc/init.d/firewall restart
sh /etc/vlanprio.sh
-
Avec la méthode du tuto tout est ok
pour la methode 1
je recupere une ip en 8x.xx.xx.xx fonctionelle
pour la methode 2 aussi
en ne mettant que sh vlanprio.sh puis reboot dans rc.local j'ai une ip en 176.xx.xx.xx
en mettant juste sleep 10 et sh vlanprio.sh et en faisant un reboot (sans lidown et ifup) je recupere une ip fonctionelle en 8x.xx.xx.xx
(le ifup et el ifdown servent si j'ai bien compris le commentaire associé au tuto a être tout a fait sûr de récupéré une bonne ip)
-
Avec la méthode du tuto tout est ok
pour la methode 1
je recupere une ip en 8x.xx.xx.xx fonctionelle
pour la methode 2 aussi
en ne mettant que sh vlanprio.sh puis reboot dans rc.local j'ai une ip en 176.xx.xx.xx
en mettant juste sleep 10 et sh vlanprio.sh et en faisant un reboot (sans lidown et ifup) je recupere une ip fonctionelle en 8x.xx.xx.xx
Et donc si je comprend bien quand tu ajoute le fichier :
/etc/hotplug.d/iface/21-vlanprio
Avec les lignes :
sleep 10
ifdown wan
sh /etc/vlanprio.sh
ifup wan
où alors, (vu que tu as testé) juste avec les lignes :
sleep 10
sh /etc/vlanprio.sh
Là tu ne récupère pas ton ipv4 en 8x.xx.xx.xx en fesant un :
/etc/init.d/network restart
En faite tout ce qui ce trouve dans '/etc/hotplug.d/iface/' est ce qui va être lancé après un restart des interfaces ou alors un branchement à chaud.
en fesant un :
ls -l /etc/hotplug.d/iface/
tu as bien les 2 fichiers ?
00-netstate
20-firewall
C'est la raison pour laquelle je l'ai nommé 21-vlanprio pour qu'il se lance après 20-firewall
Après installe ces 2 packages :
opkg update
opkg install kmod-button-hotplug kmod-gpio-button-hotplug
Mais là je suis pas sùr qu'ils sont liés, c'est juste que je les ai installés pour d'autres raisons et que peut être qu'ils contribuent au faite que cela fonctionne sur mon APU2C4
-
rc.local est "vide"
en faisant un reboot ou /etc/init.d/network restart :
en mettant sleep 10 + sh /etc/vlanprio.sh dans /etc/hotplug.d/iface/21-vlanprio je récupère une ip fonctionelle en 8.xx.xx (ip public il me semble)
en mettant en plus ifup et ifdown j'ai de nouveau une ip publique mais la connexion se relance d'elle mème toute les 10s environ
en ne mettant que sh /etc/vlanrio.sh dans /etc/hotplug.d/iface/21-vlanprio je récupere une ip en 172.xx.xx..xx
le sleep 10 semble faire la différence
sans rajoutez kmod-button-hotplug kmod-gpio-button-hotplug
-
rc.local est "vide"
en faisant un reboot ou /etc/init.d/network restart :
en mettant sleep 10 + sh /etc/vlanprio.sh dans /etc/hotplug.d/iface/21-vlanprio je récupère une ip fonctionelle en 8.xx.xx (ip public il me semble)
en mettant en plus ifup et ifdown j'ai de nouveau une ip publique mais la connexion se relance d'elle mème toute les 10s environ
en ne mettant que sh /etc/vlanrio.sh dans /etc/hotplug.d/iface/21-vlanprio je récupere une ip en 172.xx.xx..xx
le sleep 10 semble faire la différence
Quand on y pense cela semble logique pour le "ifup et ifdown", hotplug doit le considéré comme une reconnexion à chaud et bonjour la boucle. Heureusement que tu me le remonte. Donc un "/etc/hotplug.d/iface/21-vlanprio" avec les lignes :
sleep 10
sh /etc/vlanprio.sh
Cela fonctionnent chez toi, peut tu me confirmer si c'était suite a l'installation du kmod-button-hotplug (pour le kmod-gpio-button-hotplug j'ai un autre appareil qui ne la pas et cela fonctionnent sans)
Merci pour ton retour
-
sleep 10
sh /etc/vlanprio.sh
fonctionne
je n'ai pas installé les packages kmod-button-hotplug kmod-gpio-button-hotplug
j'ai aussi testé en débranchant le rj45
je débranche : l'interface garde l'ip mais bien sûr pas de connection
j'ai donc fais un /etc/init.d/network pour remettre la connection à "0" , attendu 4-5 minutes et rebranché le cable : je récupère une ip stable publique fonctionelle
merci à toi pour cette méthode
-
sleep 10
sh /etc/vlanprio.sh
fonctionne
je n'ai pas installé les packages kmod-button-hotplug kmod-gpio-button-hotplug
j'ai aussi testé en débranchant le rj45
je débranche : l'interface garde l'ip mais bien sûr pas de connection
j'ai donc fais un /etc/init.d/network pour remettre la connection à "0" , attendu 4-5 minutes et rebranché le cable : je récupère une ip stable publique fonctionelle
merci à toi pour cette méthode
Merci pour ta confirmation alors on a pas besoin des kmod. Donc maintenant que cela fonctionne tu ne devrait même plus avoir besoin d'un /etc/init.d/network lorsque tu rebranche le câble. Le but de hotplug, c'est que ce soit automatisé.
J’espère avoir contribué pour ce tuto
-
Salut,
juste un retour d'expérience sur le tuto de Ubune et l'apport de Yousstech.
J'ai flashé un Edgerouter X avec Openwrt. (je suis plus a l'aise avec Openwrt et je cherchai un peit routeur de qualité pas cher.....)
En suivant le tuto de Ubune et an activant le Hardware flow offloading ce petit routeur tient sans problème et aucune peine le 300/300 de Sosh.
D'aprés le forum Openwrt il devrai tenir sans problème le Gbit
L'apport de Yousstech fonctionne sans problème
-
Salut,
juste un retour d'expérience sur le tuto de Ubune et l'apport de Yousstech.
J'ai flashé un Edgerouter X avec Openwrt. (je suis plus a l'aise avec Openwrt et je cherchai un peit routeur de qualité pas cher.....)
En suivant le tuto de Ubune et an activant le Hardware flow offloading ce petit routeur tient sans problème et aucune peine le 300/300 de Sosh.
D'aprés le forum Openwrt il devrai tenir sans problème le Gbit
L'apport de Yousstech fonctionne sans problème
Pour info quand j'avais testé avec mon ERX j'obtenais déjà 930/300 sans offload (ni hard ni soft)
945/300 avec offload, mais j'avais de mauvaises perf en ipv6.
Quels sont tes perfs en ipv6 avec l'offload ?
@Yousstech, Merci pour ta participation, peux-tu résumer la mise en place ?
En effet ça a l'air plus propre, même si j'ai pas l'impression qu'on y gagne grand chose, ça reste un fichier à modifier.
A+
-
Pour info quand j'avais testé avec mon ERX j'obtenais déjà 930/300 sans offload (ni hard ni soft)
945/300 avec offload, mais j'avais de mauvaises perf en ipv6.
Quels sont tes perfs en ipv6 avec l'offload ?
A+
Effectivement en ipv6 le débit est divisé par 10 en down et quasi inexistant en up (fibre sosh 300/300 : 33 en down et 1 en up)
l'offload, dans mes test, me permet d'avoir le même débit en utilisant beaucoup moins de ressources cpu
en ipv 4 300 en don et 300 en up
Tu as une explication pour la différence de déit ipv6/ipv4 (cpu ??) ?
Mon Wrt32x n'a pas ces limitations ( l'Erl est là pour bricoler et apprendre à utilisé le git d'OPenwrt - but :apprendre à faire un firmware avec les packages requis pour la fibre Orange, plus simple lors d'un sysupgrade)
-
Effectivement en ipv6 le débit est divisé par 10 en down et quasi inexistant en up (fibre sosh 300/300 : 33 en down et 1 en up)
l'offload, dans mes test, me permet d'avoir le même débit en utilisant beaucoup moins de ressources cpu
en ipv 4 300 en don et 300 en up
Tu as une explication pour la différence de déit ipv6/ipv4 (cpu ??) ?
Mon Wrt32x n'a pas ces limitations ( l'Erl est là pour bricoler et apprendre à utilisé le git d'OPenwrt - but :apprendre à faire un firmware avec les packages requis pour la fibre Orange, plus simple lors d'un sysupgrade)
Il faudrait comparer les perf ipv6 edge os avec offload vs openwrt, mais à mon avis c'est juste pas géré/optimisé.
Mais de toute façon l'offload sur du sosh a peu d'interêt sur l'erx.
Car sans offload, la forwarding est donc fait coté cpu, sur les 4 cpu, 2 seront utilisés pour cette tache.
Quand je faisais un forward sur le lien orange 1gbps, débit max => 920-930mbps, j'atteignais les 50% d'utilisation cpu (saturation des deux cpu), donc il reste quand même 2 autres cpu dispo, et on perd "que" 20-25mbps, donc pour faire du 300/300 ça doit pas être génant :)
L’intérêt serait vraiment si tu veux atteindre le 945 et que tu fais que de l'ipv4.
Ton wrt32x ne fait pas d'offload mais a un cpu largement taillé pour faire du gbps.
-
Salut à tous, donc pour résumé, Hotplug automatise juste le tout. Au lieu que vlanprio.sh soit appelé seulement au démarrage, il est relancé à chaque fois que l’on touche à la configuration réseau ou alors qu’on débranche un câble. Mais je sais pas si c’est plus propre ce que j’ai fais, car si on jette un coup d’œil à la doc de Hotplug d’OpenWrt , j’ai pas réussi à respecter la syntaxe des scripts. Je me suis donc résigné à y mettre le minimum et ça fonctionne bien comme cela, donc restons sur le principe KISS.
Pour résumer la mise en place :
- On retire les commandes du ‘/etc/rc.local’
- On créé le fichier ‘/etc/hotplug.d/iface/21-vlanprio’
Soit on ajoute la ligne :
sh /etc/vlanprio.sh
où alors on remplace par ces lignes pour ceux qui n’ont pas d’ipv4 publique qui remonte (nonosch a testé merci à lui):
sleep 10
sh /etc/vlanprio.sh
- Optionnel, on peut ajouter les 2 lignes dans /etc/sysupgrade.conf :
/etc/hotplug.d/iface/21-vlanprio
/etc/vlanprio.sh
Comme cela lors d’un backup ou d’une mise à jour, on retrouve ces fichiers.
-
Hello,
Je viens de tester une configuration avec le décodeur UHD5 sur le lan d'un OWRT. Cela fonctionne plutôt pas trop mal (zapping inclus) mais j'ai juste un petit problème que je n'arrive pas à comprendre. En fait cela fonctionne seulement si je mets l'interface br-lan en promisc. Et ça je ne comprend pas pourquoi. Faut-il cloner la MAC de la livebox sur l'interface lan ?
-
j'ai m'inscris pour vous remercier pour ce tuto! J'ai réussi à mettre mon vieux tp-link wdr4300 sur la dernière version d'OpenWRT, reconfigurer en DHCP (il était en Chaos Calmer et pppoe depuis 2014, et j'ai remarque une baisse du débit) et obtenir le débit vraiment remarquable (j'avais 50-70mbit au peigne en pppoe)
https://www.speedtest.net/result/8466212752
j'ai du ajouter les dissipateurs sur les processeurs du routeur car il surchauffait et déconnait avec le nouveau débit. Et depuis quelques jours ça tourne bien.
Le router remplace la livebox bien évidemment. Pas de télé ni de téléphone fixe. Je peux partager le config pour ce router si quelqu'un est intéressé.
-
Hello,
Je viens de tester une configuration avec le décodeur UHD5 sur le lan d'un OWRT. Cela fonctionne plutôt pas trop mal (zapping inclus) mais j'ai juste un petit problème que je n'arrive pas à comprendre. En fait cela fonctionne seulement si je mets l'interface br-lan en promisc. Et ça je ne comprend pas pourquoi. Faut-il cloner la MAC de la livebox sur l'interface lan ?
Je me répond à moi même: à priori le décodeur n'aime pas quand la passerelle par défaut n'est pas le serveur DHCP. J'avais fais ça pour le temps d'un test. Maintenant que je n'ai plus de livebox et plus qu'openwrt comme passerelle et DHCP, je n'ai plus de soucis.
-
Une petite question, est-il possible, selon vous, de faire tourner openwrt sur une vm derrière une livebox 4 qui pointe vers celui-ci en DMZ?
Tout cela pour faire tourner un pi-hole... Orange... tu me les presses....
-
Une petite question, est-il possible, selon vous, de faire tourner openwrt sur une vm derrière une livebox 4 qui pointe vers celui-ci en DMZ?
Tout cela pour faire tourner un pi-hole... Orange... tu me les presses....
Tu peux même remplacer ta box par ta vm openwrt ;)
Commence par DL : openwrt-18.06.4-x86-64-combined-ext4.img
Ensuite tu peux utiliser par exemple starwind v2v converter pour convertir en disk vm (je l'ai fait vers mon esxi)
Et il existe même des tools compatibles à télécharger ici : https://github.com/fangli/openwrt-vm-tools (fonctionne en 18.06.04)
Et hop ça fonctionne au poil ;)
-
Tu peux même remplacer ta box par ta vm openwrt ;)
Commence par DL : openwrt-18.06.4-x86-64-combined-ext4.img
Ensuite tu peux utiliser par exemple starwind v2v converter pour convertir en disk vm (je l'ai fait vers mon esxi)
Et il existe même des tools compatibles à télécharger ici : https://github.com/fangli/openwrt-vm-tools (fonctionne en 18.06.04)
Et hop ça fonctionne au poil ;)
Merci sympa comme, je vais tester avec un rpi, après je veux switcher sur un routeur. Des conseils pour un routeur, qui encaisse de la fibre à 1gb, avec mini deux ports Gigabit avec du AC1200 ET surtout pas trop cher? (WAF oblige)! Merci
-
Bonjour à tous,
Je viens de suivre le TUTO pour remplacer ma livebox4 par un Linksys wrt3200acm (passé en 18.06.4). Tout s'est très bien passé, le tuto est vraiment parfait.
J'ai relevé deux petites incohérences entre le post et les fichiers disponibles en téléchargement :
- la règle Allow-MLD est différente (les 4 lignes 'list icmp_type XXX' ne sont pas le fichier téléchargeable),
- dans le post l'interface IPV6 est nommée wanipv6 alors qu'elle est nommée wan6 dans les fichiers.
Cela semble ne pas affecter le fonctionnement.
En revanche, je bloque sur quelque chose de très très bête pour la partie TV. :-[
Il est indiqué qu'il faut convertir en hexa le numéro de série de livebox routeur.... Je veux bien, mais sur l'étiquette collée sur ma box le numéro de série commence par un 'L' (et puis au milieu il y a un 'K' et un 'P').
Alors soit je n'ai pas compris ce que c'est que la livebox routeur (cela dit, ça doit être le boitier qui n'est pas le boitier TV !), soit je n'ai pas compris (hummm... Je l'ai déjà dit).
Bref vous l'aurez compris : je ne comprends pas ! ;D
Soyez indulgents SVP, un peu d'aide serait la bienvenue.
-
Bonjour.
L'identifiant n'est pas sur une étiquette mais dans les menus reglages->information->votre box
Et c'est bien 13 chiffres.
-
Je suis passé chez sosh il y quelque jours, j'ai reçu la LB4 aujourd’hui.
J'ai suivi les indications de rhon (https://lafibre.info/remplacer-livebox/remplacement-de-la-livebox-par-un-routeur-openwrt-18-dhcp-v4v6-tv/msg589599/#msg589599) en adaptant à ma sauce et le tel fonctionne nickel :D
Tout à marché du premier coup.
J'ai même pas eu besoin de m'emmerder avec mon raspberry ou une VM pfsense (bon ok j'ai testé avec une VM pfsense avant histoire d'être sûr des options à passer, même si je vois que ça fonctionne sans le domain search qui n'est pas renseigné dans la config, car j'avais vu il y a quelques temps que la valeur sip server n’était plus utilisée, pourtant la box la demande toujours...).
-
Hello.
Pour information la configuration fonctionne aussi très bien avec les snapshot d'openWRT 19.07.
Par contre faites bien attention avant toute mise à jour de:
- sauvegarder /etc/rc.local et vlanprio.sh
- de bien avoir sous la main les packages ip-full et ses dépendances: libcap, libelf1, libmnl0 et zlib
-
Hello.
Pour information la configuration fonctionne aussi très bien avec les snapshot d'openWRT 19.07.
Par contre faites bien attention avant toute mise à jour de:
- sauvegarder /etc/rc.local et vlanprio.sh
- de bien avoir sous la main les packages ip-full et ses dépendances: libcap, libelf1, libmnl0 et zlib
Super merci pour le retour :)
Pour préserver les fichiers, on peut aussi les annoncer dans le fichier /etc/sysupgrade.conf
nano /etc/sysupgrade.conf
## This file contains files and directories that should
## be preserved during an upgrade.
/etc/rc.local
/etc/vlanprio.sh
A+
-
Il y a même dans possibilité de configurer ces fichiers dans l'interface directement. Ce que j'ai fais.
Le problème n'est pas dans la conservation de la configuration, mais dans l'obligation de l'installation de ip-full pour que les commandes dans vlanprio.sh fonctionnent.
Je me suis retrouvé bête après le reboot de la maj, sans internet parce que les commandes egress ne fonctionnent pas...
J'ai du récupérer ip-full et ses dépendances via mobile.
Si quelqu'un à un script qui récupère des packages de la version maj avant le reboot, puis qui les installes directe, ça m'intéresse.
-
En effet, sur cette partie j'ai toujours contourné le problème grâce au wifi du routeur (et un partage de co 4g) et hop un wan fonctionnel permettant d'installer les packages.
"via mobile" C'est p-e ce que tu voulais dire ?
Ça serait top d'améliorer ça, mais faut relativiser car c'est tout de même peu fréquent.
-
Salut,
merci pour le tuto !
Alors pour ma part SOSH offre 300/300, je suis sur un TP-LINK ARCHER C6V2 2.0 en snapshot 19.07 (il n'y a pas encore de stable).
J'ai configuré que la partie Internet IPv4 et v6 (pas la box tv et pas de téléphone).
Je rencontre cependant 2 problèmes :
- Perte de débit : 240 environ à la place des 290 habituels.
- Pas d'IPv6.
Je joins mes fichiers de conf si ça peut aider :
network
config interface 'loopback'
option ifname 'lo'
option proto 'static'
option ipaddr '127.0.0.1'
option netmask '255.0.0.0'
config globals 'globals'
option ula_prefix 'fd44:2bd0:130c::/48'
config interface 'lan'
option type 'bridge'
option ifname 'eth0.1'
option proto 'static'
option ipaddr '192.168.0.1'
option netmask '255.255.255.0'
option ip6assign '64'
config interface 'wan'
option ifname 'eth0.832'
option proto 'dhcp'
option broadcast '1'
option vendorid 'sagem'
option reqopts '1 15 28 51 58 59 90'
option sendopts #####MASQUE######
config interface 'wan6'
option ifname 'eth0.832'
option proto 'dhcpv6'
option reqprefix 'auto'
option defaultreqopts '0'
option sendopts #####MASQUE######
option reqopts '11 17 23 24'
option noclientfqdn '1'
option noacceptreconfig '1'
option reqaddress 'force'
config switch
option name 'switch0'
option reset '1'
option enable_vlan '1'
config switch_vlan
option device 'switch0'
option vlan '1'
option ports '2 3 4 5 0t'
config switch_vlan
option device 'switch0'
option vlan '2'
option ports '1t 0t'
option vid '832'
config interface 'lan_invites'
option ifname 'wlan0-1 wlan1-1'
option type 'bridge'
option proto 'static'
option netmask '255.255.255.0'
option ipaddr '192.168.10.1'
option ip6assign '64'
firewall
config defaults
option syn_flood '1'
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'REJECT'
config zone
option name 'lan'
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'ACCEPT'
option network 'lan lan_invites'
config forwarding
option src 'lan'
option dest 'wan'
config zone
option name 'wan'
option output 'ACCEPT'
option masq '1'
option input 'DROP'
option forward 'DROP'
option network 'wan'
option family 'ipv4'
config zone
option name 'wanipv6'
option network 'wan6'
option output 'ACCEPT'
option forward 'DROP'
option family 'ipv6'
option input 'DROP'
config rule
option name 'Allow-DHCP-Renew'
option src 'wan'
option proto 'udp'
option dest_port '68'
option target 'ACCEPT'
option family 'ipv4'
config rule
option name 'Allow-Ping'
option src 'wan'
option proto 'icmp'
option icmp_type 'echo-request'
option family 'ipv4'
option target 'ACCEPT'
config rule
option name 'Allow-IGMP'
option src 'wan'
option proto 'igmp'
option family 'ipv4'
option target 'ACCEPT'
config rule
option name 'Allow-DHCPv6'
option src 'wanipv6'
option proto 'udp'
option src_ip 'fc00::/6'
option dest_ip 'fc00::/6'
option dest_port '546'
option family 'ipv6'
option target 'ACCEPT'
config rule
option name 'Allow-MLD'
option src 'wanipv6'
option proto 'icmp'
option src_ip 'fe80::/10'
list icmp_type '130/0'
list icmp_type '131/0'
list icmp_type '132/0'
list icmp_type '143/0'
option family 'ipv6'
option target 'ACCEPT'
config rule
option name 'Allow-ICMPv6-Input'
option src 'wanipv6'
option proto 'icmp'
list icmp_type 'echo-request'
list icmp_type 'echo-reply'
list icmp_type 'destination-unreachable'
list icmp_type 'packet-too-big'
list icmp_type 'time-exceeded'
list icmp_type 'bad-header'
list icmp_type 'unknown-header-type'
list icmp_type 'router-solicitation'
list icmp_type 'neighbour-solicitation'
list icmp_type 'router-advertisement'
list icmp_type 'neighbour-advertisement'
option limit '1000/sec'
option family 'ipv6'
option target 'ACCEPT'
config rule
option name 'Allow-ICMPv6-Forward'
option src 'wanipv6'
option dest '*'
option proto 'icmp'
list icmp_type 'echo-request'
list icmp_type 'echo-reply'
list icmp_type 'destination-unreachable'
list icmp_type 'packet-too-big'
list icmp_type 'time-exceeded'
list icmp_type 'bad-header'
list icmp_type 'unknown-header-type'
option limit '1000/sec'
option family 'ipv6'
option target 'ACCEPT'
config rule
option name 'Allow-IPSec-ESP'
option src 'wan'
option dest 'lan'
option proto 'esp'
option target 'ACCEPT'
config rule
option name 'Allow-ISAKMP'
option src 'wan'
option dest 'lan'
option dest_port '500'
option proto 'udp'
option target 'ACCEPT'
config include
option path '/etc/firewall.user'
DHCP
config dnsmasq
option domainneeded '1'
option localise_queries '1'
option rebind_protection '1'
option rebind_localhost '1'
option local '/lan/'
option domain 'lan'
option expandhosts '1'
option authoritative '1'
option readethers '1'
option leasefile '/tmp/dhcp.leases'
option nonwildcard '1'
option localservice '1'
config dhcp 'lan'
option interface 'lan'
option start '100'
option limit '150'
option leasetime '12h'
option dhcpv6 'server'
option ra 'server'
option ra_slaac '1'
list ra_flags 'managed-config'
list ra_flags 'other-config'
config dhcp 'wan'
option interface 'wan'
option ignore '1'
config odhcpd 'odhcpd'
option maindhcp '0'
option leasefile '/tmp/hosts/odhcpd'
option leasetrigger '/usr/sbin/odhcpd-update'
option loglevel '4'
vlanprio.sh
!/bin/sh
set -x
for i in 0 1 2 3 4 5 6 7; do
ip link set eth0.832 type vlan egress $i:$i >/dev/null
done
ip link set eth0.832 type vlan egress 1:0 >/dev/null
ip link set eth0.832 type vlan egress 0:6 >/dev/null
firewall.user
iptables -t mangle -A POSTROUTING -j CLASSIFY --set-class 0000:0001
iptables -t mangle -A POSTROUTING -p icmp -j CLASSIFY --set-class 0000:0006
iptables -t mangle -A POSTROUTING -p igmp -j CLASSIFY --set-class 0000:0006
ip6tables -t mangle -A POSTROUTING -j CLASSIFY --set-class 0000:0001
ip6tables -t mangle -A POSTROUTING -p ipv6-icmp -j CLASSIFY --set-class 0000:0006
ip6tables -t mangle -A POSTROUTING -p udp --dport 547 -j CLASSIFY --set-class 0000:0006
Merci ! :-X
-
Bonjour,
Merci beaucoup pour le tuto.
J'aurai besoin de votre aide s'il vous plaît.
* Netgear R7800 (eth0 : WAN / eth1 : LAN)
* OpenWrt v18.06.4
J'ai téléchargé le fichier config180602_double_ETH_version1.1.zip et remplacé les informations par :
firewall.user : eth1.832 > eth0.832
vlanprio.sh : eth1.832 > eth0.832
eth1.840 > eth0.840
network : eth0.1 > eth1.1
eth1.832 > eth0.832
eth1.840 > eth0.840
en hex : fti/user
n° série LB4
Plus de connexion au routeur après redémarrage (http et ssh).
Merci d'avance de votre retour.
-
merci pour ce tuto super bien fait ubune,
cela fonctionne à la perfection avec le WRT3200ACM + TP-LINK MC220L
cf https://lafibre.info/remplacer-livebox/aide-remplacement-livebox-4-fo/
par contre, te serait-il possible de préciser la manip de changement de matériel avant ça:
Une fois tout ceci fait, au prochain redémarrage de votre routeur vous devriez recevoir votre ip public sur l'eth1.832, la route par défaut et les dns Orange,
parce que sinon, c'est pas raccord avec ça:
il faut que votre routeur ait accès à Internet, au départ vous pouvez mettre la patte wan du routeur derrière votre livebox (qui est en dhcp client par défaut)
un peu à la façon de ce qui est dit là:
https://lafibre.info/remplacer-livebox/tuto-remplacer-la-livebox-par-un-routeur-dd-wrt-internet-tv/
Etape 0, prérequis :
Comme seul matériel nécessaire l'ONT fibre Orange (ou le SFP fibre Orange + un convertisseur cuivre), le routeur DD-WRT, éventuellement le décodeur TV.
/!\ Si votre Livebox n'était initialement pas fournie avec un boitier ONT, et que vous en avez récupéré un auprès d'Orange, pensez à le faire activer.
Connectez l'ONT fibre au port WAN du routeur DD-WRT.
etc. ....
et ça se serait parfait (surtout pour ceux et celles qui débraquent
Quoiqu'il en soit, encore un grand merci, ça fait du bien de pouvoir se passer de cette bo-box de m..... ^^
-
Merci pour le retour :), oui tu peux désinstaller igmpproxy si tu ne te sert pas de la tv (et les règles associées).
J'ai modifié la section !
A bientôt
-
WRT3200acm mis à jour sur OpenWrt 19.07.0-rc1.
Tout est OK (dhcp, tv etc... rien de particulier n'a changé, je n'ai pas creusé voir si il existe quelques nouvelles options pour le dhcp, plutot que le "code").
-
Pour les spécialistes !!! :
J' ai plusieurs routeurs OpenWrt que j' utilise , non pas en routeur, mais uniquement en relay
Tout fonctionne bien avec un firmware OpenWrt mais en variante PandoraBox
Par contre en pur OpenWrt j' ai souci en utilisant le décodeur TV .
Les chaines TV ne passent pas alors que j' ai bien la page WEB , l' heure et le mediaplayer fonctionnent
---
Je suis un peu ennuyé car je peux compiler facilement les firmwares OpenWRT mais pas ceux des firmwares PandoraBox ..
Y aurait-il une âme charitable qui puisse m' aider pour utiliser les firmwares OpenWRT ?
Merci d' avance ...
-
Bonjour,
Pour info je confirme ce qui a été dit plusieurs pages avant. Quand on garde la livebox derrière le routeur pour avoir le téléphone, il faut bien penser à ajoute l'option 119 sur le dhcp du VLAN:
list dhcp_option '90,00:00:00:00:00:00:00:00:00:00:00:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx'
list dhcp_option '120,00:xxx:etc..'
list dhcp_option '125,00:00:etc.'
list dhcp_option '6,80.10.246.136,81.253.149.6' # DNS orange
list dhcp_option '15,orange.fr'
list dhcp_option '119,XXX.access.orange-multimedia.net'
list domain 'orange.fr'
-
Bonjour à tous,
Depuis peu j'ai la fibre d'orange.
J'ai donc décidé d'utiliser un APU2 (pc-engines) pour remplacer la livebox.
Grâce à vous j'ai pu mettre en place la partie internet. (1000 merci à vos tutos).
Dans mon cas je veux aussi le téléphone fixe (pour les enfants) et les 2 boitiers TV5.
La solution que j'aurais aimé est de mettre la livebox sur un port de l'APU (mon routeur) et de brancher les 2 boitiers TV et le téléphone dessus.
Je n'ai pas eu l'impression de voir cette maniere de faire dans vos tutos.
Du coup si quelqu'un peu m'aider à le faire ca serait top !
Merci.
Cyril.
-
Bonjour eden
A mon avis, faut reprendre la configuration pour mettre la livebox derrière le routeur, et remplacer la configuration du VLAN 840 pour la TV par un simple bridge avec le port de la livebox.
A tester
-
Salut,
La configuration de la livebox derrière le routeur n'est pas présente sur la page 1 ? Car j'ai l'impression que c'est uniquement du remplacement dans les tutos.
Merci
Cyril
-
Ah si c'est présenté sur la première page avec un lien vers le post de rhon
https://lafibre.info/remplacer-livebox/remplacement-de-la-livebox-par-un-routeur-openwrt-18-dhcp-v4v6-tv/msg589599/#msg589599
C'est ce que j'utilise pour avoir le téléphone (box derrière le routeur). Après je n'ai pas vérifié su derrière la box le net fonctionne encore.
-
Le net fonctionne encore. Par contre pour la TV c’est une autre histoire parce que je pense que dans toutes les configurations listées le flux TV n’est pas renvoyé jusqu’à la box.
C’est faisable et la solution tu l’as donnée (bridge entre le VLAN 840 sur le port WAN et le VLAN 840 sur le port LAN où est connectée la box).
-
OpenWRT 19.07.0 vient de sortir. Quelqu'un l'a-t-il testé ?
-
La même configuration qu'openwrt 18.06 fonctionnait sur la version 19.07 rc2. Y'a pas de raison que ça change sur la 19.07 officielle.
-
La mise à jour est passée nickel sur mon routeur TPLink Archer C7, sans rien toucher à la configuration :)
root@OpenWrt:~# cat /etc/openwrt_release
DISTRIB_ID='OpenWrt'
DISTRIB_RELEASE='19.07.0'
DISTRIB_REVISION='r10860-a3ffeb413b'
DISTRIB_TARGET='ar71xx/generic'
DISTRIB_ARCH='mips_24kc'
DISTRIB_DESCRIPTION='OpenWrt 19.07.0 r10860-a3ffeb413b'
DISTRIB_TAINTS=''
-
La mise à jour est passée nickel sur mon routeur TPLink Archer C7, sans rien toucher à la configuration :)
root@OpenWrt:~# cat /etc/openwrt_release
DISTRIB_ID='OpenWrt'
DISTRIB_RELEASE='19.07.0'
DISTRIB_REVISION='r10860-a3ffeb413b'
DISTRIB_TARGET='ar71xx/generic'
DISTRIB_ARCH='mips_24kc'
DISTRIB_DESCRIPTION='OpenWrt 19.07.0 r10860-a3ffeb413b'
DISTRIB_TAINTS=''
Super merci pour le retour ;)
-
Mise à jour ok vers 19.07.1.
J'ai dû télécharger manuellement les paquets kmod-ipt-ipopt, iptables-mod-ipopt, libmnl0, zlib, libelf1, libcap, ip-full qui n'étaient pas inclus dans l'image pour mon routeur.
Comme d'autres, j'ai cependant perdu l'ipv6, mais cela date d'il y quelques mois/versions.
Y a-t-il eu des changements du côté d'Orange pour l'ipv6 ?
-
Bonjour,
j'ai fais l'acquisition d'un Linksys EA6350 sur lequel j'ai installé OPENWRT.
Je souhaite uniquement remplacer ma livebox et faire marcher internet
Avant toute chose j'ai sauvegardé le dossier ETC au cas où,
J'ai suivi scrupuleusement le tutoriel et j'ai téléchargé config180602_double_ETH_version1.1.zip. Le fichier info est simple et explicite.
J'ai lancé la commande opkg update && opkg install nano tcpdump igmpproxy ip-full iptables-mod-ipopt luci-ssl
J'ai démarré luci et le lancement auto de igmproxy
/etc/init.d/uhttpd start
/etc/init.d/igmpproxy start
/etc/init.d/igmpproxy enable
J'ai changé d'hexadecimal du fti/qpq8888 du tutoriel par le mien transformé via le lien https://www.rapidtables.com/convert/number/ascii-to-hex.html en supprimant les espaces dans les deux emplacements demandé du fichier network via notepad.
Néanmoins lorsque je branche mon ONT à wan du routeur et mon PC sur un des autres ports (je les ai tous essayé) je n'ai pas de connexion internet. J'ai mis quelques infos sur l'imprim écran.
Mes connaissances en réseaux étant limité je sèche.
En vous remerciant par avance
-
Bonjour,
j'ai un routeur ea6350 que je souhaite remplacer par une Livebox 3. Avec le tutoriel tel quel ça ne marche pas en même temps c'est préciser pour livebox 4-6. J'ai essayé de remplacer dans le fichier network
option sendopts '11:00000000000000000000001a0900000558010341010d6674692f75777676373733 15:FSVDSL_livebox.Internet.softathome.livebox3 16:0000040e0005736167656d'
Ca ne marche pas non plus.
Est-ce que vous avez des solutions ?
En vous remerciant
-
Bonjour à tous,
J’ai remplacé ma LB4 en fibre Sosh par un routeur Netgear R6220 sous OpenWRT et tout fonctionne (ipv4 + IPv6) :)
Mais j’ai une question sur le débit :
- avec la LB, test direct de la box, j’avais environ 250mb
- avec le netgear, test direct du routeur (sans passer par le lan donc) avec iperf3, j’ai environ 160mb.
D’où peut venir cette différence ?
Test Livebox surévalué ou routeur qui ne peut pas se synchroniser à 250mb?
Merci
-
J'ai suivi ce tuto, ça fonctionne bien. Par contre, la méthode de passer par défaut en piro VLAN 6 puis de router via iptables ne me suffit pas, car j'aimerais activer le flow offload (disponible depuis OpenWRT 19.07 pour l'Archer C7 v5 que j'utilise). Sinon le proc est noyé par les IRQ, et les débits sont bridés ce qui est dommage (même si on arrive quand même à plus de 300 mbps ce qui est déjà pas si mal). Avec l'offload et avec ma vieille offre de base je suis manifestement en 400/400.
J'ai donc patché (à la rache) les clients DHCP d'OpenWRT (oui en v4 ils utilisent busybox, et en v6 odhcp6c qui sont donc disctincts). J'ai donc bien les paquets DHCP avec la prio VLAN, et uniquement eux, ce qui permet de laisser les flux passer sans jouer avec iptables, et donc d'activer l'offload.
Il faut tout de même évidemment mapper une des prio kernel en prio VLAN. J'ai pris la 6. Seulement a priori le système de ifup d'OpenWRT ne permet pas de hook en pre-up et donc de placer le mapping avant l'envoi des paquets DHCP de façon certaine (si l'interface VLAN est coupée, il faut recommencer etc.). J'ai donc fait faire ça à busybox dans la foulée (et, oui, c'est doublement crade du coup).
Bien sûr le reste du tuto reste vrai, ceci ne remplace QUE la partie iptables et script vlanprio dans le cas où on est dans une zone qui nécessite le tag VLAN PRIO. Et bien sûr cela est à refaire à chaque mise à jour (compiler en amont pour éviter les surprises et télécharger le SDK, copier les exécutables après…) ce qui peut paraitre un peu lourd !
Patch dégueu pour busybox (prio sur la socket et egress mapping) :
--- busybox-1.30.1.orig/networking/udhcp/packet.c
+++ busybox-1.30.1/networking/udhcp/packet.c
@@ -115,6 +115,20 @@ int FAST_FUNC udhcp_send_raw_packet(stru
const char *msg;
fd = socket(PF_PACKET, SOCK_DGRAM, htons(ETH_P_IP));
+#include <linux/sockios.h>
+#include <linux/if_vlan.h>
+#include <net/if.h>
+const int VLAN_DHCP_PRIORITY = 6;
+char *buf[IF_NAMESIZE];
+setsockopt(fd, SOL_SOCKET, SO_PRIORITY, &VLAN_DHCP_PRIORITY, sizeof(VLAN_DHCP_PRIORITY));
+struct vlan_ioctl_args vlan_args;
+vlan_args.cmd=SET_VLAN_EGRESS_PRIORITY_CMD;
+vlan_args.u.skb_priority=6;
+vlan_args.vlan_qos=6;
+if_indextoname(ifindex, buf);
+strcpy(vlan_args.device1,buf);
+
+ioctl (fd,SIOCSIFVLAN, &vlan_args);
if (fd < 0) {
msg = "socket(%s)";
goto ret_msg;
Patch pour odhcp6c (prio sur la socket uniquement car egress déjà fait par busybox en v4) :
--- build_dir/target-mips_24kc_musl/odhcp6c-2019-01-11-e199804b/src/dhcpv6.c.orig 2020-03-30 10:26:51.191836514 +0200
+++ build_dir/target-mips_24kc_musl/odhcp6c-2019-01-11-e199804b/src/dhcpv6.c 2020-03-30 10:27:51.531659035 +0200
@@ -140,6 +140,9 @@
ifindex = ifr.ifr_ifindex;
+const int VLAN_DHCP_PRIORITY = 6;
+setsockopt(sock, SOL_SOCKET, SO_PRIORITY, &VLAN_DHCP_PRIORITY, sizeof(VLAN_DHCP_PRIORITY));
+
// Create client DUID
size_t client_id_len;
odhcp6c_get_state(STATE_CLIENT_ID, &client_id_len);
Il suffit alors simplement de copier les nouveau exécutables à la place de ceux de base (ils se retrouveront donc sur l'overlay).
Procédure pour moi à partir du SDK de 19.07.2 et pour l'Archer C7 (999-vlan-prio.patch contenant le patch pour busybox et 192.168.1.42 l'IP du routeur pendant les tests) :
./scripts/feeds update -a
./scripts/feeds install busybox
cp 999-vlan-prio.patch ./feeds/base/package/utils/busybox/patches/
make package/busybox/compile
scp build_dir/target-mips_24kc_musl/busybox-1.30.1/.pkgdir/busybox/bin/busybox root@192.168.1.42:/bin
./scripts/feeds install odhcp6c
make package/odhcp6c/prepare
nano build_dir/target-mips_24kc_musl/odhcp6c-2019-01-11-e199804b/src/dhcpv6.c (et appliquer le patch à la main, ou directement via patch -p1)
make package/odhcp6c/compile
scp ./build_dir/target-mips_24kc_musl/odhcp6c-2019-01-11-e199804b/.pkgdir/odhcp6c/usr/sbin/odhcp6c root@192.168.1.42:/usr/sbin/
Debug :
busybox udhcpc -i eth0.832
cat /proc/eth0.832
À voir si ça peut en aider certains ou si je peux améliorer la présentation, c'est sûr que c'est très technique et que je ne réexplique pas tous les concepts sinon on s'en sortirait pas :)
Je ne pense pas soumettre ces patchs aux projets concernés car c'est quand même très très spécifique… et qu'ils contiennet la partie de configuration egress du VLAN ce qui n'est pas pertinent à cet endroit dans le cas général.
-
Bonjour,
Je suis entrain de remplacer ma Livebox V4 par un "Netgear R6220-100PES" et pour le moment tout ce passe bien j'ai internet + la TV et je vais travailler par la suite sur le téléphone, j'ai un soucis avec le débit internet.
J'arrive à peine a 500 mbits /sec alors qu'avec la livebox je suis a 1giga bit /sec, j'ai beaux chercher une solution je trouve pas.
J'ai essayer le module dans le firewall mais ça ne change rien quelqu'un aurait une idée vers ou creuser s'il vous plait ?
Version du firmware que j'utilise " 19.07.2 "
-
Bonjour,
Je suis entrain de remplacer ma Livebox V4 par un "Netgear R6220-100PES" et pour le moment tout ce passe bien j'ai internet + la TV et je vais travailler par la suite sur le téléphone, j'ai un soucis avec le débit internet.
J'arrive à peine a 500 mbits /sec alors qu'avec la livebox je suis a 1giga bit /sec, j'ai beaux chercher une solution je trouve pas.
J'ai essayer le module dans le firewall mais ça ne change rien quelqu'un aurait une idée vers ou creuser s'il vous plait ?
Version du firmware que j'utilise " 19.07.2 "
C'est bien tout le problème que j'ai avec un Mikrotik hEX PoE contre une Livebox 5 avec un abonnement Open Up à 2Gb/s...
Du coup j'ai remis la livebox 5 avec un switch avec plusieurs VLAN et des bornes Wifi en répartissant mon trafic dans chaque VLan et ainsi j'arrive à cumuler le débit de chaque Vlan sur un port physique de la livebox en dépassant allègrement le 1Gb/s...
-
Bonjour tout le monde, et merci à @ubune pour ce tuto si détaillé!
J'essaie de le suivre pas à pas, mais je bute sur une notion (les tags) et j'aimerais la comprendre avant de faire une erreur du débutant que je suis.
Dans cette partie:
Ce qu'il faut comprendre, c'est que pour la gestion des vlan, il faut obligatoirement qu'un vlan associé à l'Eth en question soit aussi taggué vers son CPU.
Exemple le VLAN 832 qui est donc sur mon ETH1, doit être en taggué sur l'ETH1 mais AUSSI sur le CPU.
Dans le fichier network on doit retrouver :
La config Switch :
config switch_vlan
option device 'switch0'
option vlan '2' # index
option ports '4t 6t' # t pour tag, on tag sur le port 4 (qui est le port wan) et le 6 c'est mon cpu eth1.
option vid '832' # id du vlan
La gestion des VLANs est plus clair sur Luci => :
(https://image.noelshack.com/minis/2018/27/3/1530690963-switch.png) (https://www.noelshack.com/2018-27-3-1530690963-switch.png)
Concernant le vlan_832 qui doit être tagué sur l'eth1 et sur le cpu:
Les ports 4t et 6t sont-ils arbitraires (et on peut utiliser n'importe quel numéro) ou cela correspond à quelque-chose de précis à trouver sur chaque machine? Pour le dire autrement, comment sait on que le port wan est bien le 4 et pas un autre? Idem pour le cpu eth1 tagué sur le port 6t?
Si vous avez de la doc générale à conseiller qui permette de mieux comprendre le concept de tag et la gestion des VLAN (lien équivalent à celui cité dans le tuto qui n'existe plus) je suis preneur.
Merci d'avance!
P.S: je suis sur un zyxel nbg6617
-
Je me réponds tout seul car l'assignation par défaut des ports pour le cpu et eth1 est décrite dans la doc du zyxel (0 pour le cpu et 5 pour eth1).
Mais je suis toujours preneur de la doc manquante sur la gestion des VLAN avec Luci.
-
Bon, pas à pas je bute quand-même sur l'étape suivante. ::)
Dans la doc de mon modèle, il est marqué:
eth1 is “hard wired” to port 5 with vid 2. To get multiple vlans working we need to declare vlan 2 in /etc/config/network containing '0t 5' ports. Then we can e.g. bridge a LAN port to WAN. Note that using eth0.2, eth0.1, won't work. Bridging in vlan setup is sufficient.
Si je comprends bien (mais rien n'est moins sûr) on ne peut pas utiliser la formulation "eth0.1" dans les option ifname , et le VLAN qui me sert à me connecter à orange devra être déclaré en tant que vlan 2 et avec les tags '0t 1 5'?
Du coup j'ai remplacé les eth0.x par eth0 (idem avec eth1) et ai remplacé les option ports '4t 6t' par option ports 0t 1 5 dans les différents fichiers mais ça n'a bien sûr rien donné.
Je sais pas trop de quel côté chercher, est-ce que quelqu'un aurait une idée ou 2/3 conseils pour m'aiguiller? En attendant, je vais continuer à RTFM ça ne me fera pas de mal ^^
Merci d'avance!
P.S: Je ne cherche pas à gérer de TV, ce serait juste pour la partie internet
-
Salut Tufek !
Peux-tu m'envoyer un ifconfig de ton routeur ?
Si je comprends bien ton message, ça voudrait dire que sur ton Zyxel tu peux pas toucher à ton WAN, il est "bloqué" en eth1 vlan 2.
Ce que j'ai l'impression, c'est qu'ils te disent de configurer un port lan avec ton vlan 832, donc eth0.832, et faire un bridge entre "eth0.832 et eth1" (p-e eth1.2 sur ta conf).
As-tu le lien de la doc en question ? On regarde rapidement
Edit :
au pire on s'en fiche du port Wan.
Tu dédies un de tes ports lan, tu crées un vlan.
Vlan 1 = Lan
Vlan 99 = Poubelle (pour éviter de polluer l'ont de ton trafic arp/broadcast du vlan pc).
Vlan 832 = Internet Orange.
Port lan 1-3 untagg 1 (ton lan) => eth0.1 => Ports pour tes pc
Port lan 4 untagg 99 tag 832 (ton wan) => eth0.832 => Port pour l'ont.
Et ça devrait le faire :).
-
En faite d'après la doc Openwrt concernant ton Zyxel :
Port Zyxel ; Switch port (internal)
WAN ; 5 Non configurable.
LAN 1 ; 4
LAN 2 ; 3
LAN 3 ; 2
LAN 4 ; 1
CPU ; 0
Donc en oubliant le port Wan (si il pose soucis) ça donnerait :
config switch
option name 'switch0'
option reset '1'
option enable_vlan '1'
config switch_vlan
option device 'switch0'
option vlan '1' #INDEX PAS VLAN ID
option vid '1' # Vlan PC
option ports '0 4 3 2' # vlan 1 Untagg sur le CPU et les ports 1,2,3 du Zyxel.
config switch_vlan
option device 'switch0'
option vlan '2' #INDEX PAS VLAN ID
option vid '99' # Vlan Poubelle
option ports '0t 1' # vlan 99 Tag CPU et Untagg port 4 Zyxel.
config switch_vlan
option device 'switch0'
option vlan '3' #INDEX PAS VLAN ID
option vid '832' # Vlan Internet Orange
option ports '0t 1t' #Vlan 832 Tag CPU et Tag Port 4 Zyxel (pour ONT).
Et ensuite ton fichier network @eth0.1 pour le lan, eth0.832 pour le Wan et Wan6.
Puis ONT PORT LAN 4, PC LAN 1-3.
-
Salut,
Merci pour la réponse et les explications! (et désolé pour ma réponse un peu tardive).
Alors j'ai effectué tes modifs et copié/collé les fichiers de ton tuto (à l'exception du eth1.832 également remplacé par eth0.832 dans le /etc/firefall.user et de l'interface lan que je conserve en 192.168.0.1).
Malheureusement ça ne donne rien, lorsque je relance le réseau/redémarre derrière l'ONT, et je perds aussi la connexion filaire avec mon pc (je fais mes backups en wifi wi-fi avec un portable).
Le ifconfig après relance semble indiquer qu'il n'y ait pas pas du tout de trafic dans les nouveaux vlans (mais bon je débute en réseau, je rate sans-doute des trucs).
Du coup je te mets en PJ mes ifconfigs avant/après modifications, et ainsi mon fichier network (sans l'hexa) des fois que j'eussé fait des coquilles ou qu'une grosse erreur de n00b m'échappe ::)
thanks pour le coup de main en tout cas, c'est sympa!
-
Salut,
Merci pour la réponse et les explications! (et désolé pour ma réponse un peu tardive).
Alors j'ai effectué tes modifs et copié/collé les fichiers de ton tuto (à l'exception du eth1.832 également remplacé par eth0.832 dans le /etc/firefall.user et de l'interface lan que je conserve en 192.168.0.1).
Malheureusement ça ne donne rien, lorsque je relance le réseau/redémarre derrière l'ONT, et je perds aussi la connexion filaire avec mon pc (je fais mes backups en wifi wi-fi avec un portable).
Le ifconfig après relance semble indiquer qu'il n'y ait pas pas du tout de trafic dans les nouveaux vlans (mais bon je débute en réseau, je rate sans-doute des trucs).
Du coup je te mets en PJ mes ifconfigs avant/après modifications, et ainsi mon fichier network (sans l'hexa) des fois que j'eussé fait des coquilles ou qu'une grosse erreur de n00b m'échappe ::)
thanks pour le coup de main en tout cas, c'est sympa!
Ok c'est curieux car sur le "ifconfig après" ton eth0.1 tu n'as aucun paquet reçu coté routeur, alors que sur eth0.832 oui (dans les deux sens).
Peux-tu refaire un test avec ce fichier @network (eth0 simple pour le lan) et sans les interfaces que tu utilises pas.
As-tu aussi penser à corriger le script vlanprio.sh pour y mettre eth0.832 ?
On est d'accord, ton pc en filaire est bien branché sur le port LAN 1 ou 2 ou 3 ? et l'ont sur le port LAN 4 ?
Si possible envoi carrément ton /etc en zip.
-
my bad, j'avais omis d'éditer vlanprio.sh...
Ça fonctionne maintenant (avec une petite hausse de débit en prime), c'est génial !!
merci vraiment pour le coup de main
-
my bad, j'avais omis d'éditer vlanprio.sh...
Ça fonctionne maintenant (avec une petite hausse de débit en prime), c'est génial !!
merci vraiment pour le coup de main
Ok super, de rien content d'avoir pu aider.
Donc au final tu es bien en eth0 simple pour le vlan 1 ?
Bienvenue dans le monde d'openwrt ;)
-
Salut Ubune, j'ai mis à jour mon routeur wrt32x sur la version 19.07.02. Et au reboot, malgré "keep settings", plus d'Internet.
En fait avec la maj, le fichier `/etc/vlanprio.sh` a été supprimé.
J'ai galéré à refaire une config complète fonctionnelle, malgré le tuto...
Au final, tout fonctionne, mais je suis ne suis plus IPv6 ready :'(
Quand je fais un ifstatus wan ou wan6, je n'ai rien dans
"ipv6-address": [
],
As-tu une idée ? A+
-
Salut Ubune, j'ai mis à jour mon routeur wrt32x sur la version 19.07.02. Et au reboot, malgré "keep settings", plus d'Internet.
En fait avec la maj, le fichier `/etc/vlanprio.sh` a été supprimé.
J'ai galéré à refaire une config complète fonctionnelle, malgré le tuto...
Au final, tout fonctionne, mais je suis ne suis plus IPv6 ready :'(
Quand je fais un ifstatus wan ou wan6, je n'ai rien dans
"ipv6-address": [
],
As-tu une idée ? A+
Salut W3s,
Alors une maj c'est pas si évident sur Openwrt, car même si tu peux garder les fichiers présent sur le routeur (en les indiquant dans le fichier /etc/sysupgrade.conf), tu vas perdre les packages etc.
Une fois à jour tu as bien installé igmpproxy, ip-full et iptables-mod-ipopt ?
Reprends le zip /etc double eth du post initial, et regarde si t'as pas un oubli ou une erreur.
Si tu trouves pas, zip et partage nous ton /etc (en enlevant le fti si ça t'embete).
-
Reprends le zip /etc double eth du post initial, et regarde si t'as pas un oubli ou une erreur.
Si tu trouves pas, zip et partage nous ton /etc (en enlevant le fti si ça t'embete).
Hello, merci pour ta réponse, j'avais même pas pensé à regarder les sources dans le zip ;D
J'ai remarqué des différences entre la ressource zip et le tuto, mais mon niveau en réseau est moindre que le tiens donc est-ce que ces infos sont nécessaires ?
Dans le fichier /etc/firewall.user du zip, il y a ça en plus :
ip6tables -t mangle -A POSTROUTING -o eth1.832 -p udp --dport 547 -j CLASSIFY --set-class 0000:0006
Dans /etc/config/dhcp :
list dns '2606:4700:4700::1001'
list dns '2606:4700:4700::1111'
Est-ce que ça peut avoir une incidence ?
-
Hello, merci pour ta réponse, j'avais même pas pensé à regarder les sources dans le zip ;D
J'ai remarqué des différences entre la ressource zip et le tuto, mais mon niveau en réseau est moindre que le tiens donc est-ce que ces infos sont nécessaires ?
Dans le fichier /etc/firewall.user du zip, il y a ça en plus :
ip6tables -t mangle -A POSTROUTING -o eth1.832 -p udp --dport 547 -j CLASSIFY --set-class 0000:0006
Dans /etc/config/dhcp :
list dns '2606:4700:4700::1001'
list dns '2606:4700:4700::1111'
Est-ce que ça peut avoir une incidence ?
Dans le tuto le classify udp port 547 est aussi présent, mais je pense que tu parlais de ça =>
ip6tables -t mangle -A POSTROUTING -p udp --dport 547 -j DSCP --set-dscp-class CS6
C'est pas nécéssaire, tant que tu as le CLASSIFY cité précédemment ça suffit.
Concernant le dns, c'est simplement qu'on envoi sur le lan (option 25 présente dans le RA) les dns ipv6 de cloudflare, mais tu peux ne pas le mettre et/ou en mettre d'autres.
Tu ne reçois toujours pas le préfixe sur le wan6 ?
As-tu bien la config firewall du tuto (zone wan et zone wan6 séparées), avec les règles icmpv6/dhcpv6 ?
config zone
option name 'wan' # WAN ipv4 only
option output 'ACCEPT'
option masq '1'
option input 'DROP'
option forward 'DROP'
option network 'wan'
option family 'ipv4'
config zone
option name 'wan6' # WAN6 IPV6 Only
option input 'DROP'
option forward 'DROP'
option network 'wan6'
option family 'ipv6'
option output 'ACCEPT'
config rule
option name 'Allow-DHCPv6'
option proto 'udp'
option src_ip 'fc00::/6'
option dest_ip 'fc00::/6'
option dest_port '546'
option family 'ipv6'
option target 'ACCEPT'
option src 'wan6'
config rule
option name 'Allow-MLD'
option proto 'icmp'
option src_ip 'fe80::/10'
option family 'ipv6'
option target 'ACCEPT'
option src 'wan6'
config rule
option name 'Allow-ICMPv6-Input'
option proto 'icmp'
option limit '1000/sec'
option family 'ipv6'
option target 'ACCEPT'
option icmp_type 'echo-reply destination-unreachable echo-request router-advertisement router-solicitation time-exceeded'
option src 'wan6'
config rule
option name 'Allow-ICMPv6-Forward'
option proto 'icmp'
option limit '1000/sec'
option family 'ipv6'
option target 'ACCEPT'
option src 'wan6'
option dest '*'
Sinon envoi ton /etc et une capture tcpdump de l'eth1.832 (tcpdump -ni eth1.832 ip6 -w problem-ipv6.pcap)
-
Bonjour,
A la lecture de tests dernier message, je viens de me rendre compte que j'avais oublié (lors de la MAJ vers OpenWRT 19.07.2) de réinstaller :
- iptables-mod-ipopt
- ip-full
- le script /etc/vlanprio.sh
Pour autant, les performances de mon accès Internet me semblaient à première vue tout à fait correctes (300 Mbps symétrique sur testdebit.info, soit le maximum théorique chez Sosh).
Etrange :o
Ps : je n'utilise pas la TV.
-
Salut :)
Cela veut donc dire que tu fais parti des (rare ?) clients Orange qui n'ont pas besoin d'envoyer la requête dhcp avec la priorité.
Ces packages ainsi que le script sont là pour ça.
Donc config + simple pour toi
ps : Pour le package iptables-mod-ipopt, je ne suis plus sûr qu'il soit nécessaire en 1907, mais je ne peux pas tester pour le moment.
-
Bonjour à tous,
après avoir tester DD-WRT sur lequel j'ai un soucis de mise en réseau, j'avais un petit routeur WNDR3700, qui me permet d'avoir Open-WRT dessus, tout ce passe nickel avec les fichiers fournis,
un grand merci à vous !!!
je reste sur Open-WRT car je peux mettre le routeur sur mon onduleur de baie de brassage, le wifi passe par un autre routeur plus a l'aise et mieux positionné dans ma maison :) mur de 73cm de pierre.
j'aimerais mettre le téléphone en route, avec la livebox, allumé mais dans un autre endroit de la maison, j'ai suivi le post page6, mais je pense que je fais une erreur lors de la copie des lignes à ajouter,
mon réseau est en 10.0.0.1.
dois-je mettre à jour aussi les ip du téléphone pour la livebox (10.0.100.1)?
lorsque je la branche, elle me donne un message d'erreur de connexion réseau.
config ci-après :
- ONT Orange, routeur port WAN,
- port 1 du routeur (qui doit être le 4 dans le routeur) LAN,
- port 4 (qui doit être le 1) port téléphone, je n'ai pas besoin de la TV,
actuellement aucun soucis pour le net, vous êtes génial,
est ce que quelqu'un ayant mis le téléphone pourrait fournir les fichiers de bases, avec les lignes ajouter, afin de pouvoir adapter la configuration.
Merci d'avance, cela pourrait être ajouter au premier du poste 1, permettant le choix entre les 2 configurations, avec ou sans téléphone.
-
Plop,
les utilisateurs de ER-X peuvent-ils confirmer qu'il faut choisir entre l'offload hw-nat et le marquage DSCP ?
-
j'aimerais mettre le téléphone en route, avec la livebox, allumé mais dans un autre endroit de la maison, j'ai suivi le post page6, mais je pense que je fais une erreur lors de la copie des lignes à ajouter,
mon réseau est en 10.0.0.1.
dois-je mettre à jour aussi les ip du téléphone pour la livebox (10.0.100.1)?
lorsque je la branche, elle me donne un message d'erreur de connexion réseau.
J'ai le téléphone fonctionnel.
Ma configuration est la suivante :
/etc/config/network
config switch_vlan
option device 'switch0'
option vlan '9'
option vid '3'
option ports '2 6t'
config interface 'TEL'
option proto 'static'
option ipaddr '10.10.12.1'
option netmask '255.255.255.0'
option defaultroute '0'
option ifname 'eth0.3'
/etc/config/dhcp
config dhcp 'TEL'
option start '100'
option leasetime '12h'
option domain 'orange.fr'
option limit '150'
option interface 'TEL'
list dhcp_option '120,00:06:73:62:63:74:33:67:03:52:45:4e:06:61:63:63:65:73:73:11:6f:72:61:6e:67:65:2d:6d:75:6c:74:69:6d:65:64:69:61:03:6e:65:74:00'
list dhcp_option '125,00:00:05:58:0c:01:0a:00:01:00:00:00:ff:ff:ff:ff:ff'
list dhcp_option '90,00:00:00:00:00:00:00:00:00:00:00:64:68:63:70:6c:69:76:65:62:6f:78:66:72:32:35:30'
list dhcp_option '119,REN.access.orange-multimedia.net'
list dhcp_option '15,orange.fr'
/etc/config/firewall
config zone
option name 'tel'
option output 'ACCEPT'
option log '1'
option family 'ipv4'
option input 'ACCEPT'
option network 'TEL'
option forward 'REJECT'
config rule
option src 'tel'
option dest_port '53'
option proto 'tcpudp'
option target 'ACCEPT'
option name 'DNS for Livebox'
config rule
option src 'tel'
option dest_port '67-68'
option proto 'udp'
option target 'ACCEPT'
option name 'DHCP for Livebox'
config rule
option name 'Allow-DHCP-Renew for Livebox'
option proto 'udp'
option dest_port '68'
option target 'ACCEPT'
option family 'ipv4'
config forwarding
option dest 'lan'
option src 'tel'
config forwarding
option dest 'wan'
option src 'tel'
Note : je ne pouvais pas déclarer 2 fois le VLAN 832 sur le switch intégré à mon routeur TP-Link Archer C7 (une fois pour le WAN, une fois pour le réseau "Tel")
Par conséquent :
- J'ai défini un VLAN "3" bidon pour le réseau "Tel", et le fais sortir du routeur en Untagged, sur le port LAN1 (= 2 sur le Switch intégré)
- J'utilise un Switch managé, pour retaguer le VLAN 832
-
Bonjour à tous,
Je me permets de venir ici solliciter votre aide, je viens de passer sur Orange Fibre, et comme a mes habitudes ne souhaite pas utiliser le modem proprietaire.
Ayant procédé a ce type de config chez Orange ADSL, Free ADSL, Free VDSL etc auparavant je pensais y parvenir sans souci.. apres trois heures d'essais je jete l'éponge et me voici ^^
Mon install :
ONT Huawei ---> Asus AC51U sous OpenWRT 19
Je n'ai besoin ni de la TV ni du tel. Et bien avec la meilleure volonté du monde je n'y parviens pas ... Je précise que je configure avec Luci. Voila si quelqu'un peut me faire une petite synthèse rapide des manips a effectuer.. (j'ai bien lu le tuto mais y'a des points qui doivent m'échapper..)
Merci à vous. Nico
-
@ubune
Bonsoir ubune,
Merci pour ton tuto.
Ayant depuis plusieurs années remplacé mes livebox(s) par un Ubiquiti EdgeRouter Lite 3 ERLite-3 sous edgeOS, et ayant lu ton post sur le remplacement de la livebox par des routeurs en openwrt. J'ai eu envie de faire le remplacement de la livebox par un Raspberry pi4 sous OpenWrt en lisant cet article : https://www.zahradnik.io/raspberry-pi-as-a-home-router. Par avoir simplement une idée des perfs avec cette petite bête (mon ubiquiti me convient toujours parfaitement)
Je suis en train de tester ton tuto sur un raspberry pi4 4go de raw avec OpenWrt : (ça ressemble à mon edgeOS , c'est du debian) et j'ai un adaptateur USB3RJ45 pour faire mon port WAN avec un convertisseur FTTH-cuivre...
1- installation OpenWrt (pour ceux qui aurait envie de faire pareil ...
- charger image OpenWrt pour raspberry pi4 : https://downloads.openwrt.org/snapshots/targets/bcm27xx/bcm2711/openwrt-bcm27xx-bcm2711-rpi-4-squashfs-factory.img.gz
- ssh root@192.168.1.1 (adresse par défaut) avec un pc branché avec la même classe d'adresse...
- uci set network.lan.ipaddr=192.168.1.2 (on va partir du principe que l'ancien routeur est en 192.168.1.1 (pour installer les paquets pour OpenWrt)
- uci set network.lan.gateway=192.168.1.1
- uci set network.lan.dns=1.1.1.1
- uci commit network
- /etc/init.d/network restart ou reboot ...
Puis, on branche le raspberry sur le réseau du routeur existant .. et on installe les paquets pour la suite ....
- opkg update && opkg install block-mount kmod-fs-ext4 kmod-usb-storage kmod-usb-ohci kmod-usb-uhci e2fsprogs fdisk cfdisk xxd uhttpd
(PS dans ton tuto ubune (peut être préciser l'installation du paquet xxd et uhttpd, puisque tu t'en sers pour le conversion hexagonale du fit et je crois que le paquet uhttpd n'était pas installé quand j'ai suivi ton tuto ... ?)
(pour uhttpd : uHTTPd is the standard HTTP server for OpenWrt, but it is not included by default in the system image for the main OpenWrt releases. The package name is uhttpd. cf. https://openwrt.org/docs/guide-user/services/webserver/http.uhttpd).
- opkg install luci-nginx ou opkg install luci-ssl-nginx
- opkg install kmod-usb-net-rtl8152 ou opkg install kmod-usb-net-asix-ax88179 (pour l'installation de l'adaptateur USB3RJ45 dont voici les 2 types les plus fréquents, le plus simple étant de les installer dans l'interface de luci pour avoir toutes les dépendances)
- reboot
(pour ceux-ci qui veulent étendre la partition /overlay c'est ici : https://openwrt.org/docs/guide-user/additional-software/extroot_configuration
2- Configuration avec adaptation des fichiers de ubune pour OpenWrt avec Orange sur un Raspberry: (fichiers fournis, cf. plus bas)
Avec la configuration du Raspberry pi4, j'ai le port RJ45 du Raspberry pour le LAN (ETH0) et le port USB3RJ45 rajouté (ETH1) pour le WAN (derrière un TP-Link MC220L Convertisseur). Je suis à 300/300Mbits sur SOSH. A tester sur une FTTH 1Gbits... et mettre des switchs manageables derrière ETH1....
Cordialement
-
Bonjour à tous,
La fibre est (enfin) arrivée jusqu'à la maison hier.
Après des rapides tests avec la livebox, hop, retour dans sa boite et j'installe le routeur OpenWRT que j'avais préparé pour l'occasion grâce à ce super post.
... et bé ça marche pâ :o(
- du tout en IPv6:
ifstatus wan6
{
"up": false,
"pending": true,
"available": true,
"autostart": true,
"dynamic": false,
"proto": "dhcpv6",
"device": "eth0.832",
"data": {
et ça marcherait surement très bien en IPv4 si le DHCP d'Orange avait l'extrême amabilité de bien vouloir me refiler l'adresse de la gateway:
ifstatus wan
{
"up": true,
"pending": false,
"available": true,
"autostart": true,
"dynamic": false,
"uptime": 820,
"l3_device": "eth0.832",
"proto": "dhcp",
"device": "eth0.832",
"updated": [
"addresses",
"data"
],
"metric": 0,
"dns_metric": 0,
"delegation": true,
"ipv4-address": [
{
"address": "172.16.35.80",
"mask": 24
}
],
Je reçois bien l'IP et le masque mais strictement rien d'autre .. j'suis bien avancé sans la gateway
Destination Gateway Genmask Flags Metric Ref Use Iface
172.16.35.0 * 255.255.255.0 U 0 0 0 eth0.832
192.168.2.0 * 255.255.255.0 U 0 0 0 br-lan
J'ai pas mal joué avec un tunnel IPv6chez HE ces derniers temps pour me faire la main avec l'IPv6.
Je pense avoir tout bien fait
J'ai même tenté de rajouté l'option DHCP '3' (routeur) dans le champ "option reqopts"
J'ai même fini, sans plus de chance, avec qqchose piqué sur un sujet LEDE :
option reqopts '1 3 6 15 28 51 58 59 0 119 120 125'
Y'a des siouxerie qui seraient apparues récemment qui expliqueraient que ça ne passe pas dans mon cas ??
5h que je suis là dessus sans succès, 3 remise à zéro du routeur pour m'assurer de repartir d'une base propre (info: j'ai un routeur à base d'IQP4xxx - donc avec un seul eth0) je me suis cassé les dents là dessus pendant 1h avant de comprendre que j'avais laissé du eth1 dans le vlanprio.sh.
J'ai bien vérifié partout je n'en n'ai laissé trainer aucun autre.
Je me suis peut-être simplement fait bannir non ?
Si quelqu'un est inspiré pour m'aider ...
Cdt
Hervé
-
Ni siouxeries (rien n’a changé récemment), ni bannissement.
Sinon, je ne voudrais pas trop te décourager, mais non, tu ne reçois pas non plus d’adresse IPv4... 172.16.35.0/24 n’appartient pas à Orange, et c’est d’ailleurs une plage d’adresses privées.... Je suppose que l’attribution d’une adresse privée est le comportement par défaut d’openwrt quand les requêtes DHCP échouent (et ça explique pourquoi tu n’as pas de gateway).
-
Salut Hervé,
Non comme dit Zoc aucun changement ça fonctionne toujours.
Pour t'aider peux-tu :
faire un ifconfig eth0.832 et vérifier que tu as du dialogue dans les deux sens, (check rx).
Si pas le cas, vérifie ta conf "switch" dans le fichier network.
Si c'est le cas :
As-tu installé l'ensemble des paquets (ip-full en l'occurence).
Qu'obtiens-tu si tu lances le script manuellement ?
sh /etc/vlanprio.sh
As-tu le ficher /etc/rc.local comme dans le tuto ?
sleep 10
ifdown wan # J'ai eu besoin de faire ça pour être sûr d'éviter l'ip privée sur le wan, depuis la maj 18.02.
sh /etc/vlanprio.sh
ifup wan
exit 0
Si ça ne fonctionne toujours pas, le top pour t'aider, une fois ton routeur branché sur l'ont =>
tcpdump -ni eth0.832 -w capture-debug.pcap Powershell sur ta machine windows 10:
cd tonrepertoire
scp root@iprouteur:/root/capture-debug.pcap .
Et tu nous transmet la capture + le modèle exacte de ton routeur et ton /etc zip
-
Rebonjour,
Merci pour vos réponse.
Alors côté matos j'ai donc essayé avec:
- Un Western Digital My Net N750 (Atheros AR9344 rev 2) => C'est celui que j'utilisais cette nuit contrairement à ce que je racontais dans mon post nocturne ... plus les yeux en face des trous à cette heure là
- Un Fritz!Box 4040 (IPQ4018) connu pour avoir des soucis de VLAN (d'ou les premiers tests avec l'Atheros) avec un OpenWRT patché (trouvé là: https://forum.openwrt.org/t/build-for-fritzbox-4040-switch-and-luci-working/68996)
Côté tcpdump en effet ça ce content d'essayer de sortir, rien ne rentre sur l'interface:
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0.832, link-type EN10MB (Ethernet), capture size 262144 bytes
13:34:39.985160 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from fc:ec:da:7c:b8:32, length 354
13:34:40.006445 IP 172.16.0.1.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 304
13:34:40.084586 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from fc:ec:da:7c:b8:32, length 366
13:34:40.292891 IP 172.16.0.1.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 304
13:34:56.686559 IP6 fe80::feec:daff:fe7c:b832.546 > ff02::1:2.547: dhcp6 solicit
13:36:55.726565 IP6 fe80::feec:daff:fe7c:b832.546 > ff02::1:2.547: dhcp6 solicit
13:38:58.616537 IP6 fe80::feec:daff:fe7c:b832.546 > ff02::1:2.547: dhcp6 solicit
13:39:40.193208 ARP, Request who-has 172.16.184.50 tell 172.16.0.1, length 42
13:39:40.194397 ARP, Reply 172.16.184.50 is-at fc:ec:da:7c:b8:32, length 28
13:41:01.486525 IP6 fe80::feec:daff:fe7c:b832.546 > ff02::1:2.547: dhcp6 solicit
13:43:09.486503 IP6 fe80::feec:daff:fe7c:b832.546 > ff02::1:2.547: dhcp6 solicit
13:44:50.193906 ARP, Request who-has 172.16.184.50 tell 172.16.0.1, length 42
13:44:50.194755 ARP, Reply 172.16.184.50 is-at fc:ec:da:7c:b8:32, length 28
13:45:07.246527 IP6 fe80::feec:daff:fe7c:b832.546 > ff02::1:2.547: dhcp6 solicit
13:47:05.006603 IP6 fe80::feec:daff:fe7c:b832.546 > ff02::1:2.547: dhcp6 solicit
13:48:57.644814 IP6 fe80::feec:daff:fe7c:b832.546 > ff02::1:2.547: dhcp6 solicit
13:50:00.192832 ARP, Request who-has 172.16.184.50 tell 172.16.0.1, length 42
13:50:00.192951 ARP, Reply 172.16.184.50 is-at fc:ec:da:7c:b8:32, length 28
13:51:10.766534 IP6 fe80::feec:daff:fe7c:b832.546 > ff02::1:2.547: dhcp6 solicit
Même comportement quand j'ai essayé de faire la config sur le Fitz!box 4040 ce matin.... soit j'ai pas d'bol avec mon matos, soit je suis le maillon faible ;D
Voilà la conf du N750 de cette nuit jointe.
Merci encore pour le coup de main
Hervé
EDIT:
PS: j'ai une chinoiserie sur la route, un petit routeur 2 ports X86_64 AES_NI à base de J3160. Je voulais commencer à me roder avec mon matériel existant avant de mettre le J3160 en place après réception
-
Perso je suis surpris par ça:
13:34:39.985160 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from fc:ec:da:7c:b8:32, length 354
13:34:40.006445 IP 172.16.0.1.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 304
13:34:40.084586 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from fc:ec:da:7c:b8:32, length 366
13:34:40.292891 IP 172.16.0.1.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 304
Je ne vois pas dans quelles circonstances (chez Orange) un serveur DHCP/BOOTP avec une IP privée pourrait répondre sur le VLAN 832...
-
edit: j'avais laissé ma rep en suspens avant de voir le post de zoc
Sur la trace on voit bien du flux entrant.
Le serveur dhcp 172.16.0.1 qui attribue l'ip 172.16.0.50 à ton routeur (au vue du dialogue arp suite à l'échange dhcp), faudra élucider d’où sa vient, mais j'ai déja eu/vue des cas similaire quand la requête ne partait pas avec la bonne prio !
Faudrait regarder la mac correspondant à 172.16.0.1 pour l'enquete :p
Possible de récupérer un pcap en mp de la trace ?
T'as pu essayer de lancer le script après le boot ? et relancer l'interface ?
J'ai regardé rapidement ton /etc , ça à l'air ok, t'as bien tous les packages requis ?
-
put... de bor.... de me.....
Je mérite le totem de la chèvre bien comme il faut.
J'avais connement mis un '\' au lieu d'un '/' dans echo -n 'fti/xxxxxxx' | xxd -p
J'ai du vérifier ça 40 fois cette nuit
Mais quand on voit la différence entre ces 2 sorties ça m'a pas franchement aidé à trouver:
root:~# echo -n fti/xxxxxxx | xxd -p
6674692f78787878787878
root:~# echo -n fti\xxxxxxx | xxd -p
66746978787878787878
Pour le coup j'écris ce post avec le routeur OpenWRT fonctionnel à la place de la Livebox ;D
désolé de vous avoir embêtés pour une bêtise comme celle là
et merci encore pour le coup de main !!!
Le boulet du jour
Et au fait la MAC "fc:ec:da:7c:b8:32" qui remontait dans le tcpdump est une de celle du fichier de conf proposé en téléchargement sur le premier post ... provenance Ubiquiti :P
FC-EC-DA (hex) Ubiquiti Networks Inc.
FCECDA (base 16) Ubiquiti Networks Inc.
2580 Orchard Pkwy
San Jose CA 95131
US
Maintenant que ça marche je vais pouvoir remettre mes propres MAC et faire marcher le reste
@+.
RV.
-
put... de bor.... de me.....
Je mérite le totem de la chèvre bien comme il faut.
J'avais connement mis un '\' au lieu d'un '/' dans echo -n 'fti/xxxxxxx' | xxd -p
J'ai du vérifier ça 40 fois cette nuit
Mais quand on voit la différence entre ces 2 sorties ça m'a pas franchement aidé à trouver:
root:~# echo -n fti/xxxxxxx | xxd -p
6674692f78787878787878
root:~# echo -n fti\xxxxxxx | xxd -p
66746978787878787878
Pour le coup j'écris ce post avec le routeur OpenWRT fonctionnel à la place de la Livebox ;D
désolé de vous avoir embêtés pour une bêtise comme celle là
et merci encore pour le coup de main !!!
Le boulet du jour
Et au fait la MAC "fc:ec:da:7c:b8:32" qui remontait dans le tcpdump est une de celle du fichier de conf proposé en téléchargement sur le premier post ... provenance Ubiquiti :P
FC-EC-DA (hex) Ubiquiti Networks Inc.
FCECDA (base 16) Ubiquiti Networks Inc.
2580 Orchard Pkwy
San Jose CA 95131
US
Maintenant que ça marche je vais pouvoir remettre mes propres MAC et faire marcher le reste
@+.
RV.
Pas de soucis ! Du coup on aura appris que quand tu envoies une mauvaise auth tu peux recevoir une ip privée x)
C'était pas cette mac que je voulais, on voit bien en effet sur la trace que la requete dhcp (client, ton routeur) est faite depuis cette mac.
Il aurait fallu faire un
arp -a | grep 172.16.0.1
Pour voir la correspondance 172.16.0.1/mac (celle du serveur dhcp). Mais bon pas grave^^
-
@ubune
Bonsoir ubune,
Merci pour ton tuto.
Ayant depuis plusieurs années remplacé mes livebox(s) par un Ubiquiti EdgeRouter Lite 3 ERLite-3 sous edgeOS, et ayant lu ton post sur le remplacement de la livebox par des routeurs en openwrt. J'ai eu envie de faire le remplacement de la livebox par un Raspberry pi4 sous OpenWrt en lisant cet article : https://www.zahradnik.io/raspberry-pi-as-a-home-router. Par avoir simplement une idée des perfs avec cette petite bête (mon ubiquiti me convient toujours parfaitement)
Je suis en train de tester ton tuto sur un raspberry pi4 4go de raw avec OpenWrt : (ça ressemble à mon edgeOS , c'est du debian) et j'ai un adaptateur USB3RJ45 pour faire mon port WAN avec un convertisseur FTTH-cuivre...
Salut Bulle21 !
Désolé en relisant les dernières pages du topic je viens de voir ton post (qui était passé à la trappe).
Félicitations pour ton installation sur Raspberry ! Toujours content avec ?
Je vais ajouter un lien direct vers ton post pour les amoureux de la framboise.
Concernant uhttpd il est installé avec luci, en revanche je vais ajouter l'installation de xxd dans le tuto, merci pour le retour.
A bientôt ;)
-
Super, merci bcp. Je n'ai fait que de l'adaptation grâce à ton super boulot. Pas de réponse, je me suis dit "il aime pas les framboises ???"
Concernant uhttpd je crois avoir constaté qu'il n'est pas installé dans la seule version de l'image fournie par le site d'OpenWRT pour le PI4.
Depuis, suis repassé sur mon ERLITE3 et je l'ai migré en full IPV6 avec les tutos du site... je préfère le fanless.
Je me prepare à faire un saut vers Bouygues ou Free pour rentabiliser mon FTTH 8). J'espere que les parametrages sur erlite3 / openWRT seront aussi bien décrits sur ce site.
-
Bonjour, a ce jour, le guide a cessé de fonctionner, mon wrt3200 a fonctionné correctement jusqu'à hier mais à partir d'aujourd'hui plus d'adresse ip, zéro connexion
Si je remets la livebox 5 derrière l'ONT, tout fonctionne normalement, mais l'openwrt ne fonctionne plus.
Je n'ai rien changé du tout à la configuration, j'ai même essayé de faire une réinitialisation d'usine et de suivre le guide, mais rien.
Est-ce que quelqu'un a le même problème ?
Merci!
-
ça marche toujours par chez moi
Je reboot le routeur pour voir et si réponse dans 2 minutes c'est que ça marche toujours
:o
-
bah ça roule toujours
-
bah ça roule toujours
Il a finalement réussi à se fixer tout seul...
Bizarre :o
-
Peut-être une maintenance quelque part
ou un voisin en cours de raccordement avec un petit effet de bord sur ta connexion
va savoir
-
Une petite info pour ceux que ça intéresseraient avec un petit soucis de release du bail IPv4 sous OpenWRT 20 (snapshot).
J'ai remplacé le routeur Fritz!box avec ces vlan capricieux qui perdait le LAN tous les 2/3 jours (fatalement quand tu es en réunion/visio avec les collègues !!) par un mini-pc fanless x86_64 à base de Celeron N3160 (AES_NI) équipé de 2 nic Realtek RTL8111 et un msata de 32Go.
Ces petites machines sont en UEFI, j'ai donc dû installer une version snapshot de OpenWRT donc en 20.x, seules builds proposant l'UEFI de ce que j'en sais.
Aucun soucis pour l'install (je fais court/facile si ça peut aider quelqu'un):
- clé USB avec GPARTED Live (j'ai fait avec etcher)
- 2eme clé usb (fat32 ou ntfs) avec l'image OpenWRT dessus décrompressée avant (7zip fait des erreurs, gunzip sous Linux aussi, mais aucun soucis avec WinRAR) => prendre la snapshot generic-ext4-combined-efi.img.gz
- on boot sur la clé GPARTED et on laisse aller jusqu'à l'interface graphique, on laisse l'utilitaire gparted ouvert, on va s'en servir ensuite
- on ouvre un shell en tant que root dans l'interface graphique (sudo su , pas besoin de mot de passe)
- on insère puis monte la 2ème clef, sdc dans mon cas => (mkdir /mnt/sdc1 puis mount /dev/sdc1 /mnt/sdc1)
- on pousse l'image d'OpenWRT avec dd sur le disque du mini-pc => /dev/sda chez moi: dd if=/mnt/sdc1/image_wrt.img of=/dev/sda bs=8M status=progress
- on repasse sur l'utilitaire GPARTED dont on rafraichit l'affichage, on aggrandi la dernière partition du disque de la machine (+ de 30Go de libre pour installer des packages OpenWRT ... y'a d'quoi faire !)
- on éteind, on vire les clé USB, on boot sur OpenWRT avec la pate WAN branchée sur le LAN fonctionnel
- on installe les premiers packages nécessaires depuis la console (luci n'est pas installé par défaut sur les snapshot):
opkg update
opkg install luci iptables-mod-ipopt igmpproxy ip-full etc...
et on est prêt pour la config permettant de faire fonctionner la machine sur le réseau Orange.
Avec un stockage plus robuste que ce qui est fourni dans les petits routeurs du commerce on peut ensuite changer plein de choses dans OpenWRT au besoin pour profiter du stockage persistant
Par contre, version snapshot oblige, il faut se dépêcher d'installer tous les packages que l'on veut au plus vite, dès le lendemain les dépendances sont à moitié cassées puisque tout est recompilé toutes les nuits.
Je n'ai eu qu'un soucis, avec la même config que celle donnée ici le routeur changeait d'IP à chaque manip sur la carte WAN et à chaque redémarrage de la machine.
très pénible.
Pour indiquer à udhcpc de ne pas faire de release du bail à chaque reload de l'interface ou redémarrage du routeur j'ai dû simplement rajouter ça dans le /etc/config/network dans la section wan:
option norelease '1'
J'ai rechargé l'interface quarante fois avant d'obtenir une IPv4 publique qui me plaisait avant de mettre cette option en place ;D ;D ;D
En fait c'est plutôt étrange que cette config n'ai pas été nécessaire dès OpenWRT 18 ou avant, car ce serait plus conforme aux RFC (qui précisent que le bail doit être libéré à chaque arrêt ou relance de l'interface, d'ailleurs la Livebox est conforme sur ce point, si reboot elle change d'IP, c'est bien précisé par Orange je ne sais plus ou, pour ne pas renouveller l'IP il faut débrancher la prise de courant et ne pas faire de reboot depuis l'interface. Si on VEUT changer d'IP alors il suffit de rebooter via l'interface, ce qui indique bien qu'elle va lâcher son bail auprès du serveur DHCP)
Voilà
Cdt
Hervé
-
J'ai rechargé l'interface quarante fois avant d'obtenir une IPv4 publique qui me plaisait avant de mettre cette option en place ;D ;D ;D
;D 8)
-
Bonjour,
J'ai depuis hier soir (et un reboot du router), moi aussi un soucis pour obtenir mon adresse IP.
Tout fonctionnait bien jusque là avec mon router Linksys EA8300 sous openwrt 19.07. (J'avais dailleurs bien galéré pour avoir un setup fonctionnel car ce routeur est tres capricieux sur le tag des cpu.)
Il est possible que jai update des packages entre les reboot. Je ne sais pas si ca peut avoir un incidence.
Je vous met en pièce jointe ma config + le pcap (tcpdump -ni eth1.832 -w capture-debug.pcap)
Mon ifconfig:
root@OpenWrt:~# ifconfig
br-lan Link encap:Ethernet HWaddr C4:41:1E:23:63:E7
inet addr:192.168.1.1 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: fe80::c641:1eff:fe23:63e7/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:534 errors:0 dropped:0 overruns:0 frame:0
TX packets:99 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:62409 (60.9 KiB) TX bytes:13772 (13.4 KiB)
eth0 Link encap:Ethernet HWaddr C4:41:1E:23:63:E7
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:564 errors:0 dropped:14 overruns:0 frame:0
TX packets:131 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:72364 (70.6 KiB) TX bytes:21627 (21.1 KiB)
eth1 Link encap:Ethernet HWaddr C4:41:1E:23:63:E8
inet6 addr: fe80::c641:1eff:fe23:63e8/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:249 errors:0 dropped:2 overruns:0 frame:0
TX packets:51 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:32726 (31.9 KiB) TX bytes:14566 (14.2 KiB)
eth1.832 Link encap:Ethernet HWaddr C4:41:1E:23:63:E8
inet6 addr: fe80::c641:1eff:fe23:63e8/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:247 errors:0 dropped:0 overruns:0 frame:0
TX packets:44 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:29031 (28.3 KiB) TX bytes:13740 (13.4 KiB)
ifb4eth1.832 Link encap:Ethernet HWaddr 26:F5:37:B0:8A:12
inet6 addr: fe80::24f5:37ff:feb0:8a12/64 Scope:Link
UP BROADCAST RUNNING NOARP MTU:1500 Metric:1
RX packets:229 errors:0 dropped:0 overruns:0 frame:0
TX packets:229 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:32
RX bytes:29952 (29.2 KiB) TX bytes:29952 (29.2 KiB)
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:272 errors:0 dropped:0 overruns:0 frame:0
TX packets:272 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:21984 (21.4 KiB) TX bytes:21984 (21.4 KiB)
wlan0 Link encap:Ethernet HWaddr C6:41:1E:23:63:EB
inet6 addr: fe80::c441:1eff:fe23:63eb/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:269 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:39182 (38.2 KiB)
wlan1 Link encap:Ethernet HWaddr C4:41:1E:23:63:E9
inet6 addr: fe80::c641:1eff:fe23:63e9/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:32 errors:0 dropped:0 overruns:0 frame:0
TX packets:335 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:7892 (7.7 KiB) TX bytes:55476 (54.1 KiB)
mon ifstatus wan
root@OpenWrt:~# ifstatus wan
{
"up": false,
"pending": true,
"available": true,
"autostart": true,
"dynamic": false,
"proto": "dhcp",
"device": "eth1.832",
"data": {
}
}
En remontant la page 23, j'ai vu le soucis de l'authent sur la personne et ce fameux server:
23:55:31.011296 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from c4:41:1e:23:63:e8, length 365
23:55:31.039476 IP 172.16.0.1.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 304
Je confirme bien que mon authent était ok comme ca fonctionnait avant...
Avec la livebox play, tout roule.
Merci de votre aide si possible.
-
Tes fichiers vlanprio et firewall.user sont bien créés ?
ils n'ont pas été écrasés par quoi que ce soit, avec les bons droits ? (la dernière fois pour moi j'avais oublié de remettre le bon nom des interfaces eth0.832 vs eth1.832 compte tenu de la conf de mon routeur)
-
Je regarderai toutes les pistes ce soir, cet apres midi je ne vais pas pouvoir me déconnecter. Je vous tiendrai au courant. Merci pour l'aide en tout cas :)
-
Bon... petit update,
Le fichier firewall.user et rc.local semblait correct.
J' ai reset openwrt (10sec reset button) puis refait le tuto -- vous l'aviez compris -- je m'arrete a l'ipv6 car je n'ai pas le decodeur TV.
Bahhh ca fonctionne nickel ipv4 + ipv6. :o
Je soupsonne la mise a jour des packets via opkg qui a du mal se passer. Jai dailleurs remis a jour, et ca a re-planté...
Notamment le pkg firewall 2019-11-22-8174814a-1 vers 2019-11-22-8174814a-2 ...
Je mettrai uniquement a jour les packets dont j'ai besoin d'avoir une maj ... Un vieux toc de toujours vouloir mes packages a jour ... :'(
Comment vous gérez les updates vous ?
-
Content que ça remarche pour toi.
Je me suis posé la même question il y a peu (en ayant tout pété juste après une MAJ).
Sur le forum OpenWRT ils déconseillent assez formellement de mettre à jour ton OpenWRT, ils sont plutôt à conseiller d'attendre la release suivante et de le réinstaller à ce moment là.
Les raisons invoquées sont:
- ça bouffe toute la place sur le peu de dispo dans les ROM des petits routeurs
- ça pète facilement les nombreuses dépendances entre les différents paquets (ce qui semble avoir été ton cas)
Donc pour le coup j'ai un peu du mal à comprendre pourquoi ils proposent un mode de mise à jour des packages unitaires depuis l'interface ????
Dans mon cas très particulier (routeur à base de mini-PC X86_64 UEFI ce qui impose une version snapshot) c'est encore pire, les dépendances sont pétées dès le lendemain du build que tu viens de télécharger .... pas cool.
On va dire que ça fait parti des nombreuses interrogations ou incompréhensions que j'ai à l'égard de cette distri, mais pour en avoir essayé quelques autres ces derniers temps j'ai fini par revenir sur celle là.
Quasiment toutes les distri linux axées routeur/firewall sont en train de se laisser crever et (ou bien "car" à la place de "et" ??) pratiquement aucune ne supporte l'IPv6, même Clearos avec le mastodonte HP derrière lui ne le supporte pas du tout encore.
En gros il reste OpenWRT, OPNSense, PfSense ... et celles dont je n'ai pas connaissance (J'ai épluché ce qui venait de là: https://en.wikipedia.org/wiki/List_of_router_and_firewall_distributions j'ai oublié de détailler DD-WRT) et j'ai trouvé qu'OpenWRT, même si pas 100% satisfaisante à mon goût, était au final la meilleure sur l'IPv6 ... un comble de voir un si mauvais support sur ce point pour un OS/noyau qui se veut à la pointe côté réseau sur une techno plus si nouvelle que ça ! .... Windows 95 avait déjà eu le droit au support de l'IPv6 ... et Windows 10 n'a un support vraiment complet que depuis assez peu de temps.
Paradoxalement tous les équipements de routage commerciaux (même grand publique type Netgear, Zyxel, Ubiquiti ....) ont un support très correct de l'IPv6.
Pour moi la plus grosse lacune qui dessert franchement OpenWRT c'est le manque de doc bien faite et à peu près maintenue.
Ce machin sait pratiquement tout faire, avec des options et possibilités hallucinantes, sauf que pour réussir à connaitre ces options et possibilités il faut aller décortiquer le code source de chaque package dans github .... la loose !
La doc n'est qu'un recensement (vieillissant !) d'exemples (plus à jours) de comment faire pour faire marcher "ceci" ou "cela" d'une façon basique et commune. Mais nul part (ou trop peu) n'est détaillé correctement le fonctionnement de chaque package avec une description des options.
En gros il manque un bon ... man .... pour chaque package.
Pour aller au bout de ma pensée, vu que je suis maintenant carrément hors sujet autant poursuivre 8), c'est le comportement des "sachants" sur le forum OpenWRT qui m'a poussé à chercher à aller voir ailleurs (pour y revenir donc), tu viens avec une question car tu te casses les dents depuis 2 ou 3 jours sur un point précis, tu as essayé de faire marcher, tu y a passé du temps, tu as creusé le sujet et au bout d'un moment tu poses la question.
La réponse est souvent la même: oh là là malheureux, fallait pas faire comme ça c'est du n'importe quoi, t'as rien compris, c'est tout simple pourtant fais comme ça tu devrais déjà le savoir.
Et le "comment faire" que ce gentil "sachant" te délivre sur le forum est 95% du temps soit incompréhensible, soit incomplet, soit foireux
Sauf que:
- le comment faire n'est dans aucune doc, aucun tuto donc en toutes bonne fois il était impossible de trouver cette info autrement (bon exemple que celui de ces mises à jour)
- la journée je suis ingé infra/virtu ... et pas ingé réseau (et je compati pour les bons pères de familles qui ne trempent pas du tout dans l'informatique et qui veulent essayer tout de même d'avoir un réseau propre/maitrisé à la maison !!!)
- le soir je suis Papa/conjoint ... autre chose à foutre que de passer 23h30 par jour à creuser un sujet aussi particulier que OpenWRT ... j'ai plus 20 piges avec que ça à foutre de mes journées
- le WE, quand j'ai un peu de temps et qu'il me reste un petit rabiot de budget j'essaye de retaper un avion (comme d'autres retapent des caisses, des motos ou des bateaux)
- mais que malgré tout je ne veux pas d'un routeur avec un OS du commerce rempli de failles ou de backdoors (Asus, D-Link, TP-Link and Co, même combat, je laisse les curieux trouver l'info)
ouala, désolé je me suis lâché .... ça va mieux merci :-X
-
ouala, désolé je me suis lâché .... ça va mieux merci :-X
Ahahah merci pour les infos, je partage complètement ton avis!!
D'un coté quel bonheur de remplacer cette shitbox -- euh LIVEbox ! D'avoir un loopback fonctionnel, de choisir ses propres DNS, d'avoir un wifi décent...
De l'autre, quelle épreuve !!
Par exemple sur mon Linksys EA8300 - que j'ai choisis apres avoir trouvé ce sujet, et m'être assuré qu'il support openwrt 19.07 out of the box + une belle promo je me lance!
L'install openwrt comme prevu, j'upload le firmware via la GUI, ca l'install sur une deuxieme partition (le stock firmware reste installé si ca merde). Genial.
Je commence le TUTO et là ca se complique pour le split des VLANs !
Le tag, je sais plus pour quelle raison (les details sont là: https://forum.openwrt.org/t/ipq40xx-switch-config-strangeness/32542/7), je dois tag 0t et 5t (5t étant invisible dans l'interface de luci pour mon cas... mais ca marche dans /etc/config/network).
Deuxième chose où j'ai bien mis 2jours avant de croire en la solution: Ce petit routeur n'accepte que le split des VLANs avec un vlan id (interne) > 100 - INCOMPREHENSIBLE.
Du coup au final ca me donne ca:
config switch_vlan
option device 'switch0'
option vlan '1'
option ports '1 2 3 4 0'
config switch_vlan
option device 'switch0'
option vlan '101'
option vid '832'
option ports '0t 5t'
Ce que je comprend pas c'est qu'aucun constructeur ne se mettent d'accord sur les interfaces etc...
J'ai réussi a m'en sortir car je suis aussi ingénieur (logiciel pour ma part) et que je sais chercher ce genre de chose comme tu l'expliques sur les tutos, github etc...
En tout cas un grand merci a Ubune pour avoir EXPLIQUÉ les modifications à effectuer en + de les décrire. Ca m'a permis de comprendre ce que je faisais et de corriger les diffs à faire a cause de mon routeur.
Allez bon courage à tout ceux qui lisent ceci, vous allez y arriver !! :D
-
Bonjour,
Tout d'abord, merci pour ce tutoriel, tout fonctionne parfaitement en suivant les instructions, j'arrive à voir internet sur mon router Linksys mr8300 avec la SNAPSHOT r14985-4d4ef1058c (ce modèle n'est pas disponible dans la dernière release). J'ai suivi exactement les steps du premier post avec exactement la même config pour le switch_vlan, aucune idée de si je devais modifier ou non les ports.
Mais dès que j'essaye d'activer le wifi (peut importe que ce soit le 5GHz ou le 2.4GHz), tout se coupe, je n'ai plus accès à l'internet, ca timeout. Si jamais je redémarre l'interface wan, celle-ci ne se re-connecte plus au réseau orange.
Je ne sais pas trop où chercher les informations ou même ou trouver des logs m'indiquant avec + de précisions le problème, les seuls logs que j'ai pu trouver sont ceux accessibles via la commande `readlog` et les voici:
Sun Nov 22 00:55:10 2020 daemon.info dnsmasq[8038]: using nameserver 80.10.246.136#53
Sun Nov 22 00:55:10 2020 daemon.info dnsmasq[8038]: using nameserver 81.253.149.6#53
Sun Nov 22 00:55:10 2020 daemon.info dnsmasq[8038]: read /etc/hosts - 4 addresses
Sun Nov 22 00:55:10 2020 daemon.info dnsmasq[8038]: read /tmp/hosts/odhcpd - 0 addresses
Sun Nov 22 00:55:10 2020 daemon.info dnsmasq[8038]: read /tmp/hosts/dhcp.cfg01411c - 1 addresses
Sun Nov 22 00:55:10 2020 daemon.info dnsmasq-dhcp[8038]: read /etc/ethers - 0 addresses
Sun Nov 22 00:59:13 2020 daemon.notice netifd: radio0 (9609): sh: out of range
Sun Nov 22 00:59:13 2020 daemon.notice netifd: radio0 (9609): sh: out of range
Sun Nov 22 00:59:13 2020 daemon.notice netifd: radio0 (9609): sh: out of range
Sun Nov 22 00:59:13 2020 daemon.notice netifd: radio0 (9609): sh: out of range
Sun Nov 22 00:59:13 2020 daemon.notice netifd: radio0 (9609): sh: out of range
Sun Nov 22 00:59:13 2020 daemon.notice hostapd: Configuration file: /var/run/hostapd-phy0.conf (phy wlan0) --> new PHY
Sun Nov 22 00:59:15 2020 kern.warn kernel: [ 1590.606606] ath10k_pci 0000:01:00.0: unsupported HTC service id: 1536
Sun Nov 22 00:59:15 2020 kern.warn kernel: [ 1590.606975] ath10k_pci 0000:01:00.0: 10.4 wmi init: vdevs: 16 peers: 48 tid: 96
Sun Nov 22 00:59:15 2020 kern.warn kernel: [ 1590.612136] ath10k_pci 0000:01:00.0: msdu-desc: 2500 skid: 32
Sun Nov 22 00:59:16 2020 kern.info kernel: [ 1590.667738] ath10k_pci 0000:01:00.0: wmi print 'P 48/48 V 16 K 144 PH 176 T 186 msdu-desc: 2500 sw-crypt: 0 ct-sta: 0'
Sun Nov 22 00:59:16 2020 kern.info kernel: [ 1590.669010] ath10k_pci 0000:01:00.0: wmi print 'free: 114572 iram: 12804 sram: 29508'
Sun Nov 22 00:59:16 2020 kern.warn kernel: [ 1591.003510] ath10k_pci 0000:01:00.0: Firmware lacks feature flag indicating a retry limit of > 2 is OK, requested limit: 4
Sun Nov 22 00:59:16 2020 kern.info kernel: [ 1591.015040] br-lan: port 2(wlan0) entered blocking state
Sun Nov 22 00:59:16 2020 kern.info kernel: [ 1591.015082] br-lan: port 2(wlan0) entered disabled state
Sun Nov 22 00:59:16 2020 daemon.notice hostapd: Frequency 5500 (primary) not allowed for AP mode, flags: 0x301979 RADAR
Sun Nov 22 00:59:16 2020 daemon.err hostapd: Primary frequency not allowed
Sun Nov 22 00:59:16 2020 daemon.warn hostapd: wlan0: IEEE 802.11 Configured channel (100) or frequency (5500) not found from the channel list of the current mode (2) IEEE 802.11a
Sun Nov 22 00:59:16 2020 daemon.warn hostapd: wlan0: IEEE 802.11 Hardware does not support configured channel
Sun Nov 22 00:59:16 2020 daemon.err hostapd: Could not select hw_mode and channel. (-3)
Sun Nov 22 00:59:16 2020 daemon.notice hostapd: wlan0: interface state UNINITIALIZED->DISABLED
Sun Nov 22 00:59:16 2020 daemon.notice hostapd: wlan0: AP-DISABLED
Sun Nov 22 00:59:16 2020 daemon.err hostapd: wlan0: Unable to setup interface.
Sun Nov 22 00:59:16 2020 daemon.notice hostapd: nl80211: deinit ifname=wlan0 disabled_11b_rates=0
Sun Nov 22 00:59:16 2020 kern.info kernel: [ 1591.019992] device wlan0 entered promiscuous mode
Sun Nov 22 00:59:16 2020 kern.info kernel: [ 1591.070643] device wlan0 left promiscuous mode
Sun Nov 22 00:59:16 2020 kern.info kernel: [ 1591.072132] br-lan: port 2(wlan0) entered disabled state
Sun Nov 22 00:59:16 2020 kern.warn kernel: [ 1591.120453] ath10k_pci 0000:01:00.0: peer-unmap-event: unknown peer id 0
Sun Nov 22 00:59:16 2020 daemon.notice hostapd: wlan0: CTRL-EVENT-TERMINATING
Sun Nov 22 00:59:16 2020 daemon.err hostapd: hostapd_free_hapd_data: Interface wlan0 wasn't started
Sun Nov 22 00:59:16 2020 daemon.notice netifd: radio0 (9609): Command failed: Invalid argument
Sun Nov 22 00:59:19 2020 kern.warn kernel: [ 1594.416778] ath10k_pci 0000:01:00.0: unsupported HTC service id: 1536
Sun Nov 22 00:59:19 2020 kern.warn kernel: [ 1594.417260] ath10k_pci 0000:01:00.0: 10.4 wmi init: vdevs: 16 peers: 48 tid: 96
Sun Nov 22 00:59:19 2020 kern.warn kernel: [ 1594.422266] ath10k_pci 0000:01:00.0: msdu-desc: 2500 skid: 32
Sun Nov 22 00:59:19 2020 kern.info kernel: [ 1594.477741] ath10k_pci 0000:01:00.0: wmi print 'P 48/48 V 16 K 144 PH 176 T 186 msdu-desc: 2500 sw-crypt: 0 ct-sta: 0'
Sun Nov 22 00:59:19 2020 kern.info kernel: [ 1594.478572] ath10k_pci 0000:01:00.0: wmi print 'free: 114572 iram: 12804 sram: 29508'
Sun Nov 22 00:59:20 2020 kern.warn kernel: [ 1594.812014] ath10k_pci 0000:01:00.0: Firmware lacks feature flag indicating a retry limit of > 2 is OK, requested limit: 4
Sun Nov 22 00:59:20 2020 kern.info kernel: [ 1594.930566] br-lan: port 2(wlan0) entered blocking state
Sun Nov 22 00:59:20 2020 kern.info kernel: [ 1594.930643] br-lan: port 2(wlan0) entered disabled state
Sun Nov 22 00:59:20 2020 kern.info kernel: [ 1594.935958] device wlan0 entered promiscuous mode
Sun Nov 22 00:59:20 2020 kern.info kernel: [ 1595.416755] ath10k_pci 0000:01:00.0: NOTE: Firmware DBGLOG output disabled in debug_mask: 0x10000000
J'active le wifi depuis l'interface LUCI à partir de Sun Nov 22 00:59:13 2020.
Merci d'avance.
-
Bonjour,
Ca fait plusieurs mois que je regarde pour virer ma livebox 4 (sosh) par un routeur. J'ai pris le R7800 spécifiquement pour ça ^^
En revanche je suis en VDSL. Je voudrais savoir si ce tuto est compatible avec cette techno, car le jour où j'aurais la fibre n'est pas encore arrivé! :S
Merci d'avance!
-
oui c'est possible si tu es en vdsl avec un bt home hub 5
cordialement
-
Hello,
Quand j'essaye d'utiliser la dernière version en date d'OpenWRT (19.07.5) avec mon Linksys mr8300 (j'utilise l'image de ea8300), le tutoriel ne semble pas fonctionner. Est-ce que quelqu'un à tester avec cette version? Ou ces modèles? (Linksys mr8300 / ea8300)
Merci
-
Bonsoir à tous !
Déjà, un grand merci à tous les contributeurs de ce tuto, sa version Tomato m'avait méchamment dépanné lors de l'installation de mon Netgear R7000 sur ma ligne toulousaine.
MAIS, et c'est là le drame, j'ai enfin la fibre dans la maison de famille en charente. Tout heureux, je sors mon Netgear R7800 acheté pour l'occasion, le flash sous OpenWRT 19.07.05, suis le tuto (juste une inversion eth1 et eth0 pour s'adapter au routeur), mais rien, nada, tout ce que je chope, c'est la fameuse ip en 172.16.1.1...
J'ai tenté en 19.07.02, et même en 18.06.02, rien à faire, et j'ai beau tout checker, je ne trouve aucune anomalie dans ma config. Là, j'avoue que je sèche, et j'aurai bien besoin d'aide ???
Mes infos :
Sosh Fibre en 300/300 via ONT et Livebox 3 Play
Config uniquement internet, je gère la box pour le tel à part via un switch manageable
La conf network (avec le FTI masqué, bien entendu), et la conf lan est adaptée de façon à utiliser l'internet existant pour le download des paquets, etc :
config interface 'loopback'
option ifname 'lo'
option proto 'static'
option ipaddr '127.0.0.1'
option netmask '255.0.0.0'
config globals 'globals'
config interface 'lan'
option type 'bridge'
option ifname 'eth1.1'
option proto 'static'
option ipaddr '192.168.0.10'
option netmask '255.255.255.0'
option ip6assign '64'
option delegate '0'
option gateway '192.168.0.2'
option dns '1.1.1.1'
config interface 'wan'
option ifname 'eth0.832'
option proto 'dhcp'
option broadcast '1'
option vendorid 'sagem'
option reqopts '0x01 0x15 0x28 0x51 0x58 0x59 0x90'
option sendopts '77:2b46535644534c5f6c697665626f782e496e7465726e65742e736f66746174686f6d652e4c697665626f7834 90:00000000000000000000001a0900000558010341010dXXXXXXXXXXX'
config interface 'wan6'
option ifname 'eth0.832'
option proto 'dhcpv6'
option reqprefix 'auto'
option reqaddress 'none'
option defaultreqopts '0'
option sendopts '11:00000000000000000000001a0900000558010341010dXXXXXXXXXX 15:FSVDSL_livebox.Internet.softathome.livebox4 16:0000040e0005736167656d'
option reqopts '11 17 23 24'
option noclientfqdn '1'
option noacceptreconfig '1'
config switch
option name 'switch0'
option reset '1'
option enable_vlan '1'
config switch_vlan
option device 'switch0'
option vlan '1'
option vid '1'
option ports '1 2 3 4 6t'
config switch_vlan
option device 'switch0'
option vlan '2'
option ports '0t 5t'
option vid '832'
firewall
config defaults
option syn_flood '1'
option input 'DROP'
option output 'DROP'
option forward 'DROP'
config zone
option name 'lan'
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'ACCEPT'
option network 'lan'
config zone
option name 'wan'
option output 'ACCEPT'
option masq '1'
option input 'DROP'
option forward 'DROP'
option network 'wan'
option family 'ipv4'
config zone
option name 'wan6'
option input 'DROP'
option forward 'DROP'
option network 'wan6'
option family 'ipv6'
option output 'ACCEPT'
config forwarding
option dest 'wan6'
option src 'lan'
config forwarding
option dest 'wan'
option src 'lan'
config include
option path '/etc/firewall.user'
config rule
option name 'Allow-DHCP-Renew'
option src 'wan'
option proto 'udp'
option dest_port '68'
option target 'ACCEPT'
option family 'ipv4'
config rule
option name 'Allow-Ping'
option src 'wan'
option proto 'icmp'
option icmp_type 'echo-request'
option family 'ipv4'
option target 'ACCEPT'
config rule
option name 'Allow-DHCPv6'
option proto 'udp'
option src_ip 'fc00::/6'
option dest_ip 'fc00::/6'
option dest_port '546'
option family 'ipv6'
option target 'ACCEPT'
option src 'wan6'
config rule
option name 'Allow-MLD'
option proto 'icmp'
option src_ip 'fe80::/10'
option family 'ipv6'
option target 'ACCEPT'
option src 'wan6'
config rule
option name 'Allow-ICMPv6-Input'
option proto 'icmp'
option limit '1000/sec'
option family 'ipv6'
option target 'ACCEPT'
option icmp_type 'echo-reply destination-unreachable echo-request router-advertisement router-solicitation time-exceeded'
option src 'wan6'
config rule
option name 'Allow-ICMPv6-Forward'
option proto 'icmp'
option limit '1000/sec'
option family 'ipv6'
option target 'ACCEPT'
option src 'wan6'
option dest '*'
dhcp
config dnsmasq
option domainneeded '1'
option boguspriv '1'
option filterwin2k '0'
option localise_queries '1'
option rebind_protection '1'
option rebind_localhost '1'
option local '/lan/'
option domain 'lan'
option expandhosts '1'
option nonegcache '0'
option authoritative '1'
option readethers '1'
option leasefile '/tmp/dhcp.leases'
option resolvfile '/tmp/resolv.conf.auto'
option nonwildcard '1'
option localservice '1'
config dhcp 'lan'
option interface 'lan'
option start '100'
option leasetime '12h'
option ra 'server'
option limit '50'
list dns '2606:4700:4700::1001'
list dns '2606:4700:4700::1111'
config dhcp 'wan'
option interface 'wan'
option ignore '1'
config odhcpd 'odhcpd'
option maindhcp '0'
option leasefile '/tmp/hosts/odhcpd'
option leasetrigger '/usr/sbin/odhcpd-update'
option loglevel '4'
firewall.user
iptables -t mangle -A POSTROUTING -j CLASSIFY --set-class 0000:0001 ## En gros tout le flux sortant passe dans la file 1 qui est en prio 0
iptables -t mangle -A POSTROUTING -p icmp -j CLASSIFY --set-class 0000:0006 ##On passe le flux icmp dans la file 6 qui est en prio 6
iptables -t mangle -A POSTROUTING -p igmp -j CLASSIFY --set-class 0000:0006 ## On passe le flux igmp (non tv) en prio 6
#la même chose en ipv6 (avec cette fois le dhcpv6)
ip6tables -t mangle -A POSTROUTING -j CLASSIFY --set-class 0000:0001
ip6tables -t mangle -A POSTROUTING -p ipv6-icmp -j CLASSIFY --set-class 0000:0006
ip6tables -t mangle -A POSTROUTING -o eth0.832 -p udp --dport 547 -j CLASSIFY --set-class 0000:0006
ip6tables -t mangle -A POSTROUTING -p udp --dport 547 -j DSCP --set-dscp-class CS6
vlanprio.sh
#!/bin/sh
set -x
for i in 0 1 2 3 4 5 6 7; do
ip link set eth0.832 type vlan egress $i:$i >/dev/null ## Chaque file devient en priorité $numdefile
done
ip link set eth0.832 type vlan egress 1:0 >/dev/null ## La file (1) était donc en prio 1 on la repasse à 0, ça deviendra (via IPTABLES) la nouvelle file par défaut.
ip link set eth0.832 type vlan egress 0:6 >/dev/null ## Tout le flux devient en prio 6 ! sauf le flux qui passera par IPTABLES (donc juste nos requêtes dhcp)
rc.local
sleep 10
ifdown wan
sh /etc/vlanprio.sh
ifup wan
exit 0
ifstatus wan
ifstatus wan
{
"up": true,
"pending": false,
"available": true,
"autostart": true,
"dynamic": false,
"uptime": 1738,
"l3_device": "eth0.832",
"proto": "dhcp",
"device": "eth0.832",
"updated": [
"addresses",
"data"
],
"metric": 0,
"dns_metric": 0,
"delegation": true,
"ipv4-address": [
{
"address": "172.16.1.1",
"mask": 24
}
],
"ipv6-address": [
],
"ipv6-prefix": [
],
"ipv6-prefix-assignment": [
],
"route": [
],
"dns-server": [
],
"dns-search": [
],
"inactive": {
"ipv4-address": [
],
"ipv6-address": [
],
"route": [
],
"dns-server": [
],
"dns-search": [
]
},
"data": {
"leasetime": 7200
}
}
Si quelqu'un arrivait à trouver mon erreur, je lui en serais très reconnaissant :) Une histoire avec le modèle de livebox peut-être ?
Question subsidiaire, la 19.07.05 est-elle bonne à installer ? j'ai vu des retours négatifs dessus. Si non, laquelle mettre ?
Merci d'avance et bonnes fêtes à tous !
-
Salut et bonnes fêtes également !
Concernant l'ip 172.16, on a vu ça principalement quand le discover dhcp n'était pas envoyé en CS6.
J'ai parcouru rapidement ta conf ça à l'air ok, as-tu bien installé le package "ip-full" ?
Via le cli si tu essaies d'exécuter le script
sh /etc/vlanprio.sh
Qu'obtiens-tu ?
Sinon essaie de faire :
zip de ton /etc
une capture => tcpdump -ni eth0.832 port 67 or port 68 -w dhcp.pcap
M'envoyer le tout en MP.
Je n'ai pas pu tester la version 19.07.05, même si j'ai du mal à voir ce qui pourrait gener.
A+
-
Bonjour ubune ^^
Oui c'est ce que j'avais cru comprendre, mais même en lançant le script à la main, je n'ai toujours que cette ip privée qui me vient...
Oui, il est bien installé, et bien visible dans la liste des packages...
J'ai revérifié la conf je ne sais combien de fois, je suis sûr qu'il doit y avoir une coquille quelque part, mais je ne vois pas...
Via le cli ? Tu veux dire en ssh ?
Si je le lance à la main, j'ai ça :
root@OpenWrt:~# sh /etc/vlanprio.sh
+ ip link set eth0.832 type vlan egress 0:0
+ ip link set eth0.832 type vlan egress 1:1
+ ip link set eth0.832 type vlan egress 2:2
+ ip link set eth0.832 type vlan egress 3:3
+ ip link set eth0.832 type vlan egress 4:4
+ ip link set eth0.832 type vlan egress 5:5
+ ip link set eth0.832 type vlan egress 6:6
+ ip link set eth0.832 type vlan egress 7:7
+ ip link set eth0.832 type vlan egress 1:0
+ ip link set eth0.832 type vlan egress 0:6
Je t'envoie le zip et le dump par mp ;)
Là je suis en 18.06.02. Si on arrive à la faire marcher, j'essaierai à nouveau la 19.07.05 et je dirai si ça fonctionne ^^
-
Bon, après un échange avec @ubune que je remercie encore, il s'avère que mon identifiant fti a changé sur la box, allez comprendre comment...
J'en ai profité pour reflasher dans la foulée, ça fonctionne en 19.07.05 ^^
-
Super merci Datiree pour le retour ;)
Pour plus d'info sur la fameuse IP Privée obtenue :
Après analyse du dump reçu =>
Machine transmettant la réponse dhcp => 172.16.0.1 adresse MAC appartenant au constructeur Nokia ;).
Ci-joint les info que transmet le serveur dhcp.
On retrouve ce cas de figure dans les situations suivantes :
- Mauvais Identifiant utilisé.
- Requête envoyée sans la priorité L2 (cos) sur les infra Orange ou c'est nécessaire.
A+
-
Rebonjour messieurs,
Bon, je craque. Autant le routeur se connecte à internet sans problème, autant la livebox derrière pour le tel...
Pas moyen de la faire fonctionner ! (incident réseau, toussa)
J'ai pourtant suivi le tuto à la lettre
Et un tcpdump ne capte rien sur l'interface correspondante lors de son boot (eth1.832) pour ma part.
C'est la livebox play qui est capricieuse ? Ou certains settings (options DHCP ?) ne sont plus à jour dans le post de rhon ?
Merci d'avance pour votre aide !
-
Un petit retour pour confirmer que tout marche parfaitement en 19.07.06.
Testé sur un abonnement Sosh avec EdgerouterX.
;)
-
Bonjour. Merci pour ce super tuto !
Je souhaite remplacer le routeur livebox avec abonnement Sosh (sans TV) et garder la livebox comme point d'accès wifi et, si possible, pour le téléphone (on verra cette dernière partie plus tard).
Je viens de flasher mon nouveau ER-X sous openWRT ce matin. Je m'attaque à la config du réseau via le tuto. J'ai cependant une question sur les configs de prio, que j'ai peut être mal compris.
Dans le fichier vlanprio.sh, à quoi sert cette ligne :
ip link set eth1.832 type vlan egress 0:6 >/dev/null ## Tout le flux devient en prio 6 ! sauf le flux qui passera par IPTABLES (donc juste nos requêtes dhcp)
Puisque les règles iptables semblent indiquer que les requetes DHCP sortiront en prio 6 via la file 6 :
iptables -t mangle -A POSTROUTING -p icmp -j CLASSIFY --set-class 0000:0006 ##On passe le flux icmp dans la file 6 qui est en prio 6
iptables -t mangle -A POSTROUTING -p igmp -j CLASSIFY --set-class 0000:0006 ## On passe le flux igmp (celui qui part vers eth1.832) dans la file 6 qui est en prio 6
Autre question, n'ayant pas de TV, et histoire de minimiser la config, puis-je supprimer la ligne :
ip link set eth1.840 type vlan egress $i:5 >/dev/null ## tout en prio 5 sur le vlan 840
Merci.
-
Bonjour. Merci pour ce super tuto !
Je souhaite remplacer le routeur livebox avec abonnement Sosh (sans TV) et garder la livebox comme point d'accès wifi et, si possible, pour le téléphone (on verra cette dernière partie plus tard).
Je viens de flasher mon nouveau ER-X sous openWRT ce matin. Je m'attaque à la config du réseau via le tuto. J'ai cependant une question sur les configs de prio, que j'ai peut être mal compris.
Dans le fichier vlanprio.sh, à quoi sert cette ligne :
ip link set eth1.832 type vlan egress 0:6 >/dev/null ## Tout le flux devient en prio 6 ! sauf le flux qui passera par IPTABLES (donc juste nos requêtes dhcp)
Puisque les règles iptables semblent indiquer que les requetes DHCP sortiront en prio 6 via la file 6 :
iptables -t mangle -A POSTROUTING -p icmp -j CLASSIFY --set-class 0000:0006 ##On passe le flux icmp dans la file 6 qui est en prio 6
iptables -t mangle -A POSTROUTING -p igmp -j CLASSIFY --set-class 0000:0006 ## On passe le flux igmp (celui qui part vers eth1.832) dans la file 6 qui est en prio 6
Autre question, n'ayant pas de TV, et histoire de minimiser la config, puis-je supprimer la ligne :
ip link set eth1.840 type vlan egress $i:5 >/dev/null ## tout en prio 5 sur le vlan 840
Merci.
Salut !
Attention sur un ERX tu n'as pas eth1 mais uniquement eth0, y'a une config presque toute faite sur mon github si tu veux (eth0only).
Aucun soucis pour supprimer le vlan 840 si tu t'en sert pas^^
Concernant ta question, en faite le flux dhcp (v4) ne passe pas par Iptables, c'est pourquoi avec le script vlanprio.sh on map tout le flux en COS6, et ensuite avec Iptables on remet les bonnes prios.
Tout le flux qui n'est pas passé par Iptables reste donc en prio 6.
-
Salut !
Attention sur un ERX tu n'as pas eth1 mais uniquement eth0, y'a une config presque toute faite sur mon github si tu veux (eth0only).
Aucun soucis pour supprimer le vlan 840 si tu t'en sert pas^^
Merci ! Je suis déjà dessus. Ca m'aide beaucoup. J'essaye de refaire la config a la main histoire de faire progresser mes petites connaissances réseau.
J'utilise aussi le logiciel liveboxinfo pour récupérer les options à envoyer. Bien pratique pour ne pas avoir à calculer les valeurs. J'ai d'ailleurs l'impression que liveboxinfo montre plus d'options que celles que tu as listé dans github. A suivre très rapidement.
Concernant ta question, en faite le flux dhcp (v4) ne passe pas par Iptables, c'est pourquoi avec le script vlanprio.sh on map tout le flux en COS6, et ensuite avec Iptables on remet les bonnes prios.
Tout le flux qui n'est pas passé par Iptables reste donc en prio 6.
Mais oui c'est évident. DHCP != ICMP ;D Je me sens un peu bête ! Merci.
-
Pour l'instant c'est un succès :)
J'ai obtenu l'ipv4 et l'ipv6. Clairement, je n'y serai pas arrivé dans les instructions détaillées encore merci ! Le routeur ERX a remplacé le petit switch managé Netgear dans mon tableau électrique.
Premier speedtest 298M up et 298M down - j'ai une connexion Sosh 300M et j'ai perdu 15 ms de ping sans aucun réglage particulier sur l'ERX.
Bref pour l'instant c'est du bonheur.
Maintenant reste à faire fonctionner le wifi de la livebox via le LAN j'imagine, puis le téléphone via le port wan.
-
Salut.
Voici un petit retour des expériences d'hier. Un grand merci à ubune qui m'a surement fait gagner plusieurs jours de tcpdump grace au github dédié.
J'ai fait quelques adaptations sur la partie IPv4/IPv6 en ajoutant un peu plus d'options DHCP que celles dans le tuto (options récupérées via le logiciel liveboxinfo).
Peut-être quelques actions notables à retenir, même si c'est plus du confort :
- L'activation de l'accélaration matérielle sur l'ER-X (via LuCi) semble fonctionner si bien que le réseau sature bien avant le CPU. edit 14/02 l'accélération matérielle améliore l'IPv4 au détriement d'une légère perte au niveau du ping et bufferblat (4ms). Sur ma connexion 300M j'ai observé que j'avais légèrement de meilleures perf sans HW acceleration. Ce paramètre est donc à réserver à ceux qui ont plus 400M sur leur connexion.
- Ajouter le fichier /etc/vlanprio.sh au fichier /etc/sysupgrade.conf afin qu'il reste présent dans les sauvegardes
- utiliser ".home" comme extension locale dans la config DNS, au lieu de ".lan" car cela mime le fonctionnement de la livebox et permet ne pas avoir à tout reconfigurer entre les serveurs : option domain 'home' et option local '/home/' dans /etc/config/dhcp
Telephone et Wifi livebox
Pour la partie wifi et téléphone, mon installation est peut-être différente de ce qui se fait classiquement, mais j'ai trouvé quelques posts sur le forum qui ont une install similaire : avant de passer sur l'ER-X, j'avais mon ONT et un switch VLAN 5 ports dans mon boitier electrique, reliés via un unique cable à un second switch managé puis à la livebox dans le salon. J'ai souhaité conserver cette configuration en remplaçant le petit switch du boitier electrique par l'ER-X.
Si jamais quelqu'un cherche à reproduire la config :
Config switchs
Je sors donc sur un même port de l'ER-X le vlan 1 (LAN) en untagged et vlan 99 (Tel) en tagged. Donc un seul cable jusqu'au port 1 du switch dans le salon.
Au niveau du switch 5 ports du salon :
- Port 1 : 1u + 99t => Relié au port 1 de l'ERX
- Port 2 : 99u => relié au port 3 du même switch
- Port 3 : 832u => pour transformer le vlan 99 en vlan 832
- Port 4 : 832t => relié au WAN de la livebox pour le téléphone
- Port 5 : 1u => relié au LAN de la livebox pour le wifi
Note : Dans le cas de mon petit switch Netgear GS105Ev2 il n'a pas apprécié la boucle entre les port 2 et 3 permettant le changement d'id du VLAN. Les requetes DHCP envoyées par le switch sont "broadcastées" sur tous les ports et finissent par lui faire perdre la boule. J'ai désactivé le DHCP et cela semble mieux se passer. A suivre.
Config OpenWRT
Voici les éléments à ajouter par rapport au modèles dans le github d'ubune.
/etc/config/network
config interface 'tel'
option ifname 'eth0.99'
option proto 'static'
option netmask '255.255.255.0'
option ipaddr '192.168.100.1'
config switch_vlan
option device 'switch0'
option vlan '4'
option ports '6t 1t' #1t si on souhaite sortir le 99 taggué, sinon mettre '1'
option vid '99'
config switch_vlan
option device 'switch0'
option vlan '1'
option ports '6t 1 2 3 4' # Déja présent dans le modèle d'ubune. Attention à enlever le port 1 si on ne tagge pas le vlan 99.
option vid '1'
/etc/config/firewall
ici une différence avec le tuto de rhon ici https://lafibre.info/remplacer-livebox/remplacement-de-la-livebox-par-un-routeur-openwrt-18-dhcp-v4v6-tv/msg589599/#msg589599 (https://lafibre.info/remplacer-livebox/remplacement-de-la-livebox-par-un-routeur-openwrt-18-dhcp-v4v6-tv/msg589599/#msg589599)
config zone
option network 'tel'
option name 'tel'
option forward 'REJECT'
option output 'ACCEPT'
option family 'ipv4'
option input 'DROP' # ici rhon avait ACCEPT qui ne parait pas nécessaire sur les regles configurées ci-dessous.
config rule
option src 'tel'
option dest_port '53'
option target 'ACCEPT'
option name 'DNS for Livebox'
list proto 'tcp'
list proto 'udp'
config rule
option src 'tel'
option dest_port '67-68'
option proto 'udp'
option target 'ACCEPT'
option name 'DHCP for Livebox'
#config rule # inutile déja autorisé juste avant
# option name 'Allow-DHCP-Renew for Livebox'
# option proto 'udp'
# option dest_port '68'
# option target 'ACCEPT'
# option family 'ipv4'
# option src 'tel'
/etc/config/dhcp
config dhcp 'tel'
option leasetime '12h'
option interface 'tel'
option start '1'
option limit '2'
list dhcp_option_force '90,00:00:00:00:00:00:00:00:00:00:00:64:68:63:70:6c:69:76:65:62:6f:78:66:72:32:35:30'
list dhcp_option_force '120,00:06:73:62:63:74:33:67:03:4e:49:43:06:61:63:63:65:73:73:11:6f:72:61:6e:67:65:2d:6d:75:6c:74:69:6d:65:64:69:61:03:6e:65:74:00'
list dhcp_option_force '125,00:00:05:58:0c:01:0a:00:01:00:00:00:ff:ff:ff:ff:ff'
list dhcp_option '6,80.10.246.3,81.253.149.10'
list domain 'orange.fr'
-
Merci pour ce super retour !
Concernant l'offload sur er-x, attention les perfs en ipv6 étaient mauvaise avec, j'ai pas réessayé depuis un moment peux-tu faire un test de débit en ipv6 ? sur Nperf par exemple.
Mais sans on atteint facilement >900Mbps donc ça va ;).
A +
-
Je tenterai des tests à l'occasion. Par contre ma connexion est en 300M donc je risque de ne jamais atteindre les 900Mbits ;)
Sur mes tests d'hier soir, en IPV4 le CPU était presque à 90% pour 300M lors d'un speedtest. Avec l'accélération matérielle activée je suis descendu à 40% environ. Pas fait de test spécifique ipv6 (à part la vérification de la connexion) mais vu que l'essentiel de mon trafic est encore en ipv4, pour l'instant je m'en soucie moins.
-
Le problème n'est pas de savoir si tu as 300 ou 900mbps, en ipv6 on ne dépassait pas les 40Mbps avec l'offload, alors qu'on passe de 920 à 945 avec en ipv4, d’où le fait que c'est pas "indispensable" surtout pour toi avec une connexion à 300Mbps.
Si tu laisses l'ipv6 actif avec la diffusion des RA sur ton lan, tes machines vont se connecter prioritairement en ipv6 quand disponible, donc une bonne partie de ton traffic (et heureusement, ça continue d'augmenter) sera réalisé en ipv6.
Après c'est p-e mieux désormais, c'est pour ça qu'un test de débit ipv6 avec et sans offload aurait été chouette ;).
-
Je vais faire le test :)
Mais pour l'instant je fais face à un autre problème. Mon idée de me rebrancher sur le même switch managé pour traduire le VLAN 99 en VLAN 832 fonctionne pour le téléphone... jusqu'au moment ou le switch tente de broadcaster une requete DHCP pour renouveller sa propre ip... et là, c'est le drame : le petit switch Netgear perd complètement la boule et change d'ip toutes les 3 secondes. :-\
J'ai mis super longtemps à trouver ce qui se passait et je me demande s'il est possible de résoudre ce problème autrement qu'en forçant une IP statique sur le switch.
-
Aller quelques tests.
Les perfs semblent donc légèrement meilleures pour mon cas perso sans HW acceleration activé. Mais je pense que pour ceux qui ont plus cela vaut surement le coup. A tester.
Par contre pas de différence notable en IPv6 comme tu semblais l'indiquer @ubune. Comment as-tu fais tes tests ?
De mon coté, je vais laisser le HW accel désactivé pour l'instant. J'ai modifié mon post original en fonction de cette nouvelle info. Reste à comparer cette config avec les perfs originales de la livebox.
SW/HW accel désactivé
IPv6-test.com
CPU IPV4 élevé.
CPU IPv6 environ 50%
(http://img2.ipv6-test.com/speedtest/result/2021/02/14/b8a75a1991af856443b5e961134abf92.png) (http://ipv6-test.com)
Speedtest netperf
Donwload : ping à 23ms
Upload : ping à 17ms
Speed.cloudflare.com
latency 9ms Jitter 5ms
SW acc activé seulement
Pour le fun,
(http://img2.ipv6-test.com/speedtest/result/2021/02/14/a523daecd639439658d7a41e9fa9884a.png) (http://ipv6-test.com)
SW & HW acc activé
IPv6-test.com
(http://img2.ipv6-test.com/speedtest/result/2021/02/14/3cdba1524ccc64205dc116a7055874f9.png) (http://ipv6-test.com)
CPU IPv4 à moins de 10%.
CPU IPv6 environ 40%
Speedtest netperf
speedtest-netperf.sh -4 -H netperf-eu.bufferbloat.net -p 1.1.1.1 --sequential #IPV4
Donwload : ping à 26ms
Upload : ping à 18ms
speed.cloudflare.com
latency 10 ms - Jitter 3.5ms
-
Merci pour ces résultats.
Mes test remontent à longtemps avec openwrt qui faisait ses débuts sur ERX.
Au vue de tes résultats j'ai juste l'impression que désormais activer l'offload ou non n'impacte que l'ipv4.
Faudrait faire des test "routé" entre deux vlans par exemple pour voir avec du 1gbps.
Par contre j'ai déjà installé du erx@openwrt sur des liens 1gbps et j'obtenais 900+Mbps en speedtest sans offload.
-
Bonjour,
J'utilise une config avec OpenWrt en remplacement de la LiveBox. Tout fonctionnait très bien jusqu'à ce matin. Tout d'un coup, mon routeur OpenWrt s'est vu affecté l'IP 172.16.20.32/24 sur le lien WAN (une IP locale invalide). J'ai ressorti ma LiveBox du placard pour valider que ma fibre et l'infra Orange fonctionnait correctement et pas de soucis, ça fonctionne avec la LiveBox.
Est-ce que Orange (Sosh pour ma part) aurait changé quelque chose à l'authentification ?
Est-ce que certains d'entre vous ont aussi rencontré un soucis récemment ?
Merci !
Albin
-
Salut,
Je suis chez Sosh et pas de soucis ici. Mais si je comprend bien cela dépend de ta région, de la livebox, et de l'age du capitaine ;D
As-tu essayé l'application liveboxinfo pour comparer les options DHCP envoyées par la LB ? C'est plus simple que des TCPdump pour démarrer.
-
Merci garga pour ta réponse, je ne connaissais pas liveboxinfo :-)
Mais j'ai finalement refait un tcpdump de la LiveBox pour trouver mon problème. S'en est suivi une grosse analyse ;D
Mon soucis était que j'avais ajouté dans ma configuration OpenWrt l'option "clientid". Cette option avait la valeur de l'adresse MAC de ma LiveBox (non cohérent donc avec la MAC de mon OpenWrt). Bref, j'ai juste viré cette option. Peut-être que Orange a fait une mise à jour de son côté qui a fait que cela ne fonctionnait plus ... ?
Bref, l'option "clientid" est inutile 8)
-
Cela n' a pas à voir avec le remplacement de la livebox + TV mais uniquement d' un problème de TV
J' ai des répéteurs officiels Orange qui fonctionnent mais cela me plairait beaucoup de solutionner le problème de passage du flux TV avec mes boitiers OpenWrt qui fonctionnent en relay et dont je peux compiler les firmware comme je le désire ...
Pour les firmware Pandorabox il y a un souci car les sources ne sont disponibles mais uniquement les packages précompilés
*
Un problème de longue date avec le réseau et le flux Orange TV que j' aimerai solutionner
Note : Le replay et le media center fonctionnent en OpenWrt relay mais je n' ai pas les chaines
1 - Micrologiciel Pandorabox entre maître + répéteur / relais et aucun problème avec flux TV
2 - Micrologiciel Openwrt entre maître + répéteur / relais exactement la même configuration et pas de TV
3 - Micrologiciel Openwrt maître + client en mode WDS pas de problème avec flux TV
*
(http://)
-
Bonsoir,
Il y a quelques jours, mon DSLAM a été changé, ce qui me permet d'avoir enfin accès au DHCP. J'ai donc testé vite fait la config donnée en première page : nickel je récupère bien une V4 (je pensais qu'il y aurait encore une subtilité, mais c'était pas le cas).
Vient le moment d'attaquer l'IPv6 et là... ça marche pas. J'ai pourtant déjà toutes les règles de pare-feu en place (j'ai un tunnel hurricane electric). Dans le doute j'ai séparé v4/v6 comme indiqué mais toujours rien. Et si je mets l’interface du tunnel sur la zone wanipv6, tout fonctionne bien, donc ce ne sont donc pas les règles qui posent problème.
Côté config j'ai fait un simple copier/coller avec mon fti. Je ne vois rien qui cloche.
config interface 'WAN_DHCP'
option proto 'dhcp'
option broadcast '1'
option vendorid 'sagem'
option reqopts '1 15 28 51 58 59 90'
option sendopts '77:2b46535644534c5f6c697665626f782e496e7465726e65742e736f66746174686f6d652e4c697665626f7834 90:00000000000000000000001a0900000558010341010dxxxxxxxxxxxxxxxxxxxxxx'
option ifname 'nas0'
config interface 'WAN6_DHCP'
option proto 'dhcpv6'
option ifname 'nas0'
option reqprefix 'auto'
option reqaddress 'none'
option defaultreqopts '0'
option sendopts '11:00000000000000000000001a0900000558010341010dxxxxxxxxxxxxxxxxxxxxxx 15:FSVDSL_livebox.Internet.softathome.livebox4 16:0000040e0005736167656d'
option reqopts '11 17 23 24'
Merci
-
J' ai solutionné le problème d' IPTV qui ne passait pas à travers un Routeur MultiWan Netgear SRX5308 en utilisant un boitier à 3 francs 6 sous qui trainait dans un placard
J' utilise isc-dhcp-relay-ipv4 qui fait passer la requête DHCP du boitier TV UHD vers la LiveBox 5
Cela "shunte" le WAN et le LAN du routeur .
-
Mon but était d' utiliser le routeur 4 * WAN Netgear mais il est bien possible que cela fonctionne aussi avec un routeur en OpenWrt seul derrière la LiveBox 5
Ceci est d' autant plus intéressant que maintenant le boitier d' interface de la fibre optique ' ONT est à l' intérieur de la LiveBox 5 et qu'il n'est donc plus possible de remplacer la LiveBox par de l' OpenWrt
-
-
Je viens de faire un tcpdump, et il se trouve que je n'ai aucune réponse d'orange.
Je n'ai que des solicit/router solicitation.
Même si je n'obtiens pas ip est-ce que je devrais reçevoir à minima un advertise ?
-
Hello renaud07,
À priori, Il est normal que tu ne reçoives aucune réponse aux router solicitation (Orange utilisant le DHCPv6 pour communiquer la config réseau, Orange n’envoie aucun router advertissement).
Dans ta trace tcpdump, j'imagine que tu vois ta requête DHCPv6 (DHCP discover). Il faut donc s'assurer que Orange réponde avec un DHCP offer. Et j'imagine que tu ne le reçois pas dans ton cas.
2 possibilités à mon avis :
- Si tes options d'identifification transmises dans le DHCP discover sont mauvaises. Il me semble que Orange ne répond pas.
- Il faut bien configurer le firewall pour laisser passer le DHCPv6 dans les 2 sens.
En espérant que cela t'aide. Tiens nous au courant ;-)
-
Orange envoie la route par défaut par RA.... D'ailleurs vu que la route par défaut est connue de tous (fe80::ba0:bab), sur mon routeur je l'ai configuré en dur et du coup:
Mar 13 19:23:28 gateway kernel: ICMPv6: RA: ndisc_router_discovery failed to add default route
Mar 13 19:43:36 gateway kernel: ICMPv6: RA: ndisc_router_discovery failed to add default route
Sauf que... pour recevoir les RA il faut d'abord avoir envoyé un DHCP6-PD solicit avec l'option 90 option 11 correctement renseignée.
-
Merci pour les pistes.
L'option 11 (et les autres) sont donc censées être envoyé dans la requête solicit ?
Du coup je pense que j'ai trouvé mon problème : elle n’apparaissent pas... Problème avec odhcp6c ? Je suis en version 17.01.4 (la 18 est instable sur mon routeur)
-
Je viens de tester en spécifiant les options à la main :
odhcp6c -V 0000040e0005736167656d -u FSVDSL_livebox.Internet.softathome.livebox4 nas0
Et cette fois ça fonctionne ! Par contre comment envoyer l'option 11 ? Je ne vois aucun argument qui corresponde...
EDIT : Bon va falloir que j'upgrade de toute évidence :-\
https://lafibre.info/remplacer-livebox/remplacement-de-la-livebox-par-un-routeur-lede-fork-dopenwrt/msg531290/#msg531290
Pour ipv6, c'est un peu plus compliqué : le client DHCPv6 (odhcp6c) de LEDE 17.04.1 ne supporte pas les options arbitraires mais il a été mis à jour dans les versions de développement (https://git.openwrt.org/?p=project/odhcp6c.git;a=commit;h=510aaf6d528210c5e8a6159f9b80b32615e88c5f). Sur une install 17.04.1 à jour, on peut l'installer assez facilement de la facon suivante:
-
En attendant d'upgrade, j'ai ressorti mon DGA4132 et... ça fonctionne ! J'ai V4 + V6 8) Merci à fatpat pour toute la doc : https://lafibre.info/remplacer-livebox/remplacer-sa-livebox-par-un-technicolor-dga4132-roote/msg841004/#msg841004
Par contre, je ne sais pas ce qu'il se passe il y a un gros problème de débit... enfin pas vraiment mais ça donne la même impression.
Lorsque je veux accéder à un site ça mouline pendant + de 10 sec avant de me l'afficher. On dirait que chaque connexion à n'importe quelle adresse prend 3 plombes et que ça se débloque d'un coup. Mais une fois connecté, le ping est régulier ou sur une vidéo YT je peux naviguer dedans sans problème, par ex.
C'est ultra bizarre. A moins qu'il y ai un problème avec la partie DSL car juste avant je l'avais connecté via le LAN pour tout paramétrer et la navigation était parfaitement fluide. De même je n'ai pas de ralentissement sur l’interface web...
-
@Renaud07, j'ai eu le meme souci il me semble en suivant le tuto de fatpat mais je ne me souvient plus très bien comment je l'ai réglé, de mémoire c'était du coté de la config dhcp, je crois que j'ai forcé les dns du lan.
Je le reinstalle et je te dis.
Edit:
Voilà il me semble qu'en mettant ça dans /etc/config/dhcp le probleme s'est résolu tout seul.
config dhcp 'lan'
option interface 'lan'
option start '251'
option leasetime '21600s'
option dhcpv6 'server'
option ra 'server'
option ra_management '0'
option ra_mininterval '200'
option ra_maxinterval '600'
option ra_lifetime '1800'
option ra_hoplimit '64'
option force '1'
option ignore '0'
option limit '2'
list dhcp_option '6,81.253.149.10,80.10.246.3'
list dhcp_option '15,orange.fr'Après tu relances dnsmasq sur le routeur et sur le PC un ipconfig /renew
-
Merci pour la config je test ça dès que je peux. Donc faut forcer les DNS orange et ne plus passer par le routeur ? Curieux. Un bug de dnsmasq sur la 2.2.1 ?
Sur le BTHH5 le problème ne se pose pas (enfin j'dit ça, mais j'ai pas encore de v6 dessus pour être dans les mêmes conditions)
En tout cas j'espère qu'il n'y aura pas de problème (j'ai essayé à l'arrache hier en ne connectant pas le LAN), car normalement je n'utilise pas les DNS orange, mais le mien avec des domaines locaux et tout un tas d'autres règles pour filtrer les pubs...
-
je ne sais pas si c'est en faisant ca ou si c'est une coincidence et que le probleme s'est finalament réglé tout seul, mais j'avais comme toi des soucis sur pas mal de sites, pour certains ca marchait pour d'autre pas du tout, et en forcant un dns autre que celui du routeur ca a fonctionné.
-
En effet c'était bien ça. Merci ;)
Je suis chez mes parents et j'en ai profité pour apporter le DGA et tester sur leur ligne (qui a aussi migré pour le DHCP).
Là j'ai mis mes DNS habituels et ça répond instantanément. J'ai ensuite basculé sur le routeur et bingo navigation hyper lente.
EDIT : chose marrante, je me retrouve avec une ip qui pointe à Montpellier ??? Pourtant quand je vais voir le whois de la plage, je vois bien POP LYO (donc Lyon là où mon trafic remonte d'habitude)
inetnum: 81.xx.xx.0 - 81.xx.xx.255
netname: IP2000-ADSL-BAS
descr: POP LYO
Sans doute le reverse non mis à jour suite à une réorganisation.
-
Résumé de cette journée :
J'ai réupgrade le BTHH5 des parents en 18.06 : ça fonctionne pour le moment et j'ai enfin de l'ipv6 natif ! A voir sur la durée, si ça plante ou pas. Voir si je bascule le mien aussi.
Enfin, ça à l'air de mal partir car j'ai eu un beau bug un peu avant : La première fois que j'ai testé, si j'obtenais bien une V6, ainsi que les appareils, sur un site de test ça me disait que j'en avais pas. J'ai donc remonté temporairement mon tunnel HE, car je n'avais plus le temps il fallait que je parte.
De retour à la maison, je continue mes tests via mon VPN. Tout va bien pendant ~1h, et là je me décide à remonter la MTU du tunnel (qui me sert à avoir une ip fixe) puisque je ne suis plus limité par le PPPoE. Et bizarrement quelques minutes après avoir fait la modif, ça commence à déconner : impossible d'accéder à l'interface du routeur ou mon proxmox (temps d'attente dépassé) Seuls les ping passent et encore très difficilement (ça fluctue bcp avec parfois des retours à 1sec !) bref... la cata.
Je bascule la connexion en V4 (vu que maintenant c'est censé être en ip fixe) : tout redevient normal et j'ai même gagné en vitesse (passer de 100ms avec le tunnel à 40ms en direct ça change beaucoup, on dirait que j'ai doublé mon débit alors que pas du tout). Depuis ça n'a pas replanté, mais je surveille ça de près.
Un peu plus tard je me suis remis à le recherche du pourquoi je n'avais pas de V6 sur les machines et j'ai finalement trouvé assez rapidement que je m'étais gouré sur 2-3 règles de pare-feu (les zones n'étaient pas les bonnes noramment) et une fois corrigé, magie ça marche 8)
Pour la blague, petite capture sur windows XP ;D
-
Bonjour à tous
Merci tout d'abord pour ce tuto formidable qui m'a permis de me débarrasser de ma livebox (par un edge routeur x + tplink).
Tout marche bien (à part l'IPv6 mais je ne suis pas encore au point sur cette techno). J'ai dans les logs de mon routeur, toutes les 36H ceci :
Mon Mar 15 00:16:54 2021 daemon.notice netifd: wan (1335): udhcpc: sending renew to XX.XX.XX.XX <- IP Orange
Mon Mar 15 00:16:54 2021 daemon.notice netifd: wan (1335): udhcpc: received DHCP NAK
Mon Mar 15 00:16:54 2021 daemon.notice netifd: Interface 'wan' has lost the connection
Mon Mar 15 00:16:57 2021 daemon.notice netifd: wan (1335): udhcpc: sending select for YYY.YYY.YYY.YYY <- mon IP
Mon Mar 15 00:16:58 2021 daemon.notice netifd: wan (1335): udhcpc: lease of YYY.YYY.YYY.YYY obtained, lease time 259200
Les 36H semblent correspondre à la moitié du lease time. Ce que je ne comprends pas c'est le NAK, si c'est normal ou pas. Dans tous les cas mon IP ne change pas, et je n'ai jamais ressenti la déconnexion.
Au cas où quelqu'un a une idée (j'ai un peu farfouillé sur internet sans grand succès), merci !
-
Salut,
Le DHCP NAK sert à 2 choses : signaler la fin du bail ou des paramètres invalides envoyés par le client.
J'ai attendu la fin de mon bail cette nuit voir ce qu'il se passait chez moi : j'ai un simple renew sans DHCP NAK. Après ça dépend peut-être de la version d'OWRT (par ex je n'ai pas "sending renew to XX..." mais juste "sending renew") :
Wed Mar 17 04:10:36 2021 daemon.notice netifd: WAN_DHCP (2620): udhcpc: sending renew
As-tu ajouté la Qos avec le script ? Car en ADSL (si c'est bien ton cas), ce n'est pas nécessaire.
-
Je ne suis plus orange ADSL mais orange fibre, j'avais effectivement oublié de mettre à jour mon profil.
Je pense avoir tout suivi au niveau du tuto et normalement j'ai mis la QoS. J'ai un OpenWrt 19.07.7.
Après j'ai modifié la conf de mon routeur en suivant le tuto mais sans faire de copier/coller "bête", donc ça m'a pris 5 fois avant d'y arriver :) (à chaque fois il me manquait un petit détail d'autant plus que j'ai un openwrt compilé maison), donc il est possible que j'ai zappé un truc.
Ce qui est bizarre, c'est que juste après le NAK ça fonctionne correctement... Je reçois un NAK sur le renew, donc peut-être que ma conf est foireuse sur le renew mais pas sur le "select". Je vais creuser de ce coté.
Merci en tout cas pour ta réponse.
-
Bon j'ai continué mes investigations à coup de tcpdump. Normalement j'ai masqué les données sensibles.
L'envoi du renew :
16:29:56.151634 Out xx:xx:xx:xx:xx:xx ethertype 802.1Q (0x8100), length 407: vlan 832, p 0, ethertype IPv4, (tos 0x0, ttl 64, id 13091, offset 0, flags [DF], proto UDP (17), length 387)
XXX.XXX.XXX.XXX.68 > YYY.YYY.YYY.YYY.67: BOOTP/DHCP, Request from xx:xx:xx:xx:xx:xx, length 359, xid 0x372a7b0e, Flags [none]
Client-IP XXX.XXX.XXX.XXX
Client-Ethernet-Address xx:xx:xx:xx:xx:xx
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Request
MSZ Option 57, length 2: 576
Parameter-Request Option 55, length 12:
Subnet-Mask, Default-Gateway, Domain-Name-Server, Hostname
Domain-Name, BR, NTP, Lease-Time
RN, RB, AUTH, Classless-Static-Route
Vendor-Class Option 60, length 5: "sagem"
Hostname Option 12, length 7: "routeur"
User-Class Option 77, length 44:
instance#1: "FSVDSL_livebox.Internet.softathome.Livebox4", length 43
AUTH Option 90, length 33: 0.0.0.0.0.0.0.0.0.0.0.a.b.c.d.e.f.g.h.i.j.k.l.m.n.o.p.q.r.s.t.u.v
16:29:56.192316 P a0:f3:e4:51:a7:95 ethertype 802.1Q (0x8100), length 323: vlan 832, p 0, ethertype IPv4, (tos 0xc0, ttl 64, id 15380, offset 0, flags [none], proto UDP (17), length 303)
YYY.YYY.YYY.YYY.67 > XXX.XXX.XXX.XXX.68: BOOTP/DHCP, Reply, length 275, xid 0x372a7b0e, Flags [none]
Client-Ethernet-Address xx:xx:xx:xx:xx:xx
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: NACK
Server-ID Option 54, length 4: YYY.YYY.YYY.YYY
MSG Option 56, length 1: " "
On voit donc que le serveur DHCP répond NACK, pas gentil.
Juste après le discover/offer qui se passe bien et le deuxième request :
16:29:59.434357 Out xx:xx:xx:xx:xx:xx ethertype 802.1Q (0x8100), length 419: vlan 832, p 6, ethertype IPv4, (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 399)
0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from xx:xx:xx:xx:xx:xx, length 371, xid 0x50eefa22, Flags [Broadcast]
Client-Ethernet-Address xx:xx:xx:xx:xx:xx
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Request
Requested-IP Option 50, length 4: XXX.XXX.XXX.XXX
Server-ID Option 54, length 4: YYY.YYY.YYY.YYY
MSZ Option 57, length 2: 576
Parameter-Request Option 55, length 12:
Subnet-Mask, Default-Gateway, Domain-Name-Server, Hostname
Domain-Name, BR, NTP, Lease-Time
RN, RB, AUTH, Classless-Static-Route
Vendor-Class Option 60, length 5: "sagem"
Hostname Option 12, length 7: "routeur"
User-Class Option 77, length 44:
instance#1: "FSVDSL_livebox.Internet.softathome.Livebox4", length 43
AUTH Option 90, length 33: 0.0.0.0.0.0.0.0.0.0.0.a.b.c.d.e.f.g.h.i.j.k.l.m.n.o.p.q.r.s.t.u.v
16:29:59.491195 B a0:f3:e4:51:a7:95 ethertype 802.1Q (0x8100), length 483: vlan 832, p 6, ethertype IPv4, (tos 0xc0, ttl 64, id 15516, offset 0, flags [none], proto UDP (17), length 463)
ZZZ.ZZZ.ZZZ.ZZZ.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 435, xid 0x50eefa22, Flags [Broadcast]
Your-IP XXX.XXX.XXX.XXX
Server-IP YYY.YYY.YYY.YYY
Gateway-IP AAA.AAA.AAA.AAA
Client-Ethernet-Address xx:xx:xx:xx:xx:xx
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: ACK
Server-ID Option 54, length 4: YYY.YYY.YYY.YYY
Subnet-Mask Option 1, length 4: 255.255.248.0
Default-Gateway Option 3, length 4: ZZZ.ZZZ.ZZZ.ZZZ
Lease-Time Option 51, length 4: 259200
[....]
En comparant les 2 request on voit que la différence est que la première est fait à partir de l'IP et non pas en broadcast mais à priori c'est normal.
La deuxième est que dans la première les 2 options 50 et 54 ne sont pas envoyés (mais en contrepartie Client-IP est envoyé au début).
Est-ce que ça peut expliquer le NACK ?
-
Moi je vois une autre différence, le renew a la priorité 802.1p à 0 (pas bon dans le 06...), l'autre est correcte avec sa priorité à 6.
Aucune chance que le renew fonctionne dans ces conditions ici, et clairement le même problème que j'ai eu avec la première version de mon patch pour le client DHCP de mon routeur Ubiquiti sous EdgeOS.
-
Raaahhhh merci beaucoup zoc !!
Effectivement je n'avais pas fait attention à ce paramètre.
Bon au final en ajoutant cette règle iptables :
iptables -t mangle -A POSTROUTING -p udp --dport 67 --sport 68 -j CLASSIFY --set-class 0000:0006
J'ai réussi à faire un renew correctement sans erreur.
A priori elle n'est pas indiquée dans le tuto, donc soit les paramètres varient localement (tu parlais du 06), soit j'ai encore un autre problème dans ma config que cette ligne permet de contourner. Je vais continuer à creuser, merci beaucoup pour ton aide en tout cas.
-
exact en fait @ubune dans son premier tuto ici : https://lafibre.info/remplacer-livebox/remplacement-de-la-livebox-par-un-routeur-lede-fork-dopenwrt/msg471879/#msg471879
Les customs rules qui se lancent au demarrage :
iptables -t mangle -A POSTROUTING -o eth1.832 -j CLASSIFY --set-class 0000:0001 ## En gros tout le flux passe dans la file 1 qui est en prio 0 (ATTENTION, si on ne fait pas ça = gros probleme de débit)
iptables -t mangle -A POSTROUTING -o eth1.832 -p igmp -j CLASSIFY --set-class 0000:0006 ##On passe le flux igmp dans la file 6 qui est en prio 6
iptables -t mangle -A POSTROUTING -o eth1.832 -p icmp -j CLASSIFY --set-class 0000:0006 ## On passe le flux icmp dans la file 6 qui est en prio 6
iptables -t mangle -A POSTROUTING -o eth1.832 -p udp --dport 67 -j CLASSIFY --set-class 0000:0006 ## Inutile ? On passe le flux dhcp dans la file 6 qui est en prio 6
Inutile ? = En faite je comprends pas l'intérêt, car le flux qui ne passe pas par IPTABLES est déja en PRIO 6, et c'est le cas du DHCP.
Edit : d'ailleurs ça fonctionne même sans cette règle (logique).
Si quelqu'un detecte que j'ai mal compris n'hésitez pas à me corriger :).
Donc il a enlevé la règle dans son tuto final, ici. Donc soit @ubune a raison et tu as oublié un truc, soit il faut vraiment l'ajouter.
-
Donc il a enlevé la règle dans son tuto final, ici. Donc soit @ubune a raison et tu as oublié un truc, soit il faut vraiment l'ajouter.
le broadcast DHCP (discovery) se fait avec des raw sockets donc ne passe par iptables.
mais le renew oui donc il faut la règle sinon il n'y a jamais de renew.
-
OK donc @ubune ou un modo, il faudrait svp ajouter au tuto page 1, dans la partie iptables custom rules:
iptables -t mangle -A POSTROUTING -o eth1.832 -p udp --dport 67 -j CLASSIFY --set-class 0000:0006 ## On passe le flux dhcp dans la file 6 qui est en prio 6, necessaire pour le DHCP Renew
-
OK donc @ubune ou un modo, il faudrait svp ajouter au tuto page 1, dans la partie iptables custom rules:
Salut à tous,
Justement curieux car en effet à l'époque j'avais bien validé le fonctionnement même sans.
Mais ça mange pas de pain de l'ajouter dans tous les cas, je corrige le tuto.
-
Salut ! @ubune et les autres
Bon ca fait x années que je ne comprends pas pourquoi je n'arrive pas avoir la TV (j'ai une LB4 et decodeur 4) avec tous mes modem/routeurs OpenWrt...
Je viens de recommencer avec mon modem/routeur BT Home Hub 5A, flashé avec le dernier snasphot.
J'ai suivi scrupuleusement ton tuto, en faisant les modifs relatives à ma connexion VDSL donc remplacer eth1.832 et 840 respectivement par dsl0.832 et 840
Au final, j'ai bien mon IPV4 et mon IPV6, mais impossible d'avoir le flux TV (j'ai le Replay, et j'ai bien le resumé des chaines avec les images et tout qui s'affiche)
Mon décodeur et relié au modem par CPL. Avec la LB4 aucun souci.
je ne comprends pas ou ça coince...
(https://i.imgur.com/KZAUmRj.png)
(https://i.imgur.com/LVq3YBf.png)
(https://i.imgur.com/eTnAgqZ.png)
et voici mon /etc/config/network
config interface 'loopback'
option ifname 'lo'
option proto 'static'
option ipaddr '127.0.0.1'
option netmask '255.0.0.0'
config dsl 'dsl'
option annex 'a'
option xfer_mode 'ptm'
option line_mode 'vdsl'
option tone 'av'
option ds_snr_offset '0'
config interface 'lan'
option type 'bridge'
option proto 'static'
option netmask '255.255.255.0'
option _orig_ifname 'eth0.1 radio0.network1 radio1.network1'
option _orig_bridge 'true'
option ifname 'eth0.1'
option broadcast '192.168.1.255'
option gateway '192.168.1.1'
option delegate '0'
option ip6assign '64'
option igmp_snooping '1'
list dns '192.168.1.1'
option ipaddr '192.168.1.1'
config device 'lan_dev'
option name 'eth0.1'
config device 'wan_dev'
option name 'dsl0'
option ipv6 '1'
option mtu '1500'
config switch
option name 'switch0'
option reset '1'
option enable_vlan '1'
config switch_vlan
option device 'switch0'
option vlan '1'
option ports '0 1 2 4 6t'
config switch_vlan
option device 'switch0'
option vlan '2'
option ports '5 6t'
config interface 'wan'
option ifname 'dsl0.832'
option proto 'dhcp'
option peerdns '1'
option broadcast '1'
option mtu '1500'
option auto '1'
option ipv6 '1'
option vendorid 'sagem'
option reqopts '1 3 6 15 28 51 58 59 90 119 120 125'
option sendopts '77:2b46535644534c5f6c697665626f782e496e7465726e65742e736f66746174686f6d652e4c697665626f7834 90:00000000000000000000001a0900000558010341010dxxxxxxxxxxxxxxxxxxxxxx'
config interface 'tvorange'
option proto 'static'
option ipaddr '192.168.255.254'
option netmask '255.255.255.255'
option gateway '192.168.255.254'
option ifname 'dsl0.840'
config interface 'wan6'
option ifname '@wan'
option proto 'dhcpv6'
option reqprefix 'auto'
option reqaddress 'none'
option defaultreqopts '0'
option reqopts '11 17 23 24'
option userclass 'FSVDSL_livebox.Internet.softathome.livebox4'
option vendorclass '0000040e0005736167656d'
option sendopts '11:00000000000000000000001a0900000558010341010dxxxxxxxxxxxxxxxxxxxxxx'
option iface_dslite '0'
option iface_464xlat '0'
option noclientfqdn '1'
option noacceptreconfig '1'
Mon /etc/config/dhcp :
config dnsmasq
option domainneeded '1'
option boguspriv '1'
option filterwin2k '0'
option localise_queries '1'
option rebind_protection '1'
option rebind_localhost '1'
option local '/lan/'
option domain 'lan'
option expandhosts '1'
option nonegcache '0'
option authoritative '1'
option readethers '1'
option leasefile '/tmp/dhcp.leases'
option resolvfile '/tmp/resolv.conf.d/resolv.conf.auto'
option nonwildcard '1'
option localservice '1'
option ednspacket_max '1232'
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'
list dhcp_option '6,192.168.1.1'
config dhcp 'wan'
option interface 'wan'
option ignore '1'
config odhcpd 'odhcpd'
option maindhcp '0'
option leasefile '/tmp/hosts/odhcpd'
option leasetrigger '/usr/sbin/odhcpd-update'
option loglevel '4'
config dhcp 'vlantv'
option leasetime '12h'
option interface 'vlantv'
option start '10'
option limit '10'
list dhcp_option '6,81.253.149.10,80.10.246.3'
list dhcp_option '15,orange.fr'
mon /etc/config/igmpproxy :
config igmpproxy
option quickleave 1
config phyint
option network tvorange
option zone wanTV
option direction upstream
list altnet "0.0.0.0/0"
config phyint lan
option network vlantv
option zone tv
option direction downstream
et mon /etc/config/firewall :
config defaults
option syn_flood 1
option input ACCEPT
option output ACCEPT
option forward REJECT
config zone
option name lan
list network 'lan'
option input ACCEPT
option output ACCEPT
option forward ACCEPT
config zone
option name wan
list network 'wan'
option input REJECT
option output ACCEPT
option forward REJECT
option masq 1
option mtu_fix 1
option family ipv4
config forwarding
option src lan
option dest wan
config zone
option name 'wanipv6'
option network 'wan6'
option output 'ACCEPT'
option forward 'DROP'
option family 'ipv6'
option input 'DROP'
config rule
option name Allow-DHCP-Renew
option src wan
option proto udp
option dest_port 68
option target ACCEPT
option family ipv4
config rule
option name Allow-Ping
option src wan
option proto icmp
option icmp_type echo-request
option family ipv4
option target ACCEPT
config rule
option name Allow-IGMP
option src wan
option proto igmp
option family ipv4
option target ACCEPT
config rule
option name 'Allow-DHCPv6'
option proto 'udp'
option src_ip 'fc00::/6'
option dest_ip 'fc00::/6'
option dest_port '546'
option family 'ipv6'
option target 'ACCEPT'
option src 'wanipv6'
config rule
option name 'Allow-MLD'
option proto 'icmp'
option src_ip 'fe80::/10'
list icmp_type '130/0'
list icmp_type '131/0'
list icmp_type '132/0'
list icmp_type '143/0'
option family 'ipv6'
option target 'ACCEPT'
option src 'wanipv6'
config rule
option name 'Allow-ICMPv6-Input'
option proto 'icmp'
list icmp_type 'echo-request'
list icmp_type 'echo-reply'
list icmp_type 'destination-unreachable'
list icmp_type 'packet-too-big'
list icmp_type 'time-exceeded'
list icmp_type 'bad-header'
list icmp_type 'unknown-header-type'
list icmp_type 'router-solicitation'
list icmp_type 'neighbour-solicitation'
list icmp_type 'router-advertisement'
list icmp_type 'neighbour-advertisement'
option limit '1000/sec'
option family 'ipv6'
option target 'ACCEPT'
option src 'wanipv6'
config rule
option name 'Allow-ICMPv6-Forward'
option dest '*'
option proto 'icmp'
list icmp_type 'echo-request'
list icmp_type 'echo-reply'
list icmp_type 'destination-unreachable'
list icmp_type 'packet-too-big'
list icmp_type 'time-exceeded'
list icmp_type 'bad-header'
list icmp_type 'unknown-header-type'
option limit '1000/sec'
option family 'ipv6'
option target 'ACCEPT'
option src 'wanipv6'
config rule
option name Allow-IPSec-ESP
option src wan
option dest lan
option proto esp
option target ACCEPT
config rule
option name Allow-ISAKMP
option src wan
option dest lan
option dest_port 500
option proto udp
option target ACCEPT
config rule
option name Support-UDP-Traceroute
option src wan
option dest_port 33434:33689
option proto udp
option family ipv4
option target REJECT
option enabled false
config include
option path /etc/firewall.user
config zone
option name 'tv'
option output 'ACCEPT'
option network 'vlantv'
option input 'ACCEPT'
option forward 'ACCEPT'
option family 'ipv4'
config zone
option name 'wanTV'
option output 'ACCEPT'
option masq '1'
option network 'tvorange'
option input 'DROP'
option forward 'DROP'
option family 'ipv4'
config forwarding
option dest 'wanTV' #On autorise la box tv à sortir sur le wanTV.
option src 'tv'
config forwarding
option dest 'wan' #On autorise la box tv à atteindre le flux wan classique (Replay/ntp par exemple).
option src 'tv'
config rule
option target 'ACCEPT'
option name 'igmp' #On autorise le flux IGMP provenant du vlan 840 à destination du routeur.
option family 'ipv4'
option proto 'igmp'
option src 'wanTV'
config rule
option target 'ACCEPT'
option name 'multicast' #On autorise le flux multicast provenant du vlan 840 à destination de la zone tv (le vlan TV ou se trouvera le décodeur).
option family 'ipv4'
option proto 'udp'
option src 'wanTV'
option dest 'tv'
option dest_ip '224.0.0.0/4'
A l'aide ! >:( ;D
PS:
j'ai un doute sur la partie switch dans /etc/config/network, j'ai laissé ce qu'il y a d'origine sur mon modem...je ne sais pas si ca peut influencer le resultat...quoi qu'il en soit sur les interfaces vlantv et tvorange on ne voit aucun paquet recu...
-
Salut Cétipabo.
Sur tes screenshot on voit que l'interface vlan 19 n'a reçu aucun paquet (RX=0), c'est en effet ta config Vlan qui n'est pas bonne.
Dans le tuto j'ai fait le choix de sortir la box TV du domaine de diffusion ou tu retrouves tes équipements (vlan 1), pour éviter toute problématique avec le flux multicast généré par la visualisation des chaines TV (devoir configurer l'igmp snooping correctement etc).
La box tv doit donc être dans le vlan 19 (subnet 192.168.19.0/24, on voit ton eth0.19 sur les screen), cette interface "vlantv" est dans la zone Firewall "tv".
Du coup il faut paramétrer le vlan 19 sur le port du routeur ou tu vas brancher ton CPL pour la box tv (en untagged), et en tagged sur le CPU.
Dans le tuto il y a donc un port dédié box tv (exemple sur équipement equivalent linksys).
config switch_vlan
option device 'switch0'
option vlan '3' # Index sur openwrt
option ports '0t 1 5t' # t pour tag (cpu et un port pour un eventuel switch administrable), ainsi que le port 1 (lan 3 sur linksys) pour la box en natif (untagged).
option vid '19' # Vlan ID 19
Essaie d'adapter ça à ton modele (regarde sur openwrt l'indexation des ports), ou fait le via la GUI.
Il faut également que le serveur dhcp openwrt (sur l'interface vlan tv) distribue les dns d'Orange et envoi l'option 125 (pour les dernières box tv).
Tiens nous au jus.
A+
-
Salut @ubune, merci pour ton retour !
donc si j'ai bien compris, à partir de luci, je devrais me retrouver comme ça, si je branche mon décodeur sur le port 2 du routeur ?
(c'est un montage avec paint, j'suis au boulot ;D )
(https://i.imgur.com/6CNPnhY.png)
EDIT:
https://openwrt.org/toh/bt/homehub_v5a#switch
(https://i.imgur.com/SqHHAyf.png)
le CPU est sur le 6 et le port 2 sur le 2...
ce qui donc devrait faire cela :
config switch_vlan
option device 'switch0'
option vlan '3' # Index sur openwrt
option ports '2 6t' # 6 (tagged) pour le CPU et 2 (untagged) pour le port connecté au décodeur
option vid '19' # Vlan ID 19
J'ai juste ?
-
C'est exactement ça !
Juste ne pas oublier d'enlever le vlan 1 en untagged sur ton port 2 du coup (bascule sur "off") ;)
Fait le en GUI car apparemment tu n'as pas le "vid" sur la config vlan de ton model.
-
j'arrive du boulot ;D
ok donc :
(https://i.imgur.com/4RPcu8f.png)
et maintenant je vois du trafic sur vlantv :
(https://i.imgur.com/aPPc7bZ.png)
Mais pas de trafic sur dsl0.840 et j'ai toujours pas de flux TV...
root@OpenWrt:~# logread | grep igmp
Thu Apr 8 17:56:03 2021 user.warn igmpproxy[9677]: setsockopt IP_MULTICAST_IF 192.168.19.254; Errno(126): Address not available
Thu Apr 8 17:56:11 2021 user.warn igmpproxy[9677]: select() failure; Errno(4): Interrupted system call
Thu Apr 8 17:57:34 2021 user.warn igmpproxy[11497]: select() failure; Errno(4): Interrupted system call
Thu Apr 8 18:03:01 2021 user.warn igmpproxy[13368]: select() failure; Errno(4): Interrupted system call
Thu Apr 8 18:03:01 2021 user.notice igmpproxy[13992]: adding VIF, Ix 0 Fl 0x0 IP 0xc0a8fffe dsl0.840, Threshold: 1, Ratelimit: 0
Thu Apr 8 18:03:01 2021 user.notice igmpproxy[13992]: adding VIF, Ix 1 Fl 0x0 IP 0xc0a813fe eth0.19, Threshold: 1, Ratelimit: 0
Thu Apr 8 18:03:01 2021 user.notice igmpproxy[13992]: Joining group 224.0.0.2 on interface eth0.19
Thu Apr 8 18:03:01 2021 user.notice igmpproxy[13992]: Joining group 224.0.0.22 on interface eth0.19
Thu Apr 8 18:03:01 2021 user.notice igmpproxy[13992]: RECV Membership query from 192.168.19.254 to 224.0.0.1
Thu Apr 8 18:03:01 2021 user.notice igmpproxy[13992]: RECV V2 member report from 192.168.19.254 to 224.0.0.2
Thu Apr 8 18:03:01 2021 user.notice igmpproxy[13992]: The IGMP message was from myself. Ignoring.
Thu Apr 8 18:03:01 2021 user.notice igmpproxy[13992]: RECV V2 member report from 192.168.19.254 to 224.0.0.22
Thu Apr 8 18:03:01 2021 user.notice igmpproxy[13992]: The IGMP message was from myself. Ignoring.
Thu Apr 8 18:03:03 2021 user.notice igmpproxy[13992]: The IGMP message was local multicast. Ignoring.
Thu Apr 8 18:03:09 2021 user.notice igmpproxy[13992]: RECV Membership query from 192.168.19.254 to 224.0.0.1
Thu Apr 8 18:03:11 2021 user.notice igmpproxy[13992]: RECV V2 member report from 192.168.19.254 to 224.0.0.22
Thu Apr 8 18:03:11 2021 user.notice igmpproxy[13992]: The IGMP message was from myself. Ignoring.
Thu Apr 8 18:03:17 2021 user.notice igmpproxy[13992]: RECV Membership query from 192.168.19.254 to 224.0.0.1
Thu Apr 8 18:03:17 2021 user.notice igmpproxy[13992]: The IGMP message was local multicast. Ignoring.
Thu Apr 8 18:03:17 2021 user.notice igmpproxy[13992]: RECV V2 member report from 192.168.19.254 to 224.0.0.2
Thu Apr 8 18:03:17 2021 user.notice igmpproxy[13992]: The IGMP message was from myself. Ignoring.
Thu Apr 8 18:03:22 2021 user.notice igmpproxy[13992]: RECV V2 member report from 192.168.19.254 to 224.0.0.22
Thu Apr 8 18:03:22 2021 user.notice igmpproxy[13992]: The IGMP message was from myself. Ignoring.
Thu Apr 8 18:03:25 2021 user.notice igmpproxy[13992]: RECV Membership query from 192.168.19.254 to 224.0.0.1
Thu Apr 8 18:03:28 2021 user.notice igmpproxy[13992]: RECV V2 member report from 192.168.19.254 to 224.0.0.2
Thu Apr 8 18:03:28 2021 user.notice igmpproxy[13992]: The IGMP message was from myself. Ignoring.
Thu Apr 8 18:03:31 2021 user.notice igmpproxy[13992]: The IGMP message was local multicast. Ignoring.
Thu Apr 8 18:03:31 2021 user.notice igmpproxy[13992]: RECV V2 member report from 192.168.19.254 to 224.0.0.22
Thu Apr 8 18:03:31 2021 user.notice igmpproxy[13992]: The IGMP message was from myself. Ignoring.
Thu Apr 8 18:03:34 2021 user.notice igmpproxy[13992]: RECV Membership query from 192.168.19.254 to 224.0.0.1
Thu Apr 8 18:03:34 2021 user.notice igmpproxy[13992]: The IGMP message was local multicast. Ignoring.
Thu Apr 8 18:03:38 2021 user.notice igmpproxy[13992]: RECV V2 member report from 192.168.19.254 to 224.0.0.2
Thu Apr 8 18:03:38 2021 user.notice igmpproxy[13992]: The IGMP message was from myself. Ignoring.
Thu Apr 8 18:03:39 2021 user.notice igmpproxy[13992]: RECV V2 member report from 192.168.19.254 to 224.0.0.22
Thu Apr 8 18:03:39 2021 user.notice igmpproxy[13992]: The IGMP message was from myself. Ignoring.
Thu Apr 8 18:03:42 2021 user.notice igmpproxy[13992]: RECV Membership query from 192.168.19.254 to 224.0.0.1
Thu Apr 8 18:03:44 2021 user.notice igmpproxy[13992]: RECV V2 member report from 192.168.19.254 to 224.0.0.22
Thu Apr 8 18:03:44 2021 user.notice igmpproxy[13992]: The IGMP message was from myself. Ignoring.
Thu Apr 8 18:03:49 2021 user.notice igmpproxy[13992]: RECV V2 member report from 192.168.19.254 to 224.0.0.2
Thu Apr 8 18:03:49 2021 user.notice igmpproxy[13992]: The IGMP message was from myself. Ignoring.
Thu Apr 8 18:03:51 2021 user.notice igmpproxy[13992]: The IGMP message was local multicast. Ignoring.
Thu Apr 8 18:03:54 2021 user.notice igmpproxy[13992]: RECV Membership query from 192.168.19.254 to 224.0.0.1
Thu Apr 8 18:03:56 2021 user.notice igmpproxy[13992]: RECV V2 member report from 192.168.19.254 to 224.0.0.2
Thu Apr 8 18:03:56 2021 user.notice igmpproxy[13992]: The IGMP message was from myself. Ignoring.
Thu Apr 8 18:03:57 2021 user.notice igmpproxy[13992]: The IGMP message was local multicast. Ignoring.
Thu Apr 8 18:04:01 2021 user.notice igmpproxy[13992]: RECV V2 member report from 192.168.19.254 to 224.0.0.22
Thu Apr 8 18:04:01 2021 user.notice igmpproxy[13992]: The IGMP message was from myself. Ignoring.
Thu Apr 8 18:04:04 2021 user.notice igmpproxy[13992]: RECV Membership query from 192.168.19.254 to 224.0.0.1
Thu Apr 8 18:04:08 2021 user.notice igmpproxy[13992]: RECV V2 member report from 192.168.19.254 to 224.0.0.22
Thu Apr 8 18:04:08 2021 user.notice igmpproxy[13992]: The IGMP message was from myself. Ignoring.
Thu Apr 8 18:04:11 2021 user.notice igmpproxy[13992]: RECV Membership query from 192.168.19.254 to 224.0.0.1
Thu Apr 8 18:04:13 2021 user.notice igmpproxy[13992]: The IGMP message was local multicast. Ignoring.
Thu Apr 8 18:04:14 2021 user.notice igmpproxy[13992]: RECV V2 member report from 192.168.19.254 to 224.0.0.2
Thu Apr 8 18:04:14 2021 user.notice igmpproxy[13992]: The IGMP message was from myself. Ignoring.
Thu Apr 8 18:04:20 2021 user.notice igmpproxy[13992]: RECV Membership query from 192.168.19.254 to 224.0.0.1
Thu Apr 8 18:04:20 2021 user.notice igmpproxy[13992]: RECV V2 member report from 192.168.19.254 to 224.0.0.2
Thu Apr 8 18:04:20 2021 user.notice igmpproxy[13992]: The IGMP message was from myself. Ignoring.
Thu Apr 8 18:04:21 2021 user.notice igmpproxy[13992]: RECV V2 member report from 192.168.19.254 to 224.0.0.22
Thu Apr 8 18:04:21 2021 user.notice igmpproxy[13992]: The IGMP message was from myself. Ignoring.
Thu Apr 8 18:04:25 2021 user.notice igmpproxy[13992]: The IGMP message was local multicast. Ignoring.
Thu Apr 8 18:04:28 2021 user.notice igmpproxy[13992]: RECV Membership query from 192.168.19.254 to 224.0.0.1
Thu Apr 8 18:04:29 2021 user.notice igmpproxy[13992]: RECV V2 member report from 192.168.19.10 to 232.0.4.111
Thu Apr 8 18:04:29 2021 user.info igmpproxy[13992]: Inserted route table entry for 232.0.4.111 on VIF #1
Thu Apr 8 18:04:29 2021 user.notice igmpproxy[13992]: Joining group 232.0.4.111 on interface dsl0.840
Thu Apr 8 18:04:32 2021 user.notice igmpproxy[13992]: RECV Leave message from 192.168.19.10 to 224.0.0.2
Thu Apr 8 18:04:32 2021 user.notice igmpproxy[13992]: Leaving group 232.0.4.111 on interface dsl0.840
Thu Apr 8 18:04:32 2021 user.notice igmpproxy[13992]: RECV Membership query from 192.168.19.254 to 232.0.4.111
Thu Apr 8 18:04:33 2021 user.notice igmpproxy[13992]: RECV V2 member report from 192.168.19.10 to 232.0.4.111
Thu Apr 8 18:04:33 2021 user.info igmpproxy[13992]: Updated route entry for 232.0.4.111 on VIF #1
Thu Apr 8 18:04:33 2021 user.notice igmpproxy[13992]: Joining group 232.0.4.111 on interface dsl0.840
Thu Apr 8 18:04:33 2021 user.notice igmpproxy[13992]: RECV V2 member report from 192.168.19.10 to 232.0.4.111
Thu Apr 8 18:04:33 2021 user.info igmpproxy[13992]: Updated route entry for 232.0.4.111 on VIF #1
Thu Apr 8 18:04:36 2021 user.notice igmpproxy[13992]: The IGMP message was local multicast. Ignoring.
Thu Apr 8 18:04:36 2021 user.notice igmpproxy[13992]: RECV Leave message from 192.168.19.10 to 224.0.0.2
Thu Apr 8 18:04:36 2021 user.notice igmpproxy[13992]: Leaving group 232.0.4.111 on interface dsl0.840
Thu Apr 8 18:04:36 2021 user.notice igmpproxy[13992]: RECV Membership query from 192.168.19.254 to 232.0.4.111
Thu Apr 8 18:04:36 2021 user.notice igmpproxy[13992]: RECV V2 member report from 192.168.19.10 to 232.0.4.111
Thu Apr 8 18:04:36 2021 user.info igmpproxy[13992]: Updated route entry for 232.0.4.111 on VIF #1
Thu Apr 8 18:04:36 2021 user.notice igmpproxy[13992]: Joining group 232.0.4.111 on interface dsl0.840
Thu Apr 8 18:04:37 2021 user.notice igmpproxy[13992]: RECV V2 member report from 192.168.19.254 to 224.0.0.22
Thu Apr 8 18:04:37 2021 user.notice igmpproxy[13992]: The IGMP message was from myself. Ignoring.
Thu Apr 8 18:04:37 2021 user.notice igmpproxy[13992]: RECV Leave message from 192.168.19.10 to 224.0.0.2
Thu Apr 8 18:04:37 2021 user.notice igmpproxy[13992]: Leaving group 232.0.4.111 on interface dsl0.840
Thu Apr 8 18:04:37 2021 user.notice igmpproxy[13992]: RECV Membership query from 192.168.19.254 to 232.0.4.111
Thu Apr 8 18:04:37 2021 user.notice igmpproxy[13992]: RECV V2 member report from 192.168.19.10 to 232.0.10.86
Thu Apr 8 18:04:37 2021 user.info igmpproxy[13992]: Inserted route table entry for 232.0.10.86 on VIF #1
Thu Apr 8 18:04:37 2021 user.notice igmpproxy[13992]: Joining group 232.0.10.86 on interface dsl0.840
Thu Apr 8 18:04:38 2021 user.notice igmpproxy[13992]: RECV V2 member report from 192.168.19.254 to 224.0.0.2
Thu Apr 8 18:04:38 2021 user.notice igmpproxy[13992]: The IGMP message was from myself. Ignoring.
Thu Apr 8 18:04:40 2021 user.notice igmpproxy[13992]: RECV Leave message from 192.168.19.10 to 224.0.0.2
Thu Apr 8 18:04:40 2021 user.notice igmpproxy[13992]: Leaving group 232.0.10.86 on interface dsl0.840
Thu Apr 8 18:04:40 2021 user.notice igmpproxy[13992]: RECV Membership query from 192.168.19.254 to 232.0.10.86
Thu Apr 8 18:04:40 2021 user.notice igmpproxy[13992]: RECV V2 member report from 192.168.19.10 to 232.0.10.86
Thu Apr 8 18:04:40 2021 user.info igmpproxy[13992]: Updated route entry for 232.0.10.86 on VIF #1
Thu Apr 8 18:04:40 2021 user.notice igmpproxy[13992]: Joining group 232.0.10.86 on interface dsl0.840
Thu Apr 8 18:04:41 2021 user.notice igmpproxy[13992]: RECV V2 member report from 192.168.19.10 to 232.0.10.86
Thu Apr 8 18:04:41 2021 user.info igmpproxy[13992]: Updated route entry for 232.0.10.86 on VIF #1
Thu Apr 8 18:04:41 2021 user.notice igmpproxy[13992]: RECV Membership query from 192.168.19.254 to 232.0.4.111
Thu Apr 8 18:04:44 2021 user.notice igmpproxy[13992]: RECV Leave message from 192.168.19.10 to 224.0.0.2
Thu Apr 8 18:04:44 2021 user.notice igmpproxy[13992]: Leaving group 232.0.10.86 on interface dsl0.840
Thu Apr 8 18:04:44 2021 user.notice igmpproxy[13992]: RECV Membership query from 192.168.19.254 to 232.0.10.86
Thu Apr 8 18:04:46 2021 user.notice igmpproxy[13992]: RECV Membership query from 192.168.19.254 to 232.0.4.111
Thu Apr 8 18:04:48 2021 user.notice igmpproxy[13992]: RECV Membership query from 192.168.19.254 to 232.0.10.86
Thu Apr 8 18:04:51 2021 user.notice igmpproxy[13992]: RECV Membership query from 192.168.19.254 to 232.0.10.86
Thu Apr 8 18:05:00 2021 user.notice igmpproxy[13992]: The IGMP message was local multicast. Ignoring.
Thu Apr 8 18:05:03 2021 user.notice igmpproxy[13992]: RECV Membership query from 192.168.19.254 to 224.0.0.1
Thu Apr 8 18:05:06 2021 user.notice igmpproxy[13992]: RECV V2 member report from 192.168.19.254 to 224.0.0.22
Thu Apr 8 18:05:06 2021 user.notice igmpproxy[13992]: The IGMP message was from myself. Ignoring.
Thu Apr 8 18:05:08 2021 user.notice igmpproxy[13992]: The IGMP message was local multicast. Ignoring.
-
@ubune ??
-
J'essaye de faire tourner sur un Raspberry Pi 4 avec OpenWRT pour valider mon SFP ONT G-010S-A, j'ai fait ma conf je vois mon SFP ONT, j'ai mon statut en 05 et tous les vlans.
Par contre quand j'essaye de faire mes régles iptable pour la CoS 6 j'ai une erreur et je comprends pas ?
Je bloque dès la première ligne :
root@OpenWrt:~# iptables -t mangle -A POSTROUTING -o eth1.832 -j CLASSIFY --set-class 0000:0001
iptables v1.8.7 (legacy): unknown option "--set-class"
Try `iptables -h' or 'iptables --help' for more information.
J'avais préparé mes règles que je voulais valider à la main avant de les mettre au boot :
iptables -t mangle -A POSTROUTING -o eth1.832 -j CLASSIFY --set-class 0000:0001
iptables -t mangle -A POSTROUTING -o eth1.832 -p igmp -j CLASSIFY --set-class 0000:0006
iptables -t mangle -A POSTROUTING -o eth1.832 -p icmp -j CLASSIFY --set-class 0000:0006
iptables -t mangle -A POSTROUTING -o eth1.832 -p udp --dport 67 --sport 68 -j CLASSIFY --set-class 0000:0006
-
tru as bien mis a jour tes packages ?
opkg update
opkg install iptables-mod-ipopt ip-full
-
tru as bien mis a jour tes packages ?
opkg update
opkg install iptables-mod-ipopt ip-full
Merci à toi j'avais pas installé les deux en questions !!
J'ai pris une image snapshot de OpenWRT pour supporter pleinement le Raspberry Pi 4 avec 8Go
-
Salut Cetipabo,
J'ai répondu à ton mp mais je le vois pas dans les messages envoyés.
L'as-tu reçu ?
A+
-
Salut Cetipabo,
J'ai répondu à ton mp mais je le vois pas dans les messages envoyés.
L'as-tu reçu ?
A+
oui je l'ai recu, pour que tu le vois tu dois cocher un truc pour qu'il soit conservé dans tes éléments envoyés. Au passage j'ai créé un topic dédié pour mon problème ;D
-
Bonjour,
dites-moi, dans le cas d'un APU2C4 https://pcengines.ch/apu2c4.htm avec 3x intel i210AT donc pas de switch interne, comment fait on pour la TV ?
J'ai un modem en mode bridge relié à mon ETH0
ETH1 vers le LAN
mon décodeur TV est sur le port ETH2
(https://i.imgur.com/vniDOpg.png)
j'arrive bien à obtenir mon IPV4/V6 et comme d'hab toujours pas de TV...
Pour la partie TV j'ai adapté comme ceci dans mon /etc/config/network :
config interface 'vlantv'
option proto 'static'
option ipaddr '192.168.19.254'
option netmask '255.255.255.0'
option ifname 'eth2.19'
config interface 'tvorange'
option proto 'static'
option ipaddr '192.168.255.254'
option netmask '255.255.255.255'
option delegate '0'
option ifname 'eth0.840'
Mais aucun trafic Rx/Tx sur eth0.840, il y a autre chose à faire ? j'imagine qu'il faut bridger eth0.840 et eth2.19 en quelques sortes mais je ne maitrise pas trop cette partie là, si quelqu'un pouvait me guider...
Et je remarque aussi que mon décodeur récupère une ip en 192.168.1.100 donc sur le mauvais vlan...mais j'imagine que c'est lié.
Merci
-
Pour le bridge c'est très facile avec luci (cf la capture dans l'autre topic)
Sinon en console ça doit être un truc comme :
config interface 'BR_TV'
option type 'bridge'
option proto 'static'
option ifname 'eth0.840 eth2.19'
option ipaddr '192.168.45.23'
Côté vlan, oui y'a un truc qui cloche. Ça ressemble à quoi ?
-
Merci @renaud07, j'aime pas trop luci en fait ;D car je ne suis jamais certain qu'avec des "clics" ca fait bien ce que j'avais l'intention de faire ;D
En ligne de commande ou avec les fichiers de config, c'est plus clair je trouve.
Donc si je créé ce BR_TV dans mon /etc/config/network, est-ce que ca implique des modifications dans les fichiers de config firewall, dhcp, igmpproxy ?
Mon fichier network est comme ca:
config interface 'loopback'
option ifname 'lo'
option proto 'static'
option ipaddr '127.0.0.1'
option netmask '255.0.0.0'
config globals 'globals'
option ula_prefix 'fd06:b172:ffe3::/48'
config interface 'lan'
option type 'bridge'
option ifname 'eth1'
option proto 'static'
option ipaddr '192.168.1.1'
option netmask '255.255.255.0'
option broadcast '192.168.1.255'
option gateway '192.168.1.1'
option ip6assign '64'
list dns '81.253.149.10'
list dns '80.10.246.3'
config interface 'wan'
option ifname 'eth0.832'
option proto 'dhcp'
option peerdns '1'
option broadcast '1'
option mtu '1500'
option vendorid 'sagem'
option reqopts '1 3 6 15 28 51 58 59 90 119 120 125'
option sendopts '77:2b46535644534c5f6c697665626f782e496e7465726e65742e736f66746174686f6d652e4c697665626f7834 90:00000000000000000000001a0900000558010341010dxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx'
config interface 'wan6'
option ifname 'eth0.832'
option proto 'dhcpv6'
option reqprefix 'auto'
option reqaddress 'none'
option defaultreqopts '0'
option reqopts '11 17 23 24'
option userclass 'FSVDSL_livebox.Internet.softathome.livebox4'
option vendorclass '0000040e0005736167656d'
option sendopts '11:00000000000000000000001a0900000558010341010dxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx'
option noclientfqdn '1'
option noacceptreconfig '1'
config interface 'vlantv'
option proto 'static'
option ipaddr '192.168.19.254'
option netmask '255.255.255.0'
option ifname 'eth2.19'
config interface 'tvorange'
option proto 'static'
option ipaddr '192.168.255.254'
option netmask '255.255.255.255'
option delegate '0'
option ifname 'eth0.840'
-
Non pas besoin de modifier quoi que ce soit ailleurs.
Vu que c'est cartes indépendantes, je pense qu'il faut s'inspirer des config type ERL, donc :
-enlever le VLAN de eth2 (avant c'était le switch qui détaggait, hors là il n'y est plus) et adapter le DHCP en conséquence
-vérifier, vu que eth2 récupère une ip du lan, que eth1 et eth2 ne sont pas bridgés quelque part via un autre fichier (car là c'est pas le cas, il n'y que eth1 dans ifname)
Si ça fonctionne dans cette config, retenter igmpproxy d'abord. Peut-être que ça fonctionnera cette fois, sinon bridge.
Pour le bridge ça devient :
config interface 'BR_TV'
option type 'bridge'
option proto 'static'
option ifname 'eth0.840 eth2'
option ipaddr '192.168.45.23'
Concernant luci, perso je trouve ça pratique justement quand on ne connais pas bien la syntaxe et ça permet de voir en un coup d’œil comment sont arrangées les interfaces (ce qui aiderait bien dans ce cas).
-
Je suis en train de faire les modifs, mais coté DHCP, que devient le "vlantv' ??
j'ai basculé toutes les options dhcp coté lan :
config dhcp 'lan'
option interface 'lan'
option leasetime '12h'
option start '10'
option limit '100'
option ra 'server'
list dhcp_option '6,80.10.246.2,80.10.246.129'
list dhcp_option '15,orange.fr'
list dhcp_option '125,xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx'
mais la partie config dhcp 'vlantv' je la supprime ?
-
Dans ce cas oui il faut le virer.
-
ok, donc là dans ce cas le decodeur trouve pas le routeur...pas d'ip recu en dhcp, il est en erreur direct.
il doit y avoir des trucs relatifs a modifier dans le firewall non ? et igmpproxy aussi ? partout ou ca fait référence a 'vlantv'.
Mais si on vire 'vlantv' de DHCP comment le décodeur relié cette interface va obtenir une IP ??
-
Il est bizarre ton routeur. Il attribue une ip lan sur eth2 quand le dhcp était sur le vlan, et là il veut plus.
Tentes de remettre le DHCP sur eth2 alors...
-
a force de bidouiller j'ai du changer un paramettre quelque part, je ne sais pas ou, impossible d'avoir une ip sur le decodeur alors que je suis revenu aux paramettres précédents...
-
Bon,
Après avoir sniffé la conversation entre ma Box et le décodeur, je viens de voir une erreur de compréhension de ma part concernant l'adresse MAC à indiquer ici :
(https://i.imgur.com/ccfynvb.png)
Moi je mettais l'adresse MAC complete tel quel, au lieu de convertir en Hexa individuellement les 3 premiers octets de la MAC (ou les 6 premiers caractères), donc YY:YY:YY:YY:YY:YY
je suis avec une LB4 et un Decodeur4 et pas 5...Est-ce que mon souci viendrait de la ? peut etre qu'en VDSL c'est devenu obligatoire ?
Autre point, les options retournées par ma livebox au décodeur en plus de la 125 :
Option 1 = 255.255.255.0
Option 3 = 192.168.1.1
Option 6 = 192.168.1.1
Option 15 = home
Option 28 = 192.168.1.255
Donc pour l'option 6 et 15 ce n'est pas ce qui est indiqué dans le tuto, ca n'a peut etre pas d'incidence mais si on veut vraiment reproduire ce que fait la livebox c'est à savoir.
Me reste plus qu'a tester...quand ma femme aura libéré la TV >:( >:( ;D
EDIT:
Bon ben je cale encore, ca vient pas de là...
J'ai parametré dnsmasq pour envoyer exactement les meme options, avec les meme valeurs que la livebox. Toujours pas de flux TV....On peut écarter la partie DHCP, je suis 100% certain que tout est bon de ce côté.
ya plus que 2 possibilités, Igmpproxy ou le Firewall.
-
Pour le FW, tu peux essayer en mettant tout à accept (entre la zone TV et le wan/840), théoriquement tout devrait passer sans restriction.
Sinon tentes le bridge...
Pour rappel, je ne peux faire que des suppositions, j'ai toujours pas la TV pour tester.
-
tout sur accept j'ai deja essayé...pas mieux.
le bridge comme tu as montré j'ai tenté aussi. c'est un truc de fou je ne comprends pas ou ca peut bloquer.
j'ai remis l'apu2c4 dans le tiroir, je me suis remis sur le BTHH5 pour eviter de multiplier les peripheriques et donc des problemes supplémentaires.
Coté DHCP je fais tout comme la livebox, j'ai meme mis la MAC de la livebox sur le wan, pour essayer de mimer au mieux la livebox. il n'y a toujours aucun trafic en réception sur le 840.
incomprehensible.
J'ai essayé de virer le vlan 19 pour faire au plus simple, et c'est pareil.
Ce qui me rend le plus dingue dans tout ca c'est que j'ai l'impression d'etre le seul en VDSL à essayer de faire marcher la TV sur autre chose qu'une LB. >:(
-
Je viens de penser : Si tu forces la connexion en ADSL pour voir ?
J'ai peu d'espoir que ça fonctionne mieux, mais vu que t'as tout essayé, je vois pas trop quoi tenter d'autre.
Pour rappel :
config atm-bridge
option atmdev '0'
option encaps 'llc'
option payload 'bridged'
option nameprefix 'dsl'
option vpi '8'
option vci '32'
option unit '0'
config atm-bridge
option atmdev '0'
option encaps 'llc'
option payload 'bridged'
option nameprefix 'dsl'
option vci '40'
option vpi '8'
option unit '1'
Avec cette config, il faut envoyer le dhcp sur dsl0 et dsl1 pour la TV
-
heuuu non mais meme si ca marchait comme ca je vais pas me mettre en adsl pour avoir la TV ;D ;D
Tien au passage, je viens de retrouver mon post, debut 2018 ou déjà j'indiquais mon problème:
https://lafibre.info/remplacer-livebox/tv-sur-le-vlan-840-ne-fonctionne-plus/
ca va faire 3 ans
-
Oui je me doute bien que tu ne resteras pas en ADSL, mais ça permettrait de confirmer ou infirmer si le type de connexion influe ou non.
-
dans les 2 config, le option nameprefix 'dsl' est le même ?
il va sortir d'ou le 'dsl1' ?
-
Oui c'est le même, ça sert à renommer l'interface, sinon c'est "nas0, nas1...", dsl est plus parlant.
Le numéro dépend de l'option unit. Tu peux mettre n'importe lequel genre 832 pour faire dsl832 (enfin je suppose, pas testé)
-
Au vue des traces de toute façon tout semblait bon, la config est ok.
On a juste pas pu vérifier la COS sur le flux IGMP en sortie de VLAN 840, mais puisque sur ton modem/routeur le script fonctionne pour le net ça devrait être le cas aussi pour le vlan 840.
En revanche y'a t il d'autres personnes qui ont remplacé la livebox en VDSL avec un service TV fonctionnel sur le Forum ?
Il y a p-e une autre subtilité en VDSL.
-
En revanche y'a t il d'autres personnes qui ont remplacé la livebox en VDSL avec un service TV fonctionnel sur le Forum ?
Il y a p-e une autre subtilité en VDSL.
A ce stade j'en suis moi aussi convaincu, il doit y avoir un autre parametre, soit valable uniquement dans mon secteur, soit pour toutes les connexions VDSL ?
c'est quand meme incroyable que je sois le seul en VDSL a essayer à mettre en place la TV avec autre chose qu'une LiveBox. S'il y a une personne pour qui ca fonctionne qu'il se manifeste SVP !!
Après j'ai un modem Bridge VDSL (HG612) celui que j'utilise avec mon APU2C4, est-ce que si on le branchait sur le port WAN de la livebox, celle ci marcherait ?
Du coup je pourrais coller un switch administrable entre les deux j'ai un Netgear GS308T (https://www.netgear.fr/support/product/gs308t.aspx) pour essayer de faire un port mirroring et capturer ce qui sort de la livebox sur le vlan 840 ?
Pour ce qui est de l'option 125 et des autres d'ailleurs, je ne pense pas avoir fait d'erreur...je ne vois pas ou ca pourrait coincer si ce n'est un parametre indispensable que j'aurais omis. Mais sans aucune personne en VDSL avec TV qui fonctionne, on ne pourra pas savoir....
-
Disclamer : JE suis un noob dans le domaine des routeurs et réseau ^^'
Bonjour,
Je viens par ici car dans l'idée c'est ce que je souhaite faire, utiliser mon routeur sans LB avec orange fibre (uniquement le net, a voir pour la télé, mais ça me semble pas jouable)
Sauf que : J'ai un AX3600 qui n'est actuellement pas supporter par openWRT, cependant, le firmware du routeur est basé sur une la 18.06. (downgradé, activation SSH permanente, retour sur le firmware globale avec SSH actif)
Le tuto m'a aider a un peu mieux comprendre ce qui doit ce passer dans le routeur, mais je sais pas si c'est possible, car je n'ai pas su vérifier si les outils obligatoire était dans le routeur Xiaomi..
ça vous semble jouable d'avoir internet sans passer par la LB dans l’état ?
-
salut @0beey
- Si le firmware est basé sur un openwrt
- Si tu as un accés root par SSH,
- Si les paquets necessaires (iptables-mod-ipopt / ip-full) sont pré-installés. igmpproxy utile pour la TV uniquement.
alors je dirais que oui. le tuto de ce topic devrait fonctionner.
-
d'acc, comment je peux vérifier que les paquet : iptables-mod-ipopt / ip-full ?
Le firmware est bien basé sur openwrt et j'ai bien l’accès SSH fonctionnel
Edit : pour les paquets, certes via opkg je n'ai pas accès de par le firmware modifier
modifier les repository ou installer les paquets à la main semble jouable ?
-
si la commande opkg est présente, tu pourras voir les paquets installés avec la commande:
opkg list-installed
les paquets iptables-mod-ipopt et ip-full servent dans le script vlanprio.sh pour definir les priorités des vlans.
sans ces paquets on ne peut pas executer les commandes :
ip link set ..........
-
Super merci, justement je cherchais sur le net une commande opkg de ce genre
j'ai bien iptables-mod-ipopt - 1.6.2-2
Par contre pas de paquet ip-full
cependant, la commande ip -h répond
root@XiaoQiang:~# ip -h
Usage: ip [ OPTIONS ] OBJECT { COMMAND | help }
ip [ -force ] -batch filename
where OBJECT := { link | addr | addrlabel | route | rule | neigh | ntable |
tunnel | tuntap | maddr | mroute | mrule | monitor | xfrm |
netns | l2tp }
OPTIONS := { -V[ersion] | -s[tatistics] | -d[etails] | -r[esolve] |
-f[amily] { inet | inet6 | ipx | dnet | link } |
-l[oops] { maximum-addr-flush-attempts } |
-o[neline] | -t[imestamp] | -b[atch] [filename] |
-rc[vbuf] [size]}
Avant la commande opkg, j'avais vu la présence du fichier ip dans /usr/sbin
A priori, il y a ce qu'il faut pour me passer de la box
Pas de trace d'igmpproxy, mais osef pour le moment, avec un peu de chance il y aura un support officiel d'openwrt pour ipx807x un de ces 4
Quand je lance un opkg update j'ai ça
Downloading http://downloads.openwrt.org/releases/18.06-SNAPSHOT/packages/aarch64_cortex-a53/base/Packages.gz
si je tente l'install d'un paquet --> Read only
Bon, il me reste a apprendre comment ça marche tout ça et tenter de faire marcher le wan
-
si je tente l'install d'un paquet --> Read only
hummm ca devrait pas etre dur a contourner ca, ca me dit quelque chose...
edit:
https://forum.archive.openwrt.org/viewtopic.php?id=44738
mtd unlock rootfs_data
-
Ça ne fonctionne pas, mais à priori, j'ai ce qu'il faut pour le WAN
J'ai essayé bête est méchant les fichier du git de l'auteur
J'ai planter le routage en lan, un petit reset et c'est reparti
Sûrement qu'il faille un peu adapter 😅
-
Ça ne fonctionne pas, mais à priori, j'ai ce qu'il faut pour le WAN
J'ai essayé bête est méchant les fichier du git de l'auteur
J'ai planter le routage en lan, un petit reset et c'est reparti
Sûrement qu'il faille un peu adapter 😅
Salut,
Oui ce que tu vas devoir adapter sur ton modèle c'est la config "Switch" dans /etc/network, le mappage port/Vlan/Cpu
-
@ubune, il faudrait que tu nous refasses ton tuto mais sans faire de vlan pour la TV, le truc le plus basique et universel possible.
Quand ca marchait chez moi je n'avais pas besoin de vlan pour la TV, l'igmp snooping faisait le taf. Suffit de ne pas ajouter de switch qui ne le gèrent pas entre le decodeur et la livebox.
-
@ubune, il faudrait que tu nous refasses ton tuto mais sans faire de vlan pour la TV, le truc le plus basique et universel possible.
Quand ca marchait chez moi je n'avais pas besoin de vlan pour la TV, l'igmp snooping faisait le taf. Suffit de ne pas ajouter de switch qui ne le gèrent pas entre le decodeur et la livebox.
Salut,
Alors déjà le "il faudrait que nous refasses", on oublie hein ^^' .
Si j'ai fait le choix de sortir la tv du lan, c'est en effet pour éviter de devoir utiliser l'igmp snooping, qui comme tu le dis fonctionne, mais pose des soucis si on reprend la conf mais avec des mini Switch derrière par exemple.
Sortir la TV du lan oblige l'utilisateur à s'y intéresser et du coup permet d'éviter cette problématique.
Mais c'est également pour avoir une gestion Firewall plus "saine", avec autorisation des flux entre vlan 840 et vlan 19 décodeur.
De plus, de mon avis ça ne change pas grand chose en faite niveau difficulté, hormis de savoir associer un port sur un vlan et de brancher le décodeur sur le bon port.
C'est un choix et je comprends que tout le monde n'y adhère pas, c'est pour ça qu'il y a le post #3 du tuto avec les "Alternatives", et un detail sur comment mettre la TV sur le Lan Classique.
Mais du coup je vais plutôt mieux détailler ce post que modifier le tuto ;).
-
;D je ne parlais pas de changer le tuto actuel, mais d'ajouter une "version" alternative sans le vlan tv. Une petite adaptation du post#1 mais pas du type "ya qu'a ajouté ça" et "ya qu'a remplacer ça".
En gros un copié/collé de l'existant avec les 2 ou 3 adaptations. J'ai essayé de mettre en place moi meme cette version, mais je ne peux pas dire que je sois sur de moi a 100% pour la partie Firewall. Je ne suis pas a l'abris d'avoir oublié un truc ou mal interpreté un truc. c'est pour ca qu'une bonne base de départ ca permet d'enlever les doutes. Après libre a chacun de complexifier ou améliorer.
-
Hello,
J'ai suivi ce tuto, ça fonctionne bien. Par contre, la méthode de passer par défaut en piro VLAN 6 puis de router via iptables ne me suffit pas, car j'aimerais activer le flow offload (disponible depuis OpenWRT 19.07 pour l'Archer C7 v5 que j'utilise). Sinon le proc est noyé par les IRQ, et les débits sont bridés ce qui est dommage (même si on arrive quand même à plus de 300 mbps ce qui est déjà pas si mal). Avec l'offload et avec ma vieille offre de base je suis manifestement en 400/400.
J'ai donc patché (à la rache) les clients DHCP d'OpenWRT (oui en v4 ils utilisent busybox, et en v6 odhcp6c qui sont donc disctincts). J'ai donc bien les paquets DHCP avec la prio VLAN, et uniquement eux, ce qui permet de laisser les flux passer sans jouer avec iptables, et donc d'activer l'offload.
Il faut tout de même évidemment mapper une des prio kernel en prio VLAN. J'ai pris la 6. Seulement a priori le système de ifup d'OpenWRT ne permet pas de hook en pre-up et donc de placer le mapping avant l'envoi des paquets DHCP de façon certaine (si l'interface VLAN est coupée, il faut recommencer etc.). J'ai donc fait faire ça à busybox dans la foulée (et, oui, c'est doublement crade du coup).
Bien sûr le reste du tuto reste vrai, ceci ne remplace QUE la partie iptables et script vlanprio dans le cas où on est dans une zone qui nécessite le tag VLAN PRIO. Et bien sûr cela est à refaire à chaque mise à jour (compiler en amont pour éviter les surprises et télécharger le SDK, copier les exécutables après…) ce qui peut paraitre un peu lourd !
Patch dégueu pour busybox (prio sur la socket et egress mapping) :
--- busybox-1.30.1.orig/networking/udhcp/packet.c
+++ busybox-1.30.1/networking/udhcp/packet.c
@@ -115,6 +115,20 @@ int FAST_FUNC udhcp_send_raw_packet(stru
const char *msg;
fd = socket(PF_PACKET, SOCK_DGRAM, htons(ETH_P_IP));
+#include <linux/sockios.h>
+#include <linux/if_vlan.h>
+#include <net/if.h>
+const int VLAN_DHCP_PRIORITY = 6;
+char *buf[IF_NAMESIZE];
+setsockopt(fd, SOL_SOCKET, SO_PRIORITY, &VLAN_DHCP_PRIORITY, sizeof(VLAN_DHCP_PRIORITY));
+struct vlan_ioctl_args vlan_args;
+vlan_args.cmd=SET_VLAN_EGRESS_PRIORITY_CMD;
+vlan_args.u.skb_priority=6;
+vlan_args.vlan_qos=6;
+if_indextoname(ifindex, buf);
+strcpy(vlan_args.device1,buf);
+
+ioctl (fd,SIOCSIFVLAN, &vlan_args);
if (fd < 0) {
msg = "socket(%s)";
goto ret_msg;
Patch pour odhcp6c (prio sur la socket uniquement car egress déjà fait par busybox en v4) :
--- build_dir/target-mips_24kc_musl/odhcp6c-2019-01-11-e199804b/src/dhcpv6.c.orig 2020-03-30 10:26:51.191836514 +0200
+++ build_dir/target-mips_24kc_musl/odhcp6c-2019-01-11-e199804b/src/dhcpv6.c 2020-03-30 10:27:51.531659035 +0200
@@ -140,6 +140,9 @@
ifindex = ifr.ifr_ifindex;
+const int VLAN_DHCP_PRIORITY = 6;
+setsockopt(sock, SOL_SOCKET, SO_PRIORITY, &VLAN_DHCP_PRIORITY, sizeof(VLAN_DHCP_PRIORITY));
+
// Create client DUID
size_t client_id_len;
odhcp6c_get_state(STATE_CLIENT_ID, &client_id_len);
Il suffit alors simplement de copier les nouveau exécutables à la place de ceux de base (ils se retrouveront donc sur l'overlay).
Procédure pour moi à partir du SDK de 19.07.2 et pour l'Archer C7 (999-vlan-prio.patch contenant le patch pour busybox et 192.168.1.42 l'IP du routeur pendant les tests) :
./scripts/feeds update -a
./scripts/feeds install busybox
cp 999-vlan-prio.patch ./feeds/base/package/utils/busybox/patches/
make package/busybox/compile
scp build_dir/target-mips_24kc_musl/busybox-1.30.1/.pkgdir/busybox/bin/busybox root@192.168.1.42:/bin
./scripts/feeds install odhcp6c
make package/odhcp6c/prepare
nano build_dir/target-mips_24kc_musl/odhcp6c-2019-01-11-e199804b/src/dhcpv6.c (et appliquer le patch à la main, ou directement via patch -p1)
make package/odhcp6c/compile
scp ./build_dir/target-mips_24kc_musl/odhcp6c-2019-01-11-e199804b/.pkgdir/odhcp6c/usr/sbin/odhcp6c root@192.168.1.42:/usr/sbin/
Debug :
busybox udhcpc -i eth0.832
cat /proc/eth0.832
À voir si ça peut en aider certains ou si je peux améliorer la présentation, c'est sûr que c'est très technique et que je ne réexplique pas tous les concepts sinon on s'en sortirait pas :)
Je ne pense pas soumettre ces patchs aux projets concernés car c'est quand même très très spécifique… et qu'ils contiennet la partie de configuration egress du VLAN ce qui n'est pas pertinent à cet endroit dans le cas général.
Waaaaaaaaaaa... Trop bien ! C'est peut-être dégueu, mais ça marche du feu de dieu ! Effectivement, en activant le software flow offloading, le débit sur mon Archer C7 v2 s'écroulait (50 Mbits en download, 0,5 Mbits en upload, en Ethernet filaire ou en WIFI 2.4 Ghz ou 5 Ghz). Après recompilation des clients dhcp patchés (SDK Openwrt 19.07.7 pour ma part), transfert sur le routeur, suppression de l'appel à /etc/vlanprio.sh dans /etc/rc.local, désactivation de toutes les custom rules du firewall (iptables -t mangle -A POSTROUTING -j CLASSIFY --set-class etc...), activation du software flow offloading, j'ai un débit supérieur à 200 Mbits en download/upload en WIFI 5 Ghz 802.11ac (test sur nperf.com/fr, avec un laptop DELL qui n'a certainement que 2 antennes), alors que je plafonnais auparavant à 110 Mbits !
Prochaine étape : claquer le bootloader BREED sur le Archer C7 v2 et overclocker légèrement les CPU/DDR/AHB (https://forum.openwrt.org/t/archer-c7-5ghz-performance-sirq-99/63104/30) pour voir si on ne peut pas gagner encore un petit peu sur le débit du WIFI 5 Ghz 802.11ac.
Merci johndescs !
PS : Je me suis même permis de supprimer la partie VLAN egress du patch busybox, car finalement en créant le fichier 05-vlanprio (+ chmod 755 sur ce fichier) suivant et en le mettant dans le répertoire /etc/hotplug.d/iface/, ça marche tout pareil :
#!/bin/sh
set -x
ip link set eth0.832 type vlan egress 6:6 >/dev/null
-
Edit : ça fonctionne après avoir pris les fichiers du repo github et n'enlever que ce qui ne concernait pas mon AP (renommber eth1 en eth0, supprimer les config switch, supprimer vlantv) ! Un énorme merci à @ubune pour la doc, même si je n'arrive à tirer que 80M au lieu de 300 (sans doute pas d'accélération HW puisque c'est un AP et pas un routeur) ça nous permet d'attendre la nouvelle LiveBox avec sérénité.
Salut, et merci beaucoup pour ce tuto !
Ma LiveBox a rendu l'âme, et le temps d'en obtenir une nouvelle j'ai flashé mon Unifi AP AC LR avec OpenWRT 19.07 pour essayer de la remplacer le temps que la nouvelle arrive. J'ai un boitier fibre HG8010Hv3, et mon point d'accès Unifi n'a qu'un seul port Ethernet, que j'aimerais utiliser comme WAN, du coup on ne peut se connecter qu'en WiFi.
J'ai suivi le guide pour une IPv4 et essayé de supprimer toutes les configs Switch puisque je n'ai pas ces ports, et IGMP proxy puisque je n'ai pas de boitier TV (Sosh de base), mais le WAN n'obtient pas d'IP :
root@OpenWrt:~# ifstatus wan
{
"up": false,
"pending": true,
"available": true,
"autostart": true,
"dynamic": false,
"proto": "dhcp",
"device": "eth0",
"data": {
}
}
Voici mes différents fichiers (j'ai remis le FTI de démo) :
root@OpenWrt:~# cat /etc/config/network
config interface 'loopback'
option ifname 'lo'
option proto 'static'
option ipaddr '127.0.0.1'
option netmask '255.0.0.0'
config globals 'globals'
option ula_prefix 'fd2d:aab4:3913::/48'
config interface 'lan'
option type 'bridge'
option proto 'static'
option ipaddr '192.168.1.1'
option netmask '255.255.255.0'
option ip6assign '60'
config interface 'wan'
option ifname 'eth0'
option proto 'dhcp'
option vendorid 'sagem'
option broadcast '1'
option reqopts '1 15 28 51 58 59 90'
option sendopts '77:2b46535644534c5f6c697665626f782e496e7465726e65742e736f66746174686f6d652e4c697665626f7834 90:00000000000000000000001a0900000558010341010d6674692f71707138383838'
root@OpenWrt:~# cat /etc/config/dhcp
config dnsmasq
option domainneeded '1'
option boguspriv '1'
option filterwin2k '0'
option localise_queries '1'
option rebind_protection '1'
option rebind_localhost '1'
option local '/lan/'
option domain 'lan'
option expandhosts '1'
option nonegcache '0'
option authoritative '1'
option readethers '1'
option leasefile '/tmp/dhcp.leases'
option resolvfile '/tmp/resolv.conf.auto'
option nonwildcard '1'
option localservice '1'
config dhcp 'lan'
option interface 'lan'
option start '100'
option limit '150'
option leasetime '12h'
option dhcpv6 'server'
option ra 'server'
option ra_management '1'
config dhcp 'wan'
option interface 'wan'
option ignore '1'
config odhcpd 'odhcpd'
option maindhcp '0'
option leasefile '/tmp/hosts/odhcpd'
option leasetrigger '/usr/sbin/odhcpd-update'
option loglevel '4'
root@OpenWrt:~# cat /etc/config/firewall
config defaults
option syn_flood '1'
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'REJECT'
config zone
option name 'lan'
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'ACCEPT'
option network 'lan'
config zone
option name 'wan'
option input 'REJECT'
option output 'ACCEPT'
option forward 'REJECT'
option masq '1'
option mtu_fix '1'
option network 'wan wan6'
config forwarding
option src 'lan'
option dest 'wan'
config rule
option name 'Allow-DHCP-Renew'
option src 'wan'
option proto 'udp'
option dest_port '68'
option target 'ACCEPT'
option family 'ipv4'
config rule
option name 'Allow-Ping'
option src 'wan'
option proto 'icmp'
option icmp_type 'echo-request'
option family 'ipv4'
option target 'ACCEPT'
config rule
option name 'Allow-IGMP'
option src 'wan'
option proto 'igmp'
option family 'ipv4'
option target 'ACCEPT'
config rule
option name 'Allow-DHCPv6'
option src 'wan'
option proto 'udp'
option src_ip 'fc00::/6'
option dest_ip 'fc00::/6'
option dest_port '546'
option family 'ipv6'
option target 'ACCEPT'
config rule
option name 'Allow-MLD'
option src 'wan'
option proto 'icmp'
option src_ip 'fe80::/10'
list icmp_type '130/0'
list icmp_type '131/0'
list icmp_type '132/0'
list icmp_type '143/0'
option family 'ipv6'
option target 'ACCEPT'
config rule
option name 'Allow-ICMPv6-Input'
option src 'wan'
option proto 'icmp'
list icmp_type 'echo-request'
list icmp_type 'echo-reply'
list icmp_type 'destination-unreachable'
list icmp_type 'packet-too-big'
list icmp_type 'time-exceeded'
list icmp_type 'bad-header'
list icmp_type 'unknown-header-type'
list icmp_type 'router-solicitation'
list icmp_type 'neighbour-solicitation'
list icmp_type 'router-advertisement'
list icmp_type 'neighbour-advertisement'
option limit '1000/sec'
option family 'ipv6'
option target 'ACCEPT'
config rule
option name 'Allow-ICMPv6-Forward'
option src 'wan'
option dest '*'
option proto 'icmp'
list icmp_type 'echo-request'
list icmp_type 'echo-reply'
list icmp_type 'destination-unreachable'
list icmp_type 'packet-too-big'
list icmp_type 'time-exceeded'
list icmp_type 'bad-header'
list icmp_type 'unknown-header-type'
option limit '1000/sec'
option family 'ipv6'
option target 'ACCEPT'
config rule
option name 'Allow-IPSec-ESP'
option src 'wan'
option dest 'lan'
option proto 'esp'
option target 'ACCEPT'
config rule
option name 'Allow-ISAKMP'
option src 'wan'
option dest 'lan'
option dest_port '500'
option proto 'udp'
option target 'ACCEPT'
config include
option path '/etc/firewall.user'
root@OpenWrt:~# cat /etc/firewall.user
# This file is interpreted as shell script.
# Put your custom iptables rules here, they will
# be executed with each firewall (re-)start.
# Internal uci firewall chains are flushed and recreated on reload, so
# put custom rules into the root chains e.g. INPUT or FORWARD or into the
# special user chains, e.g. input_wan_rule or postrouting_lan_rule.
iptables -t mangle -A POSTROUTING -j CLASSIFY --set-class 0000:0001
iptables -t mangle -A POSTROUTING -p icmp -j CLASSIFY --set-class 0000:0006
iptables -t mangle -A POSTROUTING -o eth0 -p igmp -j CLASSIFY --set-class 0000:0006
iptables -t mangle -A POSTROUTING -o eth0 -p udp --dport 67 -j CLASSIFY --set-class 0000:0006
root@OpenWrt:~# cat /etc/rc.local
# Put your custom commands here that should be executed once
# the system init finished. By default this file does nothing.
sleep 10
ifdown wan
sh /etc/vlanprio.sh
ifup wan
exit 0
root@OpenWrt:~# cat /etc/vlanprio.sh
#!/bin/sh
set -x
for i in 0 1 2 3 4 5 6 7; do
ip link set eth0 type vlan egress $i:$i >/dev/null
done
ip link set eth0 type vlan egress 1:0 >/dev/null
ip link set eth0 type vlan egress 0:6 >/dev/null
Est-ce que vous avez une idée de pourquoi ça ne fonctionnerait pas, et un moyen de vérifier les bons logs? dmesg me donne :
[ 27.623887] br-lan: port 1(wlan0) entered blocking state
[ 27.629385] br-lan: port 1(wlan0) entered disabled state
[ 27.635177] device wlan0 entered promiscuous mode
[ 28.269337] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[ 28.276134] br-lan: port 1(wlan0) entered blocking state
[ 28.281627] br-lan: port 1(wlan0) entered forwarding state
[ 28.307245] IPv6: ADDRCONF(NETDEV_CHANGE): br-lan: link becomes ready
[ 34.797215] eth0: link down
[ 34.891870] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[ 34.899726] eth0: link up (1000Mbps/Full duplex)
[ 34.905016] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[ 1056.518032] eth0: link down
[ 1056.534969] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[ 1056.542871] eth0: link up (1000Mbps/Full duplex)
[ 1056.548521] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[ 1071.712046] eth0: link down
[ 1071.744025] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[ 1071.751828] eth0: link up (1000Mbps/Full duplex)
[ 1071.757552] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
Et les logs système lorsque je redémarre le WAN, on dirait qu'il n'arrive pas à obtenir d'IP :
Fri Jul 2 15:57:28 2021 daemon.notice netifd: wan (2152): udhcpc: received SIGTERM
Fri Jul 2 15:57:28 2021 daemon.notice netifd: Interface 'wan' is now down
Fri Jul 2 15:57:28 2021 kern.info kernel: [ 2513.653258] eth0: link down
Fri Jul 2 15:57:28 2021 daemon.notice netifd: Interface 'wan' is disabled
Fri Jul 2 15:57:28 2021 kern.info kernel: [ 2513.674441] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
Fri Jul 2 15:57:28 2021 kern.info kernel: [ 2513.682235] eth0: link up (1000Mbps/Full duplex)
Fri Jul 2 15:57:28 2021 daemon.notice netifd: Interface 'wan' is enabled
Fri Jul 2 15:57:28 2021 daemon.notice netifd: Interface 'wan' is setting up now
Fri Jul 2 15:57:28 2021 kern.info kernel: [ 2513.687515] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
Fri Jul 2 15:57:28 2021 daemon.notice netifd: wan (2326): udhcpc: started, v1.30.1
Fri Jul 2 15:57:28 2021 daemon.notice netifd: wan (2326): udhcpc: sending discover
Fri Jul 2 15:57:31 2021 daemon.notice netifd: wan (2326): udhcpc: sending discover
Fri Jul 2 15:57:34 2021 daemon.notice netifd: wan (2326): udhcpc: sending discover
Merci !
-
Salut ndfred,
Remplacer sa Livebox par son ap wifi lors d'une panne, c'est pour le moins original !
Super content si tu as pu te dépanner comme ça ;).
-
Ca fonctionne super depuis hier ! J'ai tenté l'upgrade OpenWrt 21.02.0-rc3 et ça fonctionne toujours, avec en bonus le WPA 3 et le nouveau support de l'option "Coverage cell density" qui permet d'ajuster le min transmit rate comme je le fais d'habitude sur le contrôleur Ubiquiti. L'IPv6 fonctionne également, vraiment top.
-
salut, je suis anglais, excusez mon français
j'ai un BT home hub 5
la connexion DSL est réussie mais je n'ai toujours pas accès à internet
Des idées de dépannage s'il vous plait?
mon network config
config interface 'loopback'
option ifname 'lo'
option proto 'static'
option ipaddr '127.0.0.1'
option netmask '255.0.0.0'
config globals 'globals'
option ula_prefix 'fdbb:473b:26a6::/48'
config atm-bridge 'atm'
option vpi '1'
option vci '32'
option encaps 'llc'
option payload 'bridged'
option nameprefix 'dsl'
config dsl 'dsl'
option ds_snr_offset '0'
option tone 'a'
option annex 'b'
config interface 'lan'
option type 'bridge'
option ifname 'eth0.1'
option proto 'static'
option ipaddr '192.168.1.1'
option netmask '255.255.255.0'
option ip6assign '60'
config device 'lan_eth0_1_dev'
option name 'eth0.1'
option macaddr '84:a4:23:06:4f:fa'
config interface 'wan'
option ifname 'dsl0.101'
option proto 'dhcp'
option vendorid 'sagem'
option reqopts '1 15 28 51 58 59 90'
option sendopts '77:2b46535644534c5f6c697665626f782e496e7465726e65742e736f66746174686f6d652e4c697665626f7834 90:00000000000000000000001a0900000558010341010dxxxxxxxx'
config device 'wan_dsl0_dev'
option name 'dsl0'
option macaddr '84:a4:23:06:4f:fb'
config interface 'wan6'
option proto 'dhcpv6'
option reqprefix 'auto'
option ifname 'eth0.832'
option reqaddress 'none'
option defaultreqopts '0'
option sendopts '11:00000000000000000000001a0900000558010341010dxxxxxxxxxxxxx 15:FSVDSL_livebox.Internet.softathome.livebox4 16:0000040e0005736167656d'
option reqopts '11 17 23 24'
option noclientfqdn '1'
option noacceptreconfig '1'
option auto '0'
config switch
option name 'switch0'
option reset '1'
option enable_vlan '1'
config switch_vlan
option device 'switch0'
option vlan '1'
option ports '6t 4 2 0 1'
option vid '1'
config switch_vlan
option device 'switch0'
option vlan '2'
option ports '6t 5'
option vid '832'
-
@punteruk
config interface 'wan'
option ifname 'dsl0.832'
c'est le vlan 832 et pas 101 !
-
bien vu, merci!
mais quand je change et redémarre, il revient à 101 car cela semble être le "nom du hardware"? :-\
-
ok vous mettez simplement dsl0.832 dans la boîte '-- custom --'
travaille maintenant! très bien! routeur britannique pas cher fonctionnant en France lol
-
Salut tout le monde,
Je suis nouveau sur le site.
DOnc en résumé, j'ai ma box qui a cramé, et je me suis dit que je pouvais essayer de la remplacer par un Xiaomi AC2350 sous openWRT.
Donc j'ai suivi tout le tuto en essayant de l'adapter au AC2350.
Là dans le syslog je vois que la box semble arriver à avoir une adresse ip d'orange 172.x.x.x.
Par contre, quand je fais ifstatus wan.. c'est vide.
Quelqu'un pour m'aider à dépatouiller tout ca?
Je ne sais aps trop ce qu'il vous faut comme info pour m'aider. les fishier de config network à minima?
Merci d'avance.
-
bon à première vue, problème résolu!
J'avais un soucis au niveau des requête dhcp. J'ai changé le Rc.local en rajoutant un bout de code que j'ai trouvé dans le thread :
que voici
sleep 1
# Default to CoS 6 on WAN for DHCP requests to be accepted
ip link set eth0.832 type vlan egress 0:6
# Queue 6 to CoS 6 on WAN
ip link set eth0.832 type vlan egress 6:6
# Everything else to CoS 0 on WAN, through iptables
ip link set eth0.832 type vlan egress 1:0
# workaround private ip address on WAN
ifdown wan && ifup wan
ifdown wan6 && ifup wan6
Il faudra que je teste les débit, mais pour le moment ca m'a l'air pas trop mal!
Merci pour le tuto et les commentaire des uns et des autres qui permettent de faire avancer le schmilblick
-
Quelqu'un a t-il une idée pour envoyer des options depuis un serveur DHCP à un client (Livebox) ?
Je voudrais envoyer l'option 90 et 120 pour que la Livebox soit opérationnelle sur un OpenWRT.
Le port WAN de la Livebox est branché sur le port 5 du routeur, le VLAN 832 de cette interface est activé ainsi que le serveur DHCP.
J'ai essayé d'envoyer les options via le fichier /etc/config/dhcp et via l'interface Luci. Mais la Livebox ne veut rien savoir.
Je me suis connecté avec mon PC sur l'interface 5 en étant dans le VLAN 832, j'obtiens une IP du serveur DHCP, mais quand je fais une capture de trafic je n'ai pas les options 90 et 120 qui viennent s'ajouter aux autres...
Option 90 : dhcpliveboxfr250
Option 120 : sbct3g.lyo.access.orange-multimedia.net
Le DHCP Offer d'Orange :
(https://i.gyazo.com/5972ab2cdc83310273d5271722189dec.png)
Dois-je utiliser l'Héxa ou ASCII ?
-
Il manque au moins aussi l’option 125 qui est obligatoire. Bizarre que tu la vois pas sur le dump de l’offer d’orange…. Chez moi (pas sous openwrt) :
subnet-parameters "option rfc3118-auth 00:00:00:00:00:00:00:00:00:00:00:64:68:63:70:6c:69:76:65:62:6f:78:66:72:32:35:30;"
subnet-parameters "option Vendor-specific 00:00:05:58:0c:01:0a:00:01:00:00:00:ff:ff:ff:ff:ff;"
subnet-parameters "option SIP 00:06:73:62:63:74:33:67:03:4e:49:43:06:61:63:63:65:73:73:11:6f:72:61:6e:67:65:2d:6d:75:6c:74:69:6d:65:64:69:61:03:6e:65:74:00;"
subnet-parameters "option domain-search "NIC.access.orange-multimedia.net.";"
subnet-parameters "option domain-name "orange.fr";"
-
Il manque au moins aussi l’option 125 qui est obligatoire. Bizarre que tu la vois pas sur le dump de l’offer d’orange…. Chez moi (pas sous openwrt) :
subnet-parameters "option rfc3118-auth 00:00:00:00:00:00:00:00:00:00:00:64:68:63:70:6c:69:76:65:62:6f:78:66:72:32:35:30;"
subnet-parameters "option Vendor-specific 00:00:05:58:0c:01:0a:00:01:00:00:00:ff:ff:ff:ff:ff;"
subnet-parameters "option SIP 00:06:73:62:63:74:33:67:03:4e:49:43:06:61:63:63:65:73:73:11:6f:72:61:6e:67:65:2d:6d:75:6c:74:69:6d:65:64:69:61:03:6e:65:74:00;"
subnet-parameters "option domain-search "NIC.access.orange-multimedia.net.";"
subnet-parameters "option domain-name "orange.fr";"
Si justement je vois bien les options côté serveur DHCP Orange.
Mais quand j'essaye de "simuler" le serveur DHCP sur le VLAN 832 de eth5, La Livebox ne veut rien savoir.
Je sais que ça marche puisque sur Mikrotik je l'ai fait (Option 90,120,125). Je ne sais seulement pas les variables à utilisées dans le fichier de config pour forcer l'envoi d'options.
-
Bon,
encore moi,
j'ai encore des questions :
1/ est ce qu'on peut avoir et l'ipV4 et l'ipV6 en meme temps sur le wan, ou bien le faut choisir entre les deux?
2/ Sur le Wan6, quand je fais le ifstatus, je n'ai rien. soucis de config ou conflit avec IPV4?
3/ En wifi peut importe si je suis en 2.4 ou 5ghs, je suis à peu près à la moitié du débit théorique que je dois pouvoir avoir. (150 au lieu de 300mb). Une idée du pourquoi du comment?
Merci d'avance pour votre aide.
Dan
-
Il n'y a pas d'IPv6 sur la patte wan. Donc, il n'y a qu'une IPv4.
Tu récupères un préfixe IPv6, dans lequel il faut attribuer une IPv6 au routeur.
-
@HJ67, je ne suis pas sur d'avoir compris.
Tu veux dire que sur le réseau Orange il n'y a pas encore d'IPv6? que tous les box internet sont en IPv4?
Sinon pour mon soucis de débit, tu aurais une idée?
-
Il veut dire qu’il est totalement inutile et même contre productif (parce que tu gâche 2^64 adresses) d’avoir une IPv6 « publique » (GUA) sur l’interface WAN, puisqu’il n’y en a pas besoin (l’adresse Link Local est suffisante pour joindre le premier saut, la route par défaut).
La Livebox n’a pas d’adresse IPv6 GUA sur son port WAN mais uniquement sur son port LAN. Ça ne l’empêche pas de fournir de l’IPv6 natif (et pas un tunnel comme chez certains).
D’une manière générale, c’est une mauvaise idée de transposer ce qu’on connaît d’IPv4 à IPv6. Les différentes types d’adresses et leur portée spécifique changent toute la donne.
-
Hello,
Merci pour ces explication, j'étais sûr que la livebox avait une adresse IPv6 sur le réseau Orange.
Je me coucherais moins bête ce soir.
SInon pour ce qui est de mon débit, je pense que c'est une limitation matériel au niveau du WiFi.
EN filaire je suis quasiment à mon débit maximum.
Il faudra que je regarde comment mettre à jour le firmware OpenWRT
-
Bonjour,
si certains parmi vous cherchent une machine de compétition pour faire tourner Openwrt (ou autre) je suis tombé sur ça :
https://www.solid-run.com/embedded-networking/marvell-octeon-tx2-family/clearfog-cn9130/
Environ 300$ pour le CLEARFOG CN9130 PRO, le prix est très raisonnable je trouve.
Marvell OCTEON based CN9130 Quad core Arm Cortex A72 up to 2.2 GHz
up to 8GB DDR4
8GB eMMC
MicroSD
1 x Port dedicated Ethernet
5 x Switched Ethernet RJ45 10/100/1000
1 x SFP+ 10GbE
mikroBUS header
M.2
2 x mSATA/mPCIE with SIM holder
Indication LEDs
User Push Buttons
RTC Battery
JTAG Header
Analog Audio/TDM module support
Vendu dans son boitier, mais sans transfo (vendu a part).
La version précédente, en dual core @1.6Ghz est à 182$:
https://www.solid-run.com/embedded-networking/marvell-armada-family/clearfog/
-
Bonjour,
si certains parmi vous cherchent une machine de compétition pour faire tourner Openwrt (ou autre) je suis tombé sur ça :
https://www.solid-run.com/embedded-networking/marvell-octeon-tx2-family/clearfog-cn9130/
Environ 300$ pour le CLEARFOG CN9130 PRO, le prix est très raisonnable je trouve.Vendu dans son boitier, mais sans transfo (vendu a part).
La version précédente, en dual core @1.6Ghz est à 182$:
https://www.solid-run.com/embedded-networking/marvell-armada-family/clearfog/
Merci pour l'info !
Ca à l'air top mais frustrant à ce prix de pas y trouver un port Lan 2.5G ou + (histoire d'être futur-proof).
Il manquerait plus qu'a tester si le port SFP 2.5G (de l'ancien modele) pourrait être compatible avec les SFP ONT qu'on peut commander sur le net (pour bénéficier des 2G down).
-
Avec du 2.5Gbps j'ai vu le combo Odroid H2+ avec en option la carte fille H2 Net Card qui permet de passer de 2 a 6 ports Ethernet 2.5Gbps.
https://www.hardkernel.com/shop/odroid-h2plus/
https://www.hardkernel.com/shop/h2-net-card/
Mais pas de SFP...
Et là du coup on est sur du X86 Intel Quad-core J4115 (https://ark.intel.com/content/www/fr/fr/ark/products/192635/intel-celeron-j4115-processor-4m-cache-up-to-2-50-ghz.html).
La carte fille se connecte sous la carte mère.
(https://i.imgur.com/3i3v6gg.png)
Après au niveau du boitier on ne peut pas dire que ce soit très esthétique...
https://www.hardkernel.com/shop/odroid-h2-case-type-7/
(https://i.imgur.com/LkS2g13.jpg)
-
bonjour
j'ai suivi lu tuto a la lettre j'ai bien un prefix ipv6 mais quand je teste sur https://ipv6-test.com/ j'ai ipv6 not supported
-
bonjour
j'ai suivi lu tuto a la lettre j'ai bien un prefix ipv6 mais quand je teste sur https://ipv6-test.com/ j'ai ipv6 not supported
Salut,
Si tu as la configuration du tuto, tu reçois le préfixe sur la patte Wan, ton routeur s'est généré une adresse du premier /64 sur la patte lan et distribue le prefixe via les RA.
Peux-tu vérifier la configuration de ces deux fichiers :
Dans le fichier /etc/config/dhcp :
config dhcp 'lan'
option interface 'lan'
option start '100'
option leasetime '4h'
option ra 'server'
list dhcp_option '6,192.168.1.1'
option limit '30'
Dans le fichier /etc/config/network :
config interface 'lan'
option type 'bridge' #chez moi c'est un bridge car j'ai un SSID wifi + l'eth0
option proto 'static'
option ipaddr '192.168.1.1'
option netmask '255.255.255.0'
option delegate '0'
option mtu '1500'
option ifname 'eth0.1'
option ip6assign '64'
-
Salut ubune
je suis sur wrt320acm firmware 21.02
config dhcp 'lan'
option interface 'lan'
option start '100'
option leasetime '12h'
option dhcpv4 'server'
option dhcpv6 'server'
option ra 'server'
option ndp 'relay'
option limit '30'
list ra_flags 'none'
config interface 'lan'
option device 'br-lan'
option proto 'static'
option ipaddr '192.168.1.1'
option netmask '255.255.255.0'
option mtu '1500'
option ip6assign '64'
-
Bonjour à tous,
Je desirerai effectuer la mise à jour vers openwrt 21.02 pour mon ERX.
Est-ce que l'un de vous pourrait m'indiquer la configuration des VLAN avec ce nouveau système DSA? Malgré avoir quotidiennement lu la doc, j'ai vraiment du mal à appréhender ce système et la nouvelle syntaxe.
D'ailleurs je vois que personne n'a encore effectuer de PR sur le github de ubune, est-ce encore trop tôt?
Merci!
-
Salut,
J'ai réussi à passer la mise à jour 21.02 avec un ERX, et Internet est fonctionnel (je n'utilise pas le téléphone ni la TV).
La configuration des VLAN se fait assez simplement avec Luci : dans Network > Interfaces > Devices, j'ai ajouté un device type "VLAN (802.1q)" qui tag le vlan 832.
Sinon ma configuration /etc/config/network ressemble à ceci :
config device
option type '8021q'
option ifname 'eth0'
option vid '832'
option name 'eth0.832'
config interface 'wan'
...
option device 'eth0.832'
config interface 'wan6'
...
option device 'eth0.832'
Les paquets côté WAN sont bien taggué sur le vlan 832 et je récupère bien une IPv4 et un préfixe IPv6.
Par contre j'ai remarqué qu'a chaque reboot du routeur, Orange envoie désormais une nouvelle IPv4 ! Je n'ai pas l'impression que c'était le cas avant où j'avais pu garder la même IPv4 presque 2 ans ! Pas de changement de préfixe v6 par contre.
-
@Khalgon
Y a t il une raison que tu aies créé un device type "VLAN (802.1q)" plutôt que d'activer VLAN filtering sous br-lan?
J'ai vraiment du mal à appréhender les VLANs sous DSA depuis openwrt 21.02, et serais bien preneur de conseils.
-
Bonjour à tous,
J'ai enfin franchi le pas le WE dernier... ma LiveBox est retourné dans sa boite :)
(Je n'utilise pas le téléphone ni la TV)
J'ai utilisé un EdgeRouter X avec la version 21.02.1 de OpenWrt : je confirme ce qu'a dit Khalgon, cela marche très bien avec cette version.
Par contre, on peut encore simplifier le fichier "/etc/config/network" car le bloc suivant n'est pas nécessaire (car implicite) :
config device
option type '8021q'
option ifname 'eth0'
option vid '832'
option name 'eth0.832'
Je suis parti des fichiers de configuration par défaut de OpenWrt et j'ai juste suivi le tutorial de ubune pour ajouter les parties manquantes.
Cela donne cela chez moi à la fin :
Dans le fichier "etc/config/network":
- Modifier "ip6assign" de "lan" en 64:
config interface 'lan'
option ip6assign '64'- Modifier les interface "wan" et "wan6" comme ça (en oubliant pas de mettre ton identifiant encodé comme indiqué dans le tuto)
config interface 'wan'
option device 'eth0.832'
option proto 'dhcp'
option broadcast '1'
option vendorid 'sagem' # on envoi le vendor id sagem
option reqopts '1 15 28 51 58 59 90' # liste des options demandées
option sendopts '77:2b46535644534c5f6c697665626f782e496e7465726e65742e736f66746174686f6d652e4c697665626f7834 90:00000000000000000000001a0900000558010341010d6674692fXXXXXXXXXXXXXX' # option 77 + 90 (fti)
config interface 'wan6'
option device 'eth0.832'
option proto 'dhcpv6'
option reqprefix 'auto'
option reqaddress 'none'
option defaultreqopts '0'
option sendopts '11:00000000000000000000001a0900000558010341010d6674692fXXXXXXXXXXXXXX 15:FSVDSL_livebox.Internet.softathome.livebox4 16:0000040e0005736167656d'
option reqopts '11 17 23 24'
option noclientfqdn '1'
option noacceptreconfig '1'
Dans le fichier "etc/config/firewall":
- Modifier la zone "wan" (supprimer la ligne "wan6" et ajouter la ligne "ipv4" et modifier la ligne "mtu_fix"):
config zone
option name wan
list network 'wan'
option input REJECT
option output ACCEPT
option forward REJECT
option masq 1
option mtu_fix 0
option family 'ipv4'- Ajouter la zone "wan6" (je ne sais juste pas s'il faut modifier "masq", "mtu_fix" pour l'IPv6 : si quelqu'un sait ce qu'il faut vraiment mettre ici je suis preneur d'une explication [merci ubune pour ton explication détaillée]):
config zone
option name wan6
list network 'wan6'
option input REJECT
option output ACCEPT
option forward REJECT
option masq 0
option mtu_fix 0
option family 'ipv6'- Ajouter la règle:
config forwarding
option src lan
option dest wan6- Remplacer le "wan" par "wan6" dans les règles suivantes :
config rule
option name Allow-DHCPv6
option src wan6config rule
option name Allow-MLD
option src wan6config rule
option name Allow-ICMPv6-Input
option src wan6config rule
option name Allow-ICMPv6-Forward
option src wan6
Et pour les fichiers "/etc/firewall.user" et "/etc/vlanprio.sh" (contenu à récupérer dans le tuto ou dans le git de ubune), vérifiez qu'il y a bien "eth0.832" là ou il faut (j'ai supprimé la ligne relative à la TV dans "vlanprio.sh" (vlan 840)).
En tout cas un grand merci à ubune et à tous ceux qui ont travaillé à cette discussion.
-
Salut,
Merci pour les infos, il faudra que je maj le tuto à l'occasion pour cette version d'openwrt.
Concernant ce point :
"(je ne sais juste pas s'il faut modifier "masq", "mtu_fix" pour l'IPv6 : si quelqu'un sait ce qu'il faut vraiment mettre ici je suis preneur d'une explication):"
masq c'est pour masquerade, en gros on remplace l'ip source de la machine par l'ip portée sur l'interface de sortie du routeur, c'est nécessaire en ipv4 (on remplace l'ip source de ta machine 192.168.X.X par ton ip publique quand le flux part sur internet).
Donc ce paramètre est à désactiver en ipv6 (les ips globales sont routées sur internet), mais je pense que même si tu l'as laissé il doit être ignoré (à vérifier).
Concernant "mtu-fix" c'est un peu plus technique, c'est important de l'activer quand ton opérateur ne te fournit pas un lien avec une MTU à 1500 octet, exemple en adsl/fibre avec pppoe (le protocole consomme 8octets).
La mtu c'est la taille maximal d'un paquet (niveau 3) qui transite sur le réseau, 1500 est la valeur configurée par défaut sur nos machines, mais du coup, si tu étais sur un lien pppoe par exemple, tu aurais de la fragmentation, possiblement sur le trajet (en ipv4), en ipv6 on est aidé par l'icmpv6 type 2 (si il n'est pas filtré).
Ce paramètre "mtu-fix" n'agit pas sur la mtu directement, mais sur l'options MSS d'une négociation TCP, donc quand ta machine envoi un syn avec l'option MSS à 1460 en ipv4, (1460 + 20 (entete tcp) + 20 (entete ip) = 1500), le routeur va corriger pour que ça corresponde à la mtu max possible.
- exemple en pppoe sur un flux ipv4 la mss aurait été réécrite à 1452 et sur un flux ipv6 à 1432.
La limitation est que ça ne fonctionne que sur tcp, udp ne sera pas concerné et donc la fragmentation risquera quand même d'avoir lieu avec ce protocole de transport.
Pour résumer, en lien fibre Orange dhcp, MTU 1500 donc :
masquerade IPV4 : oui
mtu fix : non
masquerade IPV6 : non
mtu fix : non
A +
-
Salut !
Je branchais la Livebox derrière le routeur pour avoir le téléphone, tout fonctionnait bien jusqu'à la mise à jour de ma livebox qui s'est fait dans la nuit du 07 décembre 2021 vers 2h (nouvelle version SG30_sip-fr-7.12.0.1). Depuis, j'avais perdu le téléphone...
Pour réparer, j'ai dû modifier les options 119 et 120 envoyées à la livebox par mon routeur.
Il y a plusieurs mois, j'avais suivi l'indication donnée dans ce post en configurant uniquement les options dhcp 90, 120 et 125 : https://lafibre.info/remplacer-livebox/remplacement-de-la-livebox-par-un-routeur-openwrt-18-dhcp-v4v6-tv/msg589599/#msg589599
Cependant, il semblerait que l'option 120 soit devenue obsolète et ait été remplacée par la 119 (voir ce topic https://lafibre.info/remplacer-livebox/cacking-nouveau-systeme-de-generation-de-loption-90-dhcp/msg596234/#msg596234).
J'ai vérifié avec une trace côté Orange et en effet, leur serveur DHCP ne semble plus envoyer l'option 120 aujourd'hui.
Voici donc ce que j'utilise comme configuration DHCP pour fournir à ma box (l'option 120 n'est plus nécessaire et j'ai du ajouter l'option 119) :
/etc/config/dhcp :
config dhcp 'tel'
option leasetime '12h'
option domain 'orange.fr'
option interface 'tel'
option start '1'
option limit '2'
list dhcp_option '90,00:00:00:00:00:00:00:00:00:00:00:64:68:63:70:6c:69:76:65:62:6f:78:66:72:32:35:30'
list dhcp_option '119,XXX.access.orange-multimedia.net'
list dhcp_option '125,00:00:05:58:0c:01:0a:00:01:00:00:00:ff:ff:ff:ff:ff'
list dhcp_option '6,80.10.246.5,81.253.149.13'
Remplacez les "XXX" dans l'option 119 par ce que vous recevez d'Orange (pour moi c'est "NCY" pour Nancy).
Redémarrez votre box et le téléphone devrait à nouveau fonctionner !
-
Salut :)
J'avais rencontré exactement le même problème en juin 2019.
Le téléphone ne fonctionnait plus.
Et tout comme toi, j'avais dû ajouter l'option 119, parmi les options DHCP envoyées à la Livebox : https://lafibre.info/remplacer-livebox/remplacement-de-la-livebox-par-un-routeur-openwrt-18-dhcp-v4v6-tv/msg663128/#msg663128
Pour info, je viens d'effectuer sans encombre, la MAJ OpenWrt 19.07.8 > 21.02.1 sur mon routeur TP-Link Archer C7 v2.
C'est passé sans aucun soucis, sans rien avoir à reconfigurer :
root@OpenWrt:/tmp# sysupgrade -v openwrt-21.02.1-ath79-generic-tplink_archer-c7-v2-squashfs-sysupgrade.bin
root@OpenWrt:~# opkg update
root@OpenWrt:~# opkg install iptables-mod-ipopt ip-full tcpdump ddns-scripts luci-app-ddns
NB : chez moi, le script /etc/vlanprio.sh ne semble pas nécessaire pour qu'Internet fonctionne.
J'ai donc pu installer les paquets iptables-mod-ipopt + ip-full via un simple "opkg install", sans avoir à les télécharger en anticipé.
J'ai remarqué que mon IPv4 publique change dorénavant lors d'un reboot du routeur (ou lorsque je lance manuellement /etc/network/restart). Ce n'était pas le cas auparavant. Conséquence du passage à OpenWRT 21.x, ou simple coïncidence ?
-
J'ai remarqué que mon IPv4 publique change dorénavant lors d'un reboot du routeur (ou lorsque je lance manuellement /etc/network/restart). Ce n'était pas le cas auparavant. Conséquence du passage à OpenWRT 21.x, ou simple coïncidence ?
Trouvé : pour que l'IP ne change pas, il suffit d'ajouter option norelease '1' dans la section wan du fichier /etc/config/network, comme précisé dans ce post :
Une petite info pour ceux que ça intéresseraient avec un petit soucis de release du bail IPv4 sous OpenWRT 20 (snapshot).
[...]
Je n'ai eu qu'un soucis, avec la même config que celle donnée ici le routeur changeait d'IP à chaque manip sur la carte WAN et à chaque redémarrage de la machine.
très pénible.
Pour indiquer à udhcpc de ne pas faire de release du bail à chaque reload de l'interface ou redémarrage du routeur j'ai dû simplement rajouter ça dans le /etc/config/network dans la section wan:
option norelease '1'
-
Hello,
J'avais testé un openWRT 21 rcx avec une config de 19.07, et à l'époque cela fonctionnait.
J'ai eu une parenthèse de 2 ans chez Free et aujourd'hui j'ai dépoussiéré ma configuration sur un openWRT 21.02.1 (histoire d'avoir 2Gbps sur l'ONU FS.com).
La seule grosse différence que j'ai noté par rapport au 19.07 c'est qu'il n'est plus nécessaire d’appeler le script vlanprio.sh pour configurer les egress. De toute façon les commandes 'ip' du script ne fonctionnent plus. En fait, openWRT 21.01 gère maintenant les egress.
Exemple de ma configuration dans /etc/config/network pour mon port WAN ethbcm0:
config device
option name 'ethbcm0.832'
option type '8021q'
option ifname 'ethbcm0'
option vid '832'
list egress_qos_mapping '0:0'
list egress_qos_mapping '2:2'
list egress_qos_mapping '3:3'
list egress_qos_mapping '4:4'
list egress_qos_mapping '5:5'
list egress_qos_mapping '6:6'
list egress_qos_mapping '7:7'
list egress_qos_mapping '1:0'
list egress_qos_mapping '0:6'
config device
option name 'ethbcm0.840'
option type '8021q'
option ifname 'ethbcm0'
option vid '840'
list egress_qos_mapping '0:5'
list egress_qos_mapping '1:5'
list egress_qos_mapping '2:5'
list egress_qos_mapping '3:5'
list egress_qos_mapping '4:5'
list egress_qos_mapping '5:5'
list egress_qos_mapping '6:5'
list egress_qos_mapping '7:5'
Par contre il faut toujours garder la configuration de la priorité cos6 pour les DHCP(v6) dans /etc/firewall.user :
ETH_WO=ethbcm0
iptables -t mangle -A POSTROUTING -j CLASSIFY --set-class 0000:0001 ## En gros tout le flux sortant passe dans la file 1 qui est en prio 0
iptables -t mangle -A POSTROUTING -p icmp -j CLASSIFY --set-class 0000:0006 ##On passe le flux icmp dans la file 6 qui est en prio 6
iptables -t mangle -A POSTROUTING -p igmp -j CLASSIFY --set-class 0000:0006 ## On passe le flux igmp (celui qui part vers ${ETH_W0}.832) dans la file 6 qui es
#la même chose en ipv6 (avec cette fois le dhcpv6)
ip6tables -t mangle -A POSTROUTING -j CLASSIFY --set-class 0000:0001
ip6tables -t mangle -A POSTROUTING -p ipv6-icmp -j CLASSIFY --set-class 0000:0006
ip6tables -t mangle -A POSTROUTING -o ${ETH_WO}.832 -p udp --dport 547 -j CLASSIFY --set-class 0000:0006
ip6tables -t mangle -A POSTROUTING -p udp --dport 547 -j DSCP --set-dscp-class CS6
En fait, j'aimerai savoir si openWRT supporte maintenant la COS6 au niveau du client DHCP. Voir s'il y a un paramétrage cliquable pour remplacer ces lignes iptables (bref s'il existe un moyen propre).
-
Bonjour,
Malgré avoir lu vos commentaires sur la nouvelle gestion des vlans en version 21.xx, j'ai tenté de passer mon install depuis 19.07.x et j'ai rien compris.
J'ai compris que mettre ethX.832 crérait implicitement un device taggué sur le vlan 832.
J'ai un linksys WRT32X avec "normalement" 2 CPU (eth0 pour le LAN et eth1 pour le WAN). Sur 21.xx, il n'y a plus de trace de eth1.
J'ai donc configuré wan et wan6 sur eth0.832, mais rien ne fonctionne.
J'ai retourné le tuto de Ubune dans tous les sens. Lors de ma 1ère installation en 2020, je suivais le tuto sans presque rien comprendre.
Aujourd'hui, je comprends tout, mais même avec ça, la conf ne fonctionne pas. Du coup, je suis revenu en 19.07.8.
Avant, je ne travaillais qu'avec Luci, aujourd'hui, je me sens + à l'aise avec la cli ou la conf textuelle...
Extrêmement déçu parce que je bloque sur la nouvelle gestion des vlans qui pourtant a l'air d'être "conforme" à la norme "DSA".
Est ce que quelqu'un peut être + explicite et m'expliquer quoi faire dans mon cas ?
Thx
Edit : Sur ma config en 19.07.8 je vois bien que le wan est configuré sur l'interface eth1.832 (fonctionne parfaitement) :
(https://i.imgur.com/tQc3T9j.png)
-
Hello, Merci pour les retours.
En effet la version 21 apporte beaucoup de changement, désolé n'étant plus sur une connexion Orange le tuto n'est toujours pas à jour.
Cependant je vais récupérer prochainement un Linksys WRT1200AC que j'installerai sur une connexion sosh.
J'en profiterai pour Maj le tuto
En espérant que que d'autres vous aide en attendant.
A bientôt
-
C'est vrai que dans mon cas j'ai que des ports ethernet et pas de switch à configurer (openwrt sur pc). Je pense que la configuration du switch a dut bien changer. Par contre curieux que de 2 ports ethernet il n'en reste plus qu'un. Ce n'est pas normal et on dirait bien un bug.
Normalement un routeur devrait avoir 2 eth sur le switch....
-
Pour ma part sur un x86 version 21.02.1 j'ai juste appliquer la CONF ETH1 et CONF FIREWALL, créer le vlan 832 et j'obtiens un IPV4 j'ai rien fait d'autre pas d'iptables etc...
-
Pour ma part sur un x86 version 21.02.1 j'ai juste appliquer la CONF ETH1 et CONF FIREWALL, créer le vlan 832 et j'obtiens un IPV4 j'ai rien fait d'autre pas d'iptables etc...
parce que tu n'as pas besoin de la TV ;)
-
parce que tu n'as pas besoin de la TV ;)
Non plus de nos jours
-
Bonjour,
Je viens de suivre le tuto sur un AX3600 flasher sur OPENWRT 21.02.
Je récupère bien une IPV4, je peux effectuer le test de ping et de tracerout sur luci mais les appareils n'ont pas accès a internet malgré que Windows dit que le PC est "Connecté"
Si quelqu'un pourrais m'aider ce serais sympas :)
etc/network
config interface 'loopback'
option device 'lo'
option proto 'static'
option ipaddr '127.0.0.1'
option netmask '255.0.0.0'
config globals 'globals'
option ula_prefix 'fd60:ab45:5b3d::/48'
config device
option name 'br-lan'
option type 'bridge'
list ports 'eth1'
list ports 'eth2'
list ports 'eth3'
config interface 'lan'
option device 'br-lan'
option proto 'static'
option ipaddr '192.168.1.1'
option netmask '255.255.255.0'
option ip6assign '60'
config interface 'wan'
option device 'eth0.832'
option proto 'dhcp'
option broadcast '1'
option vendorid 'sagem' # on envoi le vendor id sagem
option reqopts '1 15 28 51 58 59 90' # liste des options demandées
option sendopts '77:2b46535644534c5f6c697665626f782e496e7465726e65742e736f66746174686f6d652e4c697665626f7834 90:00000000000000000000001a0900000558010341010d6674692Fxxxxxxxxxxxxxx' # option 77 + 90 (fti)
config switch_vlan
option device 'switch0'
option vlan '2'
option ports '0t 6t'
option vid '832'
config interface 'wan6'
option device 'eth0'
option proto 'dhcpv6'
etc/firewall
config defaults
option syn_flood 1
option input ACCEPT
option output ACCEPT
option forward REJECT
# Uncomment this line to disable ipv6 rules
# option disable_ipv6 1
config zone
option name lan
list network 'lan'
option input ACCEPT
option output ACCEPT
option forward ACCEPT
config zone
option name wan
list network 'wan'
option input REJECT
option output ACCEPT
option forward REJECT
option masq 1
option mtu_fix 0
option family 'ipv4'
config zone
option name wan6
list network 'wan6'
option input REJECT
option output ACCEPT
option forward REJECT
option masq 0
option mtu_fix 0
option family 'ipv6'
config forwarding
option src lan
option dest wan
config include
option path '/etc/firewall.user'
# We need to accept udp packets on port 68,
# see https://dev.openwrt.org/ticket/4108
config rule
option name Allow-DHCP-Renew
option src wan
option proto udp
option dest_port 68
option target ACCEPT
option family ipv4
# Allow IPv4 ping
config rule
option name Allow-Ping
option src wan
option proto icmp
option icmp_type echo-request
option family ipv4
option target ACCEPT
config rule
option name Allow-IGMP
option src wan
option proto igmp
option family ipv4
option target ACCEPT
# Allow DHCPv6 replies
# see https://dev.openwrt.org/ticket/10381
config rule
option name Allow-DHCPv6
option src wan
option proto udp
option src_ip fc00::/6
option dest_ip fc00::/6
option dest_port 546
option family ipv6
option target ACCEPT
config rule
option name Allow-MLD
option src wan
option proto icmp
option src_ip fe80::/10
list icmp_type '130/0'
list icmp_type '131/0'
list icmp_type '132/0'
list icmp_type '143/0'
option family ipv6
option target ACCEPT
# Allow essential incoming IPv6 ICMP traffic
config rule
option name Allow-ICMPv6-Input
option src wan
option proto icmp
list icmp_type echo-request
list icmp_type echo-reply
list icmp_type destination-unreachable
list icmp_type packet-too-big
list icmp_type time-exceeded
list icmp_type bad-header
list icmp_type unknown-header-type
list icmp_type router-solicitation
list icmp_type neighbour-solicitation
list icmp_type router-advertisement
list icmp_type neighbour-advertisement
option limit 1000/sec
option family ipv6
option target ACCEPT
# Allow essential forwarded IPv6 ICMP traffic
config rule
option name Allow-ICMPv6-Forward
option src wan
option dest *
option proto icmp
list icmp_type echo-request
list icmp_type echo-reply
list icmp_type destination-unreachable
list icmp_type packet-too-big
list icmp_type time-exceeded
list icmp_type bad-header
list icmp_type unknown-header-type
option limit 1000/sec
option family ipv6
option target ACCEPT
config rule
option name Allow-IPSec-ESP
option src wan
option dest lan
option proto esp
option target ACCEPT
config rule
option name Allow-ISAKMP
option src wan
option dest lan
option dest_port 500
option proto udp
option target ACCEPT
### EXAMPLE CONFIG SECTIONS
# do not allow a specific ip to access wan
#config rule
# option src lan
# option src_ip 192.168.45.2
# option dest wan
# option proto tcp
# option target REJECT
# block a specific mac on wan
#config rule
# option dest wan
# option src_mac 00:11:22:33:44:66
# option target REJECT
# block incoming ICMP traffic on a zone
#config rule
# option src lan
# option proto ICMP
# option target DROP
# port redirect port coming in on wan to lan
#config redirect
# option src wan
# option src_dport 80
# option dest lan
# option dest_ip 192.168.16.235
# option dest_port 80
# option proto tcp
# port redirect of remapped ssh port (22001) on wan
#config redirect
# option src wan
# option src_dport 22001
# option dest lan
# option dest_port 22
# option proto tcp
### FULL CONFIG SECTIONS
#config rule
# option src lan
# option src_ip 192.168.45.2
# option src_mac 00:11:22:33:44:55
# option src_port 80
# option dest wan
# option dest_ip 194.25.2.129
# option dest_port 120
# option proto tcp
# option target REJECT
#config redirect
# option src lan
# option src_ip 192.168.45.2
# option src_mac 00:11:22:33:44:55
# option src_port 1024
# option src_dport 80
# option dest_ip 194.25.2.129
# option dest_port 120
# option proto tcp
rc.local (J'ai été obliger de faire comme ca sinon je récupérais une adresse IPV4 privée en 172.x)
# Put your custom commands here that should be executed once
# the system init finished. By default this file does nothing.
sleep 10
sh /etc/vlanprio.sh
vlanprio.sh
#!/bin/sh
set -x
for i in 0 1 2 3 4 5 6 7; do
ip link set eth0.832 type vlan egress $i:$i >/dev/null ## Chaque file devient en priorité $numdefile
ip link set eth0.840 type vlan egress $i:5 >/dev/null ## tout en prio 5 sur le vlan 840
done
ip link set eth0.832 type vlan egress 1:0 >/dev/null ## La file (1) était donc en prio 1 on la repasse à 0, ça deviendra (via IPTABLES) la nouvelle file par défaut.
ip link set eth0.832 type vlan egress 0:6 >/dev/null ## Tout le flux devient en prio 6 ! sauf le flux qui passera par IPTABLES (donc juste nos requêtes dhcp)
firewall.user
iptables -t mangle -A POSTROUTING -j CLASSIFY --set-class 0000:0001 ## En gros tout le flux sortant passe dans la file 1 qui est en prio 0
iptables -t mangle -A POSTROUTING -p icmp -j CLASSIFY --set-class 0000:0006 ##On passe le flux icmp dans la file 6 qui est en prio 6
iptables -t mangle -A POSTROUTING -o eth0.832 -p igmp -j CLASSIFY --set-class 0000:0006 ## On passe le flux igmp (non tv) en prio 6
iptables -t mangle -A POSTROUTING -o eth0.832 -p udp --dport 67 -j CLASSIFY --set-class 0000:0006 ## On passe le flux dhcp dans la file 6 qui est en prio 6, necessaire pour le DHCP Renew
#la même chose en ipv6 (avec cette fois le dhcpv6)
ip6tables -t mangle -A POSTROUTING -j CLASSIFY --set-class 0000:0001
ip6tables -t mangle -A POSTROUTING -p ipv6-icmp -j CLASSIFY --set-class 0000:0006
ip6tables -t mangle -A POSTROUTING -p udp --dport 547 -j CLASSIFY --set-class 0000:0006
ip6tables -t mangle -A POSTROUTING -p udp --dport 547 -j DSCP --set-dscp-class CS6
Je tiens aussi a préciser aussi que je ne peux pas télécharger/installer le package "iptables-mod-ipopt" sur ma version mais je ne pense pas que c'est cela qui bloque.
Merci d'avance :D
-
si tu fais un ipconfig /all sur ton PC tu obtiens quoi ?
-
si tu fais un ipconfig /all sur ton PC tu obtiens quoi ?
Voici mon ipconfig /all (C'est sur mon PC directement que les DNS de cloudflare sont configurer)
Configuration IP de Windows
Nom de l’hôte . . . . . . . . . . : DESKTOP-xxxxxxx
Suffixe DNS principal . . . . . . :
Type de noeud. . . . . . . . . . : Hybride
Routage IP activé . . . . . . . . : Non
Proxy WINS activé . . . . . . . . : Non
Liste de recherche du suffixe DNS.: lan
Carte Ethernet Ethernet :
Suffixe DNS propre à la connexion. . . : lan
Description. . . . . . . . . . . . . . : Realtek PCIe 2.5GbE Family Controller
Adresse physique . . . . . . . . . . . : 2C-F0-5D-AA-98-C9
DHCP activé. . . . . . . . . . . . . . : Oui
Configuration automatique activée. . . : Oui
Adresse IPv6. . . . . . . . . . . . . .: fd60:ab45:5b3d::ac4(préféré)
Bail obtenu. . . . . . . . . . . . . . : vendredi 8 avril 2022 16:58:09
Bail expirant. . . . . . . . . . . . . : samedi 9 avril 2022 04:58:08
Adresse IPv6. . . . . . . . . . . . . .: fd60:ab45:5b3d:0:5cf6:bac4:xxxx:xxxx(préféré)
Adresse IPv6 temporaire . . . . . . . .: fd60:ab45:5b3d:0:11f8:a765:xxxx:xxxx(préféré)
Adresse IPv6 de liaison locale. . . . .: fe80::5cf6:bac4:xxxx:xxx%x(préféré)
Adresse IPv4. . . . . . . . . . . . . .: 192.168.1.116(préféré)
Masque de sous-réseau. . . . . . . . . : 255.255.255.0
Bail obtenu. . . . . . . . . . . . . . : vendredi 8 avril 2022 14:38:54
Bail expirant. . . . . . . . . . . . . : samedi 9 avril 2022 04:59:36
Passerelle par défaut. . . . . . . . . : 192.168.1.1
Serveur DHCP . . . . . . . . . . . . . : 192.168.1.1
IAID DHCPv6 . . . . . . . . . . . : 103608413
DUID de client DHCPv6. . . . . . . . : 00-01-00-01-29-C4-FC-64-2C-xx-xx-xx-xx-xx
Serveurs DNS. . . . . . . . . . . . . : fd60:ab45:5b3d::1
1.1.1.1
1.0.0.1
fd60:ab45:5b3d::1
NetBIOS sur Tcpip. . . . . . . . . . . : Activé
Voici le message d'erreur de mon navigateur que j'ai quand j'essaie d'ouvrir un page internet par exemple la fibre.info que pourtant j'arrive a atteindre avec un traceroute depuis le routeur
Ce site est inaccessible
lafibre.info n'autorise pas la connexion.
Voici quelques conseils :
Vérifier la connexion
Vérifier le proxy et le pare-feu
ERR_CONNECTION_REFUSED
-
tu as forcé tes DNS dans ta carte réseau ?
depuis ton PC, tu ping orange.fr ?
tu as de l'ipv6 sur le PC alors que dans ta config routeur (wan6) tu n'as rien parametré pour ca...désactive l'ipv6 sur ta carte réseau qu'on y vois plus clair...
-
tu as forcé tes DNS dans ta carte réseau ?
depuis ton PC, tu ping orange.fr ?
tu as de l'ipv6 sur le PC alors que dans ta config routeur (wan6) tu n'as rien parametré pour ca...désactive l'ipv6 sur ta carte réseau qu'on y vois plus clair...
Oui c'est ca j'ai forcer les DNS dans ma carte réseau mais je l'ai désactivé en même temps que l'IPV6 quand j'ai lu ton message
Résultat du ping orange.fr sur le PC :
Envoi d’une requête 'ping' sur orange.fr [193.252.117.145] avec 32 octets de données :
Réponse de 192.168.1.1 : Impossible de joindre le port de destination.
Réponse de 192.168.1.1 : Impossible de joindre le port de destination.
Délai d’attente de la demande dépassé.
Délai d’attente de la demande dépassé.
Statistiques Ping pour 193.252.117.145:
Paquets : envoyés = 4, reçus = 2, perdus = 2 (perte 50%),
C:\Users\rapha>ping orange.Fr
Envoi d’une requête 'ping' sur orange.fr [193.252.117.145] avec 32 octets de données :
Réponse de 192.168.1.1 : Impossible de joindre le port de destination.
Réponse de 192.168.1.1 : Impossible de joindre le port de destination.
Réponse de 192.168.1.1 : Impossible de joindre le port de destination.
Réponse de 192.168.1.1 : Impossible de joindre le port de destination.
Statistiques Ping pour 193.252.117.145:
Paquets : envoyés = 4, reçus = 4, perdus = 0 (perte 0%),
C:\Users\rapha>ping orange.fr
Envoi d’une requête 'ping' sur orange.fr [193.252.117.145] avec 32 octets de données :
Réponse de 192.168.1.1 : Impossible de joindre le port de destination.
Réponse de 192.168.1.1 : Impossible de joindre le port de destination.
Réponse de 192.168.1.1 : Impossible de joindre le port de destination.
Réponse de 192.168.1.1 : Impossible de joindre le port de destination.
Statistiques Ping pour 193.252.117.145:
Paquets : envoyés = 4, reçus = 4, perdus = 0 (perte 0%),
Ping orange.fr sur Luci :
PING orange.fr (193.252.117.145): 56 data bytes
64 bytes from 193.252.117.145: seq=0 ttl=248 time=8.963 ms
64 bytes from 193.252.117.145: seq=1 ttl=248 time=9.090 ms
64 bytes from 193.252.117.145: seq=2 ttl=248 time=8.922 ms
64 bytes from 193.252.117.145: seq=3 ttl=248 time=8.808 ms
64 bytes from 193.252.117.145: seq=4 ttl=248 time=9.403 ms
--- orange.fr ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 8.808/9.037/9.403 ms
-
tu dois avoir un truc qui ne va pas dans le Firewall du routeur, ton ping ne sort pas du réseau. La résolution DNS se fait par contre.
regarde chez moi :
(https://i.imgur.com/YTK045I.png)
-
Regarde les adaptations pour openwrt 21.x ici :
https://lafibre.info/remplacer-livebox/remplacement-de-la-livebox-par-un-routeur-openwrt-18-dhcp-v4v6-tv/msg906247/#msg906247
-
Regarde les adaptations pour openwrt 21.x ici :
https://lafibre.info/remplacer-livebox/remplacement-de-la-livebox-par-un-routeur-openwrt-18-dhcp-v4v6-tv/msg906247/#msg906247
Je me suis déjà servis de ce post pour configurer OPENWRT, j'ai vérifié mais rien n'y change, j'ai le même problème.
-
Hello. Au niveau du firewall, au lieu de reject mettre plutôt drop. Sinon le routeur va répondre par icmp "c'est pas atteignable".
-
que vois tu si tu fais sur le PC un traceroute vers orange.fr ?
tracert orange.fr
Après tes modifs tu as redémarré le routeur ? ou fait un
/etc/init.d/network restart
/etc/init.d/firewall restart
redémarré le PC ?
-
Hello. Au niveau du firewall, au lieu de reject mettre plutôt drop. Sinon le routeur va répondre par icmp "c'est pas atteignable".
Merci a toi c'est fait même si cela ne règle pas le problème
que vois tu si tu fais sur le PC un traceroute vers orange.fr ?
tracert orange.fr
Après tes modifs tu as redémarré le routeur ? ou fait un
/etc/init.d/network restart
/etc/init.d/firewall restart
redémarré le PC ?
Je viens de redémarrer le PC et quand je change quelque chose je fais toujours un perform reboot.
Quand je fais un tracert orange, je ne passe pas le saut de mon réseau local.
OPENWRT.lan [192.168.1.1]
Délai d'attente de la demande dépassée a l'infini après.
Mais la résolution DNS se fait bien encore
-
J'obtiens la même chose sur un autre PC.
Maintenant les navigateurs me disent :
La fibre.info a mis trop de temps à répondre.
Avec tout les sites ça fait ça.
En tout cas merci beaucoup à vous d'essayer de m'aider c'est super sympas
-
Bon c'est clair que le Firewall du routeur ne te laisse pas sortir sur le net.
tu n'as pas de message d'erreur ? lorsque tu fais un :
/etc/init.d/firewall restart
-
je pense que le problème viens de firewall.user qui n'est pas executé :
https://forum.openwrt.org/t/firewall-user-is-not-applied/122162
Avec le passage à openwrt 21, certaines choses ont changé. je ne vois plus la zone dans le firewall d'openwrt ou on pouvait manuellement ecrire ce qui devenait par la suite le firewall.user.
-
essaie ça :
renome ton fichier firewall.user en firewall.sh
rends le executable avec un chmod a+x /etc/firewall.sh
ensuite dans ton /etc/rc.local ajoute cette ligne à la fin :
sh /etc/firewall.sh
Vérifie qu'il n'y a pas d'erreur en lancant
/etc/firewall.sh
Oublie ca ! iptable n'est plus installé par défaut, c'est nft maintenant, donc il va falloir adapter :-X
-
Bon c'est clair que le Firewall du routeur ne te laisse pas sortir sur le net.
tu n'as pas de message d'erreur ? lorsque tu fais un :
/etc/init.d/firewall restart
Voici la réponse a la commande
root@OpenWrt:~# /etc/init.d/firewall restart
Section @rule[3] (Allow-DHCPv6) option 'src' specifies invalid value 'wan6'
Section @rule[3] (Allow-DHCPv6) skipped due to invalid options
Section @rule[4] (Allow-MLD) option 'src' specifies invalid value 'wan6'
Section @rule[4] (Allow-MLD) skipped due to invalid options
Section @rule[5] (Allow-ICMPv6-Input) option 'src' specifies invalid value 'wan6'
Section @rule[5] (Allow-ICMPv6-Input) skipped due to invalid options
Section @rule[6] (Allow-ICMPv6-Forward) option 'src' specifies invalid value 'wan6'
Section @rule[6] (Allow-ICMPv6-Forward) skipped due to invalid options
Section @forwarding[0] inheriting IPv4 restriction from dest wan
J'ai deja renommé des trucs en WAN6 (Comme dit dans ce post : https://lafibre.info/remplacer-livebox/remplacement-de-la-livebox-par-un-routeur-openwrt-18-dhcp-v4v6-tv/msg906247/#msg906247) mais j'ai pas encore configuré le reste
-
pourquoi tu ne mets pas ton ipv6 en place correctement dans /etc/config/newtork ? ca coute pas plus cher... ;D
Remarque, si tu arrives a obtenir une ipv4 sans que iptables fonctionne...c'est que tu es dans une zone ou la COS6 n'est pas obligatoire...et que donc le problème n'est pas là.
-
essaie ça :
renome ton fichier firewall.user en firewall.sh
rends le executable avec un chmod a+x /etc/firewall.sh
ensuite dans ton /etc/rc.local ajoute cette ligne à la fin :
sh /etc/firewall.sh
Vérifie qu'il n'y a pas d'erreur en lancant
/etc/firewall.sh
Oublie ca ! iptable n'est plus installé par défaut, c'est nft maintenant, donc il va falloir adapter :-X
Tu as une idée de comment débloquer ma situation du coup ?
Ou même si quelqu'un d'autre a une idée je suis preneur ;D
-
ben je vais me répetter : dans /etc/config/network fait la partie WAN6 pour que le firewall fonctionne sans erreur.
ou alors tu retires le WAN6 du network et du firewall si tu n'en veux pas.
Essaie avec mon fichier de config/firewall pour voir ? :
config defaults
option input 'ACCEPT'
option output 'ACCEPT'
option synflood_protect '1'
option forward 'DROP'
config zone
option name 'lan'
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'ACCEPT'
list network 'lan'
config zone
option name 'wan'
option output 'ACCEPT'
option masq '1'
option mtu_fix '0'
option input 'DROP'
option forward 'DROP'
list network 'wan'
list network 'wan6'
config forwarding
option src 'lan'
option dest 'wan'
config rule
option name 'Allow-DHCP-Renew'
option src 'wan'
option proto 'udp'
option dest_port '68'
option target 'ACCEPT'
option family 'ipv4'
config rule
option name 'Allow-Ping'
option src 'wan'
option proto 'icmp'
option icmp_type 'echo-request'
option family 'ipv4'
option target 'ACCEPT'
config rule
option name 'Allow-IGMP'
option src 'wan'
option proto 'igmp'
option family 'ipv4'
option target 'ACCEPT'
config rule
option name 'Allow-DHCPv6'
option src 'wan'
option proto 'udp'
option src_ip 'fc00::/6'
option dest_ip 'fc00::/6'
option dest_port '546'
option family 'ipv6'
option target 'ACCEPT'
config rule
option name 'Allow-MLD'
option src 'wan'
option proto 'icmp'
option src_ip 'fe80::/10'
list icmp_type '130/0'
list icmp_type '131/0'
list icmp_type '132/0'
list icmp_type '143/0'
option family 'ipv6'
option target 'ACCEPT'
config rule
option name 'Allow-ICMPv6-Input'
option src 'wan'
option proto 'icmp'
list icmp_type 'echo-request'
list icmp_type 'echo-reply'
list icmp_type 'destination-unreachable'
list icmp_type 'packet-too-big'
list icmp_type 'time-exceeded'
list icmp_type 'bad-header'
list icmp_type 'unknown-header-type'
list icmp_type 'router-solicitation'
list icmp_type 'neighbour-solicitation'
list icmp_type 'router-advertisement'
list icmp_type 'neighbour-advertisement'
option limit '1000/sec'
option family 'ipv6'
option target 'ACCEPT'
config rule
option name 'Allow-ICMPv6-Forward'
option src 'wan'
option dest '*'
option proto 'icmp'
list icmp_type 'echo-request'
list icmp_type 'echo-reply'
list icmp_type 'destination-unreachable'
list icmp_type 'packet-too-big'
list icmp_type 'time-exceeded'
list icmp_type 'bad-header'
list icmp_type 'unknown-header-type'
option limit '1000/sec'
option family 'ipv6'
option target 'ACCEPT'
config rule
option name 'Allow-IPSec-ESP'
option src 'wan'
option dest 'lan'
option proto 'esp'
option target 'ACCEPT'
config rule
option name 'Allow-ISAKMP'
option src 'wan'
option dest 'lan'
option dest_port '500'
option proto 'udp'
option target 'ACCEPT'
-
Test rapide. Faire un ping vers ton routeur (192.168.1.1), vers une IPv4 (ping 8.8.8.8), et enfin vers une ipv6 (ping ipv6.google.com).
-
ben je vais me répetter : dans /etc/config/network fait la partie WAN6 pour que le firewall fonctionne sans erreur.
ou alors tu retires le WAN6 du network et du firewall si tu n'en veux pas.
Essaie avec mon fichier de config/firewall pour voir ? :
config defaults
option input 'ACCEPT'
option output 'ACCEPT'
option synflood_protect '1'
option forward 'DROP'
config zone
option name 'lan'
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'ACCEPT'
list network 'lan'
config zone
option name 'wan'
option output 'ACCEPT'
option masq '1'
option mtu_fix '0'
option input 'DROP'
option forward 'DROP'
list network 'wan'
list network 'wan6'
config forwarding
option src 'lan'
option dest 'wan'
config rule
option name 'Allow-DHCP-Renew'
option src 'wan'
option proto 'udp'
option dest_port '68'
option target 'ACCEPT'
option family 'ipv4'
config rule
option name 'Allow-Ping'
option src 'wan'
option proto 'icmp'
option icmp_type 'echo-request'
option family 'ipv4'
option target 'ACCEPT'
config rule
option name 'Allow-IGMP'
option src 'wan'
option proto 'igmp'
option family 'ipv4'
option target 'ACCEPT'
config rule
option name 'Allow-DHCPv6'
option src 'wan'
option proto 'udp'
option src_ip 'fc00::/6'
option dest_ip 'fc00::/6'
option dest_port '546'
option family 'ipv6'
option target 'ACCEPT'
config rule
option name 'Allow-MLD'
option src 'wan'
option proto 'icmp'
option src_ip 'fe80::/10'
list icmp_type '130/0'
list icmp_type '131/0'
list icmp_type '132/0'
list icmp_type '143/0'
option family 'ipv6'
option target 'ACCEPT'
config rule
option name 'Allow-ICMPv6-Input'
option src 'wan'
option proto 'icmp'
list icmp_type 'echo-request'
list icmp_type 'echo-reply'
list icmp_type 'destination-unreachable'
list icmp_type 'packet-too-big'
list icmp_type 'time-exceeded'
list icmp_type 'bad-header'
list icmp_type 'unknown-header-type'
list icmp_type 'router-solicitation'
list icmp_type 'neighbour-solicitation'
list icmp_type 'router-advertisement'
list icmp_type 'neighbour-advertisement'
option limit '1000/sec'
option family 'ipv6'
option target 'ACCEPT'
config rule
option name 'Allow-ICMPv6-Forward'
option src 'wan'
option dest '*'
option proto 'icmp'
list icmp_type 'echo-request'
list icmp_type 'echo-reply'
list icmp_type 'destination-unreachable'
list icmp_type 'packet-too-big'
list icmp_type 'time-exceeded'
list icmp_type 'bad-header'
list icmp_type 'unknown-header-type'
option limit '1000/sec'
option family 'ipv6'
option target 'ACCEPT'
config rule
option name 'Allow-IPSec-ESP'
option src 'wan'
option dest 'lan'
option proto 'esp'
option target 'ACCEPT'
config rule
option name 'Allow-ISAKMP'
option src 'wan'
option dest 'lan'
option dest_port '500'
option proto 'udp'
option target 'ACCEPT'
J'ai pris le même fichier que toi j'ai juste ajouter les options IPV6, j'ai réussi a activer l'IPV6 mais ca me fait pareil qu'avec l'IPV4 le routeur peut ping/tracerout mais j'ai encore des délai dépassé sur le PC et rien ne charge même les sites accessible en IPV6
-
c'est bizarre cette histoire...et en wifi il se passe la meme chose ?
Tu peux poster ton /etc/config/network après installation d'opnwrt et avant modification ?
j'ai un doute sur ton :
config device
option name 'br-lan'
option type 'bridge'
list ports 'eth1'
list ports 'eth2'
list ports 'eth3'
-
c'est bizarre cette histoire...et en wifi il se passe la meme chose ?
Tu peux poster ton /etc/config/network après installation d'opnwrt et avant modification ?
j'ai un doute sur ton :
config device
option name 'br-lan'
option type 'bridge'
list ports 'eth1'
list ports 'eth2'
list ports 'eth3'
C'est de base dans ma version d'openwrt, j'ai pas modifier ca.
Je vais essayer en wi-fi
-
Même chose en wi-fi
-
ben alors la je ne vois pas, il faut aller sur le forum openwrt du ax3600, ca doit etre un truc tout con...
-
Tu peux faire un screen de ta page Network >> Switch ?
http://192.168.1.1/cgi-bin/luci/admin/network/switch
-
Tu peux faire un screen de ta page Network >> Switch ?
http://192.168.1.1/cgi-bin/luci/admin/network/switch
Je n'ai pas la page Switch sur cette version...
Je vais essayer de voir... Je dirais si j'ai trouver la solution
-
ha...
d'après wikidevi c'est le Qualcomm Atheros QCA8075 qui fait aoffice de switch.
https://wikidevi.wi-cat.ru/Xiaomi_Mi_AX3600
Le portage d'openwrt est loin d'etre fini sur ce routeur, il n'y a meme pas de snaphsot dispo...
je pense que tu aurais plus de chances de réussite en utilisant le firmware d'origine ROOTÉ.
-
ben alors la je ne vois pas, il faut aller sur le forum openwrt du ax3600, ca doit etre un truc tout con...
Petite update :
J'ai refait l'installation au propre, le pare feux est bien le problème en tout cas pour l'IPV6 mais pour l'IPV4 je ne sais pas
Quand je désactive le par feux par un /etc/init.d/firewall stop quand j'essaie de ping 8.8.8.8 j'ai "Délai d’attente de la demande dépassé." mais j'ai acces a internet mais juste en IPV6
Sans le désactiver IPV6 et IPV4 me dise "Impossible de joindre le port de destination."
-
si je stoppe le Firewall moi non plus je n'ai plus accès à internet, car si je ne dis pas de bétises il n'y a plus de NAT.
-
essaie voir en supprimant ca de ton /etc/config/network
config switch_vlan
option device 'switch0'
option vlan '2'
option ports '0t 6t'
option vid '832'
puis /etc/init.d/network restart
-
essaie voir en supprimant ca de ton /etc/config/network
config switch_vlan
option device 'switch0'
option vlan '2'
option ports '0t 6t'
option vid '832'
puis /etc/init.d/network restart
C'est déjà retirer je ne l'ai pas mis dans mon essai actuel
etc/config/firewall :
config defaults
option syn_flood 1
option input ACCEPT
option output ACCEPT
option forward REJECT
# Uncomment this line to disable ipv6 rules
# option disable_ipv6 1
config zone
option name lan
list network 'lan'
option input ACCEPT
option output ACCEPT
option forward ACCEPT
config zone
option name wan
list network 'wan'
option input REJECT
option output ACCEPT
option forward REJECT
option masq 1
option mtu_fix 0
option family ipv4
config zone
option name wan6
list network 'wan6'
option input REJECT
option output ACCEPT
option forward REJECT
option masq 0
option mtu_fix 0
option family ipv6
config forwarding
option src lan
option dest wan
config forwarding
option src lan
option dest wan6
config include
option path '/etc/firewall.user'
# We need to accept udp packets on port 68,
# see https://dev.openwrt.org/ticket/4108
config rule
option name Allow-DHCP-Renew
option src wan
option proto udp
option dest_port 68
option target ACCEPT
option family ipv4
# Allow IPv4 ping
config rule
option name Allow-Ping
option src wan
option proto icmp
option icmp_type echo-request
option family ipv4
option target ACCEPT
config rule
option name Allow-IGMP
option src wan
option proto igmp
option family ipv4
option target ACCEPT
# Allow DHCPv6 replies
# see https://dev.openwrt.org/ticket/10381
config rule
option name Allow-DHCPv6
option src wan6
option proto udp
option src_ip fc00::/6
option dest_ip fc00::/6
option dest_port 546
option family ipv6
option target ACCEPT
config rule
option name Allow-MLD
option src wan6
option proto icmp
option src_ip fe80::/10
list icmp_type '130/0'
list icmp_type '131/0'
list icmp_type '132/0'
list icmp_type '143/0'
option family ipv6
option target ACCEPT
# Allow essential incoming IPv6 ICMP traffic
config rule
option name Allow-ICMPv6-Input
option src wan6
option proto icmp
list icmp_type echo-request
list icmp_type echo-reply
list icmp_type destination-unreachable
list icmp_type packet-too-big
list icmp_type time-exceeded
list icmp_type bad-header
list icmp_type unknown-header-type
list icmp_type router-solicitation
list icmp_type neighbour-solicitation
list icmp_type router-advertisement
list icmp_type neighbour-advertisement
option limit 1000/sec
option family ipv6
option target ACCEPT
# Allow essential forwarded IPv6 ICMP traffic
config rule
option name Allow-ICMPv6-Forward
option src wan6
option dest *
option proto icmp
list icmp_type echo-request
list icmp_type echo-reply
list icmp_type destination-unreachable
list icmp_type packet-too-big
list icmp_type time-exceeded
list icmp_type bad-header
list icmp_type unknown-header-type
option limit 1000/sec
option family ipv6
option target ACCEPT
config rule
option name Allow-IPSec-ESP
option src wan
option dest lan
option proto esp
option target ACCEPT
config rule
option name Allow-ISAKMP
option src wan
option dest lan
option dest_port 500
option proto udp
option target ACCEPT
### EXAMPLE CONFIG SECTIONS
# do not allow a specific ip to access wan
#config rule
# option src lan
# option src_ip 192.168.45.2
# option dest wan
# option proto tcp
# option target REJECT
# block a specific mac on wan
#config rule
# option dest wan
# option src_mac 00:11:22:33:44:66
# option target REJECT
# block incoming ICMP traffic on a zone
#config rule
# option src lan
# option proto ICMP
# option target DROP
# port redirect port coming in on wan to lan
#config redirect
# option src wan
# option src_dport 80
# option dest lan
# option dest_ip 192.168.16.235
# option dest_port 80
# option proto tcp
# port redirect of remapped ssh port (22001) on wan
#config redirect
# option src wan
# option src_dport 22001
# option dest lan
# option dest_port 22
# option proto tcp
### FULL CONFIG SECTIONS
#config rule
# option src lan
# option src_ip 192.168.45.2
# option src_mac 00:11:22:33:44:55
# option src_port 80
# option dest wan
# option dest_ip 194.25.2.129
# option dest_port 120
# option proto tcp
# option target REJECT
#config redirect
# option src lan
# option src_ip 192.168.45.2
# option src_mac 00:11:22:33:44:55
# option src_port 1024
# option src_dport 80
# option dest_ip 194.25.2.129
# option dest_port 120
# option proto tcp
etc/config/network
config interface 'loopback'
option device 'lo'
option proto 'static'
option ipaddr '127.0.0.1'
option netmask '255.0.0.0'
config globals 'globals'
option ula_prefix 'fd08:5a5b:b71a::/48'
config device
option name 'br-lan'
option type 'bridge'
list ports 'eth1'
list ports 'eth2'
list ports 'eth3'
config interface 'lan'
option device 'br-lan'
option proto 'static'
option ipaddr '192.168.1.1'
option netmask '255.255.255.0'
option ip6assign '64'
config interface 'wan'
option device 'eth0.832'
option proto 'dhcp'
option broadcast '1'
option vendorid 'sagem'
option reqopts '1 15 28 51 58 59 90'
option sendopts '77:2b46535644534c5f6c697665626f782e496e7465726e65742e736f66746174686f6d652e4c697665626f7834 90:00000000000000000000001a0900000558010341010d6674692F'
config interface 'wan6'
option device 'eth0.832'
option proto 'dhcpv6'
option reqprefix 'auto'
option reqaddress 'none'
option defaultreqopts '0'
option sendopts '11:00000000000000000000001a0900000558010341010d6674692F 15:FSVDSL_livebox.Internet.softathome.livebox4 16:0000040e0005736167656d'
option reqopts '11 17 23 24'
option noclientfqdn '1'
option noacceptreconfig '1'
option peerdns '0'
list dns '2606:4700:4700::1111'
list dns '2606:4700:4700::1001'
-
Bon maintenant IPV6 fonctionne normalement, j'ai un peu toucher au règle du firewall et ca a marcher.
Mais toujours pas IPV4, mon problème se situerais peut-être au niveau du NAT ?
-
est-ce que tu peux pinguer l'ip d'un autre PC branché sur un des ports du routeur ?
-
est-ce que tu peux pinguer l'ip d'un autre PC branché sur un des ports du routeur ?
oui je peux
-
dans le doute regarde si tu as ces packages d'installés :
(https://i.imgur.com/DkR5DDy.png)
-
dans le doute regarde si tu as ces packages d'installés :
(https://i.imgur.com/DkR5DDy.png)
Oui je les ai tous
-
Bonjour a tous,
J'ai réussi à faire fonctionner IPV6 et IPV4 si d'autre on le même problème que moi, faites le tuto mais sans modifier /etc/config/firewall.
Je ferais un GitHub avec les fichiers pour facilité la vie des utilisateurs des AX3600 quand j'aurais fini.
Mais j'ai encore un problème quand je fais un speed test j'ai 35/0.5 de débit, j'ai essayé de mettre le firewall.user et de mettre la ligne de code dans /etc/config/firewall pour qu'il se lance mais rien n'y fait.
-
firewall.user ne peut pas fonctionner dans ton cas, car tu as nftables et pas iptables.
Les commandes iptables doivent être adaptées à nftables, et là franchement je ne saurais t'aider.
-
Je bataille avec une ligne Sosh (membre de la famille) qui n'est toujours pas active car pas assez de brins fibre dispo sur le PB.
Du coup c'est chaise musicale avec les voisins, SFR est l'opérateur qui a fibré la ville et je n'ai pas l'impression que c'est des rapides pour corriger le tir.
Des que c'est opérationnel je m'y mets et j'updaterai le tuto, j'ai un Linksys 1200AC en 21.02 qui attend dans le carton.
-
Je bataille avec une ligne Sosh (membre de la famille) qui n'est toujours pas active car pas assez de brins fibre dispo sur le PB.
Du coup c'est chaise musicale avec les voisins, SFR est l'opérateur qui a fibré la ville et je n'ai pas l'impression que c'est des rapides pour corriger le tir.
Des que c'est opérationnel je m'y mets et j'updaterai le tuto, j'ai un Linksys 1200AC en 21.02 qui attend dans le carton.
Okay nickel c'est gentil ;)
Pour l'instant j'avais un peu toucher aux règles NFTABLES en essayant de convertir les tiennes qui était en IPTABLES, j'arrivais a 570/535 mbps en IPV6 ou IPV4 avec mon processeur seulement 35-40% sur le premier cœur et 25% sur les 3 autres environs.
Pourtant j'ai l'offre Up Fibre a 2gbps/600 (Je sais l'ONT est limité a 1Gbps). J'ai essayé de faire de l'offloading mais ca me remettais a 35/0.5 mbps.
Je vais attendre tes instructions je pense, ca a déjà bien manger sur mon sommeil ;D
-
Par contre en 21.02 c'est pas tous les routeurs qui sont en nftables. Mon APU2C4 et resté en iptables, mon A8000RU est passé en nftables...
-
je viens de trouver une info interessante:
https://forum.openwrt.org/t/22-03-0-rc1-nftables-fw4-migration-guide/125949/2?u=shdf
The package iptables-nft is fully compatible with nftables and actually uses nftables underneath. It provides the command "iptables" so old iptables scripts can still be used.
-
Bonjour,
Tout d'abord merci pour ce précieux tutoriel. J'ai une question avant de commencer : Étant donné que j'utilise un ancien pc mini itx pour le projet je n'ai pas de switch intégré, seulement l'interface réseau de base + une autre interface branchée en PCI. Le switch que je vais utiliser est donc externe, c'est un Netgear GS724T. Ainsi je me demandais si dans mon cas la partie "configurer le "switch" pour taguer le vlan 832" devait se faire dans /etc/config/network sur le routeur ou alors dans le switch Netgear directement, et si tel est le cas comment faudrait-il s'y prendre.
Si par ailleurs il y a d'autres parties du tutoriel qui doivent être adaptées dans la mesure où j'utilise un pc au lieu d'un "vrai" routeur, merci de me le faire savoir également.
Par avance merci pour votre aide.
Cordialement
-
Bonjour à tous. Je viens de déménager cette semaine et j'ai une nouvelle connexion orange. Au lieu de reprendre mon routeur précédent, j'ai installé une 21.02 sur un routeur Xiaomi R3G de test. Je compte m'attaquer à la config d'ici quelques jours. Mais d'abord il faut que je passe les cables CAT6A dans les gaines de la maison. Je serai donc aussi dispo pour aider pour le tuto 21.02 et réaliser quelques tests de configs.
-
Pour le 21.02 il y a trop peu de différence vs le 18.06 (il y a juste quelques commandes iptables qui ont été intégré). A mon avis il faudra reprendre le tuto pour openwrt 22.03 (première version en nftable).
-
Bonsoir à tous, depuis le dernier reboot de mon routeur openwrt en 21.02.3 mercredi dernier, je n’ai plus d’internet.
La livebox fonctionne et quand je rebranche mon routeur il reçoit une IP du genre 172.16.x.x
Suis-je le seul ? Comment résoudre ?
-
Peut etre le meme probleme qu'ici :
https://lafibre.info/remplacer-livebox/cacking-nouveau-systeme-de-generation-de-loption-90-dhcp/msg947187/#msg947187
génère ou récupère une option DHCP 90 valide.
-
Hello même souci que @kourai.
J'ai posté les info sur le thread de l'opt DHCP (90) mais je ne suis pas sur que ça soit cette option qui pose pb.
J'utilise la fibre sosh et ce matin j'ai voulu passer sous openWRT (Xiaomi AX3600) via le transsiver fibre orange mais j'ai eu beaucoup de soucis, bon nous sommes passé de iptables à nftables sur ma version de openwrt, mais même en traduisant les règles toujours pas de réponse à ma requéte DHCP.
J'ai copier l'option 90 via livebox info, pas mieux.
root@OpenWrt:~# udhcpc -p /var/run/udhcpc-eth0.832.pid -t 0 -i eth0.832 -x hostname:OpenWrt -V sagem -C -B -R -O 1 -O 15 -O 28 -O 51 -O 58 -O 59 -O 90 -x 61:010887C659B5C0 -x 77:2b46535644534c5f6c697665626f782e496e7465726e65742e736f66746174686f6d652e4c697665626f7834 -x 90:00000000000000000000001a0900000558010341010d6674692f677a616634757a3c124a2f5b7872XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX714
udhcpc: started, v1.35.0
udhcpc: broadcasting discover
udhcpc: broadcasting select for 172.16.150.131, server 80.10.247.48
udhcpc: broadcasting select for 172.16.150.131, server 80.10.247.48
udhcpc: broadcasting select for 172.16.150.131, server 80.10.247.48
Auriez-vous une idée pour m'aider ?
-
il faudrait demander au gars qui fait le snapshot pour le ax3600, d'avoir l'amabilité de compiler une version avec iptables.
il existe un frontend en ligne qui de permet créer facilement sa propre image avec les paquets de son choix ici : https://chef.libremesh.org/
malheureusement l'ax3600 n'est pas encore supporté, meme en snapshot, il faudra encore attendre pour pouvoir le faire.
-
Oui, malheureusement les issue ne semblent pas ouvertes sur le github, c'est vrai que j'ai (comme beaucoup je pense) beaucoup plus de facilitées avec iptables mais ma conf de nft me semblais correct:
nft add rule inet fw4 mangle_postrouting counter meta priority set 0:1
nft add rule inet fw4 mangle_postrouting ip protocol icmp counter meta priority set 0:6
nft add rule inet fw4 mangle_postrouting ip protocol igmp counter meta priority set 0:6
nft add rule inet fw4 mangle_postrouting oifname "eth1.832" udp dport 67 counter meta priority set 0:6
(https://i.ibb.co/mNx0ZLt/screen-2022-05-16-14-20-30.png)
-
nft add rule inet fw4 mangle_postrouting oifname "eth1.832" udp dport 67 counter meta priority set 0:6
ca ne correspond pas à ton image écran sur Luci : eth0.832 ? normal ?
Sinon as tu essayé, comme je l'indiquais ici (https://lafibre.info/remplacer-livebox/remplacement-de-la-livebox-par-un-routeur-openwrt-18-dhcp-v4v6-tv/msg945669/#msg945669), le paquet iptables-nft. Qui, si j'ai bien compris, permettrai de rendre compatibles les scripts iptables avec nft. Donc l'utilisation d'une commande iptables serait automatiquement interpretée comme une commande nftable.
EDIT:
autre point à noter.
dans /etc/config/firewall avec fw4 (nftables)
le paramètre include :
config include
option path '/etc/firewall.user'n'est plus exécuté !
Donc si tu as mis tes regles nft dans le fichier firewall.user, cela explique peut etre pourquoi ca ne marche pas.
essaie de les executer manuellement dans putty pour voir si tu obtiens une ip après exécution ?
ou bien integre les lignes a la fin du vlanprio.sh ?
-
Hello,
Oui effectivement j'ai changé le eth1 en 0 dans ma conf (celle du screen est la bonne)
J'ai bien rendu le script firewall.user exécutable et je l'ai lancé a la main mais pas mieux.
Pour le paquet j'ai bien tenté une installation mais il ne le trouve pas.
J'ai trouvé un topic sur stackexchange avec quelqu'un qui fait du nft sous debian et pour qui ça semble fonctionner.
https://unix.stackexchange.com/questions/479796/packet-meta-class-applied-but-captured-vlan-priority-is-wrong
J'ai lancé un tcpdump pour voir un peu les requêtes, je vois un tos 0x0, normal ?
16:43:43.127028 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 430)
0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 28:d1:27:fc:96:83 (oui Unknown), length 402, xid 0x21e89b20, secs 207, Flags [Broadcast]
Client-Ethernet-Address 28:d1:27:fc:96:83 (oui Unknown)
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Discover
Requested-IP Option 50, length 4: 172.16.150.131
MSZ Option 57, length 2: 576
Parameter-Request Option 55, length 12:
Subnet-Mask, Default-Gateway, Domain-Name-Server, Hostname
Domain-Name, BR, NTP, Lease-Time
RN, RB, AUTH, Classless-Static-Route
Hostname Option 12, length 7: "OpenWrt"
Vendor-Class Option 60, length 5: "sagem"
User-Class Option 77, length 44:
instance#1: "FSVDSL_livebox.Internet.softathome.Livebox4", length 43
AUTH Option 90, length 70: 0.0.0.0.0.0.0.0.0.0.0.26.9.0.0.5.88.1.3.65.1.13.102.116.105.47.103.122.97.102.52.117.122.60.18.74.47.91.120.114.66.36.118.63.56.108.92.58.103.39.70.3.19.108.XX.XX.XXX.XXX.XX.XXX.XXX.XXX.XXX.XX.XXX.XXX.XXX.XXX.XXX.XX
16:43:43.145564 IP (tos 0xc0, ttl 64, id 61260, offset 0, flags [none], proto UDP (17), length 332)
le second paquet semble étrange aussi:
172.16.0.1.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 304, xid 0x21e89b20, secs 207, Flags [Broadcast]
Your-IP 172.16.150.131
Server-IP 80.10.247.48
Gateway-IP 80.10.236.129
Client-Ethernet-Address 28:d1:27:fc:96:83 (oui Unknown)
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Offer
Server-ID Option 54, length 4: 80.10.247.48
Lease-Time Option 51, length 4: 7200
AUTH Option 90, length 27: 0.0.0.0.0.0.0.0.0.0.0.100.104.99.112.108.105.118.101.98.111.120.102.114.50.53.48
T125 Option 125, length 17: 0.0.5.88.12.1.10.1.255.1.0.255.255.255.255.255.255
16:43:43.206938 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 436)
-
J'ai bien rendu le script firewall.user exécutable et je l'ai lancé a la main mais pas mieux.
il me semble qu'il y a un ordre a respecter. le vlanprio.sh doit etre executé après le firewall. Si tu n'as pas déjà testé ?
donc
/etc/init.d/firewall restart
./firewall.user.sh
./vlanprio.sh
J'ai trouvé un topic sur stackexchange avec quelqu'un qui fait du nft sous debian et pour qui ça semble fonctionner.
https://unix.stackexchange.com/questions/479796/packet-meta-class-applied-but-captured-vlan-priority-is-wrong
alors ca, ca ne concerne pas nftables, ce serait plutot pour la partie qui se trouve dans le vlanprio.sh
mais dans openwrt il n'y a pas de commande up ou de pre-up
-
On s’en fout du tos, c’est pas ça qui est sensé être à 6, mais la CoS 802.1p qui est dans l’entête ethernet, et que l’on ne voit pas ici car ce n’est pas eth0.832 qu’il faut sniffer mais eth0 (afin de voir tous les VLANs).
-
Hello, merci, je confirme que ça fonctionne, je te répond depuis ma connexion wifi sur mon AX3600.
Merci beaucoup, c'était bien l'ordre qui posait problème apparemment.
Je vais voir pour intégrer tout ça correctement dans un script commun.
Pour ce qui est des règles NFTables (FW4) je confirme qu'elle fonctionnent, résultat sans les règles:
(https://i.ibb.co/C8Dy6fP/screen-2022-05-17-07-31-14.png)
Avec:
(https://i.ibb.co/TbhVVDs/screen-2022-05-17-07-40-18.png)
Je met les règles ici si ça peux servir :
root@OpenWrt:~# nft list ruleset
[...]
chain mangle_postrouting {
type filter hook postrouting priority mangle; policy accept;
counter packets 693553 bytes 1124288097 meta priority set 0:1
ip protocol icmp counter packets 12 bytes 6912 meta priority set 0:6
ip protocol igmp counter packets 60 bytes 1920 meta priority set 0:6
oifname "eth0.832" udp dport 67 counter packets 0 bytes 0 meta priority set 0:6
}
le script firewall.user:
root@OpenWrt:~# cat /etc/firewall.user
nft add rule inet fw4 mangle_postrouting counter meta priority set 0:1
nft add rule inet fw4 mangle_postrouting ip protocol icmp counter meta priority set 0:6
nft add rule inet fw4 mangle_postrouting ip protocol igmp counter meta priority set 0:6
nft add rule inet fw4 mangle_postrouting oifname "eth0.832" udp dport 67 counter meta priority set 0:6
-
Bravo !! ;)
-
Salut à toutes et tous.
First thing first merci à l'auteur et aux passionnés de partager ces précieuses informations. C'est de la balle.
EDIT 2 : /etc/config/network
Je tente depuis hier de mettre en place un routeur à la zonmé. Js'uis pas un ouf en réseau mais c'est justement pour monter un lab et commencer à entrer dans le vif du sujet.
Si quelqu'un est ok pour m'aiguiller ou m'aider à combler mon insondable ignorance je suis preneur.
Je dispose d'un mikrotik HexS (http://mikrotik HexS) flashé avec la version snapshsot d'Openwrt r19670-16e9ccd5fa.
J'ai un adaptateur compatible orange me semble-t-il : GPON SFP ONT Sercom FGS202.
Le projet est plutôt simple en faire le routeur avec le WAN sur le SFP et distribuer le réseau ensuite sur le LAN avec des VLAN.
Vraisemblablement y'a plus qu'à.
Sauf que y'a des trucs que j'ai pas capté. C'est pour ça que je suis viendu vous demander
1. le tag vlan du cpu : t pour tag, on tag sur le port 4 (qui est le port wan) et le 6 c'est mon cpu eth1.
Je pige pas. meme avec la doc : https://openwrt.org/docs/guide-user/network/vlan/switch_configuration
2. Il semble qu'il y a des choses qui ont changé sur les dernières versions comme la syntaxe du fichier /etc/config/network : https://openwrt.org/releases/21.02/notes-21.02.0#new_network_configuration_syntax_and_boardjson_change
Bon j'ai tenté une conf mais sans succès.
Si vous voulez zyeuter :
config interface 'loopback'
option device 'lo'
option proto 'static'
option ipaddr '127.0.0.1'
option netmask '255.0.0.0'
config globals 'globals'
option packet_steering '1'
option ula_prefix 'fd27:cf44:3355::/48'
config device
option name 'br-lan'
option type 'bridge'
list ports 'lan2'
list ports 'lan3'
list ports 'lan4'
list ports 'lan5'
config device
option name 'lan2'
option macaddr 'dc:2c:6e:80:XX:YY'
config device
option name 'lan3'
option macaddr 'dc:2c:6e:80:XX:YY'
config device
option name 'lan4'
option macaddr 'dc:2c:6e:80:XX:YY'
config device
option name 'lan5'
option macaddr 'dc:2c:6e:80:XX:YY'
config interface 'lan'
option device 'br-lan'
option proto 'static'
option ipaddr '192.168.1.1'
option netmask '255.255.255.0'
option ip6assign '64'
config device
option name 'br-wan'
option type 'bridge'
list ports 'eth0'
list ports 'sfp'
list ports 'wan'
config device
option name 'wan'
option macaddr 'dc:2c:6e:80:XX:ZZ'
config device
option name 'sfp'
option macaddr 'dc:2c:6e:80:XX:ZZ'
config device
option name 'sfp.832'
option type '8021q'
option ifname 'sfp'
option vid '832'
list egress_qos_mapping '0:0'
list egress_qos_mapping '2:2'
list egress_qos_mapping '3:3'
list egress_qos_mapping '4:4'
list egress_qos_mapping '5:5'
list egress_qos_mapping '6:6'
list egress_qos_mapping '7:7'
list egress_qos_mapping '1:0'
list egress_qos_mapping '0:6'
config interface 'wan'
option device 'sfp.832'
option proto 'dhcp'
option broadcast '1'
option vendorid 'sagem'
option reqopts '1 15 28 51 58 59 90'
option sendopts '77:2b46535644534c5f6c697665626f782e496e7465726e65742e736f66746174686f6d652e4c697665626f7834 90:FTI/PASSWORD'
config interface 'wan6'
option device 'sfp.832'
option proto 'dhcpv6'
option reqprefix 'auto'
option reqaddress 'none'
option defaultreqopts '0'
option sendopts '11:00000000000000000000001a0900000558010341010d6674692f6674692f7574677a716464 15:FSVDSL_livebox.Internet.softathome.livebox4 16:0000040e0005736167656d'
option reqopts '11 17 23 24'
option noclientfqdn '1'
option noacceptreconfig '1'
Avant de me lancer plus loin je voulais savoir si il y a des étapes complémentaires à ce tuto (je pense que oui) ?
Par exemple :
1. Le passage à nftables
Merci @simonf :
2. La nécessité d'ajouter le password salté/hashé autrement dit version longue pour option 90.
Merci @cetipabo
Merci @ElementW
Si quelqu'un peut m’éclairer avant que je me lance ça me motiverait à fond.
Merci d'avance.
@+
EDIT : typo
EDIT 2 : Update
EDIT 3 : Il avait pas obfusqué ses MAC le type.
-
J'ai un adaptateur compatible orange me semble-t-il : GPON SFP ONT Sercom FGS202.
c'est celui qu'orange t'a fourni et qui est bien enregistré chez eux ? Si orange ne connait pas ton ONT, la suite n'a aucune chance de fonctionner. Donc 1er point à vérifier.
-
Arf j'avais pas saisis cet important detail merci cetipabo.
Etant donné que j'ai une Livebox 5 je ne sais pas comment faire pour obtenir un adatateur SFP (Livebox 4 ) alors que c'est integré sur la 5.
Je vais devoir asser au boitier ONT ? :'( ( c'est moins fun ) .
-
tu peux utiliser un ONT SFP compatible, dans lequel tu peux cloner les infos de l'ONT interne de ta Livebox 5. La liste est dispo sur ce topic (https://lafibre.info/remplacer-livebox/guide-de-connexion-fibre-directement-sur-un-routeur-voire-meme-en-2gbps/)
en l'occurence, celui-ci : https://www.fs.com/fr/products/133619.html
Etant donné que ton Hex S n'a que des ports 1Gb il n'est pas necessaire de faire tout le tralala pour rendre l'ONT compatible 2.5Gb. il faut juste cloner les infos de l'ONT de ta Livebox 5, et il te suffit de le demander au commercial lors de l'achat, tu lui fournis les infos et tu le recois déjà flashé, pret a l'emploi. je te conseille d'aller dans le topic en question et de poser les questions a ceux qui en savent plus que moi sur le sujet :D
-
Cette lecture est diablement intéressante.
Merci.
PS : Je ferais un recap en cas de réussite.
PS2 : Ce site est genial.
-
Hello,
Merci pour vos messages, j'ai un edgerouterX en 22.03 RC2 (snapshot), et ça m'a pris 3min pour adapter la conf.
J'attends la release de la 22.03 avant de maj completement le tuto, mais je vais mettre ma config à dispo en page 1.
Pour rappel, en 22.03 il n'y a plus d'iptables du tout.
Mon edgerouter X est en remplacement d'une Livebox 5, avec un ONT LEOX (cf schéma).
Ipv4/ipv6 100% ok, il n'y a besoin d'aucun fichier de config ou package en + que ceux natif openwrt, c'est même faisable depuis l'interface web.
Tout se passe dans le fichier network, et le fichier rc.local pour ajouter les commandes nft après le boot (Merci simonf).
Dans ma config, je sépare toujours la zone FW WAN (ipv4 only) et WAN6 (ipv6 only).
Au passage, un edgerouterX@openwrt avec l'offloading hardware activé, ça donne 900-920down /800up cf screenshot.
-
J'ai maj le premier post du topic, le 2em post contient l'ancien tuto.
-
J'ai maj le premier post du topic, le 2em post contient l'ancien tuto.
Salut. Merci pour la mise à jour du tuto. En comparant avec l'ancienne config je me demande pourquoi tu as cette fois ci passé les config suivantes dans le firewall :
Pour Wan:
option forward 'ACCEPT'
Pour Wan6 :
option forward 'ACCEPT'
option mtu_fix '1'
Est-ce lié à cette partie ?
config forwarding #Attention, ici c'est en mode freebox, on autorise le flux wan6 to lan
option src 'wan6'
option dest 'lan'
-
Salut. Merci pour la mise à jour du tuto. En comparant avec l'ancienne config je me demande pourquoi tu as cette fois ci passé les config suivantes dans le firewall :
Pour Wan:
option forward 'ACCEPT'
Je retire, c'est un oublie, c'est dans la conf par défaut, mais n'a pas d'interet (surtout en v4).
Pour Wan6 :
option forward 'ACCEPT'
option mtu_fix '1'Le forward general 'ACCEPT' n'a pas d'interet car on précise ensuite les src/dest, je corrige aussi, concernant le mss clamping (mtu_fix) on peut le retirer aussi car nos liens Fibre Orange sont en MTU 1500.
Est-ce lié à cette partie ?
config forwarding #Attention, ici c'est en mode freebox, on autorise le flux wan6 to lan
option src 'wan6'
option dest 'lan'Non même si tu mets le forward de la zone en drop, si tu spécifie ici ça fonctionnera.
Merci pour le retour je lmaj le tuto en conséquence.
-
Après vérification, je vois que mon flux sortant passe encore en prio 6.
08:37:44.992061 78:8a:20:f9:ff:1e > a0:f3:e4:51:a7:a7, ethertype 802.1Q (0x8100), length 78: vlan 832, p 6, ethertype IPv6, 2a01:cb1d:XXX:XXXX:7819:c6bd:31e7:e1a9.51624 > 2a01:cb1c:2004:4000::3.8080: Flags [R], seq 3746280205, win 0, length 0
Pourtant pas de problème de débit, mais c'est un coup de chance.
J'essaie de changer la config coté nft et j'updaterai le post.
Edit :
J'ai ce comportement qu'avec l'offloading hardware actif sur mon erx.
Sans j'ai bien la prio 0 sur tout mon traffic.
Cependant je vois que l'icmp sortant est toujours en prio 0, malgré les rules spécifiques, donc ça pourrait poser soucis sur un renew dhcp du wan si l'autre rule udp port 67 ne fonctionne pas par exemple.
Edit2, j'ai corrigé le mapping eth0 comme annoncé précedemment. Et les rules fonctionnent.
Concernant l'erx je vais maj en 22.03.RC3 et refaire le test (offload).
-
La priorité de l’ICMP apparemment Orange s’en fout partout : je suis dans une zone où la priorité à 6 est obligatoire pour le DHCP, mais je n’ai aucune règle pour ICMP (ni ARP d’ailleurs, la box applique aussi une CoS 6 sur ARP) qui est donc en priorité 0.
-
@ubune, si tu fais un speedtest/nperf en ipv6 avec ton ERX, quel débit obtiens-tu ?
Chez SFR, en CGNAT, sur un xiaomi MI 3G avec MT7621, HW NAT activé, sur dernière image stable, 920Mbps en ipv4 cpu a 0%, mais en ipv6 625Mbps seulement et cpu a 100%.
pourtant il y a eu un patch il n'y a pas lontemps qui apportait de l'offloading sur le routage en ipv6, et d'après les tests, ipv6 et ipv4 etaient tous deux +900Mbps
https://lafibre.info/remplacer-sfr/ftth-tuto-bypass-complet-neufbox-avec-un-routeur-openwrt/msg952212/#msg952212
-
La priorité de l’ICMP apparemment Orange s’en fout partout : je suis dans une zone où la priorité à 6 est obligatoire pour le DHCP, mais je n’ai aucune règle pour ICMP (ni ARP d’ailleurs, la box applique aussi une CoS 6 sur ARP) qui est donc en priorité 0.
Oui c'est ça, mais en faite c'était surtout pour vérifier facilement si les rules étaient bien prises en compte.
Car si le ping sort en p 6 ça voulait dire que mon renew dhcp partira également en p 6.
Mais au final tout est ok, le problème est sur mon soc avec offloading hardware actif.
@ubune, si tu fais un speedtest/nperf en ipv6 avec ton ERX, quel débit obtiens-tu ?
Chez SFR, en CGNAT, sur un xiaomi MI 3G avec MT7621, HW NAT activé, sur dernière image stable, 920Mbps en ipv4 cpu a 0%, mais en ipv6 625Mbps seulement et cpu a 100%.
pourtant il y a eu un patch il n'y a pas lontemps qui apportait de l'offloading sur le routage en ipv6, et d'après les tests, ipv6 et ipv4 etaient tous deux +900Mbps
https://lafibre.info/remplacer-sfr/ftth-tuto-bypass-complet-neufbox-avec-un-routeur-openwrt/msg952212/#msg952212
Je te confirme, avec offloading actif je suis à 900-920 en ipv4 ET ipv6 avec MT7621 (erx) en 22.03.RC3
Cependant laissez l'offloading actif sur ce soc ne permet plus aux rules nft de fonctionner correctement.
Pour l'instant je conseillerai d'utiliser l'erx avec un switch qui modifie la prio en amont, ou sans offload si abonnement < 500Mbps.
-
Je te confirme, avec offloading actif je suis à 900-920 en ipv4 ET ipv6 avec MT7621 (erx) en 22.03.RC3
Cependant laissez l'offloading actif sur ce soc ne permet plus aux rules nft de fonctionner correctement.
Pour l'instant je conseillerai d'utiliser l'erx avec un switch qui modifie la prio en amont, ou sans offload si abonnement < 500Mbps.
Je viens de faire un test avec le nouveau tuto sur un Xiaomi R3G V1 (aussi avec le soc MT7621) flashé en 22.03.RC3. J'ai bien mon IPv4 et IPv6 sur le wan. La seule chose que j'ai du adapter c'est le nom de l'interface qui s'appelle wan au lieu de eth0 sur le R3G. Nickel 8)
Je suis sur une connexion Sosh 300M, donc mes tests sont limités, mais j'ai remarqué que lorsque j'ai activé l'offloading hardware pour la premiere fois, mon débit a été fortement réduit (environ 20M max). En relançant les regles NFT pour forcer les prio à la main, tout est rentré dans l'ordre. Depuis à chaque reboot je n'ai pas de perte de débit malgré l'offloading hardware activé.
edit : J'ai peut être crié victoire trop vite, on dirait que les regles nft sont instables, je suis au moins tombé sur une occurence ou j'ai du les relancer manuellement. Peut-etre faudrait-il prévoir un job cron qui les passerait toutes les 10 minutes.
-
Je viens de faire un test avec le nouveau tuto sur un Xiaomi R3G V1 (aussi avec le soc MT7621) flashé en 22.03.RC3. J'ai bien mon IPv4 et IPv6 sur le wan. La seule chose que j'ai du adapter c'est le nom de l'interface qui s'appelle wan au lieu de eth0 sur le R3G. Nickel 8)
Je suis sur une connexion Sosh 300M, donc mes tests sont limités, mais j'ai remarqué que lorsque j'ai activé l'offloading hardware pour la premiere fois, mon débit a été fortement réduit (environ 20M max). En relançant les regles NFT pour forcer les prio à la main, tout est rentré dans l'ordre. Depuis à chaque reboot je n'ai pas de perte de débit malgré l'offloading hardware activé.
edit : J'ai peut être crié victoire trop vite, on dirait que les regles nft sont instables, je suis au moins tombé sur une occurence ou j'ai du les relancer manuellement. Peut-etre faudrait-il prévoir un job cron qui les passerait toutes les 10 minutes.
Et attention, tout changement de config qui va reload le firewall va du coup faire disparaitre les règles.
Les ajouter à la suite c'est pas top car elles apparaissent plusieurs fois dans la table si elles y étaient déjà.
D'ailleurs je les ajoute 15sec (sleep 15 dans le rc.local) après le boot car sinon de temps en temps elles n'étaient pas chargées.
Pour vérifier tu peux utiliser cette commande :
nft list ruleset | grep "chain mangle_postrouting" -A 7
Qui donne comme résultat (si elles sont chargées) :
chain mangle_postrouting {
type filter hook postrouting priority mangle; policy accept;
oifname "eth0.832" counter packets 5274903 bytes 2564692315 meta priority set 0:1
oifname "eth0.832" ip protocol ipv6-icmp counter packets 0 bytes 0 meta priority set 0:6
oifname "eth0.832" udp dport 547 counter packets 0 bytes 0 meta priority set 0:6
oifname "eth0.832" ip protocol icmp counter packets 2992 bytes 455392 meta priority set 0:6
oifname "eth0.832" ip protocol igmp counter packets 0 bytes 0 meta priority set 0:6
oifname "eth0.832" udp dport 67 counter packets 0 bytes 0 meta priority set 0:6
Puisqu'on a le même soc peux-tu s'il te plait, faire une trace de flux sortant sur ton interface physique, sans mettre le vlan pour qu'on voit l'entete, et me dire si tous les flux initiés vers internet sont également en "p 6" quand tu as l'offloading actif, même si les rules sont chargées (vérifié avec la commande précedente).
La commande pour sniffer (remplace eth0 par le nom de ton interface physique sans vlan de sortie wan) :
tcpdump -nei eth0Tu fais control+c juste après pour cancel.
Merci d'avance !
-
Après avoir activé la config de la copie d'écran.
J'ai relancé les nft rules à la main. Ce qui donne :
nft list ruleset | grep "chain mangle_postrouting" -A 10
chain mangle_postrouting {
type filter hook postrouting priority mangle; policy accept;
oifname "wan.832" counter packets 7020 bytes 1281387 meta priority set 0:1
oifname "wan.832" ip protocol icmp counter packets 541 bytes 33450 meta priority set 0:6
oifname "wan.832" ip protocol igmp counter packets 0 bytes 0 meta priority set 0:6
oifname "wan.832" udp dport 67 counter packets 0 bytes 0 meta priority set 0:6
oifname "wan.832" udp dport 547 counter packets 0 bytes 0 meta priority set 0:6
oifname "wan.832" ip protocol ipv6-icmp counter packets 0 bytes 0 meta priority set 0:6
}
chain mangle_input {
Le "tcpdump -nei wan" montre bien une grosse partie du traffic en prio 0 (p 0) et quelques paquets en (p 6). Speedtest sans soucis de débit.
Je vais garder cette config quelques heures voir si j'ai à nouveau des soucis de débit.
-
Attention !
Le plus gros du traffic visible sera le flux entrant, donc si tu vois le 0 c'est surtout pour les réponses.
Si tu vois encore du P 6 c'est que t'as le même symptome que moi avec l'offload actif.
Pour être sur, identifie les trames initiés depuis le lan, regarde dans le champ ip source quand tu vois ton ip publique ou ton /64, ici tu verras du P 6.
Retest sans l'offload (oublie pas de réappliquer les nft rules) et possiblement tu ne verras que du 0 (ou 6 avec un ping sortant ^^').
-
Attention !
Le plus gros du traffic visible sera le flux entrant, donc si tu vois le 0 c'est surtout pour les réponses.
Si tu vois encore du P 6 c'est que t'as le même symptome que moi avec l'offload actif.
Pour être sur, identifie les trames initiés depuis le lan, regarde dans le champ ip source quand tu vois ton ip publique ou ton /64, ici tu verras du P 6.
Retest sans l'offload (oublie pas de réappliquer les nft rules) et possiblement tu ne verras que du 0 (ou 6 avec un ping sortant ^^').
Effectivement. Voici un récap des tests :
1/ HW / SW offloading désactivé :
Sans NFT Rules : speedtest 50M down / 1M up
Avec NFT Rules : speedtest 290 down / 295 up + très peu de paquets en p 6 avec source mon ip publique (ICMP seulement)
2/ HW / SW offloading activé :
Sans NFT Rules : speedtest 50 M down / 1.1 M up
Avec NFT rules : speedtest 290 M down / 290 M up + quelques paquets en p 6 avec comme source mon ip publique (autres que ICMP), mais il y a aussi des paquets avec comme source mon ip publique qui partent en p 0.
On dirait que les rules ont de l'effet même dans la config HW offloading activé (vu l'impact sur mon débit). Mais quelques paquets passent tout de même au travers des filtres ?
-
Ok donc même soc même combat :)
C'est vraiment curieux en effet, si je fais un iperf3 ipv4 ou ipv6 j'ai les débits attendu (down/up).
Mais par exemple un nperf sur serveur ipv6 j'ai un upload catastrophique. Je vois bien le flux sortir en p 6.
Donc du coup je suis sans offload pour le moment (ça donne 700/400Mbps).
Sinon je suis en train de chercher un routeur permettant de faire du 2.5G car je vais acheter un Switch CRS305 + le SFP GPON-ONU-34-20BI.
@cetipabo tu m'avais donné quelques modèles il y a quelques temps, tu avais essayé ?
L'avantage c'est qu'avec le switch je vais pouvoir gerer le changement de COS (prio L2) en gardant l'existant (avec le port cuivre 1Gbps), jusqu'a trouver un routeur 2.5G ou + (en restant sur openwrt).
-
C'est un peu HS, mais dans ce cas pourquoi ne pas partir sur une solution type pfsense avec des interfaces en 2.5G ethernet : https://www.aliexpress.com/item/1005003744743799.html?spm=a2g0o.productlist.0.0.3c67495bxmBmI9&algo_pvid=a23d355b-357b-4af5-be9c-f28ea2f32c5d&algo_exp_id=a23d355b-357b-4af5-be9c-f28ea2f32c5d-2&pdp_ext_f=%7B%22sku_id%22%3A%2212000027020913559%22%7D&pdp_npi=2%40dis%21EUR%21%21193.97%21%21%21%21%21%400b0a01f816539164474638472e133e%2112000027020913559%21sea (https://www.aliexpress.com/item/1005003744743799.html?spm=a2g0o.productlist.0.0.3c67495bxmBmI9&algo_pvid=a23d355b-357b-4af5-be9c-f28ea2f32c5d&algo_exp_id=a23d355b-357b-4af5-be9c-f28ea2f32c5d-2&pdp_ext_f=%7B%22sku_id%22%3A%2212000027020913559%22%7D&pdp_npi=2%40dis%21EUR%21%21193.97%21%21%21%21%21%400b0a01f816539164474638472e133e%2112000027020913559%21sea)
Pour en revenir au topic, dernière question je pense pour moi, le forward de "wan6->lan" dans le tuto n'est pas un peu violent ? J'ai l'impression qu'il ouvre l'accès à toutes les machines du lan en IPv6.
Sans ce forward, j'ai toujours mon score de 19/20 sur ipv6-test. Pour ceux qui en ont besoin, ne faudrait-il mieux pas autoriser les IP du lan qui ont effectivement un serveur qui tourne ?
-
edit : J'ai peut être crié victoire trop vite, on dirait que les regles nft sont instables, je suis au moins tombé sur une occurence ou j'ai du les relancer manuellement. Peut-etre faudrait-il prévoir un job cron qui les passerait toutes les 10 minutes.
Je t'ai fait un truc très simple mais efficace (check toutes les 5min):
nano /etc/checknftrules.sh
#!/bin/sh
var=$(nft list ruleset | grep "set 0:" | wc -l);
if [ $var -ne 0 ]; then
echo "nft rules ok le $(date)" > /root/checkrules.txt
else
echo "nft rules corrige par le script le $(date)" >> /root/error-rules.txt
nft add rule inet fw4 mangle_postrouting oifname "wan.832" counter meta priority set 0:1
nft add rule inet fw4 mangle_postrouting oifname "wan.832" ip protocol icmpv6 counter meta priority set 0:6
nft add rule inet fw4 mangle_postrouting oifname "wan.832" udp dport 547 counter meta priority set 0:6
nft add rule inet fw4 mangle_postrouting oifname "wan.832" ip protocol icmp counter meta priority set 0:6
nft add rule inet fw4 mangle_postrouting oifname "wan.832" ip protocol igmp counter meta priority set 0:6
nft add rule inet fw4 mangle_postrouting oifname "wan.832" udp dport 67 counter meta priority set 0:6
fi
chmod a+x /etc/checknftrules.sh
crontab -e
*/5 * * * * /etc/checknftrules.sh
De plus, hésite pas à ajouter les scripts aux exclusions pour ne pas qu'ils soient supprimés lors d'une maj
-
C'est un peu HS, mais dans ce cas pourquoi ne pas partir sur une solution type pfsense : https://www.aliexpress.com/item/1005003744743799.html?spm=a2g0o.productlist.0.0.3c67495bxmBmI9&algo_pvid=a23d355b-357b-4af5-be9c-f28ea2f32c5d&algo_exp_id=a23d355b-357b-4af5-be9c-f28ea2f32c5d-2&pdp_ext_f=%7B%22sku_id%22%3A%2212000027020913559%22%7D&pdp_npi=2%40dis%21EUR%21%21193.97%21%21%21%21%21%400b0a01f816539164474638472e133e%2112000027020913559%21sea (https://www.aliexpress.com/item/1005003744743799.html?spm=a2g0o.productlist.0.0.3c67495bxmBmI9&algo_pvid=a23d355b-357b-4af5-be9c-f28ea2f32c5d&algo_exp_id=a23d355b-357b-4af5-be9c-f28ea2f32c5d-2&pdp_ext_f=%7B%22sku_id%22%3A%2212000027020913559%22%7D&pdp_npi=2%40dis%21EUR%21%21193.97%21%21%21%21%21%400b0a01f816539164474638472e133e%2112000027020913559%21sea)
Pour en revenir au topic, dernière question je pense pour moi, le forward de "wan6->lan" dans le tuto n'est pas un peu violent ? J'ai l'impression qu'il ouvre l'accès à toutes les machines du lan en IPv6.
Sans ce forward, j'ai toujours mon score de 19/20 sur ipv6-test. Pour ceux qui en ont besoin, ne faudrait-il mieux pas autoriser les IP du lan qui ont effectivement un serveur qui tourne ?
J'adore la customisation/flexibilité d'openwrt, mais ça peut s'installer sur ce boitier X86, j'aurai préféré de l'arm mais à voir ;), merci
Concernant le forward, l'icmpv6 fonctionnera toujours grâce à cette rule :
config rule
option name 'Allow-ICMPv6-Forward'
option dest '*'
option proto 'icmp'
option limit '1000/sec'
option family 'ipv6'
option target 'ACCEPT'
list icmp_type 'bad-header'
list icmp_type 'destination-unreachable'
list icmp_type 'echo-reply'
list icmp_type 'echo-request'
list icmp_type 'packet-too-big'
list icmp_type 'time-exceeded'
list icmp_type 'parameter-problem'
list icmp_type 'unknown-header-type'
option src 'wan6'
Pour le Forward "général", c'est un choix, les deux s'argumentent, Free laisse tout open, mais d'un coté il est très difficile de "deviner" une ipv6 d'une de tes machines, et également il y a encore le firewall de la machine derrière.
Mais passer en drop par defaut n'est pas du tout un mauvais choix.
Le plus important c'est de laisser au moins les flux icmpv6 cités dans la rfc (les différents type de message icmpv6 présents dans la rule), voir la RFC 4890 (Section 4.3.1, 4.3.2) pour plus de détail => https://datatracker.ietf.org/doc/html/rfc4890
-
Sinon je suis en train de chercher un routeur permettant de faire du 2.5G car je vais acheter un Switch CRS305 + le SFP GPON-ONU-34-20BI.
@cetipabo tu m'avais donné quelques modèles il y a quelques temps, tu avais essayé ?
Oula depuis le temps la moitié sont devenus soit introuvables soit morts-nés. il y a peut etre possibilité de trouver des Macchiatobin...
A ce jour en solution apacher, et toujours viable, il n'y a pas grand chose qui me traverse l'esprit...le mieux c'est vraiment le mini-pc type aliexpress.
ou alors a des fins de test, sur une petite tour mettre une carte pcie 4x 2.5G : https://fr.aliexpress.com/item/1005004216189893.html
-
Oula depuis le temps la moitié sont devenus soit introuvables soit morts-nés. il y a peut etre possibilité de trouver des Macchiatobin...
A ce jour en solution apacher, et toujours viable, il n'y a pas grand chose qui me traverse l'esprit...le mieux c'est vraiment le mini-pc type aliexpress.
ou alors a des fins de test, sur une petite tour mettre une carte pcie 4x 2.5G : https://fr.aliexpress.com/item/1005004216189893.html
Ok merci pour le retour, le truc c'était d'avoir une machine qui consomme assez peu (arm), mais en effet je vais m'orienter vers un mini-pc.
-
quelqu'un a parlé du Nanopi R5S
https://www.minimachines.net/actu/nanopi-r5s-109124
https://fr.aliexpress.com/item/1005004297204348.html
https://www.friendlyelec.com/index.php?route=product/product&path=69&product_id=287
un quad core 2.Ghz, avec 2 ports 2.5Gb...après je ne sais pas si la puce Rockchip est vraiment optimisée pour le réseau. les Mhz ca ne fait pas tout.
-
Ok merci pour le retour, le truc c'était d'avoir une machine qui consomme assez peu (arm), mais en effet je vais m'orienter vers un mini-pc.
Le Intel J4125 semble etre assez raisonnable coté conso à en croire ce test (idle 5W, load 10W)
https://www.servethehome.com/inexpensive-4x-2-5gbe-fanless-router-firewall-box-review-intel-j4125-i225-pfsense/
-
sur un peu plus long terme il vaut mieux se diriger vers un cpu plus récent, le N6005 qu'on trouve avec les ports 2.5Gb, il arrivera certainement mieux a gérer un débit a 2.5gb.
https://www.cpubenchmark.net/compare/Intel-Celeron-J4125-vs-Intel-Pentium-Silver-N6005/3667vs4565
https://fr.aliexpress.com/item/1005003990581434.html?
-
Concernant le forward, l'icmpv6 fonctionnera toujours grâce à cette rule :
config rule
option name 'Allow-ICMPv6-Forward'
...
Pour le Forward "général", c'est un choix, les deux s'argumentent, Free laisse tout open, mais d'un coté il est très difficile de "deviner" une ipv6 d'une de tes machines, et également il y a encore le firewall de la machine derrière.
Mais passer en drop par defaut n'est pas du tout un mauvais choix.
Oui cette regle est présente par défaut dans openwrt. Je l'ai laissée. Après pour une personne qui recopie le tuto sans bien comprendre toutes les regles (c'était mon cas il y a 2 ans ;)) je pense que ca serait plus sécurisé de ne pas activer le forward wan6->lan par défaut.
D'ailleurs merci pour le script checknftrules.sh j'avais fait un script similaire avec un cron ce midi :) Tu devrais l'ajouter au tuto ca ne mange pas de pain !
-
Oui cette regle est présente par défaut dans openwrt. Je l'ai laissée. Après pour une personne qui recopie le tuto sans bien comprendre toutes les regles (c'était mon cas il y a 2 ans ;)) je pense que ca serait plus securisé de ne pas activer le forward par défaut.
D'ailleurs merci pour le script checknftrules.sh j'avais fait un script similaire avec un cron. Tu devrais l'ajouter au tuto ca ne mange pas de pain !
De rien ! Je l'avais directement ajouté en "bonus 2".
Pour la règle par defaut, fait attention il manque juste 1 Type par défaut (parameter problem).
Et merci à vous deux pour les liens pour les routeurs, je vais analyser ça ;)
-
@ubune
1 lenovo Tiny M920q ou M720q, dispose d'un slot Pcie x8, et une plaque amovible a l'arriere qui permet d'y insérer une carte réseau pcie x4 avec un riser.
a la base l'emplacement est prévu pour une carte graphique Nvidia Quadro. il y a des modèles vendu avec d'origine.
on arrive a en trouver sur Ebay a 250€ avec un I5 9400T (6 coeurs) dans les bons jours, sinon plutot dans les 350€ après négo.
le riser c'est 23€ sur alie
et la carte pcie x4 2.5Gb sur alie, j'ai déja donné le lien page précédente = 69€
250€ le mini pc sur ebay
15€ frais de port Ebay
23€ le Riser
69€ la carte reseau 4x 2.5Gb
Total : 357€ ou si tu en as marre d'attendre et de rater les bonnes occaz sur Ebay (comme moi >:( ), ce sera 100€ de plus, donc 457€
(https://i.imgur.com/1ueTTsN.png)
(https://i.imgur.com/38ozo0d.png)
(https://i.imgur.com/wLthQTF.png)
Attention les Watts indiqués sur cpubenchmark correspondent au TDP, donc à la chaleur émise par le CPU, rien a voir avec la consommation.
ca parle plutot de 9-12w ou 10-15w, pas bien compris : https://www.servethehome.com/lenovo-thinkcentre-m920-and-m920q-tiny-guide-and-review/3/#:~:text=Idle%20power%20consumption%20on%20120V,for%20the%20quad%2Dcore%20unit.
(https://i.imgur.com/ebjfjfF.png)
-
Le N6005 à l'air d'être le bon compromis ;)
https://fr.aliexpress.com/item/1005004055650546.html
Par contre les délais de livraisons c'est horrible :(
-
certain vendeurs indiquent sur les images, 3-10 days delivery. Pourtant a coté le delais de livraison calculé par Alie est plus élevé, mais je pense que c'est un bug.
(https://i.imgur.com/XERMIy9.png)
dans la description ils disent qu'en choisissant le "Seller's Shipping Method" ca va plus vite qu'avec DHL, car ca par par avion.
(https://i.imgur.com/68Xidtl.png)
ici (https://lafibre.info/routeur/mini-pc-avec-4x-ports-rj45-2-5gbps-intel-i225-v/msg937744/#msg937744) il y a un gars qui l'a recu tres rapidement...
d'autre part, le vendeur dit qu'il y a bien un numéro de suivi, alors qu'alie indique qu'il n'y en a pas :
(https://i.imgur.com/Pi1qxkB.png)
Je pense que c'est Alie qui déconne.
Bon j'arrête de poluer plus le topic ;)
-
Finalement mon choix s'est porté sur celui-ci : https://fr.aliexpress.com/item/1005004302428997.html?spm=a2g0o.order_list.0.0.2d395e5bVbIVLB&gatewayAdapt=glo2fra
Du coup j'aurai :
- Routeur X86 N5105 4x2.5Gbps
- GPON-ONU-34-20BI
- Mikrotik CRS 305 pour accueillir l'onu en 2.5Gbps et gérer la cos 6 (udp 67 et udp 547).
- Mikrotik S+RJ10Gb (pour la liaison cuivre 2.5Gbps Mikro => Routeur X86
J'update une fois receptionné/en place ;)
-
J'update une fois receptionné/en place ;)
J'ai eu du mal à recevoir le Gbic Cuivre, du coup j'ai commandé une marque tiers.
Et hop, ça fonctionne parfaitement (screenshot1), le routeur est supervisé avec le couple prometheus/Grafana (screenshot2).
-
Avec la livebox 6 j'obtenais de manière très stable les 800Mbps d'upload, avec openwrt moyenne toujours > à 700 mais beaucoup de variation entre 500/800.
Après analyse, c'est des pertes suite à la saturation de l'upload, et du coup algo tcp qui fait que ça redescend pour remonter, jusqu'a saturer de nouveau et rechuter etc etc.
J'ai donc déployé le package SQM sur openwrt, uniquement sur les flux sortant (cf screenshot1).
Paramétré à 847000 (je suis monté en valeur, jusqu'a trouver le point ou SQM n'était plus efficace).
Désormais je n'ai plus aucune perte sur un iperf de 60s, le jour et la nuit !
Screenshot 1 = configuration
Screenshot 2 = iperf3 résumé 60s upload.
Screenshot 3 = iperf3 complet de 10sec.
-
du coup avec SQM ta charge cpu passe de combien à combien pour l'upload ?
-
J'ai enormément de mal à voir l'impact cpu, c'est "que" l'upload donc 800Mbps, la en repetant des test pendant l'iperf3
Avec SQM 96% CPU IDLE
Sans SQM 97/98% CPU IDLE
Par contre ta remarque est importante dans le cas ou certains routeurs non x86 ont besoin de l'offloading hardware, qui n'est pas toujours compatible avec SQM.
Edit : Pour le fun j'ai fait des test en download, j'avais toujours environ 2100Mbps après plusieurs speedtest (sans SQM).
J'ai réglé SQM de tel sorte qu'il limite mon débit descendant à 2030Mbps, j'ai mis "2140000" au pif et chaque speedtest était limité à 2030 ensuite.
La je vois clairement l'impact CPU, je consomme 30% ! (IDLE 70% pendant le speedtest).
Et ça marche extremement bien (cf screenshot).
-
30% ca va, vu qu'on DL pas au taquet 24/24h non plus ;D
le truc un peu ennuyeux dans cette histoire c'est de devoir mettre SQM pour stabiliser l'upload, alors que ca devrait etre fait côté driver reseau. il y a peut etre moyen de voir avec la commande ethtool si ca peut pas ce gérer par un petit setting d'offloading a activer ou désactiver...
-
30% ca va, vu qu'on DL pas au taquet 24/24h non plus ;D
le truc un peu ennuyeux dans cette histoire c'est de devoir mettre SQM pour stabiliser l'upload, alors que ca devrait etre fait côté driver reseau. il y a peut etre moyen de voir avec la commande ethtool si ca peut pas ce gérer par un petit setting d'offloading a activer ou désactiver...
30% pour le download, qui n'est pas necessaire du tout, c'est plutôt 1/2% si on reste sur upload uniquement.
ça serait interessant de comparer l'upload livebox vs routeur openwrt chez d'autres personnes, si on constate la même chose que moi.
Concernant ethtool le rx/tx control ça va se jouer sur les limites physiques du port, difficile pour le routeur de "savoir" que la limitation est à 800Mbps en upload.
C'est pour ça que SQM sera toujours imba, tu spécifies toi la limite et il s'adapte.
J'en profite au passage, mais ça me permet d'avoir presque aucun impact de latence sur un ping.
En gros si je fais un ping 8.8.8.8 à 6ms hors speedtest, il monte facilement a 50-80ms pendant speedtest (upload) sans SQM, là ça presque change rien, les petits paquets passent encore.
Surement au détriment de 1/2Mbps qu'il garde en reserve et qui sont négligeable vue nos débits.
-
Concernant ethtool le rx/tx control ça va se jouer sur les limites physiques du port, difficile pour le routeur de "savoir" que la limitation est à 800Mbps en upload.
oui, mais pas que. tu peux aussi définir la taille de la mémoire tampon de l'offloading. peut etre qu'en le réduisant ou l'augmentant ca peut avoir un impact.
De mon coté j'ai meme requarqué que sur une de mes cartes (mais realtek) l'offloading n'était pas activé par défaut. j'ai pu l'activer avec ethtool.
en fait, a quoi ressemble ta courbe d'upload avec nperf ? ca fait des montagnes russes j'imagine non ? (tampon qui se rempli, qui se vide,...). si c'est ca j'ai eu un souci similaire.
quand j'ai comparé les reglages par défaut de la realtek par rapport a la intel :
on voit pas mal de réglages sur "off" sur ma realtek, à gauche.
(https://forum.openwrt.org/uploads/default/original/3X/f/0/f039055739f9a75739cc4119c740908a21771c0f.png)
j'ai pu les passer sur "ON" avec la commande :
ethtool -K eth1 sg onBon après ça peut n'avoir aucun impact, mais ca coute rien de vérifier :)
-
Ok je vois, merci pour les infos !
je vérifie ça dans l'aprem et je ferai d'autres tests sans sqm et après changement des paramètres (si ils sont absents) ;).
-
Merci pour ce retour.
@ubune :
- As-tu un wattmètre pour mesurer la conso électrique du routeur N5105 idle/en charge ?
- Est-ce que tu as bien 2 slot de SODIMM à l'intérieur ?
- A quoi sert le port COM ? (carte réseau ou port série ?)
- As-tu eu des mauvaises surprises avec la machine ?
Merci.
-
- A quoi sert le port COM ? (carte réseau ou port série ?)
ca remplace l'interface clavier/ecran. on fait une connection direct avec son PC sur ce port et on peut voir/agir dans putty (par exemple) depuis son PC comme si on était connecté en SSH au routeur.
-
Merci pour ce retour.
@ubune :
- As-tu un wattmètre pour mesurer la conso électrique du routeur N5105 idle/en charge ?
Non, j'ai mis le processeur sans turbo-boost par contre (reglage bios).
- Est-ce que tu as bien 2 slot de SODIMM à l'intérieur ?
Oui, j'ai ajouté 2x4go DDR4 2666Mhz (25euros) et un SSD Nvme 256Go (Docker soon) 25 euros
- A quoi sert le port COM ? (carte réseau ou port série ?)
Repondu par Cetipabo
- As-tu eu des mauvaises surprises avec la machine ?
J'en suis super content, en revanche attention c'est du passif, le boitier est extremement brulant, mais je n'ai pas l'impression qu'il trottle du tout vue les perf
Merci.
J'ai trouvé ça :
root@openwrt-N5105:~# find /* -name *temp
/bin/mktemp
/sys/devices/virtual/thermal/thermal_zone0/trip_point_5_temp
/sys/devices/virtual/thermal/thermal_zone0/trip_point_4_temp
/sys/devices/virtual/thermal/thermal_zone0/trip_point_3_temp
/sys/devices/virtual/thermal/thermal_zone0/trip_point_2_temp
/sys/devices/virtual/thermal/thermal_zone0/trip_point_1_temp
/sys/devices/virtual/thermal/thermal_zone0/temp
/sys/devices/virtual/thermal/thermal_zone0/trip_point_0_temp
/sys/devices/virtual/thermal/thermal_zone1/trip_point_1_temp
/sys/devices/virtual/thermal/thermal_zone1/temp
/sys/devices/virtual/thermal/thermal_zone1/trip_point_0_temp
/sys/bus/platform/drivers/coretemp
/sys/bus/pci/drivers/k10temp
/sys/bus/pci/drivers/k8temp
/sys/bus/pci/drivers/i5500_temp
/sys/module/coretemp
/sys/module/k10temp
/sys/module/k10temp/drivers/pci:k10temp
Un cat de ces deux valeurs donne ça :
root@openwrt-N5105:~# cat /sys/devices/virtual/thermal/thermal_zone0/temp
27800
root@openwrt-N5105:~# cat /sys/devices/virtual/thermal/thermal_zone1/temp
65000
Quelqu'un peut me confirmer ce que ça signifie ? Je suppose 65° cpu ?
Edit : je m'autorépond, mais c'était bien ça ;) :
root@openwrt-N5105:~# cat /sys/class/thermal/thermal_zone*/type
acpitz
x86_pkg_temp
-
oui, mais pas que. tu peux aussi définir la taille de la mémoire tampon de l'offloading. peut etre qu'en le réduisant ou l'augmentant ca peut avoir un impact.
De mon coté j'ai meme requarqué que sur une de mes cartes (mais realtek) l'offloading n'était pas activé par défaut. j'ai pu l'activer avec ethtool.
en fait, a quoi ressemble ta courbe d'upload avec nperf ? ca fait des montagnes russes j'imagine non ? (tampon qui se rempli, qui se vide,...). si c'est ca j'ai eu un souci similaire.
quand j'ai comparé les reglages par défaut de la realtek par rapport a la intel :
on voit pas mal de réglages sur "off" sur ma realtek, à gauche.
(https://forum.openwrt.org/uploads/default/original/3X/f/0/f039055739f9a75739cc4119c740908a21771c0f.png)
j'ai pu les passer sur "ON" avec la commande :
ethtool -K eth1 sg onBon après ça peut n'avoir aucun impact, mais ca coute rien de vérifier :)
Quelques feature off
root@openwrt-N5105:~# ethtool -k eth0
Features for eth0:
rx-checksumming: on
tx-checksumming: on
tx-checksum-ipv4: off [fixed]
tx-checksum-ip-generic: on
tx-checksum-ipv6: off [fixed]
tx-checksum-fcoe-crc: off [fixed]
tx-checksum-sctp: on
scatter-gather: on
tx-scatter-gather: on
tx-scatter-gather-fraglist: off [fixed]
tcp-segmentation-offload: on
tx-tcp-segmentation: on
tx-tcp-ecn-segmentation: on
tx-tcp-mangleid-segmentation: off
tx-tcp6-segmentation: on
generic-segmentation-offload: on
generic-receive-offload: on
large-receive-offload: off [fixed]
rx-vlan-offload: off [fixed]
tx-vlan-offload: off [fixed]
ntuple-filters: off
receive-hashing: off [fixed]
highdma: on [fixed]
rx-vlan-filter: off [fixed]
vlan-challenged: off [fixed]
tx-lockless: off [fixed]
netns-local: off [fixed]
tx-gso-robust: off [fixed]
tx-fcoe-segmentation: off [fixed]
tx-gre-segmentation: on
tx-gre-csum-segmentation: on
tx-ipxip4-segmentation: on
tx-ipxip6-segmentation: on
tx-udp_tnl-segmentation: on
tx-udp_tnl-csum-segmentation: on
tx-gso-partial: on
tx-tunnel-remcsum-segmentation: off [fixed]
tx-sctp-segmentation: off [fixed]
tx-esp-segmentation: off [fixed]
tx-udp-segmentation: off [fixed]
tx-gso-list: off [fixed]
fcoe-mtu: off [fixed]
tx-nocache-copy: off
loopback: off [fixed]
rx-fcs: off [fixed]
rx-all: off [fixed]
tx-vlan-stag-hw-insert: off [fixed]
rx-vlan-stag-hw-parse: off [fixed]
rx-vlan-stag-filter: off [fixed]
l2-fwd-offload: off [fixed]
hw-tc-offload: on
esp-hw-offload: off [fixed]
esp-tx-csum-hw-offload: off [fixed]
rx-udp_tunnel-port-offload: off [fixed]
tls-hw-tx-offload: off [fixed]
tls-hw-rx-offload: off [fixed]
rx-gro-hw: off [fixed]
tls-hw-record: off [fixed]
rx-gro-list: off
macsec-hw-offload: off [fixed]
-
Pour la température, je me suis amusé à stresser le cpu à 100%
stress -c 4root@openwrt-N5105:~# cat /sys/class/thermal/thermal_zone*/type
acpitz
x86_pkg_temproot@openwrt-N5105:~# cat /sys/class/thermal/thermal_zone*/temp
27800
74000Je passe de 65 à 74°, pourtant il fait encore relativement chaud dans mon garage (27°).
Le TJ-Max du cpu est à 105°, y'a encore de la marge ;)
Bonus : speedtest realisé avec le cpu à 100% (le réseau c'est prio :P)
-
Bonjour ma connexion est de 1000dl /1000up
lors d'un test sans routeur OpenWrt
J'obtiens A+A+A+
lors de la configuration de sqm a des valeurs qu'il peut prendre en charge j'obtiens A voir B dans bufferbloat,
ma question concerne la hiérarchisation si je n'ai pas de bufferbloat, puis mettez des valeurs vides et ne laissez que la hiérarchisation?
.
J'ai tout crée la hiérarchisation depuis traffic rules mais est elle vraiment fiable
CS1 CS2 etc merci
-
Bonjour ma connexion est de 1000dl /1000up
lors d'un test sans routeur OpenWrt
J'obtiens A+A+A+
lors de la configuration de sqm a des valeurs qu'il peut prendre en charge j'obtiens A voir B dans bufferbloat,
ma question concerne la hiérarchisation si je n'ai pas de bufferbloat, puis mettez des valeurs vides et ne laissez que la hiérarchisation?
.
J'ai tout crée la hiérarchisation depuis traffic rules mais est elle vraiment fiable
CS1 CS2 etc merci
Salut,
Perso configuration extrêmement simple :
Interface : eth0.832
Upload speed : 846000 => Offre Orange avec upload à 800Mbps.
Queuing disciplines : cake
Queue setup script : piece of cake
Et c'est du A+ partout.
En gros c'est simplement eviter une saturation complète de l'upload pour laisser passer les "petits" paquets.
-
Merci pour ce retour.
@ubune :
- As-tu un wattmètre pour mesurer la conso électrique du routeur N5105 idle/en charge ?
- Est-ce que tu as bien 2 slot de SODIMM à l'intérieur ?
- A quoi sert le port COM ? (carte réseau ou port série ?)
- As-tu eu des mauvaises surprises avec la machine ?
Merci.
Voyant le peu d'utilisation de ressource d'openwrt (même en routage 2.5Gbps)
J'ai installé Esxi sur cette petite machine, et ça tourne merveilleusement bien.
Il faut juste se créer un iso esxi avec les drivers i225v (pour les 4 ports 2.5gbps).
Du coup j'ai déployé une VM openwrt avec 2vcpu et 1Go de ram, ça suffit largement même avec SQM actif.
Avec le reste des ressources, j'ai 2 vm, un debian@jeedom et un ubuntu-server@docker ;)
-
Bonjour
Déjà, je tiens à remercier cette communauté pour tout ce qu'elle fait : Tutoriels, aide, infos diverses...
Mon EdgeRouter POE 5 m'ayant lâché, j'ai ressorti ma livebox 3.
J'ai ressorti aussi mon ancien routeur, un Netgear WNDR3800 v1, sur lequel j'ai installé OpenWRT 22.03-rc5 dans le but de remplacer ma livebox
J'ai suivi le tuto de la 1ere page. J'arrive à me connecter au réseau Orange.
En revanche, quand je fais un speedtest, j'obtiens environ 800Mbits/s en download mais seulement 4MBits/s en upload.
Sur la livebox, je suis à 400MBit/s en upload (et >900MBits en download).
Comment peut-on expliquer cette différence ?
Je suppose qu'une partie de la réponse est dû au Netgear qui n'est pas tout récent et peut-être pas assez perfomant.
Question Annexe : Je souhaite acheter un nouveau routeur qui tienne le 1Gbit/s (voire le 2Gbits/s pour prévoir un peu le futur) et si possible sous OpenWRT, que me conseillez-vous ?
La solution "mini PC" type N5105 ont l'air pas mal malgré le prix.
Merci d'avance pour votre aide.
-
Salut,
Flash une version stable plutot qu'une RC, et dit nous ce qu'il en est.
-
Bonjour,
Je suis passée sur la version officielle OpenWrt 21.02.3 r16554.
Le débit en Upload est toujours autour de 4/5Mbits/s.
-
Bonjour,
Je suis passée sur la version officielle OpenWrt 21.02.3 r16554.
Le débit en Upload est toujours autour de 4/5Mbits/s.
Saluts Akeix,
Ton traffic internet sort bien en priorité 0 ?
tu peux le voir avec la commande suivante :
Si ton wan est eth0.832, il faut taper la commande suivante :
tcpdump -nei "eth0" port 53
J'ai mis port 53 pour voir que le flux dns c'est suffisant pour checker.
Si ok tu devrais voir "p 0" dans les échanges.
Ton port est bien négocié en 1gbps full ?
pour check
ethtool eth0
As-tu des erreurs sur l'interface ?
ethtool -S eth0Si t'as pas les packages,
opkg update && opkg install tcpdump ethtool
-
Bonjour,
Perso mon wan est sur le port eth1.832
(https://openwrt.org/_media/media/netgear/wndr3700/wndr3700-c.png)
J'ai essayé des différentes commandes.
- tcpdump -nei "eth1" port 53 : j'ai bien le "p 0"
- ethtool eth1 : je suis bien en 1000MB/s, Full, MII
- ethtool -S eth1 : je n'ai aucune erreur
-
T'as quoi comme parametre, offload/Packet Steering ?
Peux-tu faire :
Test upload monosession ipv4 :
iperf3 -c bouygues.iperf.fr -p 9201 -P 1 -4
Test upload monosession ipv6 :
iperf3 -c bouygues.iperf.fr -p 9201 -P 1 -6
Depuis le routeur dans un premier temps puis depuis une machine ?
opkg update && opkg install iperf3
-
Bonjour,
Voici les résultats :
iperf3 -c bouygues.iperf.fr -p 9201 -P 1 -4
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 615 KBytes 5.04 Mbits/sec 0 54.4 KBytes
[ 5] 1.00-2.00 sec 660 KBytes 5.40 Mbits/sec 0 82.3 KBytes
[ 5] 2.00-3.00 sec 522 KBytes 4.27 Mbits/sec 0 110 KBytes
[ 5] 3.00-4.00 sec 628 KBytes 5.14 Mbits/sec 0 139 KBytes
[ 5] 4.00-5.00 sec 565 KBytes 4.63 Mbits/sec 0 167 KBytes
[ 5] 5.00-6.00 sec 628 KBytes 5.14 Mbits/sec 0 195 KBytes
[ 5] 6.00-7.00 sec 753 KBytes 6.17 Mbits/sec 0 223 KBytes
[ 5] 7.00-8.00 sec 565 KBytes 4.63 Mbits/sec 0 266 KBytes
[ 5] 8.00-9.00 sec 628 KBytes 5.14 Mbits/sec 0 356 KBytes
[ 5] 9.00-10.00 sec 329 KBytes 2.70 Mbits/sec 20 372 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 5.75 MBytes 4.83 Mbits/sec 20 sender
[ 5] 0.00-10.55 sec 5.44 MBytes 4.32 Mbits/sec receiver
iperf3 -c bouygues.iperf.fr -p 9201 -P 1 -6
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 615 KBytes 5.04 Mbits/sec 0 54.4 KBytes
[ 5] 1.00-2.00 sec 658 KBytes 5.39 Mbits/sec 0 83.7 KBytes
[ 5] 2.00-3.00 sec 519 KBytes 4.25 Mbits/sec 0 112 KBytes
[ 5] 3.00-4.00 sec 628 KBytes 5.14 Mbits/sec 0 139 KBytes
[ 5] 4.00-5.00 sec 753 KBytes 6.17 Mbits/sec 0 167 KBytes
[ 5] 5.00-6.00 sec 439 KBytes 3.60 Mbits/sec 0 197 KBytes
[ 5] 6.00-7.00 sec 753 KBytes 6.17 Mbits/sec 0 225 KBytes
[ 5] 7.00-8.00 sec 565 KBytes 4.63 Mbits/sec 0 266 KBytes
[ 5] 8.00-9.00 sec 628 KBytes 5.14 Mbits/sec 0 356 KBytes
[ 5] 9.00-10.00 sec 331 KBytes 2.71 Mbits/sec 21 363 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 5.75 MBytes 4.82 Mbits/sec 21 sender
[ 5] 0.00-10.54 sec 5.44 MBytes 4.34 Mbits/sec receiver
Les résultats sont similaires au speedtest fait depuis mon PC.
-
Les deux tests envoyés sont les mêmes.
Tu confirmes que tu as le même pb en ipv4 et en ipv6 ?
-
J'ai eu un doute donc je viens de refaire la commande "iperf3 -c bouygues.iperf.fr -p 9201 -P 1 -6" et j'ai modifié mon message.
Mais j'ai le même problème en ipv4 et ipv6.
J'ai peut-être trouvé une piste en regardant "le system log" :
Sat Jul 16 07:20:46 2022 daemon.notice procd: /etc/rc.d/S95done: /etc/rc.local: line 9: nft: not found
Sat Jul 16 07:20:46 2022 daemon.notice procd: /etc/rc.d/S95done: /etc/rc.local: line 10: nft: not found
Sat Jul 16 07:20:46 2022 daemon.notice procd: /etc/rc.d/S95done: /etc/rc.local: line 11: nft: not found
Sat Jul 16 07:20:46 2022 daemon.notice procd: /etc/rc.d/S95done: /etc/rc.local: line 12: nft: not found
Sat Jul 16 07:20:46 2022 daemon.notice procd: /etc/rc.d/S95done: /etc/rc.local: line 13: nft: not found
Sat Jul 16 07:20:46 2022 daemon.notice procd: /etc/rc.d/S95done: /etc/rc.local: line 14: nft: not found
Sat Jul 16 07:20:47 2022 daemon.info procd: - init complete -
La commande "nft" n'est pas présente dans mon OpenWRT.
J'ai donc installé "nft" via la commande :
opkg install nftables"
Maintenant dans le system log, j'ai des erreurs :
Sat Jul 16 07:20:49 2022 daemon.notice procd: /etc/rc.d/S95done: Error: Could not process rule: No such file or directory
Sat Jul 16 07:20:49 2022 daemon.notice procd: /etc/rc.d/S95done: add rule inet fw4 mangle_postrouting oifname eth1.832 counter meta priority set 0:1
Sat Jul 16 07:20:49 2022 daemon.notice procd: /etc/rc.d/S95done: ^^^
Sat Jul 16 07:20:49 2022 daemon.notice procd: /etc/rc.d/S95done: Error: Could not process rule: No such file or directory
Sat Jul 16 07:20:49 2022 daemon.notice procd: /etc/rc.d/S95done: add rule inet fw4 mangle_postrouting oifname eth1.832 ip protocol icmp counter meta priority set 0:6
Sat Jul 16 07:20:49 2022 daemon.notice procd: /etc/rc.d/S95done: ^^^
Sat Jul 16 07:20:49 2022 daemon.notice procd: /etc/rc.d/S95done: Error: Could not process rule: No such file or directory
Sat Jul 16 07:20:49 2022 daemon.notice procd: /etc/rc.d/S95done: add rule inet fw4 mangle_postrouting oifname eth1.832 ip protocol igmp counter meta priority set 0:6
Sat Jul 16 07:20:49 2022 daemon.notice procd: /etc/rc.d/S95done: ^^^
Sat Jul 16 07:20:49 2022 daemon.notice procd: /etc/rc.d/S95done: Error: Could not process rule: No such file or directory
Sat Jul 16 07:20:49 2022 daemon.notice procd: /etc/rc.d/S95done: add rule inet fw4 mangle_postrouting oifname eth1.832 udp dport 67 counter meta priority set 0:6
Sat Jul 16 07:20:49 2022 daemon.notice procd: /etc/rc.d/S95done: ^^^
Sat Jul 16 07:20:49 2022 daemon.notice procd: /etc/rc.d/S95done: Error: Could not process rule: No such file or directory
Sat Jul 16 07:20:49 2022 daemon.notice procd: /etc/rc.d/S95done: add rule inet fw4 mangle_postrouting oifname eth1.832 udp dport 547 counter meta priority set 0:6
Sat Jul 16 07:20:49 2022 daemon.notice procd: /etc/rc.d/S95done: ^^^
Sat Jul 16 07:20:49 2022 daemon.notice procd: /etc/rc.d/S95done: Error: Could not process rule: No such file or directory
Sat Jul 16 07:20:49 2022 daemon.notice procd: /etc/rc.d/S95done: add rule inet fw4 mangle_postrouting oifname eth1.832 ip protocol icmpv6 counter meta priority set 0:6
Sat Jul 16 07:20:49 2022 daemon.notice procd: /etc/rc.d/S95done: ^^^
Le copier/coller su "system log" ne rend pas pareil que la capture en image ci-dessous :
-
En 21.02.3 tu es sous firewall3, tu fonctionnes sous iptables et non nftable. Donc pour toi c'est la config avec iptables qui doit être appliquée.
C'est à partir du Snapshot ou 22.03.x que tu passes sous Firewall4, avec nftable.
-
Bon, j'ai fait un reset du WNDR3800.
iperf3 -c bouygues.iperf.fr -p 9201 -P 1 -4 #Sans offloading hard
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 19.8 MBytes 166 Mbits/sec 1 414 KBytes
[ 5] 1.00-2.01 sec 22.6 MBytes 188 Mbits/sec 0 430 KBytes
[ 5] 2.01-3.05 sec 21.5 MBytes 173 Mbits/sec 0 436 KBytes
[ 5] 3.05-4.01 sec 21.6 MBytes 188 Mbits/sec 2 452 KBytes
[ 5] 4.01-5.00 sec 22.8 MBytes 193 Mbits/sec 0 464 KBytes
[ 5] 5.00-6.01 sec 22.0 MBytes 182 Mbits/sec 0 475 KBytes
[ 5] 6.01-7.00 sec 23.4 MBytes 198 Mbits/sec 0 488 KBytes
[ 5] 7.00-8.00 sec 22.6 MBytes 190 Mbits/sec 2 383 KBytes
[ 5] 8.00-9.00 sec 23.2 MBytes 195 Mbits/sec 0 431 KBytes
[ 5] 9.00-10.00 sec 23.5 MBytes 197 Mbits/sec 0 464 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 223 MBytes 187 Mbits/sec 5 sender
[ 5] 0.00-10.02 sec 223 MBytes 187 Mbits/sec receiver
iperf3 -c bouygues.iperf.fr -p 9201 -P 1 -6 #Sans offloading hard
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.03 sec 23.4 MBytes 190 Mbits/sec 1 283 KBytes
[ 5] 1.03-2.02 sec 30.0 MBytes 255 Mbits/sec 0 337 KBytes
[ 5] 2.02-3.02 sec 31.2 MBytes 263 Mbits/sec 0 358 KBytes
[ 5] 3.02-4.00 sec 32.7 MBytes 278 Mbits/sec 0 396 KBytes
[ 5] 4.00-5.00 sec 33.9 MBytes 284 Mbits/sec 0 442 KBytes
[ 5] 5.00-6.00 sec 33.6 MBytes 282 Mbits/sec 0 471 KBytes
[ 5] 6.00-7.00 sec 33.2 MBytes 279 Mbits/sec 0 489 KBytes
[ 5] 7.00-8.00 sec 33.1 MBytes 278 Mbits/sec 0 506 KBytes
[ 5] 8.00-9.00 sec 33.3 MBytes 279 Mbits/sec 0 584 KBytes
[ 5] 9.00-10.00 sec 34.5 MBytes 290 Mbits/sec 0 720 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 319 MBytes 267 Mbits/sec 1 sender
[ 5] 0.00-10.01 sec 319 MBytes 267 Mbits/sec receiver
Avec l'offloading hard, j'obtiens les mêmes résultats. Donc, c'est beaucoup mieux qu'avant. Il manque toujours 100Mbits/s par rapport à la livebox qui est à 400Mbits/s. Mais le résultat est déjà bien.
Du coup, j'ai fait un speedtest.
- Pour l'upload, je retrouve bien les résultats de iperf3
- En revanche, le débit download a été divisé par 2, je suis maintenant à 362MBits/s (avec ou sans offloading hard). Avant, j'étais vers 800MBits/s avec offloading hard activé
-
l'offloading Hard ne fonctionne que sur les SOC Mediatek (MT7621/MT7622), ce n'est pas le cas de ton WNDR3800 (https://deviwiki.com/wiki/Netgear_WNDR3800) qui dispose d'un Atheros AR7161, mono core a 680Mhz...je ne vois pas comment on peut atteindre 1Gbps NAT sous openwrt avec ça :o :o étant donné que l'accélération matérielle, s'il y en a une, n'est possible qu'avec le firmware d'origine.
Il n'y a que l'offloading software qui peut permettre une petite amélioration.
Installe HTOP, et regarde son graphique lorsque tu fais ton speedtest, si l'utilisation du CPU monte a 100%, c'est que tu es au max de ses possibilités.
Tu as vu mon post au dessus concernant Firewall3 et 4 ? sur quelle version d'openwrt es-tu maintenant du coup ?
-
Quand tu me l'a dis, j'ai fait un reset du wndr3800 et je suis donc reparti sur la config avec iptable et firewall 3.
En revanche, lors de mes essais avec la future version 22 (rc5), sans offload hard, j'avais environ 300-400 Mbits/s. En activant le offload hard, j'étais à 800 Mbits/s en download
-
En revanche, lors de mes essais avec la future version 22 (rc5), sans offload hard, j'avais environ 300-400 Mbits/s. En activant le offload hard, j'étais à 800 Mbits/s en download
sans offload Hard c'est avec ou sans offload software ?
a mon avis c'est le seul "truc" qui joue dans l'histoire, pour activer le Hard tu dois activer le soft. Et comme le hard il n'y en a pas, c'est que le Soft qui marche.
Donc au final tu es sans offload ou avec offload software.
Avec offload soft ou avec offload soft+hard = c'est la même chose pour ton routeur.
-
sans offload Hard c'est avec ou sans offload software ?
a mon avis c'est le seul "truc" qui joue dans l'histoire, pour activer le Hard tu dois activer le soft. Et comme le hard il n'y en a pas, c'est que le Soft qui marche.
Donc au final tu es sans offload ou avec offload software.
Avec offload soft ou avec offload soft+hard = c'est la même chose pour ton routeur.
sans offload Hard c'était sans offload software.
En ce moment, je ne suis pas chez moi pour tester. Donc je verrai à mon retour l'histoire du HTOP.
Sinon, avez-vous un routeur à me conseiller qui tienne le 1Gbits/s (voire les 2GBits/s pour prévoir un peu le futur) en restant sur du cuivre ?
Les solutions à base de mini PC ont l'air pas mal.
-
Sinon, avez-vous un routeur à me conseiller qui tienne le 1Gbits/s (voire les 2GBits/s pour prévoir un peu le futur) en restant sur du cuivre ?
Les solutions à base de mini PC ont l'air pas mal.
ben celui qu'a pris ubune, il a posté le lien Aliexpress.
https://lafibre.info/remplacer-livebox/remplacement-de-la-livebox-par-un-routeur-openwrt-18-dhcp-v4v6-tv/msg955412/#msg955412
-
Bonjour,
Tout d'abord merci pour ce topic/tutoriel et les échanges que j'ai pu y trouver !
Je viens juste de m'inscrire et j'aimerai vous faire un petit retour d’expérience autour du remplacement de ma livebox5 avec mon forfait Sosh 300Mbits
Avant l'installation de la fibre, j'avais donc lu en long et en large ce topic pour savoir comment anticiper. Le technicien est venu m'installer la fibre, Il a été très professionnel, je lui ai demandé un GPON et il me l'a donné sans problème, un GPON Huawei Orange.
La livebox 5 fonctionne, le technicien repart, J'ai un débit plutôt correct 250Mbits DL, 280 en UP, 6ms de ping.
Comme une livebox elle chauffe, toujours pas possible de changer les DNS, DHCP moisi, bref je veux la remplacer.
J'avais trouve un Ubiquity Edge Router 3 Lite pas cher pendant le confinement, et je l'avais mis de cote en attendant la fibre. J'installe donc OpenWRT dessus, la 21 officiel ne boot pas, je pars sur une 22 RC4 qui fonctionne.
J'applique le tutoriel, je passe un coup de chat sur le support SOSH pour demander l'enregistrement du GPON, A ma grande surprise la personne sait de quoi je parle. Bravo SOSH, j’ai été très agréablement surpris. GPON active immédiatement je perds la connexion avant d'avoir pu remercier le support.
Je branche mon EDGE et ça marche directement. J'ai mon IPv4 et v6.
Sauf test des débits 80 en DL et UP ping 15ms.
Je trifouille un peu OPENWRT, j'active le packet steering pour utiliser les 2cores du ERL-3, je double mes debits 160 UP et DL. Je teste l'offload soft et hardware, c'est la cata, bon c'est marque expérimental, j'insiste pas trop, c'est une implémentation propriétaire.
Je vérifie mes QOS, elles sont OK, tout va bien de ce cote. Je relis le tutoriel et les pages du topic. RIEN. Bon je fini par me dire que le ER3-LITE ne peut pas faire mieux et que c'est déjà pas mal ..
Je pars de loin j'avais 4Mbits en ADSL a 5Km du DSLAM, je suis déjà aux anges.
Hier je reprend la lecture des 50 pages, et je commence a fouiller sur le net pour d'autre config et des retours sur ERL-3 lite en tant que routeur.
Je tombe la dessus https://forum.openwrt.org/t/performance-edgerouter-lite-3-is-this-really-all-it-can-do/830
900Mbits avec le stock firmware .. j'ai de la marge ..
Je relis la page 1 et j'essaye de comprendre la config en détail.
Dans le doute, je vire la conf IPv6, toujours pareil,
Je vire le bridge LAN, ça remonte un peu a 200Mbits,
Je vire la QOS et la je remonte a 230Mbits, j'active le software offloading --> 300Mbits/300Mbits/4ms.
Du coup on voit bien que la gestion de la QOS n'est pas nécessaire dans mon cas et met a genou le ERL3 Lite.
Quelqu'un aurait une explication qui justifie l'utilisation de la QOS a 300Mbits sur des petits routeurs ??
Merci
e.
-
l'offloading Hard ne fonctionne que sur les SOC Mediatek (MT7621/MT7622), ce n'est pas le cas de ton WNDR3800 (https://deviwiki.com/wiki/Netgear_WNDR3800) qui dispose d'un Atheros AR7161, mono core a 680Mhz...je ne vois pas comment on peut atteindre 1Gbps NAT sous openwrt avec ça :o :o étant donné que l'accélération matérielle, s'il y en a une, n'est possible qu'avec le firmware d'origine.
Il n'y a que l'offloading software qui peut permettre une petite amélioration.
Installe HTOP, et regarde son graphique lorsque tu fais ton speedtest, si l'utilisation du CPU monte a 100%, c'est que tu es au max de ses possibilités.
Tu as vu mon post au dessus concernant Firewall3 et 4 ? sur quelle version d'openwrt es-tu maintenant du coup ?
Bonjour,
je suis rapidement passer chez moi.
J'ai testé l'histoire de HTOP. Et effectivement, pendant un speedtest, le CPU est à 100%.
Voilà mes mesures (MBits/s) :
| Offload | Download | Upload |
| Sans | 383 | 193 |
| Soft | 365 | 247 |
| Hard | 360 | 231 |
Avec le "offload soft", je gagne sur l'upload mais je perds sur le download.
Ce qui est dingue, c'est qu'avec OpenWRT 22.03-rc5, avec offload hard, j'avais 800Mbits/s sur le speedtest.
Je ferais de nouveau un test avec cette version à mon retour.
Pour le moment, ma livebox va rester en place.
Pour la suite, je pense que je vais partir sur le mini-Pc proposé par Ubune.
Le seul inconvénient, c'est que cela chauffe pas mal.
Encore merci pour votre aide.
-
Bonjour,
J'avais trouve un Ubiquity Edge Router 3 Lite pas cher pendant le confinement, et je l'avais mis de cote en attendant la fibre. J'installe donc OpenWRT dessus, la 21 officiel ne boot pas, je pars sur une 22 RC4 qui fonctionne.
Bonjour prysme,
Le routeur EdgeRouter 3 Lite (ou l'EdegRouter 5 POE que j'avais) permet d'obtenir le 1GBits/s sur la fibre Orange en gardant le firmware d'Ubiquity.
Du coup et par curiosité, pourquoi as-tu voulu mettre OpenWRT dessus ?
-
Du coup et par curiosité, pourquoi as-tu voulu mettre OpenWRT dessus ?
A vrai dire, je ne me suis pas pose la question, un ami avait un ERL X et m'avait recommande openwrt donc plutôt par principe de mettre un logiciel libre et par recommandation, et surtout sans me douter que j'aurai autant de mal a obtenir 300Mbits
-
Hier je reprend la lecture des 50 pages, et je commence a fouiller sur le net pour d'autre config et des retours sur ERL-3 lite en tant que routeur.
Je tombe la dessus https://forum.openwrt.org/t/performance-edgerouter-lite-3-is-this-really-all-it-can-do/830
900Mbits avec le stock firmware .. j'ai de la marge ..
Je relis la page 1 et j'essaye de comprendre la config en détail.
Dans le doute, je vire la conf IPv6, toujours pareil,
Je vire le bridge LAN, ça remonte un peu a 200Mbits,
Je vire la QOS et la je remonte a 230Mbits, j'active le software offloading --> 300Mbits/300Mbits/4ms.
Du coup on voit bien que la gestion de la QOS n'est pas nécessaire dans mon cas et met a genou le ERL3 Lite.
Quelqu'un aurait une explication qui justifie l'utilisation de la QOS a 300Mbits sur des petits routeurs ??
Mon experience avec un ERL et un ER4 d'Ubiquiti :
La QoS en upload aide à eliminer le bufferbloat (https://www.bufferbloat.net/projects/bloat/wiki/What_can_I_do_about_Bufferbloat/ (https://www.bufferbloat.net/projects/bloat/wiki/What_can_I_do_about_Bufferbloat/)), ce qui est très utile quand on a plusieurs personnes à faire des réunions Teams en télétravail tout le temps, au même temps que l'on fait des downloads. C'est mon cas mais c'est un cas très particulier.
Ça vaut la peine que tu fasses un test avec offloading activé ET la QoS, et sans QoS.
-
Hello,
Je tente de remplacer ma Livebox 5 (SOSH) par un router OpenWRT + TP-Link MC220L + ONT fourni avec mon ancienne Livebox 4.
Je fais la procédure en première page (avec les valeurs des options DHCP générées par l'outil, ou récupérées par LiveboxInfo), mais c'est comme s'il n'y avait rien qui arrivait sur la partie WAN
La seule chose que j'obtiens via un tcpdump c'est
17:18:49.305461 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 28:87:ba:a1:07:7c (oui Unknown), length 387
J'ai demandé à SOSH de m'activer mon ONT mais ça ne change rien, le MC220L a bien ses deux LED d'allumées (liaison gbic + gigabit vers le router)
Est-ce que vous auriez une idée ?
Merci :)
-
Hello,
J'ai déjà remarqué que chez orange, s'il n'y a pas de réponse au dhcp, on ne reçoit rien et c'est tout à fait normal: pas d'IP = rien pour recevoir quoi que ce soit.
C'est un peu tout le contraire de chez Free ou même s'il n'y a pas d'Ip, comme on est en IP fixe on reçoit toute la pourriture d'internet direct....
Bon, faut faire un tcpdump avec -vvv et -xxx histoire de voire pourquoi la requête dhcp n'est pas comprise par le serveur (genre il manque une option ou son format n'est pas bon).
-
Hello,
Je tente de remplacer ma Livebox 5 (SOSH) par un router OpenWRT + TP-Link MC220L + ONT fourni avec mon ancienne Livebox 4.
Je fais la procédure en première page (avec les valeurs des options DHCP générées par l'outil, ou récupérées par LiveboxInfo), mais c'est comme s'il n'y avait rien qui arrivait sur la partie WAN
La seule chose que j'obtiens via un tcpdump c'est
17:18:49.305461 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 28:87:ba:a1:07:7c (oui Unknown), length 387
J'ai demandé à SOSH de m'activer mon ONT mais ça ne change rien, le MC220L a bien ses deux LED d'allumées (liaison gbic + gigabit vers le router)
Est-ce que vous auriez une idée ?
Merci :)
Salut,
On est d'accord que du coup, l'ont de ta livebox 4 est toujours enregistré chez Orange ?
Ensuite pour la trace sur openwrt , fait plutôt un
tcpdump -nei eth0 port 67 or port 68
Remplace eth0 par le nom de ton interface wan si ce n'est pas celle-ci, attention eth0 et pas eth0.832.
Et si tu veux faire une capture complète
tcpdump -nei eth0 -w sniff.pcapTu attends une dizaine de seconde puis ctrl-c
Ensuite depuis ton pc (cmd ou powershell) :
scp root@iplandurouteur:/root/sniff.pcap .\Desktop\
Et tu devrais avoir la trace prête à être analysée (wireshark) sur ton bureau ;).
Tu peux me l'envoyer si tu veux.
A+
-
En effet je n'ai pas pensé à activer tcpdump en plus verbeux, je suis revenu sur la Livebox v4 pour retrouver internet, je retente demain, merci ;)
-
Je n'ai rien sur le port 67/68 sur eth0 (sauf si je précise l'interface sur le vlan)
root@router:~# tcpdump -nei eth0.832 port 67 or port 68
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth0.832, link-type EN10MB (Ethernet), snapshot length 262144 bytes
11:15:49.278947 28:87:ba:a1:07:7c > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 429: 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 28:87:ba:a1:07:7c, length 387
11:15:52.419036 28:87:ba:a1:07:7c > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 429: 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 28:87:ba:a1:07:7c, length 387
11:15:55.548952 28:87:ba:a1:07:7c > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 429: 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 28:87:ba:a1:07:7c, length 387
^C
3 packets captured
3 packets received by filter
0 packets dropped by kernel
root@router:~# tcpdump -nei eth0 port 67 or port 68
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth0, link-type NULL (BSD loopback), snapshot length 262144 bytes
Je peux faire un export complet du tcp dump sur eht0 mais je pense que je n'aurais que du traffic interne ou de paquets voulant sortir
Sinon en verbeux on voit juste la requete bootstrap du router
11:11:00.768924 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 415)
0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from 28:87:ba:a1:07:7c (oui Unknown), length 387, xid 0xe1e12352, secs 323, Flags [Broadcast] (0x8000)
Client-Ethernet-Address 28:87:ba:a1:07:7c (oui Unknown)
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message (53), length 1: Discover
MSZ (57), length 2: 576
Parameter-Request (55), length 12:
Subnet-Mask (1), Default-Gateway (3), Domain-Name-Server (6), Hostname (12)
Domain-Name (15), BR (28), NTP (42), Lease-Time (51)
RN (58), RB (59), AUTH (90), Classless-Static-Route (121)
Vendor-Class (60), length 5: "sagem"
User-Class (77), length 44:
instance#1: "FSVDSL_livebox.Internet.softathome.Livebox4", length 43
AUTH (90), length 70: 0.0.0.0.0.0.0.0.0.0.0.26.9.0.0.5.88.1.3.65.1.13.102.116.105.47.112.98.112.54.107.122.101.60.18.49.50.51.52.53.54.55.56.57.48.49.50.51.50.49.54.3.19.65.165.250.174.213.73.253.141.220.57.108.22.103.107.253.161.238
-
Hello,
Je ne sais pas si c'est normal, mais on dirait que tu n'as pas la bonne COS.
tos 0x0 correspond à la COS 0.
Je pense que tu devrais avoir 0xc pour de la COS 6.
Vous confirmez ?
-
La CoS se retrouve sur le header L2 (ethernet), pas L3 (IP).
Ajoute -xx pour avoir le contenue binaire de l'entête ethernet dans tes dumps. Et dump eth0 sans filtre (je pense que c'est le filtre qui marche moins bien avec le VLAN). Ce qui est important c'est les 18 premiers bytes ou tu devrais voir le cos avec le VLAN (genre 81 00 c3 40 = VLAN 832 + cos 6) pour les octets 12 13 14 15.
-
Hello,
Je ne sais pas si c'est normal, mais on dirait que tu n'as pas la bonne COS.
tos 0x0 correspond à la COS 0.
Je pense que tu devrais avoir 0xc pour de la COS 6.
Vous confirmez ?
Non, CoS 802.1p et TOS sont deux choses différentes.
Là sur aucun dump on ne voit l’en-tête ethernet donc impossible de conclure.
-
Merci pour l’info.
Comment voir la COS dans tcpdump ? Ça ressemblerait à quoi ?
Merci
-
Déjà il faut sniffer l’interface physique et pas un VLAN particulier (parce que du coup l’entête Ethernet saute). Ensuite avec les paramètres donnés par @Fuli10 ça devrait le faire.
-
Et ça apparaîtrait comment dans la trace ?
As tu une trace exemple stp ?
-
Non je suis en vacances à 500 bornes de chez moi, je n’ai qu’un iPad ici.
-
:) merci, bonnes vacances !!
-
Merci :). De mémoire sur la première ligne du dump d’un paquet tu dois avoir un p0 si la priorité est à 0 ou p6 pour une priorité à 6.
-
Merci !
-
Vos posts m'ont convaincu : je viens de commander un N5105 ( https://www.aliexpress.com/item/1005004302428997.html?spm=a2g0o.order_detail.0.0.51567d561aHPiJ ) sans OS.
Puisque vous l'avez déjà fait, quelle est la procédure pour installer OpenWRT dessus ?
Merci.
-
Puisque vous l'avez déjà fait, quelle est la procédure pour installer OpenWRT dessus ?
Tu branches un clavier/souris et un ecran sur le mini pc, et tu boot sur la clé usb comme lorsqu'on installe un OS.
Pour flasher openwrt sur la clé usb, tu récupères l'image officielle ici : https://downloads.openwrt.org/releases/21.02.3/targets/x86/64/
Tu prends : generic-ext4-combined-efi.img.gz et tu décompresses l'archive.
Tu flash la clé avec (par exemple) rufus : https://rufus.ie/fr/ ou Balena Etcher : https://www.balena.io/etcher/
Tuto très simple ici : https://openwrt.org/docs/guide-user/installation/openwrt_x86
PS:
Attention dans la version stable 21.02.3, il n'y a pas le driver pour les puces I225 : kmod-igc il faudra l'installer manuellement.
il sera installé d'office dans l'image dans la prochaine stable : 22.03.x
donc pour l'avoir directement dans son image on peut passer par les version RC (release candidate) et Snapshot :
https://downloads.openwrt.org/releases/22.03.0-rc6/targets/x86/64/
https://downloads.openwrt.org/snapshots/targets/x86/64/
ou alors créer en ligne une image stable 21.02.3, avec le driver kmod-igc intégré. c'est très simple à partir de ce lien :
https://firmware-selector.openwrt.org/?version=22.03.0-rc6&target=x86%2F64&id=generic
il suffit d'ajouter "kmod-igc" dans la liste des paquets. voir image.
(https://i.imgur.com/S8O5v4g.png)
PS2:
avec la 21.02.3 on est avec firewall3, donc IPTABLES
avec la 22.03.x ainsi que les RC et les Snapshot, on est avec firewall4, donc NFTABLES
-
Tu branches un clavier/souris et un ecran sur le mini pc, et tu boot sur la clé usb comme lorsqu'on installe un OS.
Pour flasher openwrt sur la clé usb, tu récupères l'image officielle ici : https://downloads.openwrt.org/releases/21.02.3/targets/x86/64/
Tu prends : generic-ext4-combined-efi.img.gz et tu décompresses l'archive.
Tu flash la clé avec (par exemple) rufus : https://rufus.ie/fr/ ou Balena Etcher : https://www.balena.io/etcher/
Tuto très simple ici : https://openwrt.org/docs/guide-user/installation/openwrt_x86
PS:
Attention dans la version stable 21.02.3, il n'y a pas le driver pour les puces I225 : kmod-igc il faudra l'installer manuellement.
il sera installé d'office dans l'image dans la prochaine stable : 22.03.x
donc pour l'avoir directement dans son image on peut passer par les version RC (release candidate) et Snapshot :
https://downloads.openwrt.org/releases/22.03.0-rc6/targets/x86/64/
https://downloads.openwrt.org/snapshots/targets/x86/64/
ou alors créer en ligne une image stable 21.02.3, avec le driver kmod-igc intégré. c'est très simple à partir de ce lien :
https://firmware-selector.openwrt.org/?version=22.03.0-rc6&target=x86%2F64&id=generic
il suffit d'ajouter "kmod-igc" dans la liste des paquets. voir image.
(https://i.imgur.com/S8O5v4g.png)
PS2:
avec la 21.02.3 on est avec firewall3, donc IPTABLES
avec la 22.03.x ainsi que les RC et les Snapshot, on est avec firewall4, donc NFTABLES
Que dire !
Merci pour la clarté de ta réponse. Tout y est :)
Je vais donc préparer la clef en avance…
Je vais commencer par une installation OpenWRT directement (OS principal, sans virtualisation, donc exactement ce que tu décris, merci :) ), probablement avec la dernière RC de la version 22…
Je suis très habitué à iptables, ebtables, un peu tc qdisc et filters (mes règles actuelles sont toutes iptables/ebtable) mais autant m'habituer dès le départ à nftables avec ce nouveau routeur.
Si je peux avoir docker-ce dessus (il semble qu'OpenWRT le permette), je mettrai ensuite d'autres choses en container (IDS ou IPS, smokeping…) par dessus OpenWRT.
Si non, je verrai à l'avenir pour un solution en virtualisation comme décrite plus haut dans ce sujet.
Je passerai indiquer comment tout cela se passe une fois la bête reçue, mais je sens que ça va être du gâteau 8)
-
j'ai oublié de préciser un truc, sur les Snapshot on n'a pas l'interface graphique Luci. Dans ce cas il faut l'installer manuellement...
opkg update
opkg install luci
Sur les versions stables, et release candidate, Luci est bien présent.
si tu pars sur la dernière RC6 c'est bon pour toi, tu auras le driver kmod-igc et Luci :)
-
j'ai oublié de préciser un truc, sur les Snapshot on n'a pas l'interface graphique Luci. Dans ce cas il faut l'installer manuellement...
opkg update
opkg install luci
Sur les versions stables, et release candidate, Luci est bien présent.
si tu pars sur la dernière RC6 c'est bon pour toi, tu auras le driver kmod-igc et Luci :)
Merci encore.
L'interface graphique, elle ne me servira qu'à l'installation… En fait, je l'enlèverai après, il n'y aura pas de moniteur ni de clavier (sauf à l'installation initiale donc).
J'ai l'habitude d'accéder à mon routeur et de tout y faire en SSH (et root ::) ). Je ferai probablement pareil avec celui-là, mais je vais quand même essayer l'interface web OpenWRT.
-
A partir d'OpenWrt 22.03-rc5 c'est possible de passer les règles nft par des include à la place de les charger dans /etc/rc.local :
Ajouter le fichier /etc/nftables.d/orange_rules.include qui contient
oifname "eth0.832" counter meta priority set 0:1
oifname "eth0.832" ip protocol icmp counter meta priority set 0:6
oifname "eth0.832" ip protocol igmp counter meta priority set 0:6
oifname "eth0.832" udp dport 67 counter meta priority set 0:6
oifname "eth0.832" udp dport 547 counter meta priority set 0:6
oifname "eth0.832" ip protocol icmpv6 counter meta priority set 0:6
Ajouter une section dans /etc/config/firewall
config include 'orange_rules'
option enabled '1'
option type 'nftables'
option path '/etc/nftables.d/orange_rules.include'
option position 'chain-append'
option chain 'mangle_postrouting'
;)
-
Finalement mon choix s'est porté sur celui-ci : https://fr.aliexpress.com/item/1005004302428997.html?spm=a2g0o.order_list.0.0.2d395e5bVbIVLB&gatewayAdapt=glo2fra
Du coup j'aurai :
- Routeur X86 N5105 4x2.5Gbps
- GPON-ONU-34-20BI
- Mikrotik CRS 305 pour accueillir l'onu en 2.5Gbps et gérer la cos 6 (udp 67 et udp 547).
- Mikrotik S+RJ10Gb (pour la liaison cuivre 2.5Gbps Mikro => Routeur X86
J'update une fois receptionné/en place ;)
Bonjour, ton routeur X86 N5105 tu l'as pris sans ram ni stockage ? Merci.
-
Bonjour, ton routeur X86 N5105 tu l'as pris sans ram ni stockage ? Merci.
Pour ma part, j'ai commandé avec 16 Go de RAM et 512 Go de NVMe pour un total de 287,69 euros.
J'ai commandé séparément chez Amazon :
https://www.amazon.fr/Thermal-Grizzly-Kryonaut-Wärmeleitpaste-Gramm/dp/B07FLL3QDZ/ref=sr_1_1?keywords=thermal+grizzly+kryonaut&qid=1660997749&sr=8-1
Pour remplacer la pâte thermique dès le départ par la meilleure du marché (pour un heatsink en alu), et
https://www.amazon.fr/gp/product/B08LDBJ9JV/ref=ppx_yo_dt_b_asin_title_o00_s00?ie=UTF8&psc=1
Pour mettre dessus.
-
A partir d'OpenWrt 22.03-rc5 c'est possible de passer les règles nft par des include à la place de les charger dans /etc/rc.local :
Ajouter le fichier /etc/nftables.d/orange_rules.include qui contient
oifname "eth0.832" counter meta priority set 0:1
oifname "eth0.832" ip protocol icmp counter meta priority set 0:6
oifname "eth0.832" ip protocol igmp counter meta priority set 0:6
oifname "eth0.832" udp dport 67 counter meta priority set 0:6
oifname "eth0.832" udp dport 547 counter meta priority set 0:6
oifname "eth0.832" ip protocol icmpv6 counter meta priority set 0:6
Ajouter une section dans /etc/config/firewall
config include 'orange_rules'
option enabled '1'
option type 'nftables'
option path '/etc/nftables.d/orange_rules.include'
option position 'chain-append'
option chain 'mangle_postrouting'
;)
Trop cool ça :D
Merci pour l'info, j'updaterai le tuto quand la 22.03 sera en version stable.
Bonjour, ton routeur X86 N5105 tu l'as pris sans ram ni stockage ? Merci.
J'ai commandé sans rien, et j'ai ajouté un ssd nvme 256go et 2x4Go de ram pour 60e sur amazon
-
au détour d'une conversation j'ai vu qu'il existait 2 supers routeurs 100% compatibles Openwrt, les images sont déjà dispo depuis la stable 21.02.1
IEI Puzzle M901 : https://www.ieiworld.com/fr/product/model.php?II=747
• Marvell® CN9130 quad-core Armv8 Cortex-A72 @ up to 2200 MHz
• Onboard 4GB DDR4
• Six 2.5GbE RJ-45 ports (three via Marvell CN9130; three via Marvell 88F8215)
• 4 GB eMMC; one console port (pin-header); one reset button
• LED indicators: status/power & WAN/LAN interface indicator
• Pre-installed OpenWrt
IEI Puzzle M902 : https://www.ieiworld.com/fr/product/model.php?II=748
• Marvell® CN9130 quad-core Armv8 Cortex-A72 @ up to 2200 MHz
• Six 2.5GbE RJ-45 ports (two via Marvell CN9130; four via Marvell 88F8215)
• Three 10GbE RJ-45 ports (one via Marvell CN9130; two via Marvell 88F8215)
• 4 GB eMMC; one console port (pin-header); one reset button
• LED indicators: status/power & WAN/LAN interface indicator
Les prix pratiqués sont pas si élevés vu les prestations, mais il faut arriver a les trouver :( :
M901 = https://store.qnap.com.tw/puzzle-m901-cn1-r10.html = 424€
M902 = https://store.qnap.com.tw/puzzle-m902-cn1-r10.html = 509€
https://www.youtube.com/watch?v=QgX76tLS6Dc
-
Du coup avec ce genre de config :
- Routeur X86 N5105 4x2.5Gbps
- GPON-ONU-34-20BI
- Mikrotik CRS 305 pour accueillir l'onu en 2.5Gbps et gérer la cos 6 (udp 67 et udp 547).
- Mikrotik S+RJ10Gb (pour la liaison cuivre 2.5Gbps Mikro => Routeur X86
la live box 6 ne sert plus à rien ou elle est quand utilisée?
Je viens de l'acquérir et je me demande en quoi le port 2,5 gigabit est il utile quand l'offre "Max" donne droit au max sur le papier à 2 gigabits....
Merci.
-
la live box 6 ne sert plus à rien ou elle est quand utilisée?
Je viens de l'acquérir et je me demande en quoi le port 2,5 gigabit est il utile quand l'offre "Max" donne droit au max sur le papier à 2 gigabits....
Tu as acheté une LB6 ?
Ben, le port 2.5 Gb/s te permet de profiter des 2 Gb/s de l'offre !
-
Tu as acheté une LB6 ?
Ben, le port 2.5 Gb/s te permet de profiter des 2 Gb/s de l'offre !
A condition d'avoir une carte réseau qui permet cela, non ?
-
Ben oui, ça tombe sous le sens !
Si tu n'as que des cartes ou du cablage à 100Mb/s, tu n'auras même pas le Gigabit.
-
A condition d'avoir une carte réseau qui permet cela, non ?
Oui, il faut que des deux côtés du câble les interfaces sachent parler 2,5 Gbps, sinon, ça sera ajusté le débit de l'interface la plus lente.
Et bien sûr que le câble soit adapté…
-
Ben oui, ça tombe sous le sens !
Si tu n'as que des cartes ou du cablage à 100Mb/s, tu n'auras même pas le Gigabit.
Je suis en gigabit sur mes ordis. J'ai prolongé la fibre sur les 3 niveaux de ma maison via des Switch (D-Link) en Gigabits également reliés entre eux via connections SFP mais tout ce petit monde est en 1g donc les 2 gigabits de mon n'offre ne seront pas atteignable si j'ai bien compris...
-
J'ai prolongé la fibre sur les 3 niveaux de ma maison via des Switch (D-Link) en Gigabits également reliés entre eux via connections SFP mais tout ce petit monde est en 1g donc les 2 gigabits de mon n'offre ne seront pas atteignable si j'ai bien compris...
Euh....
Quelle fibre as-tu prolongée ? la fibre Orange ?
Un petit schéma permettrait d'y voir plus clair.
Mais on est HS dans cette discussion.
-
Je suis en gigabit sur mes ordis. J'ai prolongé la fibre sur les 3 niveaux de ma maison via des Switch (D-Link) en Gigabits également reliés entre eux via connections SFP mais tout ce petit monde est en 1g donc les 2 gigabits de mon n'offre ne seront pas atteignable si j'ai bien compris...
Non, avec le câblage actuel (à compter que la catégorie le permette), la seule solution et de changer les switches et les cartes de chaque appareil…
Mais, c'est éventuellement possible en utilisant deux câbles 1 Gbps et de les grouper (LAG) si le switch le permet. Du coup, ça permet 2 Gbps.
-
Euh....
Quelle fibre as-tu prolongée ? la fibre Orange ?
Un petit schéma permettrait d'y voir plus clair.
Mais on est HS dans cette discussion.
Oui, on s'éloigne un peu du sujet initial… Mais ça reste quand même pertinent puisque krickgpe971 est chez Orange et se pose ces questions (sur la config de son LAN) dans le cadre d'un remplacement de sa Livebox par un routeur Openwrt…
Pour ma part, je ne suis que de passage sur ce sujet (pour la partie concernant le routeur N5105), car je ne suis pas chez Orange…
-
Euh....
Quelle fibre as-tu prolongée ? la fibre Orange ?
Un petit schéma permettrait d'y voir plus clair.
Mais on est HS dans cette discussion.
La fibre initiale d'orange rentre dans la Live box 6 je raccorde la lb6 au premier switch via un câble RJ45 cat7 et ce switch est connecté au 2ème via une jarretière et un connecteur gibic bd, idem pour aller du 2ème au 3ème switch.
-
Ok, donc tu ne prolonges pas du tout la fibre qui s'arrête à la LB6.
Tu as fait la desserte de ton réseau interne en fibre.
Si ton premier switch n'est pas en 2.5G, tu ne peux effectivement pas tirer plus que 1Gb/s pour l'ensemble de ton réseau. Ce qui est dommage.
En plus, si j'ai bien compris, tu as mis tes switch en cascade......
-
Ok, donc tu ne prolonges pas du tout la fibre qui s'arrête à la LB6.
Tu as fait la desserte de ton réseau interne en fibre.
Si ton premier switch n'est pas en 2.5G, tu ne peux effectivement pas tirer plus que 1Gb/s pour l'ensemble de ton réseau. Ce qui est dommage.
En plus, si j'ai bien compris, tu as mis tes switch en cascade......
La solution est de mettre un premier switch en 2,5G (Mikrotik - CRS305) comme expliqué ici :
https://lafibre.info/remplacer-livebox/tuto-switch-mikrotik-crs-305-pour-hgsmii-2-5gbps-et-la-cos-6/ ? Merci.
-
Oui, et alimenter les deux autres switch depuis le premier sans faire de cascade.
-
Oui, et alimenter les deux autres switch depuis le premier sans faire de cascade.
Ok, merci, si c'est pas en cascade c'est comment ?...
-
Les deux en direct sur le premier.
-
Les deux en direct sur le premier.
Du coup les 3 branchés sur le CRS305.
-
Au début tu parles de 3 switch, si tu rajoutes un CRS305, oui les 3 directement.
-
Au début tu parles de 3 switch, si tu rajoutes un CRS305, oui les 3 directement.
Ok merci.
-
Bonjour,
Comme je n'utilise pas de connexion la nuit, j'ai mis mon installation sur prise connectée avec allumage et extinction automatiques.
Je me suis rendu compte qu'en allumant tout au même moment, je me retrouvais avec un upload à 5 Mb/s au lieu d'avoir 300 Mb/s.
Quand le routeur s'allume, il faut donc dans mon cas que l'ONT soit pleinement actif sinon j'ai ce genre d'erreurs.
-
Un petit post pour confirmer que le N5105 fonctionne très bien comme routeur.
J'ai acheté avec un petit ventilateur USB à placer dessus, ainsi qu'une pâte thermique de qualité pour remplacer celle par défaut.
Je n'ai pas encore changé la pâte, et avec le ventilo, ça ne chauffe pas.
Un routeur avec 4 ports 2,5 Gbps et indépendants (pas en switch), c'est sympa !
Me reste à trouver le meilleur protocole pour les futures mises-à-jour de OpenWRT.
-
Hello,
Ça fait un bon moment que je n'ai plus touché à la config de mon routeur alors je suis un peu rouillé.
J'ai voulu réactiver l'ipv6 sur mon BT, sauf que, ça ne fonctionne plus (alors que la première fois ça avait marché du premier coup, je n'ai rien touché depuis). J'ai revérifié ma conf, à priori tout est ok (il est pour le moment sur la 18.06.1). L'IPv4 fonctionne sans problème.
Note : Je suis en ADSL, donc pas de prio à gérer.
config interface 'WAN6_DHCP'
option proto 'dhcpv6'
option reqprefix 'auto'
option defaultreqopts '0'
option sendopts '11:00000000000000000000001a0900000558010341010dXXXXXXXXXXXXXXXXXXXXXX 15:FSVDSL_livebox.Internet.softathome.livebox4 16:0000040e0005736167656d'
option reqopts '11 17 23 24'
option noclientfqdn '1'
option noacceptreconfig '1'
option reqaddress 'try'
option ifname 'dsl0'
Le FW :
config rule
option name 'Allow-MLD'
option proto 'icmp'
option src_ip 'fe80::/10'
list icmp_type '130/0'
list icmp_type '131/0'
list icmp_type '132/0'
list icmp_type '143/0'
option family 'ipv6'
option target 'ACCEPT'
option src 'wanipv6'
config rule
option name 'Allow-ICMPv6-Input'
option proto 'icmp'
list icmp_type 'echo-request'
list icmp_type 'echo-reply'
list icmp_type 'destination-unreachable'
list icmp_type 'packet-too-big'
list icmp_type 'time-exceeded'
list icmp_type 'bad-header'
list icmp_type 'unknown-header-type'
list icmp_type 'router-solicitation'
list icmp_type 'neighbour-solicitation'
list icmp_type 'router-advertisement'
list icmp_type 'neighbour-advertisement'
option limit '1000/sec'
option family 'ipv6'
option target 'ACCEPT'
option src 'wanipv6'
config rule
option name 'Allow-ICMPv6-Forward'
option proto 'icmp'
option limit '1000/sec'
option family 'ipv6'
option target 'ACCEPT'
option icmp_type 'echo-reply destination-unreachable echo-request time-exceeded'
option src 'wanipv6'
option dest '*'
config zone
option name 'wanipv6'
option output 'ACCEPT'
option input 'DROP'
option forward 'DROP'
option network 'WAN6_DHCP'
config forwarding
option dest 'wan'
option src 'lan'
config forwarding
option dest 'wanipv6'
option src 'lan'
-
Option 11 "longue" peut-etre devenue obligatoire (et ça devrait suivre pour l'option 90 IPv4 si ce n'est pas encore le cas) ?
-
Merci pour la piste.
Je viens de changer mais toujours pas d'adresse qui pop, du coup j'ai sorti tcpdump et c'est bizarre : Je reçois apparemment bien le préfixe mais il n'est pas pris en compte. Et il envoie en boucle des RS ???
Problème de FW peut-être ?
-
Alors, j'ai trouvé une solution : après avoir upgradé en 18.06.2 puis en 19.07 sans résultat, j'ai essayé de mettre en accept l'entrant : toujours rien. J'ai alors tenté de modifier la règle DHCPv6-input et au lieu d'avoir fc00::/6 en source et destination, j'ai mis any et magie, je récupère mon préfixe :D
Ce qui m'amène à une question : pourquoi fc00::/6 ? Car dans la capture on voit bien que l'échange se fait avec les link local. Je ne m'étais jamais posé la question avant, mais maintenant ça me parait bizarre.
EDIT : Je crois avoir compris la plage fc00::/6 engloble la fe80::/10 ? Du coup, je me demande pourquoi il a fallut autoriser tout...
-
Joie de courte durée... si j'ai bien récupéré mon préfixe, y'a un problème de routage, car rien ne sort... J'ai loupé quoi ?
La route vers ba0bab à l'air pourant en place :
ip -6 route show
default from 2a01:xxx:d2a:xxx::/56 via fe80::ba0:bab dev dsl0 metric 4096
2a01:xxx:d2a:xxx::/64 dev br-lan metric 1024
unreachable 2a01:xxx:d2a:xxx:/56 dev lo metric 2147483647 error -148
fd63:13cf:cda4::/64 dev br-lan metric 1024
unreachable fd63:13cf:cda4::/48 dev lo metric 2147483647 error -148
fe80::/64 dev eth0 metric 256
fe80::/64 dev eth0.832 metric 256
fe80::/64 dev br-lan metric 256
fe80::/64 dev wlan1 metric 256
fe80::/64 dev dsl0 metric 256
fe80::/64 dev wlan0 metric 256
anycast 2a01:cb14:d2a:9400:: dev br-lan metric 0
anycast fd63:13cf:cda4:: dev br-lan metric 0
anycast fe80:: dev eth0 metric 0
anycast fe80:: dev eth0.832 metric 0
anycast fe80:: dev br-lan metric 0
anycast fe80:: dev wlan1 metric 0
anycast fe80:: dev dsl0 metric 0
anycast fe80:: dev wlan0 metric 0
EDIT : un tcpdump plus tard, les deux se répondent continuellement avec des NS et NA sans autre trafic.
21:50:50.476425 IP6 fe80::200:1ff:fe00:0 > ff02::1:ffa0:bab: ICMP6, neighbor solicitation, who has fe80::ba0:bab, length 32
21:50:50.498362 IP6 fe80::ba0:bab > fe80::200:1ff:fe00:0: ICMP6, neighbor advertisement, tgt is fe80::ba0:bab, length 32
21:50:51.495616 IP6 fe80::200:1ff:fe00:0 > ff02::1:ffa0:bab: ICMP6, neighbor solicitation, who has fe80::ba0:bab, length 32
21:50:51.518453 IP6 fe80::ba0:bab > fe80::200:1ff:fe00:0: ICMP6, neighbor advertisement, tgt is fe80::ba0:bab, length 32
21:50:52.519651 IP6 fe80::200:1ff:fe00:0 > ff02::1:ffa0:bab: ICMP6, neighbor solicitation, who has fe80::ba0:bab, length 32
21:50:52.548770 IP6 fe80::ba0:bab > fe80::200:1ff:fe00:0: ICMP6, neighbor advertisement, tgt is fe80::ba0:bab, length 32
21:51:06.358137 IP6 fe80::200:1ff:fe00:0 > ff02::1:ffa0:bab: ICMP6, neighbor solicitation, who has fe80::ba0:bab, length 32
21:51:06.388594 IP6 fe80::ba0:bab > fe80::200:1ff:fe00:0: ICMP6, neighbor advertisement, tgt is fe80::ba0:bab, length 32
21:51:07.367618 IP6 fe80::200:1ff:fe00:0 > ff02::1:ffa0:bab: ICMP6, neighbor solicitation, who has fe80::ba0:bab, length 32
21:51:07.408681 IP6 fe80::ba0:bab > fe80::200:1ff:fe00:0: ICMP6, neighbor advertisement, tgt is fe80::ba0:bab, length 32
21:51:08.391615 IP6 fe80::200:1ff:fe00:0 > ff02::1:ffa0:bab: ICMP6, neighbor solicitation, who has fe80::ba0:bab, length 32
21:51:08.418769 IP6 fe80::ba0:bab > fe80::200:1ff:fe00:0: ICMP6, neighbor advertisement, tgt is fe80::ba0:bab, length 32
21:51:11.420250 IP6 fe80::200:1ff:fe00:0 > ff02::1:ffa0:bab: ICMP6, neighbor solicitation, who has fe80::ba0:bab, length 32
21:51:11.448769 IP6 fe80::ba0:bab > fe80::200:1ff:fe00:0: ICMP6, neighbor advertisement, tgt is fe80::ba0:bab, length 32
21:51:11.639009 IP6 fe80::ba0:bab > fe80::200:1ff:fe00:0: ICMP6, neighbor solicitation, who has fe80::200:1ff:fe00:0, length 32
21:51:12.423614 IP6 fe80::200:1ff:fe00:0 > ff02::1:ffa0:bab: ICMP6, neighbor solicitation, who has fe80::ba0:bab, length 32
21:51:12.448841 IP6 fe80::ba0:bab > fe80::200:1ff:fe00:0: ICMP6, neighbor advertisement, tgt is fe80::ba0:bab, length 32
21:51:13.447617 IP6 fe80::200:1ff:fe00:0 > ff02::1:ffa0:bab: ICMP6, neighbor solicitation, who has fe80::ba0:bab, length 32
???
EDIT : Problème résolu ! La config de mon parefeu est aux fraises, je suis obligé de mettre la zone wan pour que ça fonctionne, alors même que l'interface WAN6_DHCP a sa propre zone, comme dans le tuto... J'y comprends rien pour le coup.
EDIT2 : J'ai essayé de réarranger le bouzin mais ça ne fonctionne toujours pas et lors d'un reload, j'ai ces lignes :
Warning: fw3_ipt_rule_append(): Can't find target 'input_wan6_rule'
Warning: fw3_ipt_rule_append(): Can't find target 'output_wan6_rule'
Warning: fw3_ipt_rule_append(): Can't find target 'forwarding_wan6_rule'
Warning: fw3_ipt_rule_append(): Can't find target 'prerouting_wan6_rule'
Warning: fw3_ipt_rule_append(): Can't find target 'postrouting_wan6_rule'
Je ne comprends pas d'où ça sort. Et je suppose que c'est pour ça que les règles chient dans la colle.
Voici ma conf :
config defaults
option syn_flood '1'
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'REJECT'
config zone
option name 'lan'
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'ACCEPT'
option network 'lan'
config zone
option name 'wan'
option output 'ACCEPT'
option masq '1'
option input 'DROP'
option forward 'DROP'
option mtu_fix '1'
option network 'WAN_DHCP HENET'
config zone
option name 'wan6'
option output 'ACCEPT'
option forward 'DROP'
option network 'WAN6_DHCP'
option input 'DROP'
config zone
option input 'ACCEPT'
option forward 'REJECT'
option output 'ACCEPT'
option network 'tellb'
option name 'SIPLB4'
config rule
option name 'Allow-DHCP-Renew'
option src 'wan'
option proto 'udp'
option dest_port '68'
option target 'ACCEPT'
option family 'ipv4'
config rule
option name 'Allow-Ping'
option src 'wan'
option proto 'icmp'
option icmp_type 'echo-request'
option family 'ipv4'
option target 'ACCEPT'
config rule
option name 'Allow-IGMP'
option src 'wan'
option proto 'igmp'
option family 'ipv4'
option target 'ACCEPT'
config rule
option name 'Allow-DHCPv6'
option proto 'udp'
option src_ip 'fc00::/6'
option dest_ip 'fc00::/6'
option dest_port '546'
option family 'ipv6'
option target 'ACCEPT'
option src 'wan6'
config rule
option name 'Allow-MLD'
option proto 'icmp'
option src_ip 'fe80::/10'
list icmp_type '130/0'
list icmp_type '131/0'
list icmp_type '132/0'
list icmp_type '143/0'
option family 'ipv6'
option target 'ACCEPT'
option src 'wan6'
config rule
option name 'Allow-ICMPv6-Forward'
option proto 'icmp'
option limit '1000/sec'
option family 'ipv6'
option target 'ACCEPT'
option icmp_type 'echo-reply destination-unreachable echo-request time-exceeded'
option src 'wan6'
option dest '*'
config rule
option name 'Allow-ICMPv6-Input'
option proto 'icmp'
option limit '1000/sec'
option family 'ipv6'
option target 'ACCEPT'
list icmp_type 'destination-unreachable'
list icmp_type 'echo-reply'
list icmp_type 'echo-request'
list icmp_type 'neighbour-advertisement'
list icmp_type 'neighbour-solicitation'
list icmp_type 'router-advertisement'
list icmp_type 'router-solicitation'
list icmp_type 'time-exceeded'
option src 'wan6'
config rule
option name 'Allow-IPSec-ESP'
option src 'wan'
option dest 'lan'
option proto 'esp'
option target 'ACCEPT'
config rule
option name 'Allow-ISAKMP'
option src 'wan'
option dest 'lan'
option dest_port '500'
option proto 'udp'
option target 'ACCEPT'
config include
option path '/etc/firewall.user'
config forwarding
option dest 'wan'
option src 'SIPLB4'
config rule
option src 'SIPLB4'
option dest_port '53'
option proto 'tcpudp'
option target 'ACCEPT'
option name 'DNS Livebox'
config rule
option src 'SIPLB4'
option dest_port '67-68'
option proto 'udp'
option target 'ACCEPT'
option name 'DHCP Livebox'
config rule
option name 'Allow-DHCP-Renew for Livebox'
option proto 'udp'
option dest_port '68'
option target 'ACCEPT'
option family 'ipv4'
option src 'SIPLB4'
config forwarding
option dest 'wan'
option src 'lan'
config forwarding
option dest 'wan6'
option src 'lan'
EDIT3 : Je crois avoir enfin résolu le pb pour de bon ! : j'avais oublié de restreindre en v4/v6 chaque zone. Cette fois si je sélectionne wan6, j'ai bien mon préfixe. Par contre les lignes warning n'ont pas disparues.
-
Salut Renaud07
Oui il faut bien définir les zones,
Concernant ipv6 et le Fw, j'ai déjà eu plusieurs cas similaire au tiens que j'avais résolu en ajoutant l'interface vlan832 dans la zone wan6.
Si tu regardes la zone ipv6 du tuto (version 22.03) :
config zone
option name 'wan6'
option input 'DROP'
option output 'ACCEPT'
option forward 'DROP'
option family 'ipv6' ## Zone ipv6 only pour ne pas mélanger les règles sur les deux mondes
list network 'wan6'
list device 'eth0.832'
Du coup maintenant que la 22.03 est sortie en version stable, tu ne veux pas tenter l'upgrade ?
A +
-
Merci pour ta réponse. Le problème c'est que je suis en ADSL donc pas de VLAN à définir.
Sans compter que le eth0.832 est déjà occupé par la LB pour le téléphone. Ça va d'ailleurs être chaud lors du passage à la fibre, j'ai presque plus de place dans mon meuble pour caser un switch et le media converter.
Ou alors je change de routeur.
-
Merci pour ta réponse. Le problème c'est que je suis en ADSL donc pas de VLAN à définir.
Sans compter que le eth0.832 est déjà occupé par la LB pour le téléphone. Ça va d'ailleurs être chaud lors du passage à la fibre, j'ai presque plus de place dans mon meuble pour caser un switch et le media converter.
Ou alors je change de routeur.
Si adsl (sans vlans) tu devrais, du coup, associer ton interface pppoe dans la zone.
-
Bon la 22.03 est enfin en version stable donc je vais enfin pouvoir mettre à jour mon routeur !
J'ai lu les nouvelles instructions concernant nftables et il y a un truc que je ne comprends pas.
Au niveau de la configuration du device vous mappez la priorité netfilter 1 vers un VLAN PCP de 0 et la priorité netfilter 0 vers un VLAN PCP de 6 :
config device
option name 'eth0.832'
option type '8021q'
option ifname 'eth0'
option vid '832'
list egress_qos_mapping '0:0'
list egress_qos_mapping '2:2'
list egress_qos_mapping '3:3'
list egress_qos_mapping '4:4'
list egress_qos_mapping '5:5'
list egress_qos_mapping '6:6'
list egress_qos_mapping '7:7'
list egress_qos_mapping '1:0'
list egress_qos_mapping '0:6'
Puis dans les règles nftables vous créez une règle qui passe tout le trafic par défaut vers la priorité netfilter 1 :
nft add rule inet fw4 mangle_postrouting oifname "eth0.832" counter meta priority set 0:1
Pour ensuite avoir des règles spécifiques pour les protocoles ICMP, IGMP, DHCP, DHCPv6 et ICMPv6 :
nft add rule inet fw4 mangle_postrouting oifname "eth0.832" ip protocol icmp counter meta priority set 0:6
nft add rule inet fw4 mangle_postrouting oifname "eth0.832" ip protocol igmp counter meta priority set 0:6
nft add rule inet fw4 mangle_postrouting oifname "eth0.832" udp dport 67 counter meta priority set 0:6
nft add rule inet fw4 mangle_postrouting oifname "eth0.832" udp dport 547 counter meta priority set 0:6
nft add rule inet fw4 mangle_postrouting oifname "eth0.832" ip protocol icmpv6 counter meta priority set 0:6
Si on prends l'exemple d'une trame standard (qui n'est aucun des protocoles listés précédemment) :
1. Elle arrive sur le routeur, le noyau lui applique une priorité netfilter par défaut : 0
2. Elle fini par passer par la chaîne postrouting de la table mangle qui change cette priorité netfilter : 0->1
3. Elle arrive sur le device, le noyau map la priorité netfilter à une valeur PCP : 1->0
En gros on a changé sa priorité netfilter pour au final retomber sur un PCP de 0, je ne vois pas trop l'intérêt pour le coup. Pire on fait travailler le routeur pour rien, on demande au noyau de changer la priorité de toutes les trames qui passent.
Pourquoi ne pas simplifier la configuration comme ceci :
config device
option name 'eth0.832'
option type '8021q'
option ifname 'eth0'
option vid '832'
list egress_qos_mapping '0:0'
list egress_qos_mapping '6:6'
nft add rule inet fw4 mangle_postrouting oifname "eth0.832" ip protocol icmp counter meta priority set 0:6
nft add rule inet fw4 mangle_postrouting oifname "eth0.832" ip protocol igmp counter meta priority set 0:6
nft add rule inet fw4 mangle_postrouting oifname "eth0.832" udp dport 67 counter meta priority set 0:6
nft add rule inet fw4 mangle_postrouting oifname "eth0.832" udp dport 547 counter meta priority set 0:6
nft add rule inet fw4 mangle_postrouting oifname "eth0.832" ip protocol icmpv6 counter meta priority set 0:6
En gros avec ça, on ne touche pas au trafic par défaut. On laisse la priorité netfilter par défaut à 0 pour toutes les trames. Cette priorité est mappée à une valeur PCP de 0, ce qui est le cas par défaut. Ça ne demande aucun temps de calcul supplémentaire au routeur.
Pour le trafic qu'on veut changer (ICMP, IGMP, DHCP, DHCPv6 et ICMPv6) on demande à nftables de changer la priorité netfilter des trames à 6. Cette priorité est mappée à une valeur PCP de 6, ce qu'Orange veut pour récupérer une IPv4 et un préfixe IPv6.
Voilà, je me demandais si j'oubliais quelque chose qui fait que la solution que je propose ne fonctionnerait pas ou pas ! De toute façon je vais sûrement tester ça ce soir et je reviendrais donner des nouvelles. Mais si quelqu'un à une réponse avant ça me permettrait de ne pas perdre de temps ce soir à tester inutilement une solution qui ne fonctionne pas ^^
-
Je ne connais pas bien nftables et donc s'il est sujet aux mêmes limitations concernant les sockets RAW, mais en fait avec iptables il est impossible de matcher les paquets DHCP IPv4 du client DHCP (en IPv6 c'est différent, il est possible de faire un client sans utiliser de socket RAW) => Pour DHCPv4, Il est donc obligatoire de mapper la prio noyau 0 vers PCP6 vu qu'aucune règle iptables ne pourra changer la prio noyau. Le reste des règles découle de cette obligation pour remettre le traffic bulk en PCP0, puis les autres protocole qui le nécessitent en prio 6 (entre nous, inutile pour ICMP et IGMP, Orange s'en fout, même dans les zones ou PCP6 est obligatoire pour le DHCP).
Accessoirement, les règles qui tentent de matcher le dport 67 et 547 en fw4 ne servent IMO à rien (toujours pour la même raison).
-
Si adsl (sans vlans) tu devrais, du coup, associer ton interface pppoe dans la zone.
Ah ok, donc je dois faire un truc comme ça ? (je ne suis plus en pppoe)
option name 'wan6'
option input 'DROP'
option output 'ACCEPT'
option forward 'DROP'
option family 'ipv6'
list network 'WAN6_DHCP'
list device 'dsl0'
-
Je ne connais pas bien nftables et donc s'il est sujet aux mêmes limitations concernant les sockets RAW, mais en fait avec iptables il est impossible de matcher les paquets DHCP IPv4 du client DHCP (en IPv6 c'est différent, il est possible de faire un client sans utiliser de socket RAW) => Pour DHCPv4, Il est donc obligatoire de mapper la prio noyau 0 vers PCP6 vu qu'aucune règle iptables ne pourra changer la prio noyau. Le reste des règles découle de cette obligation pour remettre le traffic bulk en PCP0, puis les autres protocole qui le nécessitent en prio 6 (entre nous, inutile pour ICMP et IGMP, Orange s'en fout, même dans les zones ou PCP6 est obligatoire pour le DHCP).
Accessoirement, les règles qui tentent de matcher le dport 67 et 547 en fw4 ne servent IMO à rien (toujours pour la même raison).
OK je me souvenais de la limitation d'iptables concernant les trames DHCP mais vu que les nouvelles instructions essayent de matcher ces trames là je me suis dit que nftables réglait le problème, mais si c'est pas le cas je comprends mieux.
Personnellement ça fait un moment que j'utilise 'tc' pour modifier les priorités netfilter car celui-ci peut matcher les trames DHCP du client DHCPv4 d'OpenWrt et donc éviter de devoir modifier la priorité de toutes les trames.
J'ai jamais posté cette solution par manque de temps. Le problème potentiel de cette solution c'est qu'elle risque d'interférer avec le module SQM d'OpenWrt, mais personnellement je ne l'utilise pas donc ça ne me gène pas !
Je testerais les deux ce soir et je posterais les résultats.
Merci pour ta réponse en tout cas !
-
Accessoirement, les règles qui tentent de matcher le dport 67 et 547 en fw4 ne servent IMO à rien (toujours pour la même raison).
En faite la règle dport67 est necessaire, mais seulement pour le renew ! qui lui passe bien par fw3/fw4.
cf screenshot
-
Ah ok, donc je dois faire un truc comme ça ? (je ne suis plus en pppoe)
option name 'wan6'
option input 'DROP'
option output 'ACCEPT'
option forward 'DROP'
option family 'ipv6'
list network 'WAN6_DHCP'
list device 'dsl0'
Je viens d'essayer, ajouter dsl0 n'a aucun effet. Bref, c'est pas bien grave.
-
OK je me souvenais de la limitation d'iptables concernant les trames DHCP mais vu que les nouvelles instructions essayent de matcher ces trames là je me suis dit que nftables réglait le problème, mais si c'est pas le cas je comprends mieux.
...
Je testerais les deux ce soir et je posterais les résultats.
Merci pour ta réponse en tout cas !
Hello
Est-ce que la règle simplifié fonctionne du coup avec nftables ?
-
Hello !
La règle "simplifiée" n'a rien à voir avec nftables/iptables, tout se passe avec l'outil 'tc' qui configure le packet scheduler de Linux. Je n'ai d'ailleurs rien inventé, j'étais tombé sur l'excellent blog de Vincent Bernat qui a mis en place cette méthode pour son routeur "pur" Linux : https://vincent.bernat.ch/fr/blog/2019-orange-livebox-linux je n'ai fait que l'adapter à OpenWrt.
J'ai fait la MAJ 22.03 hier sur mon TP-Link Archer C7 v2, j'ai appliquée la configuration qui suit et ça fonctionne !
Je précise que je n'ai fait que quelques tests vite fait, j'ai voulu remonter toute ma config à la main cette fois-ci et ça m'a pris du temps donc j'ai pas encore tout testé. Mais mes speedtests préliminaires me permettent bien d'obtenir mes 300/300 en single et multi stream avec le flow offload d'activé. Malheureusement je ne peux pas benchmark plus que ça vu que j'atteint le plafond de mon offre et que j'ai un peu la flemme de tester la version nftables pour comparer.
Tagging du VLAN 832 sur le port physique WAN et l'interface eth0 :
uci set network.@switch_vlan[1].vlan='832'
uci set network.@switch_vlan[1].vid='832'
uci set network.@switch_vlan[1].ports='1t 6t'
uci commit
/etc/init.d/network restart
Configuration des mappings PCP egress sur la sous-interface eth0.832 :
uci add network device
uci set network.@device[1].name='eth0.832'
uci set network.@device[1].type='8021q'
uci set network.@device[1].ifname='eth0'
uci set network.@device[1].vid='832'
uci add_list network.@device[1].egress_qos_mapping='0:0'
uci add_list network.@device[1].egress_qos_mapping='6:6'
uci commit
/etc/init.d/network restart
Configuration DHCP/DHCPv6 sur les interfaces WAN et WAN6 :
uci set network.wan.proto='dhcp'
uci set network.wan.device='eth0.832'
uci set network.wan.broadcast='1'
uci set network.wan.macaddr='XX:XX:XX:XX:XX:XX'
uci set network.wan.hostname='*'
uci set network.wan.clientid='xxxxxxxxxxxx'
uci set network.wan.vendorid='sagem'
uci set network.wan.reqopts='1 3 6 15 28 51 58 59 90'
uci set network.wan.sendopts='77:xxxxxxxxxxxxxxxxxxxxx 90:yyyyyyyyyyyyyyyyyyyyyyyy'
uci set network.wan6.proto='dhcpv6'
uci set network.wan6.device='eth0.832'
uci set network.wan6.macaddr='XX:XX:XX:XX:XX:XX'
uci set network.wan6.reqaddress='none'
uci set network.wan6.reqprefix='auto'
uci set network.wan6.reqopts='11 17 23 24'
uci set network.wan6.sendopts='11:yyyyyyyyyyyyyyyyyyyyyyyy 15:FSVDSL_livebox.Internet.softathome.livebox4 16:0000040e0005736167656d'
uci set network.wan6.noclientfqdn='1'
uci set network.wan6.noacceptreconfig='1'
uci commit
(Je rajoute des configurations de requêtes qui ne sont pas obligatoire, comme le clone de l'adresse MAC de ma Livebox. C'est au cas où ces paramètres soient requis par Orange un jour.)
Script de changement de priorité netfilter :
#!/bin/sh
# Purpose: Change WAN egress ARP, DHCPv4, IGMP, ICMP, DHCPv6 and ICMPv6 traffic
# netfilter priority to a value of '6' in order to be mapped to a
# 802.1q PCP value of '6' later which is required by the french ISP
# "Orange" to obtain a public IPv4 address and an IPv6 prefix.
# Usage: This script expects a virtual subinterface name as the first and only
# argument.
# It's primarily made to be used on OpenWrt and called from an hotplug
# event script.
# Author: Victor Bouvier-Deleau (PlqnK)
# Adapted from: Vincent Bernat (MTU Ninja)
# https://vincent.bernat.ch/fr/blog/2019-orange-livebox-linux
# License: This script is available under the 3-Clause BSD License.
WAN_DATA_DEVICE="${1}"
# Configure a PRIO qdisc on WAN "data" interface.
tc qdisc replace dev "${WAN_DATA_DEVICE}" root handle 1: prio
tc filter del dev "${WAN_DATA_DEVICE}"
# DHCP (raw sockets, do not specify "protocol ip")
tc filter add dev "${WAN_DATA_DEVICE}" parent 1: prio 1 u32 \
match ip protocol 17 ff \
match ip dport 67 ffff \
action skbedit priority 0:6
# ARP
tc filter add dev "${WAN_DATA_DEVICE}" parent 1: prio 2 protocol 0x806 u32 \
match u32 0 0 \
action skbedit priority 0:6
# IGMP
tc filter add dev "${WAN_DATA_DEVICE}" parent 1: prio 3 protocol ip u32 \
match ip protocol 2 ff \
action skbedit priority 0:6
# ICMP
tc filter add dev "${WAN_DATA_DEVICE}" parent 1: prio 4 protocol ip u32 \
match ip protocol 1 ff \
action skbedit priority 0:6
# DHCPv6
tc filter add dev "${WAN_DATA_DEVICE}" parent 1: prio 5 protocol ipv6 u32 \
match ip6 protocol 17 ff \
match ip6 dport 547 ffff \
action skbedit priority 0:6
# ICMPv6
tc filter add dev "${WAN_DATA_DEVICE}" parent 1: prio 6 protocol ipv6 u32 \
match ip6 protocol 58 ff \
action skbedit priority 0:6
"Installé" comme ceci :
mkdir /etc/scripts && cd /etc/scripts
vi wan_tc_egress_priorities.sh # Copier/coller le contenu du script
chmod +x wan_tc_egress_priorities.sh
Script hotplug pour appeler le script précédent à chaque changement d'état de l'interface WAN/WAN6 :
WAN_DATA_DEVICE=eth0.832
[ "${ACTION}" = "ifup" -a "${DEVICE}" = "${WAN_DATA_DEVICE}" ] && {
logger -t hotplug "Configuring WAN tc filters due to ${ACTION} of ${INTERFACE} (${DEVICE})"
sh /etc/scripts/wan_tc_egress_priorities.sh "${DEVICE}"
}
"Installé" comme ceci :
cd /etc/hotplug.d/iface
vi 10-wan-tc # Copier/coller le contenu du script
chmod +x 10-wan-tc
-
Configuration du VLAN sur l'interface WAN :
uci set network.@switch_vlan[1].vlan='832'
uci set network.@switch_vlan[1].vid='832'
uci set network.@switch_vlan[1].ports='1t 6t'
uci commit
/etc/init.d/network restart
Configuration des mappings PCP sur l'interface WAN :
uci add network device
uci set network.@device[1].name='eth0.832'
uci set network.@device[1].type='8021q'
uci set network.@device[1].ifname='eth0'
uci set network.@device[1].vid='832'
uci add_list network.@device[1].egress_qos_mapping='0:0'
uci add_list network.@device[1].egress_qos_mapping='6:6'
uci commit
/etc/init.d/network restart
Je m'intéresse à openwrt et je n'y connais pas grand chose. Je regardais la configuration qui fonctionne. Je me demandais la nécessité de tag avec le vlan 832 au niveau du switch "Configuration du VLAN sur l'interface WAN" alors c'est fait déjà fait au niveau du wan "Configuration des mappings PCP sur l'interface WAN"?
-
Alors, je ne suis pas un pro d'OpenWrt mais de ce que je comprends le routeur dispose de 2 interfaces physiques. Une reliée au port physique WAN (eth0 sur mon routeur) et une reliée au switch physique (eth1 sur mon routeur).
Bien que l'interface eth0 est reliée au port WAN, celui-ci "apparait" comme un port du switch "virtuel" d'OpenWrt. Il est donc nécessaire de configurer le switch pour tagger le port physique et l'interface eth0. C'est ce que fait la première partie.
La deuxième partie créer un device eth0.832 pour pouvoir gérer le VLAN 832 sur l'interface eth0.
Il me semble que c'est spécifique à OpenWrt et son "module" swconfig. Pour les routeurs qui sont passé de swconfig à DSA le fonctionnement ressemble plus à un Linux classique, tu créer simplement une sous-interface eth0.832 et tu tag le VLAN 832 sur le port WAN du bridge br0.
N'hésitez pas à me corriger si je me trompe !
J'ai renommé les étapes de mon post précédent pour que ce soit plus clair.
-
Bonjour soucis avec decodeur UHD et non v4.
Routeur utilisé cudy wr1300, version 22.03
J'ai utilisé la configuration de la premiere page pour la configuration et le décodeur est sur le lan (2 ports physique , un pour le wan et un pour le lan)
Les flux HD passe de temps en temps par contre ceux HD+ , n'ont pas l'air de passer, une idée ?
Merci
-
Bonjour,
J'ai remplacé mon Netgear WNRD3800 par un un mini PC Lenovo m720q avec une carte ethernet 4 ports à base e realtek 8125B.
J'ai un LEOX LTX-010G-H.
J'ai installé la version OpenWRT 22.03 officielle et je l'ai configuré en suivant le tutoriel de la 1ere page.
J'ai lancé un test de débit sur le web (nperf).
J'obtiens :
- Downlod : 937MBits/s
- Upload : 4,1MB/s
Mon offre est l'Orange Up (2GBit/s et 600MBit/s).
Avec la livebox, je suis bien autour des 600MBit/s.
Pouvez-vous m'aider ?
Merci d'avance.
J'ai exécuté quelques commandes :
tcpdump -nei "eth4" port 53
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth4, link-type EN10MB (Ethernet), capture size 262144 bytes
10:34:10.127214 1c:fd:08:74:74:8f > a4:7b:2c:31:93:82, ethertype 802.1Q (0x8100), length 83: vlan 832, p 6, ethertype IPv4, 86.196.132.242.64313 > 8.8.8.8.53: 16247+ A? BRN3C2AF485549A.lan. (37)
10:34:10.135896 a4:7b:2c:31:93:82 > 1c:fd:08:74:74:8f, ethertype 802.1Q (0x8100), length 158: vlan 832, p 0, ethertype IPv4, 8.8.8.8.53 > 86.196.132.242.64313: 16247 NXDomain 0/1/0 (112)
10:34:27.455181 1c:fd:08:74:74:8f > a4:7b:2c:31:93:82, ethertype 802.1Q (0x8100), length 83: vlan 832, p 6, ethertype IPv4, 86.196.132.242.60514 > 8.8.8.8.53: 10448+ A? BRN3C2AF485549A.lan. (37)
10:34:27.464887 a4:7b:2c:31:93:82 > 1c:fd:08:74:74:8f, ethertype 802.1Q (0x8100), length 158: vlan 832, p 0, ethertype IPv4, 8.8.8.8.53 > 86.196.132.242.60514: 10448 NXDomain 0/1/0 (112)
10:34:40.681382 1c:fd:08:74:74:8f > a4:7b:2c:31:93:82, ethertype 802.1Q (0x8100), length 90: vlan 832, p 6, ethertype IPv4, 86.196.132.242.56821 > 8.8.8.8.53: 47204+ A? fe2cr.update.microsoft.com. (44)
10:34:40.681607 1c:fd:08:74:74:8f > a4:7b:2c:31:93:82, ethertype 802.1Q (0x8100), length 90: vlan 832, p 6, ethertype IPv4, 86.196.132.242.50923 > 8.8.8.8.53: 15063+ AAAA? fe2cr.update.microsoft.com. (44)
10:34:40.687831 a4:7b:2c:31:93:82 > 1c:fd:08:74:74:8f, ethertype 802.1Q (0x8100), length 176: vlan 832, p 0, ethertype IPv4, 8.8.8.8.53 > 86.196.132.242.56821: 47204 3/0/0 CNAME fe2cr.update.msft.com.trafficmanager.net., A 20.83.81.165, A
La priorité alterne entre 0 et 6 !
ethtool eth4
Settings for eth4:
Supported ports: [ TP ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
2500baseT/Full
Supported pause frame use: Symmetric Receive-only
Supports auto-negotiation: Yes
Supported FEC modes: Not reported
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Advertised pause frame use: No
Advertised auto-negotiation: Yes
Advertised FEC modes: Not reported
Link partner advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Link partner advertised pause frame use: No
Link partner advertised auto-negotiation: Yes
Link partner advertised FEC modes: Not reported
Speed: 1000Mb/s
Duplex: Full
Auto-negotiation: on
Port: Twisted Pair
PHYAD: 0
Transceiver: internal
MDI-X: Unknown
Supports Wake-on: pumbg
Wake-on: g
Current message level: 0x00000033 (51)
drv probe ifdown ifup
Link detected: yes
Je suis bien en 1Gbit/s full duplex.
ethtool -S eth4
tx_packets: 559821
rx_packets: 4669350
tx_errors: 0
rx_errors: 0
rx_missed: 0
align_errors: 0
tx_single_collisions: 0
tx_multi_collisions: 0
unicast: 4669211
broadcast: 2
multicast: 137
tx_aborted: 0
tx_underrun: 0
tx_octets: 113631417
rx_octets: 7034742788
rx_multicast64: 0
tx_unicast64: 559802
tx_broadcast64: 3
tx_multicast64: 16
tx_pause_on: 0
tx_pause_off: 0
tx_pause_all: 0
tx_deferred: 0
tx_late_collision: 0
tx_all_collision: 0
tx_aborted32: 0
align_errors32: 0
rx_frame_too_long: 0
rx_runt: 0
rx_pause_on: 0
rx_pause_off: 0
rx_pause_all: 0
rx_unknown_opcode: 0
rx_mac_error: 0
tx_underrun32: 0
rx_mac_missed: 1
rx_tcam_dropped: 0
tdu: 0
rdu: 0
iperf3 -c bouygues.iperf.fr -p 9201 -P 1 -4
[ 5] local 86.196.132.242 port 42004 connected to 89.84.1.186 port 9201
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 772 KBytes 6.32 Mbits/sec 0 56.6 KBytes
[ 5] 1.00-2.00 sec 669 KBytes 5.48 Mbits/sec 0 84.8 KBytes
[ 5] 2.00-3.00 sec 669 KBytes 5.48 Mbits/sec 0 113 KBytes
[ 5] 3.00-4.00 sec 851 KBytes 6.97 Mbits/sec 0 141 KBytes
[ 5] 4.00-5.00 sec 730 KBytes 5.98 Mbits/sec 0 171 KBytes
[ 5] 5.00-6.00 sec 365 KBytes 2.99 Mbits/sec 0 199 KBytes
[ 5] 6.00-7.00 sec 912 KBytes 7.47 Mbits/sec 0 228 KBytes
[ 5] 7.00-8.00 sec 486 KBytes 3.98 Mbits/sec 0 272 KBytes
[ 5] 8.00-9.00 sec 1.19 MBytes 9.97 Mbits/sec 0 362 KBytes
[ 5] 9.00-10.00 sec 851 KBytes 6.97 Mbits/sec 0 477 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 7.35 MBytes 6.16 Mbits/sec 0 sender
[ 5] 0.00-10.87 sec 5.97 MBytes 4.60 Mbits/sec receiver
iperf3 -c bouygues.iperf.fr -p 9201 -P 1 -6
[ 5] local 2a01:cb00:8173:8300::1 port 42738 connected to 2001:860:de01:1100::2 port 9201
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 774 KBytes 6.34 Mbits/sec 0 55.8 KBytes
[ 5] 1.00-2.00 sec 675 KBytes 5.53 Mbits/sec 0 83.7 KBytes
[ 5] 2.00-3.00 sec 675 KBytes 5.53 Mbits/sec 0 112 KBytes
[ 5] 3.00-4.00 sec 552 KBytes 4.52 Mbits/sec 0 139 KBytes
[ 5] 4.00-5.00 sec 675 KBytes 5.53 Mbits/sec 0 169 KBytes
[ 5] 5.00-6.00 sec 798 KBytes 6.53 Mbits/sec 0 197 KBytes
[ 5] 6.00-7.00 sec 920 KBytes 7.54 Mbits/sec 0 225 KBytes
[ 5] 7.00-8.00 sec 491 KBytes 4.02 Mbits/sec 0 268 KBytes
[ 5] 8.00-9.00 sec 1.32 MBytes 11.1 Mbits/sec 0 357 KBytes
[ 5] 9.00-10.00 sec 920 KBytes 7.54 Mbits/sec 0 470 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 7.65 MBytes 6.41 Mbits/sec 0 sender
[ 5] 0.00-10.87 sec 5.89 MBytes 4.54 Mbits/sec receiver
-
Hello,
Elle n'alterne pas la priorité, elle est toujours à 6 dans le sens chez toi > distant.
Vérifie tes règles nft, faut que je maj le tuto d'ailleurs mtn qu'on peut le faire directement depuis le /etc/config/firewall
nft list ruleset | grep "set 0:" | wc -ldoit te donner > 0 si tes règles sont chargées
-
Tu peux faire comme le présente Naouel (remplace eth0.832 par eth4.832 dans tons cas) :
A partir d'OpenWrt 22.03-rc5 c'est possible de passer les règles nft par des include à la place de les charger dans /etc/rc.local :
Ajouter le fichier /etc/nftables.d/orange_rules.include qui contient
oifname "eth0.832" counter meta priority set 0:1
oifname "eth0.832" ip protocol icmp counter meta priority set 0:6
oifname "eth0.832" ip protocol igmp counter meta priority set 0:6
oifname "eth0.832" udp dport 67 counter meta priority set 0:6
oifname "eth0.832" udp dport 547 counter meta priority set 0:6
oifname "eth0.832" ip protocol icmpv6 counter meta priority set 0:6
Ajouter une section dans /etc/config/firewall
config include 'orange_rules'
option enabled '1'
option type 'nftables'
option path '/etc/nftables.d/orange_rules.include'
option position 'chain-append'
option chain 'mangle_postrouting'
;)
-
Il y a truc bizzard.
Quand je mets la fibre au cul de la livebox, j'ai bien les 600Mbit/s. Jusqu'ici c'est normal !
Par contre, quand je mets le LEOX (donc port 4 de livebox), j'obtiens 2 à 5MBit/s en upload ! Et pourtant j'ai bien 900Mbit/s en download !
La commande nft list ruleset | grep "set 0:" | wc -l me donne 0
J'ai fait l'histoire de l'include. Maintenant la commande nft list ruleset | grep "set 0:" | wc -l me donne 12
Maintenant, l'upload est inférieur à 1MBit/s
(https://pic.nperf.com/r/3407017273212434-9tmP2WmU.png)
-
Si tu as le problème avec la Livebox + Leox il va falloir investiguer différemment.
Ca me fait penser à ce post de V3yz, peux-tu, dans le doute, demarrer l'ont et attendre quelques minutes avant de brancher la box ?
Bonjour,
Comme je n'utilise pas de connexion la nuit, j'ai mis mon installation sur prise connectée avec allumage et extinction automatiques.
Je me suis rendu compte qu'en allumant tout au même moment, je me retrouvais avec un upload à 5 Mb/s au lieu d'avoir 300 Mb/s.
Quand le routeur s'allume, il faut donc dans mon cas que l'ONT soit pleinement actif sinon j'ai ce genre d'erreurs.
Sinon depuis l'interface web/cli de l'ont, tu as moyen de récupérer des logs ?
-
J'ai attendu quelques minutes (3 à 5) et c'est pareil.
Et j'ai pas vu de log dans le LEOX.
-
Dites, la délégation de préfixe fonctionne sur le LAN ? Je voulais me faire un 2nd réseau sur un pfsense, mais y veut rien me donner, j'ai droit invariablement à : Status Code: NoPrefixAvail (6)
Après avoir lu la doc, il semblerait qu'il faille mettre la valeur ip6assign plus petit que /64. J'ai donc essayé /60 voir le /56 entier... toujours rien. J'ai également rajouté dans le doute la ligne : option dhcpv6_pd '1'
Setting the ip6assign-parameter to a value < 64 will allow the DHCPv6-server to hand out all but the first /64 via DHCPv6-Prefix Delegation to downstream routers on the interface.
Ma conf :
config dhcp 'lan'
option interface 'lan'
option ignore '1'
option ra 'server'
option dhcpv6 'server'
option dhcpv6_pd '1'
list domain 'lpa.lan'
list dns 'fd63:13cf:cda4:0:ba27:xxx:xxx:xxx'
option ra_management '1'
-
Dites, la délégation de préfixe fonctionne sur le LAN ? Je voulais me faire un 2nd réseau sur un pfsense, mais y veut rien me donner, j'ai droit invariablement à : Status Code: NoPrefixAvail (6)
Après avoir lu la doc, il semblerait qu'il faille mettre la valeur ip6assign plus petit que /64. J'ai donc essayé /60 voir le /56 entier... toujours rien. J'ai également rajouté dans le doute la ligne : option dhcpv6_pd '1'
Ma conf :
config dhcp 'lan'
option interface 'lan'
option ignore '1'
option ra 'server'
option dhcpv6 'server'
option dhcpv6_pd '1'
list domain 'lpa.lan'
list dns 'fd63:13cf:cda4:0:ba27:xxx:xxx:xxx'
option ra_management '1'
Que souhaites-tu faire ?
Si c'est juste présenter un /64 par interface lan, c'est pas du PD à faire coté LAN.
PD c'est juste sur le wan pour récupérer le /56.
Regarde ma conf, j'ai 7 vlans avec chacuns un /64, très simple, pas de dhcpv6 (et donc pas de flags ra) que du slaac :
Openwrt va utiliser automatiquement les /64 dispo du /56, mais tu peux le spécifier si tu préfères.
config dhcp 'vlanX'
option interface 'lanX'
option start '100'
option limit '59'
option leasetime '12h'
option dhcpv4 'server'
option ra 'server'
list ra_flags 'none'
list dns '2606:4700:4700::1111'
Coté Network :
config interface 'lanX'
option proto 'static'
option ipaddr '192.168.X.1'
option netmask '255.255.255.0'
option ip6assign '64'
option ip6ifaceid '::bad'
option device 'eth1.X'
-
Ah ok, mais ça c'est si les VLAN sont sur le routeur.
Ce que je cherche faire c'est déléguer un /64 à un pfsense qui est sur le LAN afin d'avoir une plage dédiée pour mes VM. Donc dans ce cas je suis bien obligé de faire du PD, non ?
-
Ah ok, mais ça c'est si les VLAN sont sur le routeur.
Ce que je cherche faire c'est déléguer un /64 à un pfsense qui est sur le LAN afin d'avoir une plage dédiée pour mes VM. Donc dans ce cas je suis bien obligé de faire du PD, non ?
Ok je comprends mieux, non pas de PD "obligatoire".
Si c'est uniquement pour un seul /64, rien ne t'empêche de configurer une ipv6 du /64 attribué (de ton choix) au lan pfsense sur l'interface Lan Pfsense, sans PD, diffuser les RA en conséquence sur le lan pfsense.
Et de faire une route static sur openwrt ::/64 "lan-pfsense" vers "ipv6-wan-pfsense"
-
Merci.
C'est vrai que je pourrais le faire à la main, mais j'aimerais bien arriver à faire fonctionner le PD.
Je vais quand même voir si j'y arrive à la mano au cas où.
EDIT : Ça à l'air mal parti, le pfsense me bombarde le réseau de NS malgré l'IP attribuée et je n'ai pas accès au net... J'ai l'impression qu'il y a des bugs sur l'ipv6 sur les dernières versions. Je vais ouvrir mon propre sujet du coup.
EDIT2 : à priori il y a une incompatibilité entre freeBSD et certains bridges virtuels (j'ai aussi vu le cas sur hyper-v ou KVM après recherche). Le message d'erreur fait référence à DAD (Duplicate Address Detection)
a looped back NS message is detected during DAD for [IPv6 ADDRESS REDACTED]. Another DAD probes are being sent.
Il faut donc désactiver la fonction dans sysctl : net.inet6.ip6.dad_count=0 (à rensigner via l'interface web : System > Advanced > System Tunables)
-
Finalement ça fonctionne : il suffisait de rebooter (un network restart n'était pas suffisant) ::)
Par contre, c'est normal que ça délègue un /62 et pas /64 ? J'ai essayé de trouver des infos, mais c'est pas très clair... J'ai aussi remarqué qu'on ne peut pas demander autre chose, par ex j'indique que je veux un /60, c'est toujours un /62 qui est renvoyé. (J'ai bien évidemment mis le ip6assign à /56)
EDIT : J'ai rien dit : j'avais oublié de cocher la case Send IPv6 prefix hint dans les options. Et cette fois j'ai bien un /64 ou un /60 8)
-
Bonjour,
Même souci de mon coté que "akeix" sur les débits avec un Netgear R7800, je plafonne à 5 max en upload.
Je suis passé du firmware ath10k-firmware-qca9984-ct au ath10k-firmware-qca9984 classique car lors de mon souci avec openwrt 19.08 cela avait fonctionner...
Malheureusement pas cette fois.
Idem pour l'allumage de l'ONT avant le routeur.
Si quelqu'un à des pistes et commandes pour investiguer sur ce souci je suis intéresser.
Bonne journée.
-
Bonjour à tous,
Tout d'abord merci à ubune pour son travail et son tuto !
Je suis chez Sosh en fibre optique et j'ai acheté depuis peu un routeur ASUS RT-AX53U et j'aimerai le mettre à la place de ma livebox 4.
=> Lien vers la fiche de mon routeur : https://www.asus.com/fr/Networking-IoT-Servers/WiFi-Routers/ASUS-WiFi-Routers/RT-AX53U/
Je suis en SFP, j'ai donc acheté un boitier ONT TP-LINK MC220L, j'ai mis le SFP dedans et je l'ai branché pour testé sur la livebox sur le port wan => cela fonctionne parfaitement.
J'ai installé sur mon routeur OpenWrt 22.03 sans souci, c'est à partir de la que les choses se gâtent :)
J'ai suivi scrupuleusement le tuto et quand je branche le câble ethernet sortant de l'ONT sur le port WAN de mon routeur, je n'ai pas accès à internet.
Je n'ai aucune idée de se que j'ai mal fait, et encore moins de savoir comment je pourrais avoir accès à des log d'erreur ou autre.
J'ai regardé les logs dans luci mais y a rien de concluant, mes interfaces WAN4 et WAN6 ne démarrent pas.
Les règles du fichier etc/nftables.d/nft-prio6-rules.include sont bien chargées ( nft list ruleset | grep "set 0:" | wc -l me renvoie bien 6)
Pour le reste, j'ai suvi le tuto en adaptant au règles de base que j'avais dans mes fichiers network, firewall et dhcp.
Peux être dois je en supprimer certaines, j'ai essayé plusieurs configurations sans succès.
J'ajoute mes fichiers en PJ si une belle âme veux bien y jeter un œil, j'ai remplacé la chaîne de caractère générée par les identifiants par XXXXXXXX
Les résultats de ifstatus sont :
=> wan4
{
"up": false,
"pending": true,
"available": true,
"autostart": true,
"dynamic": false,
"proto": "dhcp",
"device": "eth0.832",
"data": {
}
}
wan6 :
{
"up": false,
"pending": true,
"available": true,
"autostart": true,
"dynamic": false,
"proto": "dhcpv6",
"device": "eth0.832",
"data": {
}
}
Un petit coup de pouce ne serait pas de refus.
Merci à tous :)
-
Hello,
D'après ton fichier network
config device
option name 'br-lan'
option type 'bridge'
list ports 'lan1'
list ports 'lan2'
list ports 'lan3'
list ports 'lan4'
Tes 4 ports physiques sont associés au br-lan.
Peux-tu envoyer le fichier network "vierge" après installation d'openwrt sur ton routeur ?
Le plus simple dans ton cas est de configurer l'interface wan vlan 832 depuis luci pour voir comment ça se nomme sur ton fichier network.
Mais si tu dois sortir un port pour le wan, tu devras configurer un truc du style :
config device
option name 'br-lan'
option type 'bridge'
list ports 'lan1'
list ports 'lan2'
list ports 'lan3'
config device
option name 'lan4.832'
config device
option type '8021q'
option ifname 'lan4'
option vid '832'
list egress_qos_mapping '0:0'
list egress_qos_mapping '2:2'
list egress_qos_mapping '3:3'
list egress_qos_mapping '4:4'
list egress_qos_mapping '5:5'
list egress_qos_mapping '6:6'
list egress_qos_mapping '7:7'
list egress_qos_mapping '1:0'
list egress_qos_mapping '0:6'
config interface 'wan4'
option proto 'dhcp'
option device 'lan4.832'
option hostname '*'
option broadcast '1'
option norelease '1'
option vendorid 'sagem'
option reqopts '1 15 28 51 58 59 90'
option sendopts '77:2b46535644534c5f6c697665626f782e496e7465726e65742e736f66746174686f6d652e4c697665626f7834 90:XXXXXXXXXX'
config interface 'wan6'
option proto 'dhcpv6'
option device 'lan4.832'
option reqprefix 'auto'
option reqaddress 'none'
option defaultreqopts '0'
option sendopts '11:XXXXXXXXXX 15:FSVDSL_livebox.Internet.softathome.livebox4 16:0000040e0005736167656d'
option reqopts '11 17 23 24'
option noclientfqdn '1'
option noacceptreconfig '1'
Et du coup modifie ton fichier nft-prio6-rules.include et ton fichier firewall avec lan4.832 au lieu de eth0.832
Attention, j'ai pris au pif lan4, à toi de découvrir quel port physique correspond lan4 et ajuster si tu préfères brancher ta box ailleurs.
-
Bonjour ubune,
J'ai fais un premier essai sur le lan4 sans succès car c'est assez étrange qu'il y ait 4 ports lans dans la config device sous luci par défaut alors qu'il n'y a que 3 ports éthernets + 1 port wan sur le router.
Du coup, lan4 semblait pas si mal ;)
Finalement, j'ai mappé sur le device nommé "wan" (tout bêtement) pour créer le "wan.382" + modification du fichier des règles etc et ça fonctionne !!!!
Je vais tester tout ça un peu plus en profondeur maintenant que cela fonctionne !
Un grand merci à toi pour le coup de main !
-
Cool parfait ;)
ça donne quoi niveau perf ce routeur ?
J'ai ajouté un petite ligne en rouge dans le tuto pour prévenir que eth0 n'est pas le nom pour tous.
A bientôt
-
@akeix
Décoche "Software flow offloading" ;-)
-
@ubune
Cool parfait ;)
ça donne quoi niveau perf ce routeur ?
J'ai ajouté un petite ligne en rouge dans le tuto pour prévenir que eth0 n'est pas le nom pour tous.
A bientôt
Pour mon appart de 65m², la couverture wifi est bonne, si plus grand peut être qu'il sera un peu limite (après ça dépends des murs / couloirs bien sûr).
Sinon pour les perfs pures, je suis chez sosh donc limité à 300mb/s dans les deux sens et j'atteins ce max en terme de débit.
A part ça, j'ai installé pas mal de modules openwrt : adblock, DNS over TLS sur cloudflare, partage samba4 sur une clé usb connecté au port usb2.0 du routeur et dynamique dns sur no-ip car pas d'ip fixe avec sosh.
Le tout tiens la charge sans problème, j'ai encore pas mal de ressources disponibles (stockage openwrt, mémoire ram disponible) même si le partage samba bouffe pas mal de RAM. J'ai planifié un petit reboot matinal quotidien pour cela, j'ai l'impression qu'il ne libère pas bien la mémoire du partage samba4 (mais bon c'est du à samba pas au routeur en lui même). Niveau CPU, j'ai pas regardé la charge pendant les tests de perfs, ou transfert samba, j'y jetterais un coup d'œil et je mettrais à jour le post.
Me reste plus qu'à mettre wiregard server pour l'accès vpn et peux être SQM mais j'ai cru comprendre que ça bouffe pas mal de CPU et pour le moment j'ai pas trop de problème de saturation de bande passante.
Le seul bémol le port usb 2.0, du coup pour le partage samba c'est un peu lent entre 6Mo à 10Mo par seconde en écriture (non limité par la clé usb qui encaisse bien plus en terme de vitesse de transfert) mais ça reste correcte et la lecture sur ce "NAS du pauvre" via kodi par mon Android Tv est utilisable malgré un petit temps d'attente pour l'initialisation.
Y a sans doute des optimisations possible dans ce secteur (NFS sans doute mieux que samba) mais j'ai pas eu le temps de geeker dessus encore.
D'autre part, l'installation de openwrt est vraiment facile, on peut activer directement l'accès via ssh depuis l'os d'asus, se connecter via ssh puis faire un wget de l'image d'openwrt et flasher.
Enfin, il supporte le wifi 6, ce qui je pense est assez rare dans les routeurs supportant openwrt en dernière version stable.
En tout cas j'en suis pleinement satisfait pour le moment pour un prix de 76 euros (sans l'ONT juste le routeur).
-
@akeix
Décoche "Software flow offloading" ;-)
Bonjour,
La case "Sotfware flow offloading" n'est pas cochée
-
Bonjour,
Après avoir fait le tuto de zéro puis ma configuration d'origine pas à pas, j'ai constatée que c'était cette option qui me bridée en upload.
Je ne vois pas donc pas de où vient votre souci, désolé.
-
Bonjour,
Avec ma livebox 5 (Fibre <====> Livebox 5 <====> PC), je n'ai aucun soucis de débit montant. J'atteins bien les 600MBit/s
Par contre, avec le LEOX LTX-010H-D (or le LTX-010G-D), le débit montant est inférieur à 7 Mbit/s que ce soit avec ma livebox 5 ou mon routeur OpenWRT :
Fibre <====> LEOX <====> Livebox 5-Eth4 (Ou mon routeur OpenWRT) <====> PC
Chez moi (Bourges), j'ai du changer la valeur de HW_HWVER. Donc je dois être sur un OLT Alcatel d'après les informations du forum.
Sans changer cette valeur, le leox passe bien au statut "O5" mais la livebox ne se connecte pas.
J'ai donc passé les commandes suivantes pour configurer le LEOX:
flash set GPON_SN ARLTxxxxxxxx
flash set PON_VENDOR_ID ARLT
flash set HW_HWVER ARLTyyyyyyyy
D'après iperf3, je perds environ 2% des paquets qui circulent en UDP.
iperf3 -c speedtest.milkywan.fr -p 9201 -u -b 400M
Connecting to host speedtest.milkywan.fr, port 9201
[ 5] local 2a01:cb00:8173:8300::1 port 49013 connected to 2a0b:cbc0:42:1::1 port 9201
[ ID] Interval Transfer Bitrate Total Datagrams
[ 5] 0.00-1.00 sec 47.7 MBytes 400 Mbits/sec 34990
[ 5] 1.00-2.00 sec 47.7 MBytes 400 Mbits/sec 35014
[ 5] 2.00-3.00 sec 47.7 MBytes 400 Mbits/sec 35014
[ 5] 3.00-4.00 sec 47.7 MBytes 400 Mbits/sec 35037
[ 5] 4.00-5.00 sec 47.7 MBytes 400 Mbits/sec 35015
[ 5] 5.00-6.00 sec 47.7 MBytes 400 Mbits/sec 35013
[ 5] 6.00-7.00 sec 47.7 MBytes 400 Mbits/sec 35010
[ 5] 7.00-8.00 sec 47.7 MBytes 400 Mbits/sec 35007
[ 5] 8.00-9.00 sec 47.7 MBytes 400 Mbits/sec 35023
[ 5] 9.00-10.00 sec 47.7 MBytes 400 Mbits/sec 34999
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5] 0.00-10.00 sec 477 MBytes 400 Mbits/sec 0.000 ms 0/350122 (0%) sender
[ 5] 0.00-10.05 sec 466 MBytes 389 Mbits/sec 0.027 ms 7848/350117 (2.2%) receiver
Par contre, le débit descendant est tres bon : >900MBit/s avec la livebox 5 et >1900MBit/s avec mon routeur.
Mon routeur et mon PC sont équipés de carte réseau à base realtek RTL8125B.
Voilà pour l'ensemble des infos.
-
J'ai installé Esxi sur cette petite machine, et ça tourne merveilleusement bien.
Il faut juste se créer un iso esxi avec les drivers i225v (pour les 4 ports 2.5gbps).
Hello,
Puis-je te demander pourquoi une préférence Esxi vs Proxmox ?
Un problème connu avec les drivers i225v ? Préférence personnelle ?
Je demande car je souhaiterais utiliser ce mini-pc avec OpenWRT en virtualisé, mais aussi avec un container Docker qui utilise un Google Coral (USB) et apparemment il y a d'autres complications propres à l'utilisation de Esxi dans ce cas-là.
-
Certainement une préférence car c'est un produit que j'utilise au quotidien dans le taff.
Mais même coté perso, en faite j'ai déja plusieurs esxi qui sont installés sur différents liens fibres, ils sont managés par un même vcenter (ipv6 only).
Résultat je peux, par exemple, très facilement dupliquer/migrer une vm entre les noeuds des différents sites.
Dans le cas des usb, le mieux sinon est d'avoir une carte pci/usb que tu passtrough directement dans la vm désirée, et la t'es sûr de n'avoir aucun pb (c'est comme si elle était directement connecté dans la vm).
Si vraiment tu veux faire autre chose que juste "openwrt", te monter une petite tour (vive les ports pcie) c'est le top :P.
A+
-
Ok, ça marche. Je vais expérimenter tout ça. :) Merci.
-
Hello,
Puis-je te demander pourquoi une préférence Esxi vs Proxmox ?
Un problème connu avec les drivers i225v ? Préférence personnelle ?
Je demande car je souhaiterais utiliser ce mini-pc avec OpenWRT en virtualisé, mais aussi avec un container Docker qui utilise un Google Coral (USB) et apparemment il y a d'autres complications propres à l'utilisation de Esxi dans ce cas-là.
Dans mon cas, j'ai hésité à installer un Proxmox ou autre, mais j'ai finalement opté pour installer OpenWrt directement.
OpenWrt supporte bien Docker et j'utilise donc des conteneurs Docker par dessus OpenWrt pour certains services. Ça me satisfait bien ainsi.
Le N5105 est d'ailleurs super avec OpenWrt.
-
Bonjour à tous :)
Je suis actuellement sur openwrt 21.02.3 avec l'ancien tuto switch + iptables et tout fonctionne tres bien.
J'ai un linksys EA8300 qui a donc le "setup eth0 + eth1" cité ici https://github.com/ubune/openwrt-livebox
J'ai reussi a bypass pas mal d'autres problemes relatives à ce routeur (le CPU à tagger dans le switch VLAN 0t 5t pas affiché par Luci etc...). BREF!
J'ai voulu MAJ vers openwrt 22.03.1 (et comme l'EA8300 possède 2 kernels (+ alt_kernel), je ne fais pas de sysupgrade et reinstall from scratch a chaque fois.
Ca tombe bien nft remplace iptables.
J'ai donc voulu suivre le "nouveau" tuto fait par @ubune et je n'ai pas reussi à obtenir une ipv4 :(
Je trouve le tuto "moins" clair que pour le v19/v21. Surtout pour mon setup eth0 + eth1 et surtout avec le github qui permet de voir les fichiers necessaires complets pour savoir s'il faut laisser les parties de base de openwrt factory.
Serait-il possible de mettre à jour le github, par exemple avec une nouvelle branche. Tout en gardant le mode eth0+eth1 et eth0 only?
Je pense que cela aiderait pas mal de personnes dans mon cas.
Sinon je veux bien poster ma config ici et essayer de voir où se trouve le soucis...
Merci à tous!
hurtauda
-
Hello,
@ubune: est ce que t'as regardé l'option pour passer par le packet scheduler plutôt que par netfilter pour gérer la QOS.
Il s'agit d'adapter ce qui est décrit ici (https://lafibre.info/remplacer-livebox/remplacement-de-la-livebox-par-un-routeur-openwrt-18-dhcp-v4v6-tv/msg972342/#msg972342).
J'ai essayé rapidement mais j'ai vu que le script tc ne semble pas compatible avec openwrt version 22.03 (ce n'est pas le même scheduler par défaut). Et je n'ai pas essayé de le corriger/adapter plus car je n'ai juste pas le temps.
Si quelqu'un a le courage d'y jeter un oeil ce serait cool. Ne serait-ce que pour comparer en terme d'usage CPU en cas de ligne chargée (mes 2 coeurs en VM ne tiennent même pas 10Gbps en local inter-VM).
-
Hello @hurtauda
Yes mettre à jour le Github, c'est prévu, faut que je m'y mette (beaucoup de taff en ce moment).
En + j'ai toujours un Linksys 1200AC et un edgerouterX en 22.03 sur des liens orange...
@Fuli10
Tu voulais dire "Cos" ? :P
Non j'ai pas testé, j'ai pas eu de pb de perf, mais interessé si quelqu'un s'y met ;)
-
I had a email from someone called Stefan related to this thread with ne-pas-repondre@lafibre.info as address, and no PM here, so I cannot answer him.
I will answer here in English, since Stefan is not comfortable with French: I do have an OpenWRT router, but I am not with Orange, so I can’t help with these specific settings.
However, Stefan, if you install OpenWrt 21.02.3, it seems that this tutorial is accurate: https://github.com/ubune/openwrt-livebox
All the Best
-
Hello,
Le client dhcp d’ISC (dhclient) est en fln de vie.
Quel est le client utilisé par OpenWRT ?
L’idée est d’adapter le travail fait ici pour les distrib Linux standards en utilisant le même client dhcp que celui d’OpenWRT.
Merci
-
Quel est le client utilisé par OpenWRT ?
pour l'ipv4 : udhcpc
pour l'ipv6 : odhcp6c
-
Merci.
Qqun pourrait poster le contenu de leurs fichiers de conf respectifs ? (Sans les paramètres confidentiels)
-
Un grand merci pour ce topic et le tutoriel qui m'a permis d'installer sans trop de difficultés mon routeur N5105 avec Proxmox VE.
Le seul petit point sur lequel j'ai dû chercher un peu plus est lié à l'IPV6. Je n'avais pas créé correctement mes forwards et il me manquait aussi cette ligne pour la zone LAN que j'ai retrouvée dans le tuto original (second post) :
option ip6assign '64'
Je pense que ça pourrait utile de remettre cette configuration de la zone LAN dans le tuto mis à jour du premier post.
-
pour l'ipv4 : udhcpc
pour l'ipv6 : odhcp6c
Par défaut, oui.
Il est possible d’utiliser odhcpc en dual stack ainsi que d’autres configurations.
-
Un grand merci pour ce topic et le tutoriel qui m'a permis d'installer sans trop de difficultés mon routeur N5105 avec Proxmox VE.
Le seul petit point sur lequel j'ai dû chercher un peu plus est lié à l'IPV6. Je n'avais pas créé correctement mes forwards et il me manquait aussi cette ligne pour la zone LAN que j'ai retrouvée dans le tuto original (second post) :
option ip6assign '64'
Je pense que ça pourrait utile de remettre cette configuration de la zone LAN dans le tuto mis à jour du premier post.
done :)
config interface 'lan'
option proto 'static'
option ipaddr '192.168.1.1'
option netmask '255.255.255.0'
option ip6assign '64'
option ip6ifaceid '::bad'
option device 'br-lan'
-
Bonjour,
Je rejoins @cyayon car étant un nouveau dans ce domaine (même si j'avais réussi à faire tourner mon Linksys WRT3200ACM sur la WRT 19.07), en particulier sur la dernière version de open WRT (22.03.2), j'ai du mal à savoir si je dois faire un annule et remplace sur les fichiers dhcp, firewall et network ou si je dois ajouter les lignes.
@ubune - quand le temps te le permettra, peux-tu poster les nouveaux fichiers compatibles 22.03 sur github ou ici?
D'avance, merci,
Thomas
-
Salut @ubune et merci pour ce tuto, ca m'a permis de faire tout fonctionner .
Juste deux petites remarques :
1/ Cette partie semble un peu dangereuse
config forwarding #Attention, ici c'est en mode freebox, on autorise le flux wan6 to lan
option src 'wan6'
option dest 'lan'
https://openwrt.org/docs/guide-user/firewall/fw3_configurations/fw3_ipv6_examples
Ca rend dispo tout les ports de toute les machines ipv6 derrière le routeur.
2/ J'ai galéré sur cette partie sur les YY
list dhcp_option '125,00:00:0d:e9:24:04:06:YY:YY:YY:YY:YY:YY:05:0f:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:06:09:4c:69:76:65:62:6f:78:20:34'
Nouveauté pour le nouveau décodeur TV5, l'option 125 est obligatoire, les Y en Orange c'est les 6 octets correspondant à l'adresse mac de votre livebox routeur, et il faut remplacer les XX:XX par votre numéro de série de livebox routeur, après l'avoir converti en Hexa.
Donc comme dit à d'autres endroits il faut prendre les 3 premiers octets de la mac de la box.
ex : votre mac est 11:22:33:44:55:66. vous prenez 112233 et vous convertissez en texte 31:31:32:32:33:33
Pour les XX , c'est simple vous transformez votre numéro de série de la livebox ..
ex: DM0123456789012 -> 44:4D:30:31:32:33:34:35:36:37:38:39:30:31:32
-
Salut @ubune et merci pour ce tuto, ca m'a permis de faire tout fonctionner .
Juste deux petites remarques :
1/ Cette partie semble un peu dangereuse
config forwarding #Attention, ici c'est en mode freebox, on autorise le flux wan6 to lan
option src 'wan6'
option dest 'lan'
https://openwrt.org/docs/guide-user/firewall/fw3_configurations/fw3_ipv6_examples
Ca rend dispo tout les ports de toute les machines ipv6 derrière le routeur.
Hello, d'ou le message "Attention, ici c'est en mode freebox, on autorise le flux wan6 to lan".
C'est le cas chez Free, mais en effet tu peux choisir de drop tous les flux initiés de l'exterieur par défaut.
Le plus important est de ne pas drop certains messages icmpv6, mais si tu as récupéré le fichier firewall du tuto tu as ce qu'il faut ;)
https://www.rfc-editor.org/rfc/rfc4890#section-4.3.1
Après attention, en ipv6 ce n'est pas pareil qu'en ipv4, déja déviner une adresse globale c'est presque impossible, ensuite grâce aux privacy-extension même quand tu inities une connexion vers l'exterieur ce n'est pas l'ipv6 définitive de ta machine qui est vue coté serveur.
Pour plus d'info sur ipv6, hésite pas à check mes vidéos ici : https://lafibre.info/ipv6/lumiere-sur-ipv6-video/
-
Bonjour,
Je rejoins @cyayon car étant un nouveau dans ce domaine (même si j'avais réussi à faire tourner mon Linksys WRT3200ACM sur la WRT 19.07), en particulier sur la dernière version de open WRT (22.03.2), j'ai du mal à savoir si je dois faire un annule et remplace sur les fichiers dhcp, firewall et network ou si je dois ajouter les lignes.
@ubune - quand le temps te le permettra, peux-tu poster les nouveaux fichiers compatibles 22.03 sur github ou ici?
D'avance, merci,
Thomas
Hello,
C'est upload sur Github ;)
-
- De votre option 90 générée grâce au script de kgersen.
- De configurer l'interface Wan en utilisant le VLAN 832 en dhcp => /etc/config/network
- D'envoyer les bonnes options dhcp permettant l'authentification auprès d'orange => /etc/config/network
- D'envoyer tout le flux qui ne passe pas par nftables en priorité L2 (802.1p) CS6 => /etc/config/network (egress mapping)
- Gérer les files pour éviter les pbs de débit (on remet bien notre traffic internet avec des priorités cohérentes) => /etc/rc.local (nft rules)
C'est pas un peu "crade" d'envoyer tout le trafic en priorité 6 puis de devoir faire un "mangle_postrouting" via nftables pour éviter le problème de débit en upload ?
Je me pose la question car avant d'acheter un BananaPi R3, je ne voudrais pas faire l'erreur que son Quad-Core ARMv8 Cortex A53 ne supporte pas la charge dû au changement de priorité.
-
Le problème c'est pour le dhcp. Comme pour envoyer les requêtes dhcp sans IP sur l'interface, le client passe par une socket RAW. Ces paquets ne passent pas par les nftables. Du coup il n'est pas possible de changer la priorité, du coup c'est envoyé avec la priorité 0.
C'est pour ça qu'il y a la règle nftable pour tout passer en priorité autre, sauf les paquets DHCP qui ne passent pas par socket RAW. Ensuite c'est (de ce que j'ai compris) le HW de la carte reseau qui applique la règle priorité 0 (raw socket et dhcp) vers 6 et de priorité 1 (tout le reste via nftable) vers 0.
C'est pour ça que je voulais tester si c'est HW ou SW, en utilisant les filtres avec tc et d'intégrer ça proprement dans openwrt, mais je n'ai pas eu le temps.
-
Le problème c'est pour le dhcp. Comme pour envoyer les requêtes dhcp sans IP sur l'interface, le client passe par une socket RAW. Ces paquets ne passent pas par les nftables. Du coup il n'est pas possible de changer la priorité, du coup c'est envoyé avec la priorité 0.
C'est pour ça qu'il y a la règle nftable pour tout passer en priorité autre, sauf les paquets DHCP qui ne passent pas par socket RAW. Ensuite c'est (de ce que j'ai compris) le HW de la carte reseau qui applique la règle priorité 0 (raw socket et dhcp) vers 6 et de priorité 1 (tout le reste via nftable) vers 0.
C'est pour ça que je voulais tester si c'est HW ou SW, en utilisant les filtres avec tc et d'intégrer ça proprement dans openwrt, mais je n'ai pas eu le temps.
J'ai testé en egress avec seulement "0:0 & 6:6" mais dans Wireshark elle reste à 0, alors que un egress "0:0 & 0:6" modifie bien la priorité en 6.
J'ai essayé avec le script tc mais ça n'a pas l'air de fonctionner...
-
J'ai testé en egress avec seulement "0:0 & 6:6" mais dans Wireshark elle reste à 0, alors que un egress "0:0 & 0:6" modifie bien la priorité en 6.
J'ai essayé avec le script tc mais ça n'a pas l'air de fonctionner...
Oui ben dhcp sort en 0, et nftable ne peut rien faire dessus. Et oui le script tc est à changer car entre temps il y a eu pas mal de changement dans la définition des règles dans openwrt 22 pour que le tc du script fonctionne encore avec. Je crois que c'est le passage a sqm par défaut qui fait que ça ne marche plus. Faudrait le revoir complètement.
-
En fait je posais ces questions car imaginons un jour ils (Orange) mettent une config avec un SIP serveur, mais que ce dernier doit être atteint avec une COS 5 sur le même segment (VID 832) on fera comment ?
-
Le client SIP a besoin de packet RAW? Si non alors nftables. Si oui, pas le choix, faudra trouver le moyen de configurer tc filter.
-
J'ai un souci que je n'arrive pas à cerner sur ma VM OpenWRT (sur NUC N5105). J'ai aucun package custo installé, c'est quasi 100 % le tuto. J'ai juste un Adguard en upstream hosté sur un container LXC.
Il est dans une VM virtualisée sur Proxmox et de manière aléatoire, après 24 à 72 heures, la VM ne répond plus et CPU passe à 100% sur proxmox.
J'ai essayé de rebooter une fois par jour la nuit, pas de différence. J'ai regardé si ça correspondait à une expiration de bail DHCP Orange, pas de rapport non plus.
J'ai extrait les logs avec rsyslog sur mon NAS, j'ai essayé de faire des top réguliers ou juste avant que ça pète, tout est à 0. Rien dans le journal ou le dmesg du OpenWRT avant que ça crash.
Je ne suis pas sûr que ça soit le CPU de la VM elle-même mais ça pourrait être aussi un problème d'IO sur la VM, ça fait aussi 100 % si je simule des IO via stress sur la VM OpenWRT. Pas de prob de température sur le NUC lui-même. Juste un doute sur le M2 qui indique des erreurs dans smartd mais visiblement c'est "courant".
J'ai cherché plein de trucs. J'ai vu qu'il y avait un bug dans dnsmasq qui pouvait le faire monter à 100 % de CPU si pas de réponse de l'upstream. J'ai mis exprès une version plus récente et non, ça ne semble pas venir de ça non plus...
Dès que l'OpenWRT part en sucette, tout le réseau tombe. Le seul workaround que j'ai, c'est de monitorer le CPU de la VM sur Proxmox via l'API et de stop/start la VM dès que le CPU > 80 %. La VM et Internet remontent en 30 secondes.
J'ai un autre container LXC qui n'a aucun problème et le Proxmox lui-même est bien stable. Juste cette VM OpenWRT qui déconnne périodiquement. :-/
Si jamais ça parle à quelqu'un...
-
En fait je posais ces questions car imaginons un jour ils (Orange) mettent une config avec un SIP serveur, mais que ce dernier doit être atteint avec une COS 5 sur le même segment (VID 832) on fera comment ?
Hello,
Sip est un protocole applicatif, ça passe dans NFT donc il suffirait de faire une règle comme celle presente dans le tuto.
Exemple : oifname "eth0.832" udp dport 3060 counter meta priority set 0:5
Attention également, ne pas confondre priorité L2 (cos) et L3 (dscp).
Chez Orange par exemple, seul la priorité L2 est requise, pourtant par défaut la livebox modifie également le dscp.
A+
-
J'ai un souci que je n'arrive pas à cerner sur ma VM OpenWRT (sur NUC N5105). J'ai aucun package custo installé, c'est quasi 100 % le tuto. J'ai juste un Adguard en upstream hosté sur un container LXC.
Il est dans une VM virtualisée sur Proxmox et de manière aléatoire, après 24 à 72 heures, la VM ne répond plus et CPU passe à 100% sur proxmox.
J'ai essayé de rebooter une fois par jour la nuit, pas de différence. J'ai regardé si ça correspondait à une expiration de bail DHCP Orange, pas de rapport non plus.
J'ai extrait les logs avec rsyslog sur mon NAS, j'ai essayé de faire des top réguliers ou juste avant que ça pète, tout est à 0. Rien dans le journal ou le dmesg du OpenWRT avant que ça crash.
Je ne suis pas sûr que ça soit le CPU de la VM elle-même mais ça pourrait être aussi un problème d'IO sur la VM, ça fait aussi 100 % si je simule des IO via stress sur la VM OpenWRT. Pas de prob de température sur le NUC lui-même. Juste un doute sur le M2 qui indique des erreurs dans smartd mais visiblement c'est "courant".
J'ai cherché plein de trucs. J'ai vu qu'il y avait un bug dans dnsmasq qui pouvait le faire monter à 100 % de CPU si pas de réponse de l'upstream. J'ai mis exprès une version plus récente et non, ça ne semble pas venir de ça non plus...
Dès que l'OpenWRT part en sucette, tout le réseau tombe. Le seul workaround que j'ai, c'est de monitorer le CPU de la VM sur Proxmox via l'API et de stop/start la VM dès que le CPU > 80 %. La VM et Internet remontent en 30 secondes.
J'ai un autre container LXC qui n'a aucun problème et le Proxmox lui-même est bien stable. Juste cette VM OpenWRT qui déconnne périodiquement. :-/
Si jamais ça parle à quelqu'un...
Vraiment curieux comme problème, personnellement j'ai du X86 Esxi avec vm openwrt qui tourne impec depuis un moment.
-
J'ai maj le tuto pour ajouter la partie TV (22.03) + explication.
Le github est à jour également avec au choix : 22.03 Internet uniquement ou 22.03 Internet + TV.
-
Hello,
Sip est un protocole applicatif, ça passe dans NFT donc il suffirait de faire une règle comme celle presente dans le tuto.
Exemple : oifname "eth0.832" udp dport 3060 counter meta priority set 0:5
Attention également, ne pas confondre priorité L2 (cos) et L3 (dscp)**.
Chez Orange par exemple, seul la priorité L2 est requise, pourtant par défaut la livebox modifie également le dscp.
A+
**Ça je l'ai compris au moment où j'ai refais une capture sans le tag du VLAN dans l'option -i de tcpdump.
Par contre la règle nftables que tu indiques pour l'exemple du SIP ne modifiera pas la priorité, si ? J'ai cru comprendre que seul le réglage du egress mapping dans le VLAN faisait ça.
Est ce que tu penses qu'un tel SoC pourra gérer cette manipulation : https://www.mediatek.com/products/home-networking/mediatek-filogic-830 (https://www.mediatek.com/products/home-networking/mediatek-filogic-830)
-
**Ça je l'ai compris au moment où j'ai refais une capture sans le tag du VLAN dans l'option -i de tcpdump.
Par contre la règle nftables que tu indiques pour l'exemple du SIP ne modifiera pas la priorité, si ? J'ai cru comprendre que seul le réglage du egress mapping dans le VLAN faisait ça.
Est ce que tu penses qu'un tel SoC pourra gérer cette manipulation : https://www.mediatek.com/products/home-networking/mediatek-filogic-830 (https://www.mediatek.com/products/home-networking/mediatek-filogic-830)
Pour résumer,
on mappe en prio 6 sur l'egress de l'interface, car ici ça va agir sur tous les flux (même le dhcp).
On se sert de NFTtables pour remettre des priorités cohérente, lui agit sur tous les flux SAUF la première requete dhcp. (ça passe bien par nft en renew, cf screenshot).
Donc si, la règle UDP port 3060 fonctionnera, tu peux tester facilement et vérifier avec un tcpdump.
En faite la règle dport67 est necessaire, mais seulement pour le renew ! qui lui passe bien par fw3/fw4.
cf screenshot
-
config device
option name 'eth0.832'
option type '8021q'
option ifname 'eth0'
option vid '832'
list egress_qos_mapping '0:0'
list egress_qos_mapping '2:2'
list egress_qos_mapping '3:3'
list egress_qos_mapping '4:4'
list egress_qos_mapping '5:5'
list egress_qos_mapping '6:6'
list egress_qos_mapping '7:7'
list egress_qos_mapping '1:0'
list egress_qos_mapping '0:6'
Tu as deux entrees list egress_qos_mapping '0: (1ere et dernière ligne), c'est volontaire ?
FYI à mon sens, mettre icmpv4 en CoS 6 n'est pas utile (icmpv4 n'est pas utilisé pour la comm avec le BNG).
C'est même potentiellement déléraire, car faire passer imcpv4 dans la CoS 6 va potentiellement compter dans le rate limiting de CoS 6 fait par l'OLT/BNG (et diminuer la capacité du BNG de filtrer le traffic en fonction des priorités).
-
Tu as deux entrees list egress_qos_mapping '0: (1ere et dernière ligne), c'est volontaire ?
FYI à mon sens, mettre icmpv4 en CoS 6 n'est pas utile (icmpv4 n'est pas utilisé pour la comm avec le BNG).
C'est même potentiellement déléraire, car faire passer imcpv4 dans la CoS 6 va potentiellement compter dans le rate limiting de CoS 6 fait par l'OLT/BNG (et diminuer la capacité du BNG de filtrer le traffic en fonction des priorités).
Perso j'utilise que ça pour le WAN:
config device
option name 'eth0.832'
option type '8021q'
option ifname 'eth0'
option vid '832'
list egress_qos_mapping '1:0'
list egress_qos_mapping '0:6'
list egress_qos_mapping '6:6'
Ce qui n'est pas passé par nftable (donc dhcp) et donc reste en priorité 0 est sorti en priorité 6 "0:6".
Ce qui est passé par nftable et est déjà marqué priorité 6 (dhcp mais pas les paquets raw) est laissé en priorité 6 "6:6".
Ce qui est passé par nftable et mis en priorité 1 (tout le reste pas raw socket) est sorti en priorité 0 "1:0".
-
Tu as deux entrees list egress_qos_mapping '0: (1ere et dernière ligne), c'est volontaire ?
FYI à mon sens, mettre icmpv4 en CoS 6 n'est pas utile (icmpv4 n'est pas utilisé pour la comm avec le BNG).
C'est même potentiellement déléraire, car faire passer imcpv4 dans la CoS 6 va potentiellement compter dans le rate limiting de CoS 6 fait par l'OLT/BNG (et diminuer la capacité du BNG de filtrer le traffic en fonction des priorités).
Pour l'icmp Il me semble que c'était pour reproduire le comportement de la livebox nn ?
Perso j'utilise que ça pour le WAN:
config device
option name 'eth0.832'
option type '8021q'
option ifname 'eth0'
option vid '832'
list egress_qos_mapping '1:0'
list egress_qos_mapping '0:6'
list egress_qos_mapping '6:6'
Ce qui n'est pas passé par nftable (donc dhcp) et donc reste en priorité 0 est sorti en priorité 6 "0:6".
Ce qui est passé par nftable et est déjà marqué priorité 6 (dhcp mais pas les paquets raw) est laissé en priorité 6 "6:6".
Ce qui est passé par nftable et mis en priorité 1 (tout le reste pas raw socket) est sorti en priorité 0 "1:0".
Oui, tes trois lignes sont bien présentes dans le network du tuto, en effet on pourrait supprimer le reste.
-
root@OpenWrt:~# udhcpc -p /var/run/udhcpc-eth1.832.pid -t 0 -i eth1.832 -x hostname:OpenWrt -V sagem -C -B -R -O 1 -O 15 -O 28 -O 51 -O 58 -O 59 -O 90 -x 77:2b46535644534c5f6c697665626f782e496e7465726e65742e736f66746174686f6d652e4c697665626f7834 -x 90:XXX
XXX transformé avec https://jsfiddle.net/kgersen/3mnsc6wy/
udhcpc: started, v1.33.2
udhcpc: sending discover
udhcpc: sending select for 172.16.54.215
:'( :'( :'( :'(
-
> -x hostname:OpenWrt
si tu enlèves ca, ca aide ?
-
J'ai ca dans mon fichier /etc/config/network, au cas où :
# ip6 WAN
config interface 'wan6'
option device 'eth4.832'
option proto 'dhcpv6'
option force_link '1'
option norelease '1'
option reqprefix 'auto'
option reqaddress 'none'
option defaultreqopts '0'
option sendopts '11:00000000000000000000001a0900000<redacted> 15:FSVDSL_livebox.Internet.softathome.livebox3 16:0000040e0005736167656d'
option reqopts '11 17 23 24'
option mtu '1500'
# ip4 WAN
config interface 'wan4'
option device 'eth4.832'
option proto 'dhcp'
option force_link '1'
option broadcast '1'
option vendorid 'sagem'
option sendopts '0x4d:2b46535644534c5f6c697665626f782e496e7465726e65742e736f66746174686f6d652e4c697665626f7833 0x5a:00000000000000000000001a<redacted> 0x3d:01a43e5109537d'
option reqopts '1 3 6 15 28 51 58 59 90 119 120 125'
option mtu '1500'
-
Pour l'icmp Il me semble que c'était pour reproduire le comportement de la livebox nn ?
Ah, la livebox fait ca ? Ok, je savais pas. Ceci dit, levieuxatorange semble lui aussi dire qu'icmpv4 n'est pas à mettre en CoS6 :
La COS6 sert à prioriser les pkts DHCP(4/6), ARP et ICMP NS/NA entre la boxe et la BNG (premier routeur qui gère les IPs) qui gère le contexte client.
-
Bon, j'ai repris cette solution là (https://lafibre.info/remplacer-livebox/remplacement-de-la-livebox-par-un-routeur-openwrt-18-dhcp-v4v6-tv/msg972342/#msg972342) telle que, et j'ai enfin compris ce qui déconnait.
Tout d'abord, il faut absolument installer les packages tc-tiny (pour avoir la commande 'tc') ainsi que kmod-sched (pour avoir le qdisc 'prio'). Si on oubli le module kmod-sched, on se retrouve avec une erreur abscons de 'tc' dès la première commande.
Ensuite, j'ai un problème d'ordre: je ne sais pas pourquoi mais au ifup, le script tc se lance après le dhcp. Du coup ça ne récupère pas une IP correcte. Faut que je relance juste l'interface et c'est bueno. Un peu relou.
Bref, ça marchotte.
Et sinon en terme de perf CPU, j'ai à peu près pareil. Le CPU est chargé d'IRQ tout autant et j'arrive à 50% de charge (sur 2 coeurs) lorsque je charge la ligne à 2.2Gbps.
-
J'ai ca dans mon fichier /etc/config/network, au cas où :
# ip6 WAN
config interface 'wan6'
option device 'eth4.832'
option proto 'dhcpv6'
option force_link '1'
option norelease '1'
option reqprefix 'auto'
option reqaddress 'none'
option defaultreqopts '0'
option sendopts '11:00000000000000000000001a0900000<redacted> 15:FSVDSL_livebox.Internet.softathome.livebox3 16:0000040e0005736167656d'
option reqopts '11 17 23 24'
option mtu '1500'
# ip4 WAN
config interface 'wan4'
option device 'eth4.832'
option proto 'dhcp'
option force_link '1'
option broadcast '1'
option vendorid 'sagem'
option sendopts '0x4d:2b46535644534c5f6c697665626f782e496e7465726e65742e736f66746174686f6d652e4c697665626f7833 0x5a:00000000000000000000001a<redacted> 0x3d:01a43e5109537d'
option reqopts '1 3 6 15 28 51 58 59 90 119 120 125'
option mtu '1500'
Merci beaucoup depuis le durcissement de l'option 90 je n'arrivais pas à me connecter.
Et il me manquait l'option 61 qui représente 01+ mac adresse de la livebox
cette option 61 n'est pas mentionné dans le tuto en page de garde !
Voici ma conf livebox PRO 1G/1G :
config interface 'wan'
option proto 'dhcp'
option device 'eth1.832'
option vendorid 'sagem'
option reqopts '1 15 28 51 58 59 90'
option sendopts '77:2b46535644534c5f6c697665626f782e496e7465726e65742e736f66746174686f6d652e4c697665626f7834 90:XXX 61:01YYY'
option broadcast '1'
-
Cool, c'est top que ca remarche.
Ma conf date un peu... je l'avais écrite en ~2017-2018 en sniffant la Livebox (4). J'avais tenté de faire en sorte que mes requêtes collent bit à bit à celles de la box, et ca nous avait permis à l'époque d'obtenir un /56 IPv6 (de mémoire, ubune avait déjà fait le taf pour l'IPv4).
Il est bien possible qu'avec un firmare récent, une Livebox 4 n'envoie pas ces options :-) Si quelqu'un avec une livebox à jour se sent de comparer, be my guest.
-
Merci beaucoup depuis le durcissement de l'option 90 je n'arrivais pas à me connecter.
Et il me manquait l'option 61 qui représente 01+ mac adresse de la livebox
cette option 61 n'est pas mentionné dans le tuto en page de garde !
Cette option 61 n'a (jusqu'à preuve du contraire), jamais été necessaire pour s'authentifier, tu es sûr que ton problème était à ce niveau ?
-
Bon, j'ai repris cette solution là (https://lafibre.info/remplacer-livebox/remplacement-de-la-livebox-par-un-routeur-openwrt-18-dhcp-v4v6-tv/msg972342/#msg972342) telle que, et j'ai enfin compris ce qui déconnait.
Tout d'abord, il faut absolument installer les packages tc-tiny (pour avoir la commande 'tc') ainsi que kmod-sched (pour avoir le qdisc 'prio'). Si on oubli le module kmod-sched, on se retrouve avec une erreur abscons de 'tc' dès la première commande.
Ensuite, j'ai un problème d'ordre: je ne sais pas pourquoi mais au ifup, le script tc se lance après le dhcp. Du coup ça ne récupère pas une IP correcte. Faut que je relance juste l'interface et c'est bueno. Un peu relou.
Bref, ça marchotte.
Et sinon en terme de perf CPU, j'ai à peu près pareil. Le CPU est chargé d'IRQ tout autant et j'arrive à 50% de charge (sur 2 coeurs) lorsque je charge la ligne à 2.2Gbps.
Top merci pour le retour.
Par contre si on gagne pas en perf et que ça necessite d'installer des paquets supplémentaires c'est dommage.
Ce qui est cool en 22.03 c'est l'import du /etc github editez/remplacez et hop ça fonctionne au prochain boot.
-
Cette option 61 n'a (jusqu'à preuve du contraire), jamais été necessaire pour s'authentifier, tu es sûr que ton problème était à ce niveau ?
Confirmé par LeVieux dans le thread sur l'Option 90:
L'option 61 est nécessaire (RFC). Elle peut par contre contenir la MAC de ton routeur.
Il faut qu'elle soit présente
C'est en déploiement chez eux, ca va devenir nécessaire partout progressivement.
-
Bonjour,
Malgré avoir lu vos commentaires sur la nouvelle gestion des vlans en version 21.xx, j'ai tenté de passer mon install depuis 19.07.x et j'ai rien compris.
J'ai compris que mettre ethX.832 crérait implicitement un device taggué sur le vlan 832.
J'ai un linksys WRT32X avec "normalement" 2 CPU (eth0 pour le LAN et eth1 pour le WAN). Sur 21.xx, il n'y a plus de trace de eth1.
J'ai donc configuré wan et wan6 sur eth0.832, mais rien ne fonctionne.
J'ai retourné le tuto de Ubune dans tous les sens. Lors de ma 1ère installation en 2020, je suivais le tuto sans presque rien comprendre.
Aujourd'hui, je comprends tout, mais même avec ça, la conf ne fonctionne pas. Du coup, je suis revenu en 19.07.8.
Avant, je ne travaillais qu'avec Luci, aujourd'hui, je me sens + à l'aise avec la cli ou la conf textuelle...
Extrêmement déçu parce que je bloque sur la nouvelle gestion des vlans qui pourtant a l'air d'être "conforme" à la norme "DSA".
Est ce que quelqu'un peut être + explicite et m'expliquer quoi faire dans mon cas ?
Thx
Edit : Sur ma config en 19.07.8 je vois bien que le wan est configuré sur l'interface eth1.832 (fonctionne parfaitement) :
(https://i.imgur.com/tQc3T9j.png)
Salut à tous, finalement, à l'époque j'étais revenu en 19.07.8 parce que la gestion des vlans sur OpenWRT 21 était simplement horrible pour moi.
@ubune, j'ai vu ta maj pour 22.03, beaucoup plus simple, et le github qui m'a permis de modifier ma conf (from scratch) de façon incrémentale.
Alors, actuellement ça fonctionne, Internet, VPN ok
ifstatus wan4 | jsonfilter -e '@["ipv4-address"][0].address'
# retourne bien mon @IP_PUB actuellement
Cependant, je n'ose plus rebooter mon routeur ou toucher au network parce que je constate un phénomène que je n'explique pas
Au reboot, la commande ci-dessus me retourne une IP privée (je pense de l'ONT en 172.16.x.x/16) et reste en l'état indéfiniment
Au bout du 3-4e reboot de l'ONT ou suite aux multiples /etc/init.d/network restart, je récupère l'IP publique
J'ai aussi remarqué, qu'il me fallait que mon device "wan" soit activé en configuration, en fait, je cherche l'explication du pourquoi je récupère l'IP PUB à un moment après les réinitialisations des interfaces ou pas ...
Si tu as une idée parce que j'aime comprendre
-
Bonjour,
Suite au durcissement des contrôles des options DHCP je n’arrive plus à obtenir d’IPv6 sur mon router OpenWRT.
J’ai réussi à récupérer une IPv4 publique en complétant les options DHCP.
Cependant en complétant les options dhcpv6 ca ne fonctionne toujours pas (avant l’activation du durcissement l’IPv6 fonctionnait et maintenant plus rien).
Dans le fils https://lafibre.info/remplacer-livebox/durcissement-du-controle-de-loption-9011-et-de-la-conformite-protocolaire/ il est indiqué qu’il faut rajouter l’option 1 (fait). L’option 11 est complète et identique à l’option 90 en IPv4.
config interface 'wan6'
option proto 'dhcpv6'
option device 'eth1.832'
option reqprefix 'auto'
option reqaddress 'none'
option defaultreqopts '0'
option sendopts '11:<option 11 identique que pour l’IPv4> 15:FSVDSL_livebox.Internet.softathome.livebox4 16:0000040e0005736167656d 1:00030001<mac du routeur identique que l’option 61 pour l’IPv4>'
option reqopts '11 17 23 24'
option noclientfqdn '1'
option noacceptreconfig '1'
option peerdns '0'
26: eth1.832@eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000
link/ether 00:**:**:**:**:** brd ff:ff:ff:ff:ff:ff
inet 86.**.**.**/21 brd 86.**.**.255 scope global eth1.832
valid_lft forever preferred_lft forever
inet6 fe80::**:**:**:**/64 scope link
valid_lft forever preferred_lft forever
Merci d’avance pour votre aide.
-
Il doit y avoir non compréhension dans les termes utilisés car tu ne reçois pas une IPv6 mais un prefix.
A toi de t'allouer une IPv6 dans le /56 reçu.
-
26: eth1.832@eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000
link/ether 00:**:**:**:**:** brd ff:ff:ff:ff:ff:ff
inet 86.**.**.**/21 brd 86.**.**.255 scope global eth1.832
valid_lft forever preferred_lft forever
inet6 fe80::**:**:**:**/64 scope link
valid_lft forever preferred_lft forever
En as tu une sur br0 ? peux tu poster un ip addr show complet ?
-
Confirmé par LeVieux dans le thread sur l'Option 90:
C'est en déploiement chez eux, ca va devenir nécessaire partout progressivement.
J'ai basculé chez moi, envoi des options client identifier, 61 (ipv4 = mac en hexa) et 1 (ipv6 = mac mais aussi le duid), et ajout des options en request pour correspondre à ce que demande la box.
J'avais encore un dump de ma box donc je ne me suis pas embeté j'ai envoyé la même chose.
Mais en faite la box envoi en option 61 ipv4 : 01+ la mac SANS les ":"
Pour l'option 1 (ipv6) prefixe 00030001+ la mac SANS les ":"
Je maj le tuto/github
ps : l'option 61 (ipv4) et 1 (ipv6) "client identifier", sont également configurables via l'interface web openwrt :
-
Bonjour,
Suite au durcissement des contrôles des options DHCP je n’arrive plus à obtenir d’IPv6 sur mon router OpenWRT.
J’ai réussi à récupérer une IPv4 publique en complétant les options DHCP.
Cependant en complétant les options dhcpv6 ca ne fonctionne toujours pas (avant l’activation du durcissement l’IPv6 fonctionnait et maintenant plus rien).
Dans le fils https://lafibre.info/remplacer-livebox/durcissement-du-controle-de-loption-9011-et-de-la-conformite-protocolaire/ il est indiqué qu’il faut rajouter l’option 1 (fait). L’option 11 est complète et identique à l’option 90 en IPv4.
config interface 'wan6'
option proto 'dhcpv6'
option device 'eth1.832'
option reqprefix 'auto'
option reqaddress 'none'
option defaultreqopts '0'
option sendopts '11:<option 11 identique que pour l’IPv4> 15:FSVDSL_livebox.Internet.softathome.livebox4 16:0000040e0005736167656d 1:00030001<mac du routeur identique que l’option 61 pour l’IPv4>'
option reqopts '11 17 23 24'
option noclientfqdn '1'
option noacceptreconfig '1'
option peerdns '0'
26: eth1.832@eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000
link/ether 00:**:**:**:**:** brd ff:ff:ff:ff:ff:ff
inet 86.**.**.**/21 brd 86.**.**.255 scope global eth1.832
valid_lft forever preferred_lft forever
inet6 fe80::**:**:**:**/64 scope link
valid_lft forever preferred_lft forever
Merci d’avance pour votre aide.
Peux-tu ajouter l'option 1 comme dit dans le post précédent (avec option clientid 'XXX' plutot que l'ajout dans le sendopts) et nous faire un retour ?
Le wan6 du tuto :
config interface 'wan6'
option proto 'dhcpv6'
option device 'eth0.832'
option reqprefix 'auto'
option reqaddress 'none'
option defaultreqopts '0'
option sendopts '11:00000000000000000000001a090000055801034101116674692F6674692F717071383838383c1231323334353637383930313233343536031341302f6f2d83fc857d7829d65ddea775d7 15:FSVDSL_livebox.Internet.softathome.livebox4 16:0000040e0005736167656d'
option reqopts '11 17 23 24'
option noclientfqdn '1'
option noacceptreconfig '1'
option clientid '00030001MACLIVEBOX' correspond au DUID envoyé par la box = au prefixe 00030001+ la mac sans les :
Merci
-
Salut à tous, finalement, à l'époque j'étais revenu en 19.07.8 parce que la gestion des vlans sur OpenWRT 21 était simplement horrible pour moi.
@ubune, j'ai vu ta maj pour 22.03, beaucoup plus simple, et le github qui m'a permis de modifier ma conf (from scratch) de façon incrémentale.
Alors, actuellement ça fonctionne, Internet, VPN ok
ifstatus wan4 | jsonfilter -e '@["ipv4-address"][0].address'
# retourne bien mon @IP_PUB actuellement
Cependant, je n'ose plus rebooter mon routeur ou toucher au network parce que je constate un phénomène que je n'explique pas
Au reboot, la commande ci-dessus me retourne une IP privée (je pense de l'ONT en 172.16.x.x/16) et reste en l'état indéfiniment
Au bout du 3-4e reboot de l'ONT ou suite aux multiples /etc/init.d/network restart, je récupère l'IP publique
J'ai aussi remarqué, qu'il me fallait que mon device "wan" soit activé en configuration, en fait, je cherche l'explication du pourquoi je récupère l'IP PUB à un moment après les réinitialisations des interfaces ou pas ...
Si tu as une idée parce que j'aime comprendre
Si tu obtiens l'ip privée c'est mauvaise auth et/ou cos, mais vue que ça marche après quelques restart network je pencherai sur un problème de COS.
Comment load tu les rules NFT ?
Pendant que tu récupères l'ip priv, faudrait un dump pour analyser et p-e confirmer :
tcpdump -nei eth0 port 67 or port 68 or port 546 or port 547 -w dhcp.pcap
-
@jh67 oui en effet, je ne recois plus le prefix
@simon cf ci-dessous le résultat de la commande ip a@ubune toujours pas de prefix :S
config interface 'wan'
option proto 'dhcp'
option device 'eth1.832'
option hostname '*'
option broadcast '1'
option norelease '1'
option vendorid 'sagem'
option reqopts '1 15 28 51 58 59 90'
option sendopts '77:2b46535644534c5f6c697665626f782e496e7465726e65742e736f66746174686f6d652e4c697665626f7834 90:00000000000000000000001<OPTION90> 61:01<@MAC au format xxxxxxxxxxxx'
option peerdns '0'
option dns '8.8.4.4 8.8.8.8'
config interface 'wan6'
option proto 'dhcpv6'
option device 'eth1.832'
option reqprefix 'auto'
option reqaddress 'none'
option defaultreqopts '0'
option sendopts '11:00000000000000000000001<Même valeur que pour l’option 90> 15:FSVDSL_livebox.Internet.softathome.livebox4 16:0000040e0005736167656d'
option reqopts '11 17 23 24'
option noclientfqdn '1'
option noacceptreconfig '1'
option clientid '00030001<@MAC au format xxxxxxxxxxxx'
puis
ifdown wan6
ifup wan6
ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
link/ether 00:**:**:**:**:** brd ff:ff:ff:ff:ff:ff
inet 192.168.0.1/24 brd 192.168.0.255 scope global eth0
valid_lft forever preferred_lft forever
inet6 2a01:**:**:**::1/60 scope global dynamic noprefixroute
valid_lft 604798sec preferred_lft 604798sec
inet6 fd5a:937b:5820::1/60 scope global noprefixroute
valid_lft forever preferred_lft forever
inet6 fe80::20d:**:**:**/64 scope link
valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
link/ether 00:**:**:**:**:** brd ff:ff:ff:ff:ff:ff
inet6 fe80::20d:**:**:**/64 scope link
valid_lft forever preferred_lft forever
4: eth2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
link/ether 00:**:**:**:**:** brd ff:ff:ff:ff:ff:ff
27: eth1.832@eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000
link/ether 00:**:**:**:**:** brd ff:ff:ff:ff:ff:ff
inet 86.**.**.**/21 brd 86.**.**.255 scope global eth1.832
valid_lft forever preferred_lft forever
inet6 fe80::20d:**:**:**/64 scope link
valid_lft forever preferred_lft forever
-
Peux-tu faire un
tcpdump -nei eth1 -s 0 -w dhcp.pcapQuand la capture tourne : ifdown/ifup wan4 et wan6
Stop la capture 10sec après les ifup
Puis m'envoyer ton pcap en mp ?
-
@ubune merci pour ton aide :). Il semble qu'il me reste encore beaucoup de choses à apprendre sur l'IPv6.
Je suis resté concentré sur l'interface eth1 qui n'affiche pas de prefix ou d'addresse IPv6.
Cependant l'interface locale eth0 a bien récupéré une adresse IPv6 et je n'y avais pas fait attention.
L'une des dernières manipulation m'a permis de récupérer la connectivité IPv6.
Les questions que je me pose maintenant:
* Sur l'interface web LuCi je vois bien le préfix IPv6-PD: 2a01:**:**:**::/56 au niveau de l'interface wan6 (eth1.832). Comment puis-je retrouver cette information en ligne de commande (j'étais persuadé que celle-ci était visible en faisant un ip a)?
* Pourquoi il n'y a pas d'IPv6 attribuée sur l'interface publique eth1 alors qu'il y en a une sur l'interface locale eth0
-
Les questions que je me pose maintenant:
* Sur l'interface web LuCi je vois bien le préfix IPv6-PD: 2a01:**:**:**::/56 au niveau de l'interface wan6 (eth1.832). Comment puis-je retrouver cette information en ligne de commande (j'étais persuadé que celle-ci était visible en faisant un ip a)?
ifstatus wan6 | jsonfilter -e '@["ipv6-prefix"][0].address'
ifstatus wan6 | jsonfilter -e '@["ipv6-prefix"][0].mask'* Pourquoi il n'y a pas d'IPv6 attribuée sur l'interface publique eth1 alors qu'il y en a une sur l'interface locale eth0
Car ce n'est absolument pas necessaire, c'est l'adresse link-local qui est utilisée pour le routage vers Orange, qui elle est bien visible si tu fais :
ip -6 a | grep eth1.832 -A 1
Si tu veux des infos sur ipv6, n'hésite pas à check mes vidéos ici : https://lafibre.info/ipv6/lumiere-sur-ipv6-video/
-
ip a
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
link/ether 00:**:**:**:**:** brd ff:ff:ff:ff:ff:ff
inet 192.168.0.1/24 brd 192.168.0.255 scope global eth0
valid_lft forever preferred_lft forever
inet6 2a01:**:**:**::1/60 scope global dynamic noprefixroute
valid_lft 604798sec preferred_lft 604798sec
inet6 fd5a:937b:5820::1/60 scope global noprefixroute
valid_lft forever preferred_lft forever
inet6 fe80::20d:**:**:**/64 scope link
valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
link/ether 00:**:**:**:**:** brd ff:ff:ff:ff:ff:ff
inet6 fe80::20d:**:**:**/64 scope link
valid_lft forever preferred_lft forever
4: eth2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
link/ether 00:**:**:**:**:** brd ff:ff:ff:ff:ff:ff
27: eth1.832@eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000
link/ether 00:**:**:**:**:** brd ff:ff:ff:ff:ff:ff
inet 86.**.**.**/21 brd 86.**.**.255 scope global eth1.832
valid_lft forever preferred_lft forever
inet6 fe80::20d:**:**:**/64 scope link
valid_lft forever preferred_lft forever
Comme tu as pu le constater, tu as une connectivité IPv6, et une adresse est configurée sur eth0. Le préfixe /60 semble étrange, ca devrait être /64 normalement.
Si tu n'as rien fait de volontaire pour avoir un /60 sur eth0, je te conseille de revoir la conf. Peut-on voir la conf d'eth0 dans /etc/config/network ? Si tu as option ip6assign '60', tu devrais le mettre à 64.
-
Il n'a pas du modifier la configuration, en effet par défaut l'interface LAN sur openwrt est en /60 :
option ip6assign '60'
Tu devrais avoir un lan comme dans la page 1 du tuto :
config interface 'lan'
option proto 'static'
option ipaddr '192.168.1.1'
option netmask '255.255.255.0'
option ip6assign '64'
option ip6ifaceid '::bad'
option device 'br-lan'
-
En effet @ubune @simon ip6assign était bien à 60.
* À part consommer des plages d'IP pour rien, y-a-t'il un autre problème à cela?
* Pourquoi remplacer le prefix par par ::bad dans l'option ip6assign?
J'ai appliqué les recommandation de paramétrage d'ubune sur l'interface lan et tout roule.
Merci à vous :)
-
> * Pourquoi remplacer le prefix par par ::bad dans l'option ip6assign?
Pas nécessaire, je suppose que c'est pour le fun et pour que les adresses IPv6 que le routeur attribue à ses propres interfaces soient plus mémorisables.
Je ne l'ai pas et ca ne pose aucun souci.
> J'ai appliqué les recommandation de paramétrage d'ubune sur l'interface lan et tout roule.
Super nouvelle! :)
-
Bonjour à tous,
Pour commencer un grand merci à ubune et au différents contributeurs pour ce magnifique tuto, et pour l'avoir mit au goût du jour avec openwrt 22.03!
M'en étant servi de support à fin de me passer de la livebox il y a quelques années, et suite à plusieurs mises à jour je me suis lancé il y à quelques semaines dans une re-installation propre de la dernière version d'openwrt et ai remarqué une chose:
J'ai toujours eu sur mes différentes interfaces local la configuration "DHCPv6-Service" en "server-mode", il me semble pour pouvoir annoncer mon server DNS (pihole) à mes client en ipv6.
En re-suivant ce guide il y a quelques semaine j'ai remarque qu'il est instruit de ne pas faire de dhcpv6 mais uniquement du RA. Ce qui, il me semble, me ferait perde la possibilité d'annoncer mon pihole en ipv6 et probablement permettre à mes client ipv6 de passer par le DNS de orange (!).
Pour autant je n'ai pas de soucis visible en ipv6, 10/10 sur les sites de test.
Pourriez-vous, s'il vous plait, m'indiquer si il me faudrait absolument passer mes différentes interfaces local en RA uniquement? Si oui, comment pourrais-je annoncer mon server DNS en ipv6 également ?
Merci d'avance!
-
Il est possible d'annoncer des serveurs DNS dans un RA:
RDNSS 2a01:xxxx
-
Bonjour à tous,
Pour commencer un grand merci à ubune et au différents contributeurs pour ce magnifique tuto, et pour l'avoir mit au goût du jour avec openwrt 22.03!
M'en étant servi de support à fin de me passer de la livebox il y a quelques années, et suite à plusieurs mises à jour je me suis lancé il y à quelques semaines dans une re-installation propre de la dernière version d'openwrt et ai remarqué une chose:
J'ai toujours eu sur mes différentes interfaces local la configuration "DHCPv6-Service" en "server-mode", il me semble pour pouvoir annoncer mon server DNS (pihole) à mes client en ipv6.
En re-suivant ce guide il y a quelques semaine j'ai remarque qu'il est instruit de ne pas faire de dhcpv6 mais uniquement du RA. Ce qui, il me semble, me ferait perde la possibilité d'annoncer mon pihole en ipv6 et probablement permettre à mes client ipv6 de passer par le DNS de orange (!).
Pour autant je n'ai pas de soucis visible en ipv6, 10/10 sur les sites de test.
Pourriez-vous, s'il vous plait, m'indiquer si il me faudrait absolument passer mes différentes interfaces local en RA uniquement? Si oui, comment pourrais-je annoncer mon server DNS en ipv6 également ?
Merci d'avance!
Salut Unipo, merci pour ton retour ;)
Aucun inconvenient à utiliser le dhcpv6 en stateless afin d'envoyer des options spécifiques, c'est désactivé dans le tuto car en effet sauf cas précis ce n'est pas nécessaire.
Comme dit dans le post précédent, le serveur DNS est transmit dans le RA (cf screenshot).
Par contre en effet c'est l'ipv6 du routeur openwrt qui est transmise.
Après il suffirait de rediriger les requêtes vers ton pi-hole, mais ta demande c'était p-e pour voir les machines sources sur les logs de ton pi-hole ?
A+
-
Comme dit dans le post précédent, le serveur DNS est transmit dans le RA (cf screenshot).
Par contre en effet c'est l'ipv6 du routeur openwrt qui est transmise.
Après il suffirait de rediriger les requêtes vers ton pi-hole, mais ta demande c'était p-e pour voir les machines sources sur les logs de ton pi-hole ?
On peut configurer quels DNS sont annoncés par l'option RDNSS des router advertisements, pas besoin de DHCP pour ca.
Il faut simplement ajouter la ligne suivante dans la conf de l'interface LAN:
option dns '<IP du pihole ou autre DNS souhaité>'
Si aucune IP n'est spécifiée en conf, par défaut openwrt annonce l'IP GUA de son interface locale.
-
@hj67 @ubune @simon Merci pour vos retours!
Bon bah je mourrai moins bête!
Alors je vais repartir avec ma première idée, annoncer le dns en dhcpv6. Même si j'aime bien ton idée @simon, en faisant de la sorte je perdrai les sources des requêtes dans les logs du pihole (je n'aurai que l'adresse du router en source) comme ce que se doutait @ubune ;D
Mais donc aucune contre-indication d'avoir dhcpv6 en server-mode avec RA en server-mode et SLAAC? Y'a pas de risque de conflit?
-
> Alors je vais repartir avec ma première idée, annoncer le dns en dhcpv6. Même si j'aime bien ton idée @simon, en faisant de la sorte je perdrai les sources des requêtes dans les logs du pihole (je n'aurai que l'adresse du router en source) comme ce que se doutait @ubune
Ah non, on s'est mal compris : si tu configures l'option dns dans la conf de l'interface LAN avec l'adresse de ton pi-hole, le routeur va émettre des router advertisements sur ce LAN qui vont annoncer l'adresse IP du pi-hole comme DNS.
Les machines sur ce LAN vont donc configurer cette adresse IP comme resolveur DNS, et envoyer leurs requêtes DNS à cette adresse IP *avec leur adresse IP source*.
Le routeur ne fait qu'annoncer l'adresse du pi-hole comme DNS, il ne fera pas proxy DNS ou autre intermédiaire. Ton pi-hole verra donc les adresses IP sources des stations, sans souci.
Il n'y a pas de conflit entre RA et DHCPv6 si ils émettent les mêmes infos, mais encore une fois, pour faire ce que tu cherches à faire, DHCPv6 est superflu à mon sens.
-
@ubune
Oooooh, à une époque j'avais un soucis avec le pihole ou les requêtes était relayées par le routeur et dans mes souvenirs c'était cette option qui était coupable, et par le suite j'avais paramétré les DHCP/DHCPv6 pour annoncer le pihole. Ça remonte tellement que je me suis peut-être mélangé les pinceaux ;D
Si selon toi je m'embête pour rien avec le dhcpv6, alors je vais suivre votre idée et garder les choses simple ;D
Encore un grand merci pour avoir pris le temps!
-
Pour l’annonce DNS, il y a même l'option dans luci : Announced DNS servers
Et le DHCPv6 stateless est toujours utile pour les windows antérieurs à 10 2004 (de tête). Car avant il ne supportait pas le RDNSS. MS a sacrément traîné pour l'implémenter.
-
ça tombe bien, le support de la 2004 est terminé depuis 1 an.
-
On peut configurer quels DNS sont annoncés par l'option RDNSS des router advertisements, pas besoin de DHCP pour ca.
Il faut simplement ajouter la ligne suivante dans la conf de l'interface LAN:
option dns '<IP du pihole ou autre DNS souhaité>'
Si aucune IP n'est spécifiée en conf, par défaut openwrt annonce l'IP GUA de son interface locale.
Tout a fait !
Par contre attention, pour préciser c'est l'option "list dns" et ce n'est pas dans la configuration de l'interface lan (/etc/config/network ) mais dans la configuration dhcp de l'interface lan (/etc/config/dhcp) :
Exemple ici d'une configuration annonçant les dns ipv6 de cloudflare :
config dhcp 'lan'
option interface 'lan'
option start '100'
option limit '59'
option leasetime '12h'
option dhcpv4 'server'
option ra 'server'
list ra_flags 'none'
list dns '2606:4700:4700::1111'
-
Bien vu! J'ai lu le wiki trop vite en effet. Je savais qu'il y avait une option, mais je ne l'ai jamais utilisée personnellement car le comportement par défaut (annoncer la GUA configurée sur l'interface locale du routeur) me va bien : je fais tourner un résolveur récursif sur le routeur lui-même.
-
Bien vu! J'ai lu le wiki trop vite en effet. Je savais qu'il y avait une option, mais je ne l'ai jamais utilisée personnellement car le comportement par défaut (annoncer la GUA configurée sur l'interface locale du routeur) me va bien : je fais tourner un résolveur récursif sur le routeur lui-même.
Et en + via l'interface web il faut bien passer par l'interface lan x)
En Web : Edit interface Lan => Onglet "DHCP Server" => Sous-onglet "IPV6 Settings" => Paramètre "Announced IPv6 DNS servers"
-
Du coup en faisant des test (à l'instant).
Je viens de me rendre compte que Mon PC @W11 22H2 ne prend pas le serveur dns via RA
Si je fais un ipconfig /all j'ai aucun serveur DNS ipv6.
Une trace wireshark sur la machine me montre bien que le serveur dns est transmis dans le RA.
Sur Smartphone, Mac OS et Linux sur le même Lan ça fonctionne.
Et donc si j'active le serveur dhcpv6 openwrt sur l'interface Lan, j'ai également configuré le flag RA en "Other Config", (pour obtenir uniquement des options via dhcpv6, pas d'adressage machine), la ça fonctionne également sur Windows 11 (Serveur Dns present sur l'ipconfig).
Quelqu'un peut tester si il a le même cas ?
-
https://learn.microsoft.com/en-us/answers/questions/884756/after-update-from-windows-10-to-windows-11-ipv6-rf.html
Certains ont apparament le même souci et les tests semblent dire que s'il y a soit un serveur DHCPv4 distribuant un DNS, soit un serveur DHCPv6, windows ignore les DNS émis dans le RA.
Par contre, si pas de connectivité IPv4, windows semble tout de même configurer les DNS contenus dans les RA.
Est-ce que tu peux tester de 1) désactiver DHCPv4 totalement (ou simplement la stack IPv4 sur windows) et 2) configurer windows pour qu'il n'utilise pas le DNS obtenu par DHCPv4?
-
Chez moi en 10 21H2, les DNS sont bien pris via les RA et Ipv4 en même temps. Faut que je vérifie avec 11, mais pour le moment c'est en train de MAJ.
Comme on peut le voir, pas de réponse du DHCPv6 :
-
Renaud, tes clients semblent faire des requêtes DHCPv6 qui ne recoivent jamais de réponse. Tu n'aurais pas les flags M ou O dans tes router advertisements ?
-
https://learn.microsoft.com/en-us/answers/questions/884756/after-update-from-windows-10-to-windows-11-ipv6-rf.html
Certains ont apparament le même souci et les tests semblent dire que s'il y a soit un serveur DHCPv4 distribuant un DNS, soit un serveur DHCPv6, windows ignore les DNS émis dans le RA.
Par contre, si pas de connectivité IPv4, windows semble tout de même configurer les DNS contenus dans les RA.
Est-ce que tu peux tester de 1) désactiver DHCPv4 totalement (ou simplement la stack IPv4 sur windows) et 2) configurer windows pour qu'il n'utilise pas le DNS obtenu par DHCPv4?
Yes c'est exactement ça, si je supprime la pile ipv4 du poste le serveur dns appris via RA est tout de suite pris en compte.
-
Renaud, tes clients semblent faire des requêtes DHCPv6 qui ne recoivent jamais de réponse. Tu n'aurais pas les flags M ou O dans tes router advertisements ?
A revérifier mais je crois que les "Windows" font du dhcpv6 sollicit sans même attendre un RA avec flag...
-
Yes c'est exactement ça, si je supprime la pile ipv4 du poste le serveur dns appris via RA est tout de suite pris en compte.
Okay, et si au lieu de désactiver la stack v4, tu mets simplement "Use the following DNS server addresses" dans la conf TCP/IPv4, et que tu laisses les deux champs DNS vides, c'est pareil?
Donc à priori pas besoin de DHCPv6 pour windows 11. Il utilisera les DNS IPv4 si il en a, et celui annoncé par RDNSS si non.
Très étrange ce comportement ceci dit...
-
Okay, et si au lieu de désactiver la stack v4, tu mets simplement "Use the following DNS server addresses" dans la conf TCP/IPv4, et que tu laisses les deux champs DNS vides, c'est pareil?
Donc à priori pas besoin de DHCPv6 pour Windows 11. Il utilisera les DNS IPv4 si il en a, et celui annoncé par RDNSS si non.
Très étrange ce comportement ceci dit...
Si je coche en laissant les dns ipv4 vide, c'est identique à "auto" (après avoir validé, si je retourne dans le menu c'est toujours actif).
Donc même comportement.
-
Si je coche en laissant les dns ipv4 vide, c'est pareil que si je laisse en auto (après avoir validé, si je retourne dans le menu c'est toujours actif).
Donc même comportement.
Whoa, ca pour le coup c'est même plus un comportement étrange, c'est un sacré bug. Je viens de tester dans une VM, c'est pareil sous Win10.
-
Renaud, tes clients semblent faire des requêtes DHCPv6 qui ne recoivent jamais de réponse. Tu n'aurais pas les flags M ou O dans tes router advertisements ?
A revérifier mais je crois que les "Windows" font du dhcpv6 sollicit sans même attendre un RA avec flag...
C'est ce que j'allais dire, c'est windows qui fait ça. Linux n'envoie pas de requête DHCP quand tout est à 0.
-
Je confirme pour 11, je n'ai que le DNS ipv4 si RA only.
Ce n'est pas la 22H2 mais la dernière du canal Dev (25267)
EDIT : ça refonctionne si je réactive le DHCPv6. Chose bizarre, je ne sais pas pourquoi le DHCP lui balance des IP alors qu'il ne devrait pas (réclamées dans le solicit cela dit). Enfin, j'ai remarqué que si elle n'apparaissent pas dans le Reply, elles ne sont pas prises en compte, donc ça va.
-
Okay, donc on confirme que windows 11 préfère les DNS obtenus par DHCP et va même jsuqu'à préférer IPv4 à IPv6 dans le cas où un a un DHCPv4 et un DNS fourni par router advertisement.
Est-ce que dans ton cas, il utilise ton serveur DNS IPv6, ou est-ce qu'il n'envoie en pratique ses requêtes qu'en IPv4?
-
J'ai un souci que je n'arrive pas à cerner sur ma VM OpenWRT (sur NUC N5105). J'ai aucun package custo installé, c'est quasi 100 % le tuto. J'ai juste un Adguard en upstream hosté sur un container LXC.
Il est dans une VM virtualisée sur Proxmox et de manière aléatoire, après 24 à 72 heures, la VM ne répond plus et CPU passe à 100% sur proxmox.
Je me quote au cas où ça arriverait à quelqu'un. Il semble que le problème ne soit pas du côté de la VM OpenWRT mais de Proxmox.
J'ai trouvé pas mal de trucs similaires dans ce thread :
https://forum.proxmox.com/threads/vm-freezes-irregularly.111494/
Pour faire simple, mon problème semble corrigé avec mise à jour du kernel Linux en 5.9 ou la dernière 6.1 + mise à jour du intel microcode.
Details ici: https://forum.proxmox.com/threads/vm-freezes-irregularly.111494/post-519618
J'arrête le HS là-dessus, c'était juste pour apporter une solution si d'autres personnes se retrouvent dans la même situation.
-
Hello,
comment est générée l'option 77 pour DHCPv4 svp ?
option sendopts '77:2b46535644534c5f6c697665626f782e496e7465726e65742e736f66746174686f6d652e4c697665626f7834
edit: ok c'est du text vers de l'hexa.
-
Petite question par rapport au DNS sur OpenWrt à chaque reboot les DNS sautent dans mon resolv.conf sur mon routeur x86.
Est ce que c'est classique ou pas ?
Faut mettre le bit immutable sur le fichier ou y'a une astuce pour la config ?
(Je débute sur OpenWrt, je me fais gentiment la conf 2.5G)
J'ai besoin que le router accède a internet pour les MAJ / opkg.
Config classique, un bridge sur 4 interfaces, et la 5ème qui sera mon WAN.
Pour l'instant je suis connecté sur le routeur via un port du bridge.
-
Petite question par rapport au DNS sur OpenWrt à chaque reboot les DNS sautent dans mon resolv.conf sur mon routeur x86.
Est ce que c'est classique ou pas ?
Faut mettre le bit immutable sur le fichier ou y'a une astuce pour la config ?
(Je débute sur OpenWrt, je me fais gentiment la conf 2.5G)
J'ai besoin que le router accède a internet pour les MAJ / opkg.
Config classique, un bridge sur 4 interfaces, et la 5ème qui sera mon WAN.
Pour l'instant je suis connecté sur le routeur via un port du bridge.
Normal tu dois avoir localhost dans le resolv.conf
C'est dans /etc/config/dhcp que tu dois spécifier le serveur dns ou tu forward.
config dnsmasq
list server ""
ou via l'interface web :
network/dhcp and dns/general settings
Et si tu veux utiliser les serveurs DNS du FAI, il n'y a rien à faire car le paramètre "Use DNS servers advertised by peer" sur l'interface wan est coché par défaut.
-
Top, merci Ubune, c'est plus clair sur le fonctionnement ;D
Concernant les DNS FAI, je ne veux pas les utiliser (sauf pour la TV, car pas le choix, mais je me ferrais une nouvelle interface LAN pour cette partie si besoin)
Est ce que la config dans dnsmasq prévaut sur l'option d'annonce auto par le peer sur l'interface WAN ?
-
Top, merci Ubune, c'est plus clair sur le fonctionnement ;D
Concernant les DNS FAI, je ne veux pas les utiliser (sauf pour la TV, car pas le choix, mais je me ferrais une nouvelle interface LAN pour cette partie si besoin)
Est ce que la config dans dnsmasq prévaut sur l'option d'annonce auto par le peer sur l'interface WAN ?
Décoche le paramètre sur l'interface wan4/wan6 et spéficie un dns personnalisé comme indiqué hier ;).
-
Nikel, merci ;D
edit: encore une question, je vois que sur le bridge il n'y a pas de gateway positionné, cela est normal car les machine sur le LAN prendront par défaut l'IP du bridge comme gateway ?
(actuellement j'ai positionné la gateway de mon routeur actuel, sinon pas d'internet - logique pour le coup)
-
Ubune, n'y aurait-il pas une erreur dans la conf entre ici et ton git au niveau des zone wan et wan6 dans la conf firewall ?
git:
config zone
option name 'wan6'
option output 'ACCEPT'
option family 'ipv6'
list network 'wan6'
list device 'eth0.832'
option forward 'ACCEPT'
option input 'DROP'
config zone
option name 'wan'
option output 'ACCEPT'
option family 'ipv4'
list network 'wan4'
option input 'DROP'
option forward 'DROP'
option masq '1'
ici:
config zone
option name 'wan6'
option input 'DROP'
option output 'ACCEPT'
option forward 'DROP'
option family 'ipv6' ## Zone ipv6 only pour ne pas mélanger les règles sur les deux mondes
list network 'wan6'
list device 'eth0.832'
config zone
option name 'wan'
option output 'ACCEPT'
option family 'ipv4' ## Zone ipv4 only pour ne pas mélanger les règles sur les deux mondes
list network 'wan4'
option forward 'DROP'
option masq '1' ## On remplace l'ip source "privée" des flux sortant sur internet par l'ip publique reçu sur le wan4.
option input 'DROP'
-
Est-ce que dans ton cas, il utilise ton serveur DNS IPv6, ou est-ce qu'il n'envoie en pratique ses requêtes qu'en IPv4?
Ça alterne, un coup ça passe en v6 un coup en v4 sur une même salve de requêtes. Exemple au démarrage de firefox :
Ce qui est bizarre quelques temps avant (c'était sur 10 je crois) ça alternait strictement entre v4 et v6 genre toutes les 5 min.
-
@ubune
Avec ce script là :
#!/bin/sh
WAN_DATA_DEVICE="eth0.832" #<-- Numéro d'interface à changer selon votre configuration.
# Configure a PRIO qdisc on WAN "data" interface.
tc qdisc replace dev "${WAN_DATA_DEVICE}" root handle 1: prio
tc filter del dev "${WAN_DATA_DEVICE}"
# DHCP (raw sockets, do not specify "protocol ip")
tc filter add dev "${WAN_DATA_DEVICE}" parent 1: prio 1 u32 \
match ip protocol 17 ff \
match ip dport 67 ffff \
action skbedit priority 0:6
# ARP
tc filter add dev "${WAN_DATA_DEVICE}" parent 1: prio 2 protocol 0x806 u32 \
match u32 0 0 \
action skbedit priority 0:6
# IGMP
tc filter add dev "${WAN_DATA_DEVICE}" parent 1: prio 3 protocol ip u32 \
match ip protocol 2 ff \
action skbedit priority 0:6
# ICMP
tc filter add dev "${WAN_DATA_DEVICE}" parent 1: prio 4 protocol ip u32 \
match ip protocol 1 ff \
action skbedit priority 0:6
# DHCPv6
tc filter add dev "${WAN_DATA_DEVICE}" parent 1: prio 5 protocol ipv6 u32 \
match ip6 protocol 17 ff \
match ip6 dport 547 ffff \
action skbedit priority 0:6
# ICMPv6
tc filter add dev "${WAN_DATA_DEVICE}" parent 1: prio 6 protocol ipv6 u32 \
match ip6 protocol 58 ff \
action skbedit priority 0:6
et un egress 0:0, 6:6 sur le VLAN 832 ça fonctionne. Pas besoin de netfilter.
Au lieu d'utiliser un script hotplug/iface, on peut directement mettre la commande dans le Startup via Luci (rc.local) :
(https://i.ibb.co/CHKSSjN/Capture.png)
-
Ubune, n'y aurait-il pas une erreur dans la conf entre ici et ton git au niveau des zone wan et wan6 dans la conf firewall ?
git:
config zone
option name 'wan6'
option output 'ACCEPT'
option family 'ipv6'
list network 'wan6'
list device 'eth0.832'
option forward 'ACCEPT'
option input 'DROP'
config zone
option name 'wan'
option output 'ACCEPT'
option family 'ipv4'
list network 'wan4'
option input 'DROP'
option forward 'DROP'
option masq '1'
ici:
config zone
option name 'wan6'
option input 'DROP'
option output 'ACCEPT'
option forward 'DROP'
option family 'ipv6' ## Zone ipv6 only pour ne pas mélanger les règles sur les deux mondes
list network 'wan6'
list device 'eth0.832'
config zone
option name 'wan'
option output 'ACCEPT'
option family 'ipv4' ## Zone ipv4 only pour ne pas mélanger les règles sur les deux mondes
list network 'wan4'
option forward 'DROP'
option masq '1' ## On remplace l'ip source "privée" des flux sortant sur internet par l'ip publique reçu sur le wan4.
option input 'DROP'
Vu les échanges à ce sujet fin mai sur le topic, je comprends mieux :)
https://lafibre.info/remplacer-livebox/remplacement-de-la-livebox-par-un-routeur-openwrt-18-dhcp-v4v6-tv/msg952178/#msg952178
-
Ça alterne, un coup ça passe en v6 un coup en v4 sur une même salve de requêtes. Exemple au démarrage de firefox :
Ce qui est bizarre quelques temps avant (c'était sur 10 je crois) ça alternait strictement entre v4 et v6 genre toutes les 5 min.
Je ne serai pas surpris qu'il track les temps de réponses de tous les DNS enregistrés, et qu'il utilise celui qui répond le plus rapidement. C'est ce que fait macOS et systemd-resolved si je ne me trompe pas.
Vu que les deux serveurs (v6 et v4) sont sur le même équipement, ca va bagotter pour sûr.
-
@ubune
Avec ce script là :
#!/bin/sh
WAN_DATA_DEVICE="eth0.832" #<-- Numéro d'interface à changer selon votre configuration.
# Configure a PRIO qdisc on WAN "data" interface.
tc qdisc replace dev "${WAN_DATA_DEVICE}" root handle 1: prio
tc filter del dev "${WAN_DATA_DEVICE}"
# DHCP (raw sockets, do not specify "protocol ip")
tc filter add dev "${WAN_DATA_DEVICE}" parent 1: prio 1 u32 \
match ip protocol 17 ff \
match ip dport 67 ffff \
action skbedit priority 0:6
# ARP
tc filter add dev "${WAN_DATA_DEVICE}" parent 1: prio 2 protocol 0x806 u32 \
match u32 0 0 \
action skbedit priority 0:6
# IGMP
tc filter add dev "${WAN_DATA_DEVICE}" parent 1: prio 3 protocol ip u32 \
match ip protocol 2 ff \
action skbedit priority 0:6
# ICMP
tc filter add dev "${WAN_DATA_DEVICE}" parent 1: prio 4 protocol ip u32 \
match ip protocol 1 ff \
action skbedit priority 0:6
# DHCPv6
tc filter add dev "${WAN_DATA_DEVICE}" parent 1: prio 5 protocol ipv6 u32 \
match ip6 protocol 17 ff \
match ip6 dport 547 ffff \
action skbedit priority 0:6
# ICMPv6
tc filter add dev "${WAN_DATA_DEVICE}" parent 1: prio 6 protocol ipv6 u32 \
match ip6 protocol 58 ff \
action skbedit priority 0:6
et un egress 0:0, 6:6 sur le VLAN 832 ça fonctionne. Pas besoin de netfilter.
Au lieu d'utiliser un script hotplug/iface, on peut directement mettre la commande dans le Startup via Luci (rc.local) :
(https://i.ibb.co/CHKSSjN/Capture.png)
Bonne idée d'utiliser les match de tc. As-tu pu faire un benchmark sur l'impact en termes de perf entre une solution nftables et tc ?
-
C'est OK de mon coté, vaut mieux tard que jamais ::)
(https://i.ibb.co/TKtJYMV/SCR-20221224-efe.png) (https://ibb.co/hXVrLFP)
Pensez vous que si je joue avec SQM je pourrais stabilisé un peu mieux mon upload dans mon cas ?
edit: bien mieux avec SQM sur l'upload, comme Ubien finalement, j'ai fixé a 627000 pour ma part. c'est le meilleur compromis.
Avec SQM
(https://i.ibb.co/zhDCsWk/image.png) (https://imgbb.com/)
Sans SQM
(https://i.ibb.co/HqVSW8s/image.png) (https://imgbb.com/)
Et au niveau de la charge du N5105 pendant les different tests:
(https://i.ibb.co/h9Kp7ZS/image.png) (https://ibb.co/F3BGx0F)
Par contre malgré l'ICMPv6 activé (j'accepte input et forward) dans la conf, https://ipv6-test.com me dit que je filtre ICMPv6 ?
-
Par contre malgré l'ICMPv6 activé (j'accepte input et forward) dans la conf, https://ipv6-test.com me dit que je filtre ICMPv6 ?
Il fait un ping sur l'IP source. En fonction de l'OS du terminal que tu utilises et de sa configuration, il ne répond pas forcément aux pings, même si les firewalls sur le chemin réseau les laissent passer. Windows par exemple ne répond jamais (pourquoi? va savoir...).
-
Je vois, je suis sur MacOS et j'utilise Safari pour ma part.
Je testerais depuis d'autre OS/Client pour voir.
Merci pour l'info ;D
-
Windows par exemple ne répond jamais (pourquoi? va savoir...).
De mémoire, le firewall W10 répond au ping 4 uniquement si la source est sur l'interface locale.
Pour 6, il faudrait que je regarde.
-
Décidément, Microsoft est de plus en plus créatif en ce qui concerne le réseau. Choix de DNS discutables (ne respectant pas les RFC), interface réseau qui change toute seule de "Public" à "Privé" ou l'inverse, règles de firewall pour ces deux zones qui changent lors d'une update, 3e zone "domaine" dont personne ne sait que faire... et j'en passe.
-
Je m'en souviens car j'avais galéré avec des VLAN à cause d'une non réponse au ping d'un win10! ::) :'(
Tout marchait bien et je ne comprenais pas pourquoi!
-
je ne crois pas que cela aie deja été évoqué mais pour les routeurs a base de MT7621+MT7530 (combo classique), OpenWRT SNAPSHOT intègre une optimisation qui reconfigure le switch pour relier le port WAN à un second port CPU différent de celui utilisé pour les autres ports LAN
Cela double la capacité en routage pour atteindre 2G up+down au lieu de 1G anciennement.
détails ici https://forum.openwrt.org/t/2-gbps-wan-lan-nat-routing-on-ramips-mt7621-devices/131478/14
Sur mon RB750GR3 fraichement installé, cela fonctionne sans problème. Notez ci-dessous, l'interface 'wan' n'a pas eth0 en parent et est indépendante.
root@OpenWrt:/etc/config# ip l | grep UP
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1000
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1504 qdisc fq_codel state UP qlen 1000
3: wan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP qlen 1000
4: lan2@eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue master br-lan state LOWERLAYERDOWN qlen 1000
5: lan3@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-lan state UP qlen 1000
6: lan4@eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue master br-lan state LOWERLAYERDOWN qlen 1000
7: lan5@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-lan state UP qlen 1000
18: br-lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000
19: wan.832@wan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000
et dans les logs de boot, on voit qu'il y a bien un mdio-bus différent pour wan que pour les lan2-5 et bien 2 liens ethernet sur le SOC
Fri Dec 23 19:07:19 2022 kern.info kernel: [ 1385.411746] mtk_soc_eth 1e100000.ethernet eth0: configuring for fixed/rgmii link mode
Fri Dec 23 19:07:19 2022 kern.info kernel: [ 1385.420081] mtk_soc_eth 1e100000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx
Fri Dec 23 19:07:19 2022 kern.info kernel: [ 1385.433653] mt7530 mdio-bus:1f lan2: configuring for phy/gmii link mode
Fri Dec 23 19:07:19 2022 kern.info kernel: [ 1385.494059] mt7530 mdio-bus:1f lan3: configuring for phy/gmii link mode
Fri Dec 23 19:07:19 2022 kern.info kernel: [ 1385.538419] mt7530 mdio-bus:1f lan4: configuring for phy/gmii link mode
Fri Dec 23 19:07:19 2022 kern.info kernel: [ 1385.580755] mt7530 mdio-bus:1f lan5: configuring for phy/gmii link mode
Fri Dec 23 19:07:19 2022 kern.info kernel: [ 1385.640272] mtk_soc_eth 1e100000.ethernet wan: PHY [mdio-bus:00] driver [MediaTek MT7530 PHY] (irq=POLL)
Fri Dec 23 19:07:19 2022 kern.info kernel: [ 1385.649873] mtk_soc_eth 1e100000.ethernet wan: configuring for phy/rgmii link mode
-
Petit récapitulatif pour officialiser le passage en 2.5G de mon coté:
Pour la petite histoire:
Je pars à la base d'une LB3 (offre JET) + ONT Alcatel que j'ai viré y'a 6 ans par un ER4 tout en gardant l'ONT Alcatel.
Il y a 2 ans j'ai déménagé et je n'ai pas eu le choix que de changer d'offre pour passer sur une offre UP (donc j'ai les 2G qui arrive à la fibre) sauf que je n'avais pas l'infra qui allait avec donc j'ai pas cherché plus loin à ce moment là.
Suite a un nouveau déménagement en début d'année 2022, j'avais la possibilité d'avoir une infra à + de 1G mais je n'avais pas spécialement le temps de me pencher dessus, je suivais par contre de loin les avancés sur le forum pour le passage à 2G. D'ailleurs début 2022 c'etait encore trop chiant de trouver le matos qui va bien, surtout l'ONU SFP, pour faire le switch... mais 2022 fut une bonne année pour les bidouilleurs du forum et pas mal de nouveautés ont vu le jour, surtout grace à FS qui sortit son ONU SFP, donc la je n'avais plus choix, surtout qu'un petit routeur tout mignon à ponté le bout de son nez cet été, le GoWin R86S....
Donc config ultra simple:
- un R86S (https://lafibre.info/routeur/minipc-x86-r86s-n5105n6005-3x2-5g2x10g-sfp/) sous OpenWrt 22.03.02 avec une carte OCP 2.0 en BCM57840
- un ONU FS, le GPON-ONU-34-20BI
De base le R86S est livré avec une Mellanox ConnectX3, non comptaible 2.5G, il a donc fallut trouver une carte pour la remplacer...
Je ne voulais en effet pas passer par une autre équipement pour gerer la CoS 6.
(Bon j'ai quand meme un CRS 305 au cas où si jamais cela dit)
Et ce n'était pas une mince affaire pour trouver une carte OCP 2.0 compatible avec le R86S car il faut savoir que la carte OCP tournera forcement en PCIE X.0 4x malgrés qu'elle soit en 8x, car il le port PCIE partage les lignes avec le port du SSD NVME.
Certaines cartes PCIE ne fonctionne PAS bien si la totalité des lignes PCIE ne sont pas "branchées", en tout cas dans le R86S - exemple, carte PCIE 8x dans un slot x4.
Après de longue recherche, une seule et unique carte semble existe pour remplacer la Mellanox si on veut le support 2.5G dans le R86S, une ASUS MCB-10G 57840-2S (PCIE 3 8x) que j'ai galéré à trouver et à faire rapatrier en France, la carte est EOL depuis des années et absolument rien de rien en occasion...
Et je n'avais pas encore la certitude à 100% que cette carte était comptaible avec le patch firmware et le patch des drivers de la 57810..
D'aprés un post chinois fournit par un des dev du R86S, il semblait cependant que c'etait bien le cas, donc j'ai tenté le coup.
Car si des cartes OCP 2.0 existent en BCM 57810 (et encore c'est rare, j'en ai trouvé qu'une, une Quanta en PCIE 2.0 8x donc elle aurait été en 2.0 4x dans le R86S si jamais), elles ne fonctionnent pas dans le R86S par rapport aux lignes PCIE manquantes !
Les devs prévoit une revision potentiel avec le pb reglé:
"Note!! We confirmed not all of bcm ocp 2.0 card are supported. (some special type of card cannot identification.) (May because of not full channel of PCIE lines?)(We try to fix it on version 2[change clock line], but still cannot read these special card) So, take care of it when you want to buy bcm OCP card."
Quoi qu'il soit l'info du gars de chez GoWin qui a lui meme recupéré les infos sur des forums chinois était bien bonne, la carte sur BCM57840 fonctionne bien dans le R86S et elle se patch exactement de la meme façon que les 57810, donc rien de nouveau à ce niveau, et idem pour les drivers, en meme temps ce sont presque les meme carte.
Juste à savoir, le chip de l'ASUS BCM57840 n'est pas situé au meme endroit que la Mellanox, donc il n'est pas couvert à 100% par le refroidissement d'origine du R86S, j'ai rajouté un petit ventilateur de 80mm pour refroidir le tout, meme si dans les fait ce n'est pas forcement nécessaire, ça chauffe, mais comme toutes les cartes SFP+, et vu que l'ONU FS chauffe lui comme un porc... ce n'est pas plus mal, et ça fait aussi baissé la température de 10 degres sur le CPU, donc un mal pour un bien :D
Pour le reste, l'ONU FS configuré avec le serial de mon ONT Alcatel + vendorID (ALCL) + HW_version (SMBSSGLBF121\0\0)
Le R86S, config classique OpenWRT Orange avec toutes les options DHCP qui vont bien et les regles nftables pour la CoS6 (Merci Ubune pour le topic et les infos)
Et c'est tout bon (SQM activé sur l'upload pour le stabiliser, c'était pas 100% stable sans , j'avais quelques paquets TCP retransmit lors des tests):
(https://i.ibb.co/74HZmqz/image.png) (https://ibb.co/xHyBTNs)
(https://i.ibb.co/ctwHYcQ/image.png) (https://ibb.co/Cv6ZP5Q)
Clairement, le prix de la totalité du truc ne vaut pas le coup, un simple ONT LEOX 2.5G + un routeur 4x2.5G x86 aurait eu le meme résultat pour quelques centaines d'euros de moins dans mon cas.
Mais j'aime bcp trop le format mini et le fait de n'avoir qu'un équimement pour la partie routeur (je veux dire sans ONT externe / sans switch pour la CoS6)
A voir les capacité de routage du N5105 en NAT pour le 10G un jour en XGSPON (RAS sans NAT, ça encaisse sans soucis), mais pour le 2.5G c'est les doigts dans les nez.
(https://i.ibb.co/KmVfyFn/Network-Final-2.png) (https://ibb.co/QXYTmr0)
-
Salut à tous, finalement, à l'époque j'étais revenu en 19.07.8 parce que la gestion des vlans sur OpenWRT 21 était simplement horrible pour moi.
@ubune, j'ai vu ta maj pour 22.03, beaucoup plus simple, et le github qui m'a permis de modifier ma conf (from scratch) de façon incrémentale.
Alors, actuellement ça fonctionne, Internet, VPN ok
ifstatus wan4 | jsonfilter -e '@["ipv4-address"][0].address'
# retourne bien mon @IP_PUB actuellement
Cependant, je n'ose plus rebooter mon routeur ou toucher au network parce que je constate un phénomène que je n'explique pas
Au reboot, la commande ci-dessus me retourne une IP privée (je pense de l'ONT en 172.16.x.x/16) et reste en l'état indéfiniment
Au bout du 3-4e reboot de l'ONT ou suite aux multiples /etc/init.d/network restart, je récupère l'IP publique
J'ai aussi remarqué, qu'il me fallait que mon device "wan" soit activé en configuration, en fait, je cherche l'explication du pourquoi je récupère l'IP PUB à un moment après les réinitialisations des interfaces ou pas ...
Si tu as une idée parce que j'aime comprendre
@ubune, tu sais, j'ai un problème où mon routeur perd l'IP WAN à intervalle +/- périodique de 3 jours. Tu m'as dit que si ip lan (ont) = mauvaise auth ou mauvaise priorité.
1- Mauvaise auth ?
Si je reprends ton tuto (maj 22.03+) et que j'utilise l'outil jsfiddle de kgersen (https://jsfiddle.net/kgersen/3mnsc6wy/) avec `fti/qpq8888` et `12345622`, j'obtiens la chaine :
00000000000000000000001a0900000558010341010D6674692F717071383838383c1231323334353637383930313233343536031341302f6f2d83fc857d7829d65ddea775d7
Dans le tuto, il y a des caractères en +, d'où sortent-ils ?
00000000000000000000001a090000055801034101116674692F6674692F717071383838383c1231323334353637383930313233343536031341302f6f2d83fc857d7829d65ddea775d7
2- Mauvaise priorité ?
Dans le tuto 22.03+, il est écrit :"- Gérer les files pour éviter les pbs de débit (on remet bien notre traffic internet avec des priorités cohérentes) => /etc/rc.local (nft rules)", mais cette étape n'est mentionnée que dans le tuto historique 19.07-. Faut-il ajouter quelque chose dans le /etc/rc.local ?
Merci
-
Rien de particulier à mettre dans le /etc/rc.local de plus que ce qu'a indiqué Ubune en 22.03 (voir son github)
Pour ton IP en 172.16.x.y
C'est en fait une IP de parking, lié a une option DHCP mal renseignée, et donc tu es mis de "coté" pour pas polluer le réseau.
Voir ici pour plus d'info: https://lafibre.info/remplacer-livebox/durcissement-du-controle-de-loption-9011-et-de-la-conformite-protocolaire/
Pour rappel, voici les options nécessaire à présent ou dans un futur proche:
Pour résumer les options nécéssaires minimales:
IPV4 DHCP - 4 options minimales
client identifier (option 61)
vendor class identifier (option 60)
user class information (option 77)
authentifaction (option 90)
IPV6 DHCPv6 - 5 options minimales
vendor specific information (option 17): entreprise id "Orange" 4 octets 00000558 + 2 octets option code 0006 + 14 octets Option data: 495056365f524551554553544544 ("IPV6_REQUESTED")
client identifier (option 1)
user class (option 15)
vendor class (option 16)
authentication (option 11)
Avec tout ça, ipv4 + prefix ipv6 OK. Sans l'option 17: mise en isolement au parking...
https://lafibre.info/remplacer-livebox/durcissement-du-controle-de-loption-9011-et-de-la-conformite-protocolaire/msg991229/#msg991229
-
Bon, j'ai repris cette solution là (https://lafibre.info/remplacer-livebox/remplacement-de-la-livebox-par-un-routeur-openwrt-18-dhcp-v4v6-tv/msg972342/#msg972342) telle que, et j'ai enfin compris ce qui déconnait.
Tout d'abord, il faut absolument installer les packages tc-tiny (pour avoir la commande 'tc') ainsi que kmod-sched (pour avoir le qdisc 'prio'). Si on oubli le module kmod-sched, on se retrouve avec une erreur abscons de 'tc' dès la première commande.
Ensuite, j'ai un problème d'ordre: je ne sais pas pourquoi mais au ifup, le script tc se lance après le dhcp. Du coup ça ne récupère pas une IP correcte. Faut que je relance juste l'interface et c'est bueno. Un peu relou.
Bref, ça marchotte.
Et sinon en terme de perf CPU, j'ai à peu près pareil. Le CPU est chargé d'IRQ tout autant et j'arrive à 50% de charge (sur 2 coeurs) lorsque je charge la ligne à 2.2Gbps.
pour completer d'autres pièges , après avoir fait le même taf :
- les 'prio' dans le script tc sont simplement l'ordre dans lesquels les filters seront appliqués, rien à voir avec le contenu du champs .1q priority
- le skbedit '0:6' n'a rien a voir avec le qos_mapping '0:6' . Le premier tag le paquet avec la priorité major 0 et minor 6 , le second retag les paquets taggés 0 en tag 6 mais inutile pour une solution pure tc.
Ca a l'air de marcher :
"tc -s filter show dev wan.832" montre des compteurs qui s'incrémentent correctement.
tcpdump ne voit rien de changé, tout est toujours VLAN PRI 0 mais la capture ne collecte peut etre pas au bon étage de la stack. Au passage, https://hpd.gasmi.net/ rox : je tcpdump en hex et copicolle le résultat dedans. Carrément plus simpe que des aller/retours scp+wireshark pour décoder.
Aucun changement de débit .
Bref, on verra quand cela deviendra obligatoire sur ma ligne.
-
3e zone "domaine" dont personne ne sait que faire... et j'en passe.
Ça sert... quand un PC est joint à un domaine. Mais c'est sûr que c'est inutile pour Mme Michu et même 90% des plus geeks d'entre nous.
Je m'en souviens car j'avais galéré avec des VLAN à cause d'une non réponse au ping d'un win10! ::) :'(
Tout marchait bien et je ne comprenais pas pourquoi!
Ça fait un bail que windows bloque par défaut le ping, c'était déjà le cas sur XP.
-
Hello,
J'ai ajouté l'option 17 (wan6) dans le tuto (Merci ochbob), je vais mettre à jour le github dans la journée.
17:000005580006000e495056365f524551554553544544
Resultat :
(495056365f524551554553544544 = IPV6_REQUESTED)
-
Github à jour.
Je suis bien dans une zone migrée car je reçois l'option 17 (ipv6) et 125 (ipv4) en retour, par contre ça fonctionnait même sans envoyer l'option 17.
En ipv6 : 000100000000000000000018 (voir screenshot)
En ipv4 : 00010000000000000000 (voir screenshot)
D'après le post de Levieux ça ressemble à "tout est ok" ;) :
Le canal retour :
Dans la réponse DHCP il y a un canal de retour du réseau.
C'est l'option 125 en DHCPv4, l'option 17 en DHCPv6
Le contenu (attention, les entêtes des options sont différentes, voir les RFC) est le même et dans le format suivant avec en rouge 2 octets de code d'information : 0001000000ffffffffff
Les grandes classes de réponses sont :
- 00xx : OK vu du réseau Orange et tout doit fonctionner. Si ce n'est pas le cas le problème vient de chez vous.
- 01xx : Le modèle de box, le firmware ou votre ligne est bloquée (0102 ce qui peut arriver si le comportement de votre routeur est trop agressif ...)
- 02xx : erreur de Login ou de Mot de passe ou d'encodage
- 03xx : compte ou service probablement résilié
- 04xx : problème de règlement de la facture avec de possibles limitation de débit ou blocage.
-
Bonjour,
J'ai une petite galère actuellement abonné Orange Fibre avec un ONT Huawai derriere une box 5 qui est fonctionnel je souhate mettre mon Asus AC88u a la place de cette foutu box.
J'ai passer celui-ci en OpenWRT 22.03 juque la tout va bien je fais le tuto impec je branche le routeur et la miracle une IPv4 je me dit coool ça marche sauf que pas de V6 et rien à faire elle veux pas monter
je ne sait quel infos vous fournir pour m'aider mais la je ne sais plus quoi faire j'ai meme tester depuis le git je me dit on sait jamais
si besoin je posterai ma config annonymiser
merci par avance
-
pour completer d'autres pièges , après avoir fait le même taf :
- les 'prio' dans le script tc sont simplement l'ordre dans lesquels les filters seront appliqués, rien à voir avec le contenu du champs .1q priority
- le skbedit '0:6' n'a rien a voir avec le qos_mapping '0:6' . Le premier tag le paquet avec la priorité major 0 et minor 6 , le second retag les paquets taggés 0 en tag 6 mais inutile pour une solution pure tc.
Ca a l'air de marcher :
"tc -s filter show dev wan.832" montre des compteurs qui s'incrémentent correctement.
tcpdump ne voit rien de changé, tout est toujours VLAN PRI 0 mais la capture ne collecte peut etre pas au bon étage de la stack. Au passage, https://hpd.gasmi.net/ rox : je tcpdump en hex et copicolle le résultat dedans. Carrément plus simpe que des aller/retours scp+wireshark pour décoder.
Aucun changement de débit .
Bref, on verra quand cela deviendra obligatoire sur ma ligne.
Quels sont les avantages de cette méthodes plutôt que d’utiliser nftables finalement ?
D’après ce que dit Plqnk, les perfs seraient identiques et la charge CPU aussi.
-
Bonjour,
J'ai une petite galère actuellement abonné Orange Fibre avec un ONT Huawai derriere une box 5 qui est fonctionnel je souhate mettre mon Asus AC88u a la place de cette foutu box.
J'ai passer celui-ci en OpenWRT 22.03 juque la tout va bien je fais le tuto impec je branche le routeur et la miracle une IPv4 je me dit coool ça marche sauf que pas de V6 et rien à faire elle veux pas monter
je ne sait quel infos vous fournir pour m'aider mais la je ne sais plus quoi faire j'ai meme tester depuis le git je me dit on sait jamais
si besoin je posterai ma config annonymiser
merci par avance
Toutes les options DHCP sont ok ?
Si tu as suivi le tuto d’Ubune et bien remplacer ce qu’il faut ça doit marcher normalement.
-
Quels sont les avantages de cette méthodes plutôt que d’utiliser nftables finalement ?
D’après ce que dit Plqnk, les perfs seraient identiques et la charge CPU aussi.
C'est un peu plus "propre", mais ce qui me gène c'est qu'il faut installer des packages afin d'utiliser tc, alors que les règles nft tout est natif, donc si même perf au final...
Du coup avec nft on peut remplacer la livebox from scratch, sans n'avoir jamais connecté le routeur openwrt qui vient la remplacer (plus facile, surtout pour les nouveaux utilisateurs d'openwrt).
Si tc devient natif à openwrt, le script sera dans le github/tuto ;)
-
Toutes les options DHCP sont ok ?
Si tu as suivi le tuto d’Ubune et bien remplacer ce qu’il faut ça doit marcher normalement.
Je rebondis également, si tu mets ta livebox elle obtient bien le préfixe ipv6 ?
Tu as bien les options "client-id" ?
Si tu veux fait une petite trace : tcpdump -ni eth0 port 546 or port 547 -w dhcpv6.pcap
Attention également, j'ai eu plusieurs cas ou il fallait mettre le device dans la zone wan6 (eth0.832) sinon le routeur droppait la réponse dhcpv6 d'orange.
C'est pour ça que c'est inclus dans le tuto/github
-
Github à jour.
Je suis bien dans une zone migrée car je reçois l'option 17 (ipv6) et 125 (ipv4) en retour, par contre ça fonctionnait même sans envoyer l'option 17.
En ipv6 : 000100000000000000000018 (voir screenshot)
En ipv4 : 00010000000000000000 (voir screenshot)
D'après le post de Levieux ça ressemble à "tout est ok" ;) :
Je suis également dans une zone migrée et je n'ai pas l'option 17 et j'ai bien une ipv6. D'ailleurs dans le post résumé de levieux, il ne parle pas non plus de cette option 17 (ou alors j'ai rien compris) :
https://lafibre.info/remplacer-livebox/durcissement-du-controle-de-loption-9011-et-de-la-conformite-protocolaire/msg984140/#msg984140
DHCPv6
Message type: Solicit (1)
Transaction ID: 0x1eace9
Client Identifier
Option: Client Identifier (1)
Length: 10
Value: 0003000144d454XXXXXX
DUID: 0003000144d454XXXXXX
DUID Type: link-layer address (3)
Hardware type: Ethernet (1)
Link-layer address: 44:d4:54:XX:XX:XX
Elapsed time
Option: Elapsed time (8)
Length: 2
Value: 0000
Elapsed time: 0ms
Option Request
Option: Option Request (6)
Length: 8
Value: 000b001100170018
Requested Option code: Authentication (11)
Requested Option code: Vendor-specific Information (17)
Requested Option code: DNS recursive name server (23)
Requested Option code: Domain Search List (24)
Identity Association for Prefix Delegation
Authentication
Option: Authentication (11)
Length: 70
Value: 00000000000000000000001a0900000558010341010dXXXX…
Protocol: 0
Algorithm: 0
RDM: 0
Replay Detection: 0000000000000000
Authentication Information: 1a0900000558010341010dXXXX…
User Class
Option: User Class (15)
Length: 45
Value: 002b46535644534c5f6c697665626f782e496e7465726e65…
Vendor Class
Option: Vendor Class (16)
Length: 11
Value: 0000040e0005736167656d
Enterprise ID: SAGEMCOM SAS (1038)
vendor-class-data: sagem
-
C'est ton message 'Solicit' de la requête DHCPv6, cela veut dire que tu n'envois pas cette option a priori.
Dans mon cas:
(https://i.ibb.co/ph6tmzr/image.png) (https://imgbb.com/)
Pour voir la réponse il faut regarder dans le message 'Reply' en DHCPv6.
-
Je suis également dans une zone migrée et je n'ai pas l'option 17 et j'ai bien une ipv6. D'ailleurs dans le post résumé de levieux, il ne parle pas non plus de cette option 17 (ou alors j'ai rien compris) :
https://lafibre.info/remplacer-livebox/durcissement-du-controle-de-loption-9011-et-de-la-conformite-protocolaire/msg984140/#msg984140
Il ne mentionne pas l'option 17 car elle n'est pas nécessaire dans le sens client -> serveur DHCP, mais c'est une bonne idée de la faire figurer dans la liste des options demandées par le client au serveur.
On voit d'ailleurs dans ta capture que tu la demandes :
Option Request
Option: Option Request (6)
Length: 8
Value: 000b001100170018
Requested Option code: Authentication (11)
Requested Option code: Vendor-specific Information (17) # option 17 demandée au serveur
Requested Option code: DNS recursive name server (23)
Requested Option code: Domain Search List (24)
mais que tu n'envoies pas d'option 17 à proprement parler.
Et en effet, LeVieux lui-même a confirmé qu'il était inutile d'envoyer cette option et qu'elle n'était utilisée que dans le sens serveur DHCP -> client DHCP pour fournir un code d'état de la ligne/connexion.
Si tu ne recois pas d'option 17 dans les réponses DHCP, c'est que ta zone n'a pas migré.
-
Et pourtant:
https://lafibre.info/remplacer-livebox/durcissement-du-controle-de-loption-9011-et-de-la-conformite-protocolaire/msg991229/#msg991229
L'option semble bien nécessaire malgré tout et semble envoyé depuis au moins 2018 d'aprés un membre qui avait fait des capture de la Livebox.
-
Il ne mentionne pas l'option 17 car elle n'est pas nécessaire dans le sens client -> serveur DHCP, mais c'est une bonne idée de la faire figurer dans la liste des options demandées par le client au serveur.
On voit d'ailleurs dans ta capture que tu la demandes :
mais que tu n'envoies pas d'option 17 à proprement parler.
Et en effet, LeVieux lui-même a confirmé qu'il était inutile d'envoyer cette option et qu'elle n'était utilisée que dans le sens serveur DHCP -> client DHCP pour fournir un code d'état de la ligne/connexion.
Si tu ne recois pas d'option 17 dans les réponses DHCP, c'est que ta zone n'a pas migré.
Ok merci pour l’éclaircissement, au final j'avais à moitié rien compris :) Je n'avais pas saisi la subtilité, entre j'envoie l'option 17 et j'envoie la demande d'avoir une option 17 dans la réponse :) La capture est celle de levieux sur son 2eme post, ce n'est pas mon cas exact. Chez moi je n'ai pas d'option 17 dans la config de mon fichier network (ce qu'a ajouté ubune recemment : 17:000005580006000e495056365f524551554553544544), je suis dans une zone migrée et j'ai bien l'IPv6 qui fonctionne. En revanche j'ai bien ça :
option reqopts '11 17 23 24'
Donc je pense que je fais bien la demande pour avoir une option 17 en réponse.
-
Merci des infos les options on été verifié et normalement ok il faut bien enlever les deux points ':' sur le retours du scripts pour l'authentification ? j'ai tester les deux cas donc je dirais oui.
depuis ma box j'ai bien les deux v4 et v6 par "client-id" tu veux dire l'option 90 celle géneré par le scripts ?
la seule erreur peut etre sur la mac de la box j'ai mis celle de la box 5 pas tester avec celle de l'ont
concernant le dumps je fais des retour de vacances semaines pro et je testerai le coup de la zones wan6 meme si j'ai bien cru l'avoir vu deja mises je verifirai.
je vous tiens informé de l'avancer de la choses
-
Ok merci pour l’éclaircissement, au final j'avais à moitié rien compris :) Je n'avais pas saisi la subtilité, entre j'envoie l'option 17 et j'envoie la demande d'avoir une option 17 dans la réponse :) La capture est celle de levieux sur son 2eme post, ce n'est pas mon cas exact.
On est là pour apprendre :) (et pour avoir ipv6 partout!)
Chez moi je n'ai pas d'option 17 dans la config de mon fichier network (ce qu'a ajouté ubune recemment : 17:000005580006000e495056365f524551554553544544), je suis dans une zone migrée et j'ai bien l'IPv6 qui fonctionne. En revanche j'ai bien ça :
option reqopts '11 17 23 24'
Donc je pense que je fais bien la demande pour avoir une option 17 en réponse.
Oui, ta config est bonne, j'ai la même d'ailleurs (pas d'envoi d'option 17, mais je la demande).
Je pense qu'ubune a ajouté un envoi d'option 17 dans son tuto pour coller à ce que fait la livebox, mais il me semble que LeVieux déconseillait de le faire.
Si tu as un préfixe v6 valide et routé, tout va bien!
-
la seule erreur peut etre sur la mac de la box j'ai mis celle de la box 5 pas tester avec celle de l'ont
La MAC utilisée n'a à priori pas d'importance, tant qu'elle est stable et qu'elle est valide (i.e. les adresses multicast ou broadcast ne sont pas valides).
Il est recommandé par contre de mettre dans le client-id/DUID la même MAC que celle configurée sur l'interface. Si je ne m'abuse, c'est ce que fait OpenWRT/odhcp6c par défaut.
J'utilise la MAC de ma livebox 4 qui ne m'a jamais servi, et je n'ai jamais eu de souci. L'avantage d'avoir une MAC fixée dans la configuration est que cela permet de récupérer le même préfixe après un changement de routeur.
il faut bien enlever les deux points ':' sur le retours du scripts pour l'authentification ?
Si par script tu entends https://jsfiddle.net/kgersen/3mnsc6wy/, oui, il faut enlever les ':'. Attention, il faut laisser les ':' juste après le numéro d'option. En gros, tu dois avoir le même format que dans le premier post de ce thread:
option sendopts '11:<chaine retournée par le script sans ':'> 15:FSVDSL_livebox.Internet.softathome.livebox4 16:0000040e0005736167656d'
-
Normal tu dois avoir localhost dans le resolv.conf
C'est dans /etc/config/dhcp que tu dois spécifier le serveur dns ou tu forward.
config dnsmasq
list server ""
ou via l'interface web :
network/dhcp and dns/general settings
Et si tu veux utiliser les serveurs DNS du FAI, il n'y a rien à faire car le paramètre "Use DNS servers advertised by peer" sur l'interface wan est coché par défaut.
En fait ça ne va pas...
Car j'ai un pihole et par conséquent si je forward toutes les requêtes DNS, le pihole voit toutes les requêtes avec l'IP local du routeur...
La config DNS pour mes clients DHCP est OK par contre, pas de soucis à ce niveau là (Interface -> Lan -> DHCP Server -> Advanced -> DHCP-Options -> 6,192.168.1.xxx,)
En faisant ça et en supprimant la config DNS Forwarding (Network -> DHCP & DNS -> DNS Forwarding) ce sont bien les requêtes de mes clients directement qui arrive sur le Pihole et plus celle du routeur.
Par contre pour le routeur en lui même j'ai beau cherché mais je ne vois pas comment faire pour qu'il puisse résoudre mes requêtes DNS sans forward TOUTES les requêtes ?
Sauf à modifier directement le /etc/resolv.conf et dans ce cas là c'est OK.
Une idée ?
edit:
j'ai compris comment fonctionné OpenWrt à ce niveau là et franchement c'est pas l'idéal de mon point de vue...
J'ai supprimer le lien symbolique de /etc/resolv.conf vers /tmp/resolv.conf et supprimé le fichier /tmp/resolv.conf.
Creation d'un nouveau resolv.conf et chattr +i sur le fichier.
Plus d'emmerde ::)
-
C'est ce qu'on t'as expliqué quelques post plus tôt.
Il suffit d'envoyer l'adresse de ton pihole aux client dans le RA ET dans dhcpv6 (pour les machines en Windows 11).
Du coup je ne comprends pas ce que tu dis pour le routeur ?
Tu peux spécifier un dns aux clients sans que ce soit ce même serveur dns utilisé par le routeur.
-
Bonjour à tous,
Bonne année 2023 !
Je suis nouvel arrivant sur le forum.
Je suis client Orange/Sosh fibre.
Je viens de déménager dans la commune de Ronsy-sous-Bois (93).
J'ai fait le choix de remplacer ma Livebox5, qui était branchée au boitier ONT en RJ45, par un routeur TP-link Archer C7 (v5) embarquant OpenWRT version 22.03.2 (r19803-9a599fee93).
Je tiens tout d'abord à remercier celles et ceux qui ont pris sur leur temps pour documenter les différentes manipulations à effectuer pour remplacer sa Livebox.
Pour ma part, je fais face à une difficulté de réalisation.
Le service odhcp6c sollicite une option qui n'est pas listée dans 'reqopts' malgré l'argument 'defaultreqopts' positionné sur '0'.
Il ajoute dans la liste l'option 82 (OPTION_SOL_MAX_RT) et supprime l'option 11 de la liste !
Aussi, il ajoute dans la trame l'option 3 (Identity Association for Non-temporary Address) et aucun argument me permet de passer outre.
Et, je ne vous parle pas de l'option 25 (Identity Association for Prefix Delegation) qui est impossible à combler en entier avec l'argument 'reqprefix'.
Bref, ces problèmes sont-ils connus ?
Savez-vous s'il est possible de changer de client DHCPv6 sur OpenWRT avec l'utilitaire de management de paquets 'opkg' ?
Sinon, la configuration 'wan4' fonctionne sans problèmes.
D'avance, merci.
Ci-dessous, ma configuration.
/etc/config/network :
[...]
config interface 'wan6'
option device 'eth0.832'
option proto 'dhcpv6'
option noserverunicast '1'
option noclientfqdn '1'
option noacceptreconfig '1'
option reqaddress 'force'
option reqprefix '56:aab87321'
option forceprefix '1'
option soltimeout '3600'
option defaultreqopts '0'
option reqopts '11 17 23 24'
option clientid '00030001c0d7aab87321'
option userclass 'FSVDSL_livebox.Internet.softathome.Livebox5'
option vendorclass '0000040e736167656d'
option sendopts '11:00000000000000000000001a0900000558010341010d6674692f6b3637376366793c1[CRYPT]'
[...]
/etc/config/firewall :
[...]
config zone
option name wan6
option network wan6
option family ipv6
option input REJECT
option output ACCEPT
option forward REJECT
option masq 1
option mtu_fix 1
config rule
option name Allow-DHCPv6-client
option src wan6
option proto udp
option src_port 547
option dest_port 546
option family ipv6
option target ACCEPT
#list src_ip fc00::/6
#list dest_ip fc00::/6
config rule
option name Allow-DHCPv6-server
option src wan6
option proto udp
option src_port 546
option dest_port 547
option family ipv6
option target ACCEPT
#list src_ip fc00::/6
#list dest_ip fc00::/6
[...]
/etc/config/dhcp :
[...]
config dhcp 'wan6'
option interface 'wan6'
option ignore '1'
config odhcpd 'odhcpd'
option maindhcp '0'
option leasefile '/tmp/hosts/odhcpd'
option leasetrigger '/usr/sbin/odhcpd-update'
option loglevel '7'
[...]
-
J'ai oublié une question :
De quelle documentation provient les arguments ci-dessous qui sont donnés dans le tutoriel 'Remplacement de la Livebox par un routeur Openwrt' ?
[...]
list egress_qos_mapping '0:0'
list egress_qos_mapping '2:2'
list egress_qos_mapping '3:3'
list egress_qos_mapping '4:4'
list egress_qos_mapping '5:5'
list egress_qos_mapping '6:6'
list egress_qos_mapping '7:7'
list egress_qos_mapping '1:0'
list egress_qos_mapping '0:6'
[...]
Je n'ai pas trouvé trace et, du coup, je me demande si c'est pas déprécié.
D'avance, merci.
-
C'est ce qu'on t'as expliqué quelques post plus tôt.
Il suffit d'envoyer l'adresse de ton pihole aux client dans le RA ET dans dhcpv6 (pour les machines en Windows 11).
Du coup je ne comprends pas ce que tu dis pour le routeur ?
Tu peux spécifier un dns aux clients sans que ce soit ce même serveur dns utilisé par le routeur.
Soit encore un truc m'échappe, soit j'ai définitivement pas compris :-X
Pour mes clients, RAS, ils récupèrent bien leur config DHCP avec le DNS du Pihole, que ce soit en v4 ou v6, pour ce faire je fais comme ça:
en v4: Interface -> Lan -> DHCP Server -> Advanced Settings -> DHCP Options -> ipv4 de mon pihole
en v6: Interface -> Lan -> DHCP Server -> Advanced Settings -> Ipv6 Settings -> Announced IPv6 DNS servers -> ipv6 de mon pihole
Je vois bien toutes les requetes passées avec l'IP locale v4/v6 de chacun de mes clients dans le Pihole.
Mais en faisant juste ça, pas de résolution DNS sur le routeur en lui meme.
Si je mets mnt dans Network -> DHCP and DNS -> DNS Forwardings l'adresse de mon pihole, le routeur peut à présent résoudre, parfait, MAIS le pihole voit toute les requêtes venant du routeur, meme celle de mes clients, l'IP loggué par le pihole est celle du routeur, meme si c'est l'iPad qui fait la requete.
Je ne sais pas si c'est plus clair mais c'est pour ça que j'en suis venu a modifier directement le /etc/resolv.conf du routeur, comme ça, plus de soucis, tout fonctionne bien comme je le souhaite.
Ce n'est peut être pas la bonne façon de faire par contre... mais ça répond à mon besoin ::)
-
J'ai fait le choix de remplacer ma Livebox5, qui était branchée au boitier ONT en RJ45, par un routeur TP-link Archer C7 (v5) embarquant OpenWRT version 22.03.2 (r19803-9a599fee93).
J'utilisais l'Archer C7 comme routeur jusqu'à l'an dernier, je ne l'utilise plus que comme access point, mais c'est une bonne machine pour le prix. Avec software offload, il doit pouvoir router ~400-500Mbit/s en ipv6.
Il ajoute dans la liste l'option 82 (OPTION_SOL_MAX_RT) et supprime l'option 11 de la liste !
J'ai aussi ce comportement dans mes captures (OpenWRT 22.03.2 également), mais je ne vois l'option 82 que dans le Solicit. Elle est absente du Request, et dans tous les cas, n'empêche pas la réception de messages Advertise/Reply ni même l'obtention d'un préfixe.
L'option 11 n'est en effet pas présente dans les requested options, mais l'option 11 est bien présente (avec sa chaine d'auth) dans les messages Solicit et Request. Encore une fois, aucun souci pour obtenir un préfixe, donc je ne pense pas que ca gène.
Aussi, il ajoute dans la trame l'option 3 (Identity Association for Non-temporary Address) et aucun argument me permet de passer outre.
Et, je ne vous parle pas de l'option 25 (Identity Association for Prefix Delegation) qui est impossible à combler en entier avec l'argument 'reqprefix'.
Avec
option reqaddress 'none'
option reqprefix 'auto'
je n'ai pas d'option 3. Je vois option reqaddress 'force' dans ta config, je pense que c'est pour cela que tu vois cette option 3 (mormalement pas honorée par le serveur).
Je n'ai jamais utilisé option reqprefix, mais je serai vraiment étonné que le serveur DHCP d'Orange l'honore.
Pour conserver le même préfixe, option norelease '1' et une MAC/DUID fixes ont toujours été suffisants pour moi. Est-ce que tu as des soucis de préfixe qui change ?
-
Mais en faisant juste ça, pas de résolution DNS sur le routeur en lui meme.
Si je mets mnt dans Network -> DHCP and DNS -> DNS Forwardings l'adresse de mon pihole, le routeur peut à présent résoudre, parfait, MAIS le pihole voit toute les requêtes venant du routeur, meme celle de mes clients, l'IP loggué par le pihole est celle du routeur, meme si c'est l'iPad qui fait la requete.
Si tu veux que le routeur utilise ton pihole comme serveur DNS, tu dois pouvoir ajouter à la config v4 et v6 (dans /etc/config/network, probablement églaement faisable depuis Luci):
config interface 'wan6'
option peerdns '0'
list dns '<ipv6 pi hole>'
config interface 'wan'
option peerdns '0'
list dns '<ipv4 pi hole>'
pour qu'il ignore les DNS fournis par le DHCP et qu'il utilise ton pi-hole comme resolver.
-
Avec
option reqaddress 'none'
option reqprefix 'auto'
je n'ai pas d'option 3. Je vois option reqaddress 'force' dans ta config, je pense que c'est pour cela que tu vois cette option 3 (mormalement pas honorée par le serveur).
Je n'ai jamais utilisé option reqprefix, mais je serai vraiment étonné que le serveur DHCP d'Orange l'honore.
Pour conserver le même préfixe, option norelease '1' et une MAC/DUID fixes ont toujours été suffisants pour moi. Est-ce que tu as des soucis de préfixe qui change ?
Merci pour ton retour Simon.
Je vais faire de nouveaux essais et, je posterai les résultats pour celles et ceux qui sont dans le même cas que moi.
Concernant le "préfixe qui change", je n'ai pas eu cette impression lorsque j'ai relevé les informations de ma Livebox5 avant la bascule.
Je joins à ce message une capture complète du message 'Solicit' de ma Livebox5.
Serais-tu dans quelle documentation je peux retrouver les éléments de configuration ci-dessous ?
[...]
list egress_qos_mapping '0:0'
list egress_qos_mapping '2:2'
list egress_qos_mapping '3:3'
list egress_qos_mapping '4:4'
list egress_qos_mapping '5:5'
list egress_qos_mapping '6:6'
list egress_qos_mapping '7:7'
list egress_qos_mapping '1:0'
list egress_qos_mapping '0:6'
[...]
D'avance, merci.
-
Serais-tu dans quelle documentation je peux retrouver les éléments de configuration ci-dessous ?
[...]
list egress_qos_mapping '0:0'
list egress_qos_mapping '2:2'
list egress_qos_mapping '3:3'
list egress_qos_mapping '4:4'
list egress_qos_mapping '5:5'
list egress_qos_mapping '6:6'
list egress_qos_mapping '7:7'
list egress_qos_mapping '1:0'
list egress_qos_mapping '0:6'
[...]
D'avance, merci.
Google répond https://lxr.openwrt.org/source/netifd/vlandev.c
-
Concernant le "préfixe qui change", je n'ai pas eu cette impression lorsque j'ai relevé les informations de ma Livebox5 avant la bascule.
Si ton préfixe ne change pas, pas besoin de tenter de le 'forcer' avec option reqprefix. Le préfixe sera lié au DUID/mac address. Il peut néanmoins changer (tres rarement) en cas de renumérotation du réseau d'accès Orange.
Les options egress_qos_mapping configurent le mapping entre traffic class (nftables) et valeurs de priorité Ethernet 802.1Q. Je suppose que cette option est documentée dans le wiki OpenWRT, mais je n'ai pas vérifié.
Note que tu n'as pas besoin que les solicit/request ressemblent bit à bit à ceux émis par la Livebox. Il faut certes spécifier certaines options pour obtenir un préfixe, mais la présence d'une option superflue ne devrait pas être bloquante.
-
Google répond https://lxr.openwrt.org/source/netifd/vlandev.c
Merci kfc ! ;)
-
Si ton préfixe ne change pas, pas besoin de tenter de le 'forcer' avec option reqprefix. Le préfixe sera lié au DUID/mac address. Il peut néanmoins changer (tres rarement) en cas de renumérotation du réseau d'accès Orange.
Les options egress_qos_mapping configurent le mapping entre traffic class (nftables) et valeurs de priorité Ethernet 802.1Q. Je suppose que cette option est documentée dans le wiki OpenWRT, mais je n'ai pas vérifié.
Note que tu n'as pas besoin que les solicit/request ressemblent bit à bit à ceux émis par la Livebox. Il faut certes spécifier certaines options pour obtenir un préfixe, mais la présence d'une option superflue ne devrait pas être bloquante.
Bonsoir,
Alors, je dois dire que j'ai fait une nouvelle série de tests aujourd'hui après tes conseils (encore merci Simon !) et, ça fonctionne !
Enfin ! j'y croyais plus.
Ci-dessous, la configuration actuelle :
[...]
config interface 'wan6'
option device 'eth0.832'
option proto 'dhcpv6'
option noclientfqdn '1'
option noacceptreconfig '1'
option reqaddress 'none'
option reqprefix 'auto'
option norelease '1'
option defaultreqopts '0'
option reqopts '11 17 23 24'
option clientid '00030001c0d7aab87321'
option userclass 'FSVDSL_livebox.Internet.softathome.Livebox5'
option vendorclass '0000040e0005736167656d'
option sendopts '11:00000000000000000000001a0900000558010341010d6674692f6b363737636679[CRYPT]'
[...]
J'ajoute également une copie d'écran du tableau de bord OpenWRT.
Bien à vous,
-
Super, well done!
-
Bonjour,
Suite a different test je n'ai toutjours pas de V6 j'ai fait le tcpdump mais je ne vois pas ce qui foire je mets les request ici :
Frame 1: 282 bytes on wire (2256 bits), 282 bytes captured (2256 bits)
Ethernet II, Src: ASUSTekC_6d:64:58 (MACROUTEur), Dst: IPv6mcast_01:00:02 (33:33:00:01:00:02)
Destination: IPv6mcast_01:00:02 (33:33:00:01:00:02)
Address: IPv6mcast_01:00:02 (33:33:00:01:00:02)
.... ..1. .... .... .... .... = LG bit: Locally administered address (this is NOT the factory default)
.... ...1 .... .... .... .... = IG bit: Group address (multicast/broadcast)
Source: ASUSTekC_6d:64:58 (MACROUTEur)
Address: ASUSTekC_6d:64:58 (MACROUTEur)
.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
Type: 802.1Q Virtual LAN (0x8100)
802.1Q Virtual LAN, PRI: 6, DEI: 0, ID: 832
110. .... .... .... = Priority: Internetwork Control (6)
...0 .... .... .... = DEI: Ineligible
.... 0011 0100 0000 = ID: 832
Type: IPv6 (0x86dd)
Internet Protocol Version 6, Src: fe80::692:26ff:fe6d:6458, Dst: ff02::1:2
0110 .... = Version: 6
.... 0000 0000 .... .... .... .... .... = Traffic Class: 0x00 (DSCP: CS0, ECN: Not-ECT)
.... 0000 00.. .... .... .... .... .... = Differentiated Services Codepoint: Default (0)
.... .... ..00 .... .... .... .... .... = Explicit Congestion Notification: Not ECN-Capable Transport (0)
.... .... .... 1000 1101 1110 1111 1001 = Flow Label: 0x8def9
Payload Length: 224
Next Header: UDP (17)
Hop Limit: 1
Source: fe80::692:26ff:fe6d:6458
Destination: ff02::1:2
[Source SA MAC: ASUSTekC_6d:64:58 (MACROUTEur)]
User Datagram Protocol, Src Port: 546, Dst Port: 547
Source Port: 546
Destination Port: 547
Length: 224
Checksum: 0x8ecf [unverified]
[Checksum Status: Unverified]
[Stream index: 0]
[Timestamps]
[Time since first frame: 0.000000000 seconds]
[Time since previous frame: 0.000000000 seconds]
DHCPv6
Message type: Solicit (1)
Transaction ID: 0x37a820
Elapsed time
Option: Elapsed time (8)
Length: 2
Value: 0c59
Elapsed time: 31610ms
Option Request
Option: Option Request (6)
Length: 8
Value: 0011001700180052
Requested Option code: Vendor-specific Information (17)
Requested Option code: DNS recursive name server (23)
Requested Option code: Domain Search List (24)
Requested Option code: SOL_MAX_RT (82)
Client Identifier
Option: Client Identifier (1)
Length: 10
Value: 00030001MACLB
DUID: 00030001MACLB
DUID Type: link-layer address (3)
Hardware type: Ethernet (1)
Link-layer address: MACLIVEBOX
Authentication
Option: Authentication (11)
Length: 70
Value: 00000000000000000000001a090000
Protocol: 0
Algorithm: 0
RDM: 0
Replay Detection: 0000000000000000
Authentication Information: 1a09000005
User Class
Option: User Class (15)
Length: 45
Value: 002b46535644534c5f6c6976
Vendor Class
Option: Vendor Class (16)
Length: 11
Value: 0000040e0005736167656d
Enterprise ID: SAGEMCOM SAS (1038)
vendor-class-data: sagem
Vendor-specific Information
Option: Vendor-specific Information (17)
Length: 22
Value: 000005580006000e495056365
Enterprise ID: Orange (1368)
option
Option code: 6
Option length: 14
Option data: 495056365f524551554553544544
Identity Association for Prefix Delegation
Option: Identity Association for Prefix Delegation (25)
Length: 12
Value: 000000010000000000000000
IAID: 00000001
T1: 0
T2: 0
Logiquement c'est bien anonimiser
j'ai pas de reponse a cette request du dhcpv6
jpeux poster ma config au cas ou
-
Bonjour,
Suite a different test je n'ai toutjours pas de V6 j'ai fait le tcpdump mais je ne vois pas ce qui foire je mets les request ici :
Frame 1: 282 bytes on wire (2256 bits), 282 bytes captured (2256 bits)
Ethernet II, Src: ASUSTekC_6d:64:58 (MACROUTEur), Dst: IPv6mcast_01:00:02 (33:33:00:01:00:02)
Destination: IPv6mcast_01:00:02 (33:33:00:01:00:02)
Address: IPv6mcast_01:00:02 (33:33:00:01:00:02)
.... ..1. .... .... .... .... = LG bit: Locally administered address (this is NOT the factory default)
.... ...1 .... .... .... .... = IG bit: Group address (multicast/broadcast)
Source: ASUSTekC_6d:64:58 (MACROUTEur)
Address: ASUSTekC_6d:64:58 (MACROUTEur)
.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
Type: 802.1Q Virtual LAN (0x8100)
802.1Q Virtual LAN, PRI: 6, DEI: 0, ID: 832
110. .... .... .... = Priority: Internetwork Control (6)
...0 .... .... .... = DEI: Ineligible
.... 0011 0100 0000 = ID: 832
Type: IPv6 (0x86dd)
Internet Protocol Version 6, Src: fe80::692:26ff:fe6d:6458, Dst: ff02::1:2
0110 .... = Version: 6
.... 0000 0000 .... .... .... .... .... = Traffic Class: 0x00 (DSCP: CS0, ECN: Not-ECT)
.... 0000 00.. .... .... .... .... .... = Differentiated Services Codepoint: Default (0)
.... .... ..00 .... .... .... .... .... = Explicit Congestion Notification: Not ECN-Capable Transport (0)
.... .... .... 1000 1101 1110 1111 1001 = Flow Label: 0x8def9
Payload Length: 224
Next Header: UDP (17)
Hop Limit: 1
Source: fe80::692:26ff:fe6d:6458
Destination: ff02::1:2
[Source SA MAC: ASUSTekC_6d:64:58 (MACROUTEur)]
User Datagram Protocol, Src Port: 546, Dst Port: 547
Source Port: 546
Destination Port: 547
Length: 224
Checksum: 0x8ecf [unverified]
[Checksum Status: Unverified]
[Stream index: 0]
[Timestamps]
[Time since first frame: 0.000000000 seconds]
[Time since previous frame: 0.000000000 seconds]
DHCPv6
Message type: Solicit (1)
Transaction ID: 0x37a820
Elapsed time
Option: Elapsed time (8)
Length: 2
Value: 0c59
Elapsed time: 31610ms
Option Request
Option: Option Request (6)
Length: 8
Value: 0011001700180052
Requested Option code: Vendor-specific Information (17)
Requested Option code: DNS recursive name server (23)
Requested Option code: Domain Search List (24)
Requested Option code: SOL_MAX_RT (82)
Client Identifier
Option: Client Identifier (1)
Length: 10
Value: 00030001MACLB
DUID: 00030001MACLB
DUID Type: link-layer address (3)
Hardware type: Ethernet (1)
Link-layer address: MACLIVEBOX
Authentication
Option: Authentication (11)
Length: 70
Value: 00000000000000000000001a090000
Protocol: 0
Algorithm: 0
RDM: 0
Replay Detection: 0000000000000000
Authentication Information: 1a09000005
User Class
Option: User Class (15)
Length: 45
Value: 002b46535644534c5f6c6976
Vendor Class
Option: Vendor Class (16)
Length: 11
Value: 0000040e0005736167656d
Enterprise ID: SAGEMCOM SAS (1038)
vendor-class-data: sagem
Vendor-specific Information
Option: Vendor-specific Information (17)
Length: 22
Value: 000005580006000e495056365
Enterprise ID: Orange (1368)
option
Option code: 6
Option length: 14
Option data: 495056365f524551554553544544
Identity Association for Prefix Delegation
Option: Identity Association for Prefix Delegation (25)
Length: 12
Value: 000000010000000000000000
IAID: 00000001
T1: 0
T2: 0
Logiquement c'est bien anonimiser
j'ai pas de reponse a cette request du dhcpv6
jpeux poster ma config au cas ou
Bonjour Nesquiik,
Si tu pouvais poster la partie configuration 'wan6' de ton fichier /etc/config/network de ton routeur OpenWRT.
Pour cela, il faudrait que tu te connectes en SSH au routeur.
Il te suffit d'anonymiser que le partie 'Authentification' (11) ...
Dans l'attente de te lire
-
Voici ma parti wan du fichier network :
config interface 'wan6'
option proto 'dhcpv6'
option device 'wan.832'
option reqprefix 'auto'
option reqaddress 'none'
option defaultreqopts '0'
option sendopts '11:XAUTH 15:FSVDSL_livebox.Internet.softathome.livebox4 16:0000040e0005736167656d 17:000005580006000e495056365f524551554553544544'
option reqopts '11 17 23 24'
option noclientfqdn '1'
option noacceptreconfig '1'
option clientid '00030001MACLB' # X correspond à la MAC de votre box après 00030001, ça sera également votre DUID.
config interface 'wan4'
option proto 'dhcp'
option device 'wan.832'
option hostname '*'
option broadcast '1'
option vendorid 'sagem'
option reqopts '1 3 6 15 28 51 58 59 90 119 125'
option sendopts '77:2b46535644534c5f6c697665626f782e496e7465726e65742e736f66746174686f6d652e4c697665626f7834 90:XAUTH'
option norelease '1'
option clientid '01MACLB' # MAJ 11/12/22, bientot necessaire, X correspond à la mac de la box après 01
config device
option name 'wan.832'
option type '8021q'
option ifname 'wan'
option vid '832'
list egress_qos_mapping '0:0'
list egress_qos_mapping '2:2'
list egress_qos_mapping '3:3'
list egress_qos_mapping '4:4'
list egress_qos_mapping '5:5'
list egress_qos_mapping '6:6'
list egress_qos_mapping '7:7'
list egress_qos_mapping '1:0'
list egress_qos_mapping '0:6'
-
Bonjour
Ce matin éclair de génie je reteste et fait juste une modification j'ai remplacer sur le device wan.832 la MAC address de mon routeur par la MAC de ma livebox et la que fut ma surprise quand j'ai vu le V6 ET le V4 monté et fonctionné
Tout est fonctionnel encore merci reste à faire la configuration du réseau interne
-
Bonjour,
Je viens de repasser chez Orange sur un forfait en VDSL. La fibre n'est pas encore arrivée par chez moi :(
J'ai ressorti un vieux modem BT HomeHub 5a que je viens de mettre à jour en openwrt 22.03.
Sur le tuto de la 1ere page, savez-vous ce qu'il faut modifier pour que cela fonctionne en vdsl ? Uniquement pour la connexion Internet car je n'ai pas besoin de TV ou de téléphone.
Merci d'avance à ceux et celles qui sont "encore" en adsl et qui pourraient m'aider ;)
-
Bonjour,
Je viens de repasser chez Orange sur un forfait en VDSL. La fibre n'est pas encore arrivée par chez moi :(
J'ai ressorti un vieux modem BT HomeHub 5a que je viens de mettre à jour en openwrt 22.03.
Sur le tuto de la 1ere page, savez-vous ce qu'il faut modifier pour que cela fonctionne en vdsl ? Uniquement pour la connexion Internet car je n'ai pas besoin de TV ou de téléphone.
Merci d'avance à ceux et celles qui sont "encore" en adsl et qui pourraient m'aider ;)
voir ici : https://lafibre.info/remplacer-livebox/remplacer-bt-hh5a-modemrouter-par-combo-bt-hh5a-modem-er-x-router-openwrt/msg871397/#msg871397
-
voir ici : https://lafibre.info/remplacer-livebox/remplacer-bt-hh5a-modemrouter-par-combo-bt-hh5a-modem-er-x-router-openwrt/msg871397/#msg871397
Je n'avais pas vu ce post. je vais tenter en me basant dessus.
Merci en tout cas !
-
Bonjour à tous. J'ai vu les mises à jour récentes sur le tuto concernant les options 61 et option 1 à ajouter respectivement coté ipv4 et ipv6. Chez moi cela fonctionne encore, mais si le déploiement est progressif autant anticiper le changement :)
Est-ce que l'adresse Mac à renseigner pour ces deux options est celle qui est affichée sur l'autocollant sous la livebox ?
Merci.
-
Tu peux mettre n'importe quelle adresse MAC, il n'est pas obligatoire que ce soit celle de la LB.
Par contre, il faut qu'elle soit maintenant identique en IPv4 et IPv6 dans les informations envoyées.
-
Hello,
Maj du tuto/github avec l'ajout de l'adresse mac, j'indique d'utiliser la mac de la livebox, même si en effet on peut mettre n'importe quoi tant que c'est synchro entre l'interface et les clients id.
Et personnellement, je suis passé à l'ont LXT-010H-D, ça marche à merveille, le combo routeur X86 2.5.Gbps cuivre + Leox commence à être accessible.
-
Hello,
Maj du tuto/github avec l'ajout de l'adresse mac, j'indique d'utiliser la mac de la livebox, même si en effet on peut mettre n'importe quoi tant que c'est synchro entre l'interface et les clients id.
Et personnellement, je suis passé à l'ont LXT-010H-D, ça marche à merveille, le combo routeur X86 2.5.Gbps cuivre + Leox commence à être accessible.
Bonjour, je suis tout nouveau dans le monde des routeurs et du remplacement Livebox. Je viens d'acheter un ASUS RT-AX53U et j'ai installé OpenWRT 22.03.3 dessus. J'ai suivi la configuration à partir de https://github.com/ubune/openwrt-livebox , j'ai correctement mis mon option 90 et changé eth0 en wan car c'est le nom de mon interface.
Mais même comme ça, mon routeur n'arrive pas à se connecter au réseau Orange. J'ai pourtant fait très attention à tout suivre à la lettre. Est-ce qu'il y aurait quelque chose en plus à faire ou à tester ? Je ne sais pas non plus comment avoir plus d'infos sur ce qui ne va pas. Est-ce que quelqu'un pourrait m'aider ? Dans les logs du routeur, je vois plusieurs message de ce type :
Sat Jan 21 20:01:38 2023 daemon.warn odhcp6c[2501]: Server returned IA_PD status 'No Prefix Available (No prefixes have been assigned)'
Sat Jan 21 20:01:39 2023 daemon.warn odhcp6c[2501]: Server returned IA_PD status 'No Prefix Available (No prefixes have been assigned)'
Sat Jan 21 20:01:40 2023 daemon.warn odhcp6c[2501]: Server returned IA_PD status 'No Prefix Available (No prefixes have been assigned)'
Voici tout mon dossier config avec mes paramètres :
https://anonfiles.com/Se82j4Tdye/config_7z
Mais je ne sais pas si c'est lié au problème ou non.
Merci d'avance pour toute réponse, bonne journée
EDIT : Problème résolu, j'ai refait toute la config en copiant les fichiers network, firewall et dhcp depuis le github plutôt que de les éditer pour éviter les erreurs, et ça marche. Merci énormément pour ces guides !
-
Je suis passé en 22.03.3, mais je me retrouve avec des pb de débit ???
Idle Latency: 15.88 ms (jitter: 2.49ms, low: 13.03ms, high: 18.00ms)
Download: 240.43 Mbps (data used: 311.9 MB)
33.92 ms (jitter: 3.06ms, low: 12.73ms, high: 45.76ms)
Upload: 4.54 Mbps (data used: 4.5 MB)
415.26 ms (jitter: 82.82ms, low: 84.93ms, high: 610.89ms)
Je tourné a 2100/600 avant, une idée ?
Tout semble OK, coté ipv4 et ipv6.
edit: erreur de ma part, j'ai oublié de remettre les regles nftables ::)
par contre j'avais pas fait attention, mais vous avez aussi 2 montage /boot ou pas ?
root@OpenWrt:~# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
mmcblk0 179:0 0 116.5G 0 disk
├─mmcblk0p1 179:1 0 16M 0 part /boot
│ /boot
├─mmcblk0p2 179:2 0 116.5G 0 part /
└─mmcblk0p128 259:0 0 239K 0 part
mmcblk0boot0 179:8 0 4M 1 disk
mmcblk0boot1 179:16 0 4M 1 disk
root@OpenWrt:~# df -h
Filesystem Size Used Available Use% Mounted on
/dev/root 115.0G 62.3M 114.9G 0% /
tmpfs 7.7G 336.0K 7.7G 0% /tmp
/dev/mmcblk0p1 16.0M 5.7M 10.2M 36% /boot
/dev/mmcblk0p1 16.0M 5.7M 10.2M 36% /boot
tmpfs 512.0K 0 512.0K 0% /dev
-
Bonjour,
j'essaie de faire le setup openwrt plus livebox sans m'occuper de la partie TV VOIP, mais je butte sur la partie IPV6, l ipv4 est operationnel mais les requetes IPV6 ne recoivent pas de réponses.
ce thread offre pas mal d infos, mais l info est pas mal eparpillée, et on trouve des differences entre la config sur le github de @ubune et la premiere page de ce thread. il serait peut etre bon consolider la config sur github avec qques commentaires en plus et la mettre juste en lien afin d eviter d avoir du mal à mettre a jour le thread et la conf github.
j'ai un peu de mal a comprendre quelle est l manip qui mes le COS a 6 dans toutes les configs (sont ce les rules NFT, ou bien les options mises dans le etc/config/network qui bidouillent le cos) que l'on fait, mais je suppose que dans mon cas c est bon.
Frame 600: 261 bytes on wire (2088 bits), 261 bytes captured (2088 bits)
Encapsulation type: Ethernet (1)
Arrival Time: Feb 3, 2023 12:06:57.213910000 CET
[Time shift for this packet: 0.000000000 seconds]
Epoch Time: 1675422417.213910000 seconds
[Time delta from previous captured frame: 0.054953000 seconds]
[Time delta from previous displayed frame: 0.054953000 seconds]
[Time since reference or first frame: 7.465024000 seconds]
Frame Number: 600
Frame Length: 261 bytes (2088 bits)
Capture Length: 261 bytes (2088 bits)
[Frame is marked: False]
[Frame is ignored: False]
[Protocols in frame: eth:ethertype:vlan:ethertype:ipv6:udp:dhcpv6]
[Coloring Rule Name: UDP]
[Coloring Rule String: udp]
Ethernet II, Src: IngramMi_5f:ac:d0 (mamacavecles:), Dst: IPv6mcast_01:00:02 (33:33:00:01:00:02)
Destination: IPv6mcast_01:00:02 (33:33:00:01:00:02)
Address: IPv6mcast_01:00:02 (33:33:00:01:00:02)
.... ..1. .... .... .... .... = LG bit: Locally administered address (this is NOT the factory default)
.... ...1 .... .... .... .... = IG bit: Group address (multicast/broadcast)
Source: IngramMi_5f:ac:d0 (mamacavecles:)
Address: IngramMi_5f:ac:d0 (mamacavecles:)
.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
Type: 802.1Q Virtual LAN (0x8100)
802.1Q Virtual LAN, PRI: 6, DEI: 0, ID: 832
110. .... .... .... = Priority: Internetwork Control (6)
...0 .... .... .... = DEI: Ineligible
.... 0011 0100 0000 = ID: 832
Type: IPv6 (0x86dd)
Internet Protocol Version 6, Src: fe80::5239:2fff:fe5f:acd0, Dst: ff02::1:2
0110 .... = Version: 6
.... 0000 0000 .... .... .... .... .... = Traffic Class: 0x00 (DSCP: CS0, ECN: Not-ECT)
.... 0000 00.. .... .... .... .... .... = Differentiated Services Codepoint: Default (0)
.... .... ..00 .... .... .... .... .... = Explicit Congestion Notification: Not ECN-Capable Transport (0)
.... 0001 1010 1000 0011 1010 = Flow Label: 0x1a83a
Payload Length: 203
Next Header: UDP (17)
Hop Limit: 1
Source Address: fe80::5239:2fff:fe5f:acd0
Destination Address: ff02::1:2
[Source SLAAC MAC: IngramMi_5f:ac:d0 (mamacavecles:)]
User Datagram Protocol, Src Port: 546, Dst Port: 547
Source Port: 546
Destination Port: 547
Length: 203
Checksum: 0xf07c [unverified]
[Checksum Status: Unverified]
[Stream index: 179]
[Timestamps]
[Time since first frame: 0.000000000 seconds]
[Time since previous frame: 0.000000000 seconds]
UDP payload (195 bytes)
DHCPv6
Message type: Solicit (1)
Transaction ID: 0x7a8abd
Elapsed time
Option: Elapsed time (8)
Length: 2
Elapsed time: 0ms
Option Request
Option: Option Request (6)
Length: 8
Requested Option code: Vendor-specific Information (17)
Requested Option code: DNS recursive name server (23)
Requested Option code: Domain Search List (24)
Requested Option code: SOL_MAX_RT (82)
Client Identifier
Option: Client Identifier (1)
Length: 10
DUID: 00030001mamac
DUID Type: link-layer address (3)
Hardware type: Ethernet (1)
Link-layer address: mamacavecles:
Vendor Class
Option: Vendor Class (16)
Length: 11
Enterprise ID: SAGEMCOM SAS (1038)
vendor-class-data: sagem
User Class
Option: User Class (15)
Length: 45
User Class suboption
Length: 43
Suboption: 46535644534c5f6c697665626f782e496e7465726e65742e736f66746174686f6d652e4c…
[Expert Info (Error/Malformed): User Class: suboption too long]
[User Class: suboption too long]
[Severity level: Error]
[Group: Malformed]
Authentication
Option: Authentication (11)
Length: 49
Protocol: 0
Algorithm: 0
RDM: 0
Replay Detection: 0000000000000000
Authentication Information: 1a0900000558010341010d6674692fmonauth3132…
Vendor-specific Information
Option: Vendor-specific Information (17)
Length: 22
Enterprise ID: Orange (1368)
option
Option code: 6
Option length: 14
Option data: 495056365f524551554553544544
Identity Association for Prefix Delegation
Option: Identity Association for Prefix Delegation (25)
Length: 12
IAID: 00000001
T1: 0
T2: 0
voilla un sollicit qui ne recoit jamais de réponse.
si jamais vous en avez une de réponse, ou au moins un élément :-) je suis preneur.
-
User Class
Option: User Class (15)
Length: 45
User Class suboption
Length: 43
Suboption: 46535644534c5f6c697665626f782e496e7465726e65742e736f66746174686f6d652e4c…
[Expert Info (Error/Malformed): User Class: suboption too long]
[User Class: suboption too long]
[Severity level: Error]
[Group: Malformed]
A première vue le problème est là.
-
le COS est il bon dans ma trame, je ne sais pas ou le repérer ?
edit: bizarre que le dissector indique une trame trop longue alors qu'elle a l'air bien formée, est ce un bug du dissector de wireshark ou bien un reel soucis de mon routeur a converti la chaine en hax et a trouver sa longueur ??
edit 2 : je regarde le code du dissector de wireshark pour voir si c est lui qui est moisi oubien mon paquet , si qqn est meilleur ue moi en code :
case OPTION_USER_CLASS:
{
temp_optlen = 0;
while (optlen > temp_optlen) {
subopt_len = tvb_get_ntohs(tvb, off + temp_optlen);
if (subopt_len > optlen - temp_optlen) {
expert_add_info_format(pinfo, option_item, &ei_dhcpv6_malformed_option, "User Class: suboption too long");
break;
}
subtree_2 = proto_tree_add_subtree(subtree, tvb, off+temp_optlen, subopt_len, ett_dhcpv6_userclass_option, &ti, "User Class suboption");
proto_tree_add_item(subtree_2, hf_option_userclass_length, tvb, off + temp_optlen, 2, ENC_BIG_ENDIAN);
proto_tree_add_item(subtree_2, hf_option_userclass_opaque_data, tvb, off + temp_optlen + 2, subopt_len, ENC_NA);
temp_optlen += subopt_len + 2;
}
break;
}
https://www.rfc-editor.org/rfc/rfc3315#section-22.15
je trouve aussi comme userclass dans le forum +FSVDSL_livebox.Internet.softathome.Livebox4 ....un plus devant donc, ce plus est il necessaire ou non, s agit il d un padding queconque pour palier a un bu de certains modeles de routeurs ?
la reference a ce string est aussi dans cet article : https://github.com/reinagliryc/mikrotik/blob/master/README.md , ou encore celui ci : https://vincent.bernat.ch/en/blog/2019-orange-livebox-linux
y a t il besoin du + dans la string, es ce une typo et un jour cela ne fonctionnera plus ? est ce un probleme d implementation des optionclass selon les plateformes, es ce le plus de la concatenation avec qqchose ?
edit : https://gitlab.com/wireshark/wireshark/-/issues/18032 a priori un bug connu et fixé de wireshark, je vais essayer de trouver un wireshark plus recent.
edit : remplacé la version 3.6.X fournie sous ubuntu 22.04 par la version PPA 3.6.7-1 et le paquet n'est plus flaggué comme etant mauvais par wireshark.
du coup @zoc, as tu une autre idée au regarde de la trame de ce qui pourrait ne pas coller ?
-
802.1Q Virtual LAN, PRI: 6, DEI: 0, ID: 832La CoS est bonne.
-
je continue l'investigation, j'ai sorti mon star lan tap de greatscott pour sniffer ur le cable entre mon routeur et L,ONT , alors que le tcpdump -i eth0 me donne des trames DHCPV6, je ne les voit pas passer sur le cable, alors que je vois bien passer un renew dhcp sur l ipv4 quand j'en provoque un avec le bouron restart sur l interface IPV4 dans la gui web d openwrt.
donc la question, qu es ce que le noyau linux peut encore bidouiller plus bas que ce que tcpdump ne peut capturer ? il a t il des regles de niveau 2 qui empecheraient IPV6 d envoyer un ICMP mais pas IPV4 (tout en se rappelant bien que je le capture avec un tcpdump) ?
edit, a priori j'ai testé via d autres methodes, le starlan TAP a l'air de poser de soucis au niveau de la capture des paquets, je recois bien les trames sollicit de dhcp V6, par contre malgré ce que j'ai inscrit dans ma conf, il ne requiert pas l'option 11
l livebox request le 11 le 23 le 17 et le 24
sur mon sniff je n'ai q'une demande d option 11
config interface 'wan6'
option device 'eth0.832'
option proto 'dhcpv6'
option noclientfqdn '1'
option noacceptreconfig '1'
option norelease '1'
option defaultreqopts '0'
option reqopts '11 17 23 24'
option clientid '000300015039macmac'
option vendorclass '0000040e0005736167656d'
option sendopts '11:00000000000000000000001a0900000558010341010DXXXXXXXXXXXXXXXXXXXXXX 17:000005580006000e495056365f524551554553544544 15:FSVDSL_livebox.Internet.softathome.Livebox5'
option reqaddress 'try'
option reqprefix '60'
pour l option 15 , jai bien verifié avec la livebox, elle envoie l'option 15 en : 15:FSVDSL_livebox.Internet.softathome.Livebox5' L majuscule et numero de la livebox 5.
j'ai bien reqopts 11 mais dans la trame je vois que 17 23 24 et 82. (je ne sais pas d ou sort le 82).
-
option reqaddress 'try'
option reqprefix '60'
il te faut reqaddress 'none' et reqprefix 'auto', à vue de nez.
-
effectivement je n'aivais pas vu cela, au debut je n'avait rien, cela dit cela ne fonctionne pas mieux, je n'avait pas du tout ces options au debut dans ma conf, je suppose qu'elles ne sont pas bloquantes pour obtenir un bail dhcp simple pour tester sans avoir de delegation de prefixe.
je me demande si mon mot de passe que m a communiqué le plus que tres moyen support orange sont corrects , y a til moyen d avoir acces a son mot de passe sans le demander mais via l'interface web, car ils etaient senses me l'envoyer en sms etpar mail mais je n'ai jamais recu ni l un ni l autre. ca a fini au telephoen a épeler le mot de passe.
PS : https://jsfiddle.net/kgersen/3mnsc6wy/ a l'air down c est la cata , y a t il un autre endroit ou recup un script pour generer la chaine hexa de l auth ?
-
Tu as aussi
option vendorclass '0000040e0005736167656d'
alors que je l'envoie comme une option à la mano :
option sendopts [...] 16:0000040e0005736167656d
Dans la doc, si tu utilises option vendorclass, il faut fournir une string, donc à priori simplement 'sagem' ? Aucune idée de comment udhcpc saurait qu'il faut envoyer l'enterprise ID 0x040e.
Si tu essayes avec l'option forgée en hexa directement (avec sendopts plutot que vendorclass), ca change quelque chose ?
Pour la chaine d'auth, si tu obtiens un bail DHCPv4, c'est qu'elle est bonne: tu peux simplement la copier et l'utiliser en DHCPv6. Chez moi, ce sont rigoureusement les mêmes.
-
bonne idée @simmon , c est un essai que j'ai fait effectivement a posteriori.
pour l auth en DHCP effectivement ce doit etre la bonne chaine, par contre es ce important que je ne fasse pas de req sur lo'ption 11 en V6 ?
edit : effectivement ren reverifiant, la chaine d auth n'etait plus non plus la bonne, j'ai du bugguer avec VI a un moment, mais toujours pas de bail dhcp , malgré reboot et power off on de l'ONT.
le truc frustrant la dedans c est qu on a zero reponse pour connaitre l'erreur
edit : je n'arrive toujours pas à avoir l'option 11 dans les options request, quand j inspecte la trame sollicit je ne comprend pas.
une autre difference notable lorsque je demande la delegation de prefixe, mon routeur openwrt met le IAID a 000001 , alors que la livebox met les 4 derniers octets de la mac dans le IAID.
mais a priori meme si je ne demande pas de delegation de prefixe en supprimant cette partie de cofn , je devrai au moins recuperer une ip V6 ?
-
ce thread offre pas mal d infos, mais l info est pas mal eparpillée, et on trouve des differences entre la config sur le github de @ubune et la premiere page de ce thread. il serait peut etre bon consolider la config sur github avec qques commentaires en plus et la mettre juste en lien afin d eviter d avoir du mal à mettre a jour le thread et la conf github.
Le tuto et le Github sont consolidés, la seul diff c'est en niveau des flux entrant du firewall, pas de quoi perturber quiconque, ou alors je loupe quelque chose...
J'ai une tonne de retour de personnes qui ont simplement pris le github, remplacer les 3 paramètres comme indiqué et tout fonctionne.
Pour ipv6 je pense qu'il est vraiment conseillé de spoof la mac/duid de la box, comme ça en + tu gardes le même préfixe après bascule sur openwrt.
-
oui, au debut je n'ai pas fait de copier coller car je ne comprenais pas bien le coup du switch , si c etait un truc soft ou hardware, au final l embrouille vient de mes multiples essais, on ne sait jamais trop si on met de l hexa ou de l ascii , j'ai passé pas mal de temps avec ce bug de wireshark.
maintenant j'ai recu une delegation de prefixe, par contre je ne comprend pas si le routeur lui meme recoit une IP ou si je dois la deduire de la delegation de prefixe, c est un peu paumant IPV6 , j'ai lu un bouquin dessus il y a 15 ans, mais maintenant j'ai les mains dedans.
-
maintenant j'ai recu une delegation de prefixe, par contre je ne comprend pas si le routeur lui meme recoit une IP ou si je dois la deduire de la delegation de prefixe, c est un peu paumant IPV6 , j'ai lu un bouquin dessus il y a 15 ans, mais maintenant j'ai les mains dedans.
Super, top que ca marche.
Le routeur ne recoit pas 'une' IPv6, mais un /56, soit 256 /64. Il va allouer un /64 par VLAN ou interface côté LAN, et assigner une adresse dans ce /64 sur cet interface.
Par exemple chez moi, j'ai plusieurs VLAN, dont l'un d'entre eux est déclaré comme ceci:
# VLAN 2
config interface 'vlan2'
option device 'br0.2'
option force_link '1'
option proto 'static'
option ip6assign '64'
option ip6hint '02'
ip6assign indique à netifd d'allouer un /64 du préfixe délégué par Orange (le /56).
ip6hint lui spécifie que je veux allouer le 2e /64 du préfixe délégué à cette interface.
En pratique, si Orange me délègue 2001:db8:16c4:3a00::/56, le VLAN déclaré ci-dessus se voit attribuer 2001:db8:16c4:3a02::/64, avec l'adresse 2001:db8:16c4:3a02::1 configurée sur l'interface locale du routeur.
-
ok, donc l'interface wan elle meme communique avec son adresse link local avec le routeur 'baobab' d orange :-)
du coup par contre c est tres angoissant, tout a coup on se retrouve avec toutes ses machines qui ont IPV6 sur internet avec les ports exposés en direct (si y a du samba qui traine etc etc).
le forward par defaut de tout n'est il pas trop permissif (le NAT en IPV4 fait une sorte de protection intrinseque que l'on ne trouve pas dans ipV6)
-
Il me semble que le forward par défaut fait du conntrack, et que seul le traffic initié par le LAN est autorisé, mais je n'en suis pas sûr... j'ai mon propre jeu de règles nftables, je n'utilise pas fw3/fw4.
Ceci dit, j'ai tendance à ne filtrer que le minimum au niveau du firewall, et notamment j'accepte le traffic entrant. Les machines sont bien protégées aujourd'hui (même windows) avec un firewall local activé par défaut. Sous linux, ufw fait des merveilles.
-
Pour ceux que ça intéresse voici le script tc qui modifie la CoS 6 ainsi que le DSCP sur ARP, DHCPv4, DHCPv6, ICMPv6.
Avoir installé en prérequis les paquets suivants : tc-tiny, kmod-sched, kmod-sched-prio sur un OpenWRT en 22.03.3.
0:0 et 6:6 doivent être appliqué dans la partie egress du VLAN.
#!/bin/sh
DEVICE="${1}"
# Configure a PRIO qdisc on a VLAN interface.
tc qdisc replace dev "${DEVICE}" root handle 1: prio
tc filter del dev "${DEVICE}"
# ARP
tc filter add dev "${DEVICE}" parent 1: prio 1 protocol 0x806 u32 \
match u32 0 0 \
action skbedit priority 0:6
# DHCPv4
tc filter add dev "${DEVICE}" parent 1: prio 2 u32 \
match ip ihl 5 0xf \
match u16 0x0000 0x1fff at 6 \
match ip protocol 17 0xff \
match ip sport 68 0xffff \
match ip dport 67 0xffff \
action skbedit priority 0:6 pipe \
action pedit munge ip tos set 0xc0 retain 0xfc pipe \
action csum ip4h
# DHCPv6
tc filter add dev "${DEVICE}" parent 1: prio 3 protocol ipv6 u32 \
match ip6 dst fe00::/7 \
match ip6 protocol 17 0xff \
match ip6 sport 546 0xffff \
match ip6 dport 547 0xffff \
action skbedit priority 0:6 pipe \
action pedit ex munge ip6 traffic_class set 0xc0 retain 0xfc
# ICMPv6
tc filter add dev "${DEVICE}" parent 1: prio 4 protocol ipv6 u32 \
match ip6 dst fe00::/7 \
match ip6 protocol 58 0xff \
action skbedit priority 0:6 pipe \
action pedit ex munge ip6 traffic_class set 0xc0 retain 0xfc
Script à placer dans /etc/config si un jour vous devez faire un backup.
chmod +x sur le fichier, puis modification à la main du rc.local ou via le web LuCi pour que le script soit lancé au boot. Voir script hotplug plus bas.
/etc/config/tc.sh intf.vlanid
Enfin il faudra utiliser un script hotplug et qui cette fois-ci marche pour tout le monde, quelque soit la plateforme :
#!/bin/sh
set -x
exec >>/tmp/hotplug.log 2>&1
VLAN=eth1.832
if [ "${ACTION}" == "add" ] && [ "${DEVICENAME}" == "${VLAN}" ]; then
/etc/config/tc.sh "${VLAN}"
fi
La variable VLAN est à modifier selon la configuration du routeur.
Puis enregistrer le fichier en tant que "10-tc" que l'on met dans le dossier /etc/hotplug.d/net
Après cela si on relance les interfaces en utilisant /etc/init.d/network restart le hotplug fait son taff et (re)lance le script. Il s'applique aussi dès le démarrage grâce à cette méthode.
Ne pas faire attention au VLAN ID utiliser dans les captures, c'est uniquement pour des tests dans une VM.
Résultat en DHCPv4 :
(https://i.ibb.co/9nw21rg/image.png)
DHCPv6 :
(https://i.ibb.co/jW8WCy5/image.png)
ICMPv6 :
(https://i.ibb.co/Sdsj10g/image.png)
-
A part un script firewall plus simple, est-ce que ça apporte quelque chose par rapport à la solution nftable ?
Plus propre ? Meilleur conso CPU ?
Je serais bien tenté sur mon ERX, mais j'ai peur de tout péter pour un gain pas forcément évident.
-
A part un script firewall plus simple, est-ce que ça apporte quelque chose par rapport à la solution nftable ?
Plus propre ? Meilleur conso CPU ?
Je serais bien tenté sur mon ERX, mais j'ai peur de tout péter pour un gain pas forcément évident.
C'est effectivement plus propre si on part du principe que la solution nftable doit d'abord être réglée à 0:6 en egress puis tout refiltrer le trafic derrière.
Au niveau CPU ça doit être mieux, après je n'ai pas pu voir de mon côté car j'utilise principalement du x86-64 et du ARM64 avec une puce switch intégré, donc aucun impact réel sur le CPU mais à voir sur du matériel plus limité.
-
Bonjour,
Pour ceux que ça intéresse voici le script tc qui modifie la CoS 6 ainsi que le DSCP sur ARP, DHCPv4, DHCPv6, ICMPv6.
[...]
Merci beaucoup pour ce script 8)
Je tentais de remettre ma config au propre, suite au post https://lafibre.info/remplacer-livebox/durcissement-du-controle-de-loption-9011-et-de-la-conformite-protocolaire
Tout fonctionnait, sauf le réglage du CoS 6 + DSCP sur les paquets ARP, DHCPv4, DHCPv6, ICMPv6.
Avec cette config, basée du premier post :
/etc/config/network
config device
option name 'eth1.832'
option type '8021q'
option ifname 'eth1'
option vid '832'
list egress_qos_mapping '1:0'
list egress_qos_mapping '0:6'
list egress_qos_mapping '6:6'
option macaddr 'xx:xx:xx:xx:xx:xx'
/etc/nftables.d/nft-prio6-rules.include
oifname "eth1.832" counter meta priority set 0:1
oifname "eth1.832" ip protocol icmp counter meta priority set 0:6
oifname "eth1.832" ip protocol igmp counter meta priority set 0:6
oifname "eth1.832" udp dport 67 counter meta priority set 0:6
oifname "eth1.832" udp dport 547 counter meta priority set 0:6
oifname "eth1.832" ip protocol icmpv6 counter meta priority set 0:6
... j'avais le comportant suivant suivant :
- TOUS les paquets sortant possèdent l'entête PRI:6
- Débit montant est faible
Comme si les règles nftables n'était pas prise en compte ...
Avec ton script lancé au démarrage + cette config :
/etc/config/network
config device
option name 'eth1.832'
option type '8021q'
option ifname 'eth1'
option vid '832'
list egress_qos_mapping '0:0'
list egress_qos_mapping '6:6'
option macaddr 'xx:xx:xx:xx:xx:xx'
... le comportement est OK (PRI:6 + DSCP:CS6).
Je n'ai pas pu vérifier le contenu de la 1ère requête DHCP envoyée, mais celles de renouvellement de bail sont OK.
A noter que si je réinitialise le réseau à l'aide de la commande /etc/init.d/restart, les règles tc sont perdues.
On retombe alors en PRI:0 + DSCP:CS0.
-
... j'avais le comportant suivant suivant :
- TOUS les paquets sortant possèdent l'entête PRI:6
- Débit montant est faible
Comme si les règles nftables n'était pas prise en compte ...
Il y a plusieurs moyen de vérifier si les rules sont chargées :
Exemple (en page 1) :
nft list ruleset | grep "set 0:"
Et tu avais bien "include" dans la configuration firewall ?
config include 'orange_rules'
option enabled '1'
option type 'nftables'
option path '/etc/nftables.d/nft-prio6-rules.include'
option position 'chain-append'
option chain 'mangle_postrouting'
Sinon merci pour le script, c'est vraiment propre.
Mais comme indiqué précédemment, l'éxecution du script requiert une image openwrt personnalisée ou alors l'installation des différents packages après passage en openwrt.
Le passage en 22.03 a permit de justement pouvoir remplacer la box avec une image native (aucun package à ajouter).
Sans démonstration de gain significatif je préfère laisser le tuto tel quel pour l'instant.
-
Bon j'ai mis en place chez moi avec le script tc.
Le débit est le même et le gain en CPU est marginal (j'ai fait 2 speedtest, j'ai du gagner 2/3% de CPU idle max sur le deuxième avec le tc).
Par contre le script hotplug ne fonctionne pas dans hotplug.d/iface chez moi sur mon edgerouter x.
Le script n'était trigger que sur "${DEVICE}" == "eth0.832" (au passage il manque un = sur ton deuxième test, et parfois quand je copie colle les scripts, sur certaines lignes vides je me retrouve avec un .. je sais pas si c'est mon firefox, mon vi ou autre, bref), une fois que l'interface avait reçu l'IP (et l'interface ne reçoit l'IP que si le script tc est passé, donc ça ne marchait pas). Je n'ai jamais de script trigger sur eth0 dans iface.
A la place j'ai mis le script dans hotplug.d/net et ça donne ça :
#!/bin/sh
if [ "${ACTION}" == "add" ] && [ "${DEVICENAME}" == "eth0.832" ]; then
/etc/config/tc.sh eth0.832
fi
Et là ça marche pour moi.
edit :
Et il faut penser à modifier sysupgrade.conf parce que j'ai l'impression que les scripts de hotplug custom ne sont pas backup par défaut.
-
Par contre le script hotplug ne fonctionne pas dans hotplug.d/iface chez moi sur mon edgerouter x.
Tu as quelle version de OpenWrt ?
-
La dernière stable 22.03.3.
Sur mon edgerouter x le script dans iface n'est jamais appelé sur eth0 seul. Il est appelé 2 fois, sur eth0.832, pour l'interface wan4 et pour l'interface wan6 mais une fois celle ci up (ce qui n'arrive que quand j'ai lancé le script tc), ça ne marche donc par pour moi.
En revanche dans net, je peux recevoir le signal add de eth0.832 qui me permet de lancer le script dès que l'interface existe, et la connexion se fait après normalement.
-
La dernière stable 22.03.3.
Sur mon edgerouter x le script dans iface n'est jamais appelé sur eth0 seul. Il est appelé 2 fois, sur eth0.832, pour l'interface wan4 et pour l'interface wan6 mais une fois celle ci up (ce qui n'arrive que quand j'ai lancé le script tc), ça ne marche donc par pour moi.
En revanche dans net, je peux recevoir le signal add de eth0.832 qui me permet de lancer le script dès que l'interface existe, et la connexion se fait après normalement.
J'ai remis au propre le post plus haut pour les prochains.
-
#!/bin/sh
if [ "${ACTION}" == "add" ] && [ "${DEVICENAME}" == "eth0.832" ]; then
/etc/config/tc.sh eth0.832
fi
C'est du sh ... et dans sh "==" est un alias de "=" et && un raccourci entre deux tests mais n'est pas un vrai test avec un vrai "and".
Normalement votre bout de code doit s'écrire :
#!/bin/sh
if [ "${ACTION}" = "add" -a "${DEVICENAME}" = "eth0.832" ]; then
/etc/config/tc.sh eth0.832
fi
My 2 cents ...
-
Il y a plusieurs moyen de vérifier si les rules sont chargées :
Exemple (en page 1) :
nft list ruleset | grep "set 0:"
Et tu avais bien "include" dans la configuration firewall ?
config include 'orange_rules'
option enabled '1'
option type 'nftables'
option path '/etc/nftables.d/nft-prio6-rules.include'
option position 'chain-append'
option chain 'mangle_postrouting'
Merci pour ta réponse :)
Je viens de refaire la manip pour vérifier.
Le fichier de config /etc/config/firewall est bien renseigné comme tel.
Comportement immédiatement après le démarrage :
root@OpenWrt:~# nft list ruleset | grep "set 0:"
oifname "eth1.832" counter packets 137 bytes 9421 meta priority set 0:1
oifname "eth1.832" ip protocol icmp counter packets 14 bytes 840 meta priority set 0:6
oifname "eth1.832" ip protocol igmp counter packets 0 bytes 0 meta priority set 0:6
oifname "eth1.832" udp dport 67 counter packets 0 bytes 0 meta priority set 0:6
oifname "eth1.832" udp dport 547 counter packets 0 bytes 0 meta priority set 0:6
oifname "eth1.832" ip protocol ipv6-icmp counter packets 0 bytes 0 meta priority set 0:6
Mais malgré ça :
- Flag 802.1Q "PRI: 6" sur tous les paquets sortants :(
- Débit 5 Mbps en upload.
J'ai donc rebasculé sur la solution /etc/config/tc.sh, même si elle nécessite des paquets supplémentaires (ce qui risque de compliquer un peu les futures MAJ le jour où le Cos 6 deviendra obligatoire sur ma connexion ... puisque sans accès WAN il faudra que je télécharge les ipk à la main à l'aide d'une connexion Internet de backup ;D)
Je viens de lui associer le script /etc/hotplug.d/net/10-tc de @Aize147 retouché par @Kana-chan :
C'est du sh ... et dans sh "==" est un alias de "=" et && un raccourci entre deux tests mais n'est pas un vrai test avec un vrai "and".
Normalement votre bout de code doit s'écrire :
#!/bin/sh
if [ "${ACTION}" = "add" -a "${DEVICENAME}" = "eth0.832" ]; then
/etc/config/tc.sh eth0.832
fi
Tout fonctionne dorénavant parfaitement ! 8)
- Au démarrage : PRI:6 + DSCP:CS6 sur les paquets DHCP/ARP ... les autres en priorité 0
- Toujours OK après un /etc/init.d/network restart
- Upload @300 Mbps
Un grand merci !
-
C'est du sh ... et dans sh "==" est un alias de "=" et && un raccourci entre deux tests mais n'est pas un vrai test avec un vrai "and".
Oh purée merci beaucoup. Effectivement j'ai été perturbé par le fait je fais quelquefois plutôt du bash (avec les [[ ) et le fait que dans d'autres langages = à la place de == ça marche moins bien :)
Comme Electrocut, j'ai mis à jour !
-
Je dirai même que si vous avez qu'une seule ligne dans votre partie then et rien dans else alors votre code peut se résumer à cela :
#!/bin/sh
[ "${ACTION}" = "add" -a "${DEVICENAME}" = "eth0.832" ] && /etc/config/tc.sh eth0.832
Mais cela dépend des versions de sh, de mémoire.
En sh, le "&&" veut dire "then" et le "||" veux dire "else" !
Comme si vous tapez sur une ligne de commande :
[ "$test" = "test" ] && echo "OK" || echo "KO"
Si $test = test alors cela affiche OK sinon KO.
-
Merci pour ta réponse :)
Je viens de refaire la manip pour vérifier.
Le fichier de config /etc/config/firewall est bien renseigné comme tel.
Comportement immédiatement après le démarrage :
root@OpenWrt:~# nft list ruleset | grep "set 0:"
oifname "eth1.832" counter packets 137 bytes 9421 meta priority set 0:1
oifname "eth1.832" ip protocol icmp counter packets 14 bytes 840 meta priority set 0:6
oifname "eth1.832" ip protocol igmp counter packets 0 bytes 0 meta priority set 0:6
oifname "eth1.832" udp dport 67 counter packets 0 bytes 0 meta priority set 0:6
oifname "eth1.832" udp dport 547 counter packets 0 bytes 0 meta priority set 0:6
oifname "eth1.832" ip protocol ipv6-icmp counter packets 0 bytes 0 meta priority set 0:6
Mais malgré ça :
- Flag 802.1Q "PRI: 6" sur tous les paquets sortants :(
- Débit 5 Mbps en upload.
Dernier point car il n'y a pas de raison que ça ne fonctionne pas chez toi mais chez tous les autres.
Tu avais bien ces trois lignes egress dans ton fichier network (ton eth1.832) ?
config device
option name 'eth1.832'
option type '8021q'
option ifname 'eth1'
option vid '832'
list egress_qos_mapping '1:0'
list egress_qos_mapping '0:6'
list egress_qos_mapping '6:6'
-
Elles y étaient bien (sinon les paquets seraient sortis en priorité 0 et non en priorité 6).
Dans /etc/network/firewall, j'ai config flow_offloading '1' et config flow_offloading_hw '1' (pour une meilleure performance de routage sur mon TP-Link Archer C7).
Ça pourrait peut-être expliquer que les règles nftables mangle_postrouting ne fonctionnent pas, bien qu'elles soient actives ?
-
J'ai donc rebasculé sur la solution /etc/config/tc.sh, même si elle nécessite des paquets supplémentaires (ce qui risque de compliquer un peu les futures MAJ le jour où le Cos 6 deviendra obligatoire sur ma connexion ... puisque sans accès WAN il faudra que je télécharge les ipk à la main à l'aide d'une connexion Internet de backup ;D)
Pas besoin, tu peux utiliser https://firmware-selector.openwrt.org/ (https://firmware-selector.openwrt.org/) pour créer une image avec les paquets déjà inclus.
Il faut juste ajouter dans la liste les 3 paquets nécessaire, à savoir tc-tiny | kmod-sched | kmod-sched-prio. Cela va d'ailleurs télécharger automatiquement les dépendances et ainsi compiler l'image.
(https://i.ibb.co/hKnXyBb/image.png)
-
Merci pour l'astuce, je ne savais pas que c'était possible 8)
-
Merci pour l'astuce, je ne savais pas que c'était possible 8)
Et encore + sympa, utiliser l'image builder directement !
L'avantage c'est que tu peux te preinstaller les packages, mais même le /etc avec ta config.
Exemple ce lien pour dl l'image builder correspondant à ton ath79, il contiendra tous les profil pour tous les device avec ce soc.
https://downloads.openwrt.org/releases/22.03.3/targets/ath79/generic/openwrt-imagebuilder-22.03.3-ath79-generic.Linux-x86_64.tar.xz
Petite astuce pour générer une image en quelques secondes (encore + fun si tu as déjà un routeur openwrt fonctionnel !)
Voici ma conf pour générer l'image (exemple en x86) !
cd openwrt-imagebuilder-22.03.3-x86-64.Linux-x86_64/
mkdir -p files/etc/
scp root@192.168.229.1:/etc/* files/etc/
FILES="files"
make image PROFILE="generic" PACKAGES="htop luci-ssl luci-app-sqm tcpdump nano iperf3 luci-app-wireguard prometheus-node-exporter-lua prometheus-node-exporter-lua-nat_traffic prometheus-node-exporter-lua-netstat prometheus-node-exporter-lua-openwrt" FILES="files"
Dans ton cas,
tu remplaces :
openwrt-imagebuilder-22.03.3-x86-64.Linux-x86_64par : nom du rep dezippé de ton imagebuilder pour soc ath79 téléchargé via le lien
scp root@192.168.229.1:/etc/* files/etc/
Tu remplaces 192.168.229.1 par l'ip de ton routeur qui tourne actuellement. # En gros ici on copie tout le /etc du routeur fonctionnel vers le /etc qui ira dans l'img à build
image PROFILE="generic"Tu remplaces "generic" par le profil correspondant à ton routeur, (l'image builder contiendra de base tous les profil pour soc ath79).
Et ensuite tu personnalises les packages par rapport à tes besoins.
Et la tu obtiens carrément un .img qui peut s'installer sur tous TP-Link Archer C7 et qui contient directement toute la configuration et les packages que tu as choisi ;).
L'avantage c'est que du coup tu peux juste envoyer un .img à quelqu'un qui n'ira pas trop bidouiller et hop openwrt installé avec la bonne conf.
Pour x86 c'est top aussi, ça permet d'ecrire l'img directement sur un ssd et au premier boot tout fonctionnera !
Et donc bien entendu, si vous n'avez pas encore de routeur openwrt fonctionnel, rien ne vous empêche de prendre le /etc du github, le personnaliser et l'inclure dans l'img ;).
-
Merci pour ces précieux conseils ;)
-
Je valide, merci Ubune !
-
Bonjour, je possède actuellement un ASUS RT-AC88U sous DDWRT, une veille version car le tuto n'est pas à jour pour les version récentes et cela ne fonctionne plus, j'ai donc envie de passer sous OpenWRT.
Quelqu'un a déjà essayé avec ce routeur et pourrait me confirmer que tout roule en suivant le tuto à la lettre ?
Merci ! :)
-
Ubune, sais tu si on peut intégrer un ipk (compilé de son coté) avec la méthode de l'imagebuilder lors de la génération de l'image ?
@Drakal
Si ton routeur est compatible avec Openwrt 22.03.3 (ce qui semble cas: https://openwrt.org/toh/asus/rt-ac88u)
Alors RAS, tu pourras suivre le tuto sans soucis :)
-
Merci, je teste ça ce week-end ! :)
-
Je suis sur un AC88U et je peux dire que tout fonctionne a merveille depuis plus d'un mois maintenant
-
Bonjour à tous,
j'utilise openwrt depuis la version 19 à la place de la livebox avec beaucoup de plaisir en suivant la procédure de ce post.
subitement, cette nuit vers 2h du matin, plus d'internet, je reçois bien une IPv4 (mais en 172.16/16) et une IPv6 (y compris délégation de préfixe) mais aucun routage, nada, niet, que dalle !
j'y ai passé 2h sans succès, j'ai remis ça à ce matin (coup de bol je ne travaille pas aujourd'hui)
j'ai donc remis la livebox qui n'avait pas servi depuis ... ouch, toujours ;o)
et hop, après une bonne mise à jour automatique, internet remarche (mais pas tous le reste du coup, vlans y tout y tout)
du coup petit tour sur ce forum pour mettre à jour ma conf (nouvelles options dhcp, ID avec l'adresse mac etc ...) mais sans plus de succès.
Toujours un bail fourni en 172.16/16, toujours de l'IPv6 ... mais toujours pas de net, aucun routage, rien :o(
je suis sous openwrt 22.02.0 ... dois-je impérativement mettre à niveau en 22.02.3 pour que cela fonctionne ? (je ne pense pas)
une idée quelconque de ce que je peux/dois tester pour me remettre mon bazar en service ?
Merci à tous pour vos réponses
EDIT:
La seule différence que je vois avec ce que j'ai dans ma conf et ce qui est demandé aujourd'hui c'est l'encodage du compte utilisateur pour l'option 90.
à l'époque il fallait faire (issu du github):
Convertir le FTI en hexa (fti/qpq8888 = valeur créée pour l'exemple des fichiers de configuration):
echo -n 'fti/qpq8888' | xxd -p
Récupérer les fichiers et éditer /etc/config/network :
Remplacer 6674692f71707138383838 par le vrai FTI
et aujourd'hui:
Remplacer XAUTH dans /etc/config/network (2 occurences) par le vrai FTI généré à l'aide du script de Kgersen ici : https://jsfiddle.net/kgersen/3mnsc6wy/
sauf que cette page demande le login orange (j'ai) et un mot de passe ... et là je ne l'ai pas, ou plutôt je ne sais pas quel est le mot de passe attendu ou si je dois le laisser vide pour générer la chaine de l'option 90
EDIT 2 :
C'est bon !!!!!!!!!!!!!!
J'ai trouvé mon bonheur ici: https://lafibre.info/remplacer-livebox/cacking-nouveau-systeme-de-generation-de-loption-90-dhcp/msg942041/#msg942041
c'est bien la chaine des options 90 (IPv4) et 11 (IPv6) qui ont changé de format .. comme je n'ai pas pu trouver l'info dans aucun post au sujet de si il fallait renseigner un MdP particulier (ou le laisser vide dans le site de génération de la chaine) et le cas échéant ou le trouver j'ai été bien content de trouver ce post qui propose l'outil LiveBoxInfo qui me l'a donné cadeau le code à rallonge
-
Bonjour,
Depuis cette nuit (heure indéterminée entre 1h et 7h30), mon routeur OpenWRT n'a plus accès au réseau Orange. Je n'ai pas touché à ma configuration (qui marchait très bien pendant environ 1 mois). L'ONT est au vert. J'en déduis qu'il y a eu des modifications au niveau du réseau Orange. Mais je ne sais pas exactement quel est le problème ni comment le résoudre. Je suis donc preneur de toute aide ou réponse que vous pourriez apporter.
J'ai suivi la configuration venant de https://github.com/ubune/openwrt-livebox/tree/master/22-03/etc%20-%20wan%20name%20interface%20%3D%20eth0. J'y ai ajouté un service de DNS over HTTPS (que j'ai désactivé, mais ce n'était pas ça le problème) et c'est à peu près tout. Donc je ne comprends pas ce qui a pu se passer. Bon dans le pire des cas j'ai toujours ma livebox dans un carton mais ça m'embêterai de devoir abandonner mon routeur openwrt qui me permet tellement plus de choses.
Voici le contenu de mes fichiers de config (si vous avez besoin d'info supplémentaire pour m'aider n'hésitez pas, je suis débutant donc je ne sais pas encore ce qui est pertinent à donner comme info):
root@OpenWrt:/etc/config# cat network
config interface 'loopback'
option device 'lo'
option proto 'static'
option ipaddr '127.0.0.1'
option netmask '255.0.0.0'
config device
option name 'br-lan'
option type 'bridge'
list ports 'lan1'
list ports 'lan2'
list ports 'lan3'
config interface 'lan'
option device 'br-lan'
option proto 'static'
option netmask '255.255.255.0'
option ip6assign '64'
option ip6ifaceid '::cafe'
option ipaddr '192.168.1.1'
config interface 'wan6'
option proto 'dhcpv6'
option device 'wan.832'
option reqprefix 'auto'
option reqaddress 'none'
option defaultreqopts '0'
option sendopts '11:[mon option 90] 15:FSVDSL_livebox.Internet.softathome.livebox4 16:0000040e0005736167656d 17:000005580006000e495056365f524551554553544544'
option reqopts '11 17 23 24'
option noclientfqdn '1'
option noacceptreconfig '1'
option clientid '000300017CC1777DD1A0'
config interface 'wan4'
option proto 'dhcp'
option device 'wan.832'
option hostname '*'
option broadcast '1'
option vendorid 'sagem'
option reqopts '1 3 6 15 28 51 58 59 90 119 125'
option sendopts '77:2b46535644534c5f6c697665626f782e496e7465726e65742e736f66746174686f6d652e4c697665626f7834 90:[mon option 90]'
option clientid '017CC1777DD1A0'
config device
option name 'wan.832'
option type '8021q'
option ifname 'wan'
option vid '832'
list egress_qos_mapping '1:0'
list egress_qos_mapping '0:6'
list egress_qos_mapping '6:6'
option macaddr '7C:C1:77:7D:D1:A0'
config device
option name 'eth0'
config device
option type 'bridge'
option name 'br-guest'
config interface 'guest'
option proto 'static'
option device 'br-guest'
option ipaddr '192.168.3.1'
option netmask '255.255.255.0'
root@OpenWrt:/etc/config# cat firewall
config defaults
option synflood_protect '1'
option input 'DROP'
option output 'DROP'
option forward 'DROP'
option flow_offloading '1'
option flow_offloading_hw '1'
config include 'orange_rules'
option enabled '1'
option type 'nftables'
option path '/etc/nftables.d/nft-prio6-rules.include'
option position 'chain-append'
option chain 'mangle_postrouting'
config zone
option name 'lan'
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'ACCEPT'
list network 'lan'
config zone
option name 'wan'
option output 'ACCEPT'
option family 'ipv4'
option input 'DROP'
option forward 'DROP'
option masq '1'
list network 'wan4'
config forwarding
option src 'lan'
option dest 'wan'
config rule
option name 'Allow-DHCP-Renew'
option src 'wan'
option proto 'udp'
option dest_port '68'
option target 'ACCEPT'
option family 'ipv4'
config rule
option name 'Allow-Ping'
option src 'wan'
option proto 'icmp'
option icmp_type 'echo-request'
option family 'ipv4'
option target 'ACCEPT'
config rule
option name 'Allow-IGMP'
option src 'wan'
option proto 'igmp'
option family 'ipv4'
option target 'ACCEPT'
config rule
option name 'Allow-DHCPv6'
option proto 'udp'
option dest_port '546'
option family 'ipv6'
option target 'ACCEPT'
option src 'wan6'
list src_ip 'fc00::/6'
list dest_ip 'fc00::/6'
config rule
option name 'Allow-MLD'
option proto 'icmp'
option family 'ipv6'
option target 'ACCEPT'
option src 'wan6'
list src_ip 'fe80::/10'
config rule
option name 'Allow-ICMPv6-Input'
option proto 'icmp'
option limit '1000/sec'
option family 'ipv6'
option target 'ACCEPT'
list icmp_type 'bad-header'
list icmp_type 'destination-unreachable'
list icmp_type 'echo-reply'
list icmp_type 'echo-request'
list icmp_type 'neighbour-advertisement'
list icmp_type 'neighbour-solicitation'
list icmp_type 'packet-too-big'
list icmp_type 'router-advertisement'
list icmp_type 'router-solicitation'
list icmp_type 'time-exceeded'
list icmp_type 'unknown-header-type'
option src 'wan6'
config rule
option name 'Allow-ICMPv6-Forward'
option dest '*'
option proto 'icmp'
option limit '1000/sec'
option family 'ipv6'
option target 'ACCEPT'
option src 'wan6'
list icmp_type 'bad-header'
list icmp_type 'destination-unreachable'
list icmp_type 'echo-reply'
list icmp_type 'echo-request'
list icmp_type 'packet-too-big'
list icmp_type 'parameter-problem'
list icmp_type 'time-exceeded'
list icmp_type 'unknown-header-type'
config zone
option name 'wan6'
option output 'ACCEPT'
option family 'ipv6'
list device 'wan.832'
option forward 'ACCEPT'
option input 'DROP'
list network 'wan6'
config forwarding
option src 'lan'
option dest 'wan6'
config forwarding
option src 'wan6'
option dest 'lan'
config include 'miniupnpd'
option type 'script'
option path '/usr/share/miniupnpd/firewall.include'
config redirect
option dest 'lan'
option target 'DNAT'
option name 'HTTP'
list proto 'tcp'
option src 'wan'
option src_dport '80'
option dest_ip '192.168.1.36'
option dest_port '80'
config redirect
option dest 'lan'
option target 'DNAT'
option name 'HTTPS'
list proto 'tcp'
option src 'wan'
option src_dport '443'
option dest_ip '192.168.1.36'
option dest_port '443'
config zone
option name 'guest'
option input 'REJECT'
option output 'ACCEPT'
option forward 'REJECT'
list network 'guest'
config forwarding
option src 'guest'
option dest 'wan'
config forwarding
option src 'guest'
option dest 'wan6'
config rule
option name 'Allow-DNS-Guest'
option src 'guest'
option dest_port '53'
option target 'ACCEPT'
config rule
option name 'Allow-DHCP-Guest'
option family 'ipv4'
list proto 'udp'
option src 'guest'
option src_port '68'
option dest_port '67'
option target 'ACCEPT'
root@OpenWrt:/etc/config# cat dhcp
config dnsmasq
option domainneeded '1'
option localise_queries '1'
option rebind_protection '1'
option rebind_localhost '1'
option local '/lan/'
option domain 'lan'
option expandhosts '1'
option authoritative '1'
option readethers '1'
option leasefile '/tmp/dhcp.leases'
option resolvfile '/tmp/resolv.conf.d/resolv.conf.auto'
option localservice '1'
option ednspacket_max '1232'
list server '127.0.0.1#5053'
list server '/mask.icloud.com/'
list server '/mask-h2.icloud.com/'
list server '/use-application-dns.net/'
list server '127.0.0.1#5054'
option doh_backup_noresolv '-1'
option noresolv '1'
list doh_backup_server '127.0.0.1#5053'
list doh_backup_server '/mask.icloud.com/'
list doh_backup_server '/mask-h2.icloud.com/'
list doh_backup_server '/use-application-dns.net/'
list doh_backup_server '127.0.0.1#5054'
config dhcp 'lan'
option interface 'lan'
option start '10'
option limit '50'
option leasetime '12h'
option dhcpv4 'server'
option ra 'server'
list ra_flags 'none'
config odhcpd 'odhcpd'
option maindhcp '0'
option leasefile '/tmp/hosts/odhcpd'
option leasetrigger '/usr/sbin/odhcpd-update'
option loglevel '4'
config host
option name 'DietPi'
option dns '1'
option mac 'DC:A6:32:0D:EF:12'
option ip '192.168.1.36'
config dhcp 'guest'
option interface 'guest'
option start '100'
option limit '150'
option leasetime '12h'
config host
option name 'wled-WLED'
option ip '192.168.1.50'
option mac '84:F3:EB:21:B3:62'
Toute réponse est la bienvenue, passez une agréable soirée.
EDIT : Je viens de rebrancher la livebox et elle arrive bien à se connecter au réseau. Je pense donc bien qu'il y a eu une modification du réseau Orange, mais je n'ai aucune idée de laquelle.
EDIT 2 : Je viens d'utiliser cet outil : https://lafibre.info/remplacer-livebox/cacking-nouveau-systeme-de-generation-de-loption-90-dhcp/msg942041/#msg942041 (merci @vevere), et l'option 90 donnée par l'outil est différente de celle qui m'a été donnée par orange (et que j'ai entrée dans mon routeur). Les identifiants fibre peuvent changer ???? Je vais essayer de le modifier.
EDIT 3 : C'ETAIT BIEN CA !!!! J'ai changé mon option 90 par la nouvelle donnée par l'outil et ça marche à nouveau. Donc je peux confirmer qu'Orange a changé mon option 90. Je ne savais pas du tout que c'était possible. Je suppose donc que mes identifiants fti ont changé aussi, je vais les leur redemander pour en savoir plus. Vous auriez des informations à apporter sur ce changement ? C'est quelque chose de commun ?
EDIT 4 : bien que j'ai retrouvé une ipv4 et mon accès internet, je n'ai par contre pas d'ipv6. Je ne saurai dire si c'est lié au problème que j'ai eu aujourd'hui ou si c'est antérieur par contre. Mais si quelqu'un a une idée de ce qui pourrait causer ça, je suis preneur. bonne soirée
-
je ne connais pas openwrt mais :
Pour ipv6 option 11 est l'équivalent de option 90 en ipv4, donc option 11 doit avoir la même valeur que option 90. Vue que option 90 n'était pas bonne, je pense que ce changement résoudra le soucis.
Pour les identifiants appeler le 3900, ils l'envoi par SMS.
-
Merci pour la réponse.
J'ai bien remplacé tous les endroits où l'option 90 doit être entrée, donc aussi dans l'option 11 du wan6 mais je n'ai pas d'ipv6. Le 3900 me refuse comme je suis abonné sosh. C'est un peu con, ils ont ce bot fait pour servir mais à la place je vais devoir appeler un opérateur humain aux horaires d'ouverture. Mais bon c'est comme ça.
EDIT : J'ai réutilisé l'outil, et selon lui mon option 90 ipv4 et mon option 11 ipv6 ne sont pas les même valeurs, contrairement à ce que dit le guide. Je vais essayer de changer ça aussi.
EDIT 2 : Non, toujours pas d'ipv6.
-
Le 3900 me refuse comme je suis abonné sosh.
réitère :)
concernant les abos sosh, notamment fibre/fixe, en insistant un peu avec le robot hotliner il est tut à fait possible d'avoir un support téléphonique
c'est juste que ca ce fait presque à la tete de l'abonné, ou du moins au bon vouloir du hotliner qui décroche
mais à faire l'essai plusieurs fois par jour c'est certain que tu peux avoir quelqu'un à l'écoute
après qu'il comprenne le probleme et t'escalade vers les bons niveaux c'est une autre affaire :)
-
réitère :)
concernant les abos sosh, notamment fibre/fixe, en insistant un peu avec le robot hotliner il est tut à fait possible d'avoir un support téléphonique
c'est juste que ca ce fait presque à la tete de l'abonné, ou du moins au bon vouloir du hotliner qui décroche
mais à faire l'essai plusieurs fois par jour c'est certain que tu peux avoir quelqu'un à l'écoute
après qu'il comprenne le probleme et t'escalade vers les bons niveaux c'est une autre affaire :)
Quand je dis qu'il refuse, ce n'est pas une personne qui refuse. Je tombe sur un robot, qui me demande d'entrer mon numéro de ligne, et qui me dit "vous êtes un client sosh, allez sur sosh.fr, bonne journée". Je vais réessayer avec le numéro dédié sosh.
Après je veux bien tenter de l'amadouer avec des barrettes de ram mais je doute qu'il soit ouvert aux pourparlers.
-
Quand je dis qu'il refuse, ce n'est pas une personne qui refuse. Je tombe sur un robot, qui me demande d'entrer mon numéro de ligne, et qui me dit "vous êtes un client sosh, allez sur sosh.fr, bonne journée". Je vais réessayer avec le numéro dédié sosh.
Après je veux bien tenter de l'amadouer avec des barrettes de ram mais je doute qu'il soit ouvert aux pourparlers.
excepté le sav/hotline free, pour tous les autres, meme de temps en temps sans y etre abonné (desimlockage par ex) j'ai toujours rusé en utilisant un no de tel trouvé en 3 min sur google (jamais celui en propre de ma ligne)
ya deux mois, jsuis tombé sur le sav orange pro, avec un commercial très sympa qui m'a passé le serice tech
faut juste pas avoir peur de passer 20/30 min au tel (et essayer différents numéros de ligne) ; c'estu n petit défi mais ca fonctionne à la fin
-
<-- Tutoriel vous permettant de remplacer votre Livebox par un routeur avec système d'exploitation Linux Openwrt. -->
Edit 11/12/2022 : Durcissement du controle d'Orange (Option 61 ipv4 et option 1 ipv6), attention il est necessaire de configurer les deux piles correctement.
Merci pour l'update ! Je me suis fait déco hier (durcissement options). J'ai du modifier la conf ce qui fut facile avec votre super doc :)
-
Merci pour l'update ! Je me suis fait déco hier (durcissement options). J'ai du modifier la conf ce qui fut facile avec votre super doc :)
C'est marrant car j'avais vu cette info, mais je dois être miro, je ne trouve pas, ni dans le tuto ni dans le github, à quel endroit sont déclarées ces 2 options (option 61 ipv4 et option 1 ipv6)
dans mon cas c'est le changement de calcul de l'identifiant (option 90 ipv4 et option 11 ipv6) grâce au petit outil (https://lafibre.info/remplacer-livebox/cacking-nouveau-systeme-de-generation-de-loption-90-dhcp/msg942041/#msg942041 (https://lafibre.info/remplacer-livebox/cacking-nouveau-systeme-de-generation-de-loption-90-dhcp/msg942041/#msg942041)) que j'ai cité plus haut qui a réglé mon souci de connexion, et au passage j'ai déclaré les "option clientid '01XXXXXXXXXX'" avec la MAC de la box ... ça ne mange pas de pain de l'avoir mis.
J'ai été incapable de générer mes options 90/11 avec la page https://jsfiddle.net/kgersen/3mnsc6wy/ (pas su quoi mettre dans les champs "mot de passe Orange" et "salt").
ce petit calculateur doit certainement fonctionner très bien mais je n'ai pas su être devin pour savoir quoi lui donner à manger ... j'ai surement le "mot de passe" qui doit trainer sur un papelard quelconque que Sosh à du me donner il y a 2 ans mais j'ai du le paumer depuis. Donc l'outil m'a sauvé sur ce coup là.
-
Bonsoir,
Pareil pour moi j'ai utilisé l'outil pour allez chercher les options sur la LB. J'ai bien retrouvé le courrier Sosh avec fti et password mais c’était a l'origine pour l'ADSL et ils ont changé lors de la migration en fibre.
Sur le site Sosh, seul le fti est donné. Je sais pas si on peut obtenir le mot de passe via le chat. Il faudrait que je tente.
-
Je suis sur un AC88U et je peux dire que tout fonctionne a merveille depuis plus d'un mois maintenant
Bonjour, j'ai également un RT-AC88U mais je ne parviens pas à monter OpenWrt pas la méthodde facile, le routeur reste planté , et meme un of/on ne regle rien ?
Auriez vous une piste ?
A PLUS
-
bonjour à tous,
Voir mon post précédent, j'ai abandonné l'installation de la version OpenWrt 33.03.3 qui ne s'installa pas sur mon RT-AC88U (en mode facile ou "TFTP") et j'ai opté pour la version 33.03.2 qui s'est installée au premier essai .....
Y a t il un inconvénient , une incompatibilité potentielle avec les protocoles Orange de nos jours ? , des modifications à faire ?
MercI pour votre éclairage ..
A PLUS
-
Voir mon post précédent, j'ai abandonné l'installation de la version OpenWrt 33.03.3 qui ne s'installa pas sur mon RT-AC88U (en mode facile ou "TFTP") et j'ai opté pour la version 33.03.2 qui s'est installée au premier essai .....
Y a t il un inconvénient , une incompatibilité potentielle avec les protocoles Orange de nos jours ? , des modifications à faire ?
Aucune à priori, ca marchait aussi bien sous 22.03.2 que 22.03.3 de mon côté.
Il y a quelques failles de sécu sur la 22.03.2 ceci dit, à voir si tu es concerné : https://openwrt.org/releases/22.03/notes-22.03.3 .
Tu as bien pris la bonne image ? Il y en a parfois plusieurs pour un modèle de routeur donné.
-
Pour ne pas capper à 1MB/s en SFTP, j'ai du forcer le DSCP à 0 sur les paquets IPv4/IPv6 (OpenSSH passe le TOS à 0x20 pour les paquets data).
Les règles nftables dans /etc/nftables.d/dscp-cs0.include :
oifname "eth0.832" ip dscp set cs0
oifname "eth0.832" ip6 dscp set cs0
config include 'orange_dscp'
option enabled '1'
option type 'nftables'
option path '/etc/nftables.d/dscp-cs0.include'
option position 'chain-append'
option chain 'mangle_postrouting'
Edit: Le DHCP/ARP sera également marqué en CS0 (et non plus CS6 pour ceux qui l'ont configuré iso à la Livebox), cela ne semble pas poser de problème chez moi, seul le CoS 6 semble nécessaire.
-
bonjour à tous,
Au passage, un grand bravo au responsables du site revenu en ligne en un temps record !! bravo !
Je suis sur le remplacement livebox vers un routeur Asus RT-AC88U et j'ai un problème :
D’après la doc GitHub :
<<Attention, n'hésitez pas à créer la sous interface wan "vlan832" depuis l'interface web (luci) et ensuite d'aller voir votre fichier network, car en fonction du modèle de routeur ce n'est pas exactement le même nom d'interface (intf physique).
Dans notre cas, le wan du routeur est "eth0", mais chez certains, il se nomme "wan" ou "eth1".>>
Si je fais l'inventaire des interfaces :
ifconfig me donne : br-lan ; eth1 ; extsw , lan1; lan2; lan3; lan4, lo, wan (+wlan0 et wlan1)
si je fais : ifconfig (a cela donne :
ifconfig (a cela donne) : br-lan; eth0; eth1, eth2, extsw; lan1; lan2; lan3 ; lan4 ; lo ;wan; (wlan0; wlan-1;wlan1 )
Donc je ne vois pas bien comment choisir entre wan, eth0 ou eth1 , si quelqu'un a une idée ou une explication cela m'ira bien
A PLUS
-
Pour ne pas capper à 1MB/s en SFTP, j'ai du forcer le DSCP à 0 sur les paquets IPv4/IPv6 (OpenSSH passe le TOS à 0x20 pour les paquets data).
Tu peux également simplement ajouter la directive "IPQoS none" à ton fichier .ssh/config pour que le client SSH mettre le DSCP à 0. Ca évite d'avoir à modifier le routeur.
-
Petite question sur odhcpd : Est-il possible d'envoyer des options avancées comme en v4 ? Je ne trouve pas de doc à ce sujet.
J'ai à tout hasard tenté list dhcpv6_option mais ça ne fait rien. Je cherche à reproduire le DHCPv6 d'Orange pour tester la délégation de préfixe de la LB.
Il doit falloir les options 11 et 17 (auth et vendor specific) pour que la box prenne le préfixe car en l'état elle refuse.
Merci
EDIT : Je viens de découvrir un truc : elle ne veut pas prendre de préfixe, par contre, pour s'attribuer une adresse en SLAAC, y'a pas de soucis ::)
-
Bonsoir a tous,
Help, j'ai un problème avec la structure de la chaine de caractères pour gégérer l'option 90 avec le script de de Kgersen
il est donné dans l'exemple :
00000000000000000000001a090000055801034101116674692F6674692F717071383838383c1231323334353637383930313233343536031341302f6f2d83fc857d7829d65ddea775d7
Lorsque je génère le mien, j'obtiens ceci : (copie partielle)
00:00:00:00:00:00:00:00:00:00:00:1a:09:00:00:05:58:01:03:41:01:0D:66:74:69:2F:66:6B:64:78:61:68:34:3c:12:31:32:33:34:35:36:37:38:39:30:31~~etc
Ce qui me surprend c'est la présence des : partout tous les deux caractères Est ce normal ?
Le script a t il été modifié ??
Merci d'avance
A Plus
-
Ce qui me surprend c'est la présence des : partout tous les deux caractères Est ce normal ?
Pour utilisation avec OpenWRT, il faut en effet supprimer les ':'.
-
AH OK ,
mais ce change semble etre récent non ? le script générait la chaine sans les : il y a peu ?
Non ?
Merci pour la réponse
A PLUS
-
Je ne saurais dire... en tout cas, lorsque je l'ai utilisé il y a ~2 mois, il y avait bien les :.
-
Le script a toujours généré les : pour séparer les octets, puisqu'à la base on utilisait tous isc-dhcp et que c'est la syntaxe attendue par ce client DHCP.
-
OK merci beaucoup,
Juste encore une question, au niveau de la configuration du routeur, les instructions fournies dans les fichiers network, firewall, dhcp et /etc/nftables.d/nft-prio6-rules.include
sont a reproduire dans ces fichiers , in extenso et a l'exclusion d'aitres instructions déjà présentes dans les fichiers d'origines fournies avec la version d'openwrt ? c'est bien cela ? (sauf une adaptation au niveau de l'ipv4 privée que j'ai adaptée a mon historique réseau) ?
Merci pour votre aide.
a PLUS
-
Hello
Maj du tuto pour l'option 77 ipv4, 15 ipv6, suite aux problèmes des renew (que j'ai rencontré également) en discussion ici :
https://lafibre.info/remplacer-livebox/durcissement-du-controle-de-loption-9011-et-de-la-conformite-protocolaire/msg1011246/#msg1011246
+FSVDSL_livebox.Internet.softathome.Livebox6
@Patrick91
Je ne comprends pas bien ta question, tu veux des précisions sur le fichier nft-prio6-rules.include ?
A+
-
Pour ma part, pas d'IPv6 si je mets le + sur l'option 15 (j'avais déjà le L majuscule de Livebox dans ma chaîne)
J'ai enlevé le +, IPv6 direct.
J'ai prit les traces DHCP avec tcpdump, je regarderais en détail ce soir.
Je ne sais pas si c'est lié à la migration ou pas justement.
edit: en lisant le post auquel tu fais référence, je me demande si ça ne s'applique pas que pour IPv4 ?
Car en effet la chaine 77 en IPv4: 2b46535644534c5f6c697665626f782e496e7465726e65742e736f66746174686f6d652e4c697665626f7836 = +FSVDSL_livebox.Internet.softathome.Livebox6
Donc on a deja bien le +
Mais en IPv6, passe pas de mon coté avec le +
-
Avec + dans la config (je bloque lors du SOLICIT)
(https://i.ibb.co/0G5Vwtf/Inked-SCR-20230412-ahw.jpg) (https://ibb.co/tJRPdXb)
Sans + dans la config
(https://i.ibb.co/kJqRB9b/Inked-SCR-20230412-afn.jpg) (https://ibb.co/2ScDhsV)
Quand je rajoute le + dans la chaine la longueur passe a 44 avec 002c = .,
Sans le + dans la chaine la longueur est bien de 43 avec 002b = .+
-
Interessant merci pour le dump, je suis en déplacement je n'ai pas encore eu le temps de vérifier.
Faudrait un dump de la livebox pour être sûr mais en effet d'après ce que tu montres il faut retirer le + en ipv6 uniquement.
Je maj
-
Edit :
oups autant pour moi, on parle d'ipv6 ::)
-
Interessant merci pour le dump, je suis en déplacement je n'ai pas encore eu le temps de vérifier.
Faudrait un dump de la livebox pour être sûr mais en effet d'après ce que tu montres il faut retirer le + en ipv6 uniquement.
Je maj
J'ai l'impression que le + se rajoute implicitement en IPv6 sur l'option15.
Apres je ne sais pas, je ne suis pas expert, je ne fais que constater ::)
Vous arrivez a récupérer une IPv6 avec le + implicite sur l'option 15 dans la chaine ?
Mais vu ce que cela semble envoyer avec un + implicite, je doute que ça fonctionne pour vous aussi.
-
Bon alors, pour clarifier: + = code ascii 0x2B = longueur de la chaine "FSVDSL_livebox.Internet.softathome.Livebox6"
Certains clients DHCP calculent la longueur seuls, donc pas besoin du "+". D'autres ne le font pas. Contenu de l'option à adapter au cas par cas....
-
@zoc
Merci pour la précision ;)
22.03.04 est dispo :
release notes : https://github.com/openwrt/openwrt/releases/tag/v22.03.4
Un point très utile, surtout pour les images x86 avec vos ssd, l'image builder possède désormais un paramètre "ROOTFS_PARTSIZE", qui permet donc de spécifier la taille de la partition root.
J'ai testé ça fonctionne bien, la limitation en revanche est qu'il faut executer l'image builder sur une machine ayant au moins autant de ram que la taille désirée de la partition.
A+
-
Plus qu'a trouver une machine avec 128Gb de ram pour ma part ;D
-
22.03.04 est dispo :
release notes : https://github.com/openwrt/openwrt/releases/tag/v22.03.4
Upgrade done. Ca marche au poil. Mettez à jour, c'est des updates de sécu.
-
Maj du tuto pour l'option 77 ipv4, 15 ipv6, suite aux problèmes des renew (que j'ai rencontré également) en discussion ici :
https://lafibre.info/remplacer-livebox/durcissement-du-controle-de-loption-9011-et-de-la-conformite-protocolaire/msg1011246/#msg1011246
+FSVDSL_livebox.Internet.softathome.Livebox6
Je n'avais pas fait gaffe mais j'ai le dernier livebox en minuscule en v6. Par contre en v4 c'est majuscule.
Et tout fonctionne au poil depuis la migration. Après y'a peut-être quelques différences en ADSL (déjà rien que la CoS pas nécessaire puisque pas de VLAN, j’avoue que c'est pas pour me déplaire ;D) ou c'est du hasard, genre le BNG sur lequel je suis se fout de cette différence.
-
Bonjour. Je suis chez Sosh et ma livebox est une livebox4. Mon option 15 sur wan6 est "15:FSVDSL_livebox.Internet.softathome.livebox4" je vois que les derniers changements sur le tuto concernent la Livebox6. A votre avis, vaut-il mieux rester sur mon option 15 actuelle ou passer sur celle de la liveboxv6 ?
Pour l'instant ipv4 et ipV6 fonctionnent, mais je n'ai pas tenté de renew ou de reboot depuis plus de 2 mois et je m'apprête à faire la mise à jour vers 22.03.04 (ou 22.03.05 qui vient d'arriver).
Merci.
-
Bonjour. Je suis chez Sosh et ma livebox est une livebox4. Mon option 15 sur wan6 est "15:FSVDSL_livebox.Internet.softathome.livebox4" je vois que les derniers changements sur le tuto concernent la Livebox6. A votre avis, vaut-il mieux rester sur mon option 15 actuelle ou passer sur celle de la liveboxv6 ?
Pour l'instant ipv4 et ipV6 fonctionnent, mais je n'ai pas tenté de renew ou de reboot depuis plus de 2 mois et je m'apprête à faire la mise à jour vers 22.03.04 (ou 22.03.05 qui vient d'arriver).
Merci.
Salut,
Pas d'inquiétude, tu peux rester en livebox4, tant que tu envoies la même info en ipv4 et ipv6 ça fonctionnera, disons que le plus logique serait d'envoyer ce qui correspond au modèle de la livebox que tu as rangé dans son carton ;).
Pour l'anecdote, tu peux même mettre livebox7, qui n'est pourtant pas encore sortie, livebox8 ne fonctionnera pas en revanche.
A+
-
Bonsoir à tous. Donc tout pareil pour ma part, apres 2ans en ONT->Linksys WRT3200, du jour au lendemain plus d'accès.
Donc grace à vous j'ai pu refaire fonctionner tout ca, en prenant les sendopts et reqopts avec l'outil Liveboxinfos.
En revanche.. quelquechose d'assez bizarre se produit lorsque j'effectue un speedtest (sur speedtest.net) : apres reboot je lance un test j'ai bien 300/300, et au second test en suivant le débit upload tombe direct à 6/7 .. le down ne bouge pas, sur mon pc fixe le débit baisse un poil mais beaucoup moins, (je les co en ethernet evidemment).
L'upload ne bouge pas sur Dslreports par contre et reste à 300/300. Je n'y comprends rien vraiment..
Quand je reconnecte la LB le débit est bien au max sur tous les pc..
-
Hello
Maj du tuto pour l'option 77 ipv4, 15 ipv6, suite aux problèmes des renew (que j'ai rencontré également) en discussion ici :
https://lafibre.info/remplacer-livebox/durcissement-du-controle-de-loption-9011-et-de-la-conformite-protocolaire/msg1011246/#msg1011246
+FSVDSL_livebox.Internet.softathome.Livebox6
@Patrick91
Je ne comprends pas bien ta question, tu veux des précisions sur le fichier nft-prio6-rules.include ?
A+
Merci pour l'update. Ca a coupé cette nuit chez moi et je n'ai pas encore eu le temps de faire les modifications.
Est-ce que tu pourrais ajouter une ligne à ton change log sur le premier post en indiquant que tu as fait cette modification ?
Le changelog est très pratique pour ce genre d'incident. J'apprends qu'il y a eu des modifs car j'ai vu ce post mais mon premier réflexe était de consulter le changelog de la première page et je pensais qu'il n'y avait rien de modifié.
Merci !
-
Pour ma part, j'ai eu le problème il y a une ou deux semaines. Un reboot du routeur solutionnait le souci, mais à distance... N'ayant pas le temps de m'en occuper, j'avais mis un watchcat et fait en sorte que la coupure se passe la nuit (problème se produisant toutes les 24h approx, au renew). Sauf que même après avoir appliqué les modifs, j'ai toujours le problème. Hier soir, j'ai sorti la livebox de la naphtaline, récupéré toutes les sendopts, et tout claqué à l'identique sur le routeur. Je ferai un retour si ça marche ;)
Merci pour l'update. Ca a coupé cette nuit chez moi et je n'ai pas encore eu le temps de faire les modifications.
Est-ce que tu pourrais ajouter une ligne à ton change log sur le premier post en indiquant que tu as fait cette modification ?
Le changelog est très pratique pour ce genre d'incident. J'apprends qu'il y a eu des modifs car j'ai vu ce post mais mon premier réflexe était de consulter le changelog de la première page et je pensais qu'il n'y avait rien de modifié.
Merci !
Je m'étais fait la même réflexion quand j'avais suivi les échanges sur le souci de renew, donc je plussoie ! Ne pas devoir faire un "diff" entre l'ancien et le nouveau est un bel avantage quand on a déjà une config existante ;)
Et encore une fois, un grand merci à ceux qui alimentent ce forum et ces tutos !
-
J'avais fait mon setup en octobre 2022 et effectivement, j'avais pas mal de choses à remettre à jour.
1) Il manquait des valeurs à mon reqopts sur wan4
2) Il manquait le clientid pour les 2 interfaces
3) Il manquait l'option 17 pour wan6
4) Le "L" de Livebox en majuscules (finalement je mets directement l'hexa).
J'ai utilisé LiveBoxInfos (https://www.liveboxinfos.ga/) pour récupérer directement les chaînes de ma Livebox. Très pratique pour ne pas faire d'erreur !
Bref, en reprenant les configs du tuto, j'ai pu bien tout remettre à jour et c'est reparti, merci beaucoup !
-
Je confirme qu'en claquant les options de LiveboxInfo (direct en hexa), ça fonctionne. Plus de problème de renew. Je ne sais pas exactement ce qui change par rapport à ce que j'avais mis depuis le tuto (conf que j'ai gardé en stock, faudra que je compare), à part que j'ai mis en hexa, et que ça a dû changé le numéro de box (livebox 4 en vrai, alors que ça devait être 5 via le tuto)
-
Je confirme qu'en claquant les options de LiveboxInfo (direct en hexa), ça fonctionne. Plus de problème de renew. Je ne sais pas exactement ce qui change par rapport à ce que j'avais mis depuis le tuto (conf que j'ai gardé en stock, faudra que je compare), à part que j'ai mis en hexa, et que ça a dû changé le numéro de box (livebox 4 en vrai, alors que ça devait être 5 via le tuto)
Le modèle de box n'a pas d'incidence
Tu avais surement un l au lieu d'un L non ?
Merci pour le retour, je vais en effet indiquer les modifications sur le post original du tuto.
A+
-
Le modèle de box n'a pas d'incidence
Tu avais surement un l au lieu d'un L non ?
Merci pour le retour, je vais en effet indiquer les modifications sur le post original du tuto.
A+
Voilà ce que j'avais "15:FSVDSL_livebox.Internet.softathome.Livebox6"
Et ça ne marchait pas ^^
-
Voilà ce que j'avais "15:FSVDSL_livebox.Internet.softathome.Livebox6"
Et ça ne marchait pas ^^
Oui mais avais tu la même chose en ipv4 (la chaine hexa se terminant par 6) ?
-
Hello,
J'ai changé de routeur il a quelques jours à cause de la partie DSL en carafe et je crois que j'ai un soucis de renew avec le nouveau...
Ce matin, plus de connexion alors qu'il était up depuis 1 jour et quelques heures... si j'en crois les captures ça doit se produire au bout de 23h30
Bizarrement, seul l'ipv6 était tombé (plus connecté d'après l'interface web), mais pas l'ipv4 qui continuait de tourner, mais je n'avais pas de connexion pour autant. J'ai tenté un simple restart du WAN, sans résultat. Il a fallut que je reboot complètement pour que ça revienne.
J'ai revérifié ma config et tout semble en ordre, c'est exactement comme mon autre routeur. J'ai aussi bien vérifié le user class : L majuscule pour les deux, alors que mon routeur précédent était minuscule en v6 et majuscule en v4 et jamais eu moindre problème depuis la migration...
Reste la version d'openwrt qui n'est pas identique : 19.07 pour mon routeur précédent et 15.01 pour le nouveau, c'est un DGA4132 que j'avais utilisé sans soucis plusieurs semaines lorsque je l'avais reçu il a 4 ans, avant de finalement basculer sur l'autre jusqu’à maintenant.
Je mets la conf au cas où :
config interface 'wan'
option proto 'dhcp'
option peerdns '1'
option broadcast '1'
option vendorid 'sagem'
option reqopts '1 3 6 15 28 51 58 59 90'
option sendopts '77:2b46535644534c5f6c697665626f782e496e7465726e65742e736f66746174686f6d652e4c697665626f7834 90:chaine-longue'
option mtu '1500'
option ipv6 '1'
option auto '1'
option ifname 'atmwan'
option clientid '0144a61e6cxxxx'
option macaddr '44:a6:1e:6c:xx:xx'
config interface 'wan6'
option ifname '@wan'
option proto 'dhcpv6'
option reqprefix 'auto'
option reqaddress 'none'
option defaultreqopts '0'
option reqopts '11 17 23 24'
option userclass 'FSVDSL_livebox.Internet.softathome.Livebox4'
option vendorclass '0000040e0005736167656d'
option sendopts '11:chaine-longue'
option clientid '0003000144a61e6cxxxx'
option macaddr '44:a6:1e:6c:xx:xx'
option iface_dslite '0'
option iface_464xlat '0'
option auto '1'
-
Pour info j’ai toujours le l minuscule (pour une LB4) en v6 sur mon ER4 et aucun problème même après migration.
-
Ah, il n'y donc pas que chez moi que ça marche aussi avec cette différence alors que ça semble poser problème chez d'autres au renew.
Un bug similaire à celui de la CoS ? À tout hasard, c'est quoi comme équipement en face ? Chez moi c'est du nokia.
-
Aucune idée.
-
Je crois que j'ai résolu mon soucis.
En fouillant un peu mieux, j'ai vu pleins de warning relatifs à la route par défaut inexistante dans les logs qui concernaient d'autres interfaces (le wifi invité notamment qui est foutu bizarrement sur ce routeur) qui avait l'ipv6 activé. J'ai donc voulu le désactiver pour plus que ça me pollue le truc histoire d'y voir plus clair. Mais ce que n'avais pas remarqué tout de suite c'est que une des interfaces s'était mise toute seule en alias du wan (à cause de luci, l'interface wifi normalement attachée n’apparaît pas dans la liste de sélection et donc ça me prend le prochain truc valide qu'il trouve...).
À partir de ce moment là, plus rien ne marchait, même avec un reboot, je n'avais plus de connexion. Bien que je récupère ma v4 et le préfixe, seul le routeur avait accès au net.
Je suis allé fouillé mes vieilles sauvegardes et remis par défaut et c'est là que j'ai tilté : et si c'était wan6 en alias qui foutait la grouille ? Je modifie ça, restart général des interfaces : BOUM, tout revient instantanément. Je peux relancer les interfaces indépendamment, ça revient à chaque fois. Alors qu'avant si j'avais le malheur d'y toucher, il fallait totalement reboot pour retrouver un accès et idem lors du renew je suppose, elles devaient se foutre HS mutuellement.
Bref, j'aurais du séparer les interfaces dès le départ, ce qui d'ailleurs est bien fait sur mon autre routeur. Je ne pensais pas d'un truc aussi insignifiant en apparence puisse créer autant de problème... :P
Donc, si vous avez des problèmes de renew vérifiez bien (entre autres) que vos interfaces sont indépendantes.
-
Cette nuit (région Toulouse) j’ai perdu la co vers 4h15.
J’ai juste restart les deux interface wan et c’est reparti pour ipv4 et ipv6.
Pas eu le temps de trop fouiller les log encore.
Je reviendrais poster une fois les log décortiquer ::)
-
Hello,
J'ai besoin de vos lumières pour un problème que j'avais encore jamais vu : J'ai finalement acheté un modem séparé pour mettre au cul de mon routeur malade, mais y'a un truc auquel je ne m'attendais pas : impossible de faire fonctionner la livebox dans cette config. Pourtant tout à l'air de marcher (je vois bien les paquets partir et revenir) mais le net sur la box et les machines derrière est HS, plus exactement ça fait mine de marcher au compte goutte, parfois un ping arrive à passer sur des diazines de requêtes mais c'est tout. Comme si le pare feu de la box bloquait en entrée.
Si je rebscule sur l'ADSL, tout revient sans avoir touché quoi que ce soit. Je ne fait rien de particulier si ce n'est switcher entre dsl0 et eth0.2 (non taggé sur le port RJ45 wan).
J'ai donc voulu essayer en lui donnant la connexion par un autre openwrt sur mon LAN : je désactive le DHCP et tag le 832 pour remonter jusqu'à mon switch principal et là même comportement : je vois bien les reply des pings mais c'est toujours HS. Je fini par bypass en me branchant directement sur le switch : ça fonctionne !
Il y a donc un problème même lorsque le VLAN passe par le routeur (simplement taggé entre 2 ports) ça fait plusieurs heures que je cherche ce qui pourrait causer un tel soucis mais je vois pas... d’autant plus que j'ai un autre VLAN/interface pour mes VM et tout marche sur celui-ci, alors que d'un point de vue config, c'est la même chose au N° de VLAN près.
Est-ce que ça pourrait être du à l'adresse mac identique entre eth0.2 et et la box ? Je ne vois pourtant rien dans les requêtes ARP qui pourrait faire penser ça. Vu que j'ai pas envie de me faire bannir par le réseau pour plusieurs jours, je préfère venir demander avant de la changer.
Merci
Capture de la config des VLAN :
-
Bon, il semble bien y avoir un problème avec la MAC.
J'ai simulé la box en clonant sa MAC sur un openwrt et bingo : j'ai le même soucis dans mon VLAN dédié aux VM. Et dès que je remet une MAC aléatoire ça refonctionne.
Je suis donc bon pour changer la MAC WAN, en espérant ne pas me faire bannir par le réseau pendant une semaine...
EDIT : Tant que j'y suis : je vois aussi que je perds l'ipv6 toutes les 24h (il faut relancer la séquence dhcp), chose qui ne m'étais jamais arrivé jusque là. J'ai l’impression que ba0bab arrête d'envoyer des RA/NS pour je ne sais quelle raison et il ne répond plus au ping, étrange.
Côté user class, je suis bien en Livebox en v4 et v6, donc ça devrait être bon... en théorie.
-
Je viens de trouver une commande très pratique pour forcer le renew avant le compteur officiel : kill -USR1 $(pidof odhcp6c)
À priori ça marche bien, ba0bab me répond en réinitialisant le temps restant (23h et qqes), ayant relancé la connexion hier soir vers 3h du matin, et renew fait à 20h22, théoriquement je ne devrais donc pas avoir de coupure cette nuit. Croisons les doigts.
Cela dit y'a quand même un truc que je trouve bizarre : l'ipv6 ne fonctionnait plus alors que la route par défaut était toujours valide (environ 2000s restantes)... ou alors dès que T1 expire, ba0bab cesse de répondre et coupe le routage ?
La capture du renew, tout à l'air en ordre :
root@LEDE:~# tcpdump -v -i eth0.2 udp port 546 or udp port 547 or icmp6
tcpdump: listening on eth0.2, link-type EN10MB (Ethernet), capture size 262144 bytes
20:21:03.256713 IP6 (flowlabel 0x92fb6, hlim 1, next-header UDP (17) payload length: 239) fe80::46a6:1eff:fe6c:xxxx.546 > ff02::1:2.547: [udp sum ok] dhcp6 renew (xid=4e9535 (elapsed-time 0) (option-request vendor-specific-info DNS-server DNS-search-list) (client-ID hwaddr type 1 44a61e6cxxxx) (server-ID hwaddr type 1 407c7d8f2e31) (authentication proto: 0, alg: 0, RDM: mono, RD: 0000 0000 0000 0000 ??) (user-class) (vendor-class) (IA_PD IAID:1 T1:0 T2:0 (IA_PD-prefix 2a01:cb14:xxx:xxxx::/56 pltime:0 vltime:0)))
20:21:03.615653 IP6 (class 0xc0, hlim 255, next-header UDP (17) payload length: 176) fe80::ba0:bab.547 > fe80::46a6:1eff:fe6c:xxxx.546: [udp sum ok] dhcp6 reply (xid=4e9535 (server-ID hwaddr type 1 407c7d8f2e31) (client-ID hwaddr type 1 44a61e6cxxxx) (IA_PD IAID:1 T1:84672 T2:483840 (IA_PD-prefix 2a01:cb14:xxx:xxxx::/56 pltime:604800 vltime:604800)) (authentication proto: 0, alg: 0, RDM: mono, RD: 0000 0000 0000 0000 ??) (vendor-specific-info) (DNS-search-list LYO.access.orange-multimedia.net.))
EDIT : le renew anticipé à l'air de fonctionner, aucune coupure après 24h :) Je vais laisser faire le renew de ce soir, voir ce qu'il se passe exactement en faisant une capture.
-
Contre toute attente, le renew DHCPv6 a bien eu lieu automatiquement, par contre, aucune trace en IPv4 ??? Alors que je l'avais aussi renouvelé quelques minutes avant... et comme un c*n j'ai oublié de spécifier les ports UDP 67/68 sur la capture, à la place j'ai mis 67/68 tout court, ça devrait donc capturer TCP et UDP ? Si c'est le cas, y'a rien eu non plus et aucun trace dans les logs alors que normalement ça le marque.
Quelqu'un peut confirmer que ça doit bien avoir lieu toutes les 24h ? Car en fait je n'ai jamais réellement vérifié si c'était le cas vu que tout fonctionnait avant ou si udhcpc fait un peu à sa sauce et renew en dehors du timer.
-
J'ai parlé trop vite... l'ipv6 est de nouveau down (je n'ai pas vu quand ça a coupé, sans doute dans la matinée) Franchement je ne sais pas ce qu'il se passe :(
J'ai relancé un renew, ça ne fonctionne pas. Et odhcp6c a fini par un rebind et solicit de lui-même car pas de réponse. Et c'est remonté.
root@LEDE:~# tcpdump -i eth0.2 icmp6 or udp port 546 or udp port 547
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0.2, link-type EN10MB (Ethernet), capture size 262144 bytes
13:37:47.452536 IP6 fe80::46a6:1eff:fexx:xxxx.546 > ff02::1:2.547: dhcp6 renew
13:38:05.496259 IP6 fe80::46a6:1eff:fexx:xxxx.546 > ff02::1:2.547: dhcp6 rebind
13:38:05.691611 IP6 fe80::46a6:1eff:fexx:xxxx.546 > ff02::1:2.547: dhcp6 solicit
13:38:06.752600 IP6 fe80::46a6:1eff:fexx:xxxx.546 > ff02::1:2.547: dhcp6 solicit
13:38:08.956516 IP6 fe80::46a6:1eff:fexx:xxxx.546 > ff02::1:2.547: dhcp6 solicit
13:38:13.052515 IP6 fe80::46a6:1eff:fexx:xxxx.546 > ff02::1:2.547: dhcp6 solicit
13:38:20.732517 IP6 fe80::46a6:1eff:fexx:xxxx.546 > ff02::1:2.547: dhcp6 solicit
13:38:20.866356 IP6 fe80::ba0:bab.547 > fe80::46a6:1eff:fexx:xxxx.546: dhcp6 advertise
13:38:21.676252 IP6 fe80::46a6:1eff:fexx:xxxx.546 > ff02::1:2.547: dhcp6 request
13:38:21.802995 IP6 fe80::ba0:bab > fe80::46a6:1eff:fexx:xxxx: ICMP6, router advertisement, length 32
13:38:21.906826 IP6 fe80::ba0:bab.547 > fe80::46a6:1eff:fexx:xxxx.546: dhcp6 reply
13:38:29.180567 IP6 fe80::46a6:1eff:fexx:xxxx > fe80::ba0:bab: ICMP6, neighbor solicitation, who has fe80::ba0:bab, length 32
13:38:29.196825 IP6 fe80::ba0:bab > fe80::46a6:1eff:fexx:xxxx: ICMP6, neighbor advertisement, tgt is fe80::ba0:bab, length 32
Quelqu'un a déjà eu le problème de coupure après 24h sans raison ? J'ai tenté de mettre ba0bab en route statique il y a 2 jours quand c'était HS, mais rien, comme s'il n'y avait plus de lease valide.
-
entre le moment ou tout marchait bien, et le moment ou tu t'es aperçu du problème, tu n'as pas fait un update d'openwrt ?? ou de ses packages ?
-
Non, j'ai rien fait du tout. J'en viens à me demander si ce n'est pas à cause du modem et la manière dont le bridge est géré.
Sans compter que l'ipv4 aussi fait des siennes, ça a également coupé quelques minutes après avoir remonté l'ipv6 :( Ou alors il y a bien un problème de renew en v4 et si seul l'ipv6 se renouvelle, ça coupe au bout d'un moment car incohérence...
Ayant toujours un routeur identique chez mes parents qui fonctionne, je vais regarder attentivement ce qu'il se passe, car normalement il ne coupe pas.
-
Je suis train de me demander si les clients DHCP respectent vraiment l'intervalle de renew envoyé par le serveur (du moins udhcpc et odhcp6c). Sur le routeur de mes parents à l'heure prévue, surprise, je n'ai rien vu autant en v4 qu'en v6...
J'ai fait un renew manuel pour vérifier que je récupérais les mêmes valeurs que ma ligne et c'est le cas : 84672s en T1 et 483840s en T2 sur les deux stacks.
Du coup, je comprends encore moins pourquoi ça déconnecte sur la mienne et pourquoi j'ai bien eu le renew ipv6 au bout de 24h... ou c'est parce que j'avais justement déclenché le renew à la main, qui ne se produirait pas si ça se faisait tout seul ?
-
la norme DHCP laisse du mou sur les renew, chaque implémentation de client fait un peu sa sauce.
En moyenne ça cherche à commencer à faire des renew à partir de 50% du temps de validité du bail
à moins de sniffer pendant 24h avec des filtres tu risques d'avoir du mal à voir passer les trames
-
Merci, c'est bien ce que je pensais...
Là ma stack ipv6 est retombée à cause de moi et j'ai refait une séquence et cette fois je n'ai pas du tout les mêmes valeurs : T1:97827 T2:483840
Si ça se trouve entre un solicit et un renew ce n'est pas les mêmes, ce qui expliquerait pourquoi je n'ai rien vu.
-
Je crois avoir trouvé les potentielles sources des déconnexions, 2 hypothèses :
-Mon pont wifi : avant-hier, j'ai eu une perte de paquets inexplicable sur les ping (genre 60%), bizarrement seulement en v4 (en v6 tout passait sans soucis), et une navigation dégradée (4-5 Mbps au lieu de 12), j'ai simplement débranché-rebranché le RJ45 sur mon switch (sans reboot l'antenne) et ça a disparu, pas tout capté... (elles commencent à se faire vieilles les mémères, faut dire...). Et comme j'en avais profité pour déplacer le routeur derrière (vu que maintenant je peux), je me dis que si il n'arrivait pas à répondre à temps aux paquets provenant d'orange, la connexion coupait.
-Mes bidouilles répétés avec les VM et les VLAN : Alors que j'avais remis en direct le modem et le routeur comme c'était au début, j'ai relancé sans faire gaffe une des VM sur laquelle j'avais cloné la MAC de la box et ça coïncidait avec la coupure IPv6 (cf message précédent). Après analyse, il s'avère qu'elle bavait sur le LAN et donc le routeur recevait des NS avec la MAC de la box clonée elle aussi sur le routeur. Qui faisait qu'elle ne se connectait pas lorsque elle était branchée sur celui-ci (cf #870 (https://lafibre.info/remplacer-livebox/remplacement-de-la-livebox-par-un-routeur-openwrt-18-dhcp-v4v6-tv/msg1019716/#msg1019716))
J'ai donc remodifié les MAC, supprimé les VLAN et autres bridges pour que la box soit bien hermétique au reste du LAN et depuis ça à l'air de tenir sans aucun renew.
Je ne sais donc pas laquelle des hypothèses est la bonne, sans doute un peu les deux. Je continue à surveiller ça de près. Mais pour le moment 8)
-
Le soucis de déconnexion est revenu...
Je ne sais pas si c'est lié à la resync de la ligne sans relancer le DHCP qui crée un truc bizarre (car ça repart direct après sans besoin de faire un release/discover), mais c'est de nouveau tombé la semaine dernière après 6 jours d'up (il y a du mieux c'est déjà ça). Et là à l'instant après 2 jours, mais le modem n'a pas bronché cette fois, du moins d'après l'uptime de la ligne.
J'ai mis un cron avec renew toutes les 24h, au lieu de l’approximatif à 50% du bail, je verrais si ça arrange la situation ou non.
-
Bonsoir,
Je suggère de capturer en permanence le trafic, ça pourrait aider à y voir plus clair.
Dans un screen ou équivalent, lancer :
tcpdump -evvi eth0 port 67 or port 546 or icmp6 or arp
Bien faire la capture sur l'interface physique et avec les options -evv.
-
Désolé pour le retard.
Merci pour la suggestion, je faisais déjà de la capture de paquets DHCP/ARP/ICMP pour voir en effet. Mais sans utiliser -eev.
Même si je n'ai rien trouvé pour le moment, le fait d'avoir mis le renew forcé toutes les 24h, semble grandement aider. Hormis mon interruption volontaire hier pour resync le modem, il a dépassé la semaine sans aucune coupure et a bien renouvelé le bail.
-
En désespoir de cause, j'ai fait un reset de la Livebox en utilisant le bouton derrière le boîtier, et je l'ai rebranchée directement sur la prise fibre murale.
Après avoir saisi mon identifiant dans l'interface web, et 3 reboots / mise à jour, j'ai vérifié que tout fonctionnait (internet / wifi / tél) puis je l'ai éteinte et rebranchée derrière mon routeur.
Et là surprise, j'ai enfin vu passer dans tcpdump des requêtes DHCP en provenance de la Livebox.
Du coup j'ai pu ajuster ma configuration, et cette fois le téléphone fonctionne comme attendu.
Je remet ma configuration définitive, au cas où ça puisse dépanner quelqu'un :
- Pré-requis : dérouler la partie Internet IPv4 du tuto
- Configuration du /etc/config/network : on sélectionne un port du switch que l'on va taguer avec le vlan 832 pour pouvoir brancher la Livebox, et on ajoutes une interface tel qui permettra d'avoir une instance dhcp dédiée pour la box :
config interface 'tel'
option ifname 'eth0.832'
option proto 'static'
option netmask '255.255.255.0'
option defaultroute '0'
option ipaddr '192.168.100.1'
config switch
option name 'rtl8366s'
option reset '1'
option blinkrate '2'
option enable_vlan '1'
option enable_vlan4k '1'
option max_length '3'
config switch_vlan
option device 'rtl8366s'
option vlan '1'
option ports '0 1 2 5t'
config switch_vlan
option device 'rtl8366s'
option vlan '832'
option ports '3t 5t'
option vid '832'
Remarque : l'option vid 832 est facultative, c'est pour pouvoir déboguer le DHCP en branchant un PC à la place de la Livebox. Dans ce cas là, ne pas oublier aussi de dé-taguer le port du switch sur le vlan 832 (3t à remplacer par 3 dans l'exemple), sinon le PC ne verra pas passer les trames.
- On configure ensuite le DHCP dans /etc/config/dhcp :
config dhcp 'tel'
option leasetime '12h'
option domain 'orange.fr'
option interface 'tel'
option start '1'
option limit '2'
list dhcp_option_force '90,00:00:00:00:00:00:00:00:00:00:00:64:68:63:70:6c:69:76:65:62:6f:78:66:72:32:35:30'
list dhcp_option_force '120,00:06:73:62:63:74:33:67:03:4e:49:43:06:61:63:63:65:73:73:11:6f:72:61:6e:67:65:2d:6d:75:6c:74:69:6d:65:64:69:61:03:6e:65:74:00'
list dhcp_option_force '125,00:00:05:58:0c:01:0a:00:01:00:00:00:ff:ff:ff:ff:ff'
list dhcp_option '6,80.10.246.3,81.253.149.10'
Le dhcp_option_force ne sert que pour le debug depuis un PC, il peut être remplacé par un dhcp_option car de toute façon la Livebox demande explicitement ces options au serveur DHCP.
- Pour terminer, on n'oublie pas de mettre à jour le firewall :
config zone
option name 'tel'
option network 'tel'
option output 'ACCEPT'
option log '1'
option family 'ipv4'
option input 'ACCEPT'
option forward 'REJECT'
config forwarding
option dest 'wan'
option src 'tel'
config rule
option src 'tel'
option dest_port '53'
option proto 'tcpudp'
option target 'ACCEPT'
option name 'DNS for Livebox'
config rule
option src 'tel'
option dest_port '67-68'
option proto 'udp'
option target 'ACCEPT'
option name 'DHCP for Livebox'
config rule
option name 'Allow-DHCP-Renew for Livebox'
option proto 'udp'
option dest_port '68'
option target 'ACCEPT'
option family 'ipv4'
option src 'tel'
Un grand merci à tous, et plus particulièrement à kgersen pour sa patience et ses explications !
Bonjour à tous, j'ai suivi les étapes décrites dans le post de Rhon pour avoir le téléphone fonctionnel en branchant la livebox derrière mon routeur. Cependant ça ne fonctionne pas car lorsque la livebox démarre elle affiche "connexion..." pendant quelques minutes puis indique finalement "téléphone indisponible" etc. Il faut dire que j'ai du mal à adapter la config de Rhon à mon routeur dans la mesure où ce dernier n'est pas un "vrai" routeur mais plutôt un truc "diy" à base de carte mère mini itx Intel (donc plateforme x86-x64) + carte réseau Dlink branchée en PCI faisant office d'interface WAN. Vous l'aurez compris le problème réside dans le fait que je n'ai pas de switch intégré au routeur. Mon switch est un Netgear GS724Tv1 "smart managed" donc administrable en interface web uniquement (pas de console telnet ou ssh). Ci-joint mes fichiers de config si cela peut aider.
/etc/config/network
/etc/config/dhcp
/etc/config/firewall
Merci d'avance pour vos éclaircissements :)
-
Tu es bien dans le même cas que rhon, excepté le switch en effet. Mais ça ne devrait gêner en rien.
Ton br-lan étant sur eth0, il suffit de rajouter une interface eth0.832 en définissant juste celle-ci, ne te préoccupe pas de la partie switch. Idem pour le dhcp et firewall, sa config est bonne il n'y a qu'à recopier (modulo le nom des interfaces, toi c'est "wan4" pour la ligne forwarding).
Ensuite c'est sur le swtich que ça coince peut-être, il faut tagger le port sur le 832 où est branché l'OWRT, ainsi que celui de la LB. Tu as de la chance, j'ai un modèle similaire le GS716T (le modèle 16 ports), si l’interface n'est pas trop différente :
Il faut aller dans : switching > VLAN > advanced > VLAN configuration > ajouter le VLAN 832
Puis : VLAN membership > sélectionner le 832 dans la liste > cocher les ports pour avoir un T comme tagged > sauvegarder
Théoriquement ça devrait fonctionner.
-
Hello :D
J'ai un comportement un peu étrange, j'ai perdu ipv4 et ipv6 au bout de 43 jours ce coup ci (je n'ai pas noté la dernière fois), je refais un simple ifdown / ifup sur mes interfaces wan et ça repart comme en l'an 40.
Vous avez un comportement similaire ou pas du tout ?
Il n'y a absolument rien dans les logs, donc je me demande si ce n'est pas lié a des actions sur le réseau Orange ?
Bon au final c'est totalement transparent quand ça arrive, car j'ai un script qui tourne via cron qui s'occupe de gérer ça si jamais y'a une coupure internet mais curieux de savoir si vous avez le meme symptôme.
-
Hello :D
J'ai un comportement un peu étrange, j'ai perdu ipv4 et ipv6 au bout de 43 jours ce coup ci (je n'ai pas noté la dernière fois), je refais un simple ifdown / ifup sur mes interfaces wan et ça repart comme en l'an 40.
Vous avez un comportement similaire ou pas du tout ?
Il n'y a absolument rien dans les logs, donc je demande si ce n'est pas lié a des actions sur le réseau Orange ?
Bon au final c'est totalement transparent quand ça arrive, car j'ai un script qui tourne via cron qui s'occupe de gérer ça si jamais y'a une coupure internet mais curieux de savoir si vous avez le meme symptôme.
Hello,
J'ai vérifié sur quelques openwrt qui tournent sur des fibres ftth Orange, et non ras.
Ici par exemple sur un ER-X@Sosh, j'ai le script de reboot en cas de perte du wan, donc j'aurai un uptime bien + faible si j'avais le soucis.
-
Ouais en effet 100 jours...
Merci pour ton retour ubune.
Je vais continuer à surveiller alors. ;D
-
Ca m'arrivait parfois quand j'avais mon Ubiquiti ER4, et généralement ça correspond aux opérations de maintenance chez Orange. D'où le watchdog que j'avais rajouté. Rien depuis que je suis passé chez Mikrotik, mais ça ne fait qu'un peu plus d'un mois.
A mon avis aucune inquiétude à avoir, le watchdog est là pour ça.
-
Ouais c'est ce que je pense aussi !
Et en effet le watchdog marche bien de mon coté, donc pas de soucis mais c'était pour trouver une petite explication quand meme ;D
-
Bonjour à tous,
J'ai suivi le tuto depuis le github de ubune pour remplacer ma livebox 5 par un routeur openWRT, donc tout fonctionne bien mais je souhaiterais désactiver l'ipv6.
Seulement voila quand je le désactive ( en supprimant l'interface WAN6 ou même en ssh ), je n'ai plus internet du tout.
Je souhaiterais savoir s'il est possible d'avoir internet uniquement en ipv4, car j'utilise un client VPN avec le protocoe WG mais ce provider ne fonctionne qu'avec l'ipv4 et donc mon adresse ipv6 est bien visible.
J'ai parcouru ce topic mais n''ai pas trouvé la réponse.
Je vous remercie par avance :)
-
Bonjour à tous,
J'ai suivi le tuto depuis le github de ubune pour remplacer ma livebox 5 par un routeur openWRT, donc tout fonctionne bien mais je souhaiterais désactiver l'ipv6.
Seulement voila quand je le désactive ( en supprimant l'interface WAN6 ou même en ssh ), je n'ai plus internet du tout.
Je souhaiterais savoir s'il est possible d'avoir internet uniquement en ipv4, car j'utilise un client VPN avec le protocoe WG mais ce provider ne fonctionne qu'avec l'ipv4 et donc mon adresse ipv6 est bien visible.
J'ai parcouru ce topic mais n''ai pas trouvé la réponse.
Je vous remercie par avance :)
Salut Fiester,
Pourquoi vouloir désactiver ipv6 ? C'est une mauvaise idée ! Il y a d'autres choses à faire pour éviter le traffic ipv6 quand tu lances ton wireguard ;).
Je ne vais pas m'etendre ici mais si tu veux plus d'info sur ipv6, jette un oeil sur ce lien : https://lafibre.info/ipv6/lumiere-sur-ipv6-video/
Et sinon, désactiver ipv6 sur l'interface wan6 est encore + une mauvaise idée car l'objectif du tuto est de reproduire le fonctionnement de la livebox.
Si vraiment tu ne veux pas utiliser ipv6 (sur toutes tes machines), il suffit de désactiver les ra sur ton interface "lan".
Dans ce cas, aucune machine de ton réseau local ne se generera une adresse ipv6 "globale", et donc tu seras en ipv4 only avec tes machines.
A+
-
Salut ubune,
Merci pour ta réponse.
Je veux désactiver l'ipv6 car je ne vois aucun intérêt et trouve dommage que l'on ne puisse pas le désactiver simplement mais surtout c'est pour que tous mes équipements n'utilisent que l'ipv4 et donc soit totalement couvert par le vpn WG sans fuite de l'ipv6. J'aurais un provider VPN qui gérait l'ipv6 en WG je ne me serais pas pris la tête.
Je sais pas si je me fais bien comprendre.
Je viens de faire ta méthode en mettant "RA-Service" sur disabled depuis l'interface "LAN"et effectivement je n'ai plus d'adresse ipv6 et et t'en remercie.
Ce que je voulais c'est éviter de désactiver l'ipv6 manuellement sur tous les équipements.
En tout cas problème résolu et je t'en remercie une nouvelle fois :D
-
Bonjour,
Des personnes ont deja mis à jour vers 23.05.0? Des changements à prévoir?
Merci!
hurtauda
-
Bonjour,
Des personnes ont deja mis à jour vers 23.05.0? Des changements à prévoir?
Merci!
hurtauda
Hello, non aucun
Tu peux maj directement ;).
-
Ça dépend de ta target ... Y a eu un renommage des interfaces wifi par ex qui casse les configs, des paquets SSL changés, etc. Plein de soucis ou 0 souci selon ta target encore une fois. Il faut toujours regarder les forums de Openwrt qui parle de ton device avant de flasher car, "stable", ce ne veut pas dire "tester sur tous les devices".
https://forum.openwrt.org/t/openwrt-23-05-0-first-stable-release/
-
Yes, ma réponse c'était axé sur la validité du tuto en 23.05, la y'a aucun changement à faire.
Et perso, j'ai déjà maj du x86 et un erx sans soucis, avec un sysupgrade et un reboot, et tout est ok.
-
En effet, c'est un peu plus compliqué pour moi car mon device Linksys EA8300 est passe de swconfig a DSA et donc toute ma config /etc/config/network est a refaire avec les nouveaux concepts...
Pour le moment, j'ai abandonné et je suis repassé en 22.03.5 en attendant de comprendre comment migrer... Je pense que je vais devoir lire 20 fois cette page :D
https://openwrt.org/docs/guide-user/network/dsa/converting-to-dsa
-
tu peux te créer ta propre image depuis le firmware selector :
https://firmware-selector.openwrt.org/?version=23.05.0&target=ipq40xx%2Fgeneric&id=linksys_ea8300
Tu mets la page en Français.
Tu cliques sur "Personnaliser les paquets installés et/ou le script de démarrage"
Dans la liste des paquets affichés, tu supprimes :
firewall4
nftables
kmod-nft-offload
et tu ajoutes ceux-ci :
firewall
iptables-legacy
ip6tables-legacy
kmod-ipt-offload
ensuite tu cliques "Demande de construction" et tu obtiendras ton image personnalisée en 23.05.0
-
J’imagine que ces paquets sont pour garder la config en swconfig mais a priori DSA est l’avenir donc pourquoi ne pas l’utiliser ?
Si c’est configurable je tenterai lorsque j’aurais une journee de dispo…
-
Voilà quelques temps que je n'était pas revenu sur ce thread.
Je profite d'avoir passé mes appareils sous la 23.05.0 et modifié mon install pour vous faire par de ma dernière trouvaille (tldr en fin de post):
Pour commencer, offre orange 500/500 (moins cher, suffisant margres mon utilisation intensive, et surtout c'etait le seul moyen que j'avait à l'epoque d'avoir un ONT de la part d'orange.)
Setup de base
ONT orange => Raspberry Pi4 => Edgerouter X SFP => Tout mon bordel.
Setup voulut
ONT GPON-ONU-34-20BI de chez FS.com => Edgerouter X SFP => toujours le même bordel
La raison étant de sortir le Pi 4, l'ERX-SFP étant largement suffisant pour le moment (peu de bufferbloat avec hardware offloading et il me sature 500/500) et me sortir la dernière pièce d'équipement d'orange (mis à part le décodeur)
Déplacement de config/vlans/firewall sans soucis, ONT GPON-ONU-34-20BI reconnu par l'ER-XSFP (mes recherches m'ont permit de trouvé que depuis un merge d'openwrt il n'y a plus besoins de hacker (pont de soudure) les modules SFP pour bypasser l'auto négociation).
Le problème m'ayant fait perdre le plus de temps a été de récupérer les VLANs sur l'ONT:
Je lui avait rentré le numéro de série de l'ONT d'orange ainsi que le hardwareversion. Il s'autentifiait bien auprès de l'OLT mais j'avais aucune VLAN d'orange (832/835/840/etc...).
Passé deux heures d'acharnement et proche de l'abandon j'ai tenté de rentrer un hardwareversion de l'ONT d'une livebox5 trouvé sur le net et PAF ça fonctionne!
Il va falloir m'expliquer comment l'ONT s'identifie auprès de l'OLT avec d'une part un numéro de série d'un ONT Huawei et de l'autre une harwareversion d'un ONT Sagemcom n'étant même pas le mien...
Dans les logs je vois que l'ER-X-SFP donne 1W au module qui apparemment nécessite 2.2W d'après FS.com, mais il à l'air de fonctionné correctement.
tldr: Module ONT GPON-ONU-34-20BI de chez FS.com dans Edgerouter X SFP en openwrt 23.05.0: ça fonctionne!
Encore un gros merci à Ubune et à vous tous dont vos posts m'on bien aidé !
-
Bonjour,
Tout d'abord merci pour ce tuto.
Je me trouve dans une situation où je n'arrive plus à renouveler mon IPv4 wan.
J'obtiens toujours la même IPv4 malgré les renew que je force via openwrt ou l'interface sosh de renouvellement.
Une idée ?
Merci
-
Bonjour à tous,
Pour partager mon expérience. Cette nuit mon routeur OpenWRT a perdu plusieurs fois sa connexion. Ce matin, après un reboot, l'accès internet fonctionnait via ipv4 pendant 5 min environ puis stoppait jusqu'au prochain reboot.
J'ai rebranché ma livebox (v4) sur l'ONT et elle a fait plusieurs mises à jour successives. Cela faisait probablement plus d'un an qu'elle n'avait pas été branchée. J'ai ensuite rebranché le routeur OpenWRT directement sur l'ONT et depuis la connexion semble stable. Peut-etre une façon pour Orange de forcer une mise à jour sur les livebox ?
-
Bonjour ! @ubune
Il est très important de mentionner l'ONT et de préciser son rôle dans les pré-requis. Cela peut conditionner ses choix et permettre éventuellement
de faire une mise en adéquation avec ses attentes.
- Le routeur ne dispose pas de cage SFP ou SFP+.
- L'ONT et le routeur peuvent malheureusement s'avérer être incompatibles.
- L'utilisateur peut s'avérer dans l'incapacité de paramétrer correctement l'ONT.
- ...
-
Bonjour !
La configuration du pare-feu en IPv6 pour l'échange de messages DHCPv6 me paraît problématique.
config rule
option name 'Allow-DHCPv6'
option proto 'udp'
option dest_port '546'
option family 'ipv6'
option target 'ACCEPT'
option src 'wan6'
list src_ip 'fc00::/6'
list dest_ip 'fc00::/6'
On peut comparer avec l'exemple de configuration du Wiki OpenWrt. (https://openwrt.org/docs/guide-user/network/ipv6/configuration#native_ipv6_connection)
config rule
option target 'ACCEPT'
option src 'wan'
option proto 'udp'
option dest_port '546'
option name 'Allow DHCPv6 replies'
option family 'ipv6'
option src_port '547'
La documentation n'est pas toujours très claire. On constate qu'on peut utiliser la notation CIDR en IPv4 dans l'option src_ip pour spécifier à la place un préfixe (https://openwrt.org/docs/guide-user/firewall/fw3_configurations/fw3_config_examples#opening_ports_for_selected_subnethost).
On a aussi la fonctionnalité « ensemble IP » (ipset). (https://openwrt.org/docs/guide-user/firewall/firewall_configuration#ip_sets)
Quoiqu'il en soit, la configuration dans ce tutoriel me semble erronée. Je n'ai pas vu mentionné quelque part l'option list src_ip ou list dest_ip dans la documentation.
De même, le filtrage par adresse IP source / destination ne me paraît pas cohérent avec le RFC 8415.
Clients and servers exchange DHCP messages using UDP (see [RFC768] and BCP 145 [RFC8085]). The client uses a link-local address or
addresses determined through other mechanisms for transmitting and receiving DHCP messages.
A DHCP client sends most messages using a reserved, link-scoped multicast destination address so that the client need not be
configured with the address or addresses of DHCP servers.
Dans le tutoriel de cyayon « Use | Bring Your Own Router Orange ISP », on retrouve également le préfixe fe00::/7 pour définir la COS6 (pour ICMPv6).
fe00::/7 == fe80::/10 + ff02::/16
fc00::/6 == fc00::/7 (ULA) + fe00::/7
Mais le type d'adresses IPv6 (ULA, lien-local, multicast) n'est plus vraiment dissocié par rapport au préfixe.
-
Dans le fichier de configuration UCI pour les réglages du pare-feu, c'est confirmé comme étant un bogue. (https://github.com/openwrt/openwrt/issues/5066)
-
Hello,
J'ai remarqué que j'avais un souci au bout de 7 jours exactement.
Mon bail IPv6 est released mais n'est pas renouvelé sur l'interface et j'ai des erreurs qui apparaissent dans les logs.
Redémarrer l'interface ne résout pas le problème, il faut que je reboot le routeur.
Je n'ai pas essayé d'autre choses plus "fines" entre les deux, comme redémarrer certains services.
Voilà le log au moment où ça se passe :
Fri Feb 23 07:41:53 2024 daemon.notice netifd: wan4 (3438): udhcpc: sending renew to server 80.xxxxxxxx
Fri Feb 23 07:41:53 2024 daemon.notice netifd: wan4 (3438): udhcpc: lease of 86.xxxxxx obtained from 80.xxxxxx, lease time 604800
Fri Feb 23 07:41:56 2024 daemon.notice ttyd[5976]: [2024/02/23 07:41:56:7822] N: rops_handle_POLLIN_netlink: DELADDR
Fri Feb 23 07:41:56 2024 daemon.info avahi-daemon[3939]: Withdrawing address record for 2a01:xxxxxxxxxx::bad on br-lan.
Fri Feb 23 07:41:57 2024 daemon.warn odhcpd[1718]: A default route is present but there is no public prefix on lan thus we don't announce a default route by overriding ra_lifetime!
x 11
Fri Feb 23 07:42:36 2024 daemon.notice netifd: Interface 'wan6' has lost the connection
Fri Feb 23 07:42:36 2024 user.notice root: stopping ntpclient
Fri Feb 23 07:42:37 2024 daemon.warn odhcpd[1718]: No default route present, overriding ra_lifetime!
Fri Feb 23 07:43:49 2024 daemon.warn odhcpd[1718]: No default route present, overriding ra_lifetime!
Fri Feb 23 07:43:59 2024 daemon.warn odhcpd[1718]: No default route present, overriding ra_lifetime!
Fri Feb 23 07:44:00 2024 daemon.err nlbwmon[8867]: Netlink receive failure: Out of memory
Fri Feb 23 07:44:00 2024 daemon.err nlbwmon[8867]: Unable to dump conntrack: No buffer space available
Fri Feb 23 07:45:00 2024 cron.err crond[1779]: USER root pid 12329 cmd /etc/checknftrules.sh
Fri Feb 23 07:47:49 2024 daemon.warn odhcpd[1718]: No default route present, overriding ra_lifetime!
Fri Feb 23 07:47:50 2024 daemon.warn odhcpd[1718]: No default route present, overriding ra_lifetime!
Ma config :
config interface 'wan6'
option proto 'dhcpv6'
option device 'eth0.832'
option reqprefix 'auto'
option defaultreqopts '0'
option sendopts '11:xxxxxxxxxx
option reqopts '11 17 23 24'
option noclientfqdn '1'
option noacceptreconfig '1'
option clientid 'xxxxxxxx'
option reqaddress 'none'
option peerdns '0'
list dns 'xxxxxxx:8921'
list dns '2606:4700:4700::1111'
Est-ce que vous avez une idée du problème ? J'aimerais éviter faire une crontab qui reboot tous les 6 jours, c'est plutôt moche. :(
-
Salut,
En general si tu n'as un problème qu'au renouvellement c'est que la prio cs6 ne s'applique pas lors de renew.
Peux-tu verifier que tu as bien du match dans ta table "mangle_postrouting", depuis luci => Status/Firewall
Voici mon screenshot en exemple.
Biensur, il faut avoir préalablement ceci dans ton fichier "nft-prio6-rules.include"
oifname "eth0.832" counter meta priority set 0:1
oifname "eth0.832" ip protocol icmp counter meta priority set 0:6
oifname "eth0.832" ip protocol igmp counter meta priority set 0:6
oifname "eth0.832" udp dport 67 counter meta priority set 0:6
oifname "eth0.832" udp dport 547 counter meta priority set 0:6
oifname "eth0.832" ip protocol icmpv6 counter meta priority set 0:6
-
Bonjour ! @ubune
Il est très important de mentionner l'ONT et de préciser son rôle dans les pré-requis. Cela peut conditionner ses choix et permettre éventuellement
de faire une mise en adéquation avec ses attentes.
- Le routeur ne dispose pas de cage SFP ou SFP+.
- L'ONT et le routeur peuvent malheureusement s'avérer être incompatibles.
- L'utilisateur peut s'avérer dans l'incapacité de paramétrer correctement l'ONT.
- ...
Je pense plutôt qu'il faut dissocier l'explication/choix de l'ONT du tuto. Certains possedent encore l'ont d'orange par exemple.
Je vais juste mettre une remarque sur le fait qu'il doit être déjà present/synchro.
Comme tu le dis, OpenWrt peut être installé sur pleins de modèle/types de routeurs. Tu peux avoir un routeur avec des ports SFP/SFP+ ou uniquement des ports Ethernet, par exemple. C'est donc plutôt le choix du routeur qui déterminera la solution la plus logique du côté de l'ONT. Ou le choix de l'ONT si le routeur a déjà été acheté...
-
Peux-tu verifier que tu as bien du match dans ta table "mangle_postrouting", depuis luci => Status/Firewall
Merci pour ta réponse. J'ai vérifié que j'avais la bonne config et voilà ce que ça donne dans mon cas :
(https://i.imgur.com/AoFy3N1.png)
-
ce qui est plutôt curieux dans ton cas c'est de ne voir aucun match en dhcp (ipv4), et pourtant ça fonctionne.
Le fait de perdre ipv6 a chaque fin de bail c'est systématique ou aléatoire ?
Peux-tu vérifier cette fois que la rule qui permet le flux udp port 546 a également "match" ?
histoire d'être sûr que le routeur n'a pas drop (fw) la réponse d'orange lors du renew.
Exemple :
-
Désolé pour la confusion mais actuellement je suis sous les 7 jours vu que j'ai redémarré, je suis à 3 jours et quelques.
(https://i.imgur.com/LgpAU6t.png)
Donc je reviens poster les screenshots de ces 2 sections à 7 jours car cela m'arrive effectivement souvent mais ce n'est que récemment que j'ai associé la perte de l'IPv6 sur les machines de mon réseau à ce dépassement des 7 jours de connexion.
-
Hum aucun paquet.
Peux-tu supprimer la source et dest sur la règle ? ça ressemble au beug indiqué par Basilix plus haut => https://github.com/openwrt/openwrt/issues/5066
Si c'est bien ça le soucis je vais corriger le tuto/github.
Ta règle devra ressembler à ça :
config rule
option name 'Allow-DHCPv6'
option proto 'udp'
option dest_port '546'
option family 'ipv6'
option target 'ACCEPT'
option src 'wan6'
Edit : Pourtant orange envoi l'advertise avec l'ipv6 suivante : fe80::ba0:bab qui est une link local à destination du routeur (sur sa link local également) qui devrait bien match la règle (fc00::/6 ça inclus fc::* a ff::*).
Exemple vérifié à l'instant => eth0.832 In IP6 fe80::ba0:bab.547 > fe80::5239:2fff:fef2:c110.546: dhcp6 advertise
-
Pas de problème, je vais supprimer.
Mais je constate que j'ai d'autres trucs pas cleans du tout en revoyant les règles....
Par exemple ça, je pense que ça fait parti des règles de base que je n'ai pas supprimées.
config rule
option name 'Allow-DHCPv6'
option src 'wan'
option proto 'udp'
option dest_port '546'
option family 'ipv6'
option target 'ACCEPT'
Après je ne pense pas que ça match vu que j'ai vérifié et "wan" est bien une zone IPv4 only.
Dans le tuto, je remarque que les interfaces s'appellent "wan4" et "wan6" mais les zones c'est "wan" et "wan6", c'est voulu ?
Est- ce que les rules du tuto sont les rules à mettre et en supprimant ce qui est par défaut ?
Voilà ce que j'ai actuellement donc je vais nettoyer les règles incohérentes :
(https://i.imgur.com/7jSAFyG.png)
Enfin, je retire source et dest sur la rule :
config rule
option name 'Allow-DHCPv6'
option proto 'udp'
option dest_port '546'
option family 'ipv6'
option target 'ACCEPT'
option src 'wan6'
-
Ah ben d'ailleurs, y'a pas plus explicite que la CLI...
root@OpenWrt:~# /etc/init.d/firewall reload
Section @rule[3] (Allow-DHCPv6) is restricted to IPv6 but referenced source zone is IPv4 only, skipping
Section @rule[4] (Allow-MLD) is restricted to IPv6 but referenced source zone is IPv4 only, skipping
Section @rule[5] (Allow-ICMPv6-Input) is restricted to IPv6 but referenced source zone is IPv4 only, skipping
Section @rule[6] (Allow-ICMPv6-Forward) is restricted to IPv6 but referenced source zone is IPv4 only, skipping
Automatically including '/usr/share/nftables.d/ruleset-post/30-pbr.nft'
Automatically including '/usr/share/nftables.d/table-post/30-pbr.nft'
Automatically including '/usr/share/nftables.d/chain-post/mangle_forward/30-pbr.nft'
Automatically including '/usr/share/nftables.d/chain-post/mangle_input/30-pbr.nft'
Automatically including '/usr/share/nftables.d/chain-post/mangle_output/30-pbr.nft'
Automatically including '/usr/share/nftables.d/chain-post/mangle_postrouting/30-pbr.nft'
Automatically including '/usr/share/nftables.d/chain-post/mangle_prerouting/30-pbr.nft'
-
Dans le tuto, je remarque que les interfaces s'appellent "wan4" et "wan6" mais les zones c'est "wan" et "wan6", c'est voulu ?
Regarde le fichier fw importé depuis le github, quand tu créés une zone firewall, tu associes l'interface (ligne "list network" ci-dessous), fichier firewall complet ici : https://github.com/ubune/openwrt-livebox/blob/master/22-03/etc%20-%20wan%20name%20interface%20%3D%20eth0/config/firewall
Dans le tuto, la zone wan est associée à à l'interface wan4, et la zone wan6 est associée à l'interface wan6.
Il faut en effet supprimer les règles de base, ou alors simplement remplacer la zone wan par wan6 dans la règle par defaut.
Zone Wan
config zone
option name 'wan'
option output 'ACCEPT'
option family 'ipv4' ## Zone ipv4 only pour ne pas mélanger les règles sur les deux mondes
list network 'wan4'
option forward 'DROP'
option masq '1' ## On remplace l'ip source "privée" des flux sortant sur internet par l'ip publique reçu sur le wan4.
option input 'DROP'
Zone Wan6
config zone
option name 'wan6'
option input 'DROP'
option output 'ACCEPT'
option forward 'DROP'
option family 'ipv6' ## Zone ipv6 only pour ne pas mélanger les règles sur les deux mondes
list network 'wan6'
list device 'eth0.832'
-
Oui, je comprends.
Je disais que pour être cohérent, vu que la zone "wan" est explicitement "IPv4" only, on pourrait appeler cette zone "wan4" dans le tuto, ça enlèverait l'ambiguité.
J'ai fait le nettoyage dans les règles Firewall, plus qu'à attendre 3 jours. Merci pour ton aide en tout cas. :)
-
IPv6 PD à nouveau perdu au bout de 7 jours.
Avec ces lignes retirées:
list src_ip 'fc00::/6'
list dest_ip 'fc00::/6'
Voilà les captures du traffic sur le firewall :
(https://i.imgur.com/MUeK8C7.png)
(https://i.imgur.com/TeeG01n.png)
-
Je vais essayer de générer ma propre image. Cela semble plus efficace et robuste que de copier tel quels des fichiers de configuration.
Avertissement : Générer son image OpenWrt en compilant prend beaucoup de temps ! On peut éventuellement utiliser l'utilitaire « Image Builder (https://openwrt.org/docs/guide-user/additional-software/imagebuilder) ».
En fait, cela m'a surpris. Je ne pensais pas que l'ensemble des compilations aurait été duré aussi longtemps.
It is strongly recommended to use uci-defaults (https://openwrt.org/docs/guide-developer/uci-defaults) to incrementally integrate only the required customization. This helps minimize conflicts with auto-generated settings which can change between versions.
Bien que cela ne soit pas simple à cause du processus de construction (compilation). De façon générale, il faut bien parcourir la documentation (en recherchant ce qu'on souhaite)
car il y a des informations qui peuvent éventuellement rentrer en contradiction.
UCI is useful to view the firewall configuration, but not to do any meaningful modifications for the following reasons:
- Essential prior knowledge of where a firewall rule needs to go into the rule array in order to make it work.
- uci does not recognize content within the /etc/firewall.user script.
- uci commit is necessary to save the changes, but still needs /etc/init.d/firewall reload to reload new tables.
Note : Il faut néanmoins avoir un niveau avancé (Shell Unix, config. réseau, admin. système GNU/Linux...).
-
@ubune: Pour tester une perte de connexion (c.f. le script checkinternet.sh (https://github.com/ubune/openwrt-livebox)), il me semble qu'on utiliser Hotplug (https://openwrt.org/docs/guide-user/base-system/hotplug). Mais je ne sais pas encore comment procéder.
La règle de redirection du trafic WAN6 --> LAN dans le pare-feu est trop permissive.
! Adding the following forwarding rule below will expose ALL IPv6 ports behind a v6 host on the LAN, which is potentially very dangerous (https://openwrt.org/docs/guide-user/firewall/fw3_configurations/fw3_ipv6_examples#opening_ipv6_ports_to_lan_clients). Instead, you should selectively define allow IPv6 firewall rules to avoid this.
The documentation was previously worded in a way that stated this forwarding rule was needed to allow IPv6 traffic to flow properly. This is not true. You do not need to allow wan6 → lan to everything.
Sinon, à propos du changement de CoS (https://lafibre.info/remplacer-livebox/remplacement-de-la-livebox-par-un-routeur-openwrt-18-dhcp-v4v6-tv/msg988977/#msg988977), je partage l'opinion de Aize147. Je suis d'avis que tc filter est plus adapté. Idem, je ne sais pas encore comment procéder.
-
@ubune: Pour tester une perte de connexion (c.f. le script checkinternet.sh (https://github.com/ubune/openwrt-livebox)), il me semble qu'on utiliser Hotplug (https://openwrt.org/docs/guide-user/base-system/hotplug). Mais je ne sais pas encore comment procéder.
La règle de redirection du trafic WAN6 --> LAN dans le pare-feu est trop permissive.
Sinon, à propos du changement de CoS (https://lafibre.info/remplacer-livebox/remplacement-de-la-livebox-par-un-routeur-openwrt-18-dhcp-v4v6-tv/msg988977/#msg988977), je partage l'opinion de Aize147. Je suis d'avis que tc filter est plus adapté. Idem, je ne sais pas encore comment procéder.
Comme indiqué plusieurs fois sur le sujet, c'est pourtant ce que font toutes les freebox ! Deviner une ip même en connaissant ton /64 est plus complexe que scanner toutes les ipv4, et même si c'est routé par la freebox ou ton routeur openwrt ce n'est pas pour ça que le host autorisera le flux.
Bien sur en contexte hebergement/pro je n'aurai pas le même discours. Mais pour une tv connecté, smartphone et autre je ne trouve pas ça choquant ^^'.
Si tu drop les flux entrants, fait bien attention à ne pas filtrer certains messages icmpv6 => https://www.rfc-editor.org/rfc/rfc4890 .
Dans les règles openwrt par defaut il manque certains messages cités dans la rfc).
Concernant l'image builder, y'a un lien avec un exemple sur la première page du tuto, je trouve pas ça si long, quel problème as-tu rencontré ?
je l'utilise tout le temps, image avec tous les package et la conf => https://lafibre.info/remplacer-livebox/remplacement-de-la-livebox-par-un-routeur-openwrt-18-dhcp-v4v6-tv/msg1002177/#msg1002177
-
@ubune : Le concept c'est d'appliquer des filtres sur les paquets. Un principe de base en sécurité informatique est d'ajouter diverses protections.
C'est de la défense par obscurité quand on ne cherche pas à exercer un contrôle sur les flux. Ce qui me pose problème c'est que les gens mal
intentionné eux recherchent les failles. Que cela soit difficile ou non en principe, eux, dans la pratique, ils le feront si c'est possible. D'autant plus,
si personne n'y pense, pour que cela devienne imparable ou imperceptible. En tout cas, c'est ma conviction, même si je n'y connais rien (https://www.rfc-editor.org/rfc/rfc7707.html).
-
Concernant l'image builder, y'a un lien avec un exemple sur la première page du tuto, je trouve pas ça si long, quel problème as-tu rencontré ?
En fait, comme j'avais une expérience préalable avec Buildroot, j'ai voulu compiler l'image à partir des sources. Je me suis aperçu que leur instance de Buildroot ne
ressemblait plus vraiment à Buildroot. J'y tiens vraiment au code source et au logiciel libre.
The build system is used to build OpenWrt from the source code and requires significant hardware resources, time and knowledge. You can apply custom patches and build individual packages and OpenWrt images with specific compilation flags and options.
As an alternative, you can use the Image Builder to build OpenWrt images much faster and simpler at the cost of limited customization.
-
@ubune : Le concept c'est d'appliquer des filtres sur les paquets. Un principe de base en sécurité informatique est d'ajouter diverses protections.
C'est de la défense par obscurité quand on ne cherche pas à exercer un contrôle sur les flux. Ce qui me pose problème c'est que les gens mal
intentionné eux recherchent les failles. Que cela soit difficile ou non en principe, eux, dans la pratique, ils le feront si c'est possible. D'autant plus,
si personne n'y pense, pour que cela devienne imparable ou imperceptible. En tout cas, c'est ma conviction, même si je n'y connais rien (https://www.rfc-editor.org/rfc/rfc7707.html).
@ubune : Le concept c'est d'appliquer des filtres sur les paquets. Un principe de base en sécurité informatique est d'ajouter diverses protections.
C'est de la défense par obscurité quand on ne cherche pas à exercer un contrôle sur les flux. Ce qui me pose problème c'est que les gens mal
intentionné eux recherchent les failles. Que cela soit difficile ou non en principe, eux, dans la pratique, ils le feront si c'est possible. D'autant plus,
si personne n'y pense, pour que cela devienne imparable ou imperceptible. En tout cas, c'est ma conviction, même si je n'y connais rien (https://www.rfc-editor.org/rfc/rfc7707.html).
"Le concept c'est d'appliquer des filtres sur les paquets"
Non, le concept du réseau c'est de distribuer des paquets, de permettre la communication entre differents hotes.
Le concept de filtre est un concept de sécurité, il n'apporte rien de plus que de la sécurité.
Le réseau apporte un service.
Tu lances le débat, mais tu sais qu'en contexte pro, je passe mon temps à générer et appliquer des matrices de flux.
Et pourtant, pour avoir vécu différentes attaques/exploitation, je reste convaincu que le plus important c'est de sécuriser le host, pas le chemin.
Donc comme tu dis, le mieux est de faire les deux, c'est ce que je fais au quotidien.
Mais de la à dire, qu'en ipv6, autoriser les flux entrant sur ta box à la maison est "vraiment dangereux" je ne suis pas d'accord.
Le "vraiment dangereux", je le valide sur une machine/serveur ou tu n'appliques pas de politique de fw et/ou que tu ne durcis pas l'accès.
-
Question rhétorique : Que se passe t'il en cas de compromission de l'hôte ? L'attaquant a le chemin grand ouvert.
Je ne vais pas m'étendre là-dessus, c'est mon impression. Et je ne suis pas compétent pour en discuter.
-
Question rhétorique : Que se passe t'il en cas de compromission de l'hôte ? L'attaquant a le chemin grand ouvert.
Je ne vais pas m'étendre là-dessus, c'est mon impression. Et je ne suis pas compétent pour en discuter.
Mais c'est justement l'exemple qui m'a fait avoir cet avis !
Si un hôte est compromis, le plus gros risque est que les autres hôtes du lan (ou accessible depuis l'hôte compromis) ne soient pas sécurisé/durcis, pas qu'ils soient accessible depuis internet en ipv6...
As-tu un exemple de compromission d'hôte grâce à un flux ipv6 ouvert sur une freebox ?
Surement pas, par contre il existe des millions d'exemple de compromissions d'hôtes en exploitant des vulnérabilités, du fishing, du malware etc, d'ailleurs ça traverse très bien le nat hein ;)
-
Il faut un système durci. Est-ce envisageable ? C'est tout le problème.
En conséquence, le choix de Free ne m'inspire pas du tout confiance. C'est de la sécurité par obscurité (https://forum.manjaro.org/t/does-manjaro-has-disabled-firewall-by-default/69184).
-
Bonjour,
J'aimerais me lancer dans le remplacement de ma livebox 4 par un Banana PI R3 voire R4.
J'ai fait une petite recherche sur ce topic et je n'ai vu qu'une persone qui mentionne le banana PI R3...
Avez-vous des retours d'expérience ? Pas de problématiques particulières à signaler ?
Merci d'avance
-
Bonjour,
Merci pour les précieuses infos.
Je me suis lancé dans l'opération avec un nanopi r4s en suivant le tuto github pour juste la partie internet.
Une fois le /etc/config/network modifié en conséquence, lorsque j'essaie d'acceder au menu interface avec l'interface web luci, j'ai ce vilain message :
RPCError
RPC call to uci/get failed with ubus code 9: Unspecified error
at handleCallReply (http://192.168.17.1/luci-static/resources/rpc.js?v=git-23.236.53405-fc638c8:15:3
Any idea ?
EDIT : j'ai trouvé, ca vient de cette ligne https://github.com/ubune/openwrt-livebox/blob/324019a9d8d46e3fc0d12a468daae1574f93905d/22-03/etc%20-%20wan%20name%20interface%20%3D%20eth0/config/network#L57 où le commentaire est mal formaté (il manque un # !)
-
Bonjour,
Merci pour les précieuses infos.
Je me suis lancé dans l'opération avec un nanopi r4s en suivant le tuto github pour juste la partie internet.
Une fois le /etc/config/network modifié en conséquence, lorsque j'essaie d'acceder au menu interface avec l'interface web luci, j'ai ce vilain message :
RPCError
RPC call to uci/get failed with ubus code 9: Unspecified error
at handleCallReply (http://192.168.17.1/luci-static/resources/rpc.js?v=git-23.236.53405-fc638c8:15:3
Any idea ?
EDIT : j'ai trouvé, ca vient de cette ligne https://github.com/ubune/openwrt-livebox/blob/324019a9d8d46e3fc0d12a468daae1574f93905d/22-03/etc%20-%20wan%20name%20interface%20%3D%20eth0/config/network#L57 où le commentaire est mal formaté (il manque un # !)
Oups, c'est corrigé, merci