Auteur Sujet: Remplacer sa Livebox par un routeur Ubiquiti Edgemax (Lu 1529885 fois)

tivoli · « **Réponse #2124 le:** 08 février 2016 à 12:33:36 »

Interessant, j'imagine qu'a minima on perd l'offloading ? si c'est le cas autant le faire sur un er-x (si j'ai bien lu il a un port serie interne)

BM92 · « **Réponse #2125 le:** 08 février 2016 à 19:40:21 »

Citation de: kgersen le 08 février 2016 à 10:04:48

Ensuite j'ai rapidement testé OpenBSD: la c'est nettement mieux. y'a un support officiel donc des builds réguliers et une doc d'installation: http://www.openbsd.org/octeon.html
Par contre il est impératif d'avoir un cable série pour installer OpenBSD (et FreeBSD aussi d'ailleurs).

On attend tout tes retours d'expérience et surtout comment faire

kgersen · « **Réponse #2126 le:** 09 février 2016 à 11:23:17 »

bon succès pour OpenBSD sur l'ERL avec Orange en DHCP... en IPv4 du moins.
Je n'ai pas été plus loin dans la conf (IPv6, TV, etc) car la performance n'est pas la:

J'obtient au mieux 18,8 Mo/s soit 144 Mbps. Le NAT+marquage QoS tuent la perf comme on s'y attendait.
J'ai meme pas tester l'upload qui doit être pire niveau marquage.

Je ne sais pas si il y a trop d’intérêt a poursuivre dans cette voie. En IPv6 on aura peut-etre mieux mais ce n'est meme pas sur. Si j'ai un moment je continuerai. Si quelqu'un veut continuer les tests en OpenBSD voici la la méthode de configuration (cable série pour ERL impératif).

Vu qu'il y a 2 sujets sur Orange en DHCP, on peut parler des points spécifiques a cela dans l'autre sujet: https://lafibre.info/remplacer-livebox/remplacer-la-livebox-sans-pppoe/ voir ouvrir un 3eme sujet...

zoc · « **Réponse #2127 le:** 09 février 2016 à 11:52:10 »

Personnellement, quand ce sera possible chez moi (A partir du 15 mars si le planning qui a été publié dans actus est correct), je continuerai à investiguer les hypothèses que j'ai levées:

Modifier dhclient pour avoir un skb_prio différent de 0 afin de pouvoir profiter du mapping skb_prio -> 802.1p qui est dans le code noyau
Utiliser la target CLASSIFY pour le reste, au moins pour confirmer officiellement que ça ne marche pas avec l'offload (parce que les "maybe" du support d'Ubiquiti, je ne peux pas m'en contenter

Et d'ailleurs, je me pose une autre question: Qu'est-ce qu'il se passe si on ne met la priorité 802.1p 6 qu'aux paquets DHCP et DHCP6, et que tout le reste en priorité 0 (y compris ce qui ne devrait pas y être) ? Si ça fonctionne quand même, alors mon idée de patcher dhclient devrait suffire, on aurait même pas besoin d'utiliser de règles CLASSIFY...

zoc · « **Réponse #2128 le:** 09 février 2016 à 14:03:02 »

Bon, mon patch ne changera finalement rien au problème, car manifestement un paquet raw bypass aussi le calcul du skb_priority. En effet, avec un TOS de 0x10, skb_priority devrait déjà être à 6... :

Dans le kernel, la fonction qui convertit le TOS en skb_priority est la suivante:

Code: [Sélectionner]

static inline char rt_tos2priority(u8 tos)
{
    return ip_tos2prio[IPTOS_TOS(tos)>>1];
}

IPTOS_TOS est une macro qui fait un "et logique" entre "tos" et 0x1E. Donc entre 0x10 et 0x1E, ce qui donne 0x10.

Ensuite la valeur est divisée par 2 (shift à droite), donc on obtient 0x8.

Sachant que le tableau ip_tos2prio est défini comme suit:

Code: [Sélectionner]

const __u8 ip_tos2prio[16]={0,0,0,0,2,2,2,2,6,6,6,4,4,4,4};

