Freebox Server (Ultra V9/ Pop V8/ Delta V7 / Revolution V6 / Mini 4K)

Afin de résoudre certains problèmes de bridge, je redemande la mise à jour de bridge-utils 1.5 → 1.6 (2016-10-17)
→ https://mirrors.edge.kernel.org/pub/linux/utils/net/bridge-utils/

Par ailleurs, pourriez-vous corriger le nom sur le site FLOSS et dans Freebox OS : bridgeutils → bridge-utils

Déjà signalé dans https://dev.freebox.fr/bugs/task/22518 (avec d’autres demandes de maj + corrections de noms de softs/libs)

Bonjour,

J’essai de faire un lien OpenVPN Bridgé entre deux Freebox (Mini 4K en ADSL et One en FTTH AMI Orange).
Serveur créé sur la One, client sur la mini 4K.

Déja j’ai du effacer la ligne dev-type tap du fichier sinon impossible de l’importer sur Freebox OS.

Ensuite j’ai une erreur interne, avec bad local ip, comme si le client n’arrive pas à obtenir une adresse IP.

Merci pour votre aide, ci joint le log

//d.pr/i/3g5Ukf

2019-05-02 14:14:42 starting
2019-05-02 14:14:42 calling helper script at '/etc/fbxconnman/conn.pre-up'
2019-05-02 14:14:42 l3 state change 'l3_start' => 'l3_wait_preup_helper'
2019-05-02 14:14:42 l3 state change 'l3_wait_preup_helper' => 'l3_wait_stable'
2019-05-02 14:14:42 openvpn: output: Thu May  2 14:14:42 2019 OpenVPN 2.3.17 arm-unknown-linux-muslgnueabi [SSL (OpenSSL)] [LZO] [EPOLL] [MH] [IPv6] built on Apr 26 2019
2019-05-02 14:14:42 openvpn: output: Thu May  2 14:14:42 2019 library versions: OpenSSL 1.0.2q  20 Nov 2018, LZO 2.09
2019-05-02 14:14:42 openvpn: connected to management interface
2019-05-02 14:14:42 openvpn: output: Thu May  2 14:14:42 2019 MANAGEMENT: Connected to management server at unix_mgt.sock
2019-05-02 14:14:42 openvpn: rx: >INFO:OpenVPN Management Interface Version 1 -- type 'help' for more info
2019-05-02 14:14:42 openvpn: rx: >HOLD:Waiting for hold release
2019-05-02 14:14:42 openvpn: tx: hold release
2019-05-02 14:14:42 openvpn: output: Thu May  2 14:14:42 2019 MANAGEMENT: CMD 'hold release'
2019-05-02 14:14:42 openvpn: rx: SUCCESS: hold release succeeded
2019-05-02 14:14:42 openvpn: output: Thu May  2 14:14:42 2019 MANAGEMENT: CMD 'state on'
2019-05-02 14:14:42 openvpn: rx: SUCCESS: real-time state notification set to ON
2019-05-02 14:14:42 openvpn: rx: >PASSWORD:Need 'Auth' username/password
2019-05-02 14:14:42 openvpn: tx: username "Auth" "FBX78340"
2019-05-02 14:14:42 openvpn: output: Thu May  2 14:14:42 2019 MANAGEMENT: CMD 'username "Auth" "FBX78340"'
2019-05-02 14:14:42 openvpn: rx: SUCCESS: 'Auth' username entered, but not yet verified
2019-05-02 14:14:42 openvpn: output: Thu May  2 14:14:42 2019 MANAGEMENT: CMD 'password [...]'
2019-05-02 14:14:42 openvpn: rx: SUCCESS: 'Auth' password entered, but not yet verified
2019-05-02 14:14:42 openvpn: output: Thu May  2 14:14:42 2019 MANAGEMENT: >STATE:1556799282,WILL_CONNECT,91.166.145.220,,,,,0
2019-05-02 14:14:42 openvpn: output: Thu May  2 14:14:42 2019 Socket Buffers: R=[163840->163840] S=[163840->163840]
2019-05-02 14:14:42 openvpn: output: Thu May  2 14:14:42 2019 UDPv4 link local: [undef]
2019-05-02 14:14:42 openvpn: output: Thu May  2 14:14:42 2019 UDPv4 link remote: [AF_INET]91.166.145.220:40992
2019-05-02 14:14:42 openvpn: output: Thu May  2 14:14:42 2019 MANAGEMENT: >STATE:1556799282,WAIT,,,,,,0
2019-05-02 14:14:42 openvpn: rx: >STATE:1556799282,WILL_CONNECT,91.166.145.220,,,,,0
2019-05-02 14:14:42 openvpn: rx: >STATE:1556799282,WAIT,,,,,,0
2019-05-02 14:14:42 openvpn: output: Thu May  2 14:14:42 2019 MANAGEMENT: >STATE:1556799282,AUTH,,,,,,0
2019-05-02 14:14:42 openvpn: output: Thu May  2 14:14:42 2019 TLS: Initial packet from [AF_INET]91.166.145.220:40992, sid=38ca0eec 073b41c0
2019-05-02 14:14:42 openvpn: rx: >STATE:1556799282,AUTH,,,,,,0
2019-05-02 14:14:42 openvpn: output: Thu May  2 14:14:42 2019 VERIFY OK: depth=1, C=FR, O=Freebox SA, CN=Freebox OpenVPN server CA for 5e7ece4c6892237fe51085bd58810180
2019-05-02 14:14:42 openvpn: output: Thu May  2 14:14:42 2019 Validating certificate key usage
2019-05-02 14:14:42 openvpn: output: Thu May  2 14:14:42 2019 ++ Certificate has key usage  00a0, expects 00a0
2019-05-02 14:14:42 openvpn: output: Thu May  2 14:14:42 2019 VERIFY KU OK
2019-05-02 14:14:42 openvpn: output: Thu May  2 14:14:42 2019 Validating certificate extended key usage
2019-05-02 14:14:42 openvpn: output: Thu May  2 14:14:42 2019 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
2019-05-02 14:14:42 openvpn: output: Thu May  2 14:14:42 2019 VERIFY EKU OK
2019-05-02 14:14:42 openvpn: output: Thu May  2 14:14:42 2019 VERIFY X509NAME OK: C=FR, O=Freebox SA, CN=Freebox OpenVPN server 5e7ece4c6892237fe51085bd58810180
2019-05-02 14:14:42 openvpn: output: Thu May  2 14:14:42 2019 VERIFY OK: depth=0, C=FR, O=Freebox SA, CN=Freebox OpenVPN server 5e7ece4c6892237fe51085bd58810180
2019-05-02 14:14:43 openvpn: output: Thu May  2 14:14:43 2019 WARNING: 'dev-type' is used inconsistently, local='dev-type tun', remote='dev-type tap'
2019-05-02 14:14:43 openvpn: output: Thu May  2 14:14:43 2019 WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1561', remote='link-mtu 1593'
2019-05-02 14:14:43 openvpn: output: Thu May  2 14:14:43 2019 WARNING: 'tun-mtu' is used inconsistently, local='tun-mtu 1500', remote='tun-mtu 1532'
2019-05-02 14:14:43 openvpn: output: Thu May  2 14:14:43 2019 Data Channel Encrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
2019-05-02 14:14:43 openvpn: output: Thu May  2 14:14:43 2019 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
2019-05-02 14:14:43 openvpn: output: Thu May  2 14:14:43 2019 Data Channel Decrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
2019-05-02 14:14:43 openvpn: output: Thu May  2 14:14:43 2019 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
2019-05-02 14:14:43 openvpn: output: Thu May  2 14:14:43 2019 Control Channel: TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES256-GCM-SHA384, 2048 bit RSA
2019-05-02 14:14:43 openvpn: output: Thu May  2 14:14:43 2019 [Freebox OpenVPN server 5e7ece4c6892237fe51085bd58810180] Peer Connection Initiated with [AF_INET]91.166.145.220:40992
2019-05-02 14:14:44 openvpn: rx: >STATE:1556799284,GET_CONFIG,,,,,,0
2019-05-02 14:14:44 openvpn: output: Thu May  2 14:14:44 2019 MANAGEMENT: >STATE:1556799284,GET_CONFIG,,,,,,0
2019-05-02 14:14:45 openvpn: output: Thu May  2 14:14:45 2019 SENT CONTROL [Freebox OpenVPN server 5e7ece4c6892237fe51085bd58810180]: 'PUSH_REQUEST' (status=1)
2019-05-02 14:14:46 openvpn: output: Thu May  2 14:14:46 2019 PUSH: Received control message: 'PUSH_REPLY,ping 30,ping-restart 120'
2019-05-02 14:14:46 openvpn: output: Thu May  2 14:14:46 2019 OPTIONS IMPORT: timers and/or timeouts modified
2019-05-02 14:14:46 openvpn: output: Thu May  2 14:14:46 2019 Initialization Sequence Completed
2019-05-02 14:14:46 openvpn: output: Thu May  2 14:14:46 2019 MANAGEMENT: >STATE:1556799286,CONNECTED,SUCCESS,,91.166.145.220,,,1500
2019-05-02 14:14:46 openvpn: rx: >STATE:1556799286,CONNECTED,SUCCESS,,91.166.145.220,,,1500
2019-05-02 14:14:46 openvpn: bad local ip
2019-05-02 14:14:46 l3 is now stable
2019-05-02 14:14:46 l3 does not fulfil config requirement
2019-05-02 14:14:46 l3 state change 'l3_wait_stable' => 'l3_bring_down'
2019-05-02 14:14:46 waiting for l3 providers to go down
2019-05-02 14:14:46 l3 state change 'l3_bring_down' => 'l3_wait_down'
2019-05-02 14:14:46 l3 state change 'l3_wait_down' => 'l3_cleanup_start'
2019-05-02 14:14:46 calling helper script at '/etc/fbxconnman/conn.post-down'
2019-05-02 14:14:46 l3 state change 'l3_cleanup_start' => 'l3_wait_postdown_helper'
2019-05-02 14:14:46 l3 state change 'l3_wait_postdown_helper' => 'l3_cleanup_finish'
2019-05-02 14:14:46 l3 state change 'l3_cleanup_finish' => 'l3_finished'
2019-05-02 14:14:46 state change 'wait_l3_up' => 'wait_l3_down'
2019-05-02 14:14:46 l3 state change 'l3_finished' => 'l3_down'
2019-05-02 14:14:46 state is now DOWN
2019-05-02 14:14:46 state change 'wait_l3_down' => 'l3_finished'
2019-05-02 14:14:46 state change 'l3_finished' => 'wait_l2_down'
2019-05-02 14:14:46 l2 state change 'l2_up' => 'l2_cleanup'
2019-05-02 14:14:46 l2 state change 'l2_cleanup' => 'l2_down'
2019-05-02 14:14:46 state change 'wait_l2_down' => 'down'

