[FrancYescO]

leggi qui e dintorni
https://www.ilpuntotecnico.com/forum/index.php/topic,77325.msg245426.html#msg245426

[LuKePicci]

Se lo metti in bridge su una porta il resto continua a funzionare come previsto. Solo sui router da due soldi con firmware consumer tipo il fritz non puoi tenere funzionanti le due cose in contemporanea.

Ho appena notato che gli hai proposto la cascatona, ma così si spaventa poverino. Per quello che serve a lui basta spostare la porta lan a cui ha attaccato il device in cascata sul bridge wan ed è a posto. Se attualmete lui va di relay allora vuol dire che non gli occorre tenerli entrambi operativi sula stessa subnet, cosa che la cascatona madornale prevedeva.

[LaboDJ]

Intanto grazie per le risposte

Non mi occorre che stiano sulla stessa
subnet, mi occorre che l'hub si colleghi per fornire il VoIP, la possibilità di autoaggiornamento della GUI, la possibilità di installazione delle app (blacklist principalmente) e fornire connettività WiFi di backup in caso il router in cascata (ora Asus ma presto sarà un mikrotik) fosse in manutenzione.

L'unica cosa collegata alle eth è il router in cascata, quindi non mi interessa di "perderne" una

Mi sono letto il link ma ci ho capito poco, non sono molto ferrato sulle configurazioni di openwrt...

Come dovrei configurare il network del 4032 per dedicare una eth al bridge?

È possibile configurarlo per farlo hardware dallo switch e non dalla cpu?

Il file network se lo modifico mantiene la modica al riavvio?

È corretto applicare le nuove impostazioni con service network restart?

Prendetemi per mano siate gentili 

[FrancYescO]

Se a monte hai un'altro router e vuoi dare connessione al TIMHUB ti basta semplicemente configurarlo come Broadband->ETH (va da se che il cavetto sara' da collegare nella porta WAN del TIMHUB) e Internet->DHCP (o statico se non hai il DHCP sul router a monte), l'unica cosa a cui devi prestare attenzione per questo tipo di configurazione è che in "Rete Locale" ci sia una subnet diversa rispetto quella che prendera' tramite DHCP (dal router a monte) ovviamente con questa configurazione tutti i dispositivi collegati al TIMHUB non vedranno quelli del router a monte essendo in subnet diverse, dell'alternativa piu' corretta di questa configurazione (metterli nella stessa subnet e dominio di broadcast) se ne è parlato qui https://www.ilpuntotecnico.com/forum/index.php/topic,81419.msg256092.html#msg256092

ma in ogni caso non sono sicuro che il VOIP di TIM attraversi il NAT che fa il router a monte, l'alternativa un po' piu' "barbara" è fargli stabilire una seconda pppoe tramite pppoe passthrough


il file network si mantiene al riavvio, per riavviare il servizio va bene anche il service restart, o /etc/init.d/network restart

[LuKePicci]

@LaboDJ è molto semplice, cambia le sezioni che hai nel file /etc/config/network come qui di seguito, quello che manca va lasciato come è ora:

Codice: [Seleziona]

config interface 'wan'
option type 'bridge'
[…]
list ifname 'wanptm0' # wanptm0 = modem, waneth4 = ethernet
list ifname 'eth0'

config device 'mgmteth0'
option type '8021q'
option name 'mgmtptm0'
option ifname 'eth0'
option vid '42'
option ipv6 '0'

config interface 'lan'
option type 'bridge'
option proto 'static'
[…]
list ifname 'mgmteth0'
# list ifname 'eth0'
list ifname 'eth1'
list ifname 'eth2'
list ifname 'eth3'
list ifname 'eth5'
Vai semplicemente a definire un bridge lato wan e a spostarci dentro eth0, che è la porta che dovrai usare per il router in cascata. Il risultato è funzionalmente identico al relay, solo che così funziona come cristo comanda-

[MisterFTTH]

così funziona come cristo comanda-

Non ti facevo così veemente 

[LuKePicci]

Magari qualcuno in TIM che legge così capisce che non ci vuole uno scienziato per implementare un funzione di bridging decente.

