Remplacer la LiveBox par un routeur => Discussion démarrée par: pinomat le 02 août 2020 à 19:55:23 Remplacer la LiveBox par un routeur => Discussion démarrée par: pinomat le 02 août 2020 à 19:55:23set service dns forwarding dhcp ethx.832) --> je suis donc obligé de forcer les DNS avec set service dns forwarding name-server x.x.x.xHello,
Je vous propose en dhclient patché avec la priorité 6 (kernel) sur base de la version 2.0.8-hotfix1 du firmware de l'er-6p. J'en avais marre des règles iptables pour dhcp et/ou du marquage via le switch.
J'ai compilé sur base du patching des sources qui se trouve ici https://github.com/shisva/USG_Orange (https://github.com/shisva/USG_Orange) et réalisé par mike78530 dans le tuto https://lafibre.info/remplacer-livebox/le-guide-complet-pour-usgusg-pro-internet-tv-livebox-ipv6/ (https://lafibre.info/remplacer-livebox/le-guide-complet-pour-usgusg-pro-internet-tv-livebox-ipv6/).
Seul problème que je rencontre actuellement, qui n'est pas obligatoirement lié à ce patch, c'est la récupération des DNS du DHCP (Code: [Sélectionner]set service dns forwarding dhcp ethx.832) --> je suis donc obligé de forcer les DNS avecCode: [Sélectionner]set service dns forwarding name-server x.x.x.x
Il faut donc remplacer le fichier (après avoir fait un backup) se trouvant /sbin/dhclient3 par celui fourni et ajouter le droit d'exécution (sudo chmod +x /sbin/dhclient3). Ensuite, par rapport à ma configuration, il faut aussi ajouter l'egress-qos 6:6 à l'interface WAN (ethx.832).
Merci encore pour les infos et bonne soirée à tous.
tu pourais partager le patch final? J'aimerais pouvoir compiler le mien. Tu qs fait quel changement dans le fichier discover.c?
Bizarre, le patch est quand même très similaire au mien (avec exactement les mêmes commentaires ;) ). Les modifications sont vraiment simples (et ne concernent pas que discover.c): Après avoir créé une socket, on configure sa priorité (SOL_PRIORITY) à 6, ce qui correspond à une priorité NOYAU. Ensuite, avec la ligne egress-qos de la configuration d’EdgeOS on mappe cette priorité noyau sur une priorité 802.1p.
Quand j’ai fait le patch, je ne me suis pas emmerdé à analyser à quels endroits les changements étaient nécessaires, je l’ai fait pour toutes les sockets sans distinction...
Bon sinon tu l’as généré à l’envers (il devrait y avoir des lignes débutant avec + car on rajoute de code au lieu de - qui indique qu’on supprime des lignes).
@@ -454,6 +458,10 @@
return 0;
}
+ /* Set Kernel Priority to 6 */
+ int val = 6;
+ setsockopt(ifaces->sock, SOL_SOCKET, SO_PRIORITY, &val, sizeof(val));
+
#ifdef DHCPv6
if (local_family == AF_INET6) {
ifaces->fp6 = fopen("/proc/net/if_inet6", "r");Bizarre, le patch est quand même très similaire au mien (avec exactement les mêmes commentaires ;) ). Les modifications sont vraiment simples (et ne concernent pas que discover.c): Après avoir créé une socket, on configure sa priorité (SOL_PRIORITY) à 6, ce qui correspond à une priorité NOYAU. Ensuite, avec la ligne egress-qos de la configuration d’EdgeOS on mappe cette priorité noyau sur une priorité 802.1p.
merci pour le patch. Je l'ai remis dans l'orde pour ceux que cela interesse:--> J'ai corrigé mon fichier après la remarque de zoc, vous allez trop vite, j'ai pas le temps de répondre !!!
cat /etc/resolv.conf
#line generated by /opt/vyatta/sbin/vyatta_update_resolv.pl
domain home.loc
nameserver 81.253.149.13 #nameserver written by /opt/vyatta/sbin/vyatta_update_resolv.pl
nameserver 80.10.246.5 #nameserver written by /opt/vyatta/sbin/vyatta_update_resolv.pl
D'ailleurs, pour info, j'avais testé uniquement avec la correction du fichier lpf.c et c'était suffisant (mais je préfère le mettre partour, ca ne coute aps grand chose) :/
--> J'ai corrigé mon fichier après la remarque de zoc, vous allez trop vite, j'ai pas le temps de répondre !!!
/etc/resolv.conf et les serveurs sont revenus ^^
En revanche, sur les connexions FTTH Orange de mon périmètre, j'ai récemment fait la migration inverse, c-a-d utiliser des switchs Cisco au lieu du client patché.
Tu en aurais un pas trop cher à conseiller?Du classique SG350-24/48(P)
Du classique SG350-24/48(P)
Tonitrus a de bons prix, et en reconditionné on trouve parfois de bonnes affaires sur Ebay.
Après 24/48, PoE ou non, tout dépend de ce que tu veux en faire.
Par contre, de là à n'acheter un Cisco que pour cela, oui la question d'utiliser le client patché peut se poser :)
Pour ma part, j'ai récemment compilé sous une VM QEMU en utilisant plus ou moins ce guide :--> J'avais testé ce tuto mais je n'ai jamais réussi à compiler pour Octeon (au lieu de Malta).
- cela permet également de forcer le DSCP à 0x00 pour le trafic LAN ---> ROUTEUR, car il y a des baisses de débit si on envoie autre chose que cette prio :Je n'avais pas encore vu de tels commentaires concernant des problèmes de performance avec les DSCP. A priori, on peut remettre les DSCP à 0 de tout le traffic LAN sur certains switch (dont le sg350), donc théoriquement, pas besoin d'utiliser le switch pour forcer le PCP des paquets DHCP envoyés à Orange. J'ai l'impression que c'est pour des cas spécifiques qu'il y a des problèmes. Au final est-ce que la Livebox supprime le DSCP en sortie ?
| Source | Destination | Protocol | Info | CoS/PCP | DSCP |
| LB | Broadcast | ARP | * | 6 | n/a |
| LB | ff02::1:2 | DHCPv6 | Solicit | 6 | 0xc0 |
| LB | 193.253.170.18 | DNS | Standard query | 0 | 0x00 |
| LB | 193.253.170.18 | TCP | * | 0 | 0x00 |
| LB | 80.12.255.65 | TCP | SYN | 0 | 0x00 |
| LB | 80.12.255.65 | TCP | ACK, FIN | 4 | 0x90 |
| LB | 193.253.170.18 | TLS1.2 | Client Hello | 0 | 0x00 |
| LB | 193.253.170.18 | TLS1.2 | Application Data | 0 | 0x00 |
| LB | 193.253.170.18 | TLS1.2 | Certificate, Client Key Exchange, Certificate Verify, Change Cipher Spec, Encrypted Handshake Message | 0 | 0x00 |
| LB | 193.253.170.18 | TLS1.2 | Encrypted Alert | 0 | 0x00 |
| LB | 80.12.255.65 | TLS1.2 | Client Hello | 4 | 0x90 |
| LB | 80.12.255.65 | TLS1.2 | Application Data | 4 | 0x90 |
| LB | 80.12.255.65 | TLS1.2 | Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message | 4 | 0x90 |
| LB | 80.12.255.65 | TLS1.2 | Encrypted Alert | 4 | 0x90 |
| LB | 81.253.173.116 | SIP | * | 5 | 0xb8 |
| Ubiquiti | IGMPv2 | Membership Query | 0 | 0xc0 | |
| Ubiquiti | ICMP | Destination unreachable | 0 | 0xd0 |
--> J'avais testé ce tuto mais je n'ai jamais réussi à compiler pour Octeon (au lieu de Malta).Je ne saisis pas toutes les subtilités Malta / Octeon mais il me semble que l'ARCH étant identique (mips), les binaires issus d'une compilation sont identiques.
'Je n'avais pas encore vu de tels commentaires concernant des problèmes de performance avec les DSCP. A priori, on peut remettre les DSCP à 0 de tout le traffic LAN sur certains switch (dont le sg350), donc théoriquement, pas besoin d'utiliser le switch pour forcer le PCP des paquets DHCP envoyés à Orange. J'ai l'impression que c'est pour des cas spécifiques qu'il y a des problèmes. Au final est-ce que la Livebox supprime le DSCP en sortie ?Moi non plus, jusqu'au changement de DSCP par défaut d'openSSH sous Centos 8.
Je ne saisis pas toutes les subtilités Malta / Octeon mais il me semble que l'ARCH étant identique (mips), les binaires issus d'une compilation sont identiques.Moi non plus ^^ Je crois que c'est simplement de l'optimisation.
- le trafic normal sortant (donc en CoS=0) sera parfois bridé si le DSCP des paquets IP est différent de 0, il ne s'agit pas d'un effet de bord de l'egress-qosOui, j'avais aussi constaté qu'avec un CoS <> 0 les débits étaient bridés, il y a eu aussi différents posts/articles le mentionnant. Intéressant ton problème de transfert !
Oui, j'avais aussi constaté qu'avec un CoS <> 0 les débits étaient bridés, il y a eu aussi différents posts/articles le mentionnant. Intéressant ton problème de transfert !Oui mais pas uniquement si la CoS <> 0, c'est ça qui est un peu inattendu.
Bizarre, le patch est quand même très similaire au mien (avec exactement les mêmes commentaires ;) ). Les modifications sont vraiment simples (et ne concernent pas que discover.c): Après avoir créé une socket, on configure sa priorité (SOL_PRIORITY) à 6, ce qui correspond à une priorité NOYAU. Ensuite, avec la ligne egress-qos de la configuration d’EdgeOS on mappe cette priorité noyau sur une priorité 802.1p.
Quand j’ai fait le patch, je ne me suis pas emmerdé à analyser à quels endroits les changements étaient nécessaires, je l’ai fait pour toutes les sockets sans distinction...
Bon sinon tu l’as généré à l’envers (il devrait y avoir des lignes débutant avec + car on rajoute de code au lieu de - qui indique qu’on supprime des lignes).
Pour avoir téléchargé UniFi Security Gateway firmware 4.4.51 impossible de retrouver les fichiers que j’avais dans l’archive UniFi Security Gateway firmware 4.4.41
Alors peut être que je cherche mal, mais bon je ne m’y aventure plus 😄