Weird dates and time stamps on old Linksys WAP11...

its firwmare

(9/2003). I don't use

whatever) and on a lot

I do. What happened is that Linksys hard coded some NTP (network time protocol) servers into the firmware. I think some of them went away about a year ago. Since then, the clock just uses the default date/time as it always fails to update.

Just for fun, I downloaded that 1.07 firmware image and ran it through strings to see if I could find the IP address. I couldn't find it.

Ummm, that's not suppose to happen.

to get back into

like SSID, IP

password, etc.

Well, duh, yes. If you do a hard reset, it clears everything, including the settings, back to the defaults. Did you try powering the WAP11 v2.6 on and off before resorting to a hard reset?

room (82 F degrees

It maxed out on Saturday at 103 to 115F (unofficial highs) in the hills above the Peoples Republic of Santa Cruz.

its firwmare

(9/2003). I don't use

whatever) and on a lot

Interesting. I didn't know it was using NTP. Which one was it? Can I have to use my local computers?

v1.07? I only saw v1.03. Where did you see that one? What's fixed?

Yeah. It was weird.

able to get back into

like SSID, IP

password, etc.

Right, but it should had erased EVERYTHING back to defaults, right? Not just half of them. I did power off and on before resetting.

room (82 F degrees

Heh. :)

with its firwmare

(...)

WAP11 v2.6 latest version is 1.07. See: |

Dunno. I couldn't find the IP's or names in the 1.07 image file.

Huh? I don't understand. The NTP in the WAP11 is to set its own date and time for logging and not to set those on your computer.

However, now that you asked, with Windoze XP, go to: Control Panel -> Date and Time -> Internet Time and change the time server from: time.windows.com to: us.pool.ntp.org Figure on a 10 second delay to synchronize.

half of them. I did

Yep. Everything. I recently had to reset two WAP54G v3.1 access points. Punch the reset button and EVERYTHING was back to defaults. Something might be blown in your unit.

On Thu, 27 Jul 2006 04:43:58 GMT, Jeff Liebermann wrote in :

Ugh. That's a crude DNS load balance of servers all over the place. Better to use good local servers. I personally use and recommend SymmTime 2006 , but if you must use Windoze, good open access servers in the SF Bay Area include:

• clock.fmt.he.net

• clock.sjc.he.net

• nist1.datum.com

• ntp-cup.external.hp.com

• nist1.aol-ca.truetime.com

with its firwmare

java.lang.IllegalArgumentException: Satellite Server request for page unable to proceed: (pagename is missing). Parameters: {childpagename=US/Layout, c=L_Download_C2, cid=11154171099$} at com.openmarket.Satellite.s.b(DashoA14174) at com.openmarket.Satellite.s.f(DashoA14174) at com.openmarket.Satellite.s.a(DashoA14174) at com.openmarket.Satellite.s.toString(DashoA14174) at java.lang.String.valueOf(Unknown Source) at java.lang.StringBuffer.append(Unknown Source) at com.openmarket.Satellite.c.execute(DashoA14174) at com.openmarket.Satellite.servlet.b.doGet(DashoA14174) at javax.servlet.http.HttpServlet.service(HttpServlet.java:115) at javax.servlet.http.HttpServlet.service(HttpServlet.java:92) at com.caucho.server.dispatch.ServletFilterChain.doFilter(ServletFilterChain.java:106) at com.caucho.server.webapp.WebAppFilterChain.doFilter(WebAppFilterChain.java:178) at com.caucho.server.dispatch.ServletInvocation.service(ServletInvocation.java:229) at com.caucho.server.hmux.HmuxRequest.handleRequest(HmuxRequest.java:419) at com.caucho.server.port.TcpConnection.run(TcpConnection.java:389) at com.caucho.util.ThreadPool.runTasks(ThreadPool.java:492) at com.caucho.util.ThreadPool.run(ThreadPool.java:425) at java.lang.Thread.run(Unknown Source)

Resin-3.0.18 (built Fri, 24 Feb 2006 02:47:03 PST)

I meant the older one. :)

Sorry, that is what I meant. I missed a word. "Can I have it..." Long day at work for me, today.

I meant for the WAP. :)

half of them. I did

Probably heat. :)

On Thu, 27 Jul 2006 00:25:14 -0500, snipped-for-privacy@zimage.com wrote in :

with its firwmare

snipped-for-privacy@zimage.com hath wroth:

John Navas posted one.

I posted the URL from my palatial office. I'm at home now and the ultra long URL works just fine on my home PC. Looks like Java is complaining. Check your Java version. Just go to:

John Navas hath wroth:

Crude but effective. The idea is to not burden the stratum 1 servers with NTP updates that don't require the ultimate in accuracy. I've switched to using the pool about a year ago and have had no problems.

