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

zoc · « **Réponse #4236 le:** 11 mai 2019 à 06:20:00 »

Citation de: kanabeach44 le 10 mai 2019 à 21:45:14

Donc ça la config est HS ! Et le routeur revient en config ip d'origine ?

Non, j’ai juste dit tout le contraire...

La config est conservée mais par contre il faut remettre dhclient.

FrCo · « **Réponse #4237 le:** 11 mai 2019 à 11:01:20 »

Citation de: zoc le 10 mai 2019 à 21:09:16

Pourquoi rajouter des taches dans la crontab quand on peut le faire dans le fichier de config (task-scheduler) ?

Moi aussi j'ai plein de scripts (dont un qui réinstalle dhclient et dibbler-client automatiquement au premier reboot après la mise à jour firmware). Bon, après, faire une sauvegarde, c'est évidemment toujours recommandé.

Ça veut dire que si j'update ma version (aujourd'hui en 1.9.7 hf4), je fais là mise à jour en 1.10.9 et je recopie dhclient et dibbler et normalement c'est bon ?

zoc · « **Réponse #4238 le:** 11 mai 2019 à 15:06:49 »

Non, parce qu’avec les versions 1.9 il fallait aussi modifier Vyatta-interfaces.pl pour rajouter l’option 90, ce qui n’est plus possible puisque ce fichier n’est plus utilisé en 1.10.

A la place Ubiquiti a rajouté le paramètre « global-option ». Lors du passage de 1.9 a 1.10 il faut donc modifier la config.

FrCo · « **Réponse #4239 le:** 11 mai 2019 à 15:21:53 »

Ok, merci Zoc.

Du coup, je vais reprendre le fil pour faire les updates nécessaires au niveau de la config pour pour faire l'update en 1.10.9.

nicox11 · « **Réponse #4240 le:** 12 mai 2019 à 19:50:32 »

Je viens de passer en 1.10.9 mais depuis l'IPV6 ne fonctionne pas.