Afin de résoudre certains problèmes d’adressage/routage etc. (IPv4/IPv6), de bridge et bien plus, je redemande la mise à jour de iproute2, actuellement, dans Freebox OS 4.7.6 : 5.14.0 (2021-08-31).

→ https://mirrors.edge.kernel.org/pub/linux/utils/net/iproute2/

→ https://git.kernel.org/pub/scm/network/iproute2/iproute2.git

Note importante : bridge-utils a été intégré dans iproute2.

Les Freebox ont seulement la 1.5 de 2011 mais il existe une version 1.7.1 (2021-03-22) :
→ https://mirrors.edge.kernel.org/pub/linux/utils/net/bridge-utils/

Je pense qu’il est temps de supprimer bridge-utils 1.5 (pas à jour) des Freebox Server.

Les fonctions ont été intégrées dans iproute2.

Merci d’avance.

Bonjour,

Je tente de raccorder deux freebox server (une Révolution et un Mini, j’utiliserai ces noms pour distinguer le server et le client OpenVPN) dans l’optique de fusionner les deux LAN sur le même subnet (192.168.0.*) en utilisant OpenVPN en mode Bridge.

Je configure donc le Mini en tant que server, créé un utilisateur spécifique pour cette connexion et charge le fichier de configuration généré par le Mini dans le client VPN de la Révolution. Première erreur : il faut commenter la ligne dev-type tap qui empêche au client de la Révolution de charger le fichier le configuration (et aussi tls-remote qui n’est plus nécessaire et génère un warning dans les logs).

