Problem getting logfiles written to USB stick

[tundrwd]

I'm having problems getting the logfiles written to the USB stick. The name of the USB stick is CRUZER1GB, and it mounts to /tmp/mnt/CRUZER1GB. Odd, the SMB sharing sees it as /mnt/CRUZER1GB. Anyway, error messages follow:

Aug 17 14:10:19 cstats[368]: Problem loading /mnt/CRUZER1GB/tomato_cstats_10bf48d454c8.gz. Still trying...
Aug 17 14:10:20 rstats[363]: Problem loading /mnt/CRUZER1GB/tomato_rstats_10bf48d454c8.gz. Still trying...
.
.
.
Aug 17 14:18:47 rstats[2188]: Problem loading /tmp/mnt/CRUZER1GB/tomato_rstats_10bf48d454c8.gz. Still trying...
Aug 17 14:18:47 cstats[2236]: Problem loading /tmp/mnt/CRUZER1GB/tomato_cstats_10bf48d454c8.gz. Still trying...​

telnet'ing in, and running mount, I can see:

admin@RT-N66U:/tmp/home/root# mount
rootfs on / type rootfs (rw)
/dev/root on / type squashfs (ro)
proc on /proc type proc (rw)
tmpfs on /tmp type tmpfs (rw)
devfs on /dev type tmpfs (rw,noatime)
sysfs on /sys type sysfs (rw)
devpts on /dev/pts type devpts (rw)
/dev/mtdblock4 on /jffs type jffs2 (rw,noatime)
usbfs on /proc/bus/usb type usbfs (rw)
/dev/sda1 on /tmp/mnt/CRUZER1GB type vfat (rw,nodev,noatime,fmask=0000,dmask=0000,codepage=cp437,iocharset=utf8,shortname=winnt,flush)​

So it's mounted read/write.

As you can see, I've tried entering both /mnt/CRUZER1GB and /tmp/mnt/CRUZER1GB both - neither work.

Any ideas as to the problem?

 

[joegreat]

As you can see, I've tried entering both /mnt/CRUZER1GB and /tmp/mnt/CRUZER1GB both - neither work.

Hi,

To make sure that you choose the right path, you can use the select button and pick the folder for the traffic logs.

And: Did you set the option to create the files?

[B]Web interface: Tools / Other Settings[/B]
Create or reset data files: Yes
[I](Enable if using a new location)[/I]

Sometime you need to set the option twice to yes and reboot...

With kind regards
Joe

 

[tundrwd]

Hi,

To make sure that you choose the right path, you can use the select button and pick the folder for the traffic logs.

And: Did you set the option to create the files?

[B]Web interface: Tools / Other Settings[/B]
Create or reset data files: Yes
[I](Enable if using a new location)[/I]

Sometime you need to set the option twice to yes and reboot...

With kind regards
Joe

Yep did those things first. Tried your last suggestion about "setting twice and rebooting". Did it 3 times - I can now see the stats file out there. Thanks!

 

[tundrwd]

Nope - spoke too soon.

The gzipped tar file gets initialized (i.e. "tomato_rstats_<id>.gz"), but I keep getting errors trying to write to it. I'll try to move it over to a USB hard drive (currently trying to use a USB key formatted FAT32, HD is formatted ext3), and see if that makes a difference.

 

[joegreat]

Nope - spoke too soon.

The gzipped tar file gets initialized (i.e. "tomato_rstats_<id>.gz"), but I keep getting errors trying to write to it. I'll try to move it over to a USB hard drive (currently trying to use a USB key formatted FAT32, HD is formatted ext3), and see if that makes a difference.

Hi,

OK. This WILL make the difference: Only ext2/3 filesystem type is supported here!

With kind regards
Joe

 

[tundrwd]

Hi,

OK. This WILL make the difference: Only ext2/3 filesystem type is supported here!

With kind regards
Joe

Not sure I ran across that anywhere. Merely that ext2/3 would be more robust, but not basically required.

 

[tundrwd]

Ok, more testing, and I've found some interesting things:

First, when I recreated/reinitialized the logs via the webui, it created a 62 byte gz file at the appropriate named location, named:

tomato_rstats_48d454c80000.gz

Just the one file. Looking deeper (i.e. paying more attention), to the error logs, they kept mentioning a file named - tomato_rstats_10bf48d454c8.gz.

