[Thread Ufficiale] TP-Link TD-W8970v1 - Firmware OpenWRT

[michelinodj]

Buongiorno, dopo aver tentato di resettare il router e non esserci riuscito ho provato a riflasharlo secondo la guida. Però

[matteo85]

Originariamente inviato da Giox040

Quindi Override MTU in WAN lascio 1500

Cos'e' nas0-8? 1492 dove va impostato?


Grazie...abbi pazienza.

nas0 è l'interfaccia ATM con incapsulamento AAL5, è da lì che passano i dati del PPP.
È una ethernet virtuale (Ethernet over ATM) e quindi deve stare a 1500

[avware]

Originariamente inviato da Totix92

ho scaricato i sorgenti della r47623 e ho scaricato la r47665
allora ho tolto dalla 47665 le patch incriminate e copiato le patch che erano state tolte dalla 47665 copiandole dalla 47623
risultato fa il boot e parte

mi sa comunque che prenderò un dgn3500 usato e gli monto openwrt oppure qualche altra alternativa sempre con VRX268/288 ma che non sia tp-link, sull'8970 mi sembra ancora un po' acerbo per i miei gusti, ogni tanto ho dei tx eth0 full ring o qualcosa del genere e rallenta tutto.

Io sono passato da un dgn3500 a questo router perché imputavo i "tx ring full" (del dgn3500) all'hardware poco performante. Addirittura sui chan irc del kernel m'hanno detto che la causa era che il chipset faceva cagare. In realtà quel problema riguarda la componente switch del chipset lantiq che viene pilotata male da openwrt a causa del fatto che non esiste ancora un driver nativo ma solo init di default attraverso interfaccia GMIIO. Tutti i dispositivi lantiq con montato openwrt hanno questo problema. Vi confermo comunque che la principale causa di quel "tx ring full" è minidlna.. smuove troppi dati tutti insieme e la coda dell'interfaccia si esaurisce.

[Shamrogue]

Originariamente inviato da matteo85

beh l'interprete python su MIPS, vorrei vedere...

Purtroppo la CLI di AWS usa python.
Forse potrei provare ad eseguirli con un utente dedicato e abbassare la priorità di esecuzione...

[Totix92]

boh, ho compilato la r47670... tutto ok tranne la connessione... non ne vuole proprio sapere di connettersi c'è la portante ma niente ip, in PPPoA pppd dice: No such device"
e in PPPoE: "Timeout for PADO Packets"
e ora addirittura senza che ho fatto nulla non si avvia più proprio pppd e non tenta nemmeno di connettersi
ritorno alla r47249...

[hitech95]

Originariamente inviato da avware

Io sono passato da un dgn3500 a questo router perché imputavo i "tx ring full" (del dgn3500) all'hardware poco performante. Addirittura sui chan irc del kernel m'hanno detto che la causa era che il chipset faceva cagare. In realtà quel problema riguarda la componente switch del chipset lantiq che viene pilotata male da openwrt a causa del fatto che non esiste ancora un driver nativo ma solo init di default attraverso interfaccia GMIIO. Tutti i dispositivi lantiq con montato openwrt hanno questo problema. Vi confermo comunque che la principale causa di quel "tx ring full" è minidlna.. smuove troppi dati tutti insieme e la coda dell'interfaccia si esaurisce.

Il DGN3500 non ha uno switch Lantiq ma Realtek. Semmai è il driver Ethernet che è fatto male. O almeno noi lo "crediamo", scommetto che anche il driver atheros droppa ma senza l'output...
Ah il DGN3500 butta fuori quel errore quando passano tanti dati sulla lan del SoC.

@matteo85, domanda non capisco la tua patch imposta un driver diverso per la Ethernet e la SPI? Non capisco.

[avware]

Originariamente inviato da hitech95

Il DGN3500 non ha uno switch Lantiq ma Realtek. Semmai è il driver Ethernet che è fatto male. O almeno noi lo "crediamo", scommetto che anche il driver atheros droppa ma senza l'output...
Ah il DGN3500 butta fuori quel errore quando passano tanti dati sulla lan del SoC.

@matteo85, domanda non capisco la tua patch imposta un driver diverso per la Ethernet e la SPI? Non capisco.