A l'index 0x8 (les index commencent à 0 en C pour ceux qui ne savent pas), il y a bien 6.

En pratique, on (@zommak et @kgersen) a remarqué que la prio est à 0. Conclusion, pas de mapping TOS -> skb_priority -> 802.1p pour les paquets RAW...

kgersen · « **Réponse #2129 le:** 09 février 2016 à 16:36:41 »

la capture d'une livebox donne (1er paquet DHCP/BOOTP, un broadcast Discover):

Frame 81: 380 bytes on wire (3040 bits), 380 bytes captured (3040 bits) on interface 0 Ethernet II, Src: Sagemcom_93:xx:xx(00:37:b7:xx:xx), Dst: Broadcast (ff:ff:ff:ff:ff:ff) 802.1Q Virtual LAN, PRI: 6, CFI: 0, ID: 832 Internet Protocol Version 4, Src: 0.0.0.0, Dst: 255.255.255.255 0100 .... = Version: 4 .... 0101 = Header Length: 20 bytes Differentiated Services Field: 0xc0 (DSCP: CS6, ECN: Not-ECT) 1100 00.. = Differentiated Services Codepoint: Class Selector 6 (48) .... ..00 = Explicit Congestion Notification: Not ECN-Capable Transport (0) Total Length: 362 Identification: 0x0000 (0) Flags: 0x00 Fragment offset: 0 Time to live: 64 Protocol: UDP (17) Header checksum: 0x78c4 [validation disabled] Source: 0.0.0.0 Destination: 255.255.255.255 [Source GeoIP: Unknown] [Destination GeoIP: Unknown] User Datagram Protocol, Src Port: 68 (68), Dst Port: 67 (67) Bootstrap Protocol (Discover)

couche 2 (802.1p) on a bien le PCP a 6,le VLAN a 832
couche 3 (IP) on a le DSCP a CS6 (= valeur 48)
couche 4 (UDP) on n'a pas d'adresse source, raison de l’utilisation de "raw socket" j'imagine

j'ai regardé le "code source" de la livebox:
dans
opensrc/sah/kernel/IKANOS/GEN/R_LRG_8.1/PROJ/SAGEM_PROV3/REL/2014-09-23_V2.11.0/net/8021q/vlan_dev.c
on voit comment la prio est 'émise' dans le PCP. c'est bien le skb qui va dans le PCP.

J'ai aussi regardé la code source du client DHCP busybox (dans opensrc/sah/services/busybox-x.x.x/networking/udhcp), la fonction qui envoi le discover est "udhcp_send_raw_packet" (dans packet.c) (en suivant depuis send_discover) mais y'a rien sur la prio.

donc ils font ca ailleurs ou ca n'est pas le code utilisé en live ou ils ont un autre client dhcp. je suis perplexe et je n'ai pas tout compris encore :p

zoc · « **Réponse #2130 le:** 09 février 2016 à 16:47:40 »

Il ne reste pas des tonnes de possibilités je pense en terme de client dhcp qui supporte l'ensemble des features nécessaires à Orange sans devoir le patcher (et publier les modifications si le client est en GPL) : dhcpcd (~~qui de mémoire ne requiert pas un kernel qui supporte les sockets RAW~~).

Edit: J'ai barré la connerie que j'ai dite, je viens d'aller voir le code de dhcpcd

Après, j'ai vu dans l'arborescence du noyau un module qui n'existe pas dans le noyau officiel et dans les commentaires, ça parle de "dhcp relay"... A voir à quoi ça sert...

kgersen · « **Réponse #2131 le:** 09 février 2016 à 17:15:31 »

y'a vraiment rien qui permet d'intervenir plus bas que les raw socket ? c'est le driver ensuite donc ?

en theorie, les raw socket supportent a priori la QoS avec setsockopt et SO_PRIORITY. on pourrait tester.

