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

[alfonsor]

https://forums.openvpn.net/openvpn-connect-ios-f36.html

soprattutto devi controllare che sia possibile fare una connessione p2p, senza certificati

[omega3]

Una domanda :

sul 2200V3 avevo sotto il fw di Gnommo , devo dire che l'ho messo in quanto mi serviva di mettere l' SNR dell'ADSL a 6 dB in handshaking , funzionava.
Poi mi sono nate un paio di situazioni , tipo che abbiamo deciso nel condominio di mettere un server unico dove tutti abbiamo i nostri dati , ma con tre adsl e tre reti l'unico modo che ho potuto attuare , considerando anche la sicurezza , è stata quello di mettere una distribuzione appliance su un vecchio hw x86 e fare routing tra le tre reti.
Il 2200 a quel punto l'ho usato come MODEM.
Bene , nel momento in cui ho passato il funzionamento del 2200 come modem , come per magia sono sparite le due aggiunte di Gnommo , quindi il 2200 si collegava con i 12dB di default dell'ATm in centrale.
Volevo sapere da Alfi se usando il suo firmware con il 2200 però in versione MODEM , rimane la possibilità di settare i valori di handshaking.
Purtroppo al momento non lo posso provare io per svariate ragioni , quindi chiedo scusa per il disturbo e per la domanda , magari banale.

Saluti.

[random566]

Originariamente inviato da omega3

Bene , nel momento in cui ho passato il funzionamento del 2200 come modem , come per magia sono sparite le due aggiunte di Gnommo , quindi il 2200 si collegava con i 12dB di default dell'ATm in centrale.
Volevo sapere da Alfi se usando il suo firmware con il 2200 però in versione MODEM , rimane la possibilità di settare i valori di handshaking.

con amod il tweak snr funziona anche in modalità modem

[random566]

Originariamente inviato da alfonsor

questa volta non riesco proprio a replicare il bug

paradossalmente, da ieri anche a me ad ogni disconnessione la vpn si è ripristinata sempre.
eppure non ho toccato una virgola nelle impostazioni

[alfonsor]

ho deciso per questa soluzione;

mandando un segnale al processo openvpn, questo si riavvia; non si riavvia tutto il servizio di amod, che comprende, per dire, i ritocchi al firewall, ma solo il processo;

se qualcosa tra "non essere online" e "essere online" nel processo di openvpn cambia, un riavvio di openvpn quando si va online lo dovrebbe correggere

d'altronde, a pensarci, se hanno inserito questa possibilità, sarà proprio perché su alcuni sistemi è necessario riavviare tutto quando si verificano determinate condizioni

nel nuovo amod 2200, come esiste la macro firewall.user, ci sarà quella wan.user, che è chiamata quando si va on/off-line

in questa, due righe di codice riavviano openvpn, sperando che si ottenga il risultato che si riesce a connettere

oggi, sarò andato on/off-line 30 volte, in tutte le maniere, e, in temp variabili tra i 10 e 30 secondi da quando il ddns si rinfrescava, si è sempre riconnesso (il meccanismo sopra era in azione)

[alfonsor]

credo che anche sul firmware di gnommo funzioni in modalità modem, ma che semplicemente non appaia la voce del menù a sinistra

[avware]

Ciao,
io volevo segnalare qualche problemino con il server dns integrato (dnrd). Il problema si presenta col firmware originale (credo quindi anche con quello amod) però preferirei contribuire al miglioramento di amod, ecco perché scrivo qui.

Il problema si manifesta come lentezza nel risolvere gli ip, anche una semplice richiesta http impiega 10 secondi per tornare risultati. Inizialmente credevo si trattasse di difetti adsl, poi dopo aver giocato con i parametri di linea (e varie telefonate al mio provider per fammi innalzare inutilmente il profilo db) ho capito che era causato da dnrd. Aggiungo che da windows si manifesta di meno rispetto a linux (un amico più esperto mi accennava che potrebbe dipendere dal fatto che windows usa anche la cache wins per risolvere gli ip).

Compilando l'ultima versione di dnrn (2.20.3 del sourceforge) con la toolchain Netgear e lanciandolo a mano dal router al posto di quello originale, i problemi sono scomparsi. Peccato che le customizzazioni di netgear non consentono di usare dnrd così com'è, poiché la versione 'vanilla' è priva di una serie di argomenti da linea di comando (es. modalità opendns con --o) che lo mandano in errore all'avvio da parte di rc_apps.

Dato che considero il router un bel giocattolino ma ho carenze di programmazione C, chiedo supporto per 'tirar fuori' un minimo di patch essenziali dal lavoro di netgear sulla versione 2.19 (che tra le altre cose presenta anche 2 bug di sicurezza critici risolti nella 2.19.1) da applicare poi alla 2.20.3.. qualche interessato ?

[alfonsor]

usa dnsmasq

però testa anche questo, a fondo,

http://alfie.altervista.org/_altervista_ht/dnrd

[avware]

Originariamente inviato da alfonsor

usa dnsmasq

Diciamo che non mi aspettavo questa risposta

Originariamente inviato da alfonsor

però testa anche questo, a fondo,

http://alfie.altervista.org/_altervista_ht/dnrd

Ecco, questo era quello che mi aspettavo

Il 'workaround' iniziale era proprio di sostiturilo con dnsmasq ma dopo aver visto quanto poco spazio occupava dnrd (offredo le stesse caratteristiche) ho capito perchè netgear l'ha preferito e ho ripensato al suo rimpiazzo.

In ogni caso...
/tmp/dnrd -a 192.168.0.1 -m hosts -c off -r 0 -s 208.67.222.222 -s 208.67.220.220 -o 0 -q xxx
(args lanciati da rc_apps)
per ora va che è una meraviglia Sicuramente ti ringrazio e.. credi sia possibile avere le sorgenti per capire la modifica fatta ? Sono un tipo curioso io

edit: e poi mi chiedevo perché dnsmasq e non bind ? XD

edit: segnalo che con la nuova versione si risolvono anche i lunghi tempi di attesa quando si tenta di accedere a servizi nella lan (es. ssh verso macchine collegate al router)

[alfonsor]

a dire il vero sui modelli superiori Netgear ha optato per dnsmasq

perché? perché svolge funzioni di server dhcp, dns, tftp ed ha infinite opzioni di configurazione, adattandosi a sistemi con poche risorse e poca memoria perfettamente

per i sorgenti: non ho i sorgenti per il 2200V3, ma solo quelli del 4000; per cui le modifiche fatte a dnrd-2.19 per il 2200V3 mi sono ignote; ho quindi applicato quelle fatte sul 4000 (al volo, quindi non so manco se tutte)

http://www.mediafire.com/?4o51gk6tucapuau

comunque, dnsmasq è sempre preferibile di gran lunga ma gran lunga


ops, mi sono accorto ora che ci sono i sorgenti nell'archivio del firmware V1.1.00.21_WW; poi vedo cosa hanno modificato esattamente

[random566]

messa la nuova versione 1.0.9 sul 2200v3 e il file wan.user in /config/xxx/amod.
per ora openvpn si riconnette regolarmente a seguito di disconnessioni adsl

[omega3]

Bravo Alfi.
Problema sulla 443 risolto , non sò come , ma non importa.
Bello il grafico adsl.
L'unica cosa che mi dispiace è che ho davanti 10 giorni di inferno , compresa la domenica di domani , e che non posso provare la cosa , ma per ora ti faccio i miei piu sinceri complimenti per il lavoro che stai portando avanti.
Appena posso provo la vpn e se è stabile , il tuo donate te lo sei ampiamente meritato.
Un appunto all'hardware che è limitato , altrimenti la vpn con certificati CA - Server - Client sarebbe stata il massimo.
Chissà se vale la pena di passare al 3500.

Di nuovo grazie.

[avware]

Originariamente inviato da alfonsor

per i sorgenti: non ho i sorgenti per il 2200V3, ma solo quelli del 4000; per cui le modifiche fatte a dnrd-2.19 per il 2200V3 mi sono ignote; ho quindi applicato quelle fatte sul 4000 (al volo, quindi non so manco se tutte)

Così su due piedi, sembra che le modifiche applicate alla 2.20.3 siano minimali rispetto a quelle della 2.19. Di ereditato ci sono: il 'supporto' a opendns (anche se devo capire cosa fa questa feature) e un anti dns hijack.. forse qualcosa manca ma già così è molto più reattivo di prima. Rispetto ai danni che fa la versione 2.19 io la battezzerei subito.

Per il discorso dnsmasq: tanto di cappello, ma ci sono modi per sostituirlo a dnrd ? (intendo nell'uso di rc_apps).

Qualche post più indietro ho visto che, per tentare di risolvere il problema, ti sei costruito un wrapper che intercetta il link simbolico rc_apps in modo da gestire delle chiamate start/stop ai servizi (nuovi o per eseguirne l'override) oppure rimandare i comandi all'originale nel caso di sconosciuti.

Io tenterei l'approccio 'sostituzione massiva' ..è più manutenibile un sistema in script sh che un eseguibile C (a parer mio) e se serve una mano.. sarei entusiasta di partecipare

[SteFir]

Buongiorno,

seguo con piacere questo forum da molto tempo e ringrazio tutti per gli ottimi consigli che si possono trovare.

Ho però un problema che non riesco a risolvere:

possiedo un DGN3500 sul quale ho montato, partendo dall'ultimo firmware originale, varie release di amod, fino all'ultima 9.2.3.
Non riesco a far funzionare la parte di modifica snr in nessun modo. Il problema è che il router aggancia la portante, la spia internet rimane rossa, e dopo 10 secondo circa, perde la portante.

Il fatto è che lo fa con qualsiasi valore di snr impostato. Basta che metto la spunta su "Apply section", nella sezione di modifica snr, e il problema si presenta, anche se lascio il deltasnr a 0.

Ho provato a resettare il router, a rimettere fw originale, resettare e poi rimettere fw amod, a cambiare il fw del modem, ma non ne vuole proprio sapere di funzionare.

Ringrazio anticipatamente per l'aiuto.

[alfonsor]

Originariamente inviato da avware

Qualche post più indietro ho visto che, per tentare di risolvere il problema, ti sei costruito un wrapper che intercetta il link simbolico rc_apps in modo da gestire delle chiamate start/stop ai servizi (nuovi o per eseguirne l'override) oppure rimandare i comandi all'originale nel caso di sconosciuti.

Io tenterei l'approccio 'sostituzione massiva' ..è più manutenibile un sistema in script sh che un eseguibile C (a parer mio) e se serve una mano.. sarei entusiasta di partecipare

senza i sorgenti di rc, sia sul 2200 che sul 3500, ogni cosa va fatta per aggiustamenti; se si riesce a controllare come un'applicazione viene lanciata attraverso un hook ad rc è tutto oro colato; se non ci si riesce, bisogna cambiare nome all'applicazione direttamente oppure modificare a mano rc con un hex editor

questo accade soprattutto nel 3500; nel 2200 di meno

quindi, non ho capito bene cosa intendi;

non si può "sostituire" una cosa con un'altra, dnrd con dnsmasq, perché tutto viene tirato sopra da rc e setup.cgi e i sorgenti non li ho;

quello che posso fare è questo, se ci sono idee nuovo, ben vengano

su uno ha voglia di riscriversi completamente rc, buon divertimento

[Kalindor]

Originariamente inviato da alfonsor

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

per dire "[ATTACKBRUTE] "

Ho fatto qualche prova: se imposto le regole iptables per salvare i log con il prefisso [DOS] le regole vengono salvate in maniera corretta. Quindi il sistema di logging funziona. Il problema sta tutto nella configurazione /etc/syslog.conf. Ho fatto quindi come segue:

• Modificato manualmente il file /etc/syslog.conf modificando la riga log_keyword e inserendo i parametri [INPUT DROP] e [ATTACK BRUTE]
• impostato rcS1 per caricare il file al boot, ma niente, torna quello originale netgear
• provato a riavviare manualmente syslogd ma niente, non mi prende i nuovi parametri

Ora, se riuscissi a modificare quello originale in amod, quello che va a caricare il sistema all'avvio credo che potrei risolvere il mio problema, ma dove lo trovo?
Oppure, come faccio a riavviarre syslog perchè: se lancio /sbin/syslogd restrat questo comando mi resta in esecuizione perpetua, infatti lanciando top vedo il comandi li. L'unico modo per chiuderlo è con kill [numero pid], ma anche così facendo non mi prende i nuovi parametri....

Come posso fare?
Grazie

[alfonsor]

come vedi in /usr/sbin/rc_app c'è una voce rc_syslogd

puoi provare a creare un hook in /etc/amod/hooks chiamato syslogd_pre e syslogd_post

il primo viene eseguito prima che sia chiamata rc; il secondo dopo che è stata chiamata

se il primo, syslogd_pre ritorna 42, rc non viene più chiamata; se torna qualsiasi altro risultato, l'elaborazione prosegue

quindi

gioca con questi hooks e vedi se riesci ad intercettare le chiamate a syslogd in modo da fare quello che desideri


PS
in ogni caso, considera che il meccanismo di syslog è alquanto bizzarro; per evitare che il syslog diventasse enorme, per dire qualsiasi programma portato potrebbe sysloggare mega di roba e sul 2200 non esiste nessun programma per fare il rotate, hanno messi paletti

tanto per dire per loggare una qualsiasi cosa con "amodfun log" devo aggiungerci a mano la stringa "10 00[amod] ", 10 00 viene scartata e solo così si ha il log

quasi quasi ti consiglio di provare a usare come forma per il log "10 00[LOG] MESSAGGIO"

[alfonsor]

Originariamente inviato da SteFir

Buongiorno,

seguo con piacere questo forum da molto tempo e ringrazio tutti per gli ottimi consigli che si possono trovare.

Ho però un problema che non riesco a risolvere:

possiedo un DGN3500 sul quale ho montato, partendo dall'ultimo firmware originale, varie release di amod, fino all'ultima 9.2.3.
Non riesco a far funzionare la parte di modifica snr in nessun modo. Il problema è che il router aggancia la portante, la spia internet rimane rossa, e dopo 10 secondo circa, perde la portante.

Il fatto è che lo fa con qualsiasi valore di snr impostato. Basta che metto la spunta su "Apply section", nella sezione di modifica snr, e il problema si presenta, anche se lascio il deltasnr a 0.

Ho provato a resettare il router, a rimettere fw originale, resettare e poi rimettere fw amod, a cambiare il fw del modem, ma non ne vuole proprio sapere di funzionare.

Ringrazio anticipatamente per l'aiuto.

né mi è mai capitata una cosa del genere, né è stata mai riferita;

qualcosa di profondamente sbagliato avviene;

lascia tutte le "Apply Section" non selezionate, seleziona soltanto quella della SNR, salva, riavvia, entra in telnet e dà questi 2 comandi

ls -l /tmp/modemhwe.bin
cat /etc/cmv_batch

e posta qui il risultato

[SteFir]

Originariamente inviato da alfonsor

né mi è mai capitata una cosa del genere, né è stata mai riferita;

qualcosa di profondamente sbagliato avviene;

lascia tutte le "Apply Section" non selezionate, seleziona soltanto quella della SNR, salva, riavvia, entra in telnet e dà questi 2 comandi

ls -l /tmp/modemhwe.bin
cat /etc/cmv_batch

e posta qui il risultato

Grazie per la risposta, ecco il risultato:

~ # ls -l /tmp/modemhwe.bin
lrwxrwxrwx 1 35 Jan 1 2000 /tmp/modemhwe.bin -> /firmware/modemhwe-4
.5.0.12.0.1.bin
~ # cat /etc/cmv_batch
[WaitForConfiguration]={
echo WaitForConfiguration
g997xtusecs 0x5 0x0 0x4 0x0 0x4c 0x1 0x4 0x0
locs 0 0
locs 1 0
locs 2 0
locs 3 0
g997racs 0 3
g997racs 1 3
lfcs 0 0 0 0 0 0
lfcs 1 0 0 0 0 0
}
[WaitForLinkActivate]={
echo WaitForLinkActivate
#Set bit 5 of INFO 103 20 to "1" INFO 103 20 bitmask 0x0020
cr info 103 20 $0
mov $1 0x0020
or $0 $1
cw info 103 20 $0
#Set bit 5 of OPTN 25 0 to "1" OPTN 25 0 bitmask 0x0020
#Set bit 4 of OPTN 25 0 to "1" OPTN 25 0 bitmask 0x0010
cr optn 25 0 $0
mov $1 0x0030
or $0 $1
cw optn 25 0 $0
cw test 28 0 0x1000
}
[WaitForRestart]={
echo WaitForRestart
}


Se ti possono essere di aiuto a risolvere il problema, ti do alcune informazioni aggiuntive:

1- Dopo aver attivato la sezione deltaSNR ed aver innescato il problema, anche se tolgo la spunta, do salva e poi retrain, il problema rimane, devo necessariamente riavviare il router

2- Avevo lo stesso problema anche usando ModFs

3- Con un altro vecchio router, con chipset broadcom, modificando da telnet il valore snr, aggancia la portante piena a 24 Mbps (abito molto vicino alla centrale) con SNR compresa tra 3 e 4,5 db e la mantiene stabile anche per giorni

[alfonsor]

dopo aver de-selezionato tutte le Apply Section eccetto quella SNR, dopo aver quindi salvato, hai riavviato il router?

perché mi è necessario sapere il risultato di quei due comandi dopo aver riavviato il router