[Cesarino37]

Grazie Mavelot.

Ho provato a rifare senza indicare l'interfaccia ma solo il gateway; alla fine nella routing table compare anche l'interfaccia, ma questa volta funziona a dovere.

L'altra subnet e il gateway erano già configurati a dovere e funzionavano con il vecchio router... mancava solo lo scolapasta 

[Cesarino37]

Non è vero!!! Oggi non funziona più... dopo avere riacceso il pc, continuo a non vedere l'altra sottorete... più tardi indago meglio. Strano perchè il router non l'ho toccato/spento.
 

[Cesarino37]

Mah... non capisco... l'istruzione sembra giusta, ma alla fine non vedo l'altra sottorete. Facciamo un po' il punto:

- la mia rete principale è 192.168.0.0/24 (192.168.0.255)
- il router ha l'indirizzo 192.168.0.1
- sulla rete c'è un dispositivo di videosorveglianza (192.168.0.101) con 2 schede di rete: una è la mia principale, l'altra è quella dove sono attestate le telecamere, con indirizzo 192.168.1.255 e gestita dal dispositivo
- il dispositivo di videosorveglianza funziona perfettamente, posso collegarmi e manda le immagini sulla mia rete 192.168.0.255
- se però volessi collegarmi alla singola videocamera sulla sottorete 192.168.1.xxx (per motivi di configurazione) non ci si riesce
- avevo un vecchio router Netgear al quale avevo aggiunto una regola di routing statica... per andare su 192.168.1.255 utilizza come gateway il dispositivo di videosorveglianza (192.168.0.101)... niente di più... i pacchetti di ritorno avevano già una route aperta da 192.168.1.255 alla mia rete principale
- ho cercato di fare lo stesso con lo scolapasta... ma nulla da fare

L'istruzione data da telnet è
  ip rtadd dst=192.168.1.0/24 gateway=192.168.0.101 static=enabled status=up metric=1

Perchè non funziona? Dov'è l'errore? 

Qualcuno riesce a darmi una mano? Ansuel... tu che mi sembra conosca questo modem/router come le tue tasche, cosa suggerisci?

[Caterpillar]

Da ignorante, mi pare che x.x.x.255 sia l'indirizzo broadcast del dhcp. Prova a cambiarlo.

[mavelot]

Mah... non capisco... l'istruzione sembra giusta, ma alla fine non vedo l'altra sottorete. Facciamo un po' il punto:

- la mia rete principale è 192.168.0.0/24 (192.168.0.255)
- il router ha l'indirizzo 192.168.0.1
- sulla rete c'è un dispositivo di videosorveglianza (192.168.0.101) con 2 schede di rete: una è la mia principale, l'altra è quella dove sono attestate le telecamere, con indirizzo 192.168.1.255 e gestita dal dispositivo
- il dispositivo di videosorveglianza funziona perfettamente, posso collegarmi e manda le immagini sulla mia rete 192.168.0.255
- se però volessi collegarmi alla singola videocamera sulla sottorete 192.168.1.xxx (per motivi di configurazione) non ci si riesce
- avevo un vecchio router Netgear al quale avevo aggiunto una regola di routing statica... per andare su 192.168.1.255 utilizza come gateway il dispositivo di videosorveglianza (192.168.0.101)... niente di più... i pacchetti di ritorno avevano già una route aperta da 192.168.1.255 alla mia rete principale
- ho cercato di fare lo stesso con lo scolapasta... ma nulla da fare

L'istruzione data da telnet è
  ip rtadd dst=192.168.1.0/24 gateway=192.168.0.101 static=enabled status=up metric=1

Perchè non funziona? Dov'è l'errore? 

Qualcuno riesce a darmi una mano? Ansuel... tu che mi sembra conosca questo modem/router come le tue tasche, cosa suggerisci?

La regola è giusta.
Dal router riesci a pingare quegli IP ?

[Cesarino37]

mmhhh... domanda interessante: sì, se aggiungo la regola sì e se la tolgo invece no... quindi il problema è la porta 80: l'accesso diretto alle videocamere avviene via browser!

Quindi..... ?!? 

[mavelot]

Non ho mai avuto una situazione come questa, ovvero che queste route mi servano per macchine dalla stessa lan. Di solito mi servono "cross" dalla WAN alla LAN.
Mi vengono in mente 2 possibilità:

1) Il NAT "transparent" impostato sulla LAN
2) Il firewall

Proverei per prima cosa a disabilitare il firewall

[toretto_5]

mmhhh... domanda interessante: sì, se aggiungo la regola sì e se la tolgo invece no... quindi il problema è la porta 80: l'accesso diretto alle videocamere avviene via browser!

Quindi..... ?!? 

OT: non è la porta 80 a darti i flussi delle videocamere.......sono le porte UDP a fornirti i flussi video. anche se da browser entri nel serverweb del DVR per guardare le telecamere (accesso fatto tramite porta 80), i flussi video sono trasmessi da delle porte impostate nel DVR (ora, per DAHUA dovrebbe essere 37778 UDP e 37777 TCP)....per le brutte cineserie varia 443, 8000 9000 6000............come regole nel modem, bypassa quelle 2 porte, indicando l'IP che utilizza le relative porte da non filtrare........

EDIT:notavo che hai un NVR e non un DVR........prova settare entrambe le schede sotto la stessa classe 192.168.1.x senza creare divergenze tra 0.x e 1.x altrimenti ti serve un NAT tunneling tra le 2 classi (altrimenti entrambe le reti sono affacciate ad internet ma, tra di loro non c'è nessun tipo di collegamento). Potresti anche utilizzare una sola scheda di rete per non creare problemi mettendo le telecamere su switch PoE e sullo stesso switch ci sono 2 porte NON PoE, di cui una collegata all'NVR e l'altra, direttamente su AGTOT, rimanendo così tutto sulla stessa classe di reteb o 192.168.0.x oppure 192.168.1.x, dipende da come hai impostato la rete

[Shackleton]

Scusate se ritorno sull'argomento ma qualcuno è riuscito a sostituire il firmware Tim con uno generico col quale si possano configurare tutti i parametri anche per altri isp?
Ho letto che qualcuno nel forum sembra avercela fatta ma non ho capito la procedura esatta e se è stato fatto solo col firmware inet australiano o anche con uno nativo technicolor

[mavelot]

E' stato per ora provato solo IINET ma in questo caso il firmware non ha Telnet quindi è per certi versi più bloccato.

In ogni caso, il firmware TIM se sbloccato, tramite telnet è configurabile in ogni aspetto.

[condor_uk]

Ragazzi buonasera,
ho windows 10 64bit ed ho scaricato e installato openssl,
ho messo la cartella sotto c:
e inserito nella variabile d'ambiente path di windows questo: C:\openssl-1.0.2k-x64_86-win64

Quando provo ad eseguire da cmd il comendo: openssl ottengo:
WARNING: can't open config file: /usr/local/ssl/openssl.cnf

Il problema è che non ho nessuna cartella /usr/local/ssl/openssl.cnf, che tra le altre cose sembra più un percorso unix

[Shackleton]

Ciao, è capitato anche a me e da questo topic ho letto che questo è un problema di openssl che non è configurato correttamente.

io ho risolto reinstallando openssl e mettendo il file da decriptare nella cartella nativa di openssl che per me er in C:\openssl o simile
Dopo decripta corretamente il file anche se a me dopo non funziona invece l'accesso successivo da ftp con User: Unlock e Password: root
ma devo riprovare


@mavelot: grazie per la risposta

[Crist]

Salve a tutti.
Stavo seguendo l'ottima guida di sblocco ma dopo aver eseguito il secondo ripristino del file ini (quindi dopo la copia del security.cfg) il modem mi va in loop senza riuscure ad avviarsi: selftest e vari tentativi con le stesse sequenze. Come posso sbloccarlo da questo loop? Anche accendendo/spegnendo non cambia.
Credo che possa essere il file security.cfg; durante la copia filezilla mi si è crashato e penso che abbia corrotto il file.
Vi prego sono nelle vostre mani 

[toretto_5]

metti in bootUP il modem (pulsante reset premuto, accensione mantenendo premuto il tasto fino al lampeggiamento arancione del LED i) e ri-caricare il firmware AGTOT_1.0.2 tramite il software technicolor modificato presente nel mio repository. Ripetere per 2 volte consecutive la procedura.

[Crist]

Grazie per la tua risposta.
Appena posso provo e vi farò sapere.