OpenWrt Forum Archive

Topic: wap54G problem

The content of this topic has been archived on 13 Apr 2018. There are no obvious gaps in this topic, but there may still be some posts missing at the end.

Hallo
I upgraded to RC5 wap54G v1.
The AP seems to work, but I have no access to it.
It was on default before update so IP should be 192.168.1.245.
There is no ping, telent, ssh, but the mac address is received (arp).
So I think the problem is in iptables, vlans or something else...

Idea how to resolve this problem?
I have boot-wait on so I can hopefully to get another firmware...

I tried 2 methods with no result.
I downgraded to RC4. Established a wireless connection. Upgraded to RC5 and tried to connect trough wireless, but with no success.
I tried the failsafe procedure. Run the resvudp program, get the press reset message, but nothing I do, gets me in the failsafe mode sad

Some ideas?

10x, samot, but didn't found solution sad
On my device boot_wait works ok. Lan is sending packets- at least arp replies, because I get the mac address.

If anybody (maybe developers) would like to send me modified firmwares, I will gladely test them on my devices, because my boot_wait is working. Unfortunately I don't have a serial connection, so I can only say working or not working...

I tried to build a custom image without switch, iptables,dnsmasq packages and patched. Immediately after patching I could connect to a device connected wireless. After restart it stopped working?? Strange. I am not sure I can reproduce...

avalon wrote:

On my device boot_wait works ok. Lan is sending packets- at least arp replies, because I get the mac address.

Strange. I've already suspected there are two revisions of v1.0. Maybe your dev have better pmon but the same hw problem.
Can you report S/N and send binary image of PMON?

If you can downgrade to any working fw, try setting

nvram set boardtype=bcm94710dev
nvram set boardnum=2
nvram commit

Actual values should be same as before. You need set them againg to get rid of invisible CR appended.
After that official RC5 micro image should work.

avalon wrote:

If anybody (maybe developers) would like to send me modified firmwares, I will gladely test them on my devices, because my boot_wait is working. Unfortunately I don't have a serial connection, so I can only say working or not working...

Be happy that boot_wait is working. If an image for some reason corrupts nvram, you loose way back - well except of building an uart.
I use customised kamikaze on my two wap54g v1.0 devs. Presumably such image is not what you want.

avalon wrote:

I tried to build a custom image without switch, iptables,dnsmasq packages and patched. Immediately after patching I could connect to a device connected wireless. After restart it stopped working?? Strange. I am not sure I can reproduce...

What patches you mean?

samot, thank you very much!
After setting these variables averithing works OK.
I already have only one device updated to RC5, but I have 2 RC4 which are now installed on a client and I have no access to them.
One of them was with non working bootwait, but the problem was not in the device I think. Here is the serial number of my RC5 device: MDG003358996. Now I will explain what the boot-wait problem maybe is:

I update the devices by installing hyperwap to enable boot_wait first. Hyperwap says that it needs the original firmware 1.09.01. So I in first place install this firmware, after that hyperwap and after that openwrt with tftp.
On the one device with RC4 which was with non working boot_wait I forgot to install 1.9.1 first. After that I had working openwrt but after every reboot boot_wait was resetted to off!? Maybe 1.09.1 firmware solves some problems...

I could send you whatever image you wish, but please send me email to avalon at friendofpooh dot com with instructions how to create it and I will have your email to know where to send it.

10x again smile

Ok. I maybe must take my words back sad
My second device was broken by a lightning so the ethernet port was dead. It was repaired in unknown way. I don't know if this is the reason, but it has in nvram boot_wait=on, but boot_wait doesn't work.
I installed RC4, connected through wireless (lan not working), set variables, installed RC5 with mtd and it is working now smile S/N: MDG003705553

The device is possibly broken because on some reboots (with the original firmware, I will test with RC5 now) lan works and on some not... So it is not a sure indication of device from the revision with broken boot_wait.

I've checked PMON images you've sent. Both are exactly same as mine.

Check dmesg output for "diag boartype".
If it reads 0000041a router hardware is detected corectly and vanilla RC5 can workaround PHY isolate hw bug. If so your problems are not related to it.

avalon wrote:

On the one device with RC4 which was with non working boot_wait I forgot to install 1.9.1 first. After that I had working openwrt but after every reboot boot_wait was resetted to off!? Maybe 1.09.1 firmware solves some problems...

I noticed on serial console that PMON insists on some nvram variables with \r character appended. If they are commited in "normal" form (without \r),
PMON on next boot resets all PMON related variables (including boot_wait and et1macaddr). Maybe there is a varible which can prevent this? Try diff outputs
of nvram show on those to devs. I have not found such difference between nvram.bin and nvram_bad.bin you've sent.

For the device that resets boot_wait I made a script that restores nvram variables from file and copied all from the working to the not-working device, so all variables are without \r.
Anyway I cannot test them any more.

Yes the board type is 41a and the problem is maybe imaginary because I had other network problems. Ater resolving them I have no more troubles.

BTW both devices are with 4MB flash:
Creating 5 MTD partitions on "Physically mapped flash":
0x00000000-0x00040000 : "pmon"
0x00040000-0x003f0000 : "linux"
0x000bc400-0x00168000 : "rootfs"
mtd: partition "rootfs" doesn't start on an erase block boundary -- force read-only
0x003f0000-0x00400000 : "nvram"
0x00170000-0x003f0000 : "OpenWrt"

and one just don't works without workarounding PHY isolate hw bug. The other is ok in all manners...

I will try to include this information in the wiki.
Would be good to review what I've written.

Hallo
I upgraded to RC5 my WAP54G v2. The previous firmawe was wap54g v3-3.04.02-hyperwap. Access Point works. Both lan and wlan are alive but... no access is to it. 192.168.1.245 does not answer, no ping... What is going on? HELP and sorry I am a Windows user (shame on me smile. Please help.

How do U know interfaces are alive?
What was the address of the AP before update?

RC5 comes with a web interface. Can you access it?
Did you tried telnet <IP>.
Did you tried ssh <IP> (you can use putty fot ssh access)
How did you updated (tftp or web)?
Does your boot_wait works?

wifi and lan are alive as everything is all right. I use the old WEP and wifi connects the net. I only can not use web interface. Before upgrade (by wifi in web) I could setup AP writing 192.168.1.245 in tte web. Now "ping 192.168.1.245" does not answer in telnet. Sorry I do not know what the ssh access means. Thank for answer and I wait for any sugesstions.

It seems like a firewall problem...
Try from the lan side.

ssh is as telnet but uses encryption. Putty is a program easy to use, so download it.
After setting password, you will be unable to use telnet any more.

hmmm still the same. Putty in ssh mode does not help. Still no connection - time out -. What to do?

Try if your boot_wait is working.
Use the imagebuilderhowto in the wiki to build an image without iptables and dhcp, to see if this was the problem.
After flashing, you could install these by the ipkg utility.

So tftp is it. See tftp installing in the docs.

After all read the unbricking howtos, but I think that your problem is something that you don't do as expected, because the device continues to work...
You can try to go through the recovery howto with the reset button...
And I cannot understand these versions that you gave in your first post.

Just sleep a night, reboot the device. Try to connect to it without firewalls from wifi and from lan. And try the things I mentioned above.

The previous ver. of firmware was hyperwap_V3.trx. I have no idea. I tried the unbricking method with 15-16 pins - no results.

What is it boot_wait?

WAP54G v2 with previous firmware hyperwap_V3.trx worked great.
After upload RC5 I lost web setup 192.168.1.245. Still works great with the old configuration.
No answer for ping by wifi and lan. It can not be rebooted - no actions. Probably boot_wait is off. Unbricking method and no changes. Still works but can not be configured or changed firmaware.

what to do?

I have found IP 192.168.1.255 of my wap54g by LAN Scanner program. But there is no open port, so I can not connect to it any telnet or ssh to flash new firmware. Any ideas?

You must use a separate connection with the device, because it is possible to have 2 or motre devices with the same IP address in your network, so the bridge will work, but the device is inaccessible.

First try the failsafe method with the reset button.
Try do downgrade or install custom image of RC4 with tftp (boot_wait=on). boot_wait and tftp upgrade are explained in the documentation. (as almost everithing else)

If you cannot understand the documentation, you should pay somebody experienced in networking and openwrt to help you.

please I have a wap54g V1.0 with 4702 chip bricked, so I need the cfe.bin but I cant findd the correct one, please help me please

The discussion might have continued from here.