Forum ORANGE Migration

La version d'Aria2 dont on dispose (pour le moment) a été compilée sans le support des Torrents...

Heureusement il y a Transmission, que certains connaissent déjà, et qui dispose aussi d'une interface web pour faciliter son utilisation.

Pour utiliser Transmission il nous faut installer ces 3 packages:

opkg install http://brcm63xx-tch.ddns.net/base/libevent2_2.0.22-1_brcm63xx-tch.ipk
opkg install http://brcm63xx-tch.ddns.net/packages/transmission-daemon_2.84-3_brcm63xx-tch.ipk
opkg install http://brcm63xx-tch.ddns.net/packages/transmission-web_2.84-3_brcm63xx-tch.ipk

Puis on va dans le fichier : /etc/config/transmission
et on met set option enabled 1

On indique aussi le chemin du dossier où seront téléchargés les fichiers. Ici il faut indiquer une clé usb, l'espace de stockage interne du modem n'étant pas suffisant.

option download_dir '/mnt/usb/USB-A1/done'
option incomplete_dir '/mnt/usb/USB-A1/incomplete'

Port usb 1 = /mnt/usb/USB-A1
port usb 2 = /mnt/usb/USB-A2

Une fois paramétré, il suffit de démarrer le Daemon/service Transmission :

/etc/init.d/transmission start

Pour accéder à l'interface web: http://192.168.1.1:9091

et voilà

Pour arreter le service/daemon Transmission:

/etc/init.d/transmission stop

Pour désinstaller Transmission:

opkg remove transmission-web
opkg remove transmission-daemon
opkg remove libevent2

Dernière modification par shdf (15-10-2017 13:59:14)

Bonjour.

A propos de "igmpproxy", je vois cette séquence temporelle dans mes logs au moment de l’attribution de l’adresse IP :

1) daemon.notice igmpproxy[4455]: Address XXX.XXX.XXX.XXX/255.255.255.255 created on intf pppoe-wan
2) daemon.notice igmpproxy[4455]: Intf pppoe-wan up
3) daemon.notice netifd: Network device 'pppoe-wan' link is up
4) daemon.notice pppd[30379]: local IP address XXX.XXX.XXX.XXX

Donc peut-être il faudrait encore un peu d’essais et d’analyse avant de décréter inutile le service igmpproxy pour ceux qui n’ont pas de TV.

Prudence, surtout si on n’enregistre pas (et si on n’analyse pas) tous les messages du syslog en 24/7.

Oui, mais le test "sans igmpproxy" il faut le faire sur une longue durée avec l'enregistrement des logs en continu.

Ce que je vois c’est probablement seulement une annonce passive par le igmpproxy qui dit "Je vois que le pppoe est là, ça roule pour moi".

Mon post était une mise en garde.

Enregistrer les logs en continu dans un fichier sur une clé USB est possible, puis on le déplace pour l’analyse sur un disque à 1 TB de capacité.

Le test du pppoa, ce sera pour plus tard, j’ai d’autres chats à fouetter…

En passant de pppoa à pppoe le rapport débit IP/débit ATM passe de 0,88 à 0,86, donc peanuts (quoique, mieux les avoir que les perdre…)

Mais j’y arriverai à essayer le pppoa.

Autre choses qu’il faudra tester en futur : l’arrêt du cwmpd.

Chez toi la mise à jour automatique de l’horaire via ntpd marche bien ?

Dernière modification par sambapati (19-10-2017 13:20:45)

Bonjour.

Encore une petite mise en garde, plus critique celle-là.

shdf a écrit:

.... Du coup je me demande si je vais conserver les webui buggée..la 2.23 je suis sur qu'elle est stable et correcte.

Moi aussi j'espérais que la 2.23 était stable et correcte.

Mais apparemment la webui 2.23 a aussi un bug, comme déjà indiqué dans le post no. 1440 par ElDavo du 25 septembre à 15h44 ici https://www.ilpuntotecnicoeadsl.com/for … 77325.1440 .

Modifier le "domain" depuis la webui tue(/rait ?) le service dnsmasq, donc adieu connectivité web.