Of course it's better. Whether it's necessary is dependent on whether you want your clock accurate to the nearest millisecond. If you can tolerate some more error, the pool is just fine.

Nice. I gotta try it.

It's a good idea to check if one needs to ask permission before using the servers. See:

Incidentally, this is from the WRT54G source code:

/* for NTP */ int do_ntp(void) { char ntp_servers[4][256] = { "time.nist.gov", "time.stdtime.gov.tw", "time.chttl.com.tw", "210.59.157.10", };

v2.6) with its firwmare

years (9/2003).

Thanks. Hmm, I guess I already havethis one. I thought I had v1.03. Heh.

It doesn't require Java. It was my newsreader (Tin) that couldn't word wrap the URL correctly.

On Wed, 26 Jul 2006 23:40:02 -0700, Jeff Liebermann wrote in :

I think it's a poor approach since it won't reliably result in a good server, and since subsequent updates may come from quite different servers, increasing time jitter and making clock drift correction less workable. Better to carefully pick your own server(s).

Different servers have different policies. Some Stratum 1 servers are restricted or closed; some are open to the public. Likewise Stratum 2.

Your need for time accuracy may be less stringent than mine. I've seen considerable time jitter when using the pool, resulting in excessive clock error (for my purposes at least). SymmTime (using Symmetricom time servers) gives me much better results.

The problem of PC clock drift is typically far greater than that -- I'd be very surprised if your standard PC clock is even accurate to the second. The default update period for Windows XP is a week, by which time a PC clock can easily have drifted several minutes, or more if the update couldn't be done on schedule. More frequent updates can help, but don't really solve the fundamental problem of clock drift. What's needed is software that accurately measures and continuously corrects for clock drift. Even with that, no better than 50 ms accuracy is about the best that can be expected of many (most?) PCs.

I think you'll find that it results in much more accurate system time with less clock drift. Be sure to disable the Windows XP time update when using SymmTime.

Of course -- I chose them carefully. :)

John Navas hath wroth:

Sure. A nearby time server and corrected clock makes more sense for time critical applications. NTP clients all have smooth transition features so there are no abrupt changes in time sync. I guess that's necessary for the nifty Symmetricom client, which updates the time once per hour. Were this client to use the NTP pool, then there would certainly be some jitter. However, were the client to only update once per day and when the machine starts, there would be no jitter and sufficient accuracy for most home users.

I usually use the NIST time sync software:

True. Totally non-critical. I do have some data loggers where the client insisted on accurate timing. Full time internet access was not available so I used a GPS clock sync program from the NEMA-183 output to the serial port.

How to change the XP internet time sync update interval. Start -> Run -> regedit Go unto:

HKEY_LOCAL_MACHINE\\SYSTEM\\ControlSet001\\Services\\W32Time\\TimeProviders\\NtpClient Select SpecialPollInterval Change the decimal value in seconds from 604800 to what seems like a good idea. I suggest: 172800 (2 days) or: 86400 (1 day) I wouldn't go much less than a day to avoid pounding on the designated NTP server.

I do agree that clock drift is a problem, especially if you're data logging. However, most users don't do that and even a few minutes of error is tolerable.

Drivel: Long ago, I decided to write my own GPS time sync program. It was running on an SCO Unix 3.2v4.2 box, which was also my NNTP news server and SNMP data collector. After my trademark absolute minimal debugging and zero testing process, it went live. Everything worked just fine until the HVAC repairman disconnected my rooftop GPS antenna while working on the A/C. The NEMA time string went to 00:00:00 and my server went insane. It took me weeks to clean up the mess. Lesson #1: Accurate time is important. Lesson #2: I should give up programming.

It correctly stopped "Windows Time" services and set it to "manual". Nicely done.

On Thu, 27 Jul 2006 10:18:14 -0700, Jeff Liebermann wrote in :

Not all by any means.

While that would reduce frequency of correction (period), it would almost certainly result in more, not less, jitter (amplitude).

While high time accuracy isn't needed much of the time for home users, it can be important, sometimes very important, so, given that high accuracy is so easy to achieve, I don't think it makes sense to compromise. Kind of like not wearing a seat belt because the chance of an accident is so low. ;)

I'm reminded of a client situation in which having the exact time something had occurred was very helpful in working out an online issue that otherwise could have been messy and/or expensive.

I think it's actually pretty crappy -- in addition to some annoying bugs/glitches, and abrupt clock changes, haven't you noticed how much jitter it has even when querying Stratum 1 servers over lightly-loaded broadband?

I think a good time client ought to be capable of picking an appropriate interval itself based on observed clock drift.