dslreports logo
site
 
    All Forums Hot Topics Gallery
spc

spacer




how-to block ads


Search Topic:
uniqs
4
share rss forum feed

Paralel

join:2011-03-24
Michigan, US
kudos:4
reply to rolande

Re: NVG589 modem / timestamp

said by rolande:

It is likely a mis-provisioned default config template on the device. i.e. You don't have any ability to configure as the option is probably fed from a static config file that is written to the device when it is imaged by AT&T. As far as I am aware, there is no "engineering mode" or interface that can be used to adjust the hidden config options locally. It can only be updated via a remote config push.


It is indeed possible to update this setting from the gateways command line locally. Actually, nearly every single aspect of the gateways config can be changed from the local command line, but it requires Telnet to be enabled, and, of course, it isn't, for obvious reasons.

I'm still waiting for someone to figure out how to enable it, just like they did with the NVG510. I tried the trick that is used on the NVG510, but, apparently, they "fixed" that "bug"...


rolande
Certifiable
Premium,Mod
join:2002-05-24
Dallas, TX
kudos:5
Reviews:
·ViaTalk

said by Paralel:

Actually, nearly every single aspect of the gateways config can be changed from the local command line, but it requires Telnet to be enabled, and, of course, it isn't, for obvious reasons.

Hence, why I said there is no engineering mode or interface accessible to adjust the local config options that are not accessible through the locked down web interface. The only known option is to have AT&T push a config down remotely.
--
Scott, CCIE #14618 Routing & Switching
»rolande.wordpress.com/


youtoo

@ameritech.net
reply to Paralel

I am going to go out on a limb here and bet that att has chosen to use Zulu as the standard time reporting on their network devices and they have the expectation that the customer equipment will have the ability to recognize and adjust the time accordingly. I'm not willing to hold my breath that you will get the time changed in the RG.



Msradell
P.E.
Premium
join:2008-12-25
Louisville, KY

said by youtoo :

I am going to go out on a limb here and bet that att has chosen to use Zulu as the standard time reporting on their network devices and they have the expectation that the customer equipment will have the ability to recognize and adjust the time accordingly. I'm not willing to hold my breath that you will get the time changed in the RG.

I don't believe this is the case because many users, myself included, don't have this problem. I have only been a few reported cases of this so like some of the earlier posters it seems like a corrupt or incorrect configuration file.


rolande
Certifiable
Premium,Mod
join:2002-05-24
Dallas, TX
kudos:5
Reviews:
·ViaTalk
reply to youtoo

said by youtoo :

I am going to go out on a limb here and bet that att has chosen to use Zulu as the standard time reporting on their network devices and they have the expectation that the customer equipment will have the ability to recognize and adjust the time accordingly.

I would feel safe betting that you are right on that as well. It is much easier for reporting and log correlation purposes to use a common time across all devices attached to a network. Customer facing services that rely on a device clock should have a separate presentation clock based on the local timezone.
--
Scott, CCIE #14618 Routing & Switching
»rolande.wordpress.com/

MrTorben

join:2004-12-14
Tampa, FL
reply to Paralel

have you tried to google: earlz.net nvg510


cramer
Premium
join:2007-04-10
Raleigh, NC
kudos:8

Yes, earlz found yet an other hole that AT&T will immediately patch (and remove/break) in the next release. "system.timezone" is where it's set. The provisioning server should be setting it once it connects. And yes, AT&T has access to set it. (or specifically, the auto-configuration server does) Why they aren't setting it, or it's not taking, is unknown.



mackey
Premium
join:2007-08-20
kudos:8

Between this and your other post on the subject you sound like you're actually mad he found a way to fix the stuff AT&T refuses to fix. And what's this "immediately" you speak of? It has been more then 15 months since the last firmware update was pushed (7/17/2012 was the last one) and the hack was known well before that update rolled out. People probably have at least a year before this hole is closed.

/M


cramer
Premium
join:2007-04-10
Raleigh, NC
kudos:8

Sort of. It's a game of whack-a-mole, and he's telling AT&T exactly where all the moles are. There are maybe two more iterations before there are no more (obvious) holes. And the NVG510 had an update recently. AT&T *does* have a desire to keep the system closed, so you're free to stick your head in the sand thinking they aren't paying any attention.

(If it weren't so much work, I'm sure AT&T would jump to the Swisscom "cloud" managed method: next to no configuration on the system itself, all configuration coming from the ISP TR-069 management systems.)