Salve,
da un paio di giorni ho aggiornato il 7390, che funzionava perfettamente col firmware 84.05.05, alla 84.05.06. Lì iniziano i problemi.
Con la 84.05.06 apparentemente il demone NTP ha smesso di funzionare. Questo è l'output che ottengo su un client configurato per prendere l'ora dal Fritz!Box:
Ovviamente le stesse impostazioni non creavano problemi col firmware precedente, ma per sicurezza ho già resettato e riconfigurato l'apparato, oltre ad aver cambiato i server NTP di riferimento, senza successo.
Tralasciando il fatto che devo riconfigurare i client manualmente per impostare altri server NTP funzionanti, il problema si presenta con un tunnel IPv6 fornito da SixXS. Per chi non ne fosse a conoscenza, il login su SixXS verifica anche il timestamp dell'endpoint (in questo caso il Fritz!Box) e nel caso in cui diverga di oltre 60 secondi, la configurazione fallisce.
Dall'interfaccia web, disattivando e riattivando la sincronizzazione NTP (Rete domestica->Rete->Impostazioni di rete->Sincronizzazione dell'ora (NTP) attiva) l'orario viene sincronizzato (come verificato dal log eventi) ed il tunnel torna a funzionare, ma i client continuano a ricevere un timestamp errato e dopo 5-6 ore il tunnel cessa nuovamente di funzionare (probabilmente in 5-6 ore il clock hardware riesce ad andare avanti o indietro di oltre 60 secondi). Questo comportamento mi porta a pensare che il demone NTP sia effettivamente eseguito, ma dopo la prima sincronizzazione con i server esterni crashi. Da telnet ho esplorato il file system del Fritz!Box ma, oltre all'ar7.cfg, non ho trovato altri riferimenti al demone NTP.
Qualcuno ha notato lo stesso problema? Avete qualche hint per il debug dell'NTP da telnet?
da un paio di giorni ho aggiornato il 7390, che funzionava perfettamente col firmware 84.05.05, alla 84.05.06. Lì iniziano i problemi.
Con la 84.05.06 apparentemente il demone NTP ha smesso di funzionare. Questo è l'output che ottengo su un client configurato per prendere l'ora dal Fritz!Box:
- Codice:
remote refid st t when poll reach delay offset jitter
==============================================================================
xfritz.box LOCAL(1) 10 u 108 512 377 1.467 13.197 6258.04
Ovviamente le stesse impostazioni non creavano problemi col firmware precedente, ma per sicurezza ho già resettato e riconfigurato l'apparato, oltre ad aver cambiato i server NTP di riferimento, senza successo.
Tralasciando il fatto che devo riconfigurare i client manualmente per impostare altri server NTP funzionanti, il problema si presenta con un tunnel IPv6 fornito da SixXS. Per chi non ne fosse a conoscenza, il login su SixXS verifica anche il timestamp dell'endpoint (in questo caso il Fritz!Box) e nel caso in cui diverga di oltre 60 secondi, la configurazione fallisce.
Dall'interfaccia web, disattivando e riattivando la sincronizzazione NTP (Rete domestica->Rete->Impostazioni di rete->Sincronizzazione dell'ora (NTP) attiva) l'orario viene sincronizzato (come verificato dal log eventi) ed il tunnel torna a funzionare, ma i client continuano a ricevere un timestamp errato e dopo 5-6 ore il tunnel cessa nuovamente di funzionare (probabilmente in 5-6 ore il clock hardware riesce ad andare avanti o indietro di oltre 60 secondi). Questo comportamento mi porta a pensare che il demone NTP sia effettivamente eseguito, ma dopo la prima sincronizzazione con i server esterni crashi. Da telnet ho esplorato il file system del Fritz!Box ma, oltre all'ar7.cfg, non ho trovato altri riferimenti al demone NTP.
Qualcuno ha notato lo stesso problema? Avete qualche hint per il debug dell'NTP da telnet?
Ultima modifica di makitene il Sab Dic 10, 2011 12:33 am - modificato 1 volta. (Motivazione : fix italiano)