I've got a hacked up copy of uboot that I built from the Linksys sources.  It reenables saveenv and for shits and giggles I added support for bzip2 and lzma compressed kernels, the image is at:  http://squeaker.ratbox.org/u-boot.bin

To flash it from tftp, do an upgrade boot.bin and tftp it to the router.  Be careful as if this goes wrong you *will* end up with a brick.  Also it seems to blow away some of the settings like your mac address etc so make a note of what your printenv environment looked like before doing this. 

-Aaron

(Last edited by androsyn on 19 Nov 2009, 14:56)

Hey Aaron,

Thanks for the post and u-boot.bin, my WRT160nl is working now!  Much appreciated! 

My MAC address seemed to be saved, however, the u-bootwent into some manufacturing mode boot to a tftp server.  I had to modify some environment variables (mfgboot/bootcmd/serverip/ipaddr) and reload openwrt.

Mind posting your hacks to the sources for u-boot?  Also what distribution did you build on?  I tried to build yesterday on Ubuntu 9.04, but the toolchain build failed.

Thanks again!

Chris

Here is the diff: http://squeaker.ratbox.org/uboot+saveenv+lzma.diff.bz2

I built the toolchain on Debian unstable.  Reenabling saveenv and a few other things was just a matter of tweaking the code that was there.

The LZMA decompression code was lifted from the current u-boot release, the openwrt build process doesn't build an LZMA compressed image, but its not hard to get it to do.

-Aaron

Is it possible to configure this model switch?

Building the today trunk I had to comment the switch section in /etc/config/network just to get the WAN working...

I have some pictures to share for anyone who wants a serial console without opening the WRT160NL. I used an old USB-IrDA controller which I had lying around, ripped out the IrDA chip and connected wires to the pl2303 on the board. The connector for the WRT is an ethernet connector with 3 cables mounted on the back. You have to be careful when inserting the connector, but it works reliably afterwards.

Can I see a bit more detail on the rj45 connector with how you ran the wires there?

Thanks,

Aaron

Here you go:

Hello,

I've (sort of) had success flashing an SVN trunk build as of yesterday. I made the IDE cable serial port cable mentioned earlier in this thread up (thanks for that - what a brilliant design - works perfectly) and the device boots and Wifi appears to work on 802.11g - but I get some packet loss on n, as mentioned.

However, DHCP isn't working on the "internet" port, which seems to be eth1.

udhcpc starts on boot, and 'ps' shows it running (udhcpc -i eth1), but no address. If I kill this process and then run it manually I *usually* get an address, but it is intermittent.

While trying to debug the problem I ran iptables -F, -X, -t nat -F etc to clear the firewall rules in case they were in the way.

I set a manual IP address using ipconfig, and could ping the other end. However, on occasions where udhcpc failed manually I could not ping the other end.

I installed tcpdump on the router, and it *looks* as though I do not see the ping/DHCP requests using tcpdump when the device is failing - i.e. they're going AWOL somewhere in the kernel.

I seem to be able to reproduce my problem:

- power on
- killall udhcpc
- ifconfig eth1 192.168.1.20 (eth0 port is configured as 192.168.2.1 - so this address should be valid, and 192.168.1.1 is my old router at the other end of eth1.) I don't think the router is at fault as the same problem occurs with the cable modem directly connected.

ping the wireless router at the other end - ping 192.168.1.1 - this will probably work

If I then type 'ifconfig eth1 down' it stops working - fair enough.

If I then type 'ifconfig eth1 up; ifconfig eth1 192.168.1.20' and then do the ping again it doesn't work.

If I type 'ifup wan' it restarts udhcpc etc, but again no joy - the interface seems to have gone dead.

The same thing can be reproduced by typing '/etc/rc.d/K40network stop; K40network start'.

My /etc/config/network is as follows (I tried commenting out the switch section in case this was the problem):

config interface lan
        option ifname   eth0
        option type     bridge
        option proto    static
        option ipaddr   192.168.2.1
        option netmask  255.255.255.0

config interface wan
        option ifname   eth1
        option proto    dhcp

config switch eth1
        option reset    1
        option enable_vlan 0

#config switch_vlan
#       option device   eth1
#       option vlan     1
#       option ports    "0 1 2 3 4 5"

The problem occurs with two different devices at the other end of eth1.

When it is in the failed state I can monitor traffic on eth1 - it just seems like no data gets out.

I suspect (knowing me) I'm doing something *really dumb* but the intermittentness of this puzzles me. Can anyone point out the obvious post I've missed in this forum? I've tried reading them all but I bet I've missed something critical!

Thanks,

Colin

Hi, I'm at the head banging on table stage of trying to get a working serial connection to my 160 and i'm looking for some help

I'm connecting using a short serial to usb ( prolific based ) cable to the J3 header ( GND 5, TX 2, RX 3)

Using either minicom or screen to /dev/ttyUSB0 with 115200 8N1 all I can get out to screen are random characters that seem to follow the boot process

I can't see what I've missed off, so if anyone can recommend anything, I would be very grateful

Thanks

Remove all config switch section. There is a problem with the switch  configuration.

obsy -

thanks very much for that hint. Removing the switch config means it now boots up with a DHCP address - thanks! I'm sending this reply via the router :-D

If I do 'ifdown wan', then 'ifup wan' it appears to be unable to send afterwards, but can receive. Is anyone else having this trouble?

aggress -

I had problems (a few years ago) using a Prolific USB adapter on Linux. It appeared that the baud rate sometimes wasn't set correctly which might indicate your trouble. The adapter I had seemed a bit flaky to me, but if I remember a later drived fixed the problem. I've been using a FTDI adapter with the router (http://www.ftdichip.com/Products/Evalua … 2R-3V3.htm) which seems to work OK.

Colin

My WAN is connected via PPPoE and when ever the PPPoE connection is lost (by the cable being removed, ifdown wan, etc.) it will not come back up, complaining about not finding the PPPoE discovery packet.

Has anyone else come across this issue? Apart from that everything (minus usb which I haven't tested) works great

harrisony - Your problem sounds identical to mine of about 3 posts above. Did you try removing the switch section from /etc/network/config, as suggested above? This cured the problem for me.

Colin

@ brain0: Thanks for the pics of that cable. Looks cool. I'm gonna give it a shot myself.

Good news: I now have my WRT160NL in productive usage for my home, running WPA2 wireless, PPPoE, lighttpd, irssi and storage on a flash drive. Quite nice.

Bad news: I broke my cool serial adapter. No idea what's wrong, but it simply doesn't work anymore.
More bad news: I can confirm the eth1 problem posted above. Once you bring eth1 down (which is also done by "ifdown wan"), it claims to have no carrier and a reboot is required to get eth1 back. Switch config or no switch config makes no difference, see also https://dev.openwrt.org/ticket/6309

I've tried to update firmware using sysupgrade and after that router stopped booting. I've connected to it using serial console, but when I turn it one it only gives some junk into the output and that's all. I can't do anything with it. On the router itself only the power led is flashing.
What can I do to restore the router?

Just curious, you updated from what to what?

From one build of openwrt to another.

I think the posts above indicate problems with the latest trunk. It has also been very unstable for me.

Does anyone know more details about the status for trunk?

Do you know the revisions? I am running r18666 fine, there have been changes to the ar71xx kernel between r18691 and r18697, r18699, r18710 and r18711. Some of those are fixes for the ethernet driver, one directly related to a WRT160NL issue, and I am a bit afraid to upgrade since I read your post ...

It was r18684 that killed the router.

Hi,

More head banging, what might I be doing wrong in getting my 160NL to make use of all 13 available WIFI channels, I've set the option country but still it won't go past 11

wlan0     11 channels in total; available frequencies :
          Channel 01 : 2.412 GHz
          Channel 02 : 2.417 GHz
          Channel 03 : 2.422 GHz
          Channel 04 : 2.427 GHz
          Channel 05 : 2.432 GHz
          Channel 06 : 2.437 GHz
          Channel 07 : 2.442 GHz
          Channel 08 : 2.447 GHz
          Channel 09 : 2.452 GHz
          Channel 10 : 2.457 GHz
          Channel 11 : 2.462 GHz
          Current Frequency=2.442 GHz (Channel 7)

My /etc/config/wireless is as follows

config wifi-device  wifi0
        option type     mac80211
        option channel  5
        option country  uk
        option macaddr  00:03:7f:xx:xx:xx
        option hwmode   11bng

config wifi-iface
        option device   wifi0
        option network  lan
        option mode     sta
        option ssid     OpenWrt
        option encryption none

Any working suggestions will be repaid in virtual beer or cake

Regards

Subsequently, checking dmesg I came across the following, which suggests the ath EEPROM is then setting it back to US, anyone have any ideas?

cfg80211: Using static regulatory domain info
cfg80211: Regulatory domain: EU
        (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
        (2402000 KHz - 2482000 KHz @ 40000 KHz), (600 mBi, 2000 mBm)
        (5170000 KHz - 5190000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
        (5190000 KHz - 5210000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
        (5210000 KHz - 5230000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
        (5230000 KHz - 5330000 KHz @ 40000 KHz), (600 mBi, 2000 mBm)
        (5490000 KHz - 5710000 KHz @ 40000 KHz), (600 mBi, 3000 mBm)
cfg80211: Calling CRDA for country: EU
cfg80211: Calling CRDA for country: EU
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
ath: EEPROM regdomain: 0x0
ath: EEPROM indicates default country code should be used
ath: doing EEPROM country->regdmn map search
ath: country maps to regdmn code: 0x3a
ath: Country alpha2 being used: US
ath: Regpair used: 0x3a
phy0: Selected rate control algorithm 'ath9k_rate_control'
phy0: Atheros AR9100 MAC/BB Rev:0, AR2122 RF Rev:a2, mem=0xb80c0000, irq=2
cfg80211: Calling CRDA for country: US
cfg80211: Current regulatory domain intersected:
        (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
        (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
        (5170000 KHz - 5190000 KHz @ 20000 KHz), (300 mBi, 1700 mBm)
        (5190000 KHz - 5210000 KHz @ 20000 KHz), (300 mBi, 1700 mBm)
        (5210000 KHz - 5230000 KHz @ 20000 KHz), (300 mBi, 1700 mBm)
        (5230000 KHz - 5250000 KHz @ 20000 KHz), (300 mBi, 1700 mBm)
        (5250000 KHz - 5330000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
        (5490000 KHz - 5600000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
        (5650000 KHz - 5710000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
PPP generic driver version 2.4.2

@SR: That is weird, I don't see anything that should break between 18666 and 18684

@aggress: Try "UK" instead of "uk" for the country. Also enable the ath9k option to ignore the EEPROM in the build. Furthermore, you can experiment with the command "iw reg set UK" and similar,  check what is allowed with "iw list".

Is it possible that if the firmware image is large that it can somehow overwrite the bootloader part of the memory during upgrade?
The file was 4,5Mb (but the router should have 8Mb flash memory...).
If the bootloader was somehow overwritten is there a way to restore it?