On Sat, 2006-08-19 at 00:02 +0200, Michael Buesch wrote:
> We currently know 6 different radio chips used by bcm43xx:
> http://bcm-specs.sipsolutions.net/RadioID
>
> AFAIK the chip is from broadcom, too.
It is, and there is no datasheet.
See http://johannes.sipsolutions.net/files/asus-wl100g.pn
On Fri, 2006-08-18 at 09:45 -0700, Simon Barber wrote:
> I did mean RSSI - just about anything that when interpreted as an 8 bit
> unsigned int and goes up with increasing signal fits the bill as an RSSI
> measure. RCPI requires a certain minimum accuracy and linearity (the
> accuracy required is n
On Friday 18 August 2006 23:29, Ulrich Kunitz wrote:
> On 06-08-18 09:12 Johannes Berg wrote:
>
> > On Fri, 2006-08-18 at 01:29 +0200, Ulrich Kunitz wrote:
> > > Or are here people, who
> > > really want to freely transmit on all frequencies their RF might
> > > be able to generate?
> >
> > Yes :
On 06-08-18 09:12 Johannes Berg wrote:
> On Fri, 2006-08-18 at 01:29 +0200, Ulrich Kunitz wrote:
> > Or are here people, who
> > really want to freely transmit on all frequencies their RF might
> > be able to generate?
>
> Yes :P
> Some amateur radio people asked me about extending the spectrum a
: Johannes Berg [mailto:[EMAIL PROTECTED]
Sent: Friday, August 18, 2006 12:02 AM
To: Simon Barber
Cc: Dan Williams; netdev@vger.kernel.org; Jean Tourrilhes
Subject: RE: proposal for new wireless configuration API
On Thu, 2006-08-17 at 09:42 -0700, Simon Barber wrote:
> The spec for RSSI is very lo
On Fri, Aug 18, 2006 at 09:12:05AM +0200, Johannes Berg wrote:
> On Fri, 2006-08-18 at 01:29 +0200, Ulrich Kunitz wrote:
> > Or are here people, who
> > really want to freely transmit on all frequencies their RF might
> > be able to generate?
>
> Yes :P
> Some amateur radio people asked me about e
On Fri, 2006-08-18 at 01:29 +0200, Ulrich Kunitz wrote:
> Or are here people, who
> really want to freely transmit on all frequencies their RF might
> be able to generate?
Yes :P
Some amateur radio people asked me about extending the spectrum a bit to
the top (apparently they're allowed to use the
On Thu, 2006-08-17 at 09:42 -0700, Simon Barber wrote:
> The spec for RSSI is very loose - RSSI is just a 8 bit unsigned number,
> guaranteed to be a monotonically increasing function of signal strength.
> You don't get to know anything about the scale, or linearity of the
> function. In essence RS
On 06-08-15 18:38 Michael Buesch wrote:
> On Tuesday 15 August 2006 18:29, Dan Williams wrote:
> > o Separate attributes for channel and frequency
>
> No, channel and freq is the same. It's just another name
> for the same child. I would say we only want to deal with channel numbers
> in the API.
On 06-08-17 09:42 Simon Barber wrote:
> The spec for RSSI is very loose - RSSI is just a 8 bit unsigned number,
> guaranteed to be a monotonically increasing function of signal strength.
> You don't get to know anything about the scale, or linearity of the
> function. In essence RSSI is a vendor s
On Thursday 17 August 2006 21:39, Jean Tourrilhes wrote:
> On Tue, Aug 15, 2006 at 09:13:23PM +0200, Michael Buesch wrote:
> > On Tuesday 15 August 2006 20:14, Dan Williams wrote:
> > > On Tue, 2006-08-15 at 18:38 +0200, Michael Buesch wrote:
> > > > On Tuesday 15 August 2006 18:29, Dan Williams wr
On Tue, Aug 15, 2006 at 09:13:23PM +0200, Michael Buesch wrote:
> On Tuesday 15 August 2006 20:14, Dan Williams wrote:
> > On Tue, 2006-08-15 at 18:38 +0200, Michael Buesch wrote:
> > > On Tuesday 15 August 2006 18:29, Dan Williams wrote:
> > > > o Separate attributes for channel and frequency
> >
s not very useful.
Simon
-Original Message-
From: Johannes Berg [mailto:[EMAIL PROTECTED]
Sent: Thursday, August 17, 2006 12:20 AM
To: Simon Barber
Cc: Dan Williams; netdev@vger.kernel.org; Jean Tourrilhes
Subject: RE: proposal for new wireless configuration API
On Wed, 2006-08-16 at
On Wed, 2006-08-16 at 11:02 -0700, Simon Barber wrote:
> I'd suggest that the new signal strength measure should be defined as
> 'RCPI' - the 'Received Channel Power Indicator' - which is defined in
> IEEE 802.11k (the Radio Measurements amendment to 802.11).
Except that we unfortunately have no w
11:51 PM
To: Dan Williams
Cc: netdev@vger.kernel.org; Jean Tourrilhes
Subject: Re: proposal for new wireless configuration API
On Tue, 2006-08-15 at 12:29 -0400, Dan Williams wrote:
> We might want to take the time to fix up a few of the ambiguities of
> WEXT that we've encountered over th
On Tue, 2006-08-15 at 12:14 -0400, Luis R. Rodriguez wrote:
> Basically redo WE completely from scratch using netlink.
Not quite, I hope! As Dan mentioned, for example all the key management
stuff ought to be consolidated. Same for some other things.
> For per packet this makes sense, for modifi
On Tue, 2006-08-15 at 15:59 -0400, Dan Williams wrote:
> Ok, so if somebody magically opens up new unlicensed ISM spectrum
> around, say, 7GHz, does that space get broken into channels and assigned
> specific numbers by the IEEE?
>
> I know there are stable channel #s for abg range. What about t
On Tue, 2006-08-15 at 12:29 -0400, Dan Williams wrote:
> We might want to take the time to fix up a few of the ambiguities of
> WEXT that we've encountered over the past few years:
Yes, I definitely agree.
> o Separate attributes for signal strength units; signed integer type for
> dBm, unsigned
On Tue, 2006-08-15 at 21:35 +0200, Michael Buesch wrote:
> On Tuesday 15 August 2006 21:27, Simon Barber wrote:
> > A further complication happens in Japan with 802.11j, and now in the USA
> > too - with 802.11y in the 3.65Ghz band - here there are some new channel
> > widths that are possible. Nor
On Tue, 2006-08-15 at 21:13 +0200, Michael Buesch wrote:
> On Tuesday 15 August 2006 20:14, Dan Williams wrote:
> > On Tue, 2006-08-15 at 18:38 +0200, Michael Buesch wrote:
> > > On Tuesday 15 August 2006 18:29, Dan Williams wrote:
> > > > o Separate attributes for channel and frequency
> > >
> >
On Tuesday 15 August 2006 21:27, Simon Barber wrote:
> A further complication happens in Japan with 802.11j, and now in the USA
> too - with 802.11y in the 3.65Ghz band - here there are some new channel
> widths that are possible. Normally 802.11 is 20 or 22Mhz wide (20Mhz for
> OFDM modulations -
August 15, 2006 12:13 PM
To: Dan Williams
Cc: netdev@vger.kernel.org; Jean Tourrilhes; Johannes Berg
Subject: Re: proposal for new wireless configuration API
On Tuesday 15 August 2006 20:14, Dan Williams wrote:
> On Tue, 2006-08-15 at 18:38 +0200, Michael Buesch wrote:
> > On Tuesday 15 Aug
On Tuesday 15 August 2006 20:14, Dan Williams wrote:
> On Tue, 2006-08-15 at 18:38 +0200, Michael Buesch wrote:
> > On Tuesday 15 August 2006 18:29, Dan Williams wrote:
> > > o Separate attributes for channel and frequency
> >
> > No, channel and freq is the same. It's just another name
> > for th
On Tue, 2006-08-15 at 18:38 +0200, Michael Buesch wrote:
> On Tuesday 15 August 2006 18:29, Dan Williams wrote:
> > o Separate attributes for channel and frequency
>
> No, channel and freq is the same. It's just another name
> for the same child. I would say we only want to deal with channel numbe
On Tuesday 15 August 2006 18:29, Dan Williams wrote:
> o Separate attributes for channel and frequency
No, channel and freq is the same. It's just another name
for the same child. I would say we only want to deal with channel numbers
in the API. That's much easier, as we don't have to deal with th
On Tue, 2006-08-15 at 17:28 +0200, Johannes Berg wrote:
> Hi,
>
> So I've thought about this all day long... After writing this mail I'll
> go home and hope my inbox collects some feedback ;)
We might want to take the time to fix up a few of the ambiguities of
WEXT that we've encountered over the
This all sounds good to me. A few comments here, to give you something
to read when you get home.
On 8/15/06, Johannes Berg <[EMAIL PROTECTED]> wrote:
- we implement a bunch of commands, for example NL80211_CMD_INJECT and
_SETATTR, _GETATTR[(attrnumber)] [easy with dumpit()],
_GETATTRGRO
Hi,
So I've thought about this all day long... After writing this mail I'll
go home and hope my inbox collects some feedback ;)
I've arrived at the following conclusions:
* we want to use genetlink
* we need an equivalent of the old commit() call,
but without all the stupidity
* we want to
28 matches
Mail list logo