Une fois le fichier de configuration corrigé et chargé, toute tentative de connection retourne une erreur Bad local IP dont ne je n’ai pu trouver aucune référence sur le net (autre qu’une erreur de pppd). Le log indique aussi que le client tente la requête avec dev-type tun (puisque je l’ai commenté dans le fichier de config).

Log complet :

2015-08-13 14:26:18 l2 state change ‘l2_down’ ⇒ ‘l2_down’
2015-08-13 14:26:18 l3 state change ‘l3_down’ ⇒ ‘l3_down’
2015-08-13 14:26:18 state change ‘down’ ⇒ ‘down’
2015-08-13 14:26:18 enabling connection
2015-08-13 14:26:18 state change ‘down’ ⇒ ‘wait_l2_up’
2015-08-13 14:26:18 l2 state change ‘l2_down’ ⇒ ‘l2_up’
2015-08-13 14:26:18 state change ‘wait_l2_up’ ⇒ ‘l2_up’
2015-08-13 14:26:18 state change ‘l2_up’ ⇒ ‘wait_l3_up’
2015-08-13 14:26:18 l3 state change ‘l3_down’ ⇒ ‘l3_start’
2015-08-13 14:26:18 starting
2015-08-13 14:26:18 calling helper script at ‘/etc/fbxconnman/conn.pre-up’
2015-08-13 14:26:18 l3 state change ‘l3_start’ ⇒ ‘l3_wait_preup_helper’
2015-08-13 14:26:18 l3 state change ‘l3_wait_preup_helper’ ⇒ ‘l3_wait_stable’
2015-08-13 14:26:18 openvpn: output: Thu Aug 13 14:26:18 2015 OpenVPN 2.3.2 arm-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [MH] [IPv6] built on Jul 24 2015
2015-08-13 14:26:18 openvpn: connected to management interface
2015-08-13 14:26:18 openvpn: output: Thu Aug 13 14:26:18 2015 MANAGEMENT: Connected to management server at unix_mgt.sock
2015-08-13 14:26:18 openvpn: rx: >INFO:OpenVPN Management Interface Version 1 – type ‘help’ for more info
2015-08-13 14:26:18 openvpn: rx: >HOLD:Waiting for hold release
2015-08-13 14:26:18 openvpn: tx: hold release
2015-08-13 14:26:18 openvpn: output: Thu Aug 13 14:26:18 2015 MANAGEMENT: CMD ‘hold release’
2015-08-13 14:26:18 openvpn: rx: SUCCESS: hold release succeeded
2015-08-13 14:26:18 openvpn: output: Thu Aug 13 14:26:18 2015 MANAGEMENT: CMD ‘state on’
2015-08-13 14:26:18 openvpn: rx: SUCCESS: real-time state notification set to ON
2015-08-13 14:26:18 openvpn: rx: >PASSWORD:Need ‘Auth’ username/password
2015-08-13 14:26:18 openvpn: tx: username “Auth” “[user]”
2015-08-13 14:26:18 openvpn: output: Thu Aug 13 14:26:18 2015 MANAGEMENT: CMD ‘username “Auth” “[user]”’
2015-08-13 14:26:18 openvpn: rx: SUCCESS: ‘Auth’ username entered, but not yet verified
2015-08-13 14:26:18 openvpn: output: Thu Aug 13 14:26:18 2015 MANAGEMENT: CMD ‘password [...]’
2015-08-13 14:26:18 openvpn: rx: SUCCESS: ‘Auth’ password entered, but not yet verified
2015-08-13 14:26:18 openvpn: output: Thu Aug 13 14:26:18 2015 MANAGEMENT: >STATE:1439468778,WILL_CONNECT,[IP],,,,,0
2015-08-13 14:26:18 openvpn: output: Thu Aug 13 14:26:18 2015 Socket Buffers: R=[172032→131072] S=[172032→131072]
2015-08-13 14:26:18 openvpn: output: Thu Aug 13 14:26:18 2015 UDPv4 link local: [undef]
2015-08-13 14:26:18 openvpn: output: Thu Aug 13 14:26:18 2015 UDPv4 link remote: [AF_INET][IP]:[PORT]
2015-08-13 14:26:18 openvpn: output: Thu Aug 13 14:26:18 2015 MANAGEMENT: >STATE:1439468778,WAIT,,,,,,0
2015-08-13 14:26:18 openvpn: rx: >STATE:1439468778,WILL_CONNECT,[IP],,,,,0
2015-08-13 14:26:18 openvpn: rx: >STATE:1439468778,WAIT,,,,,,0
2015-08-13 14:26:18 openvpn: output: Thu Aug 13 14:26:18 2015 MANAGEMENT: >STATE:1439468778,AUTH,,,,,,0
2015-08-13 14:26:18 openvpn: output: Thu Aug 13 14:26:18 2015 TLS: Initial packet from [AF_INET][IP]:[PORT], sid=7f32f5b5 869df738
2015-08-13 14:26:18 openvpn: rx: >STATE:1439468778,AUTH,,,,,,0
2015-08-13 14:26:18 openvpn: output: Thu Aug 13 14:26:18 2015 VERIFY OK: depth=1, C=FR, O=Freebox SA, CN=Freebox OpenVPN server CA for […]
2015-08-13 14:26:18 openvpn: output: Thu Aug 13 14:26:18 2015 Validating certificate key usage
2015-08-13 14:26:18 openvpn: output: Thu Aug 13 14:26:18 2015 ++ Certificate has key usage 00a0, expects 00a0
2015-08-13 14:26:18 openvpn: output: Thu Aug 13 14:26:18 2015 VERIFY KU OK
2015-08-13 14:26:18 openvpn: output: Thu Aug 13 14:26:18 2015 Validating certificate extended key usage
2015-08-13 14:26:18 openvpn: output: Thu Aug 13 14:26:18 2015 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
2015-08-13 14:26:18 openvpn: output: Thu Aug 13 14:26:18 2015 VERIFY EKU OK
2015-08-13 14:26:18 openvpn: output: Thu Aug 13 14:26:18 2015 VERIFY OK: depth=0, C=FR, O=Freebox SA, CN=Freebox OpenVPN server […]
2015-08-13 14:26:19 openvpn: output: Thu Aug 13 14:26:19 2015 WARNING: ‘dev-type’ is used inconsistently, local=’dev-type tun’, remote=’dev-type tap’
2015-08-13 14:26:19 openvpn: output: Thu Aug 13 14:26:19 2015 WARNING: ‘link-mtu’ is used inconsistently, local=’link-mtu 1557’, remote=’link-mtu 1589’
2015-08-13 14:26:19 openvpn: output: Thu Aug 13 14:26:19 2015 WARNING: ‘tun-mtu’ is used inconsistently, local=’tun-mtu 1500’, remote=’tun-mtu 1532’
2015-08-13 14:26:19 openvpn: output: Thu Aug 13 14:26:19 2015 Data Channel Encrypt: Cipher ‘AES-256-CBC’ initialized with 256 bit key
2015-08-13 14:26:19 openvpn: output: Thu Aug 13 14:26:19 2015 Data Channel Encrypt: Using 160 bit message hash ‘SHA1’ for HMAC authentication
2015-08-13 14:26:19 openvpn: output: Thu Aug 13 14:26:19 2015 Data Channel Decrypt: Cipher ‘AES-256-CBC’ initialized with 256 bit key
2015-08-13 14:26:19 openvpn: output: Thu Aug 13 14:26:19 2015 Data Channel Decrypt: Using 160 bit message hash ‘SHA1’ for HMAC authentication
2015-08-13 14:26:19 openvpn: output: Thu Aug 13 14:26:19 2015 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 2048 bit RSA
2015-08-13 14:26:19 openvpn: output: Thu Aug 13 14:26:19 2015 [Freebox OpenVPN server […]] Peer Connection Initiated with [AF_INET][IP]:[PORT]
2015-08-13 14:26:20 openvpn: rx: >STATE:1439468780,GET_CONFIG,,,,,,0
2015-08-13 14:26:20 openvpn: output: Thu Aug 13 14:26:20 2015 MANAGEMENT: >STATE:1439468780,GET_CONFIG,,,,,,0
2015-08-13 14:26:21 openvpn: output: Thu Aug 13 14:26:21 2015 SENT CONTROL [Freebox OpenVPN server […]]: ‘PUSH_REQUEST’ (status=1)
2015-08-13 14:26:21 openvpn: rx: >STATE:1439468781,CONNECTED,SUCCESS,,[IP],,,1500
2015-08-13 14:26:21 openvpn: bad local ip
2015-08-13 14:26:21 l3 is now stable
2015-08-13 14:26:21 l3 does not fulfil config requirement
2015-08-13 14:26:21 l3 state change ‘l3_wait_stable’ ⇒ ‘l3_bring_down’
2015-08-13 14:26:21 waiting for l3 providers to go down
2015-08-13 14:26:21 l3 state change ‘l3_bring_down’ ⇒ ‘l3_wait_down’
2015-08-13 14:26:21 l3 state change ‘l3_wait_down’ ⇒ ‘l3_cleanup_start’
2015-08-13 14:26:21 calling helper script at ‘/etc/fbxconnman/conn.post-down’
2015-08-13 14:26:21 l3 state change ‘l3_cleanup_start’ ⇒ ‘l3_wait_postdown_helper’
2015-08-13 14:26:21 openvpn: output: Thu Aug 13 14:26:21 2015 PUSH: Received control message: ‘PUSH_REPLY,ping 30,ping-restart 120’
2015-08-13 14:26:21 openvpn: output: Thu Aug 13 14:26:21 2015 OPTIONS IMPORT: timers and/or timeouts modified
2015-08-13 14:26:21 openvpn: output: Thu Aug 13 14:26:21 2015 Initialization Sequence Completed
2015-08-13 14:26:21 openvpn: output: Thu Aug 13 14:26:21 2015 MANAGEMENT: >STATE:1439468781,CONNECTED,SUCCESS,,[IP],,,1500
2015-08-13 14:26:21 l3 state change ‘l3_wait_postdown_helper’ ⇒ ‘l3_cleanup_finish’
2015-08-13 14:26:21 l3 state change ‘l3_cleanup_finish’ ⇒ ‘l3_finished’
2015-08-13 14:26:21 state change ‘wait_l3_up’ ⇒ ‘wait_l3_down’
2015-08-13 14:26:21 l3 state change ‘l3_finished’ ⇒ ‘l3_down’
2015-08-13 14:26:21 state is now DOWN
2015-08-13 14:26:21 state change ‘wait_l3_down’ ⇒ ‘l3_finished’
2015-08-13 14:26:21 state change ‘l3_finished’ ⇒ ‘wait_l2_down’
2015-08-13 14:26:21 l2 state change ‘l2_up’ ⇒ ‘l2_cleanup’
2015-08-13 14:26:21 l2 state change ‘l2_cleanup’ ⇒ ‘l2_down’
2015-08-13 14:26:21 state change ‘wait_l2_down’ ⇒ ‘down’

