Yes the router will keep a record of the duration of time in days, hours, minutes and seconds since the last boot but the actual time of day may revert to the default factory setting if the the PPP link is down due to it's inability to synchronise to a time server and thus is unable to display the actual time of day, i.e. GMT or BST.

After a reboot the router log will show the DSL is up and PPP link is up and then after some time displaying events in only minutes and seconds the router will synchronise to a SNPT server and then display the actual time of day. A loss of the PPP link can result in a similar thing where only minutes and seconds of duration are displayed until the actual time of day is synchronised.

Edited by 4M2 (Mon 08-Apr-13 14:51:26)

Well, I am sorry, but never in all my years of computing have I seen a (adsl)modem/router or such device change date to 'many years ago' because it wasn't on line.

Nick

Since we don't have access to the OP's router then the reason for "...reported the time in its log as Jan 1 2003" is entirely speculative but it does appear that the router reverted to some kind of factory default date/time when the PPP link was down

On routers I see a lot of midnight times with a date of 01/01/longago ie they don't keep time through a reboot and rely on NTP for current time. Whether that is tied up with a reset of PPP I don't know - will have a play.

OK, but forget the reboot - why (supposedly) does a adsl modem/router reset the date/time if it disconnects?

That to me is pants, and I have never seen it happen?

Could the OP be seeing a crash on the router causing it to reboot in an uncertain state?

Nick

completely conceivable that the software is written to reset the clock when it negotiates a PPP session. No idea if this is the case, but possible. A bug perhaps - resets the system clock instead of a timer. Conceptually possible.

Perhaps the thing does indeed crash all or part of the code and that's what drops the PPP session although the modem part continues to be in sync. In the log file posted above the date/time didn't reset with the loss of IP .

Most routers get power cycled or reset when they're misbehaving so the log files with the evidence are lost and the system time with it.

Time Configuration
Time Source: Automatic
Date: 08-04-2013
Time: 17:36:03
Timezone: (UTC)GMT:Dublin,Edinburgh,London
Summer Time: No
Time Since Power-on: 3 days, 8:21:35
Time Server 1: 212.159.6.10

I leave my router like that - it's happier that way, however I do have generic firmware and software variant: AA

Some may also deliberatly keep PPP up to preserve their ip, as some isp's treat ip's like the dialup days setting a new ip on every new ppp session.

I actually think its wrong to use PPP to monitor stability and using IP profiles likewise to monitor speeds. Of course this problem will originate from the fact openreach, BT wholesale and the retail isp are all seperate entities so generally would require sharing of sync information to the isp's.

This all theoretically can be shared as we already know openreach provide sync speed to BT wholesale (so IP profile can be set) and that the dslam somehow shares the sync information with an external system otherwise DLM wouldnt work. I just dont think its in BT's interest to share it, and the isp's probably wouldnt want it either as would confuse tech support staff.

I am quite suprised that no one has so far suggested asking the ISP to manually set the target margins, and disable DLM as ISP's can now and also make sure the IP profile is set up and correct for the sync afterwards do this with BT wholesale adsl2 + products, Saves the all the faffing around waiting for this and that to maybe happen ect ect, and runing a risk of ending up with a call out bill from BT

As for the PPP session timing out, this can be down to the radius servers working incorrectly,

Edited by tommy45 (Tue 09-Apr-13 04:45:33)

ISPs receive sync speed information via delta reports (ADSL) or in the PPP header (FTTC) don't they ?