Netgear DG834 emailing with wrong month!

[stduc]

I have a Netgear DG834 v1 modem/router that works just fine.

I have it email me its log on a daily basis.

Suddenly in July it started emailing me using the wrong month!
For example today, the email said
Date: Fri,28 Aug 2006 06:00:00 -0000 (GMT Daylight Time)


It has the correct date & time. Individual lines in the email noting events, have the correct timestamp. It simply insists that it is August. It has to be an internal look up table issue as the day is correct (for July) and the year is correct. It just writes in August and not July!!!!!

The Firmware Version is V3.01.25
The ADSL firmware version is 4.01.02.00

Both the latest available I believe.

I could treat it as a joke and of no importance except that if the look up table is incorrect what is going to happen next month and what will happen in December? Will the router crash because it will try to reference an entry in the look up table that does not exist and get an internal error?

I have contacted Netgear but beyond suggesting I re-boot the router (I have) they have nothing more to say.

So is anyone else experiencing this?
Does anyone have a solution?

 

[stduc]

I'm too lazy LOL - Because of the kids I have many port blocks (out) & blocked sites. It would be a long job to key it all in again.

The first update I just tried making a backup and then restoring it after the upgrade. It seems to work well. So all settings are back in place in a matter of seconds.

 

[BionicJohn]

because of the kids I have many port blocks (out) & blocked sites. It would be a long job to key it all in again.

Ah! There's nowt blocked here so it's easier to retype my U/N and P/W than restore!


LIVERPOOL FC - FA Cup Winners 2006.
Iechyd da! John
Glannau Mersi, Lloegr.

 

[gio2006]

It looks like I have wasted more time ...
I did a number of tests (all time-consuming), and the final results are all the same: the date problem cannot be fixed. I had another message from NG saying that "Based on the complexity of this case, it may be appropriate ... to seek additional resources... escalating your case to the next level for further review and response". Will see.
For general information, these are the steps I had some positive results with:
1) Uploaded Firmware V1.03.30 to 834
2) Hard-reset
3) Power-cycle
4) Configure ADSL on 834 Web Interface
5) Re-configure Wireless from Disabled to WPA-PSK

Up to this point, no joy with the email date, and NO wireless connection with my PDAs. They would connect only if Disabled, or WEP. As the laptop was working wirelessly, I thought it could be the PDAs' drivers.
So I uploaded firmware V1.03.18 and restored backup. WPA-PSK now works. Date problem still there.
I decided to stay put at V18, even if the logs don't seem to log failed logins to the router (another new "feature" I have found).
I tried to send the logs to a Syslog server as a work-around and I have been able to send them to a Linux syslog. As the date of the events is correct, the logs are manageable.
I may try to test this also with a Windows Syslog (if you want to try a free download can be found for example at

http://www.kiwisyslog.com/downloads.php

).

 

[gio2006]

I forgot to add that I even tried to use the restore utility downloaded from the NG site. This is to be used in case a firmware upgrade fails, as it erase the EEPROM, and resets ALL.

Goes without mention that the utility didn't even work!

 

[gio2006]

And also I forgot to add that the email date in my case is always 1/1/1970.

 

[DaveKb9]

I may be wrong but isn't 1/1/70 a "standard" reference date suggesting that whatever programme is responding with that date is actualy defaulting to its reference base. If so it seems that the programme is not actually receving an updated date so you may need to enforce a time synch.

 

[stduc]

I suspect the date of 1/1/1970 might be the email programs default date when it can't decrypt the date properly.

[navy]gio2006[/navy] Can you change the router config to send the email to another address, such as a hotmail account and report back what happens?

If I look at the email headers then in December the detail reports this.

Delivery-date: Thu, 30 Nov 2006 07:00:25 +0000
Date: Thu,30 Dec 2006 07:00:01 -0000

and Eudora reports 30/12/2006 is the message folder window

Now we are in December

The header details show

