HyperWRT 2.0b2 Bug List

Submit here the bugs you find in HyperWRT 2.0b2

hi avenger20,
2.0b1 was the first firmware i was able to connect my notebook with g-standard. in 2.0b2 g-standard-connections do not work again.

is that possible? :roll:

I had a inssue like this, my notebook dont connect on G devices with driver from WindowsUpdade, but with the driver from www.hp.com it works ok.
I don't know if it is similar to you, but it was what i noticed.

Cya

hello chicobyte,

i have a "centrino"-notebook and i work with intel proset. my problem is very strange. on the one hand i detected that b-standard works perfectly well. on the other hand g-standard does not work aproximately.
i do not know what i am doing wrong . . . maybe one of you can help me solving this bloody problem. :evil: would be very nice. 8)

Centrino have g technology? It just a question. It had worked with 54mb before with another firmware, or with another access point?

Cya.

Edit: I will post in you other thread because this is only for bug list. Sorry :lol:

my answer is the other thread.

hi all,

hummm, no probs with my prism based 'g' minipci card in my notebook.
works in 'g' only and mixed mode - like a charm

but i recognized another strange behaviour of my wrt54GS with the new 2.0b2 firmware. every 1 to 1 1/2 hours my connection is totally lost and my both devices (notebook and pda) could not reconnect to the wireless until i went into webbased setup of the wrt and manually disabled and then reenabled the wireless radio.
strange ? or is my wrt a little bit faulty?


bakajikara

I get exactly the same disconnection problem, but I can get it back using my card's utility.

Other than this annoying problem the beta 2 is great! The disconnection problem wasnt in beta 1 for me.

I have a WRT54G 2.0 btw if it helps.

Strange problem. I can't think of anything I added that would cause this kind of behaviour.

Are you using Qos, Portforwarding or the Scripts?

Update : I might have find the bug causing this behaviour. Will fix it in 2.0b3

MAC Filter bug????

Greetings

I ran across an interesting, repeatable problem with my WRT54G (hyperWRT2.0b2).

My normal setup is WEP encryption and MAC filtering set to allow only MACs in my filter list. This has worked fine for months.

Yesterday, I disabled the MAC filter as I had 2 new machines on my network I needed to update. Once my work was completed, I re-enabled MAC filtering. As soon as the changes were saved, I lost all wireless connections. The only way back was to hard-reset the router, re-connect via defaults and re-load my last saved configuration file.

If I repeated the steps - the same result - all wireless was blocked. I still had signal - Netstumber showed WEP enabled signal on my SSID but I was unable to connect any clients.

Has anyone seen anything similar with either the Linksys 3.x.x release or the hyperWRT 2.x release??

All the correct MAC's were in the MAC list and the boxes checked before I saved the changes. MAC filtering was set to allow only MAC's in the list.

I have disabled and re-enabled MAC filtering in the past - prior to hyperwrt2.x (Linksys 3.x.x). I did not have this problem before.

Any ideas??

It has been reported that this is a bug in Linksys 3.xx.x source code.

Thanks Avenger...

I tried falling abck to an older Linksys code base - hyper 1.4 - DId the same test, - actually loaded up my saved 1.4 config. I disabled MAC filtering, then re-enabled the filter with no changes - no problem with the router.

I re-installed hyper 2.x - same test - same failure.

I guess I will open a case with Linksys - I will just tell them I am using 3.x.x

Maybe if you see something obvious in the code where they changed something in MAC filtering area you can fix it. Maybe it is something as simple as a default value on the web screen or maybe the table of MAC addresses is getting clobbered - remember, I am setting my MAC filter to allow only MAC's in list so if the list gets clobbered, no one gets in.

I was hoping someone out here can re-create the problem as well.....

Great idee. Is there a special form to submit linksys bugs? Or how do you submit them?

I mailed once to linksys support asking them if they had plans to add 'static dhcp' but the man on the other side didn't know what I was talking about. "There is for the moment only static and dhcp to connect to your provider, as there are no providers using static dhcp" was the answer :roll:

"Static DHCP"

I wouldn't use the term "Static DHCP" when talking to Linksys. I would tell them what you are trying to do.

Something to the effect of:

I want to be able to assign specific IP addresses to indivicual MAC addresses using the DHCP facitility on the router.

I think it was D-Link which called this "Static DHCP". You might want to refer them to their competitor to see what they're doing.

I know in most major network operating systems you have the option of doing this as well. On my home network under Win2K3, I've done it there and turned off DHCP on the router. I believe you could find a freeware DHCP server to do this for you as well.

Lost DNS forwarding in HyperWRT 2.0b2

I use static IP settings on one of my wireless computers (so i can do port forwarding to it.) I had the DNS IP address set to the gateway address (192.168.1.1) in HyperWRT 1.3 and it worked fine. Upgraded to HypwerWRT 2.0b2 and now it won't do DNS resolution. Workaround was to statically set the DNS server IP addresses on that computer. I don't like to do that, as I'd prefer to have those automatically configured by the router as it was before.

Thanks Avenger.

-martin

2.0b2 does not allow Parental Control

I have subscribed to Parental Controls through Linksys on the WRT54GS. With HyperWRT 1.4 firmware it works OK. When I upgraded to 2.02b this evening, it no longer logs in.