Non so, forse ci vai di fino coi termini perché vuoi metter mano al driver, in quel caso benvenuto. Ad ogni modo il problema è presente su quasi tutti i router che adottano la piattaforma Lantiq (scrivo "quasi tutti" perché non li ho provati tutti, so ad esempio che lo stesso problema ce l'ha anche un modello lantiq della Buffalo che esce nativamente con openwrt, non conosco altri modelli esclusi i Fritz); da wikidevi:

Netgear Dgn3500:
ETH chip1: Infineon XWAY™ ARX168 (PSB 50810 EL V1.2)
Switch: Realtek RTL8366RB

Tplink TD-w8970:
ETH chip1: Lantiq XWAY™ VRX268 (PSB 80910 EL V1.2)
ETH chip2: Lantiq PEF7071V
ETH chip3: Lantiq PEF7071V
Switch: Lantiq XWAY™ VRX268 (PSB 80910 EL V1.2)

[hitech95]

Originariamente inviato da avware

Non so, forse ci vai di fino coi termini perché vuoi metter mano al driver, in quel caso benvenuto. Ad ogni modo il problema è presente su quasi tutti i router che adottano la piattaforma Lantiq (scrivo "quasi tutti" perché non li ho provati tutti, so ad esempio che lo stesso problema ce l'ha anche un modello lantiq della Buffalo che esce nativamente con openwrt, non conosco altri modelli esclusi i Fritz); da wikidevi:

Netgear Dgn3500:
ETH chip1: Infineon XWAY™ ARX168 (PSB 50810 EL V1.2)
Switch: Realtek RTL8366RB

Tplink TD-w8970:
ETH chip1: Lantiq XWAY™ VRX268 (PSB 80910 EL V1.2)
ETH chip2: Lantiq PEF7071V
ETH chip3: Lantiq PEF7071V
Switch: Lantiq XWAY™ VRX268 (PSB 80910 EL V1.2)

Come hai notato entrambi i router hanno lo "stesso" "problema": Quando c'è molto traffico questo viene "droppato" per liberare il buffer della ethernet e viene quindi re-inviato.
Sarebbe da capire che diavolo fa il driver di openwrt di diverso da quello originale Lantiq; Ho notato che quello openwrt utilizza dei file binari cosa che quello originale non sembra avere.

Mi piacerebbe sistemare il driver ma attualmente ho un problema: Non so come lavora il kernel linux, ci sono un sacco di chiavate ad esso che non so a cosa servono, come funzionano cosa restituiscono. Inoltre capire cosa passa nella testa delle altre persone è difficile. Ci vorrebbero i datasheet... ma è tutto sotto DNA. Speriamo che Latinq faccia la stessa cosa che ha fatto con l'adsl: rilasciare i driver.

Ancora non capisco, non potrebbero fare un bel driver di linea in PCI-e? Così uno mette il Soc che vuole e si risolvono infiniti problemi?

Booh.

[Totix92]

il DGN3500 però non ha il problema che ha il tp-link che i dati passano in tutte le porte...
mah... spero che Lantiq rilasci anche i driver ethernet e i driver dello switch...

[hitech95]

Originariamente inviato da Totix92

il DGN3500 però non ha il problema che ha il tp-link che i dati passano in tutte le porte...
mah... spero che Lantiq rilasci anche i driver ethernet e i driver dello switch...

Bah io ho rinunciato allo switch programmabile e ho uno switch "stupido" ma almeno così funziona.

[matteo85]

Tutti i drivers di rete droppano pacchetti quando la coda si riempie, se proprio vi da fastidio quell'errore commentate la stampa..

[Herbie_53]

"Se non puoi sconfiggere il tuo nemico, fattelo amico."
Sto facendo così con la vodafone station... non riuscendo a toglierla di mezzo per colpa del voip, sto cercando di usare la sua porta wan.
Sono riuscito a comunicare con il server remoto mettendo il tp-link prima della vsr

VSR PORTA WAN-> TP-LINK -> DOPPINO

ma ora penso di essere ad un vicolo cieco.
In pratica la vsr manda i pacchetti PADI alla porta wan. Ho creato un bridge unmanaged tra eth0 (non una VLAN, tutta l'interfaccia), eth0.3 (la porta corrispondente alla VLAN dove è connessa la VSR) e ptm0, così i pacchetti PADI passano tramite eth0.3, eth0 ed arrivano a ptm0. Tuttavia quando il server risponde con il PADO, li vedo su ptm0 e su eth0, ma non su eth0.3. Penso sia un problema di instradamento dei pacchetti.

PADI:
PADI -> ETH0.3 -> ETH0 -> PTM0 -> OK

PADO:
PADO -> PTM0 -> ETH0 ? ETH0.3  = Non lo trovo su eth0.3

Leggendo in giro ho scoperto che per fare il "PPPoE Pass Through"
si usa pppoe-relay per poter fare appunto il relay dei pacchetti, ma sembra non esserci più tra i packages di openwrt e soprattutto non trovo una alternativa!
Qualcuno ha una idea su come andare avanti?
In teoria una volta superato questo ultimo scoglio, potremmo aver raggiunto lo scenario migliore (secondo me): la parte vdsl viene gestita dal tp-link, mentre la parte voce dalla vsr, senza dover sbattere la testa su asterisk e compagnia bella!

[Totix92]

Originariamente inviato da matteo85

Tutti i drivers di rete droppano pacchetti quando la coda si riempie, se proprio vi da fastidio quell'errore commentate la stampa..

quindi vuol dire che lo fa anche il fimrware originale ed è normale?
e per quanto i dati che vengono duplicati su tutte le porte lan si può fare qualcosa?

[hitech95]

Originariamente inviato da Totix92

quindi vuol dire che lo fa anche il fimrware originale ed è normale?
e per quanto i dati che vengono duplicati su tutte le porte lan si può fare qualcosa?

Avevo ragione.
Per il fatto che i frame vengan inviati a tutte le ethernet si possono fare diverse cose:
1) portare il driver originale
2) sistemare il driver attuale
3) fare una stupida patch che elimina la possibilità di fare vlan ma che almeno non intasa tutta la rete: #define SW_PORTMAP va tolta dal driver.