sudo dibbler-client run
| Dibbler - a portable DHCPv6, version 1.0.1 (CLIENT, Linux port)
| Authors : Tomasz Mrugalski<thomson(at)klub.com.pl>,Marek Senderski<msend(at)o2.pl>
| Licence : GNU GPL v2 only. Developed at Gdansk University of Technology.
| Homepage: http://klub.com.pl/dhcpv6/
2019.05.12 07:01:46 Client Notice My pid (6954) is stored in /var/lib/dibbler/client.pid
2019.05.12 07:01:46 Client Notice Detected iface eth2.10/22, MAC=fc:ec:da:45:75:9c.
2019.05.12 07:01:46 Client Notice Detected iface eth2.20/21, MAC=fc:ec:da:45:75:9c.
2019.05.12 07:01:46 Client Notice Detected iface eth2.30/20, MAC=fc:ec:da:45:75:9c.
2019.05.12 07:01:46 Client Notice Detected iface eth2.40/19, MAC=fc:ec:da:45:75:9c.
2019.05.12 07:01:46 Client Notice Detected iface eth2.50/18, MAC=fc:ec:da:45:75:9c.
2019.05.12 07:01:46 Client Notice Detected iface eth2.90/17, MAC=fc:ec:da:45:75:9c.
2019.05.12 07:01:46 Client Notice Detected iface eth2.999/16, MAC=fc:ec:da:45:75:9c.
2019.05.12 07:01:46 Client Notice Detected iface eth1.832/15, MAC=fc:ec:da:45:75:9b.
2019.05.12 07:01:46 Client Notice Detected iface imq0/14, MAC=.
2019.05.12 07:01:46 Client Notice Detected iface loop3/13, MAC=ca:a2:50:2d:db:2a.
2019.05.12 07:01:46 Client Notice Detected iface loop2/12, MAC=b6:ee:23:3b:2d:57.
2019.05.12 07:01:46 Client Notice Detected iface loop1/11, MAC=9a:b9:70:6a:4b:c5.
2019.05.12 07:01:46 Client Notice Detected iface loop0/10, MAC=6e:1c:b5:f5:6b:b3.
2019.05.12 07:01:46 Client Notice Detected iface npi3/9, MAC=d6:5b:f4:cd:b4:dd.
2019.05.12 07:01:46 Client Notice Detected iface npi2/8, MAC=46:66:b5:37:d1:60.
2019.05.12 07:01:46 Client Notice Detected iface npi1/7, MAC=d6:9f:bd:f1:81:ce.
2019.05.12 07:01:46 Client Notice Detected iface npi0/6, MAC=86:43:2f:9a:78:5b.
2019.05.12 07:01:46 Client Notice Detected iface eth2/5, MAC=fc:ec:da:45:75:9c.
2019.05.12 07:01:46 Client Notice Detected iface eth1/4, MAC=fc:ec:da:45:75:9b.
2019.05.12 07:01:46 Client Notice Detected iface eth0/3, MAC=fc:ec:da:45:75:9a.
2019.05.12 07:01:46 Client Notice Detected iface eth3/2, MAC=fc:ec:da:45:75:99.
2019.05.12 07:01:46 Client Notice Detected iface lo/1, MAC=00:00:00:00:00:00.
2019.05.12 07:01:46 Client Notice Parsing /etc/dibbler/client.conf config file...
2019.05.12 07:01:46 Client Info Interface eth1.832/15 configuration has been loaded.
2019.05.12 07:01:46 Client Info My DUID is 00:01:00:01:24:6a:71:dd:fc:ec:da:45:75:9c.
2019.05.12 07:01:47 Client Info Loading old address database (client-AddrMgr.xml), using built-in routines.
2019.05.12 07:01:47 Client Info DB timestamp:1557644073, now()=1557644507, db is 434 second(s) old.
2019.05.12 07:01:47 Client Info All client's 00:01:00:01:24:6a:71:dd:fc:ec:da:45:75:9c leases are not valid.
2019.05.12 07:01:47 Client Notice Creating control (

socket on the lo/1 interface.
2019.05.12 07:01:47 Client Notice Creating socket (addr=fe80::feec:daff:fe45:759b) on eth1.832/15 interface.
2019.05.12 07:01:47 Client Notice CONFIRM support compiled in.
2019.05.12 07:01:47 Client Info Creating SOLICIT message with 0 IA(s), no TA and 1 PD(s) on eth1.832/15 interface.
2019.05.12 07:01:47 Client Error AUTH: protocol 13621952 not supported yet.
2019.05.12 07:01:48 Client Info Processing msg (SOLICIT,transID=0xd7e919,opts: 1 25 8 16 15 11 11 6)
2019.05.12 07:01:48 Client Error AUTH: protocol 13621952 not supported yet.

J'ai déjà eu ce message par le passé, mais impossible de corriger cette fois. Tout semble ok.
Voici mon fichier client.conf :

# Defaults for dibbler-client.
# installed at /etc/dibbler/client.conf by the maintainer scripts

log-level 7

duid-type duid-ll

downlink-prefix-ifaces "none"
script "/etc/dibbler/radvd.sh"

iface eth1.832 {
pd
option 16 hex 00:00:04:0e:00:05:73:61:67:65:6d
option 15 hex 00:2b:46:53:56:44:53:4c:5f:6c:69:76:65:62:6f:78:2e:49:6e:74:65:72:6e:65:74:2e:73:6f:66:74:61:74:68:6f:6d:65:2e:6c:69:76:65:62:6f:78:34
option 11 hex 00:00:00:00:00:00:00:00:00:00:00:xx:xx:xx
option 11 hex 00:00:00:00:00:00:00:00:00:00:00:xx:xx:xx
option dns-server
}

zoc · « **Réponse #4241 le:** 12 mai 2019 à 20:39:11 »

Pas de problème de mon coté...

dmfr · « **Réponse #4242 le:** 13 mai 2019 à 15:14:00 »

Citation de: nicox11 le 12 mai 2019 à 19:50:32

2019.05.12 07:01:47 Client Info Creating SOLICIT message with 0 IA(s), no TA and 1 PD(s) on eth1.832/15 interface.
2019.05.12 07:01:47 Client Error AUTH: protocol 13621952 not supported yet.
2019.05.12 07:01:48 Client Info Processing msg (SOLICIT,transID=0xd7e919,opts: 1 25 8 16 15 11 11 6)
2019.05.12 07:01:48 Client Error AUTH: protocol 13621952 not supported yet.

J'ai également ce problème à chaque chaque upgrade d'EdgeOS.
A mon sens, c'est le changement du DUID (généré plus ou moins aléatoirement ?) qui bloque chez Orange quand un bail est encore en place.

Deux options :
- réinstaller le DUID précédemment utilisé dans /var/lib/dibbler/client-duid
- rebooter l'ONT ou le modem, ce qui semble forcer la fin du bail en cours

kouze · « **Réponse #4243 le:** 13 mai 2019 à 16:45:47 »

Citation de: zoc le 20 avril 2019 à 16:54:35

Oui, j’ai ce problème depuis le début, et pas qu’avec des décodeurs UHD, mais aussi le décodeur TV 4.

Je ne sais pas trop comment résoudre le problème quand les décodeurs sont sur le même LAN que le reste des équipements de la maison, hormis désactiver totalement UPnp sur le routeur.

Chez moi, j’ai mis les décodeurs dans un VLAN séparé et je n’ai pas activé UPnp sur ce VLAN. Il est sûrement possible de faire mieux (ce qui en plus permettrait d’activer le pilotage à distance des décodeurs avec l’application Orange TV sur smartphone), mais je n’ai pas vraiment eu le temps de me pencher sur la question et j’ai d’autres projets plus prioritaires.

Vu que je ne pouvais pas utiliser mon 3ème port de l'ERL (manque de cablage physique pour faire un réseau à part pour la partie TV), j'ai fini par créer des ACL en DENY pour la partie UPNP2 sur les IPs de mes décodeurs TV. Depuis plus de soucis a priori.
Mais je pense qu'il manque des options pour l'upnpd de l'ERL, au moins une option pour supprimer les règles non utilisées pendant un moment (clean_ruleset_interval)

A+
kouze

nicox11 · « **Réponse #4244 le:** 14 mai 2019 à 09:38:59 »

Citation de: dmfr le 13 mai 2019 à 15:14:00

J'ai également ce problème à chaque chaque upgrade d'EdgeOS.
A mon sens, c'est le changement du DUID (généré plus ou moins aléatoirement ?) qui bloque chez Orange quand un bail est encore en place.

Deux options :
- réinstaller le DUID précédemment utilisé dans /var/lib/dibbler/client-duid
- rebooter l'ONT ou le modem, ce qui semble forcer la fin du bail en cours

Ca a fonctionné après le reboot de l'ONT, merci

zoc · « **Réponse #4245 le:** 14 mai 2019 à 11:01:40 »

duid-ll dans la configuration ça veut dire que dibbler-client doit générer le DUID à partir de l'adresse mac de l'interface réseau uniquement (contrairement à duid-llt où l'heure entre en jeu).

L'adresse mac ne change normalement pas lors d'une mise à jour firmware donc ça ne devrait avoir aucun impact (et accessoirement ça n'en n'a jamais eu chez moi).

Accessoirement, à l'époque où j'avais encore un ERL3, j'avais déplacé /var/lib/dibbler dans /run (qui est un ramdisk) pour éviter de cramer la clé USB interne. Donc à chaque reboot mon DUID est perdu, et, même si je reboote rarement, ça m'arrive et je n'ai jamais eu ce problème.

tcheuck · « **Réponse #4246 le:** 15 mai 2019 à 11:20:27 »

J'ai perdu ma connexion IPv6 vers 01h ce matin. Je n'ai plus de réponse du serveur DHCP Orange :

Code: [Sélectionner]

$ sudo service dhclient6 status
* dhclient6.service - IPv6 DHCP client
   Loaded: loaded (/etc/systemd/system/dhclient6.service; enabled; vendor preset: enabled)
   Active: active (running) since Wed 2019-05-15 09:12:21 UTC; 5min ago
  Process: 6454 ExecStart=/sbin/dhclient -6 -P -nw -cf /etc/dhcp3/dhclient6_eth1_832.conf -pf /var/run/dhclient6_eth1_832.pid -lf /var/run/dhclient6_eth1_832.leases eth1
 Main PID: 6461 (dhclient)
   CGroup: /system.slice/dhclient6.service
           `-6461 /sbin/dhclient -6 -P -nw -cf /etc/dhcp3/dhclient6_eth1_832.conf -pf /var/run/dhclient6_eth1_832.pid -lf /var/run/dhclient6_eth1_832.leases eth1.832

May 15 09:12:21 ubnt systemd[1]: Started IPv6 DHCP client.
May 15 09:12:22 ubnt dhclient[6461]: XMT: Solicit on eth1.832, interval 1040ms.
May 15 09:12:23 ubnt dhclient[6461]: XMT: Solicit on eth1.832, interval 2070ms.
May 15 09:12:25 ubnt dhclient[6461]: XMT: Solicit on eth1.832, interval 4320ms.
May 15 09:12:29 ubnt dhclient[6461]: XMT: Solicit on eth1.832, interval 8900ms.
May 15 09:12:38 ubnt dhclient[6461]: XMT: Solicit on eth1.832, interval 17860ms.
May 15 09:12:56 ubnt dhclient[6461]: XMT: Solicit on eth1.832, interval 35190ms.
May 15 09:13:31 ubnt dhclient[6461]: XMT: Solicit on eth1.832, interval 69250ms.
May 15 09:14:41 ubnt dhclient[6461]: XMT: Solicit on eth1.832, interval 125950ms.
May 15 09:16:47 ubnt dhclient[6461]: XMT: Solicit on eth1.832, interval 121100ms.

J'ai reboot l'ONT et mon ER4, sans effet. Je n'ai pas encore rebranché ma Livebox parce que je n'ai pas envie de perdre le lease de mon IPv4.
Si quelqu'un a une idée je suis preneur...

dmfr · « **Réponse #4247 le:** 15 mai 2019 à 13:14:06 »

Citation de: zoc le 14 mai 2019 à 11:01:40

duid-ll dans la configuration ça veut dire que dibbler-client doit générer le DUID à partir de l'adresse mac de l'interface réseau uniquement (contrairement à duid-llt où l'heure entre en jeu).

Le DUID généré était différent car au moment de l'upgrade il y avait certaines interfaces non ethernet (wireguard, tunnel, ...) qui n'existaient pas lors du setup dibbler initial.
Et je confirme, si on restore le DUID d'origine, la requête DHCP-PD aboutit de nouveau.