y'a un petit code ici: https://github.com/JohannesBuchner/DHCProbe qui fait juste le discover. on devrait pouvoir le patcher pour ajouter CS6 et voir si ca fonctionne dans l'ERL... j'ai juste pas la toolchain qui va bien. non bah lui n'utilise pas de raw socket.

zoc · « **Réponse #2132 le:** 09 février 2016 à 17:43:53 »

Oui j'avais vu pour cette histoire de SO_PRIORITY.

Je@nb · « **Réponse #2133 le:** 09 février 2016 à 21:00:21 »

De ce que j'ai vu dans le code de isc-dhcp :
- Le TOS est bien à ip.ip_tos = IPTOS_LOWDELAY (0x10); et on le voit bien dans la capture, le champs TOS a la bonne valeur.
- Le client DHCP, en fonction de la plateforme pour laquelle il est compilée utilise plusieurs librairies bas niveau. Pour nous sur Linux, on utilise LPF (linux packet filter).

Dans ce mode là, on fait un raw socket très avancé :
if ((sock = socket(PF_PACKET, SOCK_PACKET,
htons((short)ETH_P_ALL))) < 0) {

Ce qui veut dire qu'on construit à la fois la couche 2 et 3 (alors qu'on peut construire un raw socket avec que la couche 3 via un sock = socket (AF_INET, SOCK_RAW, IPPROTO_RAW); par exemple. (vu ici http://www.pdbuchan.com/rawsock/rawsock.html )
C'est le code dans ethernet.c qui crée la trame ethernet via assemble_ethernet_header. La trame ethernet est une trame ethernet standard, pas 802.1q.

Cette trame est envoyé via LPF au noyau.
Vu que notre interface "vlanisée" est configurée pour "reorder" les trames, Linux lui même va faire le job pour réintégrer nos headers dans sa trame 802.1q.
Ca se voit qd on fait un cat /proc/net/vlan/eth1.832 : eth1.832 VID: 832 REORDER_HDR: 1

Le README du client dhcp met bien :

Citer

LINUX: 802.1q VLAN INTERFACES

If you're using 802.1q vlan interfaces on Linux, it is necessary to
vconfig the subinterface(s) to rewrite the 802.1q information out of
packets received by the dhcpd daemon via LPF:

vconfig set_flag eth1.523 1 1

Note that this may affect the performance of your system, since the
Linux kernel must rewrite packets received via this interface. For
more information, consult the vconfig man pages.

Donc là LPF va juste réécrire notre trame en 802.1q mais ne rajoutera jamais notre information skb priority.
Voilà où j'en suis de mes recherches.
A la base je cherchais à modifier le code de dhcp pour mettre le skb priority moi même mais vu que pour le client dhcp 802.1q il connait pas

c'est DTC

Je@nb · « **Réponse #2134 le:** 09 février 2016 à 21:05:44 »

https://kb.isc.org/article/AA-00379/0/How-DHCP-uses-raw-sockets.html

A priori on pourrait se passer de raw socket en fait ...

Mais ils parlent que de solaris 11, ça marche sur linux vous croyez ? (à moins que ce soit juste pour le serveur dhcp)
Pas le temps ce soir de regarder ça :/

kgersen · « **Réponse #2135 le:** 09 février 2016 à 21:50:18 »

hum je ne comprend plus la... si ca utilise LPF ca veut dire qu'on peut faire une règle CLASSIFY non?
Hors jusqu’à present aucune règle CLASSIFY ne marche sur le trafic DHCP sortant, signifiant bien que ca ne passe par LPF. non ?

tu ne confonds pas plutôt Linux Packet Filter (utilisé par netfilter/iptables) et Linux Socket Filter (utilisé par tcpdump) ? ca n'est pas la meme chose.

et le sens de fonctionnement est important. on ne fait pas la meme chose en emission qu'en reception.
Dans notre cas, y'a que l'émission qui nous importe.

Le code du client dhcp de busybox utilise un {PF_PACKET, SOCK_DGRAM, ETH_P_IP} en emission (et pas un SOCK_PACKET)
en reception également mais il attache un filtre avec un setsockopt SO_ATTACH_FILTER (= Linux Socket Filtering ).