So, r19544 loaded into my WRT350Nv2
I have almost decided to load the original linksys bits as my wrt is now working as dumb access point (bought mikrotik router for main gateway ) but it doesn't talk to cisco wifi phone so decided to load openwrt back where everything goes smooth.

So far, so good - wifi n-mode set as default, only luci-admin-mini and luci-theme-openwrt added. We will see if network drops would come back.

dirkNL:
The wifi led is not working - using today's maddes compilation (power led not tested, just lights green as usual)

(Last edited by domadm on 8 Feb 2010, 17:00)

@sala:
Don't know. Never cared about jumbo packages. But as the packages are up-to-date it should be possible to enable. Search the wiki and forum for related information.

@domadm:
Good luck

@DirkNL:
Just checked. Your LED patch was not included.
Builds of newer r19554 with the LED patch are uploaded.
So everybody can add and test Dirk's UCI additions.

About adding it to trunk:
Where will the uci config be put without overwriting other settings?
Otherwise using /etc/uci-defaults is also possible.

I sent the following to the OpenWrt developer mailing list, let's see what the answers will be.

I want to add the following setup to /etc/config/system for the Orion
router WRT350Nv2:

config led
        option sysfs    'wrt350nv2:green:power'
        option default  1

config led
        option dev      wlan0
        option sysfs    'wrt350nv2:green:wireless'
        option mode     'link tx rx'
        option trigger  netdev

How to add this correctly to the trunk?
Are files from /trunk/package/base-files and
/trunk/target/linux/orion/base-files merged?
Or should I use /trunk/target/linux/orion/base-files/etc/uci-defaults?
Can this be added just for WRT350Nv2 only or will it be set for all
devices with Orion boards?

(Last edited by maddes.b on 7 Apr 2010, 19:43)

Can not get the leds to light up. Also nothing special in /sys/class/leds/ available:

root@router:/sys/class/leds# ls -la
lrwxrwxrwx    1 root     root            0 Feb  9 01:56 ath9k-phy0::assoc -> ../../devices/pci0000:01/0000:01:07.0/leds/ath9k-phy0::assoc
lrwxrwxrwx    1 root     root            0 Feb  9 01:56 ath9k-phy0::radio -> ../../devices/pci0000:01/0000:01:07.0/leds/ath9k-phy0::radio
lrwxrwxrwx    1 root     root            0 Feb  9 01:56 ath9k-phy0::rx -> ../../devices/pci0000:01/0000:01:07.0/leds/ath9k-phy0::rx
lrwxrwxrwx    1 root     root            0 Feb  9 01:56 ath9k-phy0::tx -> ../../devices/pci0000:01/0000:01:07.0/leds/ath9k-phy0::tx

The patches I used are here. Please review.
I assume that the config settings are causing this problem on my build.
Dirk, what's missing from your config? Any more changes to trunk necessary (check with svn status/diff)?
Or must special packages be installed on the router?
Update: Recognized that CONFIG_INPUT_EVDEV was missing, rebuilt and uploaded, not tested yet.

Additionally my system config on the router:

root@router:/etc/config# cat system

config 'system'
        option 'hostname' 'router'
        option 'timezone' 'CET-1CEST,M3.5.0,M10.5.0/3'
        option 'zonename' 'Europe/Berlin'

config led
        option sysfs    'wrt350nv2:green:power'
        option default  1

config led
        option dev      wlan0
        option sysfs    'wrt350nv2:green:wireless'
        option mode     'link tx rx'
        option trigger  netdev

(Last edited by maddes.b on 7 Apr 2010, 19:43)

Hey maddes, ran a diff on my target/linux/orion/config-default, but as i suspected, that isn't all to clean in my case. Sorry about that...

Here's the full diff: http://pastebin.com/m9bb7cf3

Filtered to only what has been added:

+CONFIG_CPU_32v5=y
+CONFIG_CPU_CP15_MMU=y
+CONFIG_CPU_FEROCEON_OLD_ID=y
+CONFIG_CPU_TLB_FEROCEON=y
+CONFIG_DECOMPRESS_LZMA=y
+CONFIG_GENERIC_CLOCKEVENTS_BUILD=y
+CONFIG_GENERIC_FIND_LAST_BIT=y
+CONFIG_GENERIC_HARDIRQS_NO__DO_IRQ=y
+CONFIG_HAVE_AOUT=y
+CONFIG_HAVE_ARCH_KGDB=y
+CONFIG_HAVE_FUNCTION_TRACER=y
+CONFIG_HAVE_GENERIC_DMA_COHERENT=y
+CONFIG_HAVE_MLOCK=y
+CONFIG_HDLC=m
+CONFIG_I2C=y
+CONFIG_INET_LRO=y
+CONFIG_INPUT=y
+CONFIG_INPUT_EVDEV=y
+CONFIG_INPUT_KEYBOARD=y
+CONFIG_KEYBOARD_GPIO=y
+CONFIG_LEDS_GPIO=y
+CONFIG_LEGACY_PTY_COUNT=256
+CONFIG_NET_DSA=y
+CONFIG_NET_DSA_MV88E6XXX=y
+CONFIG_NET_DSA_MV88E6XXX_NEED_PPU=y
+CONFIG_NET_DSA_TAG_DSA=y
+CONFIG_PAGE_OFFSET=0xC0000000
+CONFIG_PHYLIB=y
+CONFIG_SCSI=m
+CONFIG_TRACING_SUPPORT=y
+CONFIG_USB_EHCI_HCD=m
+CONFIG_ZONE_DMA_FLAG=0

I'm sorry for not being clear, but my spare time isn't up for grabs anymore so i hope you'll be able to get it right with these.

Got LEDs working. Will upload new build after some more testing during the weekend.
The next build should then replace all 19xxx builds on my ftp space.

(Last edited by maddes.b on 9 Feb 2010, 14:31)

Great news
Waiting for the new build then.

I think i got the USB LED figured out with hotplug. here's the patch for it to work: http://hosting.upexia.nl/wrt350n/160-wr … bled.patch

What it does basically is overwrite the default 10-usb hotplug.d rule and toggle the USB LED on the WRT350nv2 only for the port itself. It should also work with USB hubs, e.g. the LED has to stay on even if there's no device on the extra hub. I couldn't test this because i don't have such a hub currently.

edit
I thought of making the LED configurable like the other LEDS, but i figured 99% wants default behavior for this and the people who don't are free to make changes to the system anyway...

(Last edited by dirkNL on 9 Feb 2010, 18:01)

r19562 is available for testing, incl. all LED patches from Dirk.
Please test thoroughly and if you encounter LED issues, then please post how to reproduce the problem and your config/packages.

(Last edited by maddes.b on 10 Feb 2010, 22:07)

maddes i've been unable to download files from your FTP, I'm able to connect to the FTP and download small text files but anything larger I just experience a timeout when waiting for the files to transfer. Is there some sort of trick to the ftp?

edit: i was able to download the 17264 build previously during 18xxx builds with kernel panics

(Last edited by PeePi on 12 Feb 2010, 10:28)

No, it's just a normal ftp server with 2 connections per IP. FTp setup has not changed since 2 years.
Just tested and I could download big files from a customer network.
It can be a problem with your internet provider, the proxy you use, your network or just downloading more than 2 files at once from the ftp server.
Also try a browser or different ftp client.

Maddes

(Last edited by maddes.b on 12 Feb 2010, 16:10)

I have the same FTP issue with ALL servers, please try a know good server: Adobe FTP
Then navigate to 9.x and then to 9.3, I got a timeout here, just after a few clicks.
As a workaround I login to the router.

There are a file size limit to the available memory.
Then move the file to the PC

So I think we have something misconfigured that don't allow FTPing behind the router (I never bother to fix it).
BTW I'm still have r17427 flashed.

ah right i'm off my rocker its happening to all ftp sites I just don't use ftp sites often enough to notice it on anything else.... silly me....

Never had ftp issues and still don't have any (currently r19554).

After following the thread for quite some time, it seems that it's time to brick my wrt

Tried to update to the latest stock (2.0.20) from the web interface, but it didn't work (uploads, then refreshes the web ui - but no update, even after reboot). However, the update utility worked ...
Can anyone tell me how I can upgrade to openwrt with the upload utility? Since I can't use the web interface with the NOT_FOR_NEWBIES_openwrt-wrt350nv2-squashfs-webupgrade image ...

Update:
Updated to 2.0.19 again through the upload utility and the .bin files from maddes (thx for providing the images!). Next I'll try the webupdate from 17456 and upgrade from openwrt to the new revision. Hope the webupdate works this time ...

Update2:
Webupdate didn't work ... the recovery.bin file worked. However, I need to read a bit more about how to update from the recovery image

  Erich

(Last edited by strale on 13 Feb 2010, 00:11)

@strale:
what was the error message you got when using the webupgrade functionality of the stock firmware with my webupgrade images?
all my webupgrade images have version 2.0.19 so maybe it warns about flashing old version.

I could upgrade/downgrade from any stock to any stock firmware.
2.0.17 -> 2.0.19 -> 2.0.20 plus 2.0.17 -> 2.0.20
2.0.20 -> 2.0.19 -> 2.0.17 plus 2.0.20 -> 2.0.17
Note that after downgrading you have to hardware reset the device, otherwise you may get hang ups on boot (I assume the upgraded nvram vars are not compatible with older stock firmware, especially 2.0.17).

(Last edited by maddes.b on 13 Feb 2010, 11:16)

@maddes
http://downloads.linksysbycisco.com/dow … .00.20.rar

I wanted to update to 2.0.20 from 2.0.19 - didn't work, then I tried openwrt which also didn't work. No error messages, just the status showing 100% and then nothing happens. Doesn't seem to be a openwrt problem, since I couldn't webupdate the stock firmware as well.
I managed to use the recovery.bin file from 19554, however, I don't get wan. udhcpc only shows scanning. sysupdate -v openwrt-wrt350nv2-squashfs.img didn't work (mount: mounting mini_fo:/jffs on /mnt failed: Function not implemented). I'll google a bit about the wan issue ... hope to get my wrt working tomorrow with openwrt

That mounting message can normally be ignored.
It should have flashed correctly.

(Last edited by maddes.b on 13 Feb 2010, 02:24)

meanwhile i pulled the plug on the modem and the router, dhcp is working now. i'll try flashing the router again.

Update:
sysupgrade -v ftp://ftp.maddes.net/openwrt/kamikaze/o … uashfs.img (with the url, instead of copying the file to the router) worked!

Update2:
thanks to the forum, I got luci up in no time! great work everyone! would have been a bit easier if the info were in the wiki, instead of searching the last 20 pages or so now i need a build environment to build this usb controlled power plug software so i can control the printer.

build 19562 seems to work fine now.

(Last edited by strale on 13 Feb 2010, 15:41)

I was able to flash my r19562 webupgrade image with 2.0.20 without any issues.
Must be a problem on your side. You always flash via cable, don't you?

Due to further tests I recognized that the current wrt350nv2-builder can not create the correct checksum byte for the stock firmwares 2.0.17 and 2.0.20, but for 2.0.19 the checkum byte was correct, which was always used for OpenWrt upgrade images.
Also got the webupgrade fixed for other versions than 2.0.19 inside the OpenWrt webupgrade images.

(Last edited by maddes.b on 13 Feb 2010, 11:19)

yes, i always flash via cable ... and it worked prior to the 2.0.19 stock firmware. however, I'm happy with r19562 now!

the only problem is that the wlan driver died at night ... the next time I'll connect via cable (since the lights were still flashing, I guess the device is up) and check the logs. (could be a PSK2 issue ... I'm not sure, but I think I read somewhere that there are problems with PSK2. I'll search the forum again)

We have used PSK2 in production for close to half a year now, which seems to be mostly fine, but the WiFi becomes inaccessible sometimes. Meaning that the SSID is still visible, but any attempt to connect (or stay connected) to it fails.

At this point we usually simply reboot it, at which point it works again. It's not 100% stable yet. To be honest, I'm not sure that it will ever be, but time will tell...

It's good enough anyway IMO.

well, I'll check out if there is something in the logs next time. would be nice if it would reboot automatically if that happens.

You could also simply schedule a (bi-/tri-?)nightly reboot using cron, this would probably 'guarantee' WiFi stability. We'd do it here, but we have a 2TB USB disk attached that would get e2fsck'd too often in such a case. It seems to happen to us between approximately 2 and 14 days.

(Last edited by StrikerNL on 13 Feb 2010, 12:50)

you can change the max mount count with tune2fs, which I'll do as well. I've a hdd on my router which I hope I can put to sleep when not accessed.