Et on n’arrive pas à le redémarrer avec /etc/init.d/dnsmasq start (ni avec …/dnsmasq restart). On a toujours ce message de niveau critique dans les logs, indiqué par ElDavo:

daemon.crit dnsmasq[6528]: failed to bind DHCP server socket: Address already in use
daemon.crit dnsmasq[6528]: FAILED to start up
daemon.info procd: Instance dnsmasq::cfg02411c s in a crash loop 6 crashes, 0 seconds since last crash

Mais modifier le "domain" avec la uci ne donnerait aucun problème selon ElDavo (à re-vérifier).

Je pense que c’est un bug, celui du dnsmasq de mon post précédent, introduit avec la webui 2.23; donc relancer le unlocker, qui installe la webui 2.10, pourrait résoudre le problème.

Lancer l’unlocker n’a pas résolu la situation. Il ne reste qu’un reset d’usine, pour arriver à avoir une webui 2.23 qui marche, et encore pas si sûr.

L’avancement vers la webui 3.16 se fera plus tard, pour le moment c’est la 2.23 que je veux avoir en état de marche.

Oui, merci pour tout ton aide, ça fait du bien.

Ah, j’avais relu jusqu’à page 110 en deuxième (ou n-ème) relecture.

Je suis d’accord avec toi 100%. C’est pour ça que je veux avoir la webui 2.23 en marche aussi sur mon 2ème dga, qui doit servir comme backup et test de tout ce qu’on va nous balancer.

Et il a fait son boulot le pauvre.

Tu vois pourquoi je veux une 2.23 au lieu d’une 3.16 pour le moment ? Ce sera une base commune pour les deux.

Maintenant après un reset d’usine je suis sur la 2.10 correctement et je vais tout refaire. J’ai un log continu en arrière-plan qui enregistre sur fichier tous les messages du système.

J’ai deux instances du dnsmaq (ps -w | grep dns) qui roulent et c’est normal. Avec "pidof dnsmasq" on trouve les deux pid (aussi présents dans la 1ère colonne de l’output d’un ps -w). Utile pour l'ârret avec un "kill -9 pid-du-programme"

Je vais changer le domain dans la webui et on va voir si ça tue le dnsmasq.

On va aussi voir l'effet sur le fichier /tmp/dhcp.leases. Maintenant il est ok, il y a les données des leases pour ordis et l'AP du tim.

Avant, avec le dnsmasq mort, le fichier dhcp.leases était vide. Un autre effet était pas de nslookup.

Tout cela m’a aussi permis de tester le reset d’usine, ce qui est aussi une bonne chose pour le futur.

Dernière modification par sambapati (20-10-2017 17:54:32)

Patience shdf, la 3.16 on y arrivera.

Donc tout marche ok après le changement du "domain name" depuis la webui 2.10.

Il y bien une erreur sur odhcpd dans les logs (Failed to open DHCPv4 server socket : Address already in use), puis dnsmasq s’arrête sur réception d’un signal SIGTERM. Mais odhcpd ne s’arrête pas.

Mais puis dnsmasq repart tout de suite et ne s’arrête plus. En fait le fichier /tmp/dhcp.leases est toujours plein ok, nslookup et ping marchent bien en ssh depuis le dga vers le nom de l’ordinateur.

Tout est ok, c’est la vers 2.23 du 23 septembre 2017 qui a introduit d’autres problèmes.

Je peux passer à la version 2.23, en principe.

tout ca c'est à faire que lorsqu'on change le nom du modem ? sinon c'est pas nécessaire, si ?
/etc/init.d/odhcpd disable fait qu'il ne redémarrera plus par la suite. Donc plus d'ipv6, on est bien d'accord ?

Pour info, depuis la version 3.2 il y a dans /etc/init.d/rootdevice