Bonjour,
En utilisant le serveur OpenVPN bridgé, même si on assigne une adresse IP locale fixe au client celle-ci est sous un autre sous-réseau.
Le client n’est pas visible sur le même sous-réseau et son adresse IP locale est affichée 0.0.0.0.
Un freenaute a trouvé la solution avec une longue commande mais ce serait bien si ça pouvait marcher “out of the (free)box”.
https://https://forum.ubuntu-fr.org/viewtopic.php?id=2052651 Merci

Lorsque le Serveur est en mode bridge, le mDNS émis par le Player pollue les log des routeurs/firewall placés en aval du Serveur ce qui génère de fausses alertes d’usurpation d’IP.
Un simple switch pour activer/désactiver le mDNS du player serait la bienvenue.

D’avance merci !

Bonjour,

Suite à l’utilisation du serveur OpenVPN en mode bridgé sur ma freebox V6 (le poste distant utilisant le client OpenVPN Windows), j’ai un débit descendant (du PC distant vers ma freebox) très bon (environ 10Mo/s), alors qu’en montant ce débit est très faible (environ 70ko/s).

J’ai tenté de changer de port, forcé en UDP, changé de mode de chiffrement, sans aucun succès.

J’ai constaté ce problème depuis 2 freebox différentes (donc sur 2 lignes différentes), dans les mêmes proportions.

