Help with testing the AP+Client Bug

[post_break]

I'll give this a shot. I really hope it's stable for me too heh. Now the only problem is that if this is working where do you go from here?

[post_break]

I'm not sure how to install this build. I use the fon flash utility but I thought it used the vmlinux.gz and squashfs files not this lzma file.

[Eric]

Fon flash will work with either kernel. Alternately install 1.0.2 which is the same thing only it also has a fix for restriction white-listing too (and both .gz and .lzma are available in the download section).

[post_break]

Pardon my tiredness. I have it flashed now that I realized what goes where. So far so good. We'll see in the long run. Thanks for posting this build.

***edit***
Uptime just surpassed 7 hours. Looks like you fixed the glitch.

[crisman]

Ok, I have a version that seems to be working for me... but since everyone seems to report different symptoms I'm not sure this is a definitive solution. I'm hoping you guys can help test.

What I did (and I admit this is a horrible, ugly hack) is revert madwifi, hostapd and wpa_supplicant back to revision 13000, just after the 8.09 branch of openwrt was created, and make a couple necessary config changes for compatibility. I have this version installed on my Fon+ and configured to ap+client mode with wpa2 psk encryption. It's been running fine for the past 4 hours, without any interruption in the connection.

So, here's the new version (Gargoyle 1.0.1 + older madwifi & related packages). Please, if you can, help test this:
gargoyle-madwifi-testA.squashfs
gargoyle-madwifi-testA.lzma

Thanks in advance to all who help test!

OK, can you attach the necessary changes you applied?

Since we have a working version, what do you think to do now?
Try adding one patch at time to madwifi is very very annoying, so we should find a definitive solution, but I have no idea how to do

I think some patches of madwifi are essentials, because they improve the stability and prevents some race conditions.

Have you any idea?

[Eric]

The changes I applied are in the svn... but like I said this is a horrible ugly hack. It isn't that I applied a patch to revert previous patches, as I might do for a minor issue, it's that I reverted the entire madwifi driver, hostapd and wpa_supplicant (since the code for the latter two is influenced by the first) back to r13000 of the openwrt trunk.

Some of those patches may be useful... but it's very clear that in aggregate they break the system horribly (at least in ap+sta mode).

While I could spend the next month or so figuring out what the actual root cause of this is, I'm not sure that's the best use of my time. I can generally figure out code quickly but the madwifi driver code base is huge! Also, it is possible it will get fixed by the openwrt developers (who have a history of working with madwifi, and probably can find the root cause easier than I can).

Therefore, as people seem to be agreeing that this "solution" works, I'm inclined to leave in the ugly hack. My plan is to put the issue on the back-burner for now, unless it's clear madwifi is still causing problems.

[DoesItMatter]

Does anyone have a Realtek 8185 wireless adapter to test Gargoyle with?

Realtek 8185 Extensible 802.11b/g Wireless Device

Is the generic card I have. It was working with version 1.0, but since upgrading to the 1.0.2, I seem to be having connection issues when connecting to the router.

I know it works because I have a Netgear WNDR3300 that I can connect to no problem.

It is NOT a big deal for me, as its just for testing purposes, but am wondering if anyone else is experiencing these issues?

I'll get the "Connected with limited connectivity" option, where it won't connect, or design the default windows IP. I show 4-5 bars signal strength.

I've tried WEP, WPA, and No encryption - no luck.

Again - NOT a problem for me, but wondering if anyone else is experiencing this since the 1.0.2 madwifi hotfix?

[post_break]

There are a few bugs I have noticed in this test build (however they could be in others as well). I set up a network for this to join with WEP and the key being "#####" and it won't let me input that. Again this might not be this build specific. Not a huge problem as I use WPA2 but it could be for others. Other than that this custom build lasted over 10 hours which is enough for me to assume it wont hang up like it did before. I wrote a guide on my site (iamthekiller.net) to use fons as a cheap mesh network and now I can update the guide.

[Eric]

DoesItMatter: Huh... that's worrying. I may have to dive into the code and try to fix this the hard/right way after all. It would help if others could confirm whether some NICs aren't working.

post_break: All WEP keys should be hex, either 10 or 26 characters. There is no standard way of generating a hex key from an ascii string, so any implemented solution would not be universal and would not work in some cases. Therefore you must enter the hex wep key. WPA & WPA2 allow ascii strings as passwords, but not WEP. This has been in the case in all versions of Gargoyle.

[DoesItMatter]

I will try and downgrade my Fon in the next day or 2 back to beta 5 or even the 1.0.0 final build and see if I can connect properly.

Will post the results as soon as I can - hopefully others with some newer Realtek wireless devices can also do some testing.

I believe the RTL8185 is one of the newer Realtek chipsets.
I.e. only a couple years old if that.