new update to busybox
cyberstorm
-gzip
-gunzip
-which
-awk
-find
-logread & circular buffer support
About this last option: now syslogd doesnt use anymore the file /var/
log/messages to write log, instead it uses a buffer that can be read
using the command "logread". This is for preventing the messages file
to become really fat and eat a lot of memory in case the router
remains uptime for a long period. The buffer size is setted to 16kB.
The log.c file has been slightly changed to allow to read log from
"logread". Using circular buffer you cannot clear the log, so the
clear log button losed its function. On the other side, why would you
clear the log if now the space it uses is limited?
There are still some traces of /var/log/messages in cron, I'll fix it
soon.
Also, I have applied the last patches by toneworks execpt the one
about adsl. Anyway I cannot see how is possible that the changes done
in status.c interferes with internet led activity.
cheers
marco
toneworks
> I have added these features:
>
> -gzip
> -gunzip
> -which
> -awk
> -find
> -logread & circular buffer support
I'm updating right now.
> There are still some traces of /var/log/messages in cron, I'll fix it
> soon.
NP.
> Anyway I cannot see how is possible that the changes done
> in status.c interferes with internet led activity.
It doesn't interfere. As i posted earlier it was my iptables update
causing the problem. When giving ps command, all procs after pid 58
didn't show up (seg fault). And guess what.. wanledctrl was pid 60.
That's why led was off for some secs. Anyway I'm 2-3 days up with my
latest build and it works with no problems.
There's another minor problem with a symlink from linksys source.
trunk/linux/linux-2.4.17_mvl21/net/ipsec/alg/perlasm should be linked
with ln -s ../../libcrypto/perlasm (wrong path).
Gotta compile now, c ya
Marco Vedovati
Hash: SHA1
Il giorno 13/apr/07, alle ore 16:04, toneworks ha scritto:
>
> There's another minor problem with a symlink from linksys source.
> trunk/linux/linux-2.4.17_mvl21/net/ipsec/alg/perlasm should be linked
> with ln -s ../../libcrypto/perlasm (wrong path).
>
> Gotta compile now, c ya
i think I have messed up something in svn trying to fixing it, and
now I have no time to repair it :(.
The working copy on svn is 143, the next are broken
see u
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)
iD8DBQFGH7Qq8PPSbh9Zs4YRAqhzAJ9Hu70JM48Jr3mCr5yV4CGMUpFG1QCfYpbT
xSOmsy6TRO1rc85D2+8ILxY=
=FxA1
-----END PGP SIGNATURE-----
cyberstorm
> i think I have messed up something in svn trying to fixing it, and
> now I have no time to repair it :(.
>
> The working copy on svn is 143, the next are broken
>
Ok it's fixed, you can update to the head version.
toneworks
I'm at #143 atm, tested changes as far as i could. All work great.
A thing that is not working, is snmp. That's not because of our job
but because of the changes in rc/snmpvar.c in 1.01.11. Simply put,
snmpd does not load when enabled in web interface.
I looked in 1.01.09 snmpvar.c to be sure about it and I was correct.
Start function has changed. I don't know if you use snmp a lot , I
don't. So I just copy/pasted the specific parts from one version to
another. If you do mind, you can try a better solution.
I also give you my tiny changes at monitor_ps.c.
http://users.forthnet.gr/her/gojira/snmpvar.c
http://users.forthnet.gr/her/gojira/monitor_ps.c
C ya
cyberstorm
ok, I will put you changes on the svn.
BTW, I uploaded on google groups 2 files, one about openwrt and one
about routertech. In those files you can find some interesting
parameters about kernel tuning, both memory and net. As you have said
some parameters of the official firmware are very bad, so we can take
some insipiration from these files.
toneworks
Atm I'm playing with qos. Imho it's quite crappy. I mean if you put it
in UBR, what it does is to read US rate from avsar_stats and it
believes that you have that upload rate! I am synced in 256 Kb upload
but my true up is 170-190kb at best. This means first priority class
gets all bandwidth when there's lot of use (it gets 75% of total
upstream).
Another crappy example is with http. If you put http priority at high,
all data in ports 80 travels faster. But to surf really fast, besides
port 80 you need port 53 (dns port). Who can surf without dns? I
tested it by downloading a linux iso from http (having http high
priority) and I was right. I couldn't view a single site because of
dns. When I added port 53 all was normal.
I'll see what I can do about these things first.
Marco Vedovati
Il giorno 16/apr/07, alle ore 16:34, toneworks ha scritto:
>
> I'll see what I can do about these things first.
you are always at work!
I know the pluto project has deeply worked on qos, check it there is
something interesting.
http://sourceforge.net/projects/project-pluto/
johna...@gmail.com
would like to know what you have changed and how you measure this
number.
toneworks
As you know, all changes are in svn. In simple words what has changed
is the way httpd reads pages. Instead of reading pages character by
character now it reads them using 4096 chars buffer.
The way speedup was measured is pretty simple: wget download all links
recursively.
Before changes it took ~14.5 secs to get finished. After changes it
took ~10 secs.
Anyway since you're already touching wag354g firmware, I can't see a
reason why not joining our efforts for a better firmware. Neptune has
space for everyone, especially for skilled guys like you.
Cheers
johna...@gmail.com
You know I am working on another effort to provide firmwares for
wag354g v1 and v2 in adslgr.com forums that solve common problems. The
firmwares I produce have the original functionality, I only try to
improve the quality and fix bugs. I think that features like ssh are
cool, but I don't believe an "ordinary" guy would ever use it, maybe
he don't even know what it is. Never mind, keep up the good work.
I see the patches for httpd are from the project-pluto mentioned
somewhere here. I have also tested it myself the way you said with
even better result. I wget the site in my firmware before the change
and it took ~13.5, after applying the patches it took ~4 !!!!! Really
impressive speedup! This gain goes not come from the way it reads the
files but because the asp processing was really optimized.
I think the project-pluto has many things to teach us all...
cyberstorm
On 19 Apr, 19:08, johnath...@gmail.com wrote:
> toneworks I have already contributed my knowledge to this project....
Hi Johnathana, I also hoped you could collaborate with this project,
because I've seen your contribute so far is useful. I dont aim to do
the boss, and I have no problems to give someone the ability to commit
in svn. About ssh, you are right most of the people dont even know
what is it, but I have added it with the goal of keeping it as
unobstrusive as possible. On the other side you could easily dont even
compile it in the firmware commenting it in cy_conf.h.
Anyway good luck with your project too
marco
toneworks
from pluto.
Since it was released as GPL, and we leave it that way I can't see any
problems on that.
Bored Individual is skilled at c, he's done some really good job. Most
(if not all) of the "lented" code is his.
Anyway pluto is a much older project that ours. For some time now it's
idle. Their two things I believe are useful to us are libpcap library
fix and iptables update. They have done some work in qos but it's not
yet completely fixed (and maybe it will never be).
Also stuff like ssh maybe aren't useful to most of people (eg. I don't
care about vpn, marco doesn't care about ntp, another user won't like
telnet) but what we try to do is a better firmware for all, not only
for ourselves. If you see neptune changelog, bug fixing is always a
high priority for us and that's what you do with your work too.
Whatever your decision is, good luck.