Après une recherche sur Internet, j’ai trouvé cette explication : http://winaero.com/blog/speed-up-openvpn-and-get-faster-speed-over-its-channel/

Malheureusement pour corriger ce problème il faut modifier le fichier “server.conf” du serveur OpenVPN, chose que nous n’avons pas moyen de faire (et cela me parait normal).

Je voulais donc savoir dans quelles mesures ce fichier pouvait être modifié.

Je vous remercie,
Cordialement,
BENUR

Il semble que l’adresse fd0f:ee:b0::1 n’est pas up en mode bridge, ce qui ne permet pas d’acceder à la freebox tant qu’il n’y a pas de synchro.

Je peux utiliser l’adresse link local mais ca pose des problèmes pour la router

BTW quel est le MTU pour cette addresse 1500 ou 1480 ?

ip addr
...
31: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1480 qdisc noqueue state UP group default qlen 1000

  link/ether 14:cc:20:0c:78:5e brd ff:ff:ff:ff:ff:ff
  inet6 fd0f:ee:b0::2/64 scope global 
     valid_lft forever preferred_lft forever
  inet6 fe80::16cc:20ff:fe0c:785e/64 scope link 
     valid_lft forever preferred_lft forever

...

ip route get fd0f:ee:b0::1
fd0f:ee:b0::1 from :: dev eth0 proto kernel src fd0f:ee:b0::2 metric 256 pref medium

ping6 fd0f:ee:b0::1
PING fd0f:ee:b0::1 (fd0f:ee:b0::1): 56 data bytes

— fd0f:ee:b0::1 ping statistics — 3 packets transmitted, 0 packets received, 100% packet loss

socat - tcp6-connect:[fd0f:ee:b0::1]:80
GET /
2017/01/07 16:21:46 socat[18667] E connect(5, AF=10 [fd0f:00ee:00b0:0000:0000:0000:0000:0001]:80, 28): Host is unreachable

ping6 fe80::XXX:78ff:fe1c:2b77%eth0
PING fe80::XXX:78ff:fe1c:2b77%eth0 (fe80::6aa3:78ff:fe1c:2b77%eth0): 56 data bytes
64 bytes from fe80::XXX:78ff:fe1c:2b77: seq=0 ttl=64 time=0.494 ms
64 bytes from fe80::XXX:78ff:fe1c:2b77: seq=1 ttl=64 time=0.465 ms
64 bytes from fe80::XXX:78ff:fe1c:2b77: seq=2 ttl=64 time=0.427 ms
64 bytes from fe80::XXX:78ff:fe1c:2b77: seq=3 ttl=64 time=0.427 ms
64 bytes from fe80::XXX:78ff:fe1c:2b77: seq=4 ttl=64 time=0.417 ms

socat - tcp6-connect[fe80::XXX:78ff:fe1c:2b77%eth0]:80
2017/01/07 16:24:42 socat[18794] E unknown device/address “tcp6-connect[fe80::XXXX:78ff:fe1c:2b77%eth0]”

root@OpenWrt:~# socat - tcp6-connect:[fe80::XXXX:78ff:fe1c:2b77%eth0]:80
GET /
<!DOCTYPE HTML>

<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="user-scalable=no,width=640" />
    <title>Freebox OS</title>
    <link rel="stylesheet" href="resources/css/ext-theme-classic.css?v=6fc705ae37cb6900959981efd00a2c07d28b9c34">
    <link rel="stylesheet" href="resources/css/btn.css?v=f69a1aa3c216108c791625a61937dc3c640a4cdf">
    <link rel="stylesheet" href="resources/css/fbx.css?v=f06254ed6d39675d818e6f4cab9d30a675bc2d61">
    <script type="text/javascript">//<![CDATA[
        FbxConf = {};
        FbxConf.apiBaseUrl = '/api/v3/';
        FbxConf.uploadBaseUrl = '/api/v3/upload/';
        FbxConf.csrfToken = '';
        FbxConf.firmwareVersionMajor = '3';
        FbxConf.firmwareVersionMinor = '3';

        var _paq = _paq || [];
        _paq.push(["trackPageView"]);
        _paq.push(['setCustomVariable', 1, 'FromExt', '0', 'page']);

        FbxFilenames = {
          "expressInstall": "expressInstall.swf?v=1c12004633e89d6de3bbe4a190093a537bdecebe",
          "hlsplayer": "hlsplayer.swf?v=95b2f91b30e78015a68202ac95f65a9be7d0acc9",
        };

    //]]></script>
    <script src="resources/js/freeboxos.min.js?v=21599b783dddcd2de0e32449ea236c1b13e2394e"></script>
    <script src="resources/js/jquery.min.js?v=bfa700339185fcaa1b8388a62eb3285461f7dcb9"></script>
    <script src="resources/js/swfobject.min.js?v=760434d819abc468eb420ccd7df39198cbf6a638"></script>
</head>
<body>
</body>

Bonjour,

J’utilise une Mini 4K sur fibre FTTH et IP V4 fullstack ou est raccordé au LAN de la Mini 4k un routeur ASUS RT-AC88U (firmware ASUS Merlin à jour) qui supporte mon réseau domestique.

Micrologiciel 4.3.2 Freebox Server mini (R2)

* En mode routeur Free, pas de soucis hormis les limitations de l’usage de mon Asus, DDNS ASUS par exemple mais très stable.