Delivery-date: Sat, 09 Dec 2006 07:00:10 +0000
Date: Sat,9 (null) 2006 07:00:00 -0000

and Eudora shows nothing in the date field of the message folder window.

I think the clue is in the (null) !!!!!!!!!!!!!!!

The actual detail lines are fine - such as

Fri, 2006-12-08 18:24:28 - TCP Packet - Source:192.168.0.42,1860 Destination:nat443.national-net.com,80 - [BLOCK]

Proving the router has successfully time synced with a time server.

As soon as I get a moment I am going to try setting up that suggested syslog server. But can anyone tell me what is likely to happen when the syslog server is not available? The advantage of using email is that you can turn your PC off!

 

[BionicJohn]

gio2006 - I think the date issue can be resolved by getting the router to update the date from an NTP server.

I say that because the log which is generated after rebooting my DG834 router shows the call to the NTP server and the date being corrected to the current date and time.
It is this date which is not correctly translated to e-mail headers.

My default date is 08/09/2002 (and you can also see the time server's address):

However, if your router's call to the time server doesn't update the router, then it seems to me there's a serious fault.

LIVERPOOL FC - FA Cup Winners 2006.
Iechyd da! John
Glannau Mersi, Lloegr.

 

[gio2006]

The 1/1/70 date is all computers' beginning date (basically is the year 0 of computing).
I tend to agree that the date from the router is not correctly interpreted by the email client. But the problem is with the router, as I have tried other email addresses and also reading the messages through Webmail, which I believe is equivalent to hotmail .
The date and time for all events is correct within the email, and so is the time synch with the netgear timeserver (default) at boot time, which changes my base date of 2000-01-01 00:00 to the current one.

Now ... I have just noticed the coincidence with my base date: the Millennium!!! I think my router has the Y2K bug !!
These symptoms (reverting to the Computing Age 0) were among the dreaded ones in all Y2K projects. Maybe I should let Support know ....

I did have the issue of the month difference you all have as soon as I powered up my router (from new) for the first time. After I upgraded to V1.03.30 it looks as if this problem was completely "fixed" ... by always displaying the same date for all emails ....
Regressing to V1.03.18 has not replicated the original problem, so I suspect that the change was permanent after upgrade to V1.03.30. :-(
I should test V1.03.25 as well, but to be honest, I have no more time to waste. I'll stick with what I have now, and I will be waiting for further findings. Netgear Support have come back to me with another suggestion: use the Erase from the Backup Setting of the router, which can be accessed as below:

1)Login to the router configuration page using 192.168.1.1 or

http://www.routerlogin.com/basicsetting.htm

The private address is not the default DG834 address and the html address is a legittimate web address (nothing to do with my router!), ... not sure what Support are talking about here.

However, I had tried the Erase already, so I 'll have to wait further.
As far as the syslog is concerned, the messages should stay on the router and will be emailed as well, so the logs will not get lost if the syslog is switched off. ;-)
I need to double-check this, but I think that is the correct behaviour.

 

[Homerz]

Just to add a MeToo.

I'm using a DG834GT and experiencing the same date problem with emailed logs.

I already raised a ticket at Netgear months ago, and went through the usual reboot/firmware nonsense to no effect. My last correspondence from them actually stated that they *might be* working on new firmware:

######
10/9/2006 9:15:00 AM
Dear Customer,

The case has been escalated to the relevant department and the issue is being looked into, there may shortly be a firmware release which solves this problem, please periodically visit our website to check for the latest updates.


Regards,
Netgear Support
######

Two months later ... zzzzz (Don't hold your breath).

It's obviously a bug in the routers MTA (a program called "smtpclient"). How hard can it be to fix, especially as AFAIK it's a FOSS MTA running on linux?

I know there's a way to hack into this thing via telnet, so maybe there's a way to upgrade the MTA independently:

Try this from a browser:

http://192.168.0.1/setup.cgi?todo=debug

Then this from the command line:

telnet 192.168.0.1

Also read:

http://www.suburbia.com.au/~dan/

http://walliteam.com/dg834/

Looks like the hacker/Linux community will come up with a solution before Netgear ... LOL!

 

[Homerz]

I just telnet'ed into my router, and tried the following:

# usr/sbin/smtpc
==========================================================
Usage: ./smtpc [m:s:f:r:h:U:v] < files
-m mime type
-s subject
-f from addr (if NULL use recipient)
-r recipient
-h mail server
-p mail port (default=25)
-U user name (ESMTP)
-P password (ESMTP)
-v verbose (DEBUG)
========================================================

I'll have a play around with it and see what results I get. Perhaps there's something in the /etc directory I can change to fix its current b0rken behaviour. We'll see.

 

[Homerz]

Well I just manually sent myself a test message with the router's smtp client, and it worked ... even the date was correct:

# usr/sbin/smtpc -s Hello -r <xxxx>@<xxxx>.com -h <xxxx> -U <xxxx> -P <xxxx> -v
server->220 <xxxx> ESMTP Postfix
server <-- EHLO unknown
server->250-<xxxx>
server->250-PIPELINING
server->250-SIZE 20000000
server->250-VRFY
server->250-ETRN
server->250-XVERP
server->250 8BITMIME
need_auth==0
server <-- MAIL FROM: <xxxx>
server->250 Ok
server <-- RCPT TO: <xxxx>
server->250 Ok
server <-- DATA
server->354 End data with <CR><LF>.<CR><LF>
This is a test
server <-- .
server->250 Ok: queued as 40FEF2B6C96
server <-- QUIT
server->221 Bye
Send E-mail Success!
#

The received message does indeed have the correct date and time????

This is just plain weird. The only thing I can think of is that the router is using a script to take the log file and pass it to smtpclient, and it is that *script* that has an error in it, but why it worked before (until earlier this year) and not now, I just don't know.

Hmmm, more investigation required. Watch this space.

 

[Homerz]

Getting closer...

The radio button (on the "Logs" page of the router) labeled "Send Log" runs this javascript function:

function sendLog()
{
if(! is_email_on())
return;
stdAction(document.forms[0],'sendlog');
}

The stdAction() function is part of an external javascript called linux.js on the router. Here's a copy I uploaded to my website:

http://slated.org/files/linux.js

The last piece of the puzzle is some debugger output to determine exactly what form data is being passed to that function, but that's where my javascript skills end I'm afraid.

If someone else wants to run with this all the way, and hopefully find a solution, then good luck.

Meanwhile, I'm going to contribute my findings to the Netgear forum, and see what else turns up.

 

[stduc]

I tried using smptp on the router via telnet - This is my result. What am I doing wrong?



# usr/sbin/smtpc -s router mail test -r x@y.com -h smtp.zzzz.net -v
server->220 smtp.zzzz.net ESMTP
server <-- HELO unknown
server->250 smtp.zzzz.net
need_auth==0
server <-- MAIL FROM: <x@y.com>
server->250 sender <x@y.com > ok
server <-- RCPT TO: <x@y.com >
server->250 recipient <x@y.com > ok
server <-- DATA
server->354 go ahead
This is a test

.

Alarm clock
#

 

[Homerz]

<CTRL>d terminates and sends the message.

It's a UNIX thang

 

[stduc]

Thanks for that - I need to use <Ctrl>D twice though!

I can confirm that the email has the correct time / date with this method.

Date string is

Date: Mon, 11 Dec 2006 10:01:14 GMT

rather than

Date: Mon,11 (null) 2006 07:00:01 -0000



Please note the (null) where the month string should be. I am sure that this is the real cause of the problem. Not a Y2K issue!

 

[gio2006]

Yes. It's not a Y2K issue. I was just thinking loud when I mentioned it.
I have sent a message from the command line, and the date is correct with this method (thanks to Homerz for the tip on CLI access to the router OS).

I have actually noticed that the root filesystem is dated 1/1/1970 and looks like this:
drwxr-xr-x 1 0 0 452 Jan 1 1970 bin
drwxr-xr-x 1 0 0 0 Dec 11 11:42 dev
lrwxrwxrwx 1 0 0 8 Jan 1 1970 etc -> /tmp/etc
drwxr-xr-x 1 0 0 784 Jan 1 1970 lib
dr-xr-xr-x 42 0 0 0 Dec 11 11:42 proc
drwxr-xr-x 1 0 0 176 Jan 1 1970 sbin
drwxr-xr-x 4 0 0 0 Dec 11 12:48 tmp
drwxr-xr-x 1 0 0 116 Jan 1 1970 usr
lrwxrwxrwx 1 0 0 8 Jan 1 1970 var -> /tmp/var
lrwxrwxrwx 1 0 0 8 Jan 1 1970

http://www ->

/tmp/www
drwxr-xr-x 1 0 0 3908 Jan 1 1970

http://www.deu

drwxr-xr-x 1 0 0 3932 Jan 1 1970

http://www.eng

drwxr-xr-x 1 0 0 3848 Jan 1 1970

http://www.fre

drwxr-xr-x 1 0 0 3900 Jan 1 1970

http://www.ita

#

The current dates are a result of my touch * execution, whereas /tmp was updated by some other changes on the web interface.
All the filesystems I couldn't change are read-only, hence the dates are 1/1/1970.

Some other files which are not timestamped with the current date are dated 1/1/2000, which seems to be my base date.
I'll look further in this direction.

 

[gio2006]

I think the date problem may have something to do with the mail_sendlog call in setup.cgi script

 

[Homerz]

If you look at the available options for smtpc, you'll see that there is no way to specify a date (this is normal ... smtp gets its date from the system clock), so that leaves two possibilities. Either the system clock is wrong, or smtpc is receiving malformed data which subsequently corrupts the message headers.

Although the Linux OS installed on the router (uCLinux, I believe) does not include the "date" program, I can see from the web manager that the time and date is correct, and indeed sending an email manually using smtpc results in a message with the correct date header.

So the only remaining possibility (IMHO) is that the data being passed to smtpc by sendLog() is corrupt. It could be that somewhere along the line (firmware updates) that the log format changed, or perhaps the character encoding (UTF-8). If smtpc receives an unhandled illegal character then it may very well cause this kind of corruption in the headers.

Smtpc (like most software that accepts arguments from STDIN) will take a redirected file as input (this is exactly how the log files are being sent). Assuming that the sendLog() function is not further formating the output before sending it to smtpc, then it should be possible to simulate a Log-send manually and diagnose the results. This is what I propose to do.

I hope to be able to reproduce the error manually, and discover exactly what the problem is. Coming up with a solution is another matter though, that's up to Netgear.

 

[Homerz]

OK so manually sending the log file works, and has the correct date:

smtpc -m text/plain -s "NETGEAR Security Log [53:73:9F]" -r <xxxx>@<xxxx>.com -h <xxxx>.com -v </var/log/messages

However, sending logs from the webpage, or allowing crond to send at preset times, results in a malformed date header. AFAICT this date header is being injected by the script and is not RFC822 compliant.

The correct format is:

"Mon, 11 Dec 2006 20:13:20 +0000 (GMT)".

So for example, an old format like:

"12/11/2006 8:13:00 PM", is wrong.

What seems to be getting messed up is the month field:

"Mon, 11 (null) 2006 20:13:20 -0000"

So what value is (null)? 12? December? Blank? Given that the months have recently been one month ahead (i.e. September's emails were dated October, etc), the (null) value is probably 13, which would account for the malformed date.

I don't understand how a simple 12 value lookup table can go out of bounds like this. It's a simple 1->1 relationship, and there shouldn't be any addition operators to cause it to spin off into infinity like that.

Anyway, whichever script is doing the damage, there's precious little we can do except wait for Netgear to fix it.

/me holds breath.