ieee80211-devel — List for discussing development of ieee80211 subsystem

[Ieee80211-devel] Git broken for IPW2200

[Alejandro B. B. <abo...@li...>]

Hi,

	Where does one report this? I was building Linus Git tree as per I
updated it at 09/07/2005 7:00PM PDT and got this while compiling.

Where do I report this?

Debian unstable updated at same time.

it looks like ipw2200 is thinking that ieee80211 is not compiled in, but
I did select it as a module?

drivers/net/wireless/ipw2200.c:6676: error: dereferencing pointer to
incomplete type
drivers/net/wireless/ipw2200.c:6677: error: dereferencing pointer to
incomplete type
drivers/net/wireless/ipw2200.c:6679: error: dereferencing pointer to
incomplete type
drivers/net/wireless/ipw2200.c:6679: error: 'WLAN_AUTH_SHARED_KEY'
undeclared (first use in this function)
drivers/net/wireless/ipw2200.c:6686: error: dereferencing pointer to
incomplete type
drivers/net/wireless/ipw2200.c:6686: error: 'SEC_ENABLED' undeclared
(first use in this function)
drivers/net/wireless/ipw2200.c:6687: error: dereferencing pointer to
incomplete type
drivers/net/wireless/ipw2200.c:6689: error: dereferencing pointer to
incomplete type
drivers/net/wireless/ipw2200.c:6691: error: dereferencing pointer to
incomplete type
drivers/net/wireless/ipw2200.c:6697: error: dereferencing pointer to
incomplete type
drivers/net/wireless/ipw2200.c:6697: error: 'SEC_LEVEL' undeclared
(first use in this function)
drivers/net/wireless/ipw2200.c:6698: error: dereferencing pointer to
incomplete type
drivers/net/wireless/ipw2200.c:6699: error: dereferencing pointer to
incomplete type
drivers/net/wireless/ipw2200.c: In function 'init_supported_rates':
drivers/net/wireless/ipw2200.c:6727: error: dereferencing pointer to
incomplete type
drivers/net/wireless/ipw2200.c:6728: error: 'IEEE80211_52GHZ_BAND'
undeclared (first use in this function)
drivers/net/wireless/ipw2200.c:6731: error: 'IEEE80211_CCK_MODULATION'
undeclared (first use in this function)
drivers/net/wireless/ipw2200.c:6732: error:
'IEEE80211_OFDM_DEFAULT_RATES_MASK' undeclared (first use in this
function)
drivers/net/wireless/ipw2200.c:6739: error:
'IEEE80211_CCK_DEFAULT_RATES_MASK' undeclared (first use in this
function)
drivers/net/wireless/ipw2200.c:6740: error: dereferencing pointer to
incomplete type
drivers/net/wireless/ipw2200.c:6740: error: 'IEEE80211_OFDM_MODULATION'
undeclared (first use in this function)
drivers/net/wireless/ipw2200.c: In function 'ipw_net_init':
drivers/net/wireless/ipw2200.c:6887: warning: initialization makes
pointer from integer without a cast
drivers/net/wireless/ipw2200.c: In function 'ipw_pci_probe':
drivers/net/wireless/ipw2200.c:6970: warning: implicit declaration of
function 'alloc_ieee80211'
drivers/net/wireless/ipw2200.c:6970: warning: assignment makes pointer
from integer without a cast
drivers/net/wireless/ipw2200.c:6976: warning: assignment makes pointer
from integer without a cast
drivers/net/wireless/ipw2200.c:7060: error: dereferencing pointer to
incomplete type
drivers/net/wireless/ipw2200.c:7069: error: dereferencing pointer to
incomplete type
drivers/net/wireless/ipw2200.c:7078: error: dereferencing pointer to
incomplete type
drivers/net/wireless/ipw2200.c:7079: error: 'IEEE80211_52GHZ_BAND'
undeclared (first use in this function)
drivers/net/wireless/ipw2200.c:7079: error: 'IEEE80211_24GHZ_BAND'
undeclared (first use in this function)
drivers/net/wireless/ipw2200.c:7080: error: 'IEEE80211_OFDM_MODULATION'
undeclared (first use in this function)
drivers/net/wireless/ipw2200.c:7081: error: 'IEEE80211_CCK_MODULATION'
undeclared (first use in this function)
drivers/net/wireless/ipw2200.c:7083: error: dereferencing pointer to
incomplete type
drivers/net/wireless/ipw2200.c:7083: error: 'IEEE_A' undeclared (first
use in this function)
drivers/net/wireless/ipw2200.c:7083: error: 'IEEE_G' undeclared (first
use in this function)
drivers/net/wireless/ipw2200.c:7083: error: 'IEEE_B' undeclared (first
use in this function)
drivers/net/wireless/ipw2200.c:7094: error: dereferencing pointer to
incomplete type
drivers/net/wireless/ipw2200.c:7099: error: dereferencing pointer to
incomplete type
drivers/net/wireless/ipw2200.c:7102: error: dereferencing pointer to
incomplete type
drivers/net/wireless/ipw2200.c:7103: error: dereferencing pointer to
incomplete type
drivers/net/wireless/ipw2200.c:7105: error:
'IEEE80211_DEFAULT_RATES_MASK' undeclared (first use in this function)
drivers/net/wireless/ipw2200.c:7126: error: dereferencing pointer to
incomplete type
drivers/net/wireless/ipw2200.c:7127: error: dereferencing pointer to
incomplete type
drivers/net/wireless/ipw2200.c:7172: warning: implicit declaration of
function 'free_ieee80211'
make[4]: *** [drivers/net/wireless/ipw2200.o] Error 1
make[3]: *** [drivers/net/wireless] Error 2
make[2]: *** [drivers/net] Error 2
make[1]: *** [drivers] Error 2
make[1]: Leaving directory `/root/linux-2.6'
make: *** [stamp-build] Error 2
debian:~/linux-2.6#

.Alejandro

[Ieee80211-devel] Question over Linus Git tree and ieee80211

[Alejandro B. B. <abo...@li...>]

I just did a new git pull from Linus tree and I have a question...

When I select ieee80211 as inline:
  x x           <*>   Generic IEEE 802.11 Networking Stack
x x  
  x x           [ ]     Enable full debugging output
x x  
  x x           <M>     IEEE 802.11 WEP encryption (802.1x)
x x  
  x x           <*>     IEEE 802.11i CCMP support
x x  
  x x           <*>     IEEE 802.11i TKIP encryption

It makes WEP a module. (Why does WEP say 802.1x? WEP is not 802.1x,
right?



When I select ieee80211 as a module:

  x x           <M>   Generic IEEE 802.11 Networking Stack
x x  
  x x           [ ]     Enable full debugging output
x x  
  x x           ---     IEEE 802.11 WEP encryption (802.1x)
x x  
  x x           <M>     IEEE 802.11i CCMP support
x x  
  x x           <M>     IEEE 802.11i TKIP encryption 

It -- blanks WEP support, Why is that? And dammed WEP still says
8021.x :|


Also, I had already done a git pull from linus tree and it did have
ieee80211 in it, and since the one I did 5 minutes ago, make oldconfig
asked me again if I wanted Y/n on ieee80211. Was it submitted, then
removed and then submitted back or it was because someone changed how
you select ieee80211 in the menuconfig?

THANKS!

.Alejandro

[Ieee80211-devel] Re: ieee80211 patches

[James K. <jke...@li...>]

Jeff Garzik wrote:

> It seems like some of this overlaps changes already in upstream. 
> What's the best way to start this process?  I would prefer to receive
> patches rather than 'git pull' at the present time.

Understood.

> Should I Lindent the files first?

Probably cleanest that way.  I've been passing the net/ieee80211/*.c and
include/net/ieee80211*.h files through the following script:

#!/usr/bin/env bash
scripts/Lindent $@
for file in $@; do
        sed -i -e "s:\ *\$::g" -e "s:\t*\$::g" $file;
done

I don't know if Lindent strips trailing whitespace, so I stuck the sed
in there for good measure.

> Would you rather just start sending those 50+ patches?

I can pull netdev-2.6#ieee80211 once you have a Lindent'd version and I
can then (hopefully) run my rebase scripts, weeding out dups, and can
then send the patches out.

Thanks,
James

[Ieee80211-devel] Re: ieee80211 patches

[Jeff G. <jg...@po...>]

James Ketrenos wrote:
> Jeff Garzik wrote:
> 
> 
>>Jiri Benc wrote:
>>
>>
>>>Our patches against latest ieee80211 branch can be found at
>>>http://kernel.org/pub/linux/kernel/people/jbenc/
>>
>>Thanks for your patience.
>>
>>To answer Pavel's question from the other email:
>>
>>I was hoping that Intel would resend their patches, rediffed to the
>>latest ieee80211 branch.  I didn't want to apply all these cleanups,
>>which would then force Intel to rediff _yet again_.
> 
> 
> When it rains it pours it seems... we finally had the time to split up
> the commit Jiri originally asked us to split up; in doing so we rebased
> the commit series against netdev-2.6#ieee80211 as of Aug 15th (commit
> 1b5cca3a88b7682d538d129c25f0e3092613a243)
> 
> When we rebased, the first commit was a run scripts/Lindent and trimmed
> all trailing whitespace on include/net/ieee80211*.h and
> net/ieee80211/*.c.  This makes the first patch in the series large, but
> it is purely a Lindent patch.  Running it as the first step in the
> rebase helped resolve any conflicts later (if you're interested in the
> 'clean-rebase' script it will apply non Lindent'd patches back into a
> Lindented tree without Lindent caused conflicts).
> 
> Anyway, our rebasing from ieee80211 up to the latest development tip is
> done across 29 commits, with a series size of 225k.
> 
> We have an updated GIT overlay of the rebased ieee80211 at
> rsync://bughost.org/repos/ieee80211-rebase/.git/.  If you just want to
> pull the objects/ tree, you can walk it via the commit
> 69b08411732dfc5a028ef19fc6c79b84302c4c30.  NOTE:  The GIT overlay
> referenced here is not a full archive.  It only contains the objects
> required to move from the parent (netdev-2.6#ieee80211) to the master. 
> Once pulled you can use many of the git commands, but others (like
> checkout) will likely fail.
> 
> We are willing to keep a ieee80211 GIT tree up to date w/ everyone's
> patches that you can just periodically pull from if you'd like.  We
> already have to maintain a separate tree anyway to enable updates and
> snapshots for the ipw2{1,2}00 project users.  This is partially what is
> causing us pain right now; any set of patches we apply may later end up
> being conflicts when we try and merge back with netdev -- which means
> the merge rarely occurs.  At the same time, we can't always wait for a
> patch to be incorporated into netdev-2.6#ieee80211 before we make it
> available to users.
> 
> Anyway, here is the shortlist of the changes we have for ieee80211,
> available from the above rsync location.
> 
> (As a side note, we're working on a similar set for the ipw2{1,2}00
> drivers that catch them up to being compatible with this version of
> ieee80211, etc.  That series is 52 patches, breaking in at just over 1M.)

It seems like some of this overlaps changes already in upstream.  What's 
the best way to start this process?  I would prefer to receive patches 
rather than 'git pull' at the present time.

Should I Lindent the files first?
Would you rather just start sending those 50+ patches?

	Jeff

[Ieee80211-devel] Re: ieee80211 patches

[Jiri B. <jb...@su...>]

On Thu, 01 Sep 2005 19:16:05 +0100, Pedro Ramalhais wrote:
> >  Of
> > course you may sometimes want to force reassociation manually - and
> > there should be some call available for this. (Maybe setting BSSID while
> > the card is running should force reassociation?)
> 
> That's the kind of hackish solution that brings confusion. We should
> separate things: wireless configuration and wireless association. This
> way you won't have to do those hackish approaches and special cases.
> What i mean is that if you want to associate, tell the card to do so,
> don't send -1 as the channel or send 0 as the essid_len, or resend the
> previously configured essid.

I probably didn't explain well what I thought, sorry. Imagine following
situation: we have an AP with BSSID1 and another one with BSSID2, both
in the same ESS. When you set just the ESSID, somebody (kernel or
daemon, I'm still not decided on this) tell the driver to associate to
one of the APs - e.g. to BSSID1. When conditions change, the driver is
told to reassociate (to BSSID2). And so on. When you manually set BSSID2
(while we are associated to BSSID1), it surely means that the user wants
to reassociate to BSSID2 - there is nothing hackish in that.

But you're right anyway.


-- 
Jiri Benc
SUSE Labs

[Ieee80211-devel] Re: ieee80211 patches

[Jiri B. <jb...@su...>]

On Mon, 05 Sep 2005 16:24:41 +0200, Henrik Brix Andersen wrote:
> Only a very early version of the ieee80211 header was included in
> 2.6.13. This header is not compatible with the ones needed to compile
> the current external drivers which depend on ieee80211. This makes it
> hard to properly support these external drivers for linux-2.6.13 for
> distributions such as Gentoo Linux. 

Also, this header (as well as the whole merged "ieee80211 stack") is
still ipw-specific. Very invasive changes are needed to turn it into
the generic one - so it will become even worse during the time.

> I'd rather have waited with the inclusion into mainline until the
> ieee80211 subsystem was more mature - but I guess that's another
> topic...

I definitely agree. But it probably can't be changed now, we have to
live with it.

Fortunately, the life is not much harder for external drivers developers
- they just have to stop to depend on in-kernel ieee80211 header and
provide its own. (Heh - isn't this something we tried to avoid?)

> I believe the Intel developers are working on a native IEEE 802.11
> wireless stack for the Linux kernel,

Intel developers don't seem to work on generic ieee80211 layer. They
have bunch of ipw-specific code together with some generic features
which they call "ieee80211 stack" and which they seem to be happy with.
Sure, recently they added some code - mostly the code needed by their
ipw drivers to support QoS and similar features.


-- 
Jiri Benc
SUSE Labs

Re: [Ieee80211-devel] eth0 vs. wlan0 [was Re: ieee80211 patches]

[Pavel M. <pa...@uc...>]

Hi!

> > Fact is, couple of thousands use IPW2200, therefore ethX. I don't want to
> > see all those users lost by the fact that something really cosmetic was
> > changed. Yes, wlan0 sounds more "organized" but we should just keep having
> > what we have seen all the time.
> 
> ipw2200 is not the only driver that will be using IEEE 802.11 net
> stack and many of the other drivers have not use ethX interface names..
> As has been mentioned number of times before when the question on
> interface names has come up on various mailing lists, the interface name
> can be renamed in user space (e.g., with ifrename) if someone feels
> really strongly on the having to be something else.

As I tried to explain, it is not only interface name. It is also stuff
like "does ifconfig show number of ethernet frames, or number of wifi
frames received?", and no, you can't change that using ifrename.

								Pavel
-- 
if you have sharp zaurus hardware you don't need... you know my address

Re: [Ieee80211-devel] eth0 vs. wlan0 [was Re: ieee80211 patches]

[Jiri B. <jb...@su...>]

On Mon, 5 Sep 2005 07:52:12 -0600, Alejandro Bonilla wrote:
> IMHO, We have already used ethX for all the time that this driver has been
> used. Therefore, most likely, if we change from eth1 to wlan0, we are going
> to mix up more people than we can mix new people.

ipw is not the only driver. There are also drivers for other cards that
will use ieee80211 layer when it is mature enough. Most of them use
wlan0 now. Should we mix up their users because of ipw?

> We had a long talk about this in the IPW ML and at the end we considered the
> wireless adapter an ethernet interface too, so we just sticked with ethX.

Although 802.11 and 802.3 are bridgeable, they are not the same and they
have slightly different needs. For example, you want to get management
frames by packet socket - this is not compatible with ethernet in any
way.


-- 
Jiri Benc
SUSE Labs

RE: [Ieee80211-devel] eth0 vs. wlan0 [was Re: ieee80211 patches]

[Alejandro B. <abo...@li...>]

> Alejandro Bonilla wrote:
> >>On Mon, 2005-09-05 at 12:09 -0600, Alejandro Bonilla wrote:
>
> This is largely an irrelevant discussion, since interface naming is
> policy.  We are merely talking about the default in-kernel policy.
> nameif(8) and other solutions can afford alternative policies.

OK, I don't see much in that man page, but OK. I guess that you can make a
policy to make wireless interfaces to now be wlanX. Then this would be
different as it then would be the kernel way? This was my point all the
time.

>
> FWIW I tend to prefer wlanX naming, since the end result of ieee80211
> work (a real protocol layer) will not be emulated ethernet.

Cool, I was always under the impression that at the end it was all over this
emulated ethernet. Now with ieee80211 is not. Good to know then. Thanks for
answering. I guess that now a naming policy can be changed to support the
Wlan interfaces.

.Alejandro

>
> 	Jeff
>
>

Re: [Ieee80211-devel] eth0 vs. wlan0 [was Re: ieee80211 patches]

[Jeff G. <jg...@po...>]

Alejandro Bonilla wrote:
>>On Mon, 2005-09-05 at 12:09 -0600, Alejandro Bonilla wrote:
>>
>>>Excellent. This way, users can change it to wlan0. After
>>
>>all, the most
>>
>>>common used name is ethX.
>>
>>While it is correct that ethX is the "most common name" for ethernet
>>interfaces, you seem to have missed the point:
>>
>>eth = ETHernet, IEEE 802.3
>>wlan = Wireless LAN, IEEE 802.11
> 
> AFAIK, all the code touches a lot of IEEE802.3.? You would know.
> 
> Anyway, let's not assume any name or make this from an opinion.
> 
> Is there a naming convention document that tells what HAS to be used?
> At least an email. From Linus? Jeff? Anyone who decides?
> 
> Else, using wlan0 is just making out stuff, even if others have already done
> it.

This is largely an irrelevant discussion, since interface naming is 
policy.  We are merely talking about the default in-kernel policy. 
nameif(8) and other solutions can afford alternative policies.

FWIW I tend to prefer wlanX naming, since the end result of ieee80211 
work (a real protocol layer) will not be emulated ethernet.

	Jeff

RE: [Ieee80211-devel] eth0 vs. wlan0 [was Re: ieee80211 patches]

[Alejandro B. <abo...@li...>]

> On Mon, 2005-09-05 at 12:09 -0600, Alejandro Bonilla wrote:
> > Excellent. This way, users can change it to wlan0. After
> all, the most
> > common used name is ethX.
>
> While it is correct that ethX is the "most common name" for ethernet
> interfaces, you seem to have missed the point:
>
> eth = ETHernet, IEEE 802.3
> wlan = Wireless LAN, IEEE 802.11
AFAIK, all the code touches a lot of IEEE802.3.? You would know.

Anyway, let's not assume any name or make this from an opinion.

Is there a naming convention document that tells what HAS to be used?
At least an email. From Linus? Jeff? Anyone who decides?

Else, using wlan0 is just making out stuff, even if others have already done
it.

.Alejandro

>
> A wireless LAN interface is not an ethernet interface.
>
> ./Brix

RE: [Ieee80211-devel] eth0 vs. wlan0 [was Re: ieee80211 patches]

[Henrik B. A. <br...@ge...>]

On Mon, 2005-09-05 at 12:09 -0600, Alejandro Bonilla wrote:
> Excellent. This way, users can change it to wlan0. After all, the most
> common used name is ethX.

While it is correct that ethX is the "most common name" for ethernet
interfaces, you seem to have missed the point:

eth =3D ETHernet, IEEE 802.3
wlan =3D Wireless LAN, IEEE 802.11

A wireless LAN interface is not an ethernet interface.

./Brix

--=20
Henrik Brix Andersen <br...@ge...>
Gentoo Metadistribution | Mobile computing herd

RE: [Ieee80211-devel] eth0 vs. wlan0 [was Re: ieee80211 patches]

[Alejandro B. <abo...@li...>]

> can be renamed in user space (e.g., with ifrename) if someone feels
> really strongly on the having to be something else.

Excellent. This way, users can change it to wlan0. After all, the most
common used name is ethX.

.Alejandro

>
> --
> Jouni Malinen                                            PGP
> id EFC895FA

Re: [Ieee80211-devel] eth0 vs. wlan0 [was Re: ieee80211 patches]

[Jouni M. <jkm...@cc...>]

On Mon, Sep 05, 2005 at 11:26:29AM -0600, Alejandro Bonilla wrote:

> Fact is, couple of thousands use IPW2200, therefore ethX. I don't want to
> see all those users lost by the fact that something really cosmetic was
> changed. Yes, wlan0 sounds more "organized" but we should just keep having
> what we have seen all the time.

ipw2200 is not the only driver that will be using IEEE 802.11 net
stack and many of the other drivers have not use ethX interface names..
As has been mentioned number of times before when the question on
interface names has come up on various mailing lists, the interface name
can be renamed in user space (e.g., with ifrename) if someone feels
really strongly on the having to be something else.

-- 
Jouni Malinen                                            PGP id EFC895FA

RE: [Ieee80211-devel] eth0 vs. wlan0 [was Re: ieee80211 patches]

[Alejandro B. <abo...@li...>]

> > Unfortunately, if it stays pretending it is ethernet
> adapter, there's
> > no way to see wireless managment packets with wlan... that seems
> > wrong.
> Theres a certian amount of user confusion by not making the wireless
> interfaces blatantly wireless, but it doesn't hurt
> functionality at all.

Fact is, couple of thousands use IPW2200, therefore ethX. I don't want to
see all those users lost by the fact that something really cosmetic was
changed. Yes, wlan0 sounds more "organized" but we should just keep having
what we have seen all the time.

+complains and questions about it in the ML's.

.Alejandro

>
> -m
>
>
>

Re: [Ieee80211-devel] eth0 vs. wlan0 [was Re: ieee80211 patches]

[Mike K. <dr...@ki...>]

> Unfortunately, if it stays pretending it is ethernet adapter, there's
> no way to see wireless managment packets with wlan... that seems
> wrong.

This isn't true at all.  There are numerous drivers which use ethX and
can still be used to sniff management frames (such as the ipw drivers,
the orinoco drivers, etc). =20

Every device has an arp link type that indicates what sort of frames=20
are on it, such as IEEE raw, IEEE-PRISM/AVS, Radiotap, blah blah blah.
This is handled exactly the same if its call ethX, wlanX, athX, it
doesn't matter.

Theres a certian amount of user confusion by not making the wireless
interfaces blatantly wireless, but it doesn't hurt functionality at all.

-m

--=20
Mike Kershaw/Dragorn <dr...@ki...>
GPG Fingerprint: 3546 89DF 3C9D ED80 3381  A661 D7B2 8822 738B BDB1

Some people call them "cars" or "trucks"; I call them "dimensional
transmogrifiers" because they change three-dimensional cats into
two-dimensional ones.
                -- F. Frederick Skitty

[Ieee80211-devel] Re: eth0 vs. wlan0 [was Re: ieee80211 patches]

[Jeff G. <jg...@po...>]

Pavel Machek wrote:
> Hi!
> 
> I noticed that wireless patches are now in the mainline. That is good,
> patches are getting smaller, but it is going to make future user
> interface changes harder; and thats very bad.
> 
> There are good reasons to have wireless interfaces as wlanX, with
> tcpdump showing wireless packetes, etc; but current patches name it
> ethX, and you get plain ethernet packets on tcpdump. Are we going to
> keep showing wireless interfaces as ethernet ones forever, or do we
> plan to switch to wlanX? If we decide to switch, we should either
> switch before 2.6.14, or disable wireless before 2.6.14 so that we do
> not confuse users too badly...


We will continue to develop ieee80211 in the mainline kernel.  2.6.14 is 
not some magic barrier that prevents major changes.

	Jeff

Re: [Ieee80211-devel] eth0 vs. wlan0 [was Re: ieee80211 patches]

[Henrik B. A. <br...@ge...>]

On Mon, 2005-09-05 at 15:37 +0200, Pavel Machek wrote:
> I noticed that wireless patches are now in the mainline. That is good,
> patches are getting smaller, but it is going to make future user
> interface changes harder; and thats very bad.

Only a very early version of the ieee80211 header was included in
2.6.13. This header is not compatible with the ones needed to compile
the current external drivers which depend on ieee80211. This makes it
hard to properly support these external drivers for linux-2.6.13 for
distributions such as Gentoo Linux.=20

I'd rather have waited with the inclusion into mainline until the
ieee80211 subsystem was more mature - but I guess that's another
topic...

> There are good reasons to have wireless interfaces as wlanX, with
> tcpdump showing wireless packetes, etc; but current patches name it
> ethX, and you get plain ethernet packets on tcpdump. Are we going to
> keep showing wireless interfaces as ethernet ones forever, or do we
> plan to switch to wlanX? If we decide to switch, we should either
> switch before 2.6.14, or disable wireless before 2.6.14 so that we do
> not confuse users too badly...

I believe the Intel developers are working on a native IEEE 802.11
wireless stack for the Linux kernel, which will (should?) also change
the naming scheme of the interfaces from ethX to wlanX. As it is now,
the ieee80211 subsystem is just an "add-on" to the ethernet stack, and
interfaces are thus correctly (imho) named ethX.

I am in favor of switching to the new naming scheme once the native
stack is a reality, and I therefore also think we should have the
immature version of the ieee80211 subsystem removed before linux-2.6.14
to avoid confusion - not only among end-users, but also among wireless
developers.

Currently (as of linux-2.6.13) the only in-kernel driver relying on the
in-kernel ieee80211 header is the orinoco driver, which can easily be
modified not to.

Sincerely,
Brix=20
--=20
Henrik Brix Andersen <br...@ge...>
Gentoo Metadistribution | Mobile computing herd

Re: [Ieee80211-devel] eth0 vs. wlan0 [was Re: ieee80211 patches]

[Pavel M. <pa...@su...>]

Hi!

> > There are good reasons to have wireless interfaces as wlanX, with
> > tcpdump showing wireless packetes, etc; but current patches name it
> > ethX, and you get plain ethernet packets on tcpdump. Are we going to
> > keep showing wireless interfaces as ethernet ones forever, or do we
> > plan to switch to wlanX? If we decide to switch, we should either
> 
> IMHO, We have already used ethX for all the time that this driver has been
> used. Therefore, most likely, if we change from eth1 to wlan0, we are going
> to mix up more people than we can mix new people.
> 
> We had a long talk about this in the IPW ML and at the end we considered the
> wireless adapter an ethernet interface too, so we just sticked with ethX.
> 
> I hope it stays as ethX.

Unfortunately, if it stays pretending it is ethernet adapter, there's
no way to see wireless managment packets with wlan... that seems
wrong.
								Pavel
-- 
if you have sharp zaurus hardware you don't need... you know my address

RE: [Ieee80211-devel] eth0 vs. wlan0 [was Re: ieee80211 patches]

[Alejandro B. <abo...@li...>]

> Hi!
>
> I noticed that wireless patches are now in the mainline. That is good,
> patches are getting smaller, but it is going to make future user
> interface changes harder; and thats very bad.
Hi,

I'm also happy that these are in mainline now.

>
> There are good reasons to have wireless interfaces as wlanX, with
> tcpdump showing wireless packetes, etc; but current patches name it
> ethX, and you get plain ethernet packets on tcpdump. Are we going to
> keep showing wireless interfaces as ethernet ones forever, or do we
> plan to switch to wlanX? If we decide to switch, we should either

IMHO, We have already used ethX for all the time that this driver has been
used. Therefore, most likely, if we change from eth1 to wlan0, we are going
to mix up more people than we can mix new people.

We had a long talk about this in the IPW ML and at the end we considered the
wireless adapter an ethernet interface too, so we just sticked with ethX.

I hope it stays as ethX.

.Alejandro

> switch before 2.6.14, or disable wireless before 2.6.14 so that we do
> not confuse users too badly...
> 								Pavel

[Ieee80211-devel] eth0 vs. wlan0 [was Re: ieee80211 patches]

[Pavel M. <pa...@su...>]

Hi!

I noticed that wireless patches are now in the mainline. That is good,
patches are getting smaller, but it is going to make future user
interface changes harder; and thats very bad.

There are good reasons to have wireless interfaces as wlanX, with
tcpdump showing wireless packetes, etc; but current patches name it
ethX, and you get plain ethernet packets on tcpdump. Are we going to
keep showing wireless interfaces as ethernet ones forever, or do we
plan to switch to wlanX? If we decide to switch, we should either
switch before 2.6.14, or disable wireless before 2.6.14 so that we do
not confuse users too badly...
								Pavel
-- 
if you have sharp zaurus hardware you don't need... you know my address

[Ieee80211-devel] Re: ieee80211 patches

[Ingo O. <ne...@ax...>]

Hi,

Pedro Ramalhais wrote:
> Yes, i might want to bring the card UP so that it can scan, but don't
> want to associate. Or bring the card UP and configure the card in
> Monitor mode. Or bring the card UP and configure the card in Master
> mode. Maybe ad-hoc too, not sure.

Yes, that sounds useful. Bringing an interface UP means 
"I want a physical layer connection" in the network layer.

If a card is UP I can do the follwing:

- Passively listening on the medium (scanning traffic)
- Checking for physical layer problems
  (e.g. signal levels, bandwith, duplex)
- Being detected by NICs on the same network segment


By bringing an interface DOWN, I administrativly FORBID this all.
By bringing it UP, I adminstrativly ALLOW this all.

This is what the admin expect "ip set link up/down" to do, nothing more, 
nothing less. "ifconfig" can do more, but this is for historical reasons
and no useful example for an interface.

If you could map all this somehow to a WLAN, you are on the right way.
Everything beyond this can be done later or before.

Maybe that helps you for developing useful admin interface.


Regards

Ingo Oeser

[Ieee80211-devel] Re: ieee80211 patches

[Pedro R. <ram...@se...>]

On Thu, 2005-09-01 at 16:48 +0200, Jiri Benc wrote:
> On Thu, 01 Sep 2005 11:09:16 +0100, Pedro Ramalhais wrote:
> > The scheme looks good to me. Wireless cards mostly map to a regular
> > network card. Only difference is that you need to do something to
> > configure the link to have "carrier detected" and DHCP should only be
> > started after "carrier detected" (IFF_RUNNING IIRC).
> 
> The fact that DHCP should be only started when carrier is detected is
> not wireless-specific.
> 

Sorry, english is not my natural laguange. I was just stating the
obvious. Not related to the diference i was talking about.

> > Regarding association only on explicit userspace request, that's fixable
> > in the drivers (some drivers automatically associate once they're
> > ifconfig'ed up, the ipw2x00 drivers have a module parameter to change
> > this behaviour).
> 
> ipw drivers are broken in this manner as they try to associate right
> after modprobe. No card should do anything unless it is explicitly told
> so - policy is the matter of user-space, not the kernel. Startup scripts
> in distributions are the right place for instructing a card to
> associate.

scripts, daemons, apps, whatever the distro/user wants to use.

> 
> Sure, this is fixable in drivers. And it really needs to be fixed. Even
> more, I think it should be forced by ieee80211 layer.
> 

You mean something like not allowing the driver to send an event
association through the ieee80211 layer or accept traffic until the
layer is configured correctly? That would probably work.

> > > And yes, this brings up the problem with firmware loading. It should
> > > really be solved, but trying to solve it by requiring to bring the card
> > > up before it is configured is the bad way.
> > 
> > Why is it the "wrong way"? I don't see a big problem with this, the card
> > is only going to be used after it's UP. The only problem i see is that
> > it doesn't behave exactly like most network drivers, where they are able
> > to detect a link even when they're DOWN. Is there a good reason for a
> > card to do anything even when it's DOWN?
> 
> You seem to agree with me :-) A card in DOWN state should do nothing. In
> particular, it shouldn't associate.
> 

At least i don't see any reason why it should do anything. If someone
knows of something that could be useful during the DOWN state i'd like
to hear it.

> But it should be configurable. And it is really necessary that we can
> tell a card that we are done with configuration so it can associate. The
> easiest place for doing this is bringing the card to UP state.
> 

I fail to see why configuration needs to be done in the ifconfig up
stage.

I tend to think of a wireless card as a normal ethernet network device.
And you can map one to the other easily.
In the case of a normal network card, link state means the state of the
path between the card and another equipment (a switch or another card
with a crossover cable) and successful ethernet negotiation.
In the case of a wireless card, it means the successful association with
an access point, ad-hoc network (always link up?) or master mode (always
link up?).
There are user configurable things in both cards regarding the link: in
network cards you have the cable, in wireless cards you have wireless
association configuration AND policy.
After saying that, think about this: in a network card you can ifconfig
the card UP and connect the cable later (bringging the link up), so you
should be able to do the same thing with a wireless card: ifconfig up
and then configure the card so that it establishes a link.

> > Right, that would need a new interface where all parameters are passed
> > at once,
> 
> Then you will lose the possibility of having default parameters.
> 

Not really, there can be default parameters like channel=0 or -1,
essid_len=-1, AP bssid=00:00:00:00:00:00 or FF:FF:FF:FF:FF:FF, etc... or
a bitfield with flags for each parameter being set. The bitfield would
be nice so that you wouldn't need to pass all the parameters (even the
default ones) like the radiotap headers.

> > or keep the existing interface and add another just to
> > explicitly associate.
> 
> Is there any reason not to do this by bringing the card up ("ifconfig up")?

Yes, i might want to bring the card UP so that it can scan, but don't
want to associate. Or bring the card UP and configure the card in
Monitor mode. Or bring the card UP and configure the card in Master
mode. Maybe ad-hoc too, not sure.

> 
> > Besides that, there should also be a way to configure if you want to
> > auto-associate to new access points if the old access point becomes
> > unavailable or with a weaker signal than the new one, or if you want to
> > manually associate, ex: association is done once and never tried again
> > until you tell it to do so. The manual association would be a good thing
> > for a wireless managed, where it would have the work of handling new
> > networks, APs becoming unavailable and available again, etc.
> 
> Yes. If the new AP is in the same ESS, that should be done automatically
> (if not explicitly disabled e.g. by setting of explicit BSSID).


>  Of
> course you may sometimes want to force reassociation manually - and
> there should be some call available for this. (Maybe setting BSSID while
> the card is running should force reassociation?)

That's the kind of hackish solution that brings confusion. We should
separate things: wireless configuration and wireless association. This
way you won't have to do those hackish approaches and special cases.
What i mean is that if you want to associate, tell the card to do so,
don't send -1 as the channel or send 0 as the essid_len, or resend the
previously configured essid.

> 
> If you want to change SSID (i.e. associate to a completely new network)
> I can imagine that you will be forced to bring the card down, change
> settings and bring it up again (but I don't insist on it as it is not
> necessary - bringing the card down and up again can be done internally
> by ieee80211 layer in such case).
> 
> 

I would prefer: set the ESSID and then tell the card to associate again.
EX:
iwconfig eth0 essid  NEWESSID
# oooops, wrong ESSID
iwconfig eth0 essid NEWESSID2
iwconfig eth0 associate

And it could also be possible to do it all at once:
iwconfig eth0 essid NEWESSID3 channel 11 bssid 11:22:33:44:55:66
associate

Maybe you could configure it with the default association policy you
want with the new association:
iwconfig eth0 associate auto
This would automatically select the best AP continuosly between APs
compatible with the active configuration (same bssid, better signal
strength, etc..). I'm not sure that this is good to have in the kernel,
i've seen ideas to have a daemon that complements the kernel iee80211
stack similar to hostapd, maybe it would be better to be there in
userspace.
or:
iwconfig eth0 associate manual
which would be useful for using userspace daemons/apps to manage
associations and association policy.


Just ideas...
-- 
Pedro Ramalhais <ram...@se...>

[Ieee80211-devel] Re: ieee80211 patches

[Jiri B. <jb...@su...>]

On Thu, 01 Sep 2005 11:09:16 +0100, Pedro Ramalhais wrote:
> The scheme looks good to me. Wireless cards mostly map to a regular
> network card. Only difference is that you need to do something to
> configure the link to have "carrier detected" and DHCP should only be
> started after "carrier detected" (IFF_RUNNING IIRC).

The fact that DHCP should be only started when carrier is detected is
not wireless-specific.

> Regarding association only on explicit userspace request, that's fixable
> in the drivers (some drivers automatically associate once they're
> ifconfig'ed up, the ipw2x00 drivers have a module parameter to change
> this behaviour).

ipw drivers are broken in this manner as they try to associate right
after modprobe. No card should do anything unless it is explicitly told
so - policy is the matter of user-space, not the kernel. Startup scripts
in distributions are the right place for instructing a card to
associate.

Sure, this is fixable in drivers. And it really needs to be fixed. Even
more, I think it should be forced by ieee80211 layer.

> > And yes, this brings up the problem with firmware loading. It should
> > really be solved, but trying to solve it by requiring to bring the card
> > up before it is configured is the bad way.
> 
> Why is it the "wrong way"? I don't see a big problem with this, the card
> is only going to be used after it's UP. The only problem i see is that
> it doesn't behave exactly like most network drivers, where they are able
> to detect a link even when they're DOWN. Is there a good reason for a
> card to do anything even when it's DOWN?

You seem to agree with me :-) A card in DOWN state should do nothing. In
particular, it shouldn't associate.

But it should be configurable. And it is really necessary that we can
tell a card that we are done with configuration so it can associate. The
easiest place for doing this is bringing the card to UP state.

> Right, that would need a new interface where all parameters are passed
> at once,

Then you will lose the possibility of having default parameters.

> or keep the existing interface and add another just to
> explicitly associate.

Is there any reason not to do this by bringing the card up ("ifconfig up")?

> Besides that, there should also be a way to configure if you want to
> auto-associate to new access points if the old access point becomes
> unavailable or with a weaker signal than the new one, or if you want to
> manually associate, ex: association is done once and never tried again
> until you tell it to do so. The manual association would be a good thing
> for a wireless managed, where it would have the work of handling new
> networks, APs becoming unavailable and available again, etc.

Yes. If the new AP is in the same ESS, that should be done automatically
(if not explicitly disabled e.g. by setting of explicit BSSID). Of
course you may sometimes want to force reassociation manually - and
there should be some call available for this. (Maybe setting BSSID while
the card is running should force reassociation?)

If you want to change SSID (i.e. associate to a completely new network)
I can imagine that you will be forced to bring the card down, change
settings and bring it up again (but I don't insist on it as it is not
necessary - bringing the card down and up again can be done internally
by ieee80211 layer in such case).


-- 
Jiri Benc
SUSE Labs

[Ieee80211-devel] Re: ieee80211 patches

[Jiri B. <jb...@su...>]

On Wed, 31 Aug 2005 17:06:19 -0400, Peter Jones wrote:
> Not necessarily started "by hotplug", but started by something like
> ifplugd or NetworkManager.  And that class of programs is already
> responsible for things like choosing what AP to associate, so it's an
> extra degree of control for them, but not really a hastle for end users,
> who shouldn't have to run "ifconfig up" or anything else 99% of the
> time.

I apologize if I misunderstood you.

We're actually not talking about ifconfig. By "ifconfig up" there is in
this thread almost always meant setting IFF_UP flag regardless of
actually used program. So "that class of programs" is exactly what we're
talking about. And it's not about an extra degree of control, it's about
the right way to do this (i.e. no side effects, no unwanted
associations, etc.).

> You also don't want to "ifconfig down" when you're hopping from AP to AP
> with the same ESSID -- you generally want to tell it to reassociate with
> the other AP, but leave the connection up the entire time.

Sure. And not even that, you want the ieee80211 layer to do this
automatically (based on signal strength) if it is told so.


-- 
Jiri Benc
SUSE Labs