transfer_bank() {
    if [ -d /overlay/bank_1 ]
    then
        rm -r /overlay/bank_1
    fi
    mkdir /overlay/bank_1
    cp -r /overlay/bank_2/* /overlay/bank_1
    if [ -f /overlay/bank_1/etc/init.d/rootdevice ]
        then
        mtd erase /dev/mtd3
        mtd write /dev/mtd4 /dev/mtd3
    fi
    activeversion=$( cat /proc/banktable/activeversion )
    passiveversion=$( cat /proc/banktable/passiveversion )
   
    if [ "$activeversion" == "$passiveversion" ]
        then
        echo bank_1 > /proc/banktable/active
        reboot
    fi
}

check_bank() {
    bank_check=$( uci -q get env.var.bank_check )
    bootedbank=$( cat /proc/banktable/booted )
    if [ ! $bank_check ]
    then
        uci set env.var.bank_check="1"
    fi
    if [ $bootedbank == "bank_2" ] && [ $bank_check == "1" ]
    then
        transfer_bank
    else
        echo "  Firmware in Bank_1... Not transfering..." > /dev/console
    fi
}

Le contenu de bank2 est dupliqué sur la bank1, et bank1 devient la bank active.
Mettre la bank1 active permet en cas de catastrophe de rattraper le coup par TFTPD.
Si j'ai bien compris un flash par TFTPD va toujours se faire sur la bank1, donc si elle n'est pas active c'est foutu car ca bootera sur la bank2.

Je te mets le changelog depuis la version 3.0

3.16 Rimosso aggiornamento adsl e cwmpd...
3.15 Possibile fix tod wireless
3.14 Fix card_limiter
3.13 Fix per user non telecom
3.12 Miglioramento script root e aggiunte alcune traduzioni
3.11 Disabilitato daemon ipv6, per ora è comunque buggato e rotto
3.10 Bottone Bridge Fixato @Pigr8. Opkg quasi funzionante, provare ad installare i pacchetti e segnalare quali funzionanti.
3.9 Fixato telnet e pagina password
3.8 Fixato problema aggiornamento convertito in reset... (causato da un mio errore per aver introdotto script nel posto sbagliato)
3.7 Probabile fix al bug del dns
3.6 Aggiunto switch per disattivare check bank_1 (Funzioni Avanzate)
3.5 Fixato bug password
3.4 Refactor platform.sh e script di root per l'upgrade della versione
3.3 Aggiornato driver xDSL
3.2 Tutti in bank_1, inserito check in boot per forzare tutti lì
3.1 Tab DHCP fixata
3.0 Merge cambiamenti da AGTEF_1.0.4_007

Dernière modification par shdf (20-10-2017 23:07:00)

sambapati a écrit:

Pour info, le DGA est aussi accessible par le nom générique "dsldevice".

Ha oui, je viens de tester effectivement, et je retombe sur un truc que j'avais deja notifié sur le forum italien. un ping vers le modem/router donne une latence >=1ms, idem dans le sens modem vers PC ou c'est encore plus clair car on voit les décimales.
Normalement meme un vieux routeur 100Mbps, fait moins que 1ms...on m'a dit que ce n'était pas un problème...certe, mais parfois c'est l'arbre qui cache la forêt..

sambapati a écrit:

Maintenant c'est bien le dhcp-dnsmasq qui s'occupe de tout (avant, avec le bug, c'était le service odhcpd qui s'en chargeait d'où un dns cassé et perte de connectivité lan et web).

j'ai effectivement été victime de ce bug tout au début, et croyait l'avoir réglé en bidouillant dans le /etc/config/network...coincidence peut-etre.

sambapati a écrit:

La question maintenant est si on peut passer directement de la version 2.23 à la 3.16 sans tout casser.

Alors je l'ai fait après avoir flashé le firmware 1.0.4, unlock avec gui 2.1 (qui était inutile car le root était toujours présent), puis je suis passé en 2.23 puis en 3.9
puis retour au Firmware 1.0.3, et direct à la GUI 3.9 en ligne de commande.

Bonjour,
En SSH, pour voir exactement ce que fait le script rootdevice, tu peux enlever du fichier les " > /dev/console" avant de l'exécuter. Ca permet de bien voir les messages en sortie.

Au final, ta synchro est-elle meilleure ou identique à ta box précédente ? quelle livebox as-tu ?

tu as 3 lignes DSL ?