Su shodan è pieno di router vecchi con firmware non aggiornati esposti in rete. Alcuni di questi sono vulnerabili a qualche antica falla. Ahimè molti di questi sono configurati sfruttando il pppoe relay del router TIM. Ebbene se sfrutti la falla ed entri nel loro vecchio router poi da lì non ci vuole niente, davvero niente, per entrare nel router tim lato lan e fare macelli senza rompere ulteriormente le scatole a quello in cascata. La triste ironia è che il router TIM magari è pure aggiornato e non vulnerabile lato wan.

[LaboDJ]

Se a monte hai un'altro router e vuoi dare connessione al TIMHUB... CUT

Ho un router sotto al Tim Hub non al contrario...

Oggi pomeriggio provo a rimettere la 2.2.0 beta 4 e provo la soluzione di @LuKePicci

[LuKePicci]

Puoi provarla anche sul 2.0.1 , quando eth0 è nel bridge lan il router in cascata passa dal relay, quando eth0 è nel bridge wan il router in cascata raggiunge direttamente il modem/ont.

[LaboDJ]

Finalmente sono venuto a capo di questo problema

Provo la config di @LuKePicci sulla 2.0.1, tutto regolare, navigo correttamente da Asus e da Hub.
Aggiorno alla 2.2.0 beta 4, reset impostazioni, rimetto la gui e metto le stesse config di prima, risultato?
Sull'HUB navigo, sull'Asus no.

Questa storia che qualche pacchetto comunque passa mi puzza, vado a vedere la /etc/config/firewall, troppa roba, poi mi dico "il firewall non è che qualche pacchetto lo fa passare e qualche pacchetto lo droppa" mhh...

Entro nell'asus, cambio i valori di MTU e MRU da 1500 a 1492, BOOM  funziona

Ripristino il file config originale, funziona uguale (in pppoe relay chiaramente e non in bridge)

Il valore di 1500 non lo avevo messo a caso, tempo fa avevo fatto un test di frammentazione del pacchetto e la dimensione massima non frammentata era 1500.

Ora io il mio problema l'ho risolto (sperando non vengano fuori altre rogne), rimarrebbe da capire perché con la 2.0.1 MTU e MRU a 1500 vanno bene e con le successive versioni fanno un casino micidiale, non mi pare tanto normale

EDIT: la situazione è mooooooolto migliorata sull'asus, tuttavia alcuni siti sono irraggiungibili, tipo github.com e bitbucket.org con l'hub riesco ad aprirli, con l'asus no, sto facendo ulteriori prove, vi tengo aggiornati

[flaspc]

Qualcuno può cortesemente controllare se lo switch del DGA4132 è effettivamente capace di lavorare in full-duplex?
Basta fare un iperf -d tra due host attestati sullo stesso bridge (ad esempio porte lan 1 e 2 su configurazioni standard).

Questi i miei risultati sul DGA4132:
[ ID] Interval       Transfer     Bandwidth
[  6]  0.0-10.0 sec   571 MBytes   479 Mbits/sec
[  4]  0.0-10.0 sec   498 MBytes   416 Mbits/sec

e questi su uno switch da 20 EUR:
[  6]  0.0-10.0 sec  1.09 GBytes   934 Mbits/sec
[  4]  0.0-10.0 sec  1.09 GBytes   930 Mbits/sec

[flaspc]

Nessuno?

[FrancYescO]

Ho invalidato un po la prova perche' uno degli host/server era il 4130 stesso, inoltre utilizzavo un adattatore usbc-gigabit (che non sono sicuro abbia le capacita' di raggiungere il gigabit pieno).. ma se ti puo servire a capire qualcosa:


(sembra il server iperf è un servizio di sistema quindi non è valso quel mio iperf -s lanciato sul modem)

[flaspc]

Ti ringrazio per il riscontro.
Purtroppo eseguendo iperf direttamente sul router si falsa il test poichè a quel punto i pacchetti attraversano tutto il network stack e si rischia di essere limitati dalla cpu dello stesso. Io sono interessato alle prestazioni dello switch puro (strato L2).

Inoltre è importante eseguire iperf lato client con il parametro -d in modo da avere traffico in entrambi i sensi e valutare dunque il full-duplex.

In sostanza, se il link è full duplex devo poter inviare a 1Gb/s e ricevere a 1Gb/s contemporaneamente.

Questo avviene con lo switch da 20 EUR, ma non con il DGA4132, che invece dimezza il throughput.

[MisterFTTH]

@FrancYescO quale emulatore di terminale utilizzi?