* Re: wireless: recap of current issues (stack)
From: Ulrich Kunitz @ 2006-01-15 10:04 UTC (permalink / raw)
To: Pete Zaitcev; +Cc: Ulrich Kunitz, linville, netdev, linux-kernel, dsd
In-Reply-To: <20060114204211.72942d45.zaitcev@redhat.com>
On Sat, 14 Jan 2006, Pete Zaitcev wrote:
> On Sat, 14 Jan 2006 15:13:39 +0100 (CET), Ulrich Kunitz <kune@deine-taler.de> 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 in atomic mode, which is only true
> > for buses that support memory-mapping.
>
> If this problem is real, then it's serious. However, I'm not seeing it
> with prism54usb and Berg's softmac (yet?). Would you be so kind to provide
> the file name and function name for the code which makes these assumptions?
>
> Thanks,
> -- Pete
>
Pete,
I've been wrong.
I couldn't find the problem in the latest version of the
ieee80211softmac. Thank you for noticing me.
Uli
--
Ulrich Kunitz - kune@deine-taler.de
^ permalink raw reply
* Re: [PATCH] ACX: swap netdevice_t for struct net_device
From: Denis Vlasenko @ 2006-01-15 11:06 UTC (permalink / raw)
To: acx100-devel; +Cc: Carlos Martín, netdev
In-Reply-To: <200601150043.34890.carlos@cmartin.tk>
On Sunday 15 January 2006 01:43, Carlos Martín wrote:
> Hi,
>
> Does netdevice_t serve any actual purpose now? It used to be for 2.2/2.4
> compatibility, but we don't have that anymore.
>
> Attached patch does a s/netdevice_t/struct net_device/g on all the files that
> required it. It's against 20060114
Too late :)
acx-20060115 already has no netdevice_t.
--
vda
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id\x16865&op=click
^ permalink raw reply
* Re: wireless: recap of current issues (other issues)
From: Arnaldo Carvalho de Melo @ 2006-01-15 11:23 UTC (permalink / raw)
To: David S. Miller; +Cc: jgarzik, linville, netdev, linux-kernel
In-Reply-To: <20060114.175140.07007614.davem@davemloft.net>
On 1/14/06, David S. Miller <davem@davemloft.net> wrote:
> From: Jeff Garzik <jgarzik@pobox.com>
> 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-802.11 code to make it aware of a new frame class.
>
> The former, most importantly, can cause the packet to get copied.
> Actually, this depends upon how you implement things and when the
> header change occurs.
>
> My vote is for making the whole of the networking 802.11 frame class
> aware.
Agreed :-)
- Arnaldo
^ permalink raw reply
* acxsm: migrate acx from homegrown 802.11 handling to softmac stack
From: Denis Vlasenko @ 2006-01-15 11:52 UTC (permalink / raw)
To: netdev, softmac-dev, acx100-devel
Hi,
http://195.66.192.167/linux/acx_patches/acxsm-20060115.tar.bz2
README says:
==================
*** Not run tested. Almost certainly won't work. Lots of things are TODO. ***
This tarball contains a port of acx driver to ieee80211softmac
stack. Broadcom 43xx driver was used as an example.
See http://bcm43xx.berlios.de/,
ftp://ftp.berlios.de/pub/bcm43xx/snapshots/
Latest softmac source is in softmac-snapshot/ and net/
is a symling to softmac-snapshot/include/net/.
softmac-snapshot/ is to be replaced regularly with newer
snapshots from http://softmac.sipsolutions.net/SoftMAC.
grep for '//SM' to see the code added to standalone acx driver code.
...
...
===================
This is it.
P.S. It does not mean that acx driver is discontinued.
It will be supported as before. Let's see whether acxsm
will get any traction at all.
--
vda
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
^ permalink raw reply
* Re: [PATCH] ACX: swap netdevice_t for struct net_device
From: Carlos Martín @ 2006-01-15 11:54 UTC (permalink / raw)
To: Denis Vlasenko; +Cc: acx100-devel, netdev
In-Reply-To: <200601151306.57824.vda@ilport.com.ua>
On Sunday 15 January 2006 12:06, Denis Vlasenko wrote:
> On Sunday 15 January 2006 01:43, Carlos Martín wrote:
> > Attached patch does a s/netdevice_t/struct net_device/g on all the files
that
> > required it. It's against 20060114
>
> Too late :)
> acx-20060115 already has no netdevice_t.
Can you read my mind? :) I see you also got rid of wlandevice_t, nice.
cmn
--
Carlos Martín http://www.cmartin.tk
"Erdbeben? Sicherlich etwas, das mit Erdberen zu tun hat." -- me, paraphrased
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id\x16865&op=click
^ permalink raw reply
* Re: wireless: recap of current issues (configuration)
From: Stefan Rompf @ 2006-01-15 12:40 UTC (permalink / raw)
To: Johannes Berg; +Cc: netdev, linux-kernel
In-Reply-To: <1137191522.2520.63.camel@localhost>
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 thinking is that
> different virtual types have different structures associated, so
> changing it needs re-creating structures anyway. And different virtual
> device types might even be provided by different kernel modules so you
> don't carry around AP mode if you don't need it.
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 it and virtual interfaces are
limited to one channel anyway. These users rightfully expect to have one
interface and be able to do all configurations on it.
Stefan
^ permalink raw reply
* Re: [RFC: 2.6 patch] remove drivers/net/eepro100.c
From: Vitaly Bordug @ 2006-01-15 13:19 UTC (permalink / raw)
To: Adrian Bunk; +Cc: jgarzik, saw, linux-kernel, netdev
In-Reply-To: <20060105181826.GD12313@stusta.de>
On Thu, 5 Jan 2006 19:18:26 +0100
Adrian Bunk <bunk@stusta.de> wrote:
> This patch removes the obsolete drivers/net/eepro100.c driver.
>
> Is there any known problem in e100 still preventing us from removing
> this driver (it seems noone was able anymore to verify the ARM problem)?
>
I think I am recalling some problems on ppc82xx, when e100 was stuck on startup,
and eepro100 worked just fine.
Even if the patch below will be scheduled for application, we need to set up enough time
for approval that e100 will be fine for all the up-to-date hw; or it should be fixed/updated before eepro100 removal.
>
> Signed-off-by: Adrian Bunk <bunk@stusta.de>
>
>
--
Sincerely,
Vitaly
^ permalink raw reply
* Re: wireless: recap of current issues (configuration)
From: Stuffed Crust @ 2006-01-15 15:20 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Johannes Berg, netdev, linux-kernel
In-Reply-To: <43C97605.9030907@pobox.com>
[-- Attachment #1: Type: text/plain, Size: 5054 bytes --]
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_frequency(hw, 2412).
>
> For completely programmable hardware, the stack should interact with a
> module like ieee80211_geo, to help ensure the hardware stays within
> legal limits.
While there is much to debate about where to draw the functionality
line, completely programmable hardware is the norm these days.
... and said code would be responsible for driving the scanning state
machines, and also for more esoteric functions like handling RADAR
traps, automatic channel switching, etc.
Handling scans is quite interesting -- I've seen hardware which requires
manual channel changing (including full RF parameter specification),
host timing for the channel dwell time, and manual probe request
issuance.. and on the other end of the spectrum, a simple "issue scan"
command that takes few, if any, parameters.
And unfortunately, many things in between.
This leads me to belive that the internal scan workflow should work
something like this:
* Userspace app issues scan request (aka "refresh AP list")
* Knowing the hardware frequency capabilities, the 802.11 stack applies
802.11d and regdomain rules to the available frequency set, and
issues multiple internal "scan request" commands to the hardware
driver. (eg "perform an initial passive sweep across the entire
2.4G band", "perform an active scan on frequencies 2412->2437
looking for ssid "HandTossed", "perform an active scan on
frequencies 5200-5400 looking for ssid "HandTossed", etc)
(note that ideally, userspace apps/libs would be at least partially
aware of 802.11d rules, but the kernel must do the RightThing if
told to "scan all available channels for any access points")
* The hardware driver takes this scan request, and maps it into the
capabilities of the hardware:
Hardware A: (very thin MAC)
- Using library code, generates an appropriate probe request frame,
translates it into a format the hardware expects/needs,
and schedules it appropriately.
- Loops through the frequency set specified, and for each:
- Issues a channel change command
- Immediately transmits the probe request (for active scans)
- Dwells for an appropriate time
- RX'ed beacon/probe response frames come down as regular 802.11
frames into the stack
- Moves to the next channel
Hardware B: (thinner MAC)
- Using library code, generates an appropriate probe request frame,
and translate it into a format the hardware expects.
- Program the probe request frame into the hardware as a probe
template.
- Loops through the frequency set specified, and for each:
- Issues a channel change command
- Wait for a scan complete signal
- RX'ed beacon/probe response frames come down as regular 802.11
frames into the stack
- Moves to the next channel
Hardware C: (thick MAC, ala prism2 or prism54)
- Issues a hardware "scan request"
- Waits for the hardware to signal "scan complete"
- Requests hardware scan results
- For each scan result, the hardware returns:
- Translate result into an 802.11 probe response frame and
pass down the regular RX path.
So as you can see, I think the channel iteration, dwell, etc should
be performed by the hardware driver itself, as the variation at the
logical "tell the hardware perform a scan" step is so extreme.
* Meanwhile, the 802.11 stack is receiving the beacons/probe responses
from the hardware via the regular rx path. It diverts these (and
other 802.11 management/control) frames, decodes them, and then adds
them to the stack's internal list of available stations, updating any
internal states/counters as necessary. (These frames could also be
echoed to a special netdev interface if desired)
(stuff like detecting an AP going away depends on us noticing a lack
of beacons arriving, for example. Most hardware does not
notify us of this event. Likewise, we should expire other
APs from our list if they go away.. etc. For AP operation we need
to maintain this STA list, period -- so why not use it across the
board? But this is another discussion for another time..)
* The 802.11 stack issues a MLME-Scan-Complete notification to
userspace.
* Interested userspace apps see this event, then query the
scan results and presents them to the user in some pretty format, or
alternatively perform automatic roaming based on scan results.
- Solomon
--
Solomon Peachy ICQ: 1318344
Melbourne, FL
Quidquid latine dictum sit, altum viditur.
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: wireless: recap of current issues (other issues)
From: Stuffed Crust @ 2006-01-15 15:39 UTC (permalink / raw)
To: Jeff Garzik; +Cc: John W. Linville, netdev, linux-kernel
In-Reply-To: <43C97693.7000109@pobox.com>
[-- Attachment #1: Type: text/plain, Size: 1828 bytes --]
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 make it aware of a new frame class.
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 for a bit of efficiency. (and then, just to be
contrary, the prism54 hardware actually requires 802.3 frames!)
That said.. we need to make the rest of the stack 802.11-aware.
Translating between 802.11 and 802.3 is trivial, as we only need to know
about a few operating parameters in order to perform the conversion --
AP/STA mode, BSSID, QoS parametsrs. WDS link parameters. All of these
can be attached to the net_device to be used by the hard_header code.
(Part of the problem is that 802.11 has a variable-length header - 24,
26, 30, or 32 bytes, and each address field means different things
depending on which mode we're using..)
Meanwhile, A current "good enough for most" solution is to make all
"data" interfaces to the 802.11 stack appear as 802.3 interfaces. Each
of these net_devices could translate to/from 802.11 on the fly. Thus
internally the stack would be pure 802.11, but interacting with the
outside world would depend on the "mode" of the net_device. You want
to tx/rx 802.11 management frames with QoS enabled? Create a "type
802_11_a3_qos" inteface.
- Solomon
--
Solomon Peachy ICQ: 1318344
Melbourne, FL
Quidquid latine dictum sit, altum viditur.
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: wireless: recap of current issues (configuration)
From: Johannes Berg @ 2006-01-15 15:51 UTC (permalink / raw)
To: Stefan Rompf; +Cc: netdev, linux-kernel
In-Reply-To: <200601151340.10730.stefan@loplof.de>
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 it and virtual interfaces are
> limited to one channel anyway. These users rightfully expect to have one
> interface and be able to do all configurations on it.
Isn't that rather a question of having good user-space tools that make
deactivating one type of interface and activating another seamless?
johannes
^ permalink raw reply
* Re: wireless: recap of current issues (configuration)
From: Stuffed Crust @ 2006-01-15 16:18 UTC (permalink / raw)
To: Dan Williams; +Cc: John W. Linville, netdev, linux-kernel
In-Reply-To: <1137282117.27849.11.camel@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 1748 bytes --]
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. Similar to the IWRANGE ioctl that there is now. Half
> the problem now is that you can't reliably tell what drivers support
> which features, or how much they support a particular feature.
This is an absolute requirement, especially when talking about
encryption.
You'd need, for example:
CAP_WEP_64
CAP_WEP_128
CAP_WEP_256 (non-standard, but often supported)
CAP_TKIP
CAP_MICHAELMIC
CAP_AES_CCMP
Then, to make things more complicated:
CAP_KEYMAPPING (can the hardware do keymapping?)
CAP_CAN_DISABLE_HWCRYPT (so if the hardware can't do TKIP, can we
perform it on the host?)
And to make things even more complicated, I've seen hardware that
supports disabling of hardware crypto, but not toggling it on the fly,
thanks to never-fixed hardware bugs. (you have to perform a full
reset/firmware load cycle. this means you end up disabling host crypto
altogether, at least if any of the networks you want to support include
CCMP...
Other quirks -- hardware that requires host MICHAEL on transmits, but
handles it on reception, unless if the received frames are fragmented.
Other hardware that does keymapping on rx frames, but for transmits
takes the raw keydata in the tx descriptor. (but still requires host
MICHAEL)
The list goes on and on..
- Solomon
--
Solomon Peachy ICQ: 1318344
Melbourne, FL
Quidquid latine dictum sit, altum viditur.
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: wireless: recap of current issues (configuration)
From: Stefan Rompf @ 2006-01-15 17:53 UTC (permalink / raw)
To: Johannes Berg; +Cc: netdev, linux-kernel
In-Reply-To: <56187.84.135.205.30.1137340292.squirrel@secure.sipsolutions.net>
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 actions. IPv4 addresses and routes are removed, same for
IPv6, IPX, Appletalk etc. Stacked VLAN devices are recursively unregistered
(even though I have not tried yet if it works when I create VLANs over 802.3
emulated wlan interfaces ;-), udev bloat runs. And all this stuff has to be
restored by the nifty new configuration utility, possibly including ifindex
and future protocols.
This is from my usage pattern that I want to go into monitor mode on current
channel, look at some packets and return to the association without losing
layer 3 configuration.
So after all, it is IMHO way less painful to handle a mode change in the
kernel.
Stefan
^ permalink raw reply
* Re: acxsm: migrate acx from homegrown 802.11 handling to softmac stack
From: Carlos Martín @ 2006-01-15 18:29 UTC (permalink / raw)
To: Denis Vlasenko; +Cc: netdev, softmac-dev, acx100-devel
In-Reply-To: <200601151352.44548.vda@ilport.com.ua>
On Sunday 15 January 2006 12:52, Denis Vlasenko wrote:
> Hi,
>
> http://195.66.192.167/linux/acx_patches/acxsm-20060115.tar.bz2
I've mirrored it at http://www.cmartin.tk/acx/ and will sync as with the
'normal' tarballs.
>
> README says:
> ==================
> *** Not run tested. Almost certainly won't work. Lots of things are TODO.
I'll try to try it out this week. Unfortunately, my USB device is broken
again.
> P.S. It does not mean that acx driver is discontinued.
> It will be supported as before. Let's see whether acxsm
> will get any traction at all.
at^^^^^^^^
You mean it won't slip when the road is wet? :P
This should make certain things easier to handle, won't it? From what I've
seen you don't have to worry about fragmentation of packets. Will the stack
also handle TKPI/WPA?
cmn
--
Carlos Martín http://www.cmartin.tk
"Erdbeben? Sicherlich etwas, das mit Erdberen zu tun hat." -- me, paraphrased
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id\x16865&op=click
^ permalink raw reply
* Re: wireless: recap of current issues (configuration)
From: Samuel Ortiz @ 2006-01-15 19:05 UTC (permalink / raw)
To: ext Stuffed Crust; +Cc: Jeff Garzik, Johannes Berg, netdev, linux-kernel
In-Reply-To: <20060115152034.GA1722@shaftnet.org>
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 asked so by userspace, whatever the APs
around tell us.
Cheers,
Samuel.
^ permalink raw reply
* Re: wireless: recap of current issues (configuration)
From: Sam Leffler @ 2006-01-15 19:39 UTC (permalink / raw)
To: Stefan Rompf; +Cc: Johannes Berg, netdev, linux-kernel
In-Reply-To: <200601151340.10730.stefan@loplof.de>
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 of my thinking is that
>> different virtual types have different structures associated, so
>> changing it needs re-creating structures anyway. And different virtual
>> device types might even be provided by different kernel modules so you
>> don't carry around AP mode if you don't need it.
>
> 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 it and virtual interfaces are
> limited to one channel anyway. These users rightfully expect to have one
> interface and be able to do all configurations on it.
My experience is that once you can create+destroy virtual devices you'll
never want mode changing. From a usability standpoint when you switch
modes you typically have to reconfigure lots of settings and doing
destroy old followed by create new is easier. Depending on how things
tie into hotplug you may also find things getting complicated.
Within the kernel having the operating mode of a virtual device not
change is very good. First it lets you isolate the rules for mix+match
of different virtual devices at create. Second you can partition code
so, for example, only code required to support an ap is loaded when an
ap mode virtual device exists. There are other less obvious reasons
such as firmware-based devices can load firmware based on the operating
mode at create time but if you allow mode switching then you need to
unload+load on the fly. All these things can be handled with switching
modes but the complexity is significant and the gain is minimal.
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 this behaviour it can be done by user code.
Sam
^ permalink raw reply
* Re: wireless: recap of current issues (configuration)
From: Sam Leffler @ 2006-01-15 19:53 UTC (permalink / raw)
To: Jeff Garzik, Johannes Berg, netdev, linux-kernel
In-Reply-To: <20060115152034.GA1722@shaftnet.org>
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_frequency(hw, 2412).
>> For completely programmable hardware, the stack should interact with a
>> module like ieee80211_geo, to help ensure the hardware stays within
>> legal limits.
>
> While there is much to debate about where to draw the functionality
> line, completely programmable hardware is the norm these days.
>
> ... and said code would be responsible for driving the scanning state
> machines, and also for more esoteric functions like handling RADAR
> traps, automatic channel switching, etc.
>
> Handling scans is quite interesting -- I've seen hardware which requires
> manual channel changing (including full RF parameter specification),
> host timing for the channel dwell time, and manual probe request
> issuance.. and on the other end of the spectrum, a simple "issue scan"
> command that takes few, if any, parameters.
>
> And unfortunately, many things in between.
>
> This leads me to belive that the internal scan workflow should work
> something like this:
>
> * Userspace app issues scan request (aka "refresh AP list")
>
> * Knowing the hardware frequency capabilities, the 802.11 stack applies
> 802.11d and regdomain rules to the available frequency set, and
> issues multiple internal "scan request" commands to the hardware
> driver. (eg "perform an initial passive sweep across the entire
> 2.4G band", "perform an active scan on frequencies 2412->2437
> looking for ssid "HandTossed", "perform an active scan on
> frequencies 5200-5400 looking for ssid "HandTossed", etc)
>
> (note that ideally, userspace apps/libs would be at least partially
> aware of 802.11d rules, but the kernel must do the RightThing if
> told to "scan all available channels for any access points")
>
> * The hardware driver takes this scan request, and maps it into the
> capabilities of the hardware:
>
> Hardware A: (very thin MAC)
> - Using library code, generates an appropriate probe request frame,
> translates it into a format the hardware expects/needs,
> and schedules it appropriately.
> - Loops through the frequency set specified, and for each:
> - Issues a channel change command
> - Immediately transmits the probe request (for active scans)
> - Dwells for an appropriate time
> - RX'ed beacon/probe response frames come down as regular 802.11
> frames into the stack
> - Moves to the next channel
>
> Hardware B: (thinner MAC)
> - Using library code, generates an appropriate probe request frame,
> and translate it into a format the hardware expects.
> - Program the probe request frame into the hardware as a probe
> template.
> - Loops through the frequency set specified, and for each:
> - Issues a channel change command
> - Wait for a scan complete signal
> - RX'ed beacon/probe response frames come down as regular 802.11
> frames into the stack
> - Moves to the next channel
>
> Hardware C: (thick MAC, ala prism2 or prism54)
> - Issues a hardware "scan request"
> - Waits for the hardware to signal "scan complete"
> - Requests hardware scan results
> - For each scan result, the hardware returns:
> - Translate result into an 802.11 probe response frame and
> pass down the regular RX path.
>
> So as you can see, I think the channel iteration, dwell, etc should
> be performed by the hardware driver itself, as the variation at the
> logical "tell the hardware perform a scan" step is so extreme.
>
> * Meanwhile, the 802.11 stack is receiving the beacons/probe responses
> from the hardware via the regular rx path. It diverts these (and
> other 802.11 management/control) frames, decodes them, and then adds
> them to the stack's internal list of available stations, updating any
> internal states/counters as necessary. (These frames could also be
> echoed to a special netdev interface if desired)
>
> (stuff like detecting an AP going away depends on us noticing a lack
> of beacons arriving, for example. Most hardware does not
> notify us of this event. Likewise, we should expire other
> APs from our list if they go away.. etc. For AP operation we need
> to maintain this STA list, period -- so why not use it across the
> board? But this is another discussion for another time..)
>
> * The 802.11 stack issues a MLME-Scan-Complete notification to
> userspace.
>
> * Interested userspace apps see this event, then query the
> scan results and presents them to the user in some pretty format, or
> alternatively perform automatic roaming based on scan results.
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.
Further you want to order your channel list to hit the most likely
channels first in case you are scanning for a specific ap--e.g. so you
can stop the foreground scan and start to associate. In terms of beacon
miss processing some parts have a hardware beacon miss interrupt based
on missed consecutive beacons but others require you to detect beacon
miss in software. Other times you need s/w bmiss detection because
you're doing something like build a repeater when the station virtual
device can't depend on the hardware to deliver a bmiss interrupt.
Then of course there's whole issue of interacting with firmware-based
cards that have limited and/or funkiness in their scanning support.
Scanning (and roaming) is really a big can 'o worms.
Sam
^ permalink raw reply
* Re: wireless: recap of current issues (configuration)
From: Sam Leffler @ 2006-01-15 20:08 UTC (permalink / raw)
To: Stefan Rompf; +Cc: Johannes Berg, netdev, linux-kernel
In-Reply-To: <200601151853.31710.stefan@loplof.de>
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()
> initiates a lot of actions. IPv4 addresses and routes are removed, same for
> IPv6, IPX, Appletalk etc. Stacked VLAN devices are recursively unregistered
> (even though I have not tried yet if it works when I create VLANs over 802.3
> emulated wlan interfaces ;-), udev bloat runs. And all this stuff has to be
> restored by the nifty new configuration utility, possibly including ifindex
> and future protocols.
>
> This is from my usage pattern that I want to go into monitor mode on current
> channel, look at some packets and return to the association without losing
> layer 3 configuration.
>
> So after all, it is IMHO way less painful to handle a mode change in the
> kernel.
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--i.e. for those that require different
firmware to do monitoring you will be restricted to a single virtual
device and/or operating mode.
Sam
^ permalink raw reply
* Re: wireless: recap of current issues (configuration)
From: Johannes Berg @ 2006-01-15 20:11 UTC (permalink / raw)
To: Sam Leffler; +Cc: Stefan Rompf, netdev, linux-kernel
In-Reply-To: <43CAABD4.3070004@errno.com>
[-- Attachment #1: Type: text/plain, Size: 734 bytes --]
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--i.e. for those that require different
> firmware to do monitoring you will be restricted to a single virtual
> device and/or operating 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 switch that to a struct virtual_monitor_device. Icky.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
^ permalink raw reply
* Re: [RFC: 2.6 patch] remove drivers/net/eepro100.c
From: Stephen Hemminger @ 2006-01-16 0:03 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: Adrian Bunk, jgarzik, saw, linux-kernel, netdev
In-Reply-To: <20060115161958.07e3c7f1@vitb.dev.rtsoft.ru>
On Sun, 15 Jan 2006 16:19:58 +0300
Vitaly Bordug <vbordug@ru.mvista.com> wrote:
> On Thu, 5 Jan 2006 19:18:26 +0100
> Adrian Bunk <bunk@stusta.de> wrote:
>
> > This patch removes the obsolete drivers/net/eepro100.c driver.
> >
> > Is there any known problem in e100 still preventing us from removing
> > this driver (it seems noone was able anymore to verify the ARM problem)?
> >
> I think I am recalling some problems on ppc82xx, when e100 was stuck on startup,
> and eepro100 worked just fine.
>
> Even if the patch below will be scheduled for application, we need to set up enough time
> for approval that e100 will be fine for all the up-to-date hw; or it should be fixed/updated before eepro100 removal.
>
> >
> > Signed-off-by: Adrian Bunk <bunk@stusta.de>
> >
> >
How about doing what was done with devfs removal, and remove it
from the config menu system for a couple of releases.
^ permalink raw reply
* Re: wireless: recap of current issues (configuration)
From: Mike Kershaw @ 2006-01-16 0:06 UTC (permalink / raw)
To: Sam Leffler; +Cc: Stefan Rompf, Johannes Berg, netdev, linux-kernel
In-Reply-To: <43CAA4FD.5070605@errno.com>
[-- Attachment #1: Type: text/plain, Size: 1036 bytes --]
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 this behaviour it can be done by user code.
Right, no reason not to just put this into a hotplug script, is there?
Is it, when it comes down to it, significantly different than automating
firmware loads for the user?
-m
--
Mike Kershaw/Dragorn <dragorn@kismetwireless.net>
GPG Fingerprint: 3546 89DF 3C9D ED80 3381 A661 D7B2 8822 738B BDB1
Experts in ancient Greek culture say that people back then didn't see their
thoughts as belonging to them. When they had a thought, it occured to them
as a god or goddess giving them an order. Apollo was telling them to be
brave. Athena was telling them to fall in love.
Now people hear a commercial for sour cream potato chips and rush out to buy.
-- Chuck Palahniuk
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [RFC: 2.6 patch] remove drivers/net/eepro100.c
From: Adrian Bunk @ 2006-01-16 0:08 UTC (permalink / raw)
To: Vitaly Bordug
Cc: jgarzik, saw, linux-kernel, netdev, john.ronciak,
ganesh.venkatesan, jesse.brandeburg
In-Reply-To: <20060115161958.07e3c7f1@vitb.dev.rtsoft.ru>
On Sun, Jan 15, 2006 at 04:19:58PM +0300, Vitaly Bordug wrote:
> On Thu, 5 Jan 2006 19:18:26 +0100
> Adrian Bunk <bunk@stusta.de> wrote:
>
> > This patch removes the obsolete drivers/net/eepro100.c driver.
> >
> > Is there any known problem in e100 still preventing us from removing
> > this driver (it seems noone was able anymore to verify the ARM problem)?
> >
> I think I am recalling some problems on ppc82xx, when e100 was stuck on startup,
> and eepro100 worked just fine.
>
> Even if the patch below will be scheduled for application, we need to set up enough time
> for approval that e100 will be fine for all the up-to-date hw; or it should be fixed/updated before eepro100 removal.
How/When can you/someone else test this?
Do the e100 maintainers (Cc'ed) know about such problems and their
status?
> Sincerely,
> Vitaly
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply
* Re: linux 2.6.15.1 ppp_async panic on x86-64.
From: Diego Calleja @ 2006-01-16 3:03 UTC (permalink / raw)
To: Serge Belyshev; +Cc: linux-kernel, vitalyb, netdev
In-Reply-To: <56slrpz0j7.fsf@depni.sinp.msu.ru>
This should have been forwaded to netdev I think (forwading there)
El Sun, 15 Jan 2006 23:41:48 +0300,
Serge Belyshev <belyshev@depni.sinp.msu.ru> escribió:
Diego Calleja <diegocg@gmail.com> writes:
> > El Sun, 15 Jan 2006 21:48:38 +0200,
> > "Vitaly V. Bursov" <vitalyb@telenet.dn.ua> escribió:
> ...
> >> PPP doesn't work for me on a x86-64 kernel. Kernel panics with a message
> ...
> >> Jan 15 20:24:12 vb skb_over_panic: text:ffffffff886700d9 len:1 put:1
> >> head:ffff81002b7ed000 data:ffff81012b7ed000 tail:ffff81012b7ed001
> >> end:ffff81002b7ed600 dev:<NULL>
> ...
> > Just for the record, there're more people hitting this
> > http://bugzilla.kernel.org/show_bug.cgi?id=5857
>
> I can confirm this with a similar oops:
>
> [ 273.950666] skb_over_panic: text:ffffffff882d8c19 len:54 put:54 head:ffff81001cfecd60 data:ffff81011cfecd63 tail:ffff81011cfecd99 end:ffff81001cfed360 dev:<NULL>
> [ 273.950681] ----------- [cut here ] --------- [please bite here ] ---------
> [ 273.950684] Kernel BUG at net/core/skbuff.c:94
> [ 273.950686] invalid operand: 0000 [1] PREEMPT
> [ 273.950689] CPU 0
> [ 273.950691] Modules linked in: ppp_deflate bsd_comp ppp_async ppp_generic slhc pl2303 usbserial radeon drm af_packet ipv6 pcmcia firmware_class bridge deflate zlib_deflate zlib_inflate twofish serpent aes blowfish des sha256 sha1 af_key binfmt_misc dm_mod asus_acpi button thermal processor battery evdev eth1394 snd_intel8x0 snd_intel8x0m snd_ac97_codec snd_ac97_bus snd_pcm_oss snd_mixer_oss snd_pcm irtty_sir snd_timer ohci1394 snd sir_dev irda 8250_pci ide_cd yenta_socket rsrc_nonstatic pcmcia_core amd64_agp ehci_hcd psmouse pcspkr parport_pc parport 8250 serial_core ieee1394 cdrom ohci_hcd usbcore crc_ccitt i2c_nforce2 i2c_core soundcore snd_page_alloc rtc agpgart unix
> [ 273.950728] Pid: 4, comm: events/0 Not tainted 2.6.15-ssb1dbg #3
> [ 273.950731] RIP: 0010:[skb_over_panic+96/112] <ffffffff8027c160>{skb_over_panic+96}
> [ 273.950739] RSP: 0018:ffff81001fe19d78 EFLAGS: 00010096
> [ 273.950742] RAX: 00000000000000ab RBX: 0000000000000036 RCX: ffffffff803b5d58
> [ 273.950745] RDX: ffff81001ff38080 RSI: 0000000000000082 RDI: 0000000000000001
> [ 273.950749] RBP: ffff81001fe19d98 R08: 0000000000000005 R09: 0000000000000000
> [ 273.950752] R10: 0000000000000000 R11: 0000000000000000 R12: ffff81000c4c18e8
> [ 273.950755] R13: 000000000000003f R14: ffff8100164a8801 R15: ffff81011cfecd63
> [ 273.950759] FS: 00002aaaab3a96d0(0000) GS:ffffffff80575800(0000) knlGS:0000000000000000
> [ 273.950763] CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
> [ 273.950766] CR2: 0000000000c55000 CR3: 0000000019e81000 CR4: 00000000000006e0
> [ 273.950770] Process events/0 (pid: 4, threadinfo ffff81001fe18000, task ffff81001ff38080)
> [ 273.950772] Stack: ffff81011cfecd99 ffff81001cfed360 ffffffff80323edb ffff81000c4c18e8
> [ 273.950779] ffff81001fe19df8 ffffffff882d8c23 ffff81000c4c19a0 ffff81000c4c1918
> [ 273.950785] ffff8100164a8401 ffff8100164a8000
> [ 273.950789] Call Trace:<ffffffff882d8c23>{:ppp_async:ppp_asynctty_receive+579}
> [ 273.950800] <ffffffff80238593>{flush_to_ldisc+291} <ffffffff80142e40>{worker_thread+512}
> [ 273.950816] <ffffffff80238470>{flush_to_ldisc+0} <ffffffff8012d9c0>{default_wake_function+0}
> [ 273.950827] <ffffffff802fb3a1>{thread_return+191} <ffffffff80142c40>{worker_thread+0}
> [ 273.950839] <ffffffff801477d9>{kthread+217} <ffffffff802fc7b4>{_spin_unlock_irq+20}
> [ 273.950848] <ffffffff8012de39>{schedule_tail+73} <ffffffff8010f7d6>{child_rip+8}
> [ 273.950858] <ffffffff80147700>{kthread+0} <ffffffff8010f7ce>{child_rip+0}
> [ 273.950871]
> [ 273.950874]
> [ 273.950875] Code: 0f 0b 68 fe fe 32 80 c2 5e 00 c9 c3 66 66 66 90 55 49 89 d2
> [ 273.950885] RIP <ffffffff8027c160>{skb_over_panic+96} RSP <ffff81001fe19d78>
> [ 273.950891] <3>Debug: sleeping function called from invalid context at include/linux/rwsem.h:43
> [ 273.950895] in_atomic():1, irqs_disabled():1
> [ 273.950897]
> [ 273.950898] Call Trace:<ffffffff8012c9eb>{__might_sleep+187} <ffffffff801328ed>{profile_task_exit+29}
> [ 273.950907] <ffffffff801339e5>{do_exit+37} <ffffffff802fc7fd>{_spin_unlock_irqrestore+29}
> [ 273.950917] <ffffffff80110654>{die+84} <ffffffff802fce4d>{do_trap+269}
> [ 273.950929] <ffffffff80110e6d>{do_invalid_op+157} <ffffffff8027c160>{skb_over_panic+96}
> [ 273.950941] <ffffffff8010f621>{error_exit+0} <ffffffff8027c160>{skb_over_panic+96}
> [ 273.950962] <ffffffff8027c160>{skb_over_panic+96} <ffffffff882d8c23>{:ppp_async:ppp_asynctty_receive+579}
> [ 273.950975] <ffffffff80238593>{flush_to_ldisc+291} <ffffffff80142e40>{worker_thread+512}
> [ 273.950990] <ffffffff80238470>{flush_to_ldisc+0} <ffffffff8012d9c0>{default_wake_function+0}
> [ 273.950999] <ffffffff802fb3a1>{thread_return+191} <ffffffff80142c40>{worker_thread+0}
> [ 273.951011] <ffffffff801477d9>{kthread+217} <ffffffff802fc7b4>{_spin_unlock_irq+20}
> [ 273.951020] <ffffffff8012de39>{schedule_tail+73} <ffffffff8010f7d6>{child_rip+8}
> [ 273.951029] <ffffffff80147700>{kthread+0} <ffffffff8010f7ce>{child_rip+0}
> [ 273.951042]
> [ 273.951046] note: events/0[4] exited with preempt_count 1
>
> (this is 2.6.15-ck2 + few local hacks with debugging config)
^ permalink raw reply
* RE: wireless: recap of current issues (other issues)
From: Simon Barber @ 2006-01-16 5:32 UTC (permalink / raw)
To: Jeff Garzik, John W. Linville; +Cc: netdev, linux-kernel
To fake ethernet or not?
------------------------
There is a similar problem in the VLAN code - do you expect the rest of
the network stack to be able to interpret VLAN tagged frames? This was
the original state of the VLAN code - this caused problems since many
apps and modules did not understand VLAN tags (e.g. dhcp). The VLAN
code was extended to offer both options - the VLAN virtual device can
be switched to ethernet (non tagged) or tagged. I would suggest that for
compatibility the default for WLAN code be ethernet format frames, and
if somebody wants it to also have an option for 802.11 format frames -
then that be alowed too. If you really want to build a kernel without
ethernet support this is theoretically possible.
The 802.11 format question is related to the 'virtual devices' question.
Most 802.11 implementations split into 2 categories. 1. Those where the
MLME runs on the chip and 2. those where the MLME runs in the host. The
MLME implementations that run on the chip to date that I know about do
not support multiple virtual networks, or other advanced features that
require multiple virtual devices. For these devices frames are typically
exchanged with the hardware in ethernet format, and a single ethernet
format net_device is likely all that will be needed in linux. For
devices that leave the MLME to the host, a much wider range of advanced
features is possible - and here a raw 802.11 net_device and multiple
virtual devices is likely required. A single physical device is required
to implement a qdisc and do priority queueing properly. Multiple virtual
devices to support advanced stack features could be either 802.11 format
or ethernet format depending on the feature and configuration.
Channels/Frequencies
--------------------
For chips with firmware that runs on the chip oftentimes the setting of
channel and power limits is done on the chip, in order to meet the FCC
restriction of making it difficult for the end user to set illegal
values. In cases of chips without firmware these functions may be done
by the stack, or in some cases by a binary code block.
Simon
-----Original Message-----
From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org]
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 issues (other issues)
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 a new frame
class.
Jeff
-
To unsubscribe from this list: send the line "unsubscribe netdev" in the
body of a message to majordomo@vger.kernel.org More majordomo info at
http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: 32 bit (socket layer) ioctl emulation for 64 bit kernels
From: Shaun Pereira @ 2006-01-16 5:59 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Arnaldo Carvalho de Melo, Andi Kleen, linux-kenel, netdev, SP
In-Reply-To: <200601131146.48128.arnd@arndb.de>
Hi Arnd
I have made the changes suggested, and attached it below. I think it
should be good now.
Just a couple of questions if I may.
If I understand correctly from your comments (thanks for that, they are
helpful)
copy_to_user acts like a memcopy for an 'array' of bytes and should not
be used to copy the timeval struct to userspace.
Rather put_user / __put_user macros should be used which allows transfer
of single element values of the structure.
Does that also mean that copy_to_user should not be used in ioctl
calls?
I was wondering if this the compat_sock_get_timestamp function is
needed? If I were to remove the SIOCGSTAMP case from the
compat_x25_ioctl function, then a SIOCGSTAMP ioctl system call would
return -ENOIOCTLCMD which could then be handled by do_siocgstamp
handler in the ioctl32_hash_table? (fs/compat_ioctl.c)
In which case I could remove this patch from the rest of the series.
/Shaun
Index: linux-2.6.15/include/net/compat.h
===================================================================
--- linux-2.6.15.orig/include/net/compat.h
+++ linux-2.6.15/include/net/compat.h
@@ -23,6 +23,8 @@ struct compat_cmsghdr {
compat_int_t cmsg_type;
};
+extern int compat_sock_get_timestamp(struct sock *, struct timeval
__user *);
+
#else /* defined(CONFIG_COMPAT) */
#define compat_msghdr msghdr /* to avoid compiler warnings */
#endif /* defined(CONFIG_COMPAT) */
Index: linux-2.6.15/net/compat.c
===================================================================
--- linux-2.6.15.orig/net/compat.c
+++ linux-2.6.15/net/compat.c
@@ -503,6 +503,25 @@ static int do_get_sock_timeout(int fd, i
return err;
}
+int compat_sock_get_timestamp(struct sock *sk, struct timeval __user
*userstamp)
+{
+ struct compat_timeval __user *ctv
+ = (struct compat_timeval __user*) userstamp;
+ int err = -ENOENT;
+ if(!sock_flag(sk, SOCK_TIMESTAMP))
+ sock_enable_timestamp(sk);
+ if(sk->sk_stamp.tv_sec == -1)
+ return err;
+ if(sk->sk_stamp.tv_sec == 0)
+ do_gettimeofday(&sk->sk_stamp);
+ err = -EFAULT;
+ if(access_ok(VERIFTY_WRITE, ctv, sizeof(*ctv))) {
+ err = __put_user(sk->sk_stamp.tv_sec, &ctv->tv_sec);
+ err != __put_user(sk->sk_stamp.tv_usec, &ctv->tv_usec);
+ }
+ return err;
+}
+
asmlinkage long compat_sys_getsockopt(int fd, int level, int optname,
char __user *optval, int __user *optlen)
{
@@ -602,3 +621,5 @@ asmlinkage long compat_sys_socketcall(in
}
return ret;
}
+
+EXPORT_SYMBOL(compat_sock_get_timestamp);
On Fri, 2006-01-13 at 11:46 +0000, Arnd Bergmann wrote:
> On Friday 13 January 2006 03:14, Shaun Pereira wrote:
> > Thank you for reviewing that bit of code.
> > I had a look at compat_sys_gettimeofday and sys32_gettimeofday codes.
> > They seem to work in a similar way, casting a pointer to the structure
> > from user space to a compat_timeval type.
>
> The part with the case is ok, except that you don't have to write
>
> struct compat_timeval __user *ctv;
> ctv = (struct compat_timeval __user*) userstamp;
>
> Instead,
>
> struct compat_timeval __user *ctv = userstamp;
>
> is the more common way to write it. The result is the same, since
> userstamp is a 'void __user *'.
>
> > But to make sure I have tested the routine by forcing the sk-
> > >sk_stamp.tv_sec value to 0 in the x25_module ( for testing purposes
> > only, as it is initialised to -1). Now when
> > I make a 32 bit userspace SIOCGSTAMP ioctl to the 64 bit kernel I should
> > get the current time back in user space. This seems to work, the ioctl
> > returns the system time (just after TEST6:)
> >
> > So I have left the patch as is for now. However if necessary to use
> > the element-by-element __put_user routine as in put_tv32, then I can
> > make the change, just let me know.
>
> You need to to exactly that, yes. I'm not sure what exactly you have
> tested, but the expected result of your code would be that you see
> the sk_stamp.tv_sec value in the output, but not the tv_usec value.
>
> On little-endian system like x86_64, that is not much of a difference
> (less than a second) that you might miss in a test case, but on
> big-endian, it would be fatal.
>
> The layout of the structures on most systems is
>
> 64 bit LE 64 bit BE 32 bit
>
> bytes 0-3 tv_sec low tv_sec high tv_sec low
> bytes 4-7 tv_sec high tv_sec low tv_usec low
> bytes 8-11 tv_usec low tv_usec high
> bytes 12-15 tv_usec high tv_usec low
>
> You code copies the first eight bytes of the 64 bit data structure
> into the 32 bit data structure.
>
> Arnd <><
^ permalink raw reply
* Re: 32 bit (socket layer) ioctl emulation for 64 bit kernels
From: YOSHIFUJI Hideaki / 吉藤英明 @ 2006-01-16 6:41 UTC (permalink / raw)
To: spereira; +Cc: arnd, acme, ak, linux-kernel, netdev, pereira.shaun, yoshfuji
In-Reply-To: <1137391160.5588.32.camel@spereira05.tusc.com.au>
In article <1137391160.5588.32.camel@spereira05.tusc.com.au> (at Mon, 16 Jan 2006 16:59:20 +1100), Shaun Pereira <spereira@tusc.com.au> says:
> If I understand correctly from your comments (thanks for that, they are
> helpful)
> copy_to_user acts like a memcopy for an 'array' of bytes and should not
> be used to copy the timeval struct to userspace.
> Rather put_user / __put_user macros should be used which allows transfer
> of single element values of the structure.
> +int compat_sock_get_timestamp(struct sock *sk, struct timeval __user
> *userstamp)
> +{
> + struct compat_timeval __user *ctv
> + = (struct compat_timeval __user*) userstamp;
> + int err = -ENOENT;
> + if(!sock_flag(sk, SOCK_TIMESTAMP))
> + sock_enable_timestamp(sk);
> + if(sk->sk_stamp.tv_sec == -1)
> + return err;
> + if(sk->sk_stamp.tv_sec == 0)
> + do_gettimeofday(&sk->sk_stamp);
> + err = -EFAULT;
> + if(access_ok(VERIFTY_WRITE, ctv, sizeof(*ctv))) {
> + err = __put_user(sk->sk_stamp.tv_sec, &ctv->tv_sec);
> + err != __put_user(sk->sk_stamp.tv_usec, &ctv->tv_usec);
> + }
> + return err;
> +}
> +
Hmm, you will copy 32bit of MSB in big-endian.
You should do something like this:
strtuct compat_timeval tvtmp;
:
tvtmp.tv_sec = sk->sk_stamp.tv_sec;
tvtmp.tv_usec = sk->sk_stemp.tv_usec;
return copy_to_user(ctv, &tvtmp, sizeof(tvtmp));
Or, am I miss something?
--yoshfuji
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox