La Fibre
Datacenter et équipements réseaux => Routeurs => 
Remplacer la LiveBox par un routeur => Discussion démarrée par: lepoulpe le 18 octobre 2016 à 22:44:15
-
Bonjour,
Est-ce que quelqu'un aurait une expérience récente de remplacement de la livebox par un routeur sous open-wrt (CoS DHCP, IPv6...) ?
En effet, je serais très intéressé par le Turris Omnia. C’est un routeur libre (le soft, mais aussi autant que possible le hard), dont le développement a été financé via Indiegogo : https://www.indiegogo.com/projects/turris-omnia-hi-performance-open-source-router-security-network#/
Au programme :
- 5 ports LAN, 1 port WAN
- Wifi 3x3 802.11ac
- 1 ou 2 GB de RAM
- CPU ARM dual core 1.6 GHz
- Port SFP
- Port mSATA/mPCIe
- 2xUSB3
- Possibilité de faire tourner des serveurs virtuels via container Linux
- et plein d'autres features intéressantes (tous les détails là : https://omnia.turris.cz/en/)
Bref il a tout pour plaire (à part peut être le prix, $246 pour la version 1GB, $284 pour la version 2GB).
Pensez-vous qu'il y ai une chance que ça fonctionne "out of the box" (juste de la conf), ou bien il faudra bidouiller avec des versions de dhcp patchées comme sur l'ERL ?
Merci :)
-
Si le client DHCP est ISC-DHCP (dhclient) ou tout autre client DHCP qui fonctionne avec des sockets RAW, alors oui, il faudra probablement le patcher.
-
Hello,
Merci pour la réponse.
Après recherche, il semble que le client utilisé par défaut soit udhcpc, qui fait partie de Busybox.
De ce que j'ai vu dans les sources, il utiliserait aussi des RAW sockets.
Il y a des clients DHCP dans la nature qui n'utilisent pas les RAW sockets ?
-
Bonsoir,
Je viens de commencer la configuration de mon Turris Omnia et la connexion de base semble bien fonctionner !
Il faut tout d'abord modifier /etc/config/network:
#config interface 'wan'
# option ifname 'eth1'
# option proto 'dhcp'
config interface 'wan'
option ifname 'eth1.832'
option proto 'none'
Le client DHCP de base ne gère pas les options nécessaires, mais on peut facilement installer le client ISC :
opkg install isc-dhcp-client-ipv4
Ce paquet ne contient malheureusement pas le script /sbin/dhclient-script qui configure l'interface réseau et les routes, mais on peut trouver une version plus-ou-moins compatible dans les anciennes sources de OpenWRT :
https://dev.openwrt.org/export/32476/packages/net/dhcp/files/dhclient-script (https://dev.openwrt.org/export/32476/packages/net/dhcp/files/dhclient-script)
On peut ensuite créer le fichier de configuration /etc/dhclient/orange.conf :
option rfc3118-authentication code 90 = string;
interface "eth1.832" {
send vendor-class-identifier "sagem";
send user-class "+FSVDSL_livebox.Internet.softathome.Livebox3";
send rfc3118-authentication 00:00:00:00:00:00:00:00:00:00:00:66:74:69:2f:xx:xx:xx:xx:xx:xx:xx;
request subnet-mask, routers,
domain-name, broadcast-address, dhcp-lease-time,
dhcp-renewal-time, dhcp-rebinding-time,
rfc3118-authentication;
}
Et demander une adresse IP :
dhclient -cf /etc/dhclient/orange.conf -v -pf /var/run/dhclient.orange.pid -lf /tmp/dhclient.orange.leases eth1.832
Internet Systems Consortium DHCP Client 4.3.3
Copyright 2004-2015 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/
Listening on LPF/eth1.832/xx:xx:xx:xx:xx:xx
Sending on LPF/eth1.832/xx:xx:xx:xx:xx:xx
Sending on Socket/fallback
DHCPDISCOVER on eth1.832 to 255.255.255.255 port 67 interval 6
DHCPREQUEST on eth1.832 to 255.255.255.255 port 67
DHCPOFFER from xxx.xxx.xxx.xxx
DHCPACK from xxx.xxx.xxx.xxx
/sbin/dhclient-script: line 134: hostname: not found
/sbin/dhclient-script: line 134: hostname: not found
bound to xxx.xxx.xxx.xxx -- renewal in 33754 seconds.
root@turris:~# ping google.com
PING google.com (216.58.204.142): 56 data bytes
64 bytes from 216.58.204.142: seq=0 ttl=56 time=24.709 ms
Je n'ai pas eu à ajuster les priorités. Le débit semble aussi bon qu'avec mon ERL.
-
Très intéressant. :D
Il faudrait à présent se pencher sur les routes dédiées au décodeur TV, ainsi que sur l'ipv6.
Tes recherches sont prometteuses en tout cas.
-
on a un sujet connexe ici: https://lafibre.info/remplacer-livebox/sosh-fibre-openwrt-avec-ip-fixe-et-ipv6/
Avec les tp-link (ar71xx), le client isc-dhcp n'est pas dispo en package directement.
on etudie une solution pour patcher un autre client ou carrement le client natif ce qui serait mieux et permettrait de faire la config via l'interface web.
vu que ton routeur supporte isc-dhcp tu peux t'en sortir comme ca . Apparement tu es dans une zone qui fonctionne sans QoS donc chanceux, ce n'est pas le cas partout.
Il y a des clients DHCP dans la nature qui n'utilisent pas les RAW sockets ?
non car en IPv4 le 1er paquet de requete DHCP n'a pas d'IP source. Sous Linux ceci n'est possible qu'avec les raw sockets.
-
Juste un petit update. Internet (IPv4) et la TV fonctionnent avec le client DHCP de base :) Demain, je mettrai la configuration complète sur Github.
-
Voici les fichiers de configuration: https://github.com/rbadsi/omnia_orange (https://github.com/rbadsi/omnia_orange)
Internet (IPv4) et la TV fonctionnent parfaitement. Je rappelle que je ne change pas la priorité des requêtes DHCP, car je n'ai pas besoin de le faire sur ma ligne, mais ce n'est pas le cas de tout le monde.
Je n'ai pas encore décidé comment procéder pour l'IPv6. Le client DHCPv6 de base ne permet pas d'envoyer les options nécessaires. Je pourrais soit installer le client ISC, soit modifier le code source du client de base. L'inconvénient majeur du client ISC, c'est qu'il ne s'intègre pas très bien dans OpenWRT (il faut créer un script dans /lib/netifd/proto...).
Je n'ai pas réussi à faire marcher la VOD et le Replay. Si quelqu'un a une idée, je suis preneur !
-
comme deja indiqué plus haut on a un sujet identique ici: https://lafibre.info/remplacer-livebox/sosh-fibre-openwrt-avec-ip-fixe-et-ipv6/
si tu ne veux pas tout relire : https://lafibre.info/remplacer-livebox/sosh-fibre-openwrt-avec-ip-fixe-et-ipv6/msg393622/#msg393622
Met toi en relation avec "moht" il a une solution pour IPv6 et cherche de l'aide pour finaliser tout ca. J'ai l'impression que vous etes a travailler dans votre coin sur la meme chose...
-
Met toi en relation avec "moht" il a une solution pour IPv6 et cherche de l'aide pour finaliser tout ca. J'ai l'impression que vous etes a travailler dans votre coin sur la meme chose...
J'ai bien lu le sujet complet, et je comptais d'ailleurs voir si je pouvais apporter de l'aide à moht. La solution ultime, c'est bien évidemment d'intégrer l'option sendopts dans odhcp6c (et les scripts de configuration OpenWRT), mais cela prendra du temps, surtout compte tenu de la situation actuelle autour du projet OpenWRT... En attendant, il faut bien que je trouve une solution temporaire. Mon soucis principal est spécifique à TurrisOS. L'OS de l'Omnia n'utilise pas le système de mises à jour normal d'OpenWRT (opkg upgrade + sysupgrade). Le système est mis à jour automatiquement à l'aide d'un script développé par CZ.NIC. Les modifications nécessaires (en particulier /lib/netifd/ qui devra être modifié quelque soit la solution) risquent d'être écrasées à chaque mise à jour.
-
Je n'ai pas réussi à faire marcher la VOD et le Replay. Si quelqu'un a une idée, je suis preneur !
Je viens de regarder ton git et d'après ce que j'en ai lu, 2 solutions s'offrent à toi :
1) mode cool : activer upnpd sur ton interface 'wantv' (external_iface biensûr)
2) mode crade : tu fixe l'adresse du décodeur via le serveur dhcp et tu fais un nat du traffic qui arrive sur interface 'wantv' vers l'ip du décodeur
Dam
-
Je n'ai ni l'un ni l'autre sur mon ERL et la VOD/Replay fonctionnent...
Ce qu'il faut par contre, c'est une règle NAT pour le trafic sortant sur l'interface VLAN 838. Mais en l'espèce, je pense que le problème de VOD est lié aux routes poussées en DHCP qui ne sont pas prises en compte par le routeur (genre il manque le script qui va bien, comme sur l'ERL)...
Pour confirmer il nous faudrait la table de routage, qui devrait contenir des routes ressemblant à ça:
ubnt@gateway:~$ show ip route
Codes: K - kernel, C - connected, S - static, R - RIP, B - BGP
O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
> - selected route, * - FIB route, p - stale info
IP Route Table for VRF "default"
C *> 10.138.104.0/21 is directly connected, eth1.838
K *> 80.10.117.120/31 [0/0] via 10.138.111.254, eth1.838
K *> 80.10.204.0/22 [0/0] via 10.138.111.254, eth1.838
K *> 81.253.206.0/24 [0/0] via 10.138.111.254, eth1.838
K *> 81.253.210.0/23 [0/0] via 10.138.111.254, eth1.838
K *> 81.253.214.0/23 [0/0] via 10.138.111.254, eth1.838
K *> 172.19.20.0/23 [0/0] via 10.138.111.254, eth1.838
K *> 172.20.224.167/32 [0/0] via 10.138.111.254, eth1.838
K *> 172.23.12.0/22 [0/0] via 10.138.111.254, eth1.838
K *> 193.253.67.88/29 [0/0] via 10.138.111.254, eth1.838
K *> 193.253.153.227/32 [0/0] via 10.138.111.254, eth1.838
K *> 193.253.153.228/32 [0/0] via 10.138.111.254, eth1.838
-
Zoc je viens de calculer, l'upnpd est obligatoire pour moi et je te le confirme.
Mais ma config est différente, je n'utilise pas de bridge pour la tv.
A voir...
-
Zoc je viens de calculer. L'upnpd est obligatoire pour moi et je te le confirme.
Mais ma config est différente, je n'utilise pas de bridge pour la tv.
A voir...
Je n'utilise pas de bridge non plus. Et je ne vois pas trop le rapport avec upnp... La VOD/Replay, ce n'est pas du multicast, donc ça ne sert à rien de faire du forward de port entrant. Le seul intérêt d'avoir upnp sur l'interface, c'est de pouvoir contrôler l'enregistreur à distance...
-
Je vais essayer de te retrouver le tcpdump.
PS: je ne remet pas en cause ton analyse ;) mais la mienne est celle que j'ai évoqué
-
pour Vod/Replay (jaune sur le schéma):
- client DHCP sur vlan 838 avec les options qui vont bien:
- mettre en place les routes reçu via l'option 121 (classless static route)
- NATé l'IP recue
- config le décodeur TV avec les DNS d'Orange (si la conf DNS du lan n'est plus celle d'Orange).
pour Live TV (vert sur le schéma):
- igmp : upstream vlan 840, downstream lan (ou juste le port vers le décodeur TV)
Attention a la QoS aussi.
(https://drive.google.com/uc?id=0B5ma-el6j-bDNWMzMHphMlY0eWc)
-
Bonsoir,
Merci Kgersen pour ce rappel mais je connais déjà le fonctionnement (je l'ai lu je ne sais combien de fois en 1 an ;) ).
Voici les élèment dont je dispose. Les tests ont été fait avec le même replay en désactivant l'upnp-igd.
Pour commencer, un extrait des log de pf (10.83.252.20 étant l'ip de l'interface vlan838) :
root@rtv:~ # tcpdump -n -e -ttt -i pflog0 -vvv
00:00:00.004802 rule 0..16777216/0(match): block in on vlan838: (tos 0x90, ttl 59, id 1188, offset 0, flags [DF], proto UDP (17), length 1356)
81.253.210.202.5000 > 10.83.252.20.15004: [udp sum ok] UDP, length 1328
00:00:00.004697 rule 0..16777216/0(match): block in on vlan838: (tos 0x90, ttl 59, id 1188, offset 0, flags [DF], proto UDP (17), length 1356)
81.253.210.202.5000 > 10.83.252.20.15004: [udp sum ok] UDP, length 1328
00:00:00.004774 rule 0..16777216/0(match): block in on vlan838: (tos 0x90, ttl 59, id 1188, offset 0, flags [DF], proto UDP (17), length 1356)
81.253.210.202.5000 > 10.83.252.20.15004: [udp sum ok] UDP, length 1328
00:00:00.004856 rule 0..16777216/0(match): block in on vlan838: (tos 0x90, ttl 59, id 1188, offset 0, flags [DF], proto UDP (17), length 1356)
81.253.210.202.5000 > 10.83.252.20.15004: [udp sum ok] UDP, length 1328
00:00:00.004761 rule 0..16777216/0(match): block in on vlan838: (tos 0x90, ttl 59, id 1188, offset 0, flags [DF], proto UDP (17), length 1356)
81.253.210.202.5000 > 10.83.252.20.15004: [udp sum ok] UDP, length 1328
00:00:00.004827 rule 0..16777216/0(match): block in on vlan838: (tos 0x90, ttl 59, id 1188, offset 0, flags [DF], proto UDP (17), length 1356)
81.253.210.202.5000 > 10.83.252.20.15004: [udp sum ok] UDP, length 1328
Ensuite en fichier joint le tcpdump de l'interface 838 (en vrac).
Je suis peut être passé à coté de quelque chose avec freebsd mais là je ne vois pas
Dam
-
Merci pour vos conseils ! Pour info, c'était un problème de DNS. Le replay fonctionne depuis que j'ai changé la configuration du serveur DHCP pour annoncer les serveurs Orange au décodeur.
-
Merci pour vos conseils ! Pour info, c'était un problème de DNS. Le replay fonctionne depuis que j'ai changé la configuration du serveur DHCP pour annoncer les serveurs Orange au décodeur.
Ah oui effectivement
-
Salut à vous les possesseurs d'Omnia !
L'un d'entre vous a-t-il eu l'occasion de tester l'adaptateur SFP d'orange sur la bête pour tester son bon fonctionnement ?
J'hésite encore à passer à la caisse et avoir une certitude sur ce dernier point m'aiderait grandement donc si vous avez des retours dans ce sens je suis preneur !
Merci :)
-
Je viens de commencer la configuration de mon Turris Omnia et la connexion de base semble bien fonctionner !
Il faut tout d'abord modifier /etc/config/network:
Je m'apprête à tester ta config dans mon Turris que je viens de recevoir cependant j'avais une petite question avant si tu veux bien ;) Tu as configuré du coup ton interface WAN en DHCP tout simple dans le GUI du Turris ? avant d'appliquer tes modifs manuelles ??
En fait deux questions car j'ai testé entretemps ta config mais ça ne marche pas chez moi, ça reste bloqué là-dessus :(
root@routeur:~# dhclient -cf /etc/dhclient/orange.conf -v -pf /var/run/dhclient.orange.pid -lf /tmp/dhclient.orange.leases eth1.832
Internet Systems Consortium DHCP Client 4.3.3
Copyright 2004-2015 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/
Listening on LPF/eth1.832/d8:58:d7:00:2c:f5
Sending on LPF/eth1.832/d8:58:d7:00:2c:f5
Sending on Socket/fallback
DHCPDISCOVER on eth1.832 to 255.255.255.255 port 67 interval 3
DHCPDISCOVER on eth1.832 to 255.255.255.255 port 67 interval 6
DHCPDISCOVER on eth1.832 to 255.255.255.255 port 67 interval 19
Merci
-
bonjour ,
Le post #6 de radim indique que le client dhcp de base supporte les options DHCP. Donc ta configuration doit ressembler a celle d'Openwrt/Lede, regarde mon /etc/config/network ici:
https://lafibre.info/remplacer-livebox/remplacement-de-la-livebox-par-un-routeur-lede-fork-dopenwrt/msg471749/#msg471749
remplacer ptm0 par eth1 dans ton cas.
cette config marche sur Openwrt et sur LEDE.
-
Le post #6 de radim indique que le client dhcp de base supporte les options DHCP. Donc ta configuration doit ressembler a celle d'Openwrt/Lede, regarde mon /etc/config/network ici:
https://lafibre.info/remplacer-livebox/remplacement-de-la-livebox-par-un-routeur-lede-fork-dopenwrt/msg471749/#msg471749
remplacer ptm0 par eth1 dans ton cas.
cette config marche sur Openwrt et sur LEDE.
Peux-tu me confirmer la syntaxe de cette partie là car j'ai un doute :(
option sendopts '0x4D:2b46535644534c5f6c697665626f782e496e7465726e65742e736f66746174686f6d652e4c697665626f7834 0x5a:0000000000000000000000***********************'
comment je dois formatter la partie 0x5a ??? En effet le nombre d'étoiles ne correspond pas à mon identifiant (si je convertis mon ftdi/xxxxx avec le slash compris cela me fait 24 et là j'ai 23 étoiles ?? Erreur ?? et les 22 zéro devant ?
Pour le moment j'ai testé comme ça: 22 zéro suivi de ma string ftdi/.... encodé sur 24 caractères et ça ne marche pas, la connection ne monte pas et je sais pas trop où regarder pour essayer de déterminer ce qui cloche (le dossier /var/log du Turris est quasi vide :(
-
heu ne compte pas les * je n'ai pas compté en les mettant, utilise l'outil : https://jsfiddle.net/kgersen/45zudr15/embedded/result/ pour obtenir la chaîne de caractères correcte.
Si ton identifiant est fti/abcdefg alors ca te fera: 00000000000000000000006674692f61626364656667
option 90 = 0x5a
il faudra donc mettre 0x5a:00000000000000000000006674692f61626364656667
-
heu ne compte pas les * je n'ai pas compté en les mettant, utilise l'outil : https://jsfiddle.net/kgersen/45zudr15/embedded/result/ pour obtenir la chaîne de caractères correcte.
Si ton identifiant est fti/abcdefg alors ca te fera: 00000000000000000000006674692f61626364656667
option 90 = 0x5a
il faudra donc mettre 0x5a:00000000000000000000006674692f61626364656667
Ah super merci effectivement ma string était foireuse mais bon ça ne marche toujours pas :( J'ai le port WAN qui s'excite régulièrement, mais la connection monte pas et je récupère pas d'IP :( Un moyen de voir d'où vient le soucis ? ou quelque chose à vérifier ??
-
- Requête sur le bon VLAN ?
- Priorité 801.1p (CoS) de la requête bien à 6 ?
Le plus simple, ca reste de faire une capture Wireshark de ce qui sort du port WAN du routeur, et de comparer avec ce qu'une Livebox sort...
-
Requête sur le bon VLAN ?
Je suppose que oui puisque la modif en question fait changer mon eth1 (ma patte wan en eth1.832) non ?
Priorité 801.1p (CoS) de la requête bien à 6 ?
Euh rien vu à ce propos dans la config dont on m'a donné le lien juste avant et qui est censé supposer marcher directement......
le plus simple, ca reste de faire une capture Wireshark de ce qui sort du port WAN du routeur, et de comparer avec ce qu'une Livebox sort...
Pas trop le temps à ce genre de choses malheureusement et pas envie de me lancer dans un tel bordel :(
-
Euh rien vu à ce propos dans la config dont on m'a donné le lien juste avant et qui est censé supposer marcher directement......
Dans certaines zones géographiques, les requêtes DHCP doivent avoir une priorité à 6 pour que le serveur DHCP d'Orange réponde. Ce n'est pas le cas partout et il est donc possible que la configuration sur laquelle tu te bases ait été faite par quelqu'un qui n'en n'a pas besoin ;)
-
Dans certaines zones géographiques, les requêtes DHCP doivent avoir une priorité à 6 pour que le serveur DHCP d'Orange réponde. Ce n'est pas le cas partout et il est donc possible que la configuration sur laquelle tu te bases ait été faite par quelqu'un qui n'en n'a pas besoin ;)
ah merdum me voilà donc revenu au point de départ :( aucun des utilisateurs Turris Omnia a eu le même soucis ? parce que je sais pas trop comment le faire pour le moment (faut d'abord que j'apprenne à connaitre un peu mieux la bête !!)
-
l'histoire des priorité et cos est indiqué plus bas dans mon post:
https://lafibre.info/remplacer-livebox/remplacement-de-la-livebox-par-un-routeur-lede-fork-dopenwrt/msg471749/#msg471749
création du fichier /etc/vlanprio.sh qu'on n'oublie pas de rendre exécutable avec un chmod 755
#!/bin/sh
set -x
for i in 0 1 2 3 4 5 6 7; do
## on définit pour chaque file une priorité
ip link set ptm0.832 type vlan egress $i:$i >/dev/null
ip link set ptm0.838 type vlan egress $i:4 >/dev/null
ip link set ptm0.840 type vlan egress $i:5 >/dev/null
done
ip link set ptm0.832 type vlan egress 1:0 >/dev/null
ip link set ptm0.832 type vlan egress 0:6 >/dev/null
ensuite les regles Firewal a ajouter:
iptables -t mangle -A POSTROUTING -o ptm0.832 -j CLASSIFY --set-class 0000:0001
iptables -t mangle -A POSTROUTING -o ptm0.832 -p igmp -j CLASSIFY --set-class 0000:0006
iptables -t mangle -A POSTROUTING -o ptm0.832 -p icmp -j CLASSIFY --set-class 0000:0006
iptables -t mangle -A POSTROUTING -o ptm0.832 -p udp --dport 67 -j CLASSIFY --set-class 0000:0006
tu peux les mettre dans le même fichier si tu veux, pour commencer. ensuite il faudra faire en sorte que le routeur exécute le fichier au démarrage.
PS:
remplacer ptm0 par eth1 ;)
En cas de problème ou d'erreur, il faut vérifier que les packages ip-full et iptables-mod-ipopt soient bien installés.
-
l'histoire des priorité et cos est indiqué plus bas dans mon post:
https://lafibre.info/remplacer-livebox/remplacement-de-la-livebox-par-un-routeur-lede-fork-dopenwrt/msg471749/#msg471749
création du fichier /etc/vlanprio.sh qu'on n'oublie pas de rendre exécutable avec un chmod 755
#!/bin/sh
set -x
for i in 0 1 2 3 4 5 6 7; do
## on définit pour chaque file une priorité
ip link set ptm0.832 type vlan egress $i:$i >/dev/null
ip link set ptm0.838 type vlan egress $i:4 >/dev/null
ip link set ptm0.840 type vlan egress $i:5 >/dev/null
done
ip link set ptm0.832 type vlan egress 1:0 >/dev/null
ip link set ptm0.832 type vlan egress 0:6 >/dev/null
ensuite les regles Firewal a ajouter:
iptables -t mangle -A POSTROUTING -o ptm0.832 -j CLASSIFY --set-class 0000:0001
iptables -t mangle -A POSTROUTING -o ptm0.832 -p igmp -j CLASSIFY --set-class 0000:0006
iptables -t mangle -A POSTROUTING -o ptm0.832 -p icmp -j CLASSIFY --set-class 0000:0006
iptables -t mangle -A POSTROUTING -o ptm0.832 -p udp --dport 67 -j CLASSIFY --set-class 0000:0006
tu peux les mettre dans le même fichier si tu veux, pour commencer. ensuite il faudra faire en sorte que le routeur exécute le fichier au démarrage.
PS:
remplacer ptm0 par eth1 ;)
En cas de problème ou d'erreur, il faut vérifier que les packages ip-full et iptables-mod-ipopt soient bien installés.
Merci pour les infos mais ça ne marche pas :( iptables ne veut pas le paramètre --set-class et quand je vérifie aussi bien la liste des packages installés que de ceux disponibles j'ai aucun package ip-full et iptables-mod-ipopt :( Que faire ? :(
-
pourtant moi je les vois bien les packages, je ne sais pas si je suis dans la bonne branche mais je vois :
https://api.turris.cz/openwrt-repo/omnia-stable/packages/base/
iptables-mod-ipopt_1.4.21-3_mvebu.ipk
ip-full_4.0.0-4_mvebu.ipk
Tu as fait un opkg update pour mettre à jour la liste ?
-
pourtant moi je les vois bien les packages, je ne sais pas si je suis dans la bonne branche mais je vois :
https://api.turris.cz/openwrt-repo/omnia-stable/packages/base/
iptables-mod-ipopt_1.4.21-3_mvebu.ipk
ip-full_4.0.0-4_mvebu.ipk
Tu as fait un opkg update pour mettre à jour la liste ?
Autant pour moi je pensais qu'il gardait quand même la liste des packages en cache une fois fait une mise à jour de l'OS mais visiblement non :'( et du coup maintenant ça veut dire qu'il faut que je le resette une fois de plus pour pouvoir le remettre en DHCP sur mon LAN et qu'il ait un accès Internet pour mettre à jour et installer les packages nécessaires (j'ai tenté l'install manuelle mais c'est un enfer avec les dépendances de package !!
En tout cas merci pour toutes les infos mais je crois que je vais laisser tomber pour le moment vu le côté expérimental et instable de la chose :-[
-
Bon me revoilà avec ma galère boulet :( Je suis donc reparti de zéro ce matin et j'ai fait tout ça pour obtenir un résultat de merde :(
-> Remise à zéro du Turris Omnia
-> Connection à l'interface Web et changement de l'IP LAN (10.0.1.1) au lieu du 192.168.1.X1 en conflit avec mon réseau local et mise en DHCP du WAN
-> Connection WAN Turris à mon LAN afin de donner de l'accès Internet au Turris.
-> Exécution des mises à jour et installation des paquets iptables-mod-ipopt et ip-full
-> Réalisation des manips donnés dans ce poste https://lafibre.info/remplacer-livebox/remplacement-de-la-livebox-par-un-routeur-lede-fork-dopenwrt/msg471749/#msg471749 en remplaçant ptm0 par eth1 (puisqu'à priori eth1 est le port WAN sur le Turris Omnia). J'ai pas fait les modifs Replay et TV puisque ça me concerne pas et j'ai mis mon identifiant fti correctement encodé.
-> Reboot du Turris avec le port WAN connecté à l'ONT et mon ordi toujours en LAN).
-> Le port WAN clignote comme un taré mais la connection monte pas (mon ordi n'a pas d'accès au Net) et impossible de me reconnecter au Turris (aussi bien sur l'interface Web simple, Luci ou en SSH) pourtant mon ordi récupère bien une IP du DHCP du turris !!
Je sais plus trop quoi faire là pour un truc qui était censé marcher selon les tutoriaux postés ici!!!!
Merci si vous avez des idées....
-
tu n'as pas de log qui pourrait nous aiguiller ? parce que là comme ça je ne vois pas...Sur 4 équipements totalement différents je fais la même chose et ça marche...
1 Modem VDDSL Draytek 2860 avec DrayOS
1 Modem VDSL BT Home HUB 5A avec LEDE
1 Modem Huawei HG612 en Bridge + Routeur APU2C4 Avec LEDE
1 Modem DGA4130 Avec Openwrt "Chaos Calmer"
-
Bonjour,
je voudrais aussi remplacer ma livebox par un omnia, mais je n'ai pas de ONT on m'a relié à la livebox avec le SFP ONT Sercomm FGS202.
je voudrais utiliser un SFP compatible avec le omnia, j'ai lu que le plus simple est de passer avec le MC220L, mais savez vous si orange
récupère le SFP si l'on rend la livebox?
Si cela intéresse quelqu'un, j'ai fais un dump de 2 SFP sercomm, un vierge jamais activé avec livebox et l'autre activé (SLID entré) en fin je crois...
dump vierge:
https://mega.nz/#!ed4XUBrS!DgIX60oUBPvt-Sa1sEvFNJtAstHsNlz2-zYY-gZUzOA
dump avec ID:
https://mega.nz/#!DVQFwSbJ!WBoJAYjGIX4UZAFIL_UYiHC6VZdSJWJkXP-Q5fWq8ic
le dump à été effectué avec un minipro sur la flash/eeprom MX25L6435E du SFP.
j'espère que cela peut aider.
Cordialement.
-
tu n'as pas de log qui pourrait nous aiguiller ? parce que là comme ça je ne vois pas...Sur 4 équipements totalement différents je fais la même chose et ça marche...
1 Modem VDDSL Draytek 2860 avec DrayOS
1 Modem VDSL BT Home HUB 5A avec LEDE
1 Modem Huawei HG612 en Bridge + Routeur APU2C4 Avec LEDE
1 Modem DGA4130 Avec Openwrt "Chaos Calmer"
Ça y est j'y suis arrivé ;D J'ai tout remis à zéro dans l'Omnis en le réinstallant avec la dernière image et une clé USB !! Ensuite j'ai suivi toutes les étapes et la connection monte bien et tourne d'ailleurs déja nettement mieux qu'avec le truc qui se fait appeler box :D
Par contre si je veux ouvrir des ports je fais comment ? Je peux le faire de façon classique par l'interface web ? ou en ligne de commande uniquement sur le vlan 832 ??
Si j'ai le temps j'essayerais de faire un petit tuto spécial Turris Omnia et encore merci pour l'aide ;)
Vincèn
-
Petite mise à jour: le package ip-full est totalement inutile car le package ip fait partie des paquets standards et contient exactement la même chose que le paquet ip-full qui va être mis au rebut !
-
Pas sur LEDE en tout cas...On était en 17.0.1 quand j'ai fait le tuto.
voir le problème que j'ai eu: https://lafibre.info/remplacer-livebox/remplacement-de-la-livebox-par-un-routeur-lede-fork-dopenwrt/msg471603/#msg471603
sans IP-FULL ca ne marchait pas...
-
Pas sur LEDE en tout cas...On était en 17.0.1 quand j'ai fait le tuto.
voir le problème que j'ai eu: https://lafibre.info/remplacer-livebox/remplacement-de-la-livebox-par-un-routeur-lede-fork-dopenwrt/msg471603/#msg471603
sans IP-FULL ca ne marchait pas...
Petite question à 2 balles car je me suis fait avoir par ça au début sur Turris Omnia. En fait les 2 packages IP et IP-FULL contiennent les mêmes fichiers et le gestionnaire de paquets ne vérifient pas ce recoupement ! Du coup si tu désinstalles le paquet ip-full, de fait tu enlèves le paquet ip aussi même si le système te dit que le paquet est toujours installé les fichiers ne sont plus là ! Sur le mien j'ai dû désinstaller ip-full et ensuite forcer une réinstall du paquet ip et c'était tout bon au reboot !!
-
J'ai tenté un remplacement à base de Turris ces derniers temps, globalement ça marche en adaptant un peu la config openwrt. J'ai eu un petit soucis avec le script de priorité de vlan, car le PATH était différent sur rc.local et il executait les commandes ip avec la version busybox à /sbin/ip qui ne supporte pas l'argument type.
2019-02-21 12:25:45 emerg kresd[2278]: + ip link set eth1.832 type vlan egress 0:0
2019-02-21 12:25:45 emerg kresd[2278]: ip: either "dev" is duplicate, or "type" is garbage
En appelant /usr/sbin/ip, ça passe sans problème.
J'ai aussi voulu coller ce script dans /etc/hotplug.d/iface pour qu'il soit executé automatiquement au link up au lieu d'une référence explicite dans rc.local, mais là par contre pas moyen. J'ai même collé un appel à logger au tout début pour voir, mais rien à faire, il semble complètement ignorer le script. Que ça soit au boot ou plus tard en débranchant/rebranchant le câble Ethernet WAN du routeur.
Dans l'absolu c'est pas vraiment un problème vu que rc.local fait le boulot au boot, mais je serais curieux de savoir si quelqu'un de plus calé en Turris/OpenWRT aurait une idée.
Le script réside à /etc/hotplug.d/iface/05-vlanprio et ressemble à ça:
#!/bin/sh
set -x
logger -t vlanprio "$ACTION on $INTERFACE detected"
for i in 0 1 2 3 4 5 6 7; do
## on définit pour chaque file une priorité
/usr/sbin/ip link set eth1.832 type vlan egress $i:$i >/dev/null
done
/usr/sbin/ip link set eth1.832 type vlan egress 1:0 >/dev/null
/usr/sbin/ip link set eth1.832 type vlan egress 0:6 >/dev/null
-
Bonjour,
ayant souscrit à une offre Sosh la semaine dernière, je commence à regarder comment paramétrer mon Turris Omnia en TOS 4.0.3.
Le paquet ip-full reste obligatoire, avec un petit changement à priori :
le binaire est /sbin/ip-full. Sauf que quand on le lance, on a un joli message d'erreur
Object "-full" is unknown, try "ip help".
La solution que j'ai trouvé est de faire un symlink vers /usr/sbin/ip, et là ça fonctionne.
Maintenant, il me reste à déterminer si le fait de créer un fichier /etc/hotplug.d/iface/05-vlanprio fonctionne toujours.
je posterai mes trouvailles ici.
-
à priori, il y'a un bug sur le script /sbin/hotplug-call
#!/bin/sh
# Copyright (C) 2006-2016 OpenWrt.org
export HOTPLUG_TYPE="$1"
. /lib/functions.sh
PATH="/usr/sbin:/usr/bin:/sbin:/bin"
LOGNAME=root
USER=root
export PATH LOGNAME USER
export DEVICENAME="${DEVPATH##*/}"
[ \! -z "$1" -a -d /etc/hotplug.d/$1 ] && {
for script in $(ls /etc/hotplug.d/$1/* 2>&-); do (
if [ -f "$script" ]; then
[ -x $script ] && $script || . $script
fi
); done
}
La ligne
[ -x $script ] && $script || . $script
fait que le script python /etc/hotplug.d/dhcp/99-dhcp_host_domain_ng.py est exécuté comme un script shell et non comme un script python.
En enlevant le . après || ça marche.
A voir si ça survit à une mise à jour de firmware.
EDIT tardif : c'est d'ailleurs assez étrange parce que le script en question est bien exécutable donc il devrait pas être interprété de la sorte ...
-
Bonjour à tous,
J'ai récemment acheté l'Omnia Turris 2020 pour me connecter avec la fibre de Sosh.
Est-il possible d'avoir un tuto à jour pour configurer l'Omnia ?
D'ailleurs en branchant le SFP j'ai ce message d'erreur dans dmesg
[ 1453.111437] sfp sfp: failed to read EEPROM: -6
-
Personne pour aider ?? :'(