On Thu, Jun 26, 2008 at 7:27 PM, Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote: > On Thu, 2008-06-26 at 12:01 -0400, Pavel Roskin wrote: >> On Thu, 2008-06-26 at 17:46 +0200, Stefanik Gábor wrote: >> >> > Maybe we had more people working on/debugging AP mode if we didn't >> > intentionally disable the existing limited support for it... Possibly >> > print a big warning that "THIS IS NOT STANDARDS_COMPLIANT YET!", but >> > outright disabling it and requiring an external patch is IMHO stupid. >> > Perhaps a Kconfig option with EXPERIMENTAL and default=n would be >> > better. >> >> I agree. More people would be looking into AP support for individual >> drivers if mac80211 didn't need a patch. > > Oh and I never answered to this. I disagree. Requiring people to patch > their kernel for AP mode support is a good way to discourage > "contributors" who don't even know how to compile a kernel, trust me, > I've seen a fair share of private mails from those (which I ignore: do > not mail me in private about AP support). > > Hence, I don't want to do it for exactly this reason: a bunch of dumb > users will enable it either way, and actually _working_ on AP mode > _will_ require kernel patches, so this isn't one that matters. The problem is that the location of the patch is extremely non-obvious. Essentially one must know the location of either your or Michael Buesch's patchset before doing anything with AP mode. Also, to me "AP support requires mac80211 and nl80211 enhancements. In addition to this you need external wireless-test.git patches from johill and hostapd patches" (from the TODO-list) suggests that more than just the "Allow AP/VLAN modes" patch is required to get any AP support - in fact, it might feel like it's easier to just write a monitor-mode injection app that can do all AP work in userspace (á la airbase-ng, just with better system integration and feature set centered around normal operation, rather than penetration testing). Also, someone who can't patch a kernel likely also won't be able to compile and use a git build of hostapd. IMO this provides enough foolproofing. If we need more, then maybe add a secret and undocumented (but clearly deducible from the code, not obfuscated) parameter to hostapd, without which it refuses to handle nl80211-based interfaces. The location of the patch can in no way be deduced from the code. And, by the way, should we also require a patch for all experimental drivers? I don't think so. > > johannes > -- Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-) -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
