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

[alfonsor]

ti rispiego passo passo cosa fare; ti assicuro che lo sto facendo in questo momento mentre te lo scrivo, per cui è assicurato che funziona

prima di tutto va in services amod e premi start a destra della voce telnet

quindi con un cliente telnet di tua scelta, per dire putty su windows, fa una connessione al 3500

ora ferma transmission
stop torrent

ora cancella il file settings.json per avere una configurazione pulita
rm /mnt/shares/U/transmission/settings.json

ora apri il file /etc/amod/conf/firewall.user
nano /etc/amod/conf/firewall.user

dentro ci deve essere questo
#!/bin/sh
. /etc/amod/lib/func
AMODRouterPort open tcp 9091

ora premi ctrl-o return ctrl-x

ora rendilo eseguibile con
chmod +x /etc/amod/conf/firewall.user

ora eseguilo
/etc/amod/conf/firewall.user

deve uscire questo messaggio
* INFO: added port forwarding for tcp connections: XX.XX.XX.XX:9091 => 192.168.0.1:9091

dove XX.XX.XX.XX è il tuo indirizzo pubblico; se non esce quel messaggio sopra, ricontrolla tutti i passaggi

ora lancia transmission
start torrent

ora dal telefonino connesso in 3g, apri un browser e scrivi
http://XX.XX.XX.XX:9091

qui da me mi si apre la pagina di controllo di transmission

se anche da te dovesse finalmente aprirsi, come prima cosa la devi proteggere da una password, perché così è accessibile da chiunque via wan e non è cosa buona

comunque, nella prossima versione di amod per il 3500, ho messo un'opzione tra quelle di transmission

[ciarpame]

Sto per andare in vacanza e vorrei ridurre il rischio che il DGN3500 si pianti o abbia problemi con la linea, cose che succedono raramente ma succedono (due esempi: la settimana scorsa down internet nella zona e ho dovuto fare retrain a mano, ore dopo, per ripartire; ieri pomeriggio wifi criccato, per recuperare ho forzato il riavvio della parte wifi a mano). Lo scopo è accedere ad una ipcam e ricevere allarmi da remoto.

L'ideale per sarebbe poter schedulare un riavvio giornaliero. Non mi pare che l'opzione sia prevista né che nel thread ci siano indicazioni (ho provato a cercare con le keyword che mi sono venute in mente).
Si può fare? Magari anche senza GUI, andrebbe bene anche una cosa tipo crontab.

Suggerimenti? Grazie!

[alfonsor]

nano /etc/amod/conf/rcS2
---
#!/bin/sh
/etc/amod/bin/cron add "0 5 * * * /bin/reboot"
---
ctrl-o return ctrl-x

chmod +x /etc/amod/conf/rcS2
/etc/amod/conf/rcS2

ora ogni 05:00 di notte ci sarà un reboot

[viaimpedita]

Originariamente inviato da alfonsor

ti rispiego passo passo cosa fare; ti assicuro che lo sto facendo in questo momento mentre te lo scrivo, per cui è assicurato che funziona

prima di tutto va in services amod e premi start a destra della voce telnet

quindi con un cliente telnet di tua scelta, per dire putty su windows, fa una connessione al 3500

ora ferma transmission
stop torrent

ora cancella il file settings.json per avere una configurazione pulita
rm /mnt/shares/U/transmission/settings.json

ora apri il file /etc/amod/conf/firewall.user
nano /etc/amod/conf/firewall.user

dentro ci deve essere questo
#!/bin/sh
. /etc/amod/lib/func
AMODRouterPort open tcp 9091

ora premi ctrl-o return ctrl-x

ora rendilo eseguibile con
chmod +x /etc/amod/conf/firewall.user

ora eseguilo
/etc/amod/conf/firewall.user

deve uscire questo messaggio
* INFO: added port forwarding for tcp connections: XX.XX.XX.XX:9091 => 192.168.0.1:9091

dove XX.XX.XX.XX è il tuo indirizzo pubblico; se non esce quel messaggio sopra, ricontrolla tutti i passaggi

ora lancia transmission
start torrent

ora dal telefonino connesso in 3g, apri un browser e scrivi
http://XX.XX.XX.XX:9091

qui da me mi si apre la pagina di controllo di transmission

se anche da te dovesse finalmente aprirsi, come prima cosa la devi proteggere da una password, perché così è accessibile da chiunque via wan e non è cosa buona

comunque, nella prossima versione di amod per il 3500, ho messo un'opzione tra quelle di transmission

Effettivamente ora va
Però non ha senso l'unica cosa diversa è stata quella di eliminare prima il file setting
Grazie

[alfonsor]

e chissà che ci avevi messo dentro...

[viaimpedita]

veramente mai modificato, comunque come faccio per impostare la password per entrare dall'esterno?

[ciarpame]

Originariamente inviato da alfonsor

nano /etc/amod/conf/rcS2
---
#!/bin/sh
/etc/amod/bin/cron add "0 5 * * * /bin/reboot"
---
ctrl-o return ctrl-x

chmod +x /etc/amod/conf/rcS2
/etc/amod/conf/rcS2

ora ogni 05:00 di notte ci sarà un reboot

Grazie per la risposta istantanea, neanche fossimo in chat

Stasera provo, ora ho una curiosità: mi fai mettere il cron nel file rcS2 che viene richiamato al boot, vuol dire che cron non è persistente?

[alfonsor]

ci sono pochissimi k di memoria che non viene persa al boot, è quella memoria montata in /www.eng/langs, che nel firmware originale serve solo a contenere il file della lingua scelta per le traduzioni delle pagine web; amod la sfrutta per memorizzare un pò di cose, tra le quali le sue preferenze, vari file di configurazione, per dire di dnsmasq openvpn dropbear e via dicendo, e per alcuni file hook che vengono eseguiti quando avviene qualche cosa (boot, firewall re-avviato si va online e così via)

/etc/amod/conf è semplicemente /www.eng/langs/amod

[alfonsor]

Originariamente inviato da viaimpedita

veramente mai modificato, comunque come faccio per impostare la password per entrare dall'esterno?

http://superuser.com/questions/11364...-client-server

[kata32]

Il mio 3500 da un paio di settimane si comporta in modo strano: il led della portante DSL si spenge e addio internet. Poi dopo un paio di giorni si riaccente e tutto torna OK per 5-6 giorni. Se leggo lo stato della connessione DSL mi dice silent - 0x200.

Quasi sicuramente tutto ciò è colpa di Telecom ma quello che mi incuriosce e che sul log del 3500 non c'è traccia di queste perdite e riacquisto di portante. Se queste informazioni ci fossero forse mi potrebbero aiutare a capire la causa del problema.

[alfonsor]

purtroppo se non c'è proprio la adsl, il log viene fatto da dentro programmi e muduli chiusi, cioé se non loggano niente, c'è poco da fare

solo che è quel silent che mi lascia un tantino pensieroso, perché di solito quando non c'è la adsl lo stato di dsl_cpe dovrebbe essere idle, cioé è in attesa che succeda qualcosa sulla adsl, insomma che appaia la linea

ma se premi retrain, succede qualcosa?

[kata32]

Originariamente inviato da alfonsor

ma se premi retrain, succede qualcosa?

Non succede assolutamente nulla

Che dici, è il momento di farmi prestare un modem alternativo e verificare con quello?

[alfonsor]

no mi sono sbagliato, se la linea non c'è mostra silent

però, farsi prestare un altro modem non è una cattiva idea, in generale, giusto per escludere fallimenti del 3500

[kata32]

Originariamente inviato da alfonsor

però, farsi prestare un altro modem non è una cattiva idea, in generale, giusto per escludere fallimenti del 3500

Ok, oggi a pranzo procedo...

Ho provato:
il test è stato abortito, nel senso che quando sono arrivato a casa il led DSL era acceso e la connessione internet funzionante, tutto questo senza che io avvertissi telecom o riavviassi il 3500.
Se dovesse ricapitare sarò più lesto nel recuperare un modem DSL e nel fare la prova.

[zortec]

Dalla versione 13.1.3 di amod 3500, le email inviate dal router arrivano con l'ora del messaggio errata.
Avendo impostato nella sezione Schedule come fuso orario GMT+1 e attivata la checkbox "Adjust for Daylight Savings Time", nelle versioni precedenti la 13.1.3 le email arrivavano con l'ora corretta, dalla 13.1.3 le email arrivano con l'ora più avanti.
Per una email inviata dal router alle 14.00, prima della 13.1.3, l'header SMTP Date appariva come:

Date: Wed, 08 Jul 2015 14:00:01 +0200

mentre dalla 13.1.3:

Date: Wed,15 Jul 2015 14:00:00 +0100 (GMT Daylight Time)

Sembra che nel passaggio dalla 13.1.2 alla 13.1.3 siano state messe in amod due versioni di smtpc diverse.
Poichè il formato "+0100 (GMT Daylight Time)" non è perfettamente conforme alla rfc2822 (il testo successivo alla time zone non dovrebbe essere previsto), credo che la versione di smtpc della 13.1.2 era la più corretta.

[alfonsor]

non ricordo se è mai stato cambiato quel programma; sicuramente non negli ultimi tempi

controllerò

ho visto i sorgenti di smtp che avevo modificato per non considerare minimamente i parametri -t e -d che gli venivano passati e formare la stringa data sempre dall'ora corrente; i sorgenti li avevo modificati, solo che nel firmware del 3500 c'è sempre stato smtp originale, non ricordo la ragione per la quale non l'avevo sostituito

insomma, smtp è sempre quello e quello modificato (la modifica è sui sorgenti di smtp del 4000 a dire il vero, ma è lo stesso quasi sicuramente) non è mai stato usato

PS
ed invece hai ragione tu: nella 13.1.2 c'era la versione modificata mentre dalle successive c'è la versione originale; come è potuta accadere questa cosa? non ne ho la più pallida idea

[zortec]

Se è così, potresti per favore mettere la versione di smtpc di amod 13.1.2 nelle versioni successive per 3500?
Grazie.

[alfonsor]

ok ho ricostruito a mente la faccenda; qualche tempo fa mi sembra proprio tu raccontasti di blocchi del router quando il client smtp non riusciva a connettersi al server di posta; allora presi smtp vecchio e lo rimisi nel firmware

[zortec]

Originariamente inviato da alfonsor

ok ho ricostruito a mente la faccenda; qualche tempo fa mi sembra proprio tu raccontasti di blocchi del router quando il client smtp non riusciva a connettersi al server di posta; allora presi smtp vecchio e lo rimisi nel firmware

Si mi ricordo bene della faccenda.
Ma ora credo che smtp non sia la causa del blocco ma qualcosa in syslogd.
A me con il seguente script il blocco viene riprodotto (sia nella versione 13.1.2 sia nell'ultima):

#!/bin/sh

#a me si blocca a n=13
count=15
n=0
while [ $n -lt $count ]; do
	n=$((n + 1))
	echo "Test Log  $n"
	killall -SIGHUP syslogd
	amodfunc log "Test Log $n"
done

Attenzione: lo script di cui sopra blocca il router (almeno a me).

Con killall -SIGHUP syslogd mando la richiesta a syslogd di invio email .
amodfunc è solo utilizzato per inviare un messaggio di log mentre si sta inviando l'email.
Infatto il blocco avveniva di solito quando erano rilevati attacchi DOS e probabilmente mentre si riempiva il log contemporameamente veniva inviata l'email.
L'email server che utilizzo io risponde con errore quando si inviano troppe email velocemente (credo per evitare lo spam).

Con i sorgenti che avevi postato tempo fa di smptc (credo quelli di amod 13.1.2, ma non sono sicuro) e syslogd, a me sembra che il problema avvenga quando il server di posta restituisce un errore, ed allora smtpc inserisce un messaggio di log, e qui sembra che vada in blocco.

Ma questa può essere solo la mia impressione non ho ancora ben chiaro la cosa. Potrebbe anche essere qualche cosa relativa al semaforo impostato in syslogd? boh

[alfonsor]

non è che si blocca il router, si blocca lo script in amodfunc log

perché amodfunc log cerca di fare un openlog ed il log è loccato internamente a syslog dall'eseguzione di smtpc

avviene che il server di posta rileva una attività strana da un singolo indirizzo, tipo spam in un lasso di tempo breve, e prima avverte che non accetterà posta, al successivo smtpc, questo rimane incantato per un pò; mentre è in attesa di ricevere risposta dal server smtp, sta loccando il log, qui arriva amodfun log che vuole usarlo lui e si blocca

basta che fai un killall smtpc per fare andare avanti le cose

è una situazione limite che non mi sembra il caso di affrontare, anche perché nella realtà non è che si mandino 15 email in meno di un secondo dal router...

PS
guarda, tu hai i sorgenti di syslog, cambia in send_mail_signal le cose come:

time_t last_send = 0;

static void send_mail_signal(int sig UNUSED)
{
	if(conf.mail_enable==1) {
		char cmd[1024]="";
		time_t now;

		sem_down(s_semid);
		
		now = time(NULL);
		if (last_send>0 && now-last_send<30) {
			sem_up(s_semid);
			return;
		}

		last_send = now;

		if(conf.mail_enable_auth==1)

problemi risolti, puoi mandare una email ogni 30 secondi minimo e niente blocchi