* En mode pont (Bridge), c’est inutilisable, grosse pertes de paquets et freeze… reboot multiples et/ou reset usine de la freebox server ne change rien à l’histoire, le retour au mode routeur Free fait disparaître toute instabilité : Aller retour entre les 2 modes routeur/bridge Free effectués multe fois avec le même constat :(

De plus, j’utilise sur mon routeur ASUS mode “DUAL WAN fail over”, en clair j’utilise Free OU un autre fournisseur internet haut débit derrière le routeur ASUS de façon automatisée.

Cet autre fournisseur configuré en mode bridge haut débit fonctionne sans aucun soucis, ça ne fait que confirmer que c’est bien le mode bridge de la Mini 4K qui est en cause !

Je sais qu’il y a d’autres post sur l’implémentation du mode bridge dans les Freebox et des demande de mise à jour notamment de iproute2 et de suppression de codes obsolètes, je ne peux que m’y associer, ensuite est-ce le seul soucis et mon problème fait-il partie de ce sujet ?

Quoiqu’il en soit le mode bridge mini 4k est totalement inutilisable chez moi et ça sent vraiment le bug.

Est-ce un soucis connu et pouvez-vous s’il vous plaît vous pencher sur cette anomalie ? je suis bien sur disponible pour tout test ou fourniture d’autres éléments afin d’investiguer.

Merci par avance.

PYJ

HomeBridge a été supprimé, impossible de le réactiver. Est-ce normal? je ne trouve aucune documentation à ce sujet.

Bonjour,

Lorsque j’active le serveur VPN en mode bridgé sur la freebox V6, je suis capable de me connecter avec le client VPN de ma machine Unbuntu.
Par contre, le client ne recoit pas d’IP.

Si je fait un “sudo dhclient tap0” sur ma machine ubuntu, une addresse IP est assigné à l’interfcae tap0 mais ma machine n’arrive pas à discuter avec les autres machines du réseau.
Si je fait un “sudo ifconfig tap0 192.168.0.30”, une addresse IP est assignée à l’interfcae tap0 et ma machine arrive à discuter avec les autres machines du réseau.

Pour moi le DHCP de la V6 doit distribuer une IP à ma machine mais ça ne semble pas être le cas ou si c’est le cas ma machine ne peut pas discuter avec les autres sur le réseau. Est-ce normal?

Cordialement,
Sebastien

Je viens de perdre deux heures pour comprendre que sur la Ultra le mode Bridge ne fonctionne que sur le port SFP+ !

Ca sent le bugg et ça voudrait dire que le port SFP+ est géré à part.

Hélas le câble SFP+ que j’avais entre la Delta et mon UDM Pro ne fonctionne plus. Merci de ne pas fournir le câble idoine et de ne pas pouvoir réutiliser l’ancien.

J’ai fini par retrouver un très court câble SFP+ de chez Ubiquiti et et la tout est reconnu et fonctionnel mais avec de mauvais débits en UP.

J’ai commandé ce câble https://amzn.to/3TgSuRS qui semble OK d’après les forums.

Ce problème reste à expliquer

Bonjour,

J’aurais voulu savoir s’il était possible d’installer homebridge en VM sur la Freebox ultra, j’ai réussi à installer home assistant mais trop gourmand je l’ai donc désinstallé.

Merci beaucoup

Bonjour,

Ancien utilisateur de la fibre orange et adepte aux nouvelles technologies, j'ai une maison bien connectée. La box orange, incapable de gérer plus de 20 connexions simultanées était insuffisante pour mon usage. Or, je decide de passer chez free notamment pour pouvoir bénéficier de l'option bridge afin de m'en servir de mon propre routeur plus performant.

La Freebox pop se connect bien au réseau fibre, l'heure s'affiche. Je vais sur l'interface de réglages pour changer de mode routeur vers mode bridge. En mode routeur tout fonctionne, le routeur Netgear que je veux utiliser est connecte par ethernet et tant que la Freebox reste en mode routeur mon Netgear a access internet. C'est lors du passage en mode bridge qu'il n'y a plus d'internet. Le routeur ne détecte aucune connexion malgre être toujours connecte via ethernet. Je teste en branchant le meme cable ethernet connecté sur le Netgear sur mon ordinateur, pareil, pas de connexion internet.

Comment résoudre ce problème?

Depuis le 29/03/2022 dans la journée, ma Freebox en mode bridge ne fournit plus d'adresse IPv4 à mon unique ordinateur connecté directement en filaire sur la Freebox. Les requêtes DHCP émises localement restent sans réponse, ce qui est contraire à ce qu'indique le pop-up de Freebox OS lorsqu'on active le mode bridge.

L'option "IPv4 full stack" est bien activée (depuis longtemps) dans mon espace abonné.

Du côté IPv6, tout va bien, j'obtiens bien une adresse en SLAC et je communique bien avec le reste du monde IPv6.

C'est dommage de ne pas pouvoir profiter de 99,9 % de l'Internet parce que la Freebox ne m'a pas donné d'adresse IPv4…

Une fois le mode bridge activé sur Freebox OS, il est impossible de pouvoir réactiver le mode routeur facilement.

L’interface de Freebox OS n’est plus accessible, l’application Freebox sur mobile ne le permet pas. La seule solution est de redémarrer le server et de faire un reset d’usine.

Il me semble que sur Mini 4K on pouvait continuer d’accéder à Freebox OS pour réactiver le mode routeur si besoin.

Testé sur Freebox POP Sevrer version 4.2.5 (connexion VDSL).

Je trouve plusieurs tickets concernant l’activation du LACP, et je trouve la réponse “ça ne servirait à rien vous ne saturerez jamais le lien router⇔freebox un peu obsolète dans la mesure où le débit fibre est maintenant supérieur à 2.5Gbps avec la Pop.
On commence à trouver aujourd’hui pas mal de routeurs capables de supporter du LACP sur un port WAN 2.5GB + Ethernet 1GB, et il serait plutôt sympa d’avoir la possibilité d’en bénéficier avec la Freebox POP, en mode bridge uniquement par exemple, pour pouvoir encaisser des pics de trafic.
Je suis très satisfait de ma connexion fibre et des performances générales de la POP (que j’utilise en bridge avec un routeur wifi 6 Orbi, très bon combo), le support du LACP serait la cerise sur la gâteau fort appréciée.

Merci de prendre cela en considération!

Depuis la version 4.5.3., une Freebox pop que j’administre ne renvoie plus l’ip ni la connexion internet au routeur tiers.

Cela se produit de manière brutale et aléatoire. Un redémarrage de la box règle le problème et la box reste bien en bridge. La diode reste blanche quand le problème survient.

La box est en Vdsl. 0 soucis sur une mini 4K en fibre en comparaison.

Est possible qu’un bug de cette version du firmware soit en cause ?

J’ai une ip fullstack.

Bonjour,
Est-il possible d’utiliser l’adresse IPv6 du serveur Freebox dans les liens générés à partir de l’explorateur de fichier si on est configuré en mode Bridge vers un serveur en pont ?
Cela permettrait de pointer sur le serveur Freebox plutôt que sur le serveur en pont avec l’adresse IPv4.
Vérifié en modifiant manuellement l’adresse IPv4 du lien par l’adresse IPv6 du serveur Freebox.

Bonjour,

Impossible d’utiliser la Freebox Delta en mode Bridge. Cela rend le réseau complètement inutilisable avec des déconnexions constantes et erreurs DNS.
Obligé de se mettre en mode routeur ce que je ne souhaite pas.

Je résume mes mésaventures avec la Freebox Delta :
- Wifi mesh avec une très mauvaise stabilité et portée (remplacé par un routeur wifi TPlink c’est le jour et la nuit)
- Agrégation 4G qui n’a jamais apporté aucun débit notable, même pendant une période d’un mois où mon débit global était <1Mo à cause d’un mauvais câble (réglé depuis, sachant que 2 freehelpers n’ont absolument rien trouvé d’autre à dire que “tout va bien de notre côté”, heureusement que j’ai trouvé la source du problème tout seul)
- Bugs innombrables sur le player Dévialet, entre les artefacts d’image, le replay qui plante, le airdrop qui ne fonctionne pas, la lecture en dlna capricieuse...
Ca fait cher le player/enceinte sur laquelle on ne peut même pas brancher de casque audio (super pour les malentendants comme moi).

Le mode bridge qui ne fonctionne pas c’est un peu la goutte d’eau qui fait déborder le vase...
Merci 1000 fois à qui aura une solution ou au développeur qui réparerait ça pour la prochaine mise à jour !

Bonjour,

Après un certains temps installé sur la delta, la VM Homebridge finit toujours par ne plus fonctionner.
Lorsque je regarde sur l'application Freebox, je vois état de la vm au vert, puis etat du serveur en rouge et état des droits freebox os en rouge aussi.
Dans ce cas, redémarrer la vm et la box ne changent rien et je dois réinstaller la vm ce qui implique refaire tous les scénarios utilisant les différents détecteurs…

De plus, dans l'application Maison, l'alarme a la fâcheuse tendance à rester dans l'état "Activation".

Des idées pour ces différents problèmes?
Merci

bonjour impossible de passer en mode bridge. a chaque redemarage de la box delta elle repasse en routeur, je suis avec le firmware 4.7.1

Equipé d’un routeur Wifi Mesh TP-Link Deco x90, impossible de faire fonctionner la délégation de préfixe IPv6 de la freebox. Le deco x90 n’acceptant que le mode IP dynamique, je ne peux pas saisir manuellement d’adresse. Aucune adresse n’est assignée dynamiquement à mon deco par la freebox.
Ce problème IPv6 empêche le fonctionnement d’Oqee installé sur ma shield TV pro.

Bonjour,

il serait intéressant de pouvoir déclaré des routes vers des réseaux privés via un routeur tiers ou dans le cas ou cette fonction ne pourrait pas être implémentée, la possibilité de maintenir toutes les fonctions du freebox server lorsque celui ci est en bridge.
pour exemple :

isp 1 (free) —-

              |                
              routeur tiers ----|
              |                 |--- 10.1.0.0/24

isp 2 ———– |— 172.16.1.0/22

                                |--- 192.168.20.128/25
                         

Bonjour,

Le mode bridge de la Freebox est devenu déficient dernièrement de mon côté. En
effet, une fois la Freebox configuré en mode bridge, la plupart des paquets que
j’essaye d’envoyer sont filtrés: les pings fonctionnent bien, mais toute
connection sur, eg, le port 80/un wget est drop et les requêtes DNS ne
fonctionnent bien évidemment pas.
Je reçois bien les délégations d’adresses de la pars de la Freebox (IPv4&v6)
cependant aucun accès WAN.

Il ne s’agit pas d’une erreur de configuration de mon routeur sachant que j’ai
le même problème en essayant de me connecter avec un cable RJ45 sans
intermédiaire avec tout mes appareils, quelque soit l’OS.

Vous pouvez voir un enregistrement du problème ici, avec un routeur
OpenWRT: https://asciinema.org/a/lVHsJNZmqzlgQXLgDtu8dxd0I

Je suis disponible pour tout renseignement, aide à la reproduction, etc.
J’ai essayé d’appeller le 3244 mais malheureusement, cela était “en dehors de
leur champ d’expertise”, en continuant de me dire qu’il y’avais un intermédiaire
entre ma Freebox et mon ordinateur et que c’était une erreur de configuration,
l’intermédiaire étant mon cable ethernet entre la Freebox et mon ordinateur :)

Le bug https://dev.freebox.fr/bugs/task/29282 est possiblement lié.

Merci beaucoup et bonne journée,

Respectueusement,
Gauvain Roussel-Tarbouriech