I am experimenting with experimental (!) on a couple of wrt54gs v1.1. I have found experimental release to work at most, but it still has some minor bugs, like /etc/group and /etc/passwd missing (this makes dropbear not so happy) and also missing parts in dropbear installation (that prevent scp from working).

I have fixed them myself because it's easy, but I'd like to report them to someone if it helps.

Where and to whom should I report the bugs I find?

Thanks to every developer for the great work!

You can post them in this thread, for example. The /etc/passwd, /etc/group issue will be fixed in the next snapshot.
Are there any other issues that need fixing?

This report applies to a WRT54GS v1.1 flashed with the experimental build dated 13/3/2005 with jffs2 file system and no squashfs. To this build I have added openvpn and dropbear packages from experimental repository.

Other than the missing passwd and group, I have found that:

- using scp (wrt is scp client, my home server is scp server) fails because there is no /usr/bin/dbclient file. making a symlink from /usr/sbin/dropbear to /usr/bin/dbclient makes scp work in client mode.

- after applying the previous patch, using scp (in client mode) fails if the remote host's key is not already known to dropbear, because when dropbear asks  if I want to continue connecting, it seems that it does not wait for the answer to the "y/n" question and somehow assumes I have hit "n".

Example:

root@gerbil:~# scp casa.kurgan.org:a .
WARNING: Ignoring unknown argument '-x'
WARNING: Ignoring unknown argument '-oForwardAgent no'
WARNING: Ignoring unknown argument '-oClearAllForwardings yes'

Host 'casa.kurgan.org' is not in the trusted hosts file.
(fingerprint md5 62:71:18:22:16:37:94:4e:7d:1e:4b:72:ea:85:88:6c)
Do you want to continue connecting? (y/n)
/usr/bin/dbclient: connection to root@casa.kurgan.org:22 exited: Didn't validate host key
root@gerbil:~#

A workaround for this issue is to ssh the the remote host first, accept the remote host key, and then when the key is already known to dropbear, you can also run scp.

- Scp does not work also in server mode. If I try to scp something from the wrt (thus wrt is the scp server)it fails because the file /usr/libexec/sftp-server is missing.

Example:

[c:]pscp root@192.168.1.1:a .
root@192.168.1.1's password:
ash: /usr/libexec/sftp-server: not found
unable to initialise SFTP: could not connect

- The openvpn package does not contain any configuration file (in /etc/openvpn) and also does not contain an init script to automatically run the vpns on boot. I know that the user can take care by himself of the configurations and init scripts, but at least making the directory /etc/openvpn and installing a startup script in init.d should be a good idea.

More bugs to come if I find them.

Thanks a lot for your bug reports.
I think, I have fixed these issues now. The passwd and group files will be in the next snapshot of experimental and I have uploaded new packages here: http://nbd.vd-s.ath.cx/openwrt/packages/

If you find more bugs, just keep posting in this thread and I'll try to fix them.

An hosts file would be nice too

I am currenty using http://www.openwrt.org/downloads/experi … /packages/ as my "official" repository for experimental packages.

Is your personal repository some unofficial one, or are your packages going to be included in the official one?

I see that you have more packages than the one I am currently using.

Sorry if I make stupid questions, I'm new to openwrt and its developers community.

My package repository is unofficial, because it is built from newer CVS sources rather than current experimental snapshot. So yes, all the stuff in there will make it into the next snapshot. The reason I'm keeping it is, that people can try some newer stuff to see if all the bugs are fixed and to try out newer packages, so we don't get the same bug reports over and over again.

Thanks, I'll use your repository, then.

And then maybe I'll get the CVS tree and try to compile the whole thing myself just to try the latest versions available.

The CVS isn't public yet, so you'll have to wait for the snapshots.

I am just retesting things.

I have removed and then reinstalled dropbear. Now the "Do you want to continue connecting?" prompt in scp client waits for the answer and seems to work.

The symlink from /usr/bin/dbclient to /usr/sbin/dropbear gets correctly created, so scp client works properly.

It seems that /usr/libexec/sftp-server is still missing, so the scp server on the WRT is still not working. Is this sftp-server part of the dropbear package or not? As far as I have understood it seems that dropbear can be called only as:

'dropbear' - the Dropbear server
'dbclient' or 'ssh' - the Dropbear client
'dropbearkey' - the key generator
'dropbearconvert' - the key converter
'scp' - secure copy

but no sftp-server. Do I need another package?

There's no sftp server in dropbear.
That you can't use scp is putty's fault, not dropbear's. With openssh on my linux box, I can use scp on the router or on the linux box to the router without any problems.

Thanks nbd, the sftp issue is clear now.

About the kernel messages, it should be a good idea to disable the message that says "loading this module will taint the kernel". This message, which is displayed (obviously) every time the modules from the original WRT distribution are loaded (et, wl) makes reading the initialization messages a little difficult. I know the purpose of that message, but in this envinronment in which we NEED to use modules from Linksys, it's just annoying and nothing more.

May I ask, when public CVS will be available? Can't the CVS space of http://sourceforge.net/projects/openwrt be used for that matter?

Just woundering.

there is also a pptp package, so i would like to ask if  this would solve my problem described in http://www.openwrt.org/forum/viewtopic.php?t=1161
???

thanks a lot - dryades

I am playing with the wlan... setting SSID does not work! I have found the following nvram variables that somehow refer to ssid:

wl_ap_ssid
wl0_ap_ssid
wl0_ssid
wl_ssid

I have tried stting every value to something different than "linksys", committed, even rebooted, but the ssid is still "linksys".

I thought that the right one was "wl0_ssid", but maybe I am wrong or there's a bug.

UPDATE: my client was wrong. The ssid gets set by wl0_ssid as it is supposed to be.

When will this be public? I was working on adding Openswan to the buildroot packages. Gmp is a pre requirement...so I started adding gmp before finishing off the Openswan porition only to notice you had it up in your experimental and listed as in the buildroot. Low and behold I come across this thread that explains it!

I'd rather not waste time on things that have already been done....can we please have access to the experimental CVS repository? As it is now, I am not going to bother with experimental unless I can have that access....I do not wish to have to redo, or submit a broken patch to add Openswan after the CVS buildroot gmp doesn't coincide with the one I create.

I won't be wasting my time on this since I now know gmp is in CVS. So, do you want help?!

I have no problem sumitting a patch after (that was the idea - it is far easier to hack Openswan into an ipkg than create it within buildroot), but only if I'm in sync with the current codebase.

Dan

I am working on openswan, too. I agree with you and hope we will have experimental public really soon.

Sunshine!

wbx

Using the experimental code (all four versions of the binary possible for a wrt54g 1.0 at this point, i.e. 050313 and 050328 squashfs and jffs2), I can cause it to reboot:

I'm using wds, and pinging the opposing wds AP from a client that's going through my experimental AP.

Basically, all I have to do is ping it with very large packets: 7000 or so bytes seems to work, 9000 will cause the unit to fail almost instantly.

This is on a wrt54g_v1.0.  Previous stable (snapshot 20050202)  had no issues with my large packet test (I was able to run it for more than 24 hours with no packet loss on the older experimental binaries).

My wrt54gs v1.1 and wrt54g v2.0 running experimental 050328 (jffs2) have no issues with large packets through a wds link between themselves.

Yes, my wrt54g 1.0's are for sale :-)  inquire on irc.

[CORRECTION PUT IN - Found out my testing where it works was using stable.]
[ADDITIONS PUT IN - more test cases to verify that I wasn't on crack, also verified that wrt54g v2.0 and wrt54gs v1.1 handle the large packet test without issues)

Using both the Mar 13 and Mar 28 experimental, WRT54GS v. 2 (brand new, just got it this weekend)

I get a segfault and kernel oops in tc, usually when running wondershaper more than once. I'm using the package from openwrt.org.

kernel log from the 2005-03-28 image below:

Unable to handle kernel paging request at virtual address 00000414, epc == 800dac90, ra == 800db8c0
Oops in fault.c::do_page_fault, line 206:
$0 : 00000000 80200000 00000018 00000400 00000000 00010000 81abfcb0 00000014
$8 : 00000030 8013fa80 00000523 00000528 00000504 0000045c 81abfe88 00000509
$16: 00000000 8019ff80 81fda800 81fda810 81075e00 ffffffff 00000000 81fda800
$24: 00000000 00000000                   81abe000 81abfc50 81abfcb0 800db8c0
Hi : 00000000
Lo : 00000800
epc   : 800dac90    Tainted: P
Status: 1000fc03
Cause : 00000008
PrId  : 00029007
Process tc (pid: 1663, stackpage=81abe000)
Stack:    c0184180 00000006 00002000 81abfc90 00000460 801feeb8 801499ac
80213920 8035c220 8019ff80 81fda800 00000005 81066088 000000a0 0000045c
81abfce0 81abfcb0 800d7040 8035c220 00000000 8011ff24 81abfd80 00000000
1000fc00 81fda824 81fda82c 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 0041d994 81066040
8035c220 ...
Call Trace:   [<c0184180>] [<801499ac>] [<800d7040>] [<8011ff24>] [<800e02e4>]
[<800dfa00>] [<800e00d8>] [<800c6d84>] [<80022478>] [<800c8234>] [<800c83c0>]
[<800ded54>] [<800227ec>] [<800227b4>] [<800c7d78>] [<800c7d6c>] [<800cf7ec>]
[<800c8b18>] [<800c6a10>] [<800c696c>] [<800c6be0>] [<800084a0>]

Code: 8c8300dc  10600007  00002021 <8c620014> 10450004  00602021  8c630010  1460fffb  00002021

thanks for reporting.

can you provide your configuration files and all steps needed to reproduce this.

I have no clue about tc, but have an idea where to look at and would debug this if you give me the needed information.

thx and Sunshine!

It appears to have crashed in qdisc_lookup

I'm not sure what configuration pieces would be useful here other than what I posted already. My ipchains setup isn't too complicated, just a couple of port forwards. The packages I added include dropbear, strace, and tcpdump. I'm using a static IP

I cleaned out the router, and the following steps seem to be enough to retrigger the problem:

ipkg install wondershaper (installs kmod-sched and tc as dependencies. complains about sched-modules, but I imagine this is covered by kmod-sched)

edited the /usr/sbin/wshaper script to match my upload and download speeds (probably irrelevant)

Reboot (it runs /usr/sbin/sch_modules and /usr/sbin/wshaper. The reboot isn't necessary, it fails either way as long as the scripts above are run)

Run sh -x /usr/sbin/wshaper (sh -x not required of course, but useful for debugging)

Here's where it starts to get upset. 3rd tc command:
+ tc qdisc add dev vlan1 root handle 1: cbq avpkt 1000 bandwidth 10mbit
Segmentation fault

(in other iterations I confirmed that the command above triggered the oops I pasted)

Then it hangs on the next command:
+ tc class add dev vlan1 parent 1: classid 1:1 cbq rate 575kbit allot 1500 prio 5 bounded isolated

until I ^C.

I have just found that if I install the openntpd package (ver 3.6.1p1-1) and then I boot the WRT without internet connection, the init script for ntpd (S49ntpd) hangs forever trying to connect to the ntp server (actually it seems to hang on dns resolution for the ntpd server). I am unable to login from telnet, ssh, or serial line.

Myabe a simple modification to S49nptd should solve this issue.

#!/bin/sh
mkdir -p `grep "^ntp:" /etc/passwd | cut -d: -f6`
/usr/sbin/ntpd -s &

Simply putting and "&" at the end of the last line allows the boot process to continue even if ntpd cannot connect to the ntp server, and I think it should not do any harm. You simply end up with a wrong clock, that should anyway get the correct time as soon as ntpd can connect to the ntp server. (just tried it)

There should also be a way to enable a terminal (on the serial port or using telnet) even if some of the init.d scripts locks up. Or maybe there is one already but I don't know about it...

Maybe it should also be a good idea to have every init.d script echo something on the console (the serial port?) when it starts and it ends, so that if something goes wrong it's easy to find where the problem is.

Why not setup a real bugtracker? Or simply use the one at sourceforge? Personally I find the forums extremely annoying as they are a combined knowledge base / bugtracker / rant/chat / documentation system with way too much noise to find anything useful and organized in it.

S.

Has anyone else seen router crashes under heavy transfers between
two wireless hosts?

After my wrt53g 2.2 has been up for a few hours, doing heavy wirelessB
moves (rsync) between two hosts causes a reboot of the router.  Enabing
remote syslog and/or following the logs hasn't yet given me much info --
things die suddenly and the router reboots.  I'm running the latest
experimental build, but it also happened with the previous exp build
and with Rodent's build.

Sorry I don't have much info.  I have a second 2.2 wrt still in the box,
so when I have time I'll try things there and see if it is specific to the
router I have in "production".  But thought I'd post in case someone else
is also seeing the same problems.

--
Dale