Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!
Not eligible to see or edit group visibility for this bug.
View Bug Activity | Format For Printing | XML | Clone This Bug
I just added a comment to http://madwifi.org/ticket/776 explaining why this patch causes problems with wpa_supplicant (and everyone else who relies on wireless events). Not sure what the rationale was on including this in Gentoo, you might want to consider reverting it until the issues are ironed out. When this patch is applied, Gentoo's baselayout scripts get fed up of waiting for the connection to be completed, so the system reports that ath0 didn't come up and it doesn't start any network services (sshd, etc).
(In reply to comment #0) > When this patch is applied, Gentoo's baselayout scripts get fed up of waiting > for the connection to be completed, so the system reports that ath0 didn't come > up and it doesn't start any network services (sshd, etc). Don't set a timeout then :) Once ath0 connects, baselayout will bring up the services depending on ath0.
(In reply to comment #0) > I just added a comment to http://madwifi.org/ticket/776 explaining why this > patch causes problems with wpa_supplicant (and everyone else who relies on > wireless events). Not sure what the rationale was on including this in Gentoo, > you might want to consider reverting it until the issues are ironed out. > > When this patch is applied, Gentoo's baselayout scripts get fed up of waiting > for the connection to be completed, so the system reports that ath0 didn't come > up and it doesn't start any network services (sshd, etc). > Confirmed. My Atheros PCMCIA card (D-link DWL-G650) doesn't like this at all; the stealth patch you snuck in caused nothing but troubles when i innocently ran module-rebuild to finish an unrelated update. I'm not impressed that this made it in to the distfiles I grabbed for the update, not without a proper revision. And the patch is broken; now everything takes a long time to associate and authenticate; I use wpa_supplicant, and have never had the minute-plus delays this patch introduces. used to get the interface initialized, associated, and authenticated in < 10 seconds. please revert this patch, steev, we're begging you. everything dsd described (and more) has happened to me. note that i *was* using the same unpatched version just fine, till i happened to grab the patched version distfiles on the rebuild.
Benjamin, As the problem has been reproduced by myself, Josh, Steve, and someone on the madwifi bug, we have removed this patch from portage. If this patch is required for you I suggest you get it fixed and applied upstream first. I might be able to help, I'll keep an eye on that bug report. Also, when adding patches to packages like this, you should revbump. I'm also assuming you had permission from mobile herd to commit this in the first place.
(In reply to comment #3) Reverting the patch definitely fixes 0.9.2 for me; back to better associate and authenticate times for me. No more waiting forever.
I indeed needed this patch. 0.9.1 worked for me, and 0.9.2 didn't - and the patch fixed it for me. I'll try to investigate further
This patch apparently fixed a strange problem for me. (bug#149762) Maybe it could be made optional via a USE flag.
This patch is no longer used, closing.