La Fibre
Datacenter et équipements réseaux => Routeurs => 
Remplacer la LiveBox par un routeur => Discussion démarrée par: moviuro le 05 mars 2023 à 12:10:08
-
Hello,
Je vais récapituler ici ce que j'ai fait, et qui est fonctionnel pour une machine OpenBSD 7.2+ (il y a eu des changements impactants dans la 7.2, entre autres la simplification de dhclient qui nous est dorénavant inutile).
Si vous êtes ici, vous avez probablement une bonne idée de ce que vous faites (chers collègues barbus au chapeau d'alu) ; et si non, lisez le manuel, c'est surtout pour ça qu'on utilise OpenBSD. Mon article original est en anglais (https://try.popho.be/securing-home2.html).
Paquets nécessaires : dhcpcd(8) (une version qui inclut ce patch (https://github.com/NetworkConfiguration/dhcpcd/commit/79c3ba7c2a5ac95647512ef58d8973aac206cb77) : fin mai 2023, il s'agit donc de la version dhcpcd-10.0.1pl20230518v0 du paquet, disponible dans les ports ou paquets (https://cvsweb.openbsd.org/ports/net/dhcpcd/Makefile?rev=1.102&content-type=text/x-cvsweb-markup)) ; igmpproxy(8) pour la TV.
(Pour info, dibbler est mort en 2017 (https://klub.com.pl/dhcpv6/))
On crée les fichiers hostname.if(5) qui vont bien pour le VLAN832 (Internet).
# /etc/hostname.vlan832
# llprio c'est pour les paquets DHCP
parent em1 vnetid 832 llprio 6
description "ISP uplink"
up
# /etc/hostname.em1
# lladdr c'est la véritable MAC de la Livebox
lladdr "xx:xx:xx:xx:xx:xx"
up
Les tokens d'authentification à envoyer à Orange périment, donc on doit : générer régulièrement un token, l'intégrer dans dhcpcd.conf(5) et demander à dhcpcd(8) de MAJ la lease.
# cat /etc/dhcpcd.conf.head
# dual-stack IPv4 et IPv6
noipv4ll
nohook hostname ntp.conf
allowinterfaces vlan832
debug
# based on https://blog.brimbelle.org/index.php/2018/04/30/fibre-orange-ipv6-et-dhcpcd/
interface vlan832
# 00030001<MAC_ADDRESS_LIVEBOX_SANS_DEUXPOINTS> dans /var/db/dhcpcd/duid
# iaid below = 4 derniers octets de la MAC de la livebox
iaid 01234567
# on demande une route IPv6 par défaut -- pas besoin de hook spécifique
ipv6rs
# delegation de /64s à d'autres interfaces. rad(8) s'en occupera
# les interfaces ci-dessous dépendent bien sûr de votre config... j'ai un VLAN pour les invités, les enfants, l'IoT...
ia_pd 01234567 vlan49//64 vlan50//64 vlan51//64 em0//64
option auth
userclass FSVDSL_livebox.Internet.softathome.Livebox4
vendclass 1038 sagem
authprotocol token 0x123/0x456
# Le token 0x456 ci-dessous est un magic string (dhcplivebox250) qu'Orange renvoie
authtoken 0x456 "" forever 64:68:63:70:6c:69:76:65:62:6f:78:66:72:32:35:30
# TRÈS IMPORTANT, PAS DE RETOUR À LA LIGNE, JUSTE UNE ESPACE
# TRÈS IMPORTANT, FONCTIONNEL UNIQUEMENT AVEC dhcpcd > 9.4.1
authtoken 0x123 "" forever 🚫
Pour effacer le retour à la ligne à la fin du fichier, on utilise :
dest=/etc/dhcpcd.conf.head
dd if=/dev/null of="$dest" obs="$(( $(wc -c < "$dest") -1 ))" seek=1
Orange ne délivre pas d'IPv6 pour le routeur dans la lease DHCPv6, c'est pour ça qu'on a le ipv6rs.
Pour générer le token d'authentification (option 90, etc.) : un script largement inspiré du présent forum (https://git.sr.ht/~moviuro/moviuro.bin/tree/master/item/orange_hexauth)
# cat /usr/local/bin/orange_hexauth
#!/bin/sh
# Heavily inspired by https://lafibre.info/remplacer-livebox/tuto-remplacer-la-livebox-par-un-routeur-dd-wrt-internet-tv/
__usage(){
cat << EOH
$0 [-h]
$0 creates a hex stream (that is not \\n terminated) that can be used in DHCP
clients (v4 and v6) to authenticate to Orange France's network. The hex stream
is intended to be cat(1)-ed with configuration parts to create a complete file
(such as dhclient.conf(5)).
-h : display this help text
ENVIRONMNENT VARIABLES
You MUST specify FTI_USER and FTI_PASS as written in your (paper) contract with
Orange.
EXAMPLES
In crontab:
FTI_USER=fti/...
FTI_PASS=...
~ 1 * * 0 $0 > /etc/orange_auth_string
~ 2 * * 0 cat /etc/dhclient.conf.head /etc/orange_auth_string /etc/dhclient.conf.tail > /etc/dhclient.conf
~ 3 * * 0 dhclient vlan832
CAVEATS
Only tested on OpenBSD
EOH
}
while getopts ':h' _opt; do
case "$_opt" in
h) __usage ; exit 0 ;;
*) __usage >&2 ; exit 1 ;;
esac
done
shift "$((OPTIND-1))"
: "${FTI_USER?"Missing mandatory variable, see $0 -h"}"
: "${FTI_PASS?"Missing mandatory variable, see $0 -h"}"
if ! command -v openssl >/dev/null 2>&1; then
echo "openssl(1) was no found. WTF?" >&2
exit 2
fi
if ! command -v md5 >/dev/null 2>&1; then
md5() {
openssl md5 | cut -d' ' -f2
}
fi
# translates individual characters to their hex counterpart and prefixes each
# with `:`
# __tohex foo
# > :66:6f:6f
__tohex() {
printf '%s' "$1" | hexdump -ve '1/1 ":%.2x"'
}
case "$FTI_USER" in
fti/*) : ;;
*) FTI_USER="fti/$FTI_USER" ;;
esac
# random strings
# let's hope this never changes, because if Orange starts using "predictable"
# strings, we're in deep (think: TOTP)
: "${_r:="$(openssl rand -base64 12)"}"
: "${_c:="$(openssl rand -base64 1 | cut -c 1)"}"
# "header"
_o90="1a:09:00:00:05:58:01:03:41"
_o90="$_o90:01:0d$(__tohex "$FTI_USER")"
_o90="$_o90:3c:12$(__tohex "$_r")"
_o90="$_o90:03:13$(__tohex "$_c")"
_o90="$_o90$(printf '%s' "$_c$FTI_PASS$_r" | md5 | sed 's/\(..\)/:\1/g')"
cat << EOM >&2
Generated on $(date) with _r=$_r and _c=$_c
EOM
echo -n "${_o90}"
Avant de vérifier que ça fonctionne, on doit s'occuper des priorités de paquets dans pf.conf(5) :
# cat /etc/pf.conf
# martians also includes IPv6 martians
table <martians> { ... }
...
# tous les paquets ont priorité 1 et TOS 0x00
# (la priorité 0 limitait l'upload à 3Mbps alors que prio 1 : 300Mbps+)
match out log on egress set prio 1 tos 0x00
# pas de règle pour DHCPv4, c'est priorité 6 car llprio dans /etc/hostname.vlan832
# https://lafibre.info/remplacer-livebox/durcissement-du-controle-de-loption-9011-et-de-la-conformite-protocolaire/
# DHCPv6 COS 6
match out log on egress inet6 from (self) to ff02::1:2 set prio 6
match out log on egress inet6 proto icmp6 from (self) to fe80::ba0:bab icmp6-type { neighbrsol neighbradv } set prio 6
# peut-être n'est-ce pas nécessaire d'être aussi stricte dans les règles ci-dessus ? ce qui donne...
#match out log on egress inet6 proto icmp6 from (self) set prio 6
...
pass in quick log inet6 from fe80::ba0:bab to (self)
...
# NAT interieur -> extérieur pour les invités
match out log on egress inet from ($guest_if:network) to ! (self:network) nat-to (egress)
pass in quick log on $guest_if to ! (self:network)
# Martians should never be a source on packets going out
block out quick log on egress from <martians>
pass out quick log
# pfctl -vf /etc/pf.conf
Et maintenant on peut faire un premier test de dhcpcd:
# FTI_PASS="..." FTI_USER="fti/..." /usr/local/bin/orange_hexauth > /etc/orange_auth_string
# cat !$
1a:09:00:00:05:58........
# cat /etc/dhcpcd.conf.head !$ > /etc/dhcpcd.conf
# dhcpcd -V
....
# ifconfig vlan832
vlan832: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
lladdr xx:xx:xx:xx:xx:xx
description: ISP link
index 11 priority 0 llprio 3
encap: vnetid 832 parent em1 txprio packet rxprio outer
groups: vlan egress
media: Ethernet autoselect (1000baseT full-duplex)
status: active
inet6 fe80::xxxx:xxff:fexx:xxxx%vlan832 prefixlen 64 scopeid 0xb
inet 90.xx.xx.xx netmask 0xfffffc00 broadcast 90.xx.xx.255
# netstat -nrfinet
Routing tables
Internet:
Destination Gateway Flags Refs Use Mtu Prio Iface
default 90.xx.xx.1 UG 6 123631 - 56 vlan832
...
# netstat -nrfinet6
Routing tables
Internet6:
Destination Gateway Flags Refs Use Mtu Prio Iface
default fe80::ba0:bab%vlan832 UGS 1 101587 - 8 vlan832
...
Et on automatise dans crontab(5):
# retrouvez les valeurs dans votre contrat papier
FTI_USER=fti/...
FTI_PASS=...
~ 1 * * 0 /usr/local/bin/orange_hexauth > /etc/orange_auth_string
~ 2 * * 0 cat /etc/dhcpcd.conf.head /etc/orange_auth_string > /etc/dhcpcd.conf
# dhcpcd rebind
~ 3 * * 0 dhcpcd -n
Et pour lancer le service dhcpcd avec le reste, on va piquer directement dans les sources du port : dhcpcd.rc (https://raw.githubusercontent.com/openbsd/ports/master/net/dhcpcd/pkg/dhcpcd.rc)
Voilà, une machine OpenBSD connectée au réseau Orange. Reste plus qu'à configurer dhcpd(8) pour servir les clients en IPv4 dans les réseaux locaux et rad(8) pour l'IPv6, le firewall, etc.
Pour la TV : lire cet article. (https://undeadly.org/cgi?action=article;sid=20110222002946)
# cat /etc/pf.conf
# interface interne
tv_in_if = "vlan52"
# uplink TV... à définir dans /etc/hostname.vlan840 bien sûr
tv_if = "vlan840"
# NAT pour le boîtier TV qui a besoin d'accéder un peu à internet
match out log on egress inet from ($tv_in_if:network) to ! (self:network) nat-to (egress)
pass in quick log on $tv_in_if proto { tcp udp } to ! (self:network) port { ntp domain https http 1443 2443 3443 5443 6443 7443 8443 9443 }
# je suis pas trop sûr pour les ports non standards... j'ai un peu bâclé
# IGMP et flux TV
pass in quick log on $tv_in_if to 224.0.0.0/4 allow-opts
pass out quick log on $tv_if to 224.0.0.0/4 allow-opts
pass in quick log on $tv_if inet proto udp from any to 224.0.0.0/4 port { 8200 8202 }
pass quick log on { $in_phy_if $tv_if $tv_in_if } proto igmp allow-opts
# grep -vE '^[$#]' /etc/igmpproxy.conf
chroot /var/empty
user _igmpproxy
quickleave
phyint vlan840 upstream ratelimit 0
altnet 0.0.0.0/0
phyint vlan52 downstream ratelimit 0
phyint em1 disabled
phyint em2 disabled
Et bien sûr, le boîtier TV réclame une option DNS bizarre... certaines infos sont à récupérer dans /var/db/dhcpcd/vlan832.lease
# cat /etc/dhcpd.conf
[snip]
# TV
subnet 10.207.52.1 netmask 255.255.255.0 {
option routers 10.207.52.1;
# DNS fournis par Orange dans la lease DHCP 2023-03-01
option domain-name-servers 80.xx.xx.xx, 81.xx.xx.xx;
range 10.207.52.100 10.207.52.200;
host decodeur-tv {
hardware ethernet 44:d4:54:48:72:03;
# https://forums.framboise314.fr/viewtopic.php?f=57&t=5960
option option-125 00:00:0D:E9:24:04:06:xx:xx:xx:xx:xx:xx:05:0F:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:06:0d:4C:69:76:65:62:6F:78:20:34;
# ............^^.......^^^^^^^^^^^^^^^^^.......^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^....^^..L..i..v..e..b..o..x.. ..4
# `length `hex(first 3 bytes of Livebox MAC) `hex(serial Livebox) `length of next item
option domain-name "orange.fr";
option domain-search "XXX.access.orange-multimedia.net";
# ^^^- vérifier la lease DHCP, c'est dedans aussi
}
}
Et j'ai juste des problèmes avec l'accès aux chaînes HD+ (https://lafibre.info/remplacer-livebox/decodeur-uhd-fonctionnement-degrade-hd-seulement-livebox-remplacee-par-openbsd/msg1005482/#msg1005482), mais l'ensemble des chaînes reste fonctionnel (dont TF1, M6, replay, etc.)
Édit 2023-04-15 : dans les réponses DHCPv6 du serveur Orange, j'ai une option 17 ; et selon les indications de levieuxatorange (https://lafibre.info/remplacer-livebox/durcissement-du-controle-de-loption-9011-et-de-la-conformite-protocolaire/), ça indiquerait que je suis "migré" et donc mes propositions de configuration sont fonctionnelles.
Aussi, avec les sorties de dhcpcd-9.5.0 et 10.0.0 (11 avril 2023 et 13 avril 2023), et OpenBSD 7.3 (10 avril 2023), j'ai pu tester et valider que toute la conf fonctionnait encore (commit 257259dd (https://github.com/NetworkConfiguration/dhcpcd/tree/257259dd79d103f23342b1f0a3d608571a0ad549) sur OpenBSD 7.3).
2024-04-30 : je vous confirme que tout est encore parfaitement fonctionnel sur OpenBSD 7.4 et 7.5.
-
Orange ne délivre pas d'IPv6 pour le routeur. On gère cette situation bizarre avec un dhcpcd-run-hooks(8). (fe80::ba0:bab%vlan832 c'est le routeur Orange)
Cela n'a rien de bizarre c'est même une pratique recommandée.
La route par défaut vers fe80::ba0:bab peut s'obtenir en écoutant les ICMPv6/RA.
En IPv6, la logique est simple:
- fourniture d'un /56 via DHCPv6-PD
- fourniture d'une route par défaut via RA
p: j'ai ajouté ce sujet dans l'index général (https://lafibre.info/remplacer-livebox/index-des-solutions-de-remplacement-de-la-livebox/).
-
La manip avec dhclient.conf.head peut etre simplifier..
On peux utiliser sed(1) (https://man.openbsd.org/sed.1) pour replacer la chaine d'auth dans le fichier dhcpcd.conf sans utiliser une 2eme fichier donc:
fichier /etc/dhcpcd.conf
authtoken 0x456 "" forever 64:68:63:70:6c:69:76:65:62:6f:78:66:72:32:35:30
# TRES IMPORTANT NE PAS CHANGER OU SUPPRIMER LE COMMENTAIRE EN FIN DE LIGNE
# TRÈS IMPORTANT, FONCTIONNEL UNIQUEMENT AVEC dhcpcd > 4.9.1
authtoken 0x123 "" forever 00#CLEAUTH
# suite du fichier
commande pour remplacer la ligne ou il y a CLEAUTH par le résultat de orange_hexauth:
sed -i.bak -e 's/\(^.*forever\).*\#CLEAUTH/\1 '$(FTI_PASS="PASS" FTI_USER="fti/USER" /usr/local/bin/orange_hexauth.sh)' #CLEAUTH/' /etc/dhcpcd.conf
explication:
pour chaque ligne du fichier /etc/dhcpcd.conf qui contient '...forever...#CLEAUTH...', remplacer par '...forever X #CLEAUTH' ou X est le résultat (output) de la commande 'FTI_PASS="PASS" FTI_USER="fti/USER" sh orange_hexauth.sh'
l'ancienne version de /etc/dhcpcd.conf est sauvegarder dans /etc/dhcpcd.conf.bak
Il convient avant de modifier orange_hexauth pour qu'il n'affiche que le token => supprimer les 3 avant dernières lignes (cat EOM). On peut éventuellement les garder mais ca complique la commande car il faut filtrer stderr. Sinon fait comme dans ton cron par un fichier intermédiaire (orange_auth_string) mais je ne recommande pas trop d'utiliser trop de fichiers a usage intermédiaire (surtout pour des infos sensibles).
si on ne veut pas de 'data' dans les scripts (recommandé), on peut mettre FTI_PASS et FTI_USER directement dans /etc/dhcpcd.conf et utliser sed pour récupèrer leur valeurs:
/etc/dhcpcd.conf:
# parametres:
# FTI_PASS="pass&word!"
# FTI_USER="fti/user3615"
....
authtoken 0x456 "" forever 64:68:63:70:6c:69:76:65:62:6f:78:66:72:32:35:30
# TRES IMPORTANT NE PAS CHANGER OU SUPPRIMER LE COMMENTAIRE EN FIN DE LIGNE
# TRÈS IMPORTANT, FONCTIONNEL UNIQUEMENT AVEC dhcpcd > 4.9.1
authtoken 0x123 "" forever 00#CLEAUTH
# suite du fichier si besoin
....
script pour récupère les valeurs puis remplacer la chaine d'auth:
export FTI_PASS=$(sed -n -e 's/^# FTI_PASS="\(.*\)"/\1/p' /etc/dhcpcd.conf)
export FTI_USER=$(sed -n -e 's/^# FTI_USER="\(.*\)"/\1/p' /etc/dhcpcd.conf)
sed -i.bak -e 's/\(^.*forever\).*\#CLEAUTH/\1 '$(/usr/local/bin/orange_hexauth.sh)' #CLEAUTH/' /etc/dhcpcd.conf
L'intérêt est d'avoir la conf et tous ses paramètres/données dans un seul fichier (dhcpcd.conf) et les scripts ou le crontab n'ont aucune données.
-
La manip avec dhclient.conf.head peut etre simplifier..
Question de point de vue. cat a b > c c'est vraiment ultra simple.
Il convient avant de modifier orange_hexauth pour qu'il n'affiche que le token
Pas nécessaire, stderr est utilisé. 2>/dev/null si besoin.
L'intérêt est d'avoir la conf et tous ses paramètres/données dans un seul fichier (dhcpcd.conf) et les scripts ou le crontab n'ont aucune données.
Inversement, l'idée quand j'ai tout installé, c'était d'utiliser la même chaîne d'authentification dans dhclient.conf(5) et dhcpcd.conf(5). Entre deux, dhclient(8) a été remplacé par un truc plus simple (et inutile).
-
Question de point de vue. cat a b > c c'est vraiment ultra simple.
Ca le rend trop spécifique (on ne peut configurer une autre interface après dans le même ficher par exemple) et ce n'est pas une bonne pratique de coller des morceaux de fichiers comme cela (ce n'est pas que mon avis). Et devoir enlever une fin de ligne avec dd ce n'est pas simple comme façon de faire...
Si on veut un tuto adaptable a toute sorte d'usage et de cas il faut éviter ce genre de manips.
Inversement, l'idée quand j'ai tout installé, c'était d'utiliser la même chaîne d'authentification dans dhclient.conf(5) et dhcpcd.conf(5). Entre deux, dhclient(8) a été remplacé par un truc plus simple (et inutile).
A ce propos, le tuto est incohérent :
Pour effacer le retour à la ligne à la fin du fichier, on utilise :
dest=/etc/dhclient.conf.head
dd if=/dev/null of="$dest" obs="$(( $(wc -c < "$dest") -1 ))" seek=1
mais juste avant le fichier présenté est /etc/dhcpcd.conf.head
il ne devrait plus y avoir de dhclient.conf.head dans le tuto non ?
-
Nice !
Merci pour ce topic Moviuro, tu t'es vraiment donné du mal.
J'avoue avoir un peu laissé tombé de mon côté openbsd + orange, pour deux raisons. Déjà je suis en adsl, donc il me faut un modem en bridge. J'utilisais un cisco 2811, ce qui est un peu overkill (et qui consomme), et qui ne permettait que de bridger l'ipv4, et puis bon le fait que dhclient ne soit plus supporté me demandait pas mal de temps de reverse pour adapter ma config, temps que je n'ai pas forcément...
Vu qu'en plus l'adsl ne me sert qu'à monter des tunnels wireguard vers ailleurs, et qu'avant même le durcissement de la chaine d'auth j'avais réussi à me faire mettre en quarantaine (probablement une race condition entre le modem et le dhcp), j'ai remis la livebox et je supporte le nat de la livebox aujourd'hui, et je route mes ip publiques, ou bien je double nat en fonction des réseaux...
Merci en tout cas pour les autres ;)
-
Je n'ai pas réussi à avoir une IPv4 en suivant ton tuto. On dirait que les requêtes DHCPv4 étaient toujours en prio 3.
Pour l'IPv6 c'était correctement taggé en prio 6, mais je n'ai pas reçu de prefix.
Une coquille que j'ai relevé:
# 0003001<MAC_ADDRESS_LIVEBOX_SANS_DEUXPOINTS> dans /var/db/dhcpcd/duid
C'est 00030001<MAC_ADDRESS_LIVEBOX_SANS_DEUXPOINTS>
-
Je n'ai pas réussi à avoir une IPv4 en suivant ton tuto. On dirait que les requêtes DHCPv4 étaient toujours en prio 3.
C'est très étrange ça, mais je viens de vérifier et de mon côté aussi mes paquets sont prio 3 ! (oops)
# tcpdump -s 65535 -tttnei em1 vlan 832 and dst 255.255.255.255
Mar 29 19:00:33.145609 xx:xx:xx:xx:xx:xx ff:ff:ff:ff:ff:ff 8100 519: 802.1Q vid 832 pri 3 0.0.0.0.68 > 255.255.255.255.67: xid:0xfe686e8a secs:16 vend-rfc1048
Pour corriger : on passe vlan832 en prio 6 : ifconfig vlan832 llprio 6 et on peut faire sauter la règle de pare-feu.
J'imagine que l'absence d'IPv6 et de préfixe est liée à ton IPv4 cassé (genre : le serveur DHCP ne t'a pas authentifié, donc c'est mort).
J'ai corrigé la coquille, sorry (0 manquant dans duid).
cat /etc/hostname.vlan832
# llprio 6 is for DHCP messages that use bpf(4)
# see https://misc.openbsd.narkive.com/7SGmbxm0/allow-dhcpd-with-pf#post4
parent em1 vnetid 832 llprio 6
description "ISP link"
up
# cat /etc/pf.conf
# martians also includes IPv6 martians
table <martians> { ... }
...
# tous les paquets ont priorité 1 et TOS 0x00
# (la priorité 0 limitait l'upload à 3Mbps alors que prio 1 : 300Mbps+)
match out log on egress set prio 1 tos 0x00
# aucune règle qui ajoute la priorité 6 -- les paquets DHCP utilisent bpf(4) et bypassent les règles pf.conf(5)
...
pass in quick log inet6 from fe80::ba0:bab to (self)
...
# NAT interieur -> extérieur pour les invités
match out log on egress inet from ($guest_if:network) to ! (self:network) nat-to (egress)
pass in quick log on $guest_if to ! (self:network)
# Martians should never be a source on packets going out
block out quick log on egress from <martians>
pass out quick log
On vérifie que ça fonctionne comme ça devrait :
# tcpdump -s 65535 -tttnei em1 vlan 832 and dst 255.255.255.255
Mar 29 20:54:47.493290 xx:xx:xx:xx:xx:xx ff:ff:ff:ff:ff:ff 8100 519: 802.1Q vid 832 pri 6 0.0.0.0.68 > 255.255.255.255.67: xid:0xb86eec2b ...
-
Merci, je retente ça demain matin :)
En effet llprio semple être pile ce qu'il faut
-
Les paquets DHCP v4 et v6 sont bien tagués en prion6, mais j'ai jamais de réponses...
En IPv6 je vois les neighbors adv de ba0bab mais c'est tout. Je suis un peu perdu, j'ai même pas de parcage en 172.x, c'est le vide.
-
J'arrive pas à déchiffrer les requetes DHCPv4 avec tcpdump, mais en DHCPv6 je vois pas les options d'authentification:
11:15:39.133773 50:39:XX:XX:XX:XX 33:33:00:01:00:02 8100 255: 802.1Q vid 832 pri 6 fe80::5239:2fff:fe02:xxxx.546 > ff02::1:2.547: DHCPv6 Solicit xid d53fd
option 1 len 10 xxxxxxxxxxxx0019000c
option 25 len 12 000000000000000000060004
option 6 len 4 00080002
option 8 len 2 0000 [|dhcp6opt] [hlim 1] (len 197)
Mais c'est peut-être normal...
-
tcpdump(8) ne sait pas déchiffrer complètement les messages DHCP, j'utilise wireshark sur une autre machine pour ça.
# tcpdump -w "capture_$(date +%Y-%m-%dT%H:%m:%S).pcap" -s 65535 -tttnei em0 vlan 832
Ailleurs, rcctl restart dhcpcd
Je lis que ta MAC est 50:39:2f:xx:xx:xx... ça ne ressemble pas à une MAC de Livebox (https://macaddress.io/mac-address-lookup/K54zZ33GRo) à ma connaissance ?
-
J'ai édité pour anonymiser, mais oui c'est bien la bonne;
1.5 Adresse MAC 50:39:XX:XX:XX:XX
-
Du coup, je ne vois pas. Si tu as bien le même fichier dhcpcd.conf(5) que moi et dhcpcd master, il faudra que tu compares les captures de paquets de la Livebox avec celles de ton boîtier OpenBSD.
Je viens de refaire une capture :
Paquet Solicit XID > DHCPv6 > Authentication (dans wireshark)
0000 00 0b 00 46 00 00 00 e7 cf fd 5c 2f 52 0e 36 1a ...F......\/R.6.
0010 09 00 00 05 58 01 03 41 01 0d 66 74 69 2f xx xx ....X..A..fti/xx
0020 xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xxxxxxxxxxxxxxxx
0030 xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xxxxxxxxxxxxxxxx
0040 xx xx xx xx xx xx xx xx xx xx xxxxxxxxxx
Paquet DHCP Request > DHCP Request > Option: (90) Authentication
0000 5a 46 00 00 00 e7 cf fd 52 fc 32 03 ba 1a 09 00 ZF......R.2.....
0010 00 05 58 01 03 41 01 0d 66 74 69 2f xx xx xx xx ..X..A..fti/xxxx
0020 xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xxxxxxxxxxxxxxxx
0030 xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xxxxxxxxxxxxxxxx
0040 xx xx xx xx xx xx xx xx xxxxxxxx
-
Je ne vois pas l'option 61 pour le DHCPv4.
J'ai modifié la config avec clientid et j'ai bien l'option 61, avec comme valeur l'adresse mac.
J'ai changé les options pour n'inclure que celle mentionnée dans le fil "durcissement". Toujours rien, jamais de réponse.
Je vais essayer de capturer le traffic de la LB.
-
J'ai enlevé vendclass 1038 sagem et mis vendorclassid sagem.
J'ai copié la valeur de l'option 90 issue d'une capture de la livebox, toujours sans succès. La seule différence que je vois, c'est la valeur RDM: elle est toujours à zero dans le cas de la livebox.
-
C'est bon ça marche :) IPv4 + IPv6 ok!
J'avais mal recopié le token authentication. Je posterai ma config ce weekend. J'aurais dû faire un dump de la Livebox tout de suite, ça aurait été plus efficace :)
-
Ma config dhcpcd.conf qui marche IPv4 + IPv6 (à peu près...)
# dual-stack IPv4 et IPv6
noipv6rs
noipv4ll
nohook hostname ntp.conf
allowinterfaces vlan832
debug
interface vlan832
# 00030001<MAC_ADDRESS_LIVEBOX_SANS_DEUXPOINTS> dans /var/db/dhcpcd/duid
# iaid below = 4 derniers octets de la MAC de la livebox
iaid XXXXXXXX
clientid
# delegation de /64s à d'autres interfaces. rad(8) s'en occupera
# remplacer les XX par les 4 derniers octets de la MAC de la livebox (comme pour l'iad)
ia_pd XXXXXXXX aq1/2/64
option auth
authprotocol token 0x123/0x456
userclass FSVDSL_livebox.Internet.softathome.Livebox5
vendorclassid sagem
option 1 3 6 15 28 51 58 59 90 119 120 125
nooption 33 57
# Le token 0x456 ci-dessous est un magic string (dhcplivebox250) qu'Orange renvoie
authtoken 0x456 "" forever 64:68:63:70:6c:69:76:65:62:6f:78:66:72:32:35:30
authtoken 0x123 "" forever # < token d'authentification ici >
Après ~24h j'ai perdu le réseau, avec ça dans les logs:
dhcpcd[75339]: vlan832: no authentication from 80.10.XX.XX
Je ne sais pas si c'est parceque je ne fais pas de rotation de la clef? Je vais laisser tcpdump tourner pour voir si dhcpcd fait bien une demande de renouvellement, ou si c'est orange qui me rejete... Ce qui est bizarre c'est qu'un simple rcctl restart dhcpcd et tout rentre dans l'ordre.
Je suis sûr qu'il y a aussi moyen d'ajouter la route par défaut de manière automatique.
EDIT: J'ai ajouté comme option noauthrequired, on verra dans 24h...
-
On dirait que c'était la bonne option :)
Je me demande si c'est pas le même problème rencontré sur pf/opnsense.
Apr 3 19:35:09 obsd dhcpcd[71969]: vlan832: no authentication from 80.YY.YY.YY
Apr 3 19:35:09 obsd dhcpcd[71969]: vlan832: NAK: from 80.YY.YY.YY
Apr 3 19:35:09 obsd dhcpcd[71969]: vlan832: message:
Apr 3 19:35:09 obsd dhcpcd[71969]: vlan832: deleting route to 86.XX.XX.0/23
Apr 3 19:35:09 obsd dhcpcd[71969]: vlan832: deleting default route via 86.XX.XX.1
Apr 3 19:35:09 obsd dhcpcd[71969]: vlan832: soliciting a DHCP lease
Apr 3 19:35:10 obsd dhcpcd[71969]: vlan832: offered 86.XX.XX.XX from 80.YY.YY.YY
Apr 3 19:35:10 obsd dhcpcd[71969]: vlan832: probing address 86.XX.XX.XX/23
Apr 3 19:35:15 obsd dhcpcd[71969]: vlan832: leased 86.XX.XX.XX for 259200 seconds
Apr 3 19:35:15 obsd dhcpcd[71969]: vlan832: adding route to 86.XX.XX.0/23
Apr 3 19:35:15 obsd dhcpcd[71969]: vlan832: adding default route via 86.XX.XX.1
-
Hello,
La piste noauthrequired est intéressante. Existe-t-il une option similaire sur OPNsense ?
Merci !
-
je teste dès que je peux, vous avez réussi à avoir le prefix /56 ?
-
Hello,
La piste noauthrequired est intéressante. Existe-t-il une option similaire sur OPNsense ?
Merci !
Je ne sais pas trop, pour confirmer il faudrait les logs du client DHCP de opnsense.
je teste dès que je peux, vous avez réussi à avoir le prefix /56 ?
J'arrive à assigner plusieurs /64, je n'ai pas essayé d'assigner directement le /56 si c'est ce que tu veux faire ?
-
J'arrive à assigner plusieurs /64, je n'ai pas essayé d'assigner directement le /56 si c'est ce que tu veux faire ?
plus pour voir si ça marche pour l'instant, ce serait pour mettre un serveur dhcpd v6 ensuite pour creer les sous reseaux automatiquement
-
Bon mise a jour ce matin sans vraiment regarder le changelog et boum, plus de dhclient :(
Du coup j'essaye d'utiliser dhcpcd sans succès. Est-ce bien celui des packages ? car la version ne correspond pas a celle que vous mentionnez.
-
Non, il faut builder la version depuis la branche master du repo git: https://github.com/NetworkConfiguration/dhcpcd
Un simple
./configure
make
doas make install
a suffit pour moi (en 7.2).
Je tente l'upgrade en 7.3 ce weekend :)
J'aimerai quand même comprendre pourquoi je reçois un NAK au moment du renouvellement. Je suppose que la demande de renew de dhcpcd ne plait pas à orange ?
-
Du coup c'est pas le meme que celui qui est dans le tree packages d'openbsd ? il est en version 9.4.1... ou c'est un fork ?
De mon cote je ne veux pas d'ipv6 mais juste ipv4, je ne suis pas sense avoir besoin du patch vu qu'il est pour ipv6.
J'ai deja du mal a envoyer l'option 90... un coup ca passe, un coup non...
Non, il faut builder la version depuis la branche master du repo git: https://github.com/NetworkConfiguration/dhcpcd
Un simple
./configure
make
doas make install
a suffit pour moi (en 7.2).
Je tente l'upgrade en 7.3 ce weekend :)
J'aimerai quand même comprendre pourquoi je reçois un NAK au moment du renouvellement. Je suppose que la demande de renew de dhcpcd ne plait pas à orange ?
-
La 9.4.1 est trop ancienne, y a peut-être eu d'autres fix entre temps...
Je viens de voir que l'auteur a tout juste sorti une version stable 9.5.0, celle-ci devrait marcher: https://github.com/NetworkConfiguration/dhcpcd/releases
Par curiosité, pourquoi ne pas vouloir d'IPv6 ?
-
Je comprend pas pourquoi alors dans l'article on parle de 4.9.1...
Pourquoi pas d'ipv6 ? parce que pas besoin et que ya trop de zones d'ombres pour moi encore dessus. je ne maitrise pas assez :/
Par contre je sens bien que je vais me tapper le support des options pour dhcpleased au lieu d'utiliser un truc non natif !
La 9.4.1 est trop ancienne, y a peut-être eu d'autres fix entre temps...
Je viens de voir que l'auteur a tout juste sorti une version stable 9.5.0, celle-ci devrait marcher: https://github.com/NetworkConfiguration/dhcpcd/releases
Par curiosité, pourquoi ne pas vouloir d'IPv6 ?
-
C'est la version 4.9.1 qui est dans les ports. Elle n'est PAS compatible avec les options nécessaires pour se connecter au réseau orange (peut être en passant les options en "raw"?).
La toute dernière release devrait être compatible.
Pour IPv6 c'est dommage de pas s'en servir, ça marche très bien. Les devices par défaut auront des adresses temporaires (si c'est ça qui t'inquiète), et avec PF c'est simple de bloquer par défaut toutes les connexions entrantes.
-
dhcpcd-9.4.1p2v0.tgz pour le packages en 7.3
Je viens d'ugrade en master et rien n'y fait. Apres je suis sur une zone ou j'ai pas encore ce système de token a renew tout le temps.
J'ai une box pro donc peut être pas le meme mécanisme.
C'est la version 4.9.1 qui est dans les ports. Elle n'est PAS compatible avec les options nécessaires pour se connecter au réseau orange (peut être en passant les options en "raw"?).
La toute dernière release devrait être compatible.
Pour IPv6 c'est dommage de pas s'en servir, ça marche très bien. Les devices par défaut auront des adresses temporaires (si c'est ça qui t'inquiète), et avec PF c'est simple de bloquer par défaut toutes les connexions entrantes.
-
Je ne sais pas pour l'offre pro, en effet. Mais tu es sûr d'utiliser la version master maintenant ?
Pour le moment ça marche avec une string statique pour l'authentification, c'est ce que j'ai configuré. Le token d'authentification est configuré en dur dans ma config pour le moment.
À terme je pense que c'est faisable d'utiliser les hooks pour génerer la chaine à la volée.
-
Je ne sais pas pour l'offre pro, en effet. Mais tu es sûr d'utiliser la version master maintenant ?
Pour le moment ça marche avec une string statique pour l'authentification, c'est ce que j'ai configuré. Le token d'authentification est configuré en dur dans ma config pour le moment.
À terme je pense que c'est faisable d'utiliser les hooks pour génerer la chaine à la volée.
Bon en fait j'ai pu générer mes anciennes trames dhcp et elles sont différentes de celles de dhcpcd sur l'auth.
dhcpcd me construit une trame de 188 bytes avec un RDM truc muche alors que dhclient me faisait une trame de 77 bytes et rien dans RDM. bref, je vais matter le code voir comment ca genre tout ca...
-
Oui les RDM qui viennent de la livebox sont toujours à zero, alors que dhcpcd utilise un vrai nombre. Mais visiblement orange l'ignore pour le moment.
Je suppose que ta chaine est pas bonne: les génerateurs en ligne inclus le RDM, il faut l'enlever de la trame génerée.
Si t'as des dumps de ta LB, recopie juste la valeur du token d'authentification, c'est ce que j'ai fait :)
-
yep, version 9.99 qui vient de master.
Je ne sais pas pour l'offre pro, en effet. Mais tu es sûr d'utiliser la version master maintenant ?
Pour le moment ça marche avec une string statique pour l'authentification, c'est ce que j'ai configuré. Le token d'authentification est configuré en dur dans ma config pour le moment.
À terme je pense que c'est faisable d'utiliser les hooks pour génerer la chaine à la volée.
-
Le token d'authentification doit commencer par "1a:09". Tu peux virer ce qu'il y a avant si tu utilises un truc qui vient d'un génerateur.
-
Oui les RDM qui viennent de la livebox sont toujours à zero, alors que dhcpcd utilise un vrai nombre. Mais visiblement orange l'ignore pour le moment.
Je suppose que ta chaine est pas bonne: les génerateurs en ligne inclus le RDM, il faut l'enlever de la trame génerée.
Si t'as des dumps de ta LB, recopie juste la valeur du token d'authentification, c'est ce que j'ai fait :)
J'utilise tous les scripts qu'il y a sur ce post. Ma chaine commence par un 1a...
Que ce soit une générée ou celle que j'ai dans mon ancien dhclient, meme combat =)
-
Le token d'authentification doit commencer par "1a:09". Tu peux virer ce qu'il y a avant si tu utilises un truc qui vient d'un génerateur.
On dirait que dhcpcd encode mon token un coup de plus, en gros quand je décode avec Wireshark une ancienne trame, je vois bien fti/... mais quand je decode une actuelle, je vois que de l'hexadécimale, et ca fait quasiment le double en taille...
-
Met la en dur dans ta config, ça éliminera un potentiel problème.
T'as essayé de prendre ma config?
# dual-stack IPv4 et IPv6
noipv6rs
noipv4ll
nohook hostname ntp.conf
allowinterfaces vlan832
debug
# based on https://blog.brimbelle.org/index.php/2018/04/30/fibre-orange-ipv6-et-dhcpcd/
interface vlan832
# 00030001<MAC_ADDRESS_LIVEBOX_SANS_DEUXPOINTS> dans /var/db/dhcpcd/duid
# iaid below = 4 derniers octets de la MAC de la livebox
iaid XXXXXXXX
clientid
# delegation de /64s à d'autres interfaces. rad(8) s'en occupera
# les interfaces ci-dessous dépendent bien sûr de votre config... j'ai un VLAN pour les invités, les enfants, l'IoT...
ia_pd XXXXXXXX vether0/1/64
option auth
noauthrequired
authprotocol token 0x123/0x456
userclass FSVDSL_livebox.Internet.softathome.Livebox5
#vendclass 1038 sagem
vendorclassid sagem
option 1 3 6 15 28 51 58 59 90 119 120 125
nooption 33 57
# Le token 0x456 ci-dessous est un magic string (dhcplivebox250) qu'Orange renvoie
authtoken 0x456 "" forever 64:68:63:70:6c:69:76:65:62:6f:78:66:72:32:35:30
authtoken 0x123 "" forever # 1a:09:xx:xx:xx:xx...
-
yep, tout pareil !
J'ai teste authtoken 0x123 avec un # ou avec un espace comme dans l'autre config.
Avec le # il me dit que dhcp_auth_encode: Invalid argument
Met la en dur dans ta config, ça éliminera un potentiel problème.
T'as essayé de prendre ma config?
# dual-stack IPv4 et IPv6
noipv6rs
noipv4ll
nohook hostname ntp.conf
allowinterfaces vlan832
debug
# based on https://blog.brimbelle.org/index.php/2018/04/30/fibre-orange-ipv6-et-dhcpcd/
interface vlan832
# 00030001<MAC_ADDRESS_LIVEBOX_SANS_DEUXPOINTS> dans /var/db/dhcpcd/duid
# iaid below = 4 derniers octets de la MAC de la livebox
iaid XXXXXXXX
clientid
# delegation de /64s à d'autres interfaces. rad(8) s'en occupera
# les interfaces ci-dessous dépendent bien sûr de votre config... j'ai un VLAN pour les invités, les enfants, l'IoT...
ia_pd XXXXXXXX vether0/1/64
option auth
noauthrequired
authprotocol token 0x123/0x456
userclass FSVDSL_livebox.Internet.softathome.Livebox5
#vendclass 1038 sagem
vendorclassid sagem
option 1 3 6 15 28 51 58 59 90 119 120 125
nooption 33 57
# Le token 0x456 ci-dessous est un magic string (dhcplivebox250) qu'Orange renvoie
authtoken 0x456 "" forever 64:68:63:70:6c:69:76:65:62:6f:78:66:72:32:35:30
authtoken 0x123 "" forever # 1a:09:xx:xx:xx:xx...
-
Ah oui, faut pas le #, c'est juste pour faire un commentaire.
Le serveur dhcp d'orange ne répond pas du tout ?
-
Nope, rien du tout, mais d'un autre cote la chaine d'auth est double encodee... donc bon...
Ah oui, faut pas le #, c'est juste pour faire un commentaire.
Le serveur dhcp d'orange ne répond pas du tout ?
-
Tu l'as bien mise en hexa, avec les ':', sans guillemets, etc?
-
noipv6rs
noipv4ll
noipv6
allowinterfaces vlan832
nohook hostname ntp.conf
debug
interface vlan832
iaid DD8XXXX
ia_pd DD8AXXXX vlan832/1/64
clientid
option auth
noauthrequired
authprotocol token 0x123/0x456
userclass FSVDSL_livebox.Internet.softathome.Livebox4
vendorclassid sagem
option 1 3 6 15 28 51 58 59 90 119 120 125
nooption 33 57
authtoken 0x456 "" forever 64:68:63:70:6c:69:76:65:62:6f:78:66:72:32:35:30
authtoken 0x123 "" forever 1a:09:00:00:05:00:01:03:00:01:0d:66:74:69:2f:00:00:........:e2:a4:f2:06:7f:31:d5
Tu l'as bien mise en hexa, avec les ':', sans guillemets, etc?
-
Cette ligne
ia_pd DD8AXXXX vlan832/1/64
Ne va pas marcher (mais c'est pas ça qui te bloque actuellement je pense).
On dirait que tu as deux espaces entre forever et 1a:..., t'as essayé avec un seul? Sinon j'avoue que je vois pas trop du coup...
-
si j'enlève cet espace, j'ai un dhcp_auth_encode qui me met invalid argument :(
Cette ligne
ia_pd DD8AXXXX vlan832/1/64
Ne va pas marcher (mais c'est pas ça qui te bloque actuellement je pense).
On dirait que tu as deux espaces entre forever et 1a:..., t'as essayé avec un seul? Sinon j'avoue que je vois pas trop du coup...
-
Du coup je pense que ton token doit pas être valide... J'ai pas essayé les scripts de ce thread, j'ai utilisé la valeur que j'ai capturé venant de ma livebox :( T'as essayé https://jsfiddle.net/kgersen/3mnsc6wy/ ? (en enlevant les 00 avant 1a)
EDIT: ton token devrait commencer par "1a:09:00:00:05:58:01:03:41:01:0d", ça a pas l'air d'être le cas ici.
-
Bon ca marche !!!!
Merci pour ton aide !
en fait je testai des fois avec rcctl et des fois en lançant direct le daemon que j'avais compile. Je l'avais installé dans /sbin mais il y avait un reliquat de dhcpcd dans /usr/local/sbin :(
Je comprend pas pourquoi rcctl le prenait la...
Je comfirme que le dhcp_auth_encode: invalid Argument vient bien de la version. en 9.4.1 ca ne passe pas, avec la version master c'est bon.
si j'enlève cet espace, j'ai un dhcp_auth_encode qui me met invalid argument :(
-
Par contre le passage en 7.1 -> 7.3 je perds pas mal en vitesse :/ j'étais a ~1200Mbits en download avant, je plafonne a 600 la...
-
Je l'avais modifie lors du copie/colle pour l'anonymiser
Du coup je pense que ton token doit pas être valide... J'ai pas essayé les scripts de ce thread, j'ai utilisé la valeur que j'ai capturé venant de ma livebox :( T'as essayé https://jsfiddle.net/kgersen/3mnsc6wy/ ? (en enlevant les 00 avant 1a)
EDIT: ton token devrait commencer par "1a:09:00:00:05:58:01:03:41:01:0d", ça a pas l'air d'être le cas ici.
-
Bon au moins ça marche :)
La perte de vitesse me parait bizarre... mais ça serait pas la première fois que je vois ça, j'avais déjà vu des regressions comme ça dans le passée. Et si t'as le malheur de t'en plaindre sur la dl, tu vas t'en prendre plein la figure :( (fallait tester avant ! Pourquoi tu as pas utiliser current avant !, etc)
T'as quoi comme config (CPU, chipset réseau, etc) ? T'as bien mis match out log on egress set prio 1 tos 0x00 dans pf.conf? Sans ça j'avais vraiment pas un bon débit.
-
hmm j'ai change avec vlan1000 mais ca n'a pas l'air de fonctionner, je vais regarder un peu plus pour ipv6
Cette ligne
ia_pd DD8AXXXX vlan832/1/64
Ne va pas marcher (mais c'est pas ça qui te bloque actuellement je pense).
On dirait que tu as deux espaces entre forever et 1a:..., t'as essayé avec un seul? Sinon j'avoue que je vois pas trop du coup...
-
Pour l'IPv6 faut vraiment les régles de prio mises dans pf.conf, sans ça ça marchait pas pour moi.
-
Yep !
J'ai une machiatobin single shot, 4 core ARM a 1,6Ghz et 8Gig de ram.
600 Mbits c'est pas bien grave =) ca suffit pour ce que je dois en faire...
Bon au moins ça marche :)
La perte de vitesse me parait bizarre... mais ça serait pas la première fois que je vois ça, j'avais déjà vu des regressions comme ça dans le passée. Et si t'as le malheur de t'en plaindre sur la dl, tu vas t'en prendre plein la figure :( (fallait tester avant ! Pourquoi tu as pas utiliser current avant !, etc)
T'as quoi comme config (CPU, chipset réseau, etc) ? T'as bien mis match out log on egress set prio 1 tos 0x00 dans pf.conf? Sans ça j'avais vraiment pas un bon débit.
-
Je pense qu'il faut quand même le faire remonter, au cas où... j'ai vu pleins de fix smp pour pf, j'esperais ne pas perdre en perf en upgradant... on verra ce weekend :)
Avec un Atom C3558 sous 7.2, j'ai l'impression de plafonner à ~1.5G en téléchargement.
-
C'est deja pas mal ! Faut pas oublier que openbsd a encore un giantlock et que les perfs seront toujours inférieures...
Je pense qu'il faut quand même le faire remonter, au cas où... j'ai vu pleins de fix smp pour pf, j'esperais ne pas perdre en perf en upgradant... on verra ce weekend :)
Avec un Atom C3558 sous 7.2, j'ai l'impression de plafonner à ~1.5G en téléchargement.
-
Certes, mais il me semble que l'objectif est d'éliminer petit à petit ce giantlock, les perfs devraient augmenter au fil des releases (sans tenir compte des patchs de sécurité, qui doivent ralentir le tout...)
-
vous avez la config pour mettre la livebox derrière pour garder le tel (ou même la tv éventuellement)
-
Il faut donner à la LB :
- les DNS Orange domain-name-servers
- l'option 15 domain-name
- l'option 119 domain-search
- l'option 90 rfc3118-authentication
- l'option 125 vendor-specific-infos
Toutes les valeurs sont dans le bail reçu sur l'interface wan 832. Il faut les reprendre pour le serveur DHCP qui va répondre à la LB cliente (sur un vlan 832 également).
Pour la TV, il faudra configurer le vlan 840 sur l'interface wan et un igmp proxy sur le routeur (et non plus sur la LB). Le décodeur se branchera sur le routeur et non la LB.
-
C'est deja pas mal ! Faut pas oublier que openbsd a encore un giantlock et que les perfs seront toujours inférieures...
Le réseau n'est plus couvert par un giantlock depuis un bon moment.
Actuellement l'écueil principal est, d'une manière générale, le nombre de queues mises à disposition ou exploitables au travers de tel ou tel driver.
Quant aux performances inférieures, un peu de prudence suivant le cas d'utilisation et lorsque c'est testé par des professionnels. Voici un exemple ou fatalement avec OpenBSD on ne traverse qu'une queue via le controlleur intel i211. L'objectif de l'article est de montrer ce qu'une petite machine peut réaliser dès qu'on "vectorise" mais pour référence les perfs des piles Linux et OpenBSD sont aussi visibles avec des versions d'il y a 2 ans et demi.
https://ipng.ch/s/articles/2021/07/19/pcengines-apu6.html
Au travers de i210 puis i211
imix: Linux 150 Kpps - OpenBSD 145 Kpps
64B: Linux 97 Kpps - OpenBSD 152 Kpps
-
Dans une autre vie j'étais connecté en gigabit en câble, via un APU2. Je plafonnais à 600 Mbit/s. Après une upgrade (sans changer les règle PF) j'étais à 300.
J'avais pas des règles folles non plus, just du nat en gros... Opennsd est peut-être plus performant à gérer des milliers et plus de connections que Linux ? Possible. Est-ce applicable à notre scénario ? Je ne pense pas.
Du coup j'étais reparti sur debian + nftables et j'avais bien mon gigabit.
J'ai toujours plusieurs APU, quand/si j'ai le temps j'aimerais bien faire des tests de régression.
-
En 7.2 il y a encore des parties du réseau qui sont sous big lock, donc bon, a voir. Je vais aller jeter un coup d'oeil aux commits de mon driver mvpp.
Je dois faire encore pas mal de tests pour valider que les perfs sont moins bonnes...
Dans une autre vie j'étais connecté en gigabit en câble, via un APU2. Je plafonnais à 600 Mbit/s. Après une upgrade (sans changer les règle PF) j'étais à 300.
J'avais pas des règles folles non plus, just du nat en gros... Opennsd est peut-être plus performant à gérer des milliers et plus de connections que Linux ? Possible. Est-ce applicable à notre scénario ? Je ne pense pas.
Du coup j'étais reparti sur debian + nftables et j'avais bien mon gigabit.
J'ai toujours plusieurs APU, quand/si j'ai le temps j'aimerais bien faire des tests de régression.
-
En 7.2 il y a encore des parties du réseau qui sont sous big lock, donc bon, a voir. Je vais aller jeter un coup d'oeil aux commits de mon driver mvpp.
Je dois faire encore pas mal de tests pour valider que les perfs sont moins bonnes...
splnet a sauté du kernel_lock en 6.6. Ca fait des années qu'il y a un netlock et un pflock sous OBSD. Des morceaux d'arp ne sont pas encore traités mais ce n'est pas un problème pour votre forwarding.
Par contre mon petit doigt me dit que mvpp est mono queue et que pour 1G ca peut aller, 2.5G je ne sais pas mais pour 10G OpenBSD n'est pas encore la bonne solution. Linux sera bien plus approprié si toutefois le code a été maintenu pour suivre les éventuelles modifications du noyau l'impactant.
Quoi qu'il en soit bon courage à vous deux et à plus.
-
C'était bien sûr une faute de frappe : dhcpcd 9.4.1 = 💩 ; dhcpcd 9.5.0 et plus = 👍️. La release d'OpenBSD 7.3 a eu lieu juste avant la publication de dhcpcd 9.5.0 (et 10.0), donc le paquet/port dhcpcd sur OpenBSD 7.3 n'est toujours pas fonctionnel pour ce qu'on veut en faire !
Par ailleurs, j'ai épluché mes captures réseau, et surprise, j'ai migré selon levieuxatorange. J'ai en effet une option 17 dans la réponse DHCPv6 de fe80::ba0:bab.
0000 00 11 00 12 00 00 05 58 00 01 00 0c 00 01 00 00 .......X........ option 17 longueur 18 enterprise ID Orange (1368) option 1 longueur 12 00 01 00 00
0010 00 00 00 00 00 00 ...... 00 00 00 00 00 00
Du coup, les conseils dans le post original sont visiblement fonctionnels (yay !).
Pour les performances je n'ai malheureusement qu'une offre 1Gbps/300Mbps, et speed.cloudflare.com (http://speed.cloudflare.com) me donne un p90 à 890Mbps/300Mbps. Notez bien que pour l'upload, le match out log on egress set prio 1 est crucial.
-
Je pense avoir trouvé la raison des NAK: les renew dhcp ne sont pas envoyé en COS6. J'ai ajouté comme règle dans mon pf.conf:
# Set prio 6 on DHCP
match out log on vlan832 inet proto udp from any to any port bootps set prio 6
Depuis, plus de NAK dans les logs.
@moviuro je pense que ça serait bien d'ajouter cette ligne dans la première page, ainsi que le noauthrequired dans la config de dhcpcd, pour pas se retrouver sans connection si jamais le serveur dhcp d'orange refusait un renew.
-
C'était bien sûr une faute de frappe : dhcpcd 9.4.1 = 💩 ; dhcpcd 9.5.0 et plus = 👍️. La release d'OpenBSD 7.3 a eu lieu juste avant la publication de dhcpcd 9.5.0 (et 10.0), donc le paquet/port dhcpcd sur OpenBSD 7.3 n'est toujours pas fonctionnel pour ce qu'on veut en faire !
Par ailleurs, j'ai épluché mes captures réseau, et surprise, j'ai migré selon levieuxatorange. J'ai en effet une option 17 dans la réponse DHCPv6 de fe80::ba0:bab.
0000 00 11 00 12 00 00 05 58 00 01 00 0c 00 01 00 00 .......X........ option 17 longueur 18 enterprise ID Orange (1368) option 1 longueur 12 00 01 00 00
0010 00 00 00 00 00 00 ...... 00 00 00 00 00 00
Du coup, les conseils dans le post original sont visiblement fonctionnels (yay !).
Pour les performances je n'ai malheureusement qu'une offre 1Gbps/300Mbps, et speed.cloudflare.com (http://speed.cloudflare.com) me donne un p90 à 890Mbps/300Mbps. Notez bien que pour l'upload, le match out log on egress set prio 1 est crucial.
Il semblerait que depuis quelques jours dhcpcd version 10.0.1 soit disponible :
https://cdn.openbsd.org/pub/OpenBSD/7.3/packages-stable/amd64/dhcpcd-10.0.1pl20230518v0.tgz
Je n'ai pas testé si cela fonctionne avec ce package la, je fonctionne encore avec isc_dhclient pour ipv4&6.