On Wed, Jan 18, 2006 at 12:36:09AM +0100, Stefan Rompf wrote:
> prism2 usb is even worse - the urb is build of some control structure, the
> 802.11 3 address header, a 802.3 header and the 802.11 data part. Some bits
> in the control structure decide whether the 802.11 or the 802.3 header is
> u
On Wed, Jan 18, 2006 at 09:32:49AM +, Simon Kelley wrote:
> That may be rather over-optimistic: the Atmel hardware dosen't even
> produce consistent results over different chip revs.
But each chip on its own is fairly consistent, which is all that
random users care about. "More bars mean bet
Olivier Blin wrote:
The main problems we got in the past year is the lack of a standard
and reliable signal level report, but it will probably get solved when
all drivers are unified to use the same wireless stack.
That may be rather over-optimistic: the Atmel hardware dosen't even
produce co
Hi,
Jean Tourrilhes wrote:
> All AP changes are sent as wireless events (for drivers that
> implement iwevent), so you can use that to track APs. Kernel has no
> way to know at which rate you want to check signal strenght, and for
> some card this involve interrogating the card (i.e. I/O ove
On Tuesday 17 January 2006 12:37, Jirka Bohac wrote:
> At the present time, the ieee80211 stack is used by ipw2x00
> (heavily) and hostap (a little bit). Other mainline drivers only use
> headers (mainly constants).
>
> If it shows that the DeviceScape stack is more mature and
> appropriate (which
Am Sonntag 15 Januar 2006 16:39 schrieb Stuffed Crust:
> Internally, we're pure 802.11. One thing to keep in mind that we're not
> going to be bridging/translating non-data traffic to other networks, and
> with that in mind, 802.3<->802.11 translation is trivial, and won't lose
> anything except
Am Dienstag 17 Januar 2006 19:37 schrieb Jirka Bohac:
> - DeviceScape can be there so it can be polished and new drivers can
> start using it.
> - ieee80211 could be there with a big fat warning that it will go
> away soon, just to allow ipw2x00 to work while DeviceScape and
> the ipw2x00 po
Am Sonntag 15 Januar 2006 21:11 schrieb Johannes Berg:
> [iwconfig mode ...]
>
> Yeah, I agree with this, it is much cleaner to handle in the kernel.
> Think about the issues if you have a struct net_device that has 250
> bytes of "payload" for the struct virtual_sta_device in it and you want
> to
Jean Tourrilhes <[EMAIL PROTECTED]> writes:
>> Please consider this page about drakroam and net_applet as well:
>> http://qa.mandriva.com/twiki/bin/view/Main/EasyWifi
>
> NetApplet was already on my page, but thanks to you I've
> checked it and it's now 404. Well, assuming your netapplet is
On Tue, Jan 17, 2006 at 08:23:50PM +0100, Olivier Blin wrote:
>
> And most of the time, userland has to poll for scan results or
> association status, netlink notifications would help.
> For example, it would be a lot easier for ifplugd to listen on a
> netlink, instead of polling for current AP a
Jean Tourrilhes <[EMAIL PROTECTED]> writes:
> On Sat, Jan 14, 2006 at 02:51:14PM +0100, Michael Buesch wrote:
>> On Saturday 14 January 2006 00:03, you wrote:
>> > As an aside to this whole thing, I know we're talking about *kernel*
>> > wireless
>> > but it's worthless to most people without go
On Jan 17, 2006, at 13:41, Stuffed Crust wrote:
On Mon, Jan 16, 2006 at 10:24:41PM +, Alan Cox wrote:
If I have told my equipment to obey UK law I expect it to do so.
If I hop on the train to France and forget to revise my
configuration I'd prefer it also believed the APs
It's not that
On Mon, Jan 16, 2006 at 10:24:41PM +, Alan Cox wrote:
> If I have told my equipment to obey UK law I expect it to do so. If I
> hop on the train to France and forget to revise my configuration I'd
> prefer it also believed the APs
It's not that you might forget to revise your configuration, bu
Hi,
On Fri, Jan 13, 2006 at 05:03:28PM -0600, Chase Venters wrote:
> On Friday 13 January 2006 15:32, John W. Linville wrote:
> > What about the suggestion of having both stacks in the kernel at once?
> > I'm not very excited about two in-kernel stacks. Still, consolidating
> > wireless drivers d
On Sat, Jan 14, 2006 at 02:51:14PM +0100, Michael Buesch wrote:
> On Saturday 14 January 2006 00:03, you wrote:
> > As an aside to this whole thing, I know we're talking about *kernel*
> > wireless
> > but it's worthless to most people without good userland support as well.
> > Anyone have any t
On Mon, Jan 16, 2006 at 10:24:41PM +, Alan Cox wrote:
> I would expect equipment to honour the subset of configurations that
> meet BOTH the regulatory domain the system believes it exists within
> (which may change dynamically!) AND the AP advertisement.
>
> If I have told my equipment to ob
On Llu, 2006-01-16 at 14:06 -0500, John W. Linville wrote:
> If regulators come down on someone, it seems like common sense
> that they would be more lenient on mobile stations complying with a
> misconfigured AP than they would be with a mobile station ignoring a
> properly configured AP? I know
On Mon, Jan 16, 2006 at 10:16:06PM +0200, Samuel Ortiz wrote:
> Well, I'd rather trust a governement regulated network than my neighbour's
> AP ;-) In fact, some phones set their 802.11 regulatory domain based on
> the information they received from a somehow government regulated network,
> e.g. a
On Mon, Jan 16, 2006 at 12:14:08PM -0800, Sam Leffler wrote:
> Please read what I wrote again. Station mode power save work involves
> communicating with the ap and managing the hardware. The first
> interacts with bg scanning. We haven't even talked about how to handle
> sta mode power save.
On Mon, 16 Jan 2006, ext John W. Linville wrote:
> On Mon, Jan 16, 2006 at 08:51:31PM +0200, Samuel Ortiz wrote:
> > On Mon, 16 Jan 2006, ext Stuffed Crust wrote:
> >
> > > On Sun, Jan 15, 2006 at 09:05:33PM +0200, Samuel Ortiz wrote:
> > > > Regarding 802.11d and regulatory domains, the stack sho
Stuffed Crust wrote:
On Mon, Jan 16, 2006 at 09:54:15AM -0800, Sam Leffler wrote:
The way you implement bg scanning is to notify the ap you are going into
power save mode before you leave the channel (in sta mode). Hence bg
scanning and power save operation interact.
That is not "powersave o
On Mon, Jan 16, 2006 at 10:00:18AM -0800, Sam Leffler wrote:
> Perhaps you haven't hit some of the more recent standards that place
> more of a burden on the ap implementation? Also some vendor-specific
> protocol features suck up space for ap mode only and it is nice to be
> able to include th
On Mon, 16 Jan 2006, ext Stuffed Crust wrote:
> You may hear another beacon when the STA is awake, you may not. BSSID
> filtering has nothing to do with 802.11 power save, but rather is
> intented to reduce the host load (interrupts, processing overhead) and
> thus the host power consumption.
I k
On Mon, Jan 16, 2006 at 09:07:52PM +0200, Samuel Ortiz wrote:
> That is true, thin MACs usually don't filter beacons on the same channel.
> But in some cases (mainly power saving), you really want to avoid
> receiving useless beacons and having the host woken up for each of them.
> You may even wan
On Mon, Jan 16, 2006 at 09:54:15AM -0800, Sam Leffler wrote:
> The way you implement bg scanning is to notify the ap you are going into
> power save mode before you leave the channel (in sta mode). Hence bg
> scanning and power save operation interact.
That is not "powersave operation" -- that
On Mon, 16 Jan 2006, ext Stuffed Crust wrote:
> Background scanning, yes -- but there are all sorts of different
> thresholds and types of 'scanning' to be done, depending on how
> disruptive you are willing to be, and how capable the hardware is. Most
> thin MACs don't filter out foreign BSSIDs
On Mon, Jan 16, 2006 at 08:51:31PM +0200, Samuel Ortiz wrote:
> On Mon, 16 Jan 2006, ext Stuffed Crust wrote:
>
> > On Sun, Jan 15, 2006 at 09:05:33PM +0200, Samuel Ortiz wrote:
> > > Regarding 802.11d and regulatory domains, the stack should also be able to
> > > stick to one regulatory domain if
On Mon, 16 Jan 2006, ext Stuffed Crust wrote:
> On Sun, Jan 15, 2006 at 09:05:33PM +0200, Samuel Ortiz wrote:
> > Regarding 802.11d and regulatory domains, the stack should also be able to
> > stick to one regulatory domain if asked so by userspace, whatever the APs
> > around tell us.
>
> ...and
On Mon, 2006-01-16 at 12:28 -0500, Stuffed Crust wrote:
> Scans should be specified as "non-distruptive" so the hardware driver
> has to twiddle whatever bits are necessary to return the hardware to the
> same state that it was in before the scan kicked in. Beyond that, the
> scanning smarts are a
Stuffed Crust wrote:
On Mon, Jan 16, 2006 at 03:55:55PM +0100, Johannes Berg wrote:
I really don't see why a plain STA mode card should be required to carry
around all the code required for AP operation -- handling associations
of clients, powersave management wrt. buffering, ... Sure, fragment
Stuffed Crust wrote:
On Sun, Jan 15, 2006 at 11:53:55AM -0800, Sam Leffler wrote:
The above is a great synopsis but there is more. For example to support
roaming (and sometimes for ap operation) you want to do background
scanning; this ties in to power save mode if operating as a station.
On Mon, Jan 16, 2006 at 03:55:55PM +0100, Johannes Berg wrote:
> I really don't see why a plain STA mode card should be required to carry
> around all the code required for AP operation -- handling associations
> of clients, powersave management wrt. buffering, ... Sure, fragmentation
From the per
On Sun, Jan 15, 2006 at 11:53:55AM -0800, Sam Leffler wrote:
> The above is a great synopsis but there is more. For example to support
> roaming (and sometimes for ap operation) you want to do background
> scanning; this ties in to power save mode if operating as a station.
Opportunistic roami
On Sun, Jan 15, 2006 at 09:05:33PM +0200, Samuel Ortiz wrote:
> Regarding 802.11d and regulatory domains, the stack should also be able to
> stick to one regulatory domain if asked so by userspace, whatever the APs
> around tell us.
...and in doing so, violate the local regulatory constraints. :)
On Mon, 2006-01-16 at 15:23 +0100, Jiri Benc wrote:
> You are right. But it breaks compatibility with iwconfig unless we
> emulate 'iwconfig mode' command by deleting and adding interface. This
> means some events are generated, hotplug/udev gets involved etc. In the
> worst case it can mean that
On Sat, 2006-01-14 at 19:56 -0500, John W. Linville wrote:
> Yes, someone (Johannes? Jiri?) had the beginnings of this a few days
> ago, but I seem to have lost the link. Could someone repost it?
http://johannes.sipsolutions.net/802.11_stacks/
Someone should start a new page to collect all the
On Fri, 13 Jan 2006 23:32:02 +0100, Johannes Berg wrote:
> IMHO there's not much point in allowing changes. I have a feeling that
> might create icky issues you don't want to have to tackle when the
> solution is easy by just not allowing it. Part of my thinking is that
> different virtual types ha
y a binary code block.
Simon
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Jeff Garzik
Sent: Saturday, January 14, 2006 2:09 PM
To: John W. Linville
Cc: netdev@vger.kernel.org; linux-kernel@vger.kernel.org
Subject: Re: wireless: recap of current iss
On Sun, Jan 15, 2006 at 11:39:41AM -0800, Sam Leffler wrote:
> The big stumbling block I found to going with virtual devices is that it
> affects user apps. I looked at doing things like auto-create a station
> device for backwards compatibility but decided against it. If you
> really want thi
On Sun, 15 Jan 2006, ext Stuffed Crust wrote:
> * Knowing the hardware frequency capabilities, the 802.11 stack applies
>802.11d and regdomain rules to the available frequency set, and
Regarding 802.11d and regulatory domains, the stack should also be able to
stick to one regulatory domain if
On Sun, 2006-01-15 at 12:08 -0800, Sam Leffler wrote:
> To do what you describe I would create a monitor mode device, switch
> channel, then destroy it. All the time you leave the station device
> unchanged, though you probably need to disable it. This may not be
> possible with all devices--
Stefan Rompf wrote:
Am Sonntag 15 Januar 2006 16:51 schrieb Johannes Berg:
Isn't that rather a question of having good user-space tools that make
deactivating one type of interface and activating another seamless?
Well, it's always easy to point to userspace. However, unregister_netdev()
ini
Stuffed Crust wrote:
On Sat, Jan 14, 2006 at 05:07:01PM -0500, Jeff Garzik wrote:
This can be accomplished by passing a static table to the
register_wiphy_device() call (or perhaps via a struct wiphy_dev
parameter) or through a more explicit, dynamic interface like:
wiphy_register_supported_
Stefan Rompf wrote:
Am Samstag 14 Januar 2006 14:47 schrieb Ulrich Kunitz:
They one problem I can see is scanning over several frequencies.
If two virtual devices are doing this at the same time, we have a
conflict. Maybe each WiPHY would have only one active interface,
I think scanning can b
Stefan Rompf wrote:
Am Freitag 13 Januar 2006 23:32 schrieb Johannes Berg:
[Changing mode of virtual devices]
IMHO there's not much point in allowing changes. I have a feeling that
might create icky issues you don't want to have to tackle when the
solution is easy by just not allowing it. Part
Am Sonntag 15 Januar 2006 16:51 schrieb Johannes Berg:
> Isn't that rather a question of having good user-space tools that make
> deactivating one type of interface and activating another seamless?
Well, it's always easy to point to userspace. However, unregister_netdev()
initiates a lot of acti
On Sat, Jan 14, 2006 at 06:41:56PM -0500, Dan Williams wrote:
> One other thing: capability. It's not enough to be able to configure
> the device, user-space tools also have to know what the device is
> capable of before they try touching it. Ie, which ciphers, protocols,
> channels, etc. Simila
Stefan Rompf wrote:
> Even though it is a bit more work on kernel side, we should allow changing
> the
> mode of virtual devices. Let's face it, even though we find multi-BSS
> capabilities very interesting, 999 of 1000 users won't care due to the two
> facts that IPW firmware IMHO doesn't allow i
On Sat, Jan 14, 2006 at 05:09:23PM -0500, Jeff Garzik wrote:
> A big open issue: should you fake ethernet, or represent 802.11
> natively throughout the rest of the net stack?
>
> The former causes various and sundry hacks, and the latter requires that
> you touch a bunch of non-802.11 code to
On Sat, Jan 14, 2006 at 05:07:01PM -0500, Jeff Garzik wrote:
> >This can be accomplished by passing a static table to the
> >register_wiphy_device() call (or perhaps via a struct wiphy_dev
> >parameter) or through a more explicit, dynamic interface like:
> >
> > wiphy_register_supported_frequenc
Am Samstag 14 Januar 2006 14:47 schrieb Ulrich Kunitz:
> They one problem I can see is scanning over several frequencies.
> If two virtual devices are doing this at the same time, we have a
> conflict. Maybe each WiPHY would have only one active interface,
I think scanning can be easily serialize
Am Freitag 13 Januar 2006 23:32 schrieb Johannes Berg:
> [Changing mode of virtual devices]
>
> IMHO there's not much point in allowing changes. I have a feeling that
> might create icky issues you don't want to have to tackle when the
> solution is easy by just not allowing it. Part of my thinkin
On 1/14/06, David S. Miller <[EMAIL PROTECTED]> wrote:
> From: Jeff Garzik <[EMAIL PROTECTED]>
> Date: Sat, 14 Jan 2006 17:09:23 -0500
>
> > A big open issue: should you fake ethernet, or represent 802.11
> > natively throughout the rest of the net stack?
> >
> > The former causes various and sund
On Sat, 14 Jan 2006, Pete Zaitcev wrote:
> On Sat, 14 Jan 2006 15:13:39 +0100 (CET), Ulrich Kunitz <[EMAIL PROTECTED]>
> wrote:
>
> > [...] Register accesses in USB devices should be
> > able to sleep. However the 80211 stacks I've seen so far have a
> > fixed set of capabilities and do also ass
John W. Linville wrote:
> Configuration seems to be coalescing around netlink. Among other
> things, this technology provides for muliticast requests and
> asynchronous event notification.
On the other hand, the tree structure of sysfs can handle the
resource exclusivity and sharing naturaly.
A
On Sat, 14 Jan 2006 15:13:39 +0100 (CET), Ulrich Kunitz <[EMAIL PROTECTED]>
wrote:
> [...] Register accesses in USB devices should be
> able to sleep. However the 80211 stacks I've seen so far have a
> fixed set of capabilities and do also assume, that at the driver
> layer everything can be done
From: Jeff Garzik <[EMAIL PROTECTED]>
Date: Sat, 14 Jan 2006 17:09:23 -0500
> A big open issue: should you fake ethernet, or represent 802.11
> natively throughout the rest of the net stack?
>
> The former causes various and sundry hacks, and the latter requires that
> you touch a bunch of non
On Sat, Jan 14, 2006 at 05:11:27PM -0500, Jeff Garzik wrote:
> John W. Linville wrote:
> >Since we are toying with the issue of multiple stacks (at least in the
> >wireless development kernels), some thought needs to be done w.r.t. how
> >to make a final decision between the two stacks. An object
On Sat, Jan 14, 2006 at 05:09:23PM -0500, Jeff Garzik wrote:
> John W. Linville wrote:
> >Other Issues
> >
>
> A big open issue: should you fake ethernet, or represent 802.11
> natively throughout the rest of the net stack?
>
> The former causes various and sundry hacks, and the lat
On Fri, 2006-01-13 at 17:19 -0500, John W. Linville wrote:
> Configuration
> =
>
> Configuration seems to be coalescing around netlink. Among other
> things, this technology provides for muliticast requests and
> asynchronous event notification.
>
> The kernel should provide generic
On Sat, 2006-01-14 at 10:46 +, Simon Kelley wrote:
> Chase Venters wrote:
>
> > As an aside to this whole thing, I know we're talking about *kernel*
> > wireless
> > but it's worthless to most people without good userland support as well.
> > Anyone have any thoughts and feelings on what th
John W. Linville wrote:
Actions
===
I need to establish a public git tree for wireless. I would like for
this to be on kernel.org, but I haven't got an account established
there yet. I've been dragging my feet a little, hoping that the
kernel.org account would materialize.
Since we are
John W. Linville wrote:
Other Issues
A big open issue: should you fake ethernet, or represent 802.11
natively throughout the rest of the net stack?
The former causes various and sundry hacks, and the latter requires that
you touch a bunch of non-802.11 code to make it aware of
Stuffed Crust wrote:
The hardware knows what frequencies it supports. Unfortunately this has
to be a somewhat dynamic thing, as this is often not queryable until the
device firmware is up and running.
This can be accomplished by passing a static table to the
register_wiphy_device() call (or
On Fri, 13 Jan 2006, John W. Linville wrote:
> Can the in-kernel stack be saved? With the addition of softmac?
> Is it possible to extend softmac to support virtual wlan devices?
> If not, how do we proceed?
I don't think, that we can continue with the current model of the
stacks. There appears
On Saturday 14 January 2006 00:03, you wrote:
> As an aside to this whole thing, I know we're talking about *kernel* wireless
> but it's worthless to most people without good userland support as well.
> Anyone have any thoughts and feelings on what things look like on the
> desktop? I think if w
Johannes Berg <[EMAIL PROTECTED]> writes:
> Yeah, this is about what I thought of -- and it makes me wonder if the
> stack really should be aware of the channelization, or if the WiPHY
> driver might better just handle it itself.
The latter, possibly using library functions from the stack :-)
--
On Fri, 13 Jan 2006, John W. Linville wrote:
> Configuration
> =
>
> At init, physical devices should be represented by a "WiPHY" device,
> not directly by a net_device. The list of physical devices should
> be discoverable through netlink and/or sysfs. (A WiPHY device is an
> abstr
Johannes Berg <[EMAIL PROTECTED]> writes:
> If you want the old userspace API to 'just work' you have to create one
> default wlan device at WiPHY init.
I'm not sure the old API is that important. This isn't something
programs (third party, kernel utils don't count) rely on. Most users
would swit
Chase Venters wrote:
As an aside to this whole thing, I know we're talking about *kernel* wireless
but it's worthless to most people without good userland support as well.
Anyone have any thoughts and feelings on what things look like on the
desktop? I think if we work closely with some deskto
On Fri, 2006-01-13 at 20:17 -0500, Stuffed Crust wrote:
> If you're talking about the former.. things get quite complicated, but
> that could be handled by having two WiPHY devices registered.
The former; and yes, I thought about that too -- having a driver that
shows two physical WiPHY devices
On Fri, Jan 13, 2006 at 11:32:02PM +0100, Johannes Berg wrote:
> I'm not sure this is worth it. While putting this into the WiPHY device
> creates more logic there, putting knowledge like 'how many different
> channels can this WiPHY device support' etc. into some representation
> that can be used
"John W. Linville" <[EMAIL PROTECTED]> writes:
> Virtual devices will have a mode (e.g. station, AP, WDS, ad-hoc, rfmon,
> raw?, other modes?) which defines its "on the air" behaviour. Should
> this mode be fixed when the wlan device is created?
I think so. If needed one can delete and create.
On Fri, 2006-01-13 at 23:35 +0100, Johannes Berg wrote:
> On Fri, 2006-01-13 at 17:24 -0500, John W. Linville wrote:
>
> > Radiotap headers make sense for an rfmon virtual device. I don't
> > think it makes sense for "normal" usage. Should there be an option
> > for radiotap headers on non-rfmon
On Friday 13 January 2006 15:32, John W. Linville wrote:
> Do we need to have both wireless-stable and wireless-devel kernels?
> What about the suggestion of having both stacks in the kernel at once?
> I'm not very excited about two in-kernel stacks. Still, consolidating
> wireless drivers down to
This is a re-send since the lists ate my reply. I've also
trimmed out all but netdev and lkml email addresses.
> Do "global" config requests go to any associated wlan device?
> Or must they be directed to the WiPHY device? Does it matter?
> I think we should require "global" configuration to ta
On Fri, 2006-01-13 at 17:24 -0500, John W. Linville wrote:
> Radiotap headers make sense for an rfmon virtual device. I don't
> think it makes sense for "normal" usage. Should there be an option
> for radiotap headers on non-rfmon links?
Yes. For hardware debugging.
> Rfmon interferes w/ other
On Fri, 2006-01-13 at 17:22 -0500, John W. Linville wrote:
> Can the in-kernel stack be saved? With the addition of softmac?
> Is it possible to extend softmac to support virtual wlan devices?
> If not, how do we proceed?
Well, softmac doesn't really have too many issues [that make it
incompatib
On Fri, 2006-01-13 at 17:25 -0500, John W. Linville wrote:
> Since we are toying with the issue of multiple stacks (at least in the
> wireless development kernels), some thought needs to be done w.r.t. how
> to make a final decision between the two stacks. An objective lists
> of functional featu
> The netlink configuration mechanism needs compatibility code to
> translate wireless extension ioctls into netlink transactions.
I think we could restrict this to allow ioctl configuration only if
there's just a single active virtual dev [excluding some special cases
like changing the mode whic
[since none our replies made it to the lists, here mine are again.
apologies to those who see it twice, just skip it, I only pasted my
previous replies]
> Virtual devices will have a mode (e.g. station, AP, WDS, ad-hoc, rfmon,
> raw?, other modes?) which defines its "on the air" behaviour. Should
Stack
=
Is the in-kernel stack up-to-date w/ SourceForge? No. Why not?
Can this development be brought into wireless development kernels?
Can the in-kernel stack be saved? With the addition of softmac?
Is it possible to extend softmac to support virtual wlan devices?
If not, how do we proc
Other Issues
Radiotap headers make sense for an rfmon virtual device. I don't
think it makes sense for "normal" usage. Should there be an option
for radiotap headers on non-rfmon links?
Rfmon interferes w/ other interfaces, but may be handy to enter/leave
w/ little effort. Perhaps
Actions
===
I need to establish a public git tree for wireless. I would like for
this to be on kernel.org, but I haven't got an account established
there yet. I've been dragging my feet a little, hoping that the
kernel.org account would materialize.
I intend to get the sipsolutions softmac
Compatibility
=
The netlink configuration mechanism needs compatibility code to
translate wireless extension ioctls into netlink transactions.
We need to be an 802.11 stack (i.e. drivers need to handle 802.11
frames). Ethernet emulation is bound to paint us into a corner
eventually (
Configuration
=
Configuration seems to be coalescing around netlink. Among other
things, this technology provides for muliticast requests and
asynchronous event notification.
The kernel should provide generic handlers for netlink
configuraion messages, and there should be a per-devic
My original post got eaten by the lists -- probably too big...
I'm reposting in sections. After this intro follow sections on
Configuration, Compatibility, Stack, Other Issues, and Actions.
Enjoy! :-)
---
WiFi-ers...
Here I am, still feeling "up to the challenge"... I have stopped
hyper-venti
87 matches
Mail list logo