When you try to log in it says there has been an error and keeps you on the sign in page.

This bug disappeared immediately I downgraded to 1.4 again.

Disabling and then reenabling the parental controls does not work. Nor does switching off and on again. I also tried a number of nicknames.

Otherwise everything seemed ok on the Linksys box - I checked all the pages.

Re: 2.0b2 does not allow Parental Control

Could you test if it works with Official Linksys 3.17.4
and hyperwrt 2.0b1 (you can find it on download page, older versions).
Then I can know what could have broke it.

Re: 2.0b2 does not allow Parental Control

I have tested with both 3.17.4 (parental controls work)
and hyperwrt 2.0b1 (parental controls don't work).

Hope this helps.

Re: 2.0b2 does not allow Parental Control

I have tested with both 3.17.4 (parental controls work)
and hyperwrt 2.0b1 (parental controls don't work).

Hope this helps.[/quote]

It looks like Linksys broke Parantal Control in the source code :?

I'll compile a version from v3.17.4 source with no added code. Shall PM you the link (somewhere today - tomorrow) if you want to help to test it.

After upgrading my WRT54G to the v3.01.3 Firmware I suffered from the same problem. I also tried HyperWRT v2.02.b (which is excellent BTW) with the same result.

Going back to the v2.04.4 Firmware (and also HyperWRT 1.4) fixed the problem, which leads me to believe that this is a bug in the V3 Linksys Firmware having to do with the Client Lease time. The default value for this (on the Setup - Basic Setup Page) is 0 which means one day. It seems this is being passed correctly to the DHCP Clients (check Status of the Network Connection) but is recorded incorrectly on the router itself (check status on the Status - Local Network - DHCP Clients Table Page) resulting in the router dropping the connection after about 1.5 hours.

Setting the Client Lease Time to 1440 (in Minutes =1 day) didn't help, but changing it to 2880 (in Minutes = 2 days) helped me - no more disconnects after ~1.5 hours.

Maybe you can fix NAT in WRT54G?


Since firmware version 3.01.3 I get the error message "Please don´t use private IP addresses" when trying to register at some VoIP-providers servers.


I tried it with different firmwares for the WRT54G Version 1.1. The error occurs with firmware

Firmware Version: Alchemy-6.0-RC1.w42 V2.04.4.8sv
Firmware Version: v3.01.3 - HyperWRT 2.0b2
Firmware Version: v3.01.3
Firmware Version: Satori-4.0 v2.07.1.7sv (tinyPEAP)

Everything is OK with

Firmware Version: v2.04.3 - HyperWRT 1.4
Firmware Version: v2.04.3

VoIP-Provider blueSIP.net wrote me (sorry, german only, therefore english version only in brief)

There are tools which are used by some providers to rewrite wrong register messages with private IPs in contact. Usually the RTP stream is negotiated by the clients. In this case the client would negotiate a private IP as destination und would register at blueSIP but wouldn´t be able to arrange a direct RTP stream to other clients. This problem can be solved with a RTP Proxy. Some other providers are offering their customers such free RTP proxies or are rewriting wrong register messages. In our eyes it´s better to use routers which are SIP aware and can handel QoS for VoIP.

Here is the german version:

es gibt Tools auf Providerseite, mit denen fehlerhafte SIP REGISTER Messages mit privaten IPs im contact umgeschrieben werden.
Das Problem ist, dass normalerweise der RTP Stream direkt zwischen den clients ausgehandelt wird. Da der Client hier auch die private IP als Ziel aushandeln wuerde waere der Client zwar bei blueSIP registriert, koennte aber keinen direkten RTP Stream zu anderen Clients aufbauen.
Loesbar ist dieses Dilemma mit einem RTP Proxy, den wir auch anbieten, allerdings nur fuer Vertragskunden. Das hat zum einen rechtliche aber auch Skalierungs- und Kostengruende (schliesslich muessen wir ausreichend Bandbreite fuer RTP Streams welche dann ueber unseren Proxy laufen vorhalten).

NAT ist leider der groesste Stolperstein fuer VoIP. Das Verbiegen von falschen register Messages ist aber nach unserer Sicht keine gute Loesung.
Uns ist klar, dass andere Anbieter diese 'Korrekturmachanismen' und freie RTP Proxies anbieten. Inwieweit sich hier mit steigender Nutzerzahl eine Qualitaet aufrechterhalten laesst darf zumindest bezweifelt werden. Unsere Zielgruppe sind Geschaeftskunden, fuer die Telefonie in herkoemmlicher Qualitaet unabdingbar ist.

Wir meinen der bessere Ansatz ist geeignete Router einzusetzen, die 'SIP aware' sind. Nur solche Router garantieren auch eine saubere Sprachqualitaet, wenn ueber die Leitung noch andere Daten transportiert werden (QoS fuer SIP).

"Max Idle Time" field

Hello
It seems that this problem migrated from the original Linksys firmware into HyperWRT.

According to the internal help file (http://192.168.1.1/help/HSetup.asp) "Max Idle Time" parameter for PPPoE may be set to 0 on the Setup page:
If you want your Internet connection to remain active at all times, enter 0 in the Max Idle Time field.

In fact it's impossible to set this parameter to 0.