Originariamente inviato da hitech95

@matteo85, domanda non capisco la tua patch imposta un driver diverso per la Ethernet e la SPI? Non capisco.

Qualcuno sa rispondermi? Il devicetree usa l'altro driver. Non capisco come possa funzionare.

[xsiriusx]

Originariamente inviato da matteo85

Ma che procedura complicata!
Se colleghi il lato sinistro della resistenza R225 a massa

poi puoi inviare un bootloader via seriale con:

cat u-boot.asc > /dev/ttyUSB0

Ottimo buono a sapersi! anche se servirebbe il file .asc del bootloader!

Comunque Ho un problema Matteo85 che non riesco a spiegarmi: in pratica non mi si collega più con winscp con protocollo sftp da qualsiasi computer non mi fa più entrare, però il collegameto SSH funziona bene, con winscp mi collego con ftp! provato di tutto ma non ho una soluzione anche cambiando firmware. provato da console a dare reboot -f ma cmq non si risolve, provato a caricare firmware originale e dopo rimettere openwrt ma continua a non andare!


@totix92 quindi per le ultime trunk il problema se non ho capito male era la patch 090 sotto target/linux/generic/patches-4.1?

[Totix92]

@xsiriusx
no, il problema era causato da diverse patch sotto target/linux/generic/patches-4.1 e alcune anche su target/linux/lantiq/patches-4.1
sono coinvolte almeno 5/6 patch

[avware]

Originariamente inviato da matteo85

Tutti i drivers di rete droppano pacchetti quando la coda si riempie, se proprio vi da fastidio quell'errore commentate la stampa..

Originariamente inviato da Totix92

quindi vuol dire che lo fa anche il firmware originale ?

Ottima domanda.

Originariamente inviato da Totix92

ed è normale?

Non credo troveremo una risposta esauriente qui.

Originariamente inviato da Totix92

e per quanto i dati che vengono duplicati su tutte le porte lan si può fare qualcosa?

Anche io per risolvere (spero temporaneamente) ho messo in cascata uno switch tplink gigabit. Il tx ring full comunque è rimasto.

@hitech95: in effetti una #undef SW_PORTMAP mi consentirebbe di togliere lo switch in cascata

[avware]

Originariamente inviato da hitech95

3) fare una stupida patch che elimina la possibilità di fare vlan ma che almeno non intasa tutta la rete: #define SW_PORTMAP va tolta dal driver.

Originariamente inviato da avware

@hitech95: in effetti una #undef SW_PORTMAP mi consentirebbe di togliere lo switch in cascata

Confermo, senza SW_PORTMAP il traffico viene routato correttamente.. modifica provata ora su chaos-calmer.

[matteo85]

Winscp?

[hitech95]

Originariamente inviato da avware

Confermo, senza SW_PORTMAP il traffico viene routato correttamente.. modifica provata ora su chaos-calmer.

La uso da mesi, lo avevo scritto anche tempo fa...
Lo switch programmabile si usa in rari casi percò ho deciso di abbandonare l'idea di usarlo e di avere uno switch "semplice" ma funzionante.

Qualcuno aveva detto che avevano fixato il driver: "I led non lampeggiano più tutti assieme dalla rev.xxxx"
Quando ho provato a compilare ho visto che è sorto il problema del mount del fs

Sapete se hanno risolto?