It could never access the file named tomato_rstats_10bf48d454c8.gz simply because it didn't exist and was NOT initialized. That's after several reboots. Not sure where I've run across the 10bf48d454c8 hex string before, but I seem to recall it being used as some unique identifier of the router - or it seemed so. Other thing is that I ALSO ran across ANOTHER filename that was in error:

tomato_cstats_10bf48d454c8.gz

Note the cstats, instead of the rstats in the filename. One error was from the cstats process, the other from the rstats process. So - there were TWO files that were in error, yet only ONE file was created by the initialization.

So, I merely copied the tomato_rstats_48d454c80000.gz file to both tomato_rstats_10bf48d454c8.gz, and tomato_cstats_10bf48d454c8.gz, rebooted, and I have no further errors (to date).

It appears the initialization from the webui is NOT initializing the appropriate filename, nor is it creating BOTH files.

Again, I'm running version 3.0.0.4.372.31 of Merlin.

 

[tundrwd]

SMB sharing weirdness under 3.0.0.4.372.31

Ok, last night I had my router set up with an ext3 formatted disk connected to USB. The name of the volume (used tune2fs to label it), is "Media". There are several directories I created, "Music", "Movies", etc. on it.

Last night, I was able to connect, and map, a drive directly to it's volume name, or label. In other words, I could mount the root directory of that drive directly on my machine. Copied a bunch of files out to it (used rsync - no crash this time as I've had before - even with ext3 formatted volumes. So it may be that whatever else is going on, the Merlin firmware has done something to beef up stability with a USB mount - time will tell).

Ok - so it's working as that. I also set up last night an init-script to reboot the router at 4am every day (will probably change that to once a week later). Just to keep things "fresh".

However, when I access the system this morning - I can ONLY mount a directory on that volume - NOT the root. So I can not now see, or access the root directory of the shared volume - just individual directories. Not terribly convenient when you have to map to each individual directory, as opposed to the volume itself.

Now - I will say that this latest behavior is one I've seen with the original Asus firmware itself - map to directories on the volume, but not the root. I say that, as I was pleasantly surprised when I was able to mount the root of the volume after flashing the Merlin firmware.

Any ideas as to why it worked one way one time, and after a reboot (and no changes to the USB settings of the webui), it now behaves differently?

I'll probably try some NFS shares later today and see how well that works. Might be better anyway, since I'm mainly running *nix boxes (Mac, Linux).

 

[RMerlin]

Ok, more testing, and I've found some interesting things:

First, when I recreated/reinitialized the logs via the webui, it created a 62 byte gz file at the appropriate named location, named:

tomato_rstats_48d454c80000.gz

Just the one file. Looking deeper (i.e. paying more attention), to the error logs, they kept mentioning a file named - tomato_rstats_10bf48d454c8.gz.

It could never access the file named tomato_rstats_10bf48d454c8.gz simply because it didn't exist and was NOT initialized. That's after several reboots. Not sure where I've run across the 10bf48d454c8 hex string before, but I seem to recall it being used as some unique identifier of the router - or it seemed so. Other thing is that I ALSO ran across ANOTHER filename that was in error:

tomato_cstats_10bf48d454c8.gz

Note the cstats, instead of the rstats in the filename. One error was from the cstats process, the other from the rstats process. So - there were TWO files that were in error, yet only ONE file was created by the initialization.

So, I merely copied the tomato_rstats_48d454c80000.gz file to both tomato_rstats_10bf48d454c8.gz, and tomato_cstats_10bf48d454c8.gz, rebooted, and I have no further errors (to date).

It appears the initialization from the webui is NOT initializing the appropriate filename, nor is it creating BOTH files.

Again, I'm running version 3.0.0.4.372.31 of Merlin.

Are you doing any kind of fiddling with your MAC addresses? The same program that initializes the datafile also handles all access to it, so it's the same code used in both cases. The only thing I could think is if you have a script that changes your MAC address or your bridge configuration, it might confuse rstats. The firmware uses the MAC address stored in the "et0macaddr" nvram value.

Also, rstats and cstats are two different databases. The first is for regular traffic, the second is for IPTraffic, and must be separately initialized (same webui page).

 

[tundrwd]

Are you doing any kind of fiddling with your MAC addresses? The same program that initializes the datafile also handles all access to it, so it's the same code used in both cases. The only thing I could think is if you have a script that changes your MAC address or your bridge configuration, it might confuse rstats. The firmware uses the MAC address stored in the "et0macaddr" nvram value.

Also, rstats and cstats are two different databases. The first is for regular traffic, the second is for IPTraffic, and must be separately initialized (same webui page).

Haven't touched the MAC address. Just MAC addresses on DHCP leases.

 

[RMerlin]

Haven't touched the MAC address. Just MAC addresses on DHCP leases.

The one with "10bf" looks right to me (this is a valid Asus MAC), however the one with 48d4 is odd as it doesn't match any HW manufacturer in the OUI database.

Are you using one of the following?

- MAC cloning (check on the WAN page of the router)
- OpenVPN tunnel
- Non-router mode (repeater, media bridge, etc...)
- DualWAN

 

[tundrwd]

The one with "10bf" looks right to me (this is a valid Asus MAC), however the one with 48d4 is odd as it doesn't match any HW manufacturer in the OUI database.

Are you using one of the following?

- MAC cloning (check on the WAN page of the router)
- OpenVPN tunnel
- Non-router mode (repeater, media bridge, etc...)
- DualWAN

Only one of the above is the OpenVPN Client Tunnel. HOWEVER, I was still having problems with this PRIOR to setting up the VPN Client. And I might also mention a couple more things:

1. Only the ONE file - ..._rstats_.... was created. The ..._cstats_... file was NOT created.

2. While the date/time of the these files are now being touched, what is the format of the data in the file(s), once unzipped? (text, binary, etc.) What do I use to read/view the contents?

 

[RMerlin]

Only one of the above is the OpenVPN Client Tunnel. HOWEVER, I was still having problems with this PRIOR to setting up the VPN Client. And I might also mention a couple more things:

1. Only the ONE file - ..._rstats_.... was created. The ..._cstats_... file was NOT created.

2. While the date/time of the these files are now being touched, what is the format of the data in the file(s), once unzipped? (text, binary, etc.) What do I use to read/view the contents?

1) You must also select the option to create the database for IPTraffic - it is separate from the first option that will only create the database for the regular traffic (rstats)

2) It's a raw binary format, that isn't user-readable. It's parsed by the cstats/rstats programs, and the parsed data gets handled by the httpd daemon.

 

[tundrwd]

1) You must also select the option to create the database for IPTraffic - it is separate from the first option that will only create the database for the regular traffic (rstats)

2) It's a raw binary format, that isn't user-readable. It's parsed by the cstats/rstats programs, and the parsed data gets handled by the httpd daemon.

I'm sure I've done the first multiple times. I'll pay more attention the next time I need to do this, and watch.

Thanks for the info. The majority of my traffic monitoring has always been with a special box, or pre-configured software that does "everything for you" approach. I'll check into rstats/cstats and see. I'm sure whatever I've used in the past probably used them - I was just unaware of their use.

 

[RMerlin]

I'm sure I've done the first multiple times. I'll pay more attention the next time I need to do this, and watch.

Thanks for the info. The majority of my traffic monitoring has always been with a special box, or pre-configured software that does "everything for you" approach. I'll check into rstats/cstats and see. I'm sure whatever I've used in the past probably used them - I was just unaware of their use.

rstats and cstats were developped by Tomato devs (Jon Zarate and Augusto Bott, who based cstats on rstats) for Tomato, it's not a standalone software.

 

[tundrwd]

rstats and cstats were developped by Tomato devs (Jon Zarate and Augusto Bott, who based cstats on rstats) for Tomato, it's not a standalone software.

That explains why I've not heard of it, and why I can't find a "man page" on the 'net anywhere for either of them. I'm assuming then to view the results you would do:

rstats tomato_rstats_<macaddr>.gz
cstats tomato_cstats_<macaddr>.gz

Something like that? Or would I run that from the command line in "Tools"? so the resulting HTML would display on my browser?

 

[RMerlin]

That explains why I've not heard of it, and why I can't find a "man page" on the 'net anywhere for either of them. I'm assuming then to view the results you would do:

rstats tomato_rstats_<macaddr>.gz
cstats tomato_cstats_<macaddr>.gz

Something like that? Or would I run that from the command line in "Tools"? so the resulting HTML would display on my browser?

No. These two programs are services. When they run, they will read the datafiles, and listen to certain signals, which when received will make them dump the data into a file, which then gets processed by the httpd daemon.

 

[ddAk1mb0]

Thanks joegreat; I had noticed this pop up in my system log today and had briefly scratched my head. Such a simple fix but I hadn't noticed the option when I set the new location!

Now onto RMerlins SSID VPN script...