y'a pas que DHCLIENT non?

Certes, mais c'est lui qui fait le plus ch*er car dans l'optique ou la classification fonctionne(rait) sur l'ERL (A vérifier, même chez Ubiquiti ils ne savent pas nous dire avec certitude si ça va marcher ou pas avec l'offload...), si on doit tout "prioritiser" par défaut à 6 puis à 0, c'est bien à cause de lui.

Se passer d'offload à cause d'une règle CLASSIFY uniquement pour la téléphonie, je pense que c'est acceptable (sachant que déjà actuellement c'est le cas puisqu'on bridge et que l'offload sur un bridge n'est pas supporté). Par contre se passer totalement de l'offload parce qu'on doit classifier tout le traffic ça me gène déjà plus...

Certes, mais c'est lui qui fait le plus ch*er car dans l'optique ou la classification fonctionne(rait) sur l'ERL (A vérifier, même chez Ubiquiti ils ne savent pas nous dire avec certitude si ça va marcher ou pas avec l'offload...), si on doit tout "prioritiser" par défaut à 6 puis à 0, c'est bien à cause de lui.

Se passer d'offload à cause d'une règle CLASSIFY uniquement pour la téléphonie, je pense que c'est acceptable (sachant que déjà actuellement c'est le cas puisqu'on bridge et que l'offload sur un bridge n'est pas supporté). Par contre se passer totalement de l'offload parce qu'on doit classifier tout le traffic ça me gène déjà plus...

Je ne vois pas comment ils peuvent faire de l'offload ET supporter une classification "partielle" ?

tu croix que si on a une règle qui ne match que 'téléphonie, dhcp, arp, dhcpv6, icmpv6' alors les autres paquets peuvent être offload ?!
je ne vois pas comment. Un paquet qui ne match pas doit être testé pour voir s'il ne match pas ...non ?! :p si c'est complètement bypassé par l'offload c'est tout ou rien.
ou alors je n'ai pas compris ton message...

a beau y réfléchir un simple mapping "DSCP to skb->pri" est vraiment le plus simple. Ca se code facilement si on sait ou 

A lire mais en anglais    https://forum.pfsense.org/index.php?topic=63926.msg387713#msg387713
Mais tu connais peut-être déjà

oui j'ai vu mais le sujet est un peu mort depuis le temps.

j’avoue que PfSense dans l'ERL me plairait bien. Meme si on atteint pas 1Gbps en IPv6 on pourra peut-être l'atteindre en IPv6 (qui est plus simple a router rapidement c'est conçu pour ca quand meme: y'a pas de checksum et un flow label concu pour l'offload.).

1Gpbs en IPv6 et 240Mbps en IPv4 me conviendrait très bien vu le prix de l'ERL.

mais bon le port FreeBSD n'a pas bougé depuis 2014.

La passerelle domestique Livebox Play se base notamment sur des logiciels publiés sous une licence dite
libre ou open source, comme par exemple le noyau Linux, Busybox ou Iptables, tous les trois publiés selon
les termes de la licence GNU General Public License (GNU GPL). Le client peut consulter la liste des logiciels
concernés, leur licence et télécharger leur code source complet et correspondant sur le site web http://www.livebox-floss.com

http://www.livebox-floss.com:

Access Denied (policy_denied)

Your system policy has denied access to the requested URL.

For assistance, contact your network support team.

bj Orange !

Bien vu.

Du coup je télécharge ce qui concerne le firmware SG30_sip-fr-5.7.16 (le plus récent qu'on trouve sur le site).

En fait il y une copie complète des sources du noyau. Il faut que je trouve un moyen de trouver les différences avec le noyau officiel.

Edit:

Bon, le firmware de la livebox est basé sur le noyau 2.6.28.8. Du coup j'ai récupéré le code source d'origine sur kernel.org et j'ai fait un diff. Problème, chez Orange ils utilisent évidemment un système de gestion de révisions et ils ont committé l'ensemble du code source. Du coup il y a beaucoup de différences entre le code source d'origine et le code "orange" dues aux numéros de versions dans les headers des fichiers... Ca va être chaud d'analyser... Ceci dit j'ai déjà vu des différences dans le module 802.1q...

xt_CLASSIFY.c :

static unsigned int
classify_tg(struct sk_buff *skb, const struct xt_target_param *par)
{
const struct xt_classify_target_info *clinfo = par->targinfo;

if (clinfo->priority == 0xff) {
u_int8_t dscp = 0;
if (par->family == NFPROTO_IPV4) {
if(ip_hdr(skb)) {
dscp = ipv4_get_dsfield(ip_hdr(skb)) >> XT_DSCP_SHIFT;
}
}
else {
if(ipv6_hdr(skb)) {
dscp = ipv6_get_dsfield(ipv6_hdr(skb)) >> XT_DSCP_SHIFT;
}
}
skb->priority = (dscp >> 3) & 7;
}
else {
skb->priority = clinfo->priority;
}
return XT_CONTINUE;
}

comparé à la version du kernel d'origine:

static unsigned int
classify_tg(struct sk_buff *skb, const struct xt_target_param *par)
{
const struct xt_classify_target_info *clinfo = par->targinfo;

skb->priority = clinfo->priority;
return XT_CONTINUE;
}

Il y a surement d'autres modifications, et franchement tout interpréter ça dépasse largement mes compétences (et dire qu'à une époque j'avais osé postuler chez Texas Instruments pour bosser sur la plateforme OMAP4... Un peu prétentieux j'étais  ).

Pour l'instant on peut juste dire qu'ils utilisent iptables et CLASSIFY, mais une version perso...

Je vais en rester là pour l'instant, c'est le WE et si je continue c'est le divorce assuré...

Allez une petite dernière :

/*
 * Send an arp packet.
 */
void arp_xmit(struct sk_buff *skb)
{
skb->apFlowData.controlFlags |= IPQOS_HOQ_PACKET;
skb->priority = CONFIG_SAH_ARP_PRIORITY;
/* Send it off, maybe filter it using firewalling first.  */
NF_HOOK(NFPROTO_ARP, NF_ARP_OUT, skb, NULL, skb->dev, dev_queue_xmit);
}

Les 2 premières lignes qui configurent le skb ne sont pas dans le kernel d'origine.

Bah non puisqu'ils publient le code source de leur modification.