[Thread ufficiale] amod - firmware modificato per DGND4000, DGN3500, DGN2200V3/V4

[alfonsor]

Originariamente inviato da Kalindor

Perfetto ho fatto così e funziona tutto perfettamente, ho fatto qualche test questa mattina e con le regole iptables per il blocco delle connessioni nella porta 22. Grazie tante....

Ho qualche altro dubbio, se volessi utilizzare crontab, a quanto mi sembra si inizializza all'avvio, ma per aggiungere altre regole, dove devo aggiungerle? Ho visto un file in /tmp/etc/crontabs/root si deve modificare quello? Però con la scusa che /tmp/ si cancella ad ogni avvio del FW, non credo sia la locazione giusta, o sbaglio?

il fatto è che siamo in un router con memoria non scrivibile, eccetto una microscopica zona che si chiama /www.eng/langs

per cui non è come su una distribuzione linux qualsiasi; qui non puoi mai pensare di conservare qualcosa al boot; eccetto per quanto previsto

come ti ho scritto sopra, le cose da lanciare al boot vanno specificate in quel file

nello stesso file, quindi puoi lanciare crontabs; il crontabs va lanciato con una certa attenzione perché: non è il crontabs utilizzato dal firmware netgear e lo usano anche altre cose, come ad esempio il wol ed il wireless scheduling

per lanciarlo devi usare il comando
/etc/amod/scripts/runcron

quindi, puoi aggiungere comandi a cron con
echo "comando cron" >>/tmp/cron_root_tmp
cat /tmp/cron_root_tmp | /usr/sbin/bbcrontab -
rm /tmp/cron_root_tmp

dove comando cron è una linea con la sintassi di crontabs

[Aku]

Messo su il firmware.... beh stupendo Ottimo lavoro alfonso

[Kalindor]

Originariamente inviato da alfonsor

....

/etc/amod/scripts/runcron

quindi, puoi aggiungere comandi a cron con
echo "comando cron" >>/tmp/cron_root_tmp
cat /tmp/cron_root_tmp | /usr/sbin/bbcrontab -
rm /tmp/cron_root_tmp

dove comando cron è una linea con la sintassi di crontabs

Infatti, avevo visto che impostando lo scheduling del WIFI, ovviamente operante con cron, mi creava cron_root_tmp ma poi mi spariva e non trovavo più il nesso. bene perfetto ho capito.

Un'ultima cosa, con dropbear si ha la possibilità di disabilitare il login mediante username e password, e quindi agire solamente mediante le chiavi. Volendo intraprendere questa strada, l'unico modo è disabilitare il deamon all'avvio mediante interfaccia HTTP e farlo eseguire al boot in rcS2???

[alfonsor]

in amod services dropbear esiste l'opzione per disabilitare o abilitare il login via password e quindi usare solo la chiave

[D4r!?]

Ciao a tutti, volevo solo dire che finalmente sono riuscito a far andare la mia connessione openvpn, risolvendo quindi i problemi di cui ho parlato qualche pagina addietro
Scrivo questo soprattutto per poter magari dare una mano a chi, come me, dovesse trovarsi in questa situazione, anche perchè in giro per gli altri forum sembrano mancare delle spiegazioni/soluzioni dettagliate in merito.

Per riassumere brevemente la situazione, non riuscivo a collegarmi alla vpn ne attraverso UDP ne attraverso TCP. Con la configurazione in UDP mi usciva questo errore:

Thu May 02 09:09:09 2013 us=25461 Inactivity timeout (--ping-restart), restarting
Thu May 02 09:09:09 2013 us=25461 TCP/UDP: Closing socket
Thu May 02 09:09:09 2013 us=25461 SIGUSR1[soft,ping-restart] received, process restarting
Thu May 02 09:09:09 2013 us=25461 MANAGEMENT: >STATE:1367478549,RECONNECTING,ping-restart,,

Questo errore, come viene riportato altrove, è attribuito al fatto che il client non riesce in qualche modo a raggiungere il server oppure che vi sono due o più client che tentano la connessione ad un server configurato per un utilizzo mono-client.
Tuttavia, la mia problematica non risiedeva in nessuno dei due casi. Tutto quello che ho fatto è stato semplicemente di disattivare e poi riattivare la copressione lzo e impostare il parametro NICE a 12 . Non chiedetemi come mai ma così facendo si è sistemato tutto.

Di seguito metto tutti i passaggi fatti:

- Spento e riacceso il router
- Tentativo di connessione con configurazione iniziale (fallita con l'errore riportato di sopra)
- Disconnessione
- Disattivazione compressione lzo (chiaramente sia sulla configurazione del server che quella del client: è sufficiente commentare la riga "comp-lzo" mettendo un ; all'inizio della riga stessa)
- Nuovo tentativo di connessione (anch'esso fallito, sempre stesso errore)
- Riattivazione compressione lzo (togliete il ; dalla configurazione sia su server che su client)
- Impostato valore nice a 12 (valore iniziale -6) sulla config del server
- Ta dà! Come per magia la connessione adesso funziona perfettamente, riesco a raggiungere i dispositivi remoti senza problemi di sorta

Spero che questo possa essere d'aiuto a qualcuno.
Ripeto, non so spiegarmi PERCHE' abbia funzionato fare questa cosa, eppure adesso va che è una meraviglia

Edit: volevo solamente aggiungere i miei complimenti ad alfonsor per l'ottimo fw che ha sviluppato.. è semplicemente perfetto per le mie necessità

[alfonsor]

è un comportamento balzano; molto probabilmente, openvpn ha bisogno, o dal lato client o dal lato server, di essere riavviata per qualche ragione

[random566]

Originariamente inviato da alfonsor

.... molto probabilmente, openvpn ha bisogno, o dal lato client o dal lato server, di essere riavviata per qualche ragione

anch'io a volte con il 2200v3 ho problemi di riconnessione della vpn a seguito di una caduta della connessione adsl. con il 3500 non succedeva mai.
spesso è necessario riavviare il servizio lato server per permettere la riconnessione.
ora sto provando in udp, forse cambia qualcosa rispetto al tcp

[alfonsor]

il firewall del 2200 è un incubo; mi toccherà ritestare a fondo openvpn sul 2200; in questi giorni ho il 3500 connesso, perché so facendo lavori sul suo firmware, visto che l'introduzione del media server ha riempito lo spazio, devo fare posto; ho rimosso il firmware adsl più vecchio che nessuno credo usi e tante cose che erano messe più per sfizio che per altro, come l'interprete lua, ho ricompilato il media server con gcc 4 che lo ha ridotto all'osso; appena finito passo di nuovo mannaggia a openvpn 2200

[trim_de_brim]

Originariamente inviato da alfonsor

il firewall del 2200 è un incubo; mi toccherà ritestare a fondo openvpn sul 2200; in questi giorni ho il 3500 connesso, perché so facendo lavori sul suo firmware, visto che l'introduzione del media server ha riempito lo spazio, devo fare posto; ho rimosso il firmware adsl più vecchio che nessuno credo usi e tante cose che erano messe più per sfizio che per altro, come l'interprete lua, ho ricompilato il media server con gcc 4 che lo ha ridotto all'osso; appena finito passo di nuovo mannaggia a openvpn 2200

quanto vecchio il firmware?
spero non
Firmware Version: 4.4.4.1.3.1

[Kalindor]

Originariamente inviato da alfonsor

in amod services dropbear esiste l'opzione per disabilitare o abilitare il login via password e quindi usare solo la chiave

Hem, non avevo visto il flag scusate

Inviato dal mio Nexus 4 con Tapatalk 2

[alfonsor]

Originariamente inviato da trim_de_brim

quanto vecchio il firmware?
spero non
Firmware Version: 4.4.4.1.3.1

no, ho eliminato il 4.4.4.0.0.1

[gian_1_2000]

Originariamente inviato da alfonsor

vedendo dal 3500, sul quale basta cambiare la porta sulla quella pagina, non mi ero mai posto il problema sulla 443 del 2200

comunque tu prova se basta killare il processo

Salve ho provato sul 3500 a seguire le tue indicazioni ma al momento di salvare la regola in openvpn mi da porta out of range(1025...65535).
Anche il mio ufficio filtra le porte.La 8080 la ho già aperta per la ipcam.
Mi puoi aiutare.
Grazie Afonsor

[alfonsor]

dovete attendere le nuove versioni per entrambi i router

[Kalindor]

ho un altro piccolo problemino. Continuo a scrivere qui perchè raramente capita di parlare direttamente con chi ha creato il firmware ....

Sono sempre alle prese con iptables, e questa volta in particolar modo con i LOG. Ho impostato una regola come la sequente:

iptables -A ATTACKBRUTE -m limit --limit 1/min -j LOG --log-prefix "[ATTACKBRUTE]"

praticamente, quando il pacchetto l'attraversa, LOGGA il tutto con il prefisso [ATTACKBRUTE] con un limite massimo di un log al minuto. Ora, simulando un attacco a forza bruta, la regola viene eseguita in quanto facendo iptables -L -n -v, vedo che i pacchetti la richiamano, ma non trovo alcun riferimento del log in /var/log/messages.

Pensavo che il tutto fosse scatendato da --log-prefix "[ATTACKBRUTE]" in quanto in /etc/syslog.conf alla linea log_keyword mancava appunto la keyword [ATTACKBRUTE], impedendo al log di beccare quel tipo di messaggio lanciato dal kernel.
Ora modificando /etc/syslog.conf e ponendo log_keyword=[DOS] [PORT SCAN] [BLOCK] [TRUST] [INPUT DROP] [ATTACKBRUTE], mi ritrovo allo stesso punto di partenza, e andando a verificare /var/log/messages non trovo traccia dei miei LOG.

Sbaglio qualcosa o non si può proprio fare?

[alfonsor]

prova a mettere uno spazio alla fine della stringa di log,

per dire "[ATTACKBRUTE] "

[alfonsor]

@random

senti, io sto provando a spegnere fisicamente il router; fare un retrain, staccare il filo del telefono e via dicendo

e sempre si riconnette il cliente openvpn windows 7 via chiavetta tim al server sul 2200V3

[random566]

Originariamente inviato da alfonsor

@random

senti, io sto provando a spegnere fisicamente il router; fare un retrain, staccare il filo del telefono e via dicendo

e sempre si riconnette il cliente openvpn windows 7 via chiavetta tim al server sul 2200V3

come avevi scritto anche tu, il comportamento è un po' "bizzarro".
per esempio, ieri ho avuto 3 disconnessioni lato server, dopo la prima la vpn non si è ripristinata ed è rimasta inattiva per circa 2 ore fino alla seconda disconnessione, a seguito della quale si è ripristinata senza che io facessi niente, dopo la terza ( qualche ora più tardi) si è ripristinata regolarmente.
qualche settimana fa mi è anche successo per 2 o 3 volte un altro fatto strano, dopo una disconnessione la vpn si è ripristinata e si esplorava regolarmente la rete da entrambi i lati, eccetto però il solo indirizzo del router che effettuava il server vpn che non era raggiungibile dal lato opposto della vpn.
è tornato raggiungibile solo con il riavvio del server vpn.
capisco che sia molto difficile scoprire il problema, dato che avviene casualmente

[alfonsor]

pensavo che forse si potrebbe tagliare la testa al toro, mettendo una opzione che fa riavviare openvpn quando la wan va up; in questa maniera, openvpn riparte e saltiamo tutti i problemi

anche perché sinceramente non riesco proprio a capire dove stia il problema, questa volta

l'altra volta erano i DNS sbagliati e fu facile, insomma, rimisi la versione precedente che funzionava

questa volta non riesco proprio a replicare il bug

[alex12345]

Messa su la 9.2.3
Testing......

[gian_1_2000]

Salve,
qualcuno mi spiega come creare il .ovpn da usare su iphone per fare una prova. Ho provato a metterci la key ma niente.
mi da errore "option error:remote option not ....".