lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Thu, 4 Dec 2008 11:21:43 -0800 From: Inaky Perez-Gonzalez <inaky@...ux.intel.com> To: Johannes Berg <johannes@...solutions.net> Cc: netdev <netdev@...r.kernel.org> Subject: Re: [PATCH 00/39] merge request for WiMAX kernel stack and i2400m driver v2 On Thursday 04 December 2008, Johannes Berg wrote: > On Tue, 2008-12-02 at 18:07 -0800, Inaky Perez-Gonzalez wrote: > > For scanning, some devices require to be told exactly where to scan in > > (as in which combination of band, fft width and coloring of the > > band). Some others don't. > > But things like these are fairly easy to cover, just allow netlink > attributes to specify where to scan, and allow drivers to disregard > them, no harm caused. Maybe include a capability bit, like I'm adding to > nl80211 in my scanning patch (not included yet) that includes a > capability for how many SSIDs it can scan actively at once. The implementation details are not the problem, there I totally agree with you. The problem is how to establish the cutline. What you are saying is exactly how I envision it to happen and the direction I'd like it to take, but I just don't want to do it until at least we have two vendors talking. > > Then of course, the scan results might be > > operators? Network Service Providers? Network Access Providers? base > > station IDs? how do you stitch'em together? You need information to > > map from one to the other, and that is device specific depending on at > > which level they work. How to stich that information together depends > > on the network too (OMA-DM and provisining information help to compose > > this). If it is done at the device/firmware level or at the host level > > is device specific. > > I have no idea about these things, obviously. But what's wrong with just > defining the scan operation with netlink attributes as you need them now > (say the scan returns NSPs) and then later when somebody needs to return > NAPs add a new attribute? Userspace will easily be able to figure out > which one it got by looking at which attributes are present. Call me chicken :) [more below] > > Connect has exactly the same levels of issues as scan: what do I > > connect to? A base station? a NAP or an NSP? > > > > So back to the original question: I have no information to define such > > an interface at low level, so I am not defining it. Simple :/ > > Here's where I disagree, obviously, I think you should at least define a > subset of the imaginable interface, which is, in my opinion, _much_ > better than defining no interface at all and hoping for the next guy to > figure it out, which is unlikely to happen when you haven't started with > something the next guy can understand. No wait, I don't want guy #2 to define it--I want to work together to define it, to make sure it works for him and for me without having to throw to the garbage something I did on my own that won't work. > > > This really means you're putting the actual "driver", the piece that > > > does the hardware abstraction, into userspace. And in a binary daemon > > > even, afaict. This was quickly shot down with ipw3945/4965, not sure > > > why nobody has cared here so far. Maybe because you're actually > > > planning to open source that part. > > > > Nope. I am putting the part that knows how to scan and connect in user > > space because it does not belong in kernel space. It is big and complex, > > needs permanent storage, requires complex crypto code and can really > > use a OMA-DM client to communicate with the network. > > Ok, I guess that makes sense then, I'm not aware of all the details. > > > Not a binary, btw. Currently the supplicant is a binary, but that will > > change. The OMA-DM client daemon is also a binary as of now and we > > are still thinking how to fix that situation, as there are no open > > source equivalents. Luckily, it is kind of optional. > > Ok, thanks for the explanation. > > johannes -- Inaky -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists