* [PATCH] softmac: suggest per-frame-type TX rate
From: Daniel Drake @ 2006-04-17 19:33 UTC (permalink / raw)
To: linville; +Cc: johannes, netdev, softmac-dev, kune, sam
This patch is the first step towards rate control inside softmac.
The txrates substructure has been extended to provide different fields for
different types of packets (management/data, unicast/multicast). These fields
are updated on association to values compatible with the access point we are
associating to.
Drivers can then use the new ieee80211softmac_suggest_txrate() function call
when deciding which rate to transmit each frame at. This is immensely useful
for ZD1211, and bcm can use it too.
The user can still specify a rate through iwconfig, which is matched for all
transmissions (assuming the rate they have specified is in the rate set
required by the AP).
At a later date, we can incorporate automatic rate management into the
ieee80211softmac_recalc_txrates() function.
This patch also removes the mcast_fallback field. Sam Leffler pointed out that
this field is meaningless, because no driver will ever be retransmitting mcast
frames (they are not acked).
Signed-off-by: Daniel Drake <dsd@gentoo.org>
--- linux/include/net/ieee80211softmac.h.orig 2006-04-16 23:37:32.000000000 +0100
+++ linux/include/net/ieee80211softmac.h 2006-04-17 20:19:15.000000000 +0100
@@ -86,6 +86,9 @@ struct ieee80211softmac_assoc_info {
/* BSSID we're trying to associate to */
char bssid[ETH_ALEN];
+
+ /* Rates supported by the network */
+ struct ieee80211softmac_ratesinfo supported_rates;
/* some flags.
* static_essid is valid if the essid is constant,
@@ -129,23 +132,26 @@ enum {
struct ieee80211softmac_txrates {
/* The Bit-Rate to be used for multicast frames. */
u8 mcast_rate;
- /* The Bit-Rate to be used for multicast fallback
- * (If the device supports fallback and hardware-retry)
- */
- u8 mcast_fallback;
+
+ /* The Bit-Rate to be used for multicast management frames. */
+ u8 mgt_mcast_rate;
+
/* The Bit-Rate to be used for any other (normal) data packet. */
u8 default_rate;
/* The Bit-Rate to be used for default fallback
* (If the device supports fallback and hardware-retry)
*/
u8 default_fallback;
+
+ /* This is the rate that the user asked for */
+ u8 user_rate;
};
/* Bits for txrates_change callback. */
#define IEEE80211SOFTMAC_TXRATECHG_DEFAULT (1 << 0) /* default_rate */
#define IEEE80211SOFTMAC_TXRATECHG_DEFAULT_FBACK (1 << 1) /* default_fallback */
#define IEEE80211SOFTMAC_TXRATECHG_MCAST (1 << 2) /* mcast_rate */
-#define IEEE80211SOFTMAC_TXRATECHG_MCAST_FBACK (1 << 3) /* mcast_fallback */
+#define IEEE80211SOFTMAC_TXRATECHG_MGT_MCAST (1 << 3) /* mgt_mcast_rate */
struct ieee80211softmac_device {
/* 802.11 structure for data stuff */
@@ -246,6 +252,28 @@ extern void ieee80211softmac_fragment_lo
* Note that the rates need to be sorted. */
extern void ieee80211softmac_set_rates(struct net_device *dev, u8 count, u8 *rates);
+/* Helper function which advises you the rate at which a frame should be
+ * transmitted at. */
+static inline u8 ieee80211softmac_suggest_txrate(struct ieee80211softmac_device *mac,
+ int is_multicast,
+ int is_mgt)
+{
+ struct ieee80211softmac_txrates *txrates = &mac->txrates;
+
+ if (!mac->associated)
+ return txrates->mgt_mcast_rate;
+
+ /* We are associated, sending unicast frame */
+ if (!is_multicast)
+ return txrates->default_rate;
+
+ /* We are associated, sending multicast frame */
+ if (is_mgt)
+ return txrates->mgt_mcast_rate;
+ else
+ return txrates->mcast_rate;
+}
+
/* Start the SoftMAC. Call this after you initialized the device
* and it is ready to run.
*/
--- linux/net/ieee80211/softmac/ieee80211softmac_assoc.c.orig 2006-04-16 23:55:23.000000000 +0100
+++ linux/net/ieee80211/softmac/ieee80211softmac_assoc.c 2006-04-17 17:17:59.000000000 +0100
@@ -101,30 +101,22 @@ ieee80211softmac_disassoc(struct ieee802
/* Do NOT clear bssvalid as that will break ieee80211softmac_assoc_work! */
mac->associated = 0;
mac->associnfo.associating = 0;
+ ieee80211softmac_init_txrates(mac);
spin_unlock_irqrestore(&mac->lock, flags);
}
static inline int
we_support_all_basic_rates(struct ieee80211softmac_device *mac, u8 *from, u8 from_len)
{
- int idx, search, found;
- u8 rate, search_rate;
+ int idx;
+ u8 rate;
for (idx = 0; idx < (from_len); idx++) {
rate = (from)[idx];
if (!(rate & IEEE80211_BASIC_RATE_MASK))
continue;
- found = 0;
rate &= ~IEEE80211_BASIC_RATE_MASK;
- for (search = 0; search < mac->ratesinfo.count; search++) {
- search_rate = mac->ratesinfo.rates[search];
- search_rate &= ~IEEE80211_BASIC_RATE_MASK;
- if (rate == search_rate) {
- found = 1;
- break;
- }
- }
- if (!found)
+ if (!ieee80211softmac_ratesinfo_rate_supported(&mac->ratesinfo, rate))
return 0;
}
return 1;
@@ -283,6 +275,9 @@ ieee80211softmac_associated(struct ieee8
struct ieee80211softmac_network *net)
{
mac->associnfo.associating = 0;
+ mac->associnfo.supported_rates = net->supported_rates;
+ ieee80211softmac_recalc_txrates(mac);
+
mac->associated = 1;
if (mac->set_bssid_filter)
mac->set_bssid_filter(mac->dev, net->bssid);
@@ -373,6 +368,7 @@ ieee80211softmac_handle_disassoc(struct
spin_lock_irqsave(&mac->lock, flags);
mac->associnfo.bssvalid = 0;
mac->associated = 0;
+ ieee80211softmac_init_txrates(mac);
schedule_work(&mac->associnfo.work);
spin_unlock_irqrestore(&mac->lock, flags);
--- linux/net/ieee80211/softmac/ieee80211softmac_module.c.orig 2006-04-17 01:04:42.000000000 +0100
+++ linux/net/ieee80211/softmac/ieee80211softmac_module.c 2006-04-17 20:21:11.000000000 +0100
@@ -26,6 +26,7 @@
#include "ieee80211softmac_priv.h"
#include <linux/sort.h>
+#include <linux/etherdevice.h>
struct net_device *alloc_ieee80211softmac(int sizeof_priv)
{
@@ -59,14 +60,6 @@ struct net_device *alloc_ieee80211softma
softmac->wait_for_scan = ieee80211softmac_wait_for_scan_implementation;
softmac->stop_scan = ieee80211softmac_stop_scan_implementation;
- //TODO: The mcast rate has to be assigned dynamically somewhere (in scanning, association. Not sure...)
- // It has to be set to the highest rate all stations in the current network can handle.
- softmac->txrates.mcast_rate = IEEE80211_CCK_RATE_1MB;
- softmac->txrates.mcast_fallback = IEEE80211_CCK_RATE_1MB;
- /* This is reassigned in ieee80211softmac_start to sane values. */
- softmac->txrates.default_rate = IEEE80211_CCK_RATE_1MB;
- softmac->txrates.default_fallback = IEEE80211_CCK_RATE_1MB;
-
/* to start with, we can't send anything ... */
netif_carrier_off(dev);
@@ -166,15 +159,82 @@ static void ieee80211softmac_start_check
}
}
-void ieee80211softmac_start(struct net_device *dev)
+int ieee80211softmac_ratesinfo_rate_supported(struct ieee80211softmac_ratesinfo *ri, u8 rate)
+{
+ int search;
+ u8 search_rate;
+
+ for (search = 0; search < ri->count; search++) {
+ search_rate = ri->rates[search];
+ search_rate &= ~IEEE80211_BASIC_RATE_MASK;
+ if (rate == search_rate)
+ return 1;
+ }
+
+ return 0;
+}
+
+/* Finds the highest rate which is:
+ * 1. Present in ri (optionally a basic rate)
+ * 2. Supported by the device
+ * 3. Less than or equal to the user-defined rate
+ */
+static u8 highest_supported_rate(struct ieee80211softmac_device *mac,
+ struct ieee80211softmac_ratesinfo *ri, int basic_only)
+{
+ u8 user_rate = mac->txrates.user_rate;
+ int i;
+
+ if (ri->count == 0) {
+ dprintk(KERN_ERROR PFX "empty ratesinfo?n");
+ return IEEE80211_CCK_RATE_1MB;
+ }
+
+ for (i = ri->count - 1; i >= 0; i--) {
+ u8 rate = ri->rates[i];
+ if (basic_only && !(rate & IEEE80211_BASIC_RATE_MASK))
+ continue;
+ rate &= ~IEEE80211_BASIC_RATE_MASK;
+ if (rate > user_rate)
+ continue;
+ if (ieee80211softmac_ratesinfo_rate_supported(&mac->ratesinfo, rate))
+ return rate;
+ }
+
+ /* If we haven't found a suitable rate by now, just trust the user */
+ return user_rate;
+}
+
+void ieee80211softmac_recalc_txrates(struct ieee80211softmac_device *mac)
+{
+ struct ieee80211softmac_txrates *txrates = &mac->txrates;
+ struct ieee80211softmac_txrates oldrates;
+ u32 change = 0;
+
+ if (mac->txrates_change)
+ oldrates = mac->txrates;
+
+ change |= IEEE80211SOFTMAC_TXRATECHG_DEFAULT;
+ txrates->default_rate = highest_supported_rate(mac, &mac->associnfo.supported_rates, 0);
+
+ change |= IEEE80211SOFTMAC_TXRATECHG_DEFAULT_FBACK;
+ txrates->default_fallback = lower_rate(mac, txrates->default_rate);
+
+ change |= IEEE80211SOFTMAC_TXRATECHG_MCAST;
+ txrates->mcast_rate = highest_supported_rate(mac, &mac->associnfo.supported_rates, 1);
+
+ if (mac->txrates_change)
+ mac->txrates_change(mac->dev, change, &oldrates);
+
+}
+
+void ieee80211softmac_init_txrates(struct ieee80211softmac_device *mac)
{
- struct ieee80211softmac_device *mac = ieee80211_priv(dev);
struct ieee80211_device *ieee = mac->ieee;
u32 change = 0;
+ struct ieee80211softmac_txrates *txrates = &mac->txrates;
struct ieee80211softmac_txrates oldrates;
- ieee80211softmac_start_check_rates(mac);
-
/* TODO: We need some kind of state machine to lower the default rates
* if we loose too many packets.
*/
@@ -189,19 +249,34 @@ void ieee80211softmac_start(struct net_d
more reliable. Note similar logic in
ieee80211softmac_wx_set_rate() */
if (ieee->modulation & IEEE80211_CCK_MODULATION) {
- mac->txrates.default_rate = IEEE80211_CCK_RATE_11MB;
- change |= IEEE80211SOFTMAC_TXRATECHG_DEFAULT;
- mac->txrates.default_fallback = IEEE80211_CCK_RATE_5MB;
- change |= IEEE80211SOFTMAC_TXRATECHG_DEFAULT_FBACK;
+ txrates->user_rate = IEEE80211_CCK_RATE_11MB;
} else if (ieee->modulation & IEEE80211_OFDM_MODULATION) {
- mac->txrates.default_rate = IEEE80211_OFDM_RATE_54MB;
- change |= IEEE80211SOFTMAC_TXRATECHG_DEFAULT;
- mac->txrates.default_fallback = IEEE80211_OFDM_RATE_24MB;
- change |= IEEE80211SOFTMAC_TXRATECHG_DEFAULT_FBACK;
+ txrates->user_rate = IEEE80211_OFDM_RATE_54MB;
} else
assert(0);
+
+ txrates->default_rate = IEEE80211_CCK_RATE_1MB;
+ change |= IEEE80211SOFTMAC_TXRATECHG_DEFAULT;
+
+ txrates->default_fallback = IEEE80211_CCK_RATE_1MB;
+ change |= IEEE80211SOFTMAC_TXRATECHG_DEFAULT_FBACK;
+
+ txrates->mcast_rate = IEEE80211_CCK_RATE_1MB;
+ change |= IEEE80211SOFTMAC_TXRATECHG_MCAST;
+
+ txrates->mgt_mcast_rate = IEEE80211_CCK_RATE_1MB;
+ change |= IEEE80211SOFTMAC_TXRATECHG_MGT_MCAST;
+
if (mac->txrates_change)
- mac->txrates_change(dev, change, &oldrates);
+ mac->txrates_change(mac->dev, change, &oldrates);
+}
+
+void ieee80211softmac_start(struct net_device *dev)
+{
+ struct ieee80211softmac_device *mac = ieee80211_priv(dev);
+
+ ieee80211softmac_start_check_rates(mac);
+ ieee80211softmac_init_txrates(mac);
}
EXPORT_SYMBOL_GPL(ieee80211softmac_start);
--- linux/net/ieee80211/softmac/ieee80211softmac_wx.c.orig 2006-04-17 16:45:51.000000000 +0100
+++ linux/net/ieee80211/softmac/ieee80211softmac_wx.c 2006-04-17 20:17:37.000000000 +0100
@@ -201,8 +201,8 @@ ieee80211softmac_wx_set_rate(struct net_
if (is_ofdm && !(ieee->modulation & IEEE80211_OFDM_MODULATION))
goto out_unlock;
- mac->txrates.default_rate = rate;
- mac->txrates.default_fallback = lower_rate(mac, rate);
+ mac->txrates.user_rate = rate;
+ ieee80211softmac_recalc_txrates(mac);
err = 0;
out_unlock:
--- linux/net/ieee80211/softmac/ieee80211softmac_priv.h.orig 2006-04-17 16:46:09.000000000 +0100
+++ linux/net/ieee80211/softmac/ieee80211softmac_priv.h 2006-04-17 17:09:08.000000000 +0100
@@ -116,7 +116,10 @@ ieee80211softmac_get_network_by_essid(st
struct ieee80211softmac_essid *essid);
/* Rates related */
+int ieee80211softmac_ratesinfo_rate_supported(struct ieee80211softmac_ratesinfo *ri, u8 rate);
u8 ieee80211softmac_lower_rate_delta(struct ieee80211softmac_device *mac, u8 rate, int delta);
+void ieee80211softmac_init_txrates(struct ieee80211softmac_device *mac);
+void ieee80211softmac_recalc_txrates(struct ieee80211softmac_device *mac);
static inline u8 lower_rate(struct ieee80211softmac_device *mac, u8 rate) {
return ieee80211softmac_lower_rate_delta(mac, rate, 1);
}
^ permalink raw reply
* Re: softmac: semantics of SIOCSIWFREQ
From: Johannes Berg @ 2006-04-17 19:27 UTC (permalink / raw)
To: jt; +Cc: netdev, softmac-dev, Ulrich Kunitz
In-Reply-To: <20060417190649.GA28534@bougret.hpl.hp.com>
[-- Attachment #1: Type: text/plain, Size: 722 bytes --]
On Mon, 2006-04-17 at 12:06 -0700, Jean Tourrilhes wrote:
> Definitely. I was just pointing out that scanning behaviour is
> not dictated by current setting of the drivers (except when the
> hardware does it, cf. Ornoco).
Yeah, I was just repeating it for Ulrich :)
> For freq, it's simpler. In managed mode, it's never 'fixed',
> because the card/driver choose the frequency. In master mode, it's
> almost always 'fixed', because the user has to set the frequency. In
> ad-hoc mode, it depend in the node creates or not the IBSS.
But isn't that a detail the user shouldn't have to know? See, if a node
with a higher TSF joins the IBSS, then it gets to send out the beacons
for it, IIRC.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]
^ permalink raw reply
* Re: softmac: semantics of SIOCSIWFREQ
From: Jean Tourrilhes @ 2006-04-17 19:06 UTC (permalink / raw)
To: Johannes Berg; +Cc: netdev, softmac-dev, Ulrich Kunitz
In-Reply-To: <1145299691.4116.11.camel@localhost>
On Mon, Apr 17, 2006 at 08:48:10PM +0200, Johannes Berg wrote:
> On Mon, 2006-04-17 at 09:37 -0700, Jean Tourrilhes wrote:
>
> > Usually no, but...
> > If you are in managed mode, SIOCSIWFREQ usually should return
> > an error, because it is not allowed.
>
> Ok.
>
> > If you are in ad-hoc mode, SIOCSIWFREQ is used if a IBSS needs
> > to be created. After scanning is done, if you did not find any
> > network, you will create your own, and you will use the frequency that
> > was set. You should never return an error.
>
> Right. Well it should return an error if it is 'associated' in ad-hoc
> mode too, no?
Nope, you want to store it for later reuse.
Let suppose the following sequence :
iwconfig eth0 mode ad-hoc essid another-ibss
sleep(2)
iwconfig eth0 freq 2.42G essid a-new-ibss
You don't want the second call to fail.
> > The struct iw_scan_req has all the goodies you need to control
> > scanning.
>
> Right, so that's just a matter of using a different call to say where to
> scan. Gotcha. IOW -- those people that want wardriving should use kismet
> or whatever and properly control the driver via the iw_scan_req.
Definitely. I was just pointing out that scanning behaviour is
not dictated by current setting of the drivers (except when the
hardware does it, cf. Ornoco).
> > The IW_FREQ_FIXED is mostly use for SIOCGIWFREQ, when
> > getting. It tells you if the frequency was set by the user or
> > automatically picked as the result of scanning.
>
> Ah, but in which case is it set by the user? And is that 'fixed' then?
It's easier to explain with bitrate. If the user does not set
the bitrate, or set it to 'auto', it's never 'fixed'. If the user set
explicitely a bitrate, it's 'fixed'.
For freq, it's simpler. In managed mode, it's never 'fixed',
because the card/driver choose the frequency. In master mode, it's
almost always 'fixed', because the user has to set the frequency. In
ad-hoc mode, it depend in the node creates or not the IBSS.
> > I don't think any driver/hardware has the ability to set the
> > frequency to auto, so IW_FREQ_FIXED is the default.
>
> What would 'auto' be?
Well, in auto, I would expect the node to look either at the
scan result and/or noise level on the various frequency to decide where
to create the IBSS (ad-hoc) or BSS (master).
> > It's because softmac only implements managed mode.
>
> We might do some sort of ad-hoc client-only with Pete's patch, but we'll
> never do master or wds I think.
>
> > I've heard the call, I'll try to find some time for that.
>
> Oh I was more thinking that I myself could add it somewhere after all
> our discussion. If you do that, even better, but with the things we have
> discussed already I can definitely help out.
>
> johannes
Have fun...
Jean
^ permalink raw reply
* Re: [PATCH][RFC] Security marking
From: Patrick McHardy @ 2006-04-17 18:55 UTC (permalink / raw)
To: James Morris; +Cc: netdev, David S. Miller, Stephen Smalley, Chris Wright
In-Reply-To: <Pine.LNX.4.64.0604171440480.17563@d.namei>
James Morris wrote:
> On Mon, 17 Apr 2006, Patrick McHardy wrote:
>
>
>>>From a pure netfilter POV it would still be nice to have the socket
>>hooks for userspace queueing in socket context and filtering hard
>>to track protocols. My only question is: if I would port the skfilter
>>patches to the current kernel today and fix the unresolved issues,
>>would you still prefer this approach?
>
>
> I think the newer model of marking the packets first via Netfilter then
> interpreting them at the socket layer is superior. i.e. skfilter is
> probably not preferred for SELinux now.
>
> However, it's still useful for incoming user matching for things like
> user-level firewalling.
OK, thanks. I plan to make it ready for submission eventually, just
wanted to make sure I'm not holding back things.
^ permalink raw reply
* Re: softmac: semantics of SIOCSIWFREQ
From: Johannes Berg @ 2006-04-17 18:48 UTC (permalink / raw)
To: jt; +Cc: netdev, softmac-dev, Ulrich Kunitz
In-Reply-To: <20060417163759.GB28203@bougret.hpl.hp.com>
[-- Attachment #1: Type: text/plain, Size: 1672 bytes --]
On Mon, 2006-04-17 at 09:37 -0700, Jean Tourrilhes wrote:
> Usually no, but...
> If you are in managed mode, SIOCSIWFREQ usually should return
> an error, because it is not allowed.
Ok.
> If you are in ad-hoc mode, SIOCSIWFREQ is used if a IBSS needs
> to be created. After scanning is done, if you did not find any
> network, you will create your own, and you will use the frequency that
> was set. You should never return an error.
Right. Well it should return an error if it is 'associated' in ad-hoc
mode too, no?
> The struct iw_scan_req has all the goodies you need to control
> scanning.
Right, so that's just a matter of using a different call to say where to
scan. Gotcha. IOW -- those people that want wardriving should use kismet
or whatever and properly control the driver via the iw_scan_req.
> The IW_FREQ_FIXED is mostly use for SIOCGIWFREQ, when
> getting. It tells you if the frequency was set by the user or
> automatically picked as the result of scanning.
Ah, but in which case is it set by the user? And is that 'fixed' then?
> I don't think any driver/hardware has the ability to set the
> frequency to auto, so IW_FREQ_FIXED is the default.
What would 'auto' be?
> It's because softmac only implements managed mode.
We might do some sort of ad-hoc client-only with Pete's patch, but we'll
never do master or wds I think.
> I've heard the call, I'll try to find some time for that.
Oh I was more thinking that I myself could add it somewhere after all
our discussion. If you do that, even better, but with the things we have
discussed already I can definitely help out.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]
^ permalink raw reply
* Re: [PATCH][RFC] Security marking
From: James Morris @ 2006-04-17 18:43 UTC (permalink / raw)
To: Patrick McHardy; +Cc: netdev, David S. Miller, Stephen Smalley, Chris Wright
In-Reply-To: <4443D5BA.6060605@trash.net>
On Mon, 17 Apr 2006, Patrick McHardy wrote:
> >From a pure netfilter POV it would still be nice to have the socket
> hooks for userspace queueing in socket context and filtering hard
> to track protocols. My only question is: if I would port the skfilter
> patches to the current kernel today and fix the unresolved issues,
> would you still prefer this approach?
I think the newer model of marking the packets first via Netfilter then
interpreting them at the socket layer is superior. i.e. skfilter is
probably not preferred for SELinux now.
However, it's still useful for incoming user matching for things like
user-level firewalling.
- James
--
James Morris
<jmorris@namei.org>
^ permalink raw reply
* Re: [PATCH][RFC] Security marking
From: edwin @ 2006-04-17 18:40 UTC (permalink / raw)
To: jmorris; +Cc: netdev, fireflier-devel
Secmark, or skfilter is exactly what fireflier needs to solve the shared socket issue. Thanks for working on this.
If this gets integrated in mainline, fireflier LSM will be dropped.
Is it possible to have an SELinux policy that reinjects the packets if didn't match any rules?
I.e. if a program that listens on port 80 doesn't have access to the packet, (because it doesn't have the proper domain,)
and the SELinux won't allow the program to read the packet: is it possible to reinject this packet in the netfilter chain,
instead of dropping it?
This would allow creating rules interactively (fireflier).
But it could also be used for other purposes.
For example: if the program that listens on that port crashes, that means no program would match the required domain+port.
if in that case the packet would be reinjected, then the packet could be rerouted (by adding proper rules to mangle the packet)
to a different program/computer. AFAIK this isn't currently possible with netfilter (please correct me if I'm wrong).
What does the secmark currently do with packets that aren't allowed by policy to be received?
P.S.: Where can I get the full secmark patches, so I can test them to see if they really fit my needs?
Do you have an estimate timeline for mainline integration? (in terms of n weeks, m months)
Cheers,
Edwin
^ permalink raw reply
* Re: kernel panic (on DHCP discover?) in sky2 driver of 2.6.17-rc1
From: Stephen Hemminger @ 2006-04-17 18:18 UTC (permalink / raw)
To: Guenther Thomsen; +Cc: John W. Linville, netdev
In-Reply-To: <200604121526.51405.gthomsen@bluearc.com>
I don't know what you are doing different, but my 2 port SysKonnect card
is working fine. Running SMP AMD64 and 2.6.17 latest.
Showing full speed on both ports.
^ permalink raw reply
* Re: [RFC] Geographical/regulatory information for ieee80211
From: Rick Jones @ 2006-04-17 17:55 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: Larry Finger, netdev, jeffl
In-Reply-To: <20060415174734.GA10595@infradead.org>
Christoph Hellwig wrote:
> On Thu, Apr 13, 2006 at 07:59:21PM -0500, Larry Finger wrote:
>
>>I am planning on writing a new routine to be added to
>>net/ieee80211/ieee80211_geo.c that will populate an ieee80211_geo object
>>given a country code. The new routine will eliminate the need for each
>>driver to do their own.
>
>
> This sounds like a generally good idea, but the question is: do we want
> this inside a kernel module or in userspace, either like the regulartory
> daemon intel has (unfortunately in binary only form) or as a simple init
> script. I really don't want to recompile my kernel just because regulations
> changed, and they seems to do that quite often.
Yet I would expect the regulatory bodies to look less favorably on
something more easily maleable by the end-user.
rick jones
^ permalink raw reply
* Re: [PATCH][RFC] Security marking
From: Patrick McHardy @ 2006-04-17 17:51 UTC (permalink / raw)
To: James Morris; +Cc: netdev, David S. Miller, Stephen Smalley, Chris Wright
In-Reply-To: <Pine.LNX.4.64.0604160012500.16600@d.namei>
James Morris wrote:
> Last year, I posted a set of patches to allow iptables matching against
> associated processes for incoming packets. With this patch, I'm proposing
> a much simpler alternative and solictiting feedback on the idea from other
> networking developers.
>
> For the original patches and discussion, see:
> http://marc.theaimsgroup.com/?l=linux-netdev&m=113027175208707&w=2
> and
> http://people.redhat.com/jmorris/selinux/skfilter/
>
> The purpose of the patches was to allow incoming owner matching to work
> cleanly, as well as allow integration of SELinux and Netfilter apps
> (iptables, conntrack etc). This would also allow the existing SELinux
> networking hooks to be replaced in a more powerful and expressive way.
>
> The skfilter patches posted are quite invasive, and probably require
> moving all Netfilter 'input' processing to the socket layer, with several
> unresolved issues.
Moving the netfilter input processing to the socket layer would actually
be a nice solution in my opinion, but its unfortunately not possible
without changing user-visible behaviour. SNAT is performed in LOCAL_IN
before filtering, but we need the already SNATed packet for the
socket lookup. So I concluded that the only possibility is to keep the
existing hooks and have a seperate skfilter INPUT chain. The conntrack
confirmation problem can be solved by registering the ip_confirm hook
with the socket hooks when they are compiled in.
>From a pure netfilter POV it would still be nice to have the socket
hooks for userspace queueing in socket context and filtering hard
to track protocols. My only question is: if I would port the skfilter
patches to the current kernel today and fix the unresolved issues,
would you still prefer this approach?
^ permalink raw reply
* Re: want to randomly drop packets based on percent
From: Stephen Hemminger @ 2006-04-17 17:32 UTC (permalink / raw)
To: George Nychis; +Cc: linux-kernel, netdev
In-Reply-To: <4443CAD1.9050701@cmu.edu>
O
> >>>>I wanted to insert artificial packet loss based on a percent so i found:
> >>>>network emulab qdisc could do it, so i compiled support into the kernel
> >>>>and tried:
> >>>>tc qdisc change dev eth0 root netem loss .1%
> >>>>
> >>>>
> > ^^^^^^
> >
> >You need to do add not change. Add will set the queue discipline
> >to netem (default is pfifo_fast). Change is for changing netem parameters
> >after it is loaded.
> >
> >
> >
> bahhh I see... the wiki has "change" instead of add. Now i'm running
> into another problem, I have an XCP qdisc that I have already added via:
> tc qdisc add dev ath0 root xcp capacity 54Mbit size 500
>
Wiki reads as a set of examples. First uses, "add" after that "change".
> therefore when I also try to incorperate loss:
> tcq disc add dev ath0 root netem loss .1%
>
> I get:
> RTNETLINK answers: File exists
>
> Is it possible to use two qdiscs on the same interface?
>
No, but netem is "classful" so you can put xcp inside netem.
Look at the token bucket example on the wiki.
^ permalink raw reply
* Re: [PATCH][RFC] softmac: suggest TX rate
From: Daniel Drake @ 2006-04-17 17:43 UTC (permalink / raw)
To: Johannes Berg; +Cc: netdev, softmac-dev, Ulrich Kunitz
In-Reply-To: <1145265385.6560.48.camel@localhost>
[-- Attachment #1: Type: text/plain, Size: 270 bytes --]
Johannes Berg wrote:
> Couldn't we just initialise the softmac txrates substructure to
> something useful when associating, and have drivers look into that
> instead?
How about this?
It also addresses the fact that multicast data must be transmitted at a
basic rate.
[-- Attachment #2: patch --]
[-- Type: text/plain, Size: 10882 bytes --]
--- linux/include/net/ieee80211softmac.h.orig 2006-04-16 23:37:32.000000000 +0100
+++ linux/include/net/ieee80211softmac.h 2006-04-17 18:40:04.000000000 +0100
@@ -86,6 +86,9 @@ struct ieee80211softmac_assoc_info {
/* BSSID we're trying to associate to */
char bssid[ETH_ALEN];
+
+ /* Rates supported by the network */
+ struct ieee80211softmac_ratesinfo supported_rates;
/* some flags.
* static_essid is valid if the essid is constant,
@@ -133,12 +136,23 @@ struct ieee80211softmac_txrates {
* (If the device supports fallback and hardware-retry)
*/
u8 mcast_fallback;
+
+ /* The Bit-Rate to be used for multicast management frames. */
+ u8 mgt_mcast_rate;
+ /* The Bit-Rate to be used for multicast management fallback
+ * (If the device supports fallback and hardware-retry)
+ */
+ u8 mgt_mcast_fallback;
+
/* The Bit-Rate to be used for any other (normal) data packet. */
u8 default_rate;
/* The Bit-Rate to be used for default fallback
* (If the device supports fallback and hardware-retry)
*/
u8 default_fallback;
+
+ /* This is the rate that the user asked for */
+ u8 user_rate;
};
/* Bits for txrates_change callback. */
@@ -146,6 +160,8 @@ struct ieee80211softmac_txrates {
#define IEEE80211SOFTMAC_TXRATECHG_DEFAULT_FBACK (1 << 1) /* default_fallback */
#define IEEE80211SOFTMAC_TXRATECHG_MCAST (1 << 2) /* mcast_rate */
#define IEEE80211SOFTMAC_TXRATECHG_MCAST_FBACK (1 << 3) /* mcast_fallback */
+#define IEEE80211SOFTMAC_TXRATECHG_MGT_MCAST (1 << 4) /* mgt_mcast_rate */
+#define IEEE80211SOFTMAC_TXRATECHG_MGT_MCAST_FBACK (1 << 5) /* mgt_mcast_fallback */
struct ieee80211softmac_device {
/* 802.11 structure for data stuff */
@@ -246,6 +262,28 @@ extern void ieee80211softmac_fragment_lo
* Note that the rates need to be sorted. */
extern void ieee80211softmac_set_rates(struct net_device *dev, u8 count, u8 *rates);
+/* Helper function which advises you the rate at which a frame should be
+ * transmitted at. */
+static inline u8 ieee80211softmac_suggest_txrate(struct ieee80211softmac_device *mac,
+ int is_multicast,
+ int is_mgt)
+{
+ struct ieee80211softmac_txrates *txrates = &mac->txrates;
+
+ if (!mac->associated)
+ return txrates->mgt_mcast_rate;
+
+ /* We are associated, sending unicast frame */
+ if (!is_multicast)
+ return txrates->default_rate;
+
+ /* We are associated, sending multicast frame */
+ if (is_mgt)
+ return txrates->mgt_mcast_rate;
+ else
+ return txrates->mcast_rate;
+}
+
/* Start the SoftMAC. Call this after you initialized the device
* and it is ready to run.
*/
--- linux/net/ieee80211/softmac/ieee80211softmac_module.c.orig 2006-04-17 01:04:42.000000000 +0100
+++ linux/net/ieee80211/softmac/ieee80211softmac_module.c 2006-04-17 18:30:04.000000000 +0100
@@ -26,6 +26,7 @@
#include "ieee80211softmac_priv.h"
#include <linux/sort.h>
+#include <linux/etherdevice.h>
struct net_device *alloc_ieee80211softmac(int sizeof_priv)
{
@@ -166,15 +167,85 @@ static void ieee80211softmac_start_check
}
}
-void ieee80211softmac_start(struct net_device *dev)
+int ieee80211softmac_ratesinfo_rate_supported(struct ieee80211softmac_ratesinfo *ri, u8 rate)
+{
+ int search;
+ u8 search_rate;
+
+ for (search = 0; search < ri->count; search++) {
+ search_rate = ri->rates[search];
+ search_rate &= ~IEEE80211_BASIC_RATE_MASK;
+ if (rate == search_rate)
+ return 1;
+ }
+
+ return 0;
+}
+
+/* Finds the highest rate which is:
+ * 1. Present in ri (optionally a basic rate)
+ * 2. Supported by the device
+ * 3. Less than or equal to the user-defined rate
+ */
+static u8 highest_supported_rate(struct ieee80211softmac_device *mac,
+ struct ieee80211softmac_ratesinfo *ri, int basic_only)
+{
+ u8 user_rate = mac->txrates.user_rate;
+ int i;
+
+ if (ri->count == 0) {
+ dprintk(KERN_ERROR PFX "empty ratesinfo?\n");
+ return IEEE80211_CCK_RATE_1MB;
+ }
+
+ for (i = ri->count - 1; i >= 0; i--) {
+ u8 rate = ri->rates[i];
+ if (basic_only && !(rate & IEEE80211_BASIC_RATE_MASK))
+ continue;
+ rate &= ~IEEE80211_BASIC_RATE_MASK;
+ if (rate > user_rate)
+ continue;
+ if (ieee80211softmac_ratesinfo_rate_supported(&mac->ratesinfo, rate))
+ return rate;
+ }
+
+ /* If we haven't found a suitable rate by now, just trust the user */
+ return user_rate;
+}
+
+void ieee80211softmac_recalc_txrates(struct ieee80211softmac_device *mac)
+{
+ struct ieee80211softmac_txrates *txrates = &mac->txrates;
+ struct ieee80211softmac_txrates oldrates;
+ u32 change = 0;
+
+ if (mac->txrates_change)
+ oldrates = mac->txrates;
+
+ change |= IEEE80211SOFTMAC_TXRATECHG_DEFAULT;
+ txrates->default_rate = highest_supported_rate(mac, &mac->associnfo.supported_rates, 0);
+
+ change |= IEEE80211SOFTMAC_TXRATECHG_DEFAULT_FBACK;
+ txrates->default_fallback = lower_rate(mac, txrates->default_rate);
+
+ change |= IEEE80211SOFTMAC_TXRATECHG_MCAST;
+ txrates->mcast_rate = highest_supported_rate(mac, &mac->associnfo.supported_rates, 1);
+
+ change |= IEEE80211SOFTMAC_TXRATECHG_MGT_MCAST_FBACK;
+ txrates->mcast_fallback = lower_rate(mac, txrates->mcast_rate);
+
+ if (mac->txrates_change)
+ mac->txrates_change(mac->dev, change, &oldrates);
+
+}
+
+void ieee80211softmac_init_txrates(struct ieee80211softmac_device *mac)
{
- struct ieee80211softmac_device *mac = ieee80211_priv(dev);
struct ieee80211_device *ieee = mac->ieee;
u32 change = 0;
+ struct ieee80211softmac_txrates *txrates = &mac->txrates;
struct ieee80211softmac_txrates oldrates;
- ieee80211softmac_start_check_rates(mac);
-
/* TODO: We need some kind of state machine to lower the default rates
* if we loose too many packets.
*/
@@ -189,19 +260,40 @@ void ieee80211softmac_start(struct net_d
more reliable. Note similar logic in
ieee80211softmac_wx_set_rate() */
if (ieee->modulation & IEEE80211_CCK_MODULATION) {
- mac->txrates.default_rate = IEEE80211_CCK_RATE_11MB;
- change |= IEEE80211SOFTMAC_TXRATECHG_DEFAULT;
- mac->txrates.default_fallback = IEEE80211_CCK_RATE_5MB;
- change |= IEEE80211SOFTMAC_TXRATECHG_DEFAULT_FBACK;
+ txrates->user_rate = IEEE80211_CCK_RATE_11MB;
} else if (ieee->modulation & IEEE80211_OFDM_MODULATION) {
- mac->txrates.default_rate = IEEE80211_OFDM_RATE_54MB;
- change |= IEEE80211SOFTMAC_TXRATECHG_DEFAULT;
- mac->txrates.default_fallback = IEEE80211_OFDM_RATE_24MB;
- change |= IEEE80211SOFTMAC_TXRATECHG_DEFAULT_FBACK;
+ txrates->user_rate = IEEE80211_OFDM_RATE_54MB;
} else
assert(0);
+
+ txrates->default_rate = IEEE80211_CCK_RATE_1MB;
+ change |= IEEE80211SOFTMAC_TXRATECHG_DEFAULT;
+
+ txrates->default_fallback = IEEE80211_CCK_RATE_1MB;
+ change |= IEEE80211SOFTMAC_TXRATECHG_DEFAULT_FBACK;
+
+ txrates->mcast_rate = IEEE80211_CCK_RATE_1MB;
+ change |= IEEE80211SOFTMAC_TXRATECHG_MCAST;
+
+ txrates->mcast_fallback = IEEE80211_CCK_RATE_1MB;
+ change |= IEEE80211SOFTMAC_TXRATECHG_MCAST_FBACK;
+
+ txrates->mgt_mcast_rate = IEEE80211_CCK_RATE_1MB;
+ change |= IEEE80211SOFTMAC_TXRATECHG_MGT_MCAST;
+
+ txrates->mgt_mcast_fallback = IEEE80211_CCK_RATE_1MB;
+ change |= IEEE80211SOFTMAC_TXRATECHG_MGT_MCAST_FBACK;
+
if (mac->txrates_change)
- mac->txrates_change(dev, change, &oldrates);
+ mac->txrates_change(mac->dev, change, &oldrates);
+}
+
+void ieee80211softmac_start(struct net_device *dev)
+{
+ struct ieee80211softmac_device *mac = ieee80211_priv(dev);
+
+ ieee80211softmac_start_check_rates(mac);
+ ieee80211softmac_init_txrates(mac);
}
EXPORT_SYMBOL_GPL(ieee80211softmac_start);
--- linux/net/ieee80211/softmac/ieee80211softmac_assoc.c.orig 2006-04-16 23:55:23.000000000 +0100
+++ linux/net/ieee80211/softmac/ieee80211softmac_assoc.c 2006-04-17 17:17:59.000000000 +0100
@@ -101,30 +101,22 @@ ieee80211softmac_disassoc(struct ieee802
/* Do NOT clear bssvalid as that will break ieee80211softmac_assoc_work! */
mac->associated = 0;
mac->associnfo.associating = 0;
+ ieee80211softmac_init_txrates(mac);
spin_unlock_irqrestore(&mac->lock, flags);
}
static inline int
we_support_all_basic_rates(struct ieee80211softmac_device *mac, u8 *from, u8 from_len)
{
- int idx, search, found;
- u8 rate, search_rate;
+ int idx;
+ u8 rate;
for (idx = 0; idx < (from_len); idx++) {
rate = (from)[idx];
if (!(rate & IEEE80211_BASIC_RATE_MASK))
continue;
- found = 0;
rate &= ~IEEE80211_BASIC_RATE_MASK;
- for (search = 0; search < mac->ratesinfo.count; search++) {
- search_rate = mac->ratesinfo.rates[search];
- search_rate &= ~IEEE80211_BASIC_RATE_MASK;
- if (rate == search_rate) {
- found = 1;
- break;
- }
- }
- if (!found)
+ if (!ieee80211softmac_ratesinfo_rate_supported(&mac->ratesinfo, rate))
return 0;
}
return 1;
@@ -283,6 +275,9 @@ ieee80211softmac_associated(struct ieee8
struct ieee80211softmac_network *net)
{
mac->associnfo.associating = 0;
+ mac->associnfo.supported_rates = net->supported_rates;
+ ieee80211softmac_recalc_txrates(mac);
+
mac->associated = 1;
if (mac->set_bssid_filter)
mac->set_bssid_filter(mac->dev, net->bssid);
@@ -373,6 +368,7 @@ ieee80211softmac_handle_disassoc(struct
spin_lock_irqsave(&mac->lock, flags);
mac->associnfo.bssvalid = 0;
mac->associated = 0;
+ ieee80211softmac_init_txrates(mac);
schedule_work(&mac->associnfo.work);
spin_unlock_irqrestore(&mac->lock, flags);
--- linux/net/ieee80211/softmac/ieee80211softmac_wx.c.orig 2006-04-17 16:45:51.000000000 +0100
+++ linux/net/ieee80211/softmac/ieee80211softmac_wx.c 2006-04-17 17:27:47.000000000 +0100
@@ -201,8 +201,8 @@ ieee80211softmac_wx_set_rate(struct net_
if (is_ofdm && !(ieee->modulation & IEEE80211_OFDM_MODULATION))
goto out_unlock;
- mac->txrates.default_rate = rate;
- mac->txrates.default_fallback = lower_rate(mac, rate);
+ mac->txrates.user_rate = rate;
+ ieee80211softmac_recalc_txrates(mac);
err = 0;
out_unlock:
@@ -223,7 +223,7 @@ ieee80211softmac_wx_get_rate(struct net_
int err = -EINVAL;
spin_lock_irqsave(&mac->lock, flags);
- switch (mac->txrates.default_rate) {
+ switch (mac->txrates.user_rate) {
case IEEE80211_CCK_RATE_1MB:
data->bitrate.value = 1000000;
break;
--- linux/net/ieee80211/softmac/ieee80211softmac_priv.h.orig 2006-04-17 16:46:09.000000000 +0100
+++ linux/net/ieee80211/softmac/ieee80211softmac_priv.h 2006-04-17 17:09:08.000000000 +0100
@@ -116,7 +116,10 @@ ieee80211softmac_get_network_by_essid(st
struct ieee80211softmac_essid *essid);
/* Rates related */
+int ieee80211softmac_ratesinfo_rate_supported(struct ieee80211softmac_ratesinfo *ri, u8 rate);
u8 ieee80211softmac_lower_rate_delta(struct ieee80211softmac_device *mac, u8 rate, int delta);
+void ieee80211softmac_init_txrates(struct ieee80211softmac_device *mac);
+void ieee80211softmac_recalc_txrates(struct ieee80211softmac_device *mac);
static inline u8 lower_rate(struct ieee80211softmac_device *mac, u8 rate) {
return ieee80211softmac_lower_rate_delta(mac, rate, 1);
}
^ permalink raw reply
* Re: want to randomly drop packets based on percent
From: George Nychis @ 2006-04-17 17:05 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: linux-kernel, netdev
In-Reply-To: <20060417094634.7191fea5@localhost.localdomain>
Stephen Hemminger wrote:
>On Mon, 17 Apr 2006 18:30:51 -0400
>George Nychis <gnychis@cmu.edu> wrote:
>
>
>
>>Stephen Hemminger wrote:
>>
>>
>>
>>>On Mon, 17 Apr 2006 03:38:33 -0400
>>>George Nychis <gnychis@cmu.edu> wrote:
>>>
>>>
>>>
>>>
>>>
>>>>Hey,
>>>>
>>>>I'm using the 2.4.32 kernel with madwifi and iproute2 version
>>>>2-2.6.16-060323.tar.gz
>>>>
>>>>I wanted to insert artificial packet loss based on a percent so i found:
>>>>network emulab qdisc could do it, so i compiled support into the kernel
>>>>and tried:
>>>>tc qdisc change dev eth0 root netem loss .1%
>>>>
>>>>
> ^^^^^^
>
>You need to do add not change. Add will set the queue discipline
>to netem (default is pfifo_fast). Change is for changing netem parameters
>after it is loaded.
>
>
>
bahhh I see... the wiki has "change" instead of add. Now i'm running
into another problem, I have an XCP qdisc that I have already added via:
tc qdisc add dev ath0 root xcp capacity 54Mbit size 500
therefore when I also try to incorperate loss:
tcq disc add dev ath0 root netem loss .1%
I get:
RTNETLINK answers: File exists
Is it possible to use two qdiscs on the same interface?
Thanks!
George
^ permalink raw reply
* Re: [PATCH-2.6] e1000: fix media_type <-> phy_type thinko
From: Jesse Brandeburg @ 2006-04-17 16:51 UTC (permalink / raw)
To: Willy TARREAU, jgarzik; +Cc: jesse.brandeburg, netdev, linux-kernel, rol
In-Reply-To: <20060415110025.GA6266@w.ods.org>
On Sat, 15 Apr 2006, Willy TARREAU wrote:
> Recent patch cb764326dff0ee51aca0d450e1a292de65661055 introduced
> a thinko in e1000_main.c : e1000_media_type_copper is compared
> to hw.phy_type instead of hw.media_type. Original patch proposed
> by Jesse Brandeburg was correct, but what has been merged is not.
Yes, this fix makes the code how it should have been.
Ack.
Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
---
drivers/net/e1000/e1000_main.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
3df8a180d50c89a72c28abf37151e38ffda75f39
diff --git a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c
index add8dc4..590a456 100644
--- a/drivers/net/e1000/e1000_main.c
+++ b/drivers/net/e1000/e1000_main.c
@@ -4156,7 +4156,7 @@ e1000_mii_ioctl(struct net_device *netde
spin_unlock_irqrestore(&adapter->stats_lock, flags);
return -EIO;
}
- if (adapter->hw.phy_type == e1000_media_type_copper) {
+ if (adapter->hw.media_type == e1000_media_type_copper) {
switch (data->reg_num) {
case PHY_CTRL:
if (mii_reg & MII_CR_POWER_DOWN)
--
1.2.4
^ permalink raw reply related
* Re: want to randomly drop packets based on percent
From: Stephen Hemminger @ 2006-04-17 16:46 UTC (permalink / raw)
To: George Nychis; +Cc: linux-kernel, netdev, matt.keenan
In-Reply-To: <4444171B.90507@cmu.edu>
On Mon, 17 Apr 2006 18:30:51 -0400
George Nychis <gnychis@cmu.edu> wrote:
>
>
> Stephen Hemminger wrote:
>
> >On Mon, 17 Apr 2006 03:38:33 -0400
> >George Nychis <gnychis@cmu.edu> wrote:
> >
> >
> >
> >>Hey,
> >>
> >>I'm using the 2.4.32 kernel with madwifi and iproute2 version
> >>2-2.6.16-060323.tar.gz
> >>
> >>I wanted to insert artificial packet loss based on a percent so i found:
> >>network emulab qdisc could do it, so i compiled support into the kernel
> >>and tried:
> >>tc qdisc change dev eth0 root netem loss .1%
^^^^^^
You need to do add not change. Add will set the queue discipline
to netem (default is pfifo_fast). Change is for changing netem parameters
after it is loaded.
^ permalink raw reply
* Re: [PATCH] Fix crash on big-endian systems during scan
From: John W. Linville @ 2006-04-17 16:44 UTC (permalink / raw)
To: Dan Williams; +Cc: netdev, hostap, Pavel Roskin
In-Reply-To: <1145288203.2649.3.camel@localhost.localdomain>
On Mon, Apr 17, 2006 at 11:36:43AM -0400, Dan Williams wrote:
> On Mon, 2006-04-17 at 11:17 -0400, John W. Linville wrote:
> > On Mon, Apr 17, 2006 at 11:01:29AM -0400, Dan Williams wrote:
> > > On Mon, 2006-04-17 at 10:45 -0400, John W. Linville wrote:
> > > > On Mon, Apr 17, 2006 at 10:34:03AM -0400, Dan Williams wrote:
> > > >
> > > > > Pavel posted to netdev originally on Friday April 14th with the patch
> > > > > included in the email, with the title "[PATCH] Fix crash on big-endian
> > > > > systems during scan"...
> > > > >
> > > > > http://www.spinics.net/lists/netdev/msg03023.html
> > > > >
> > > > > Sure you don't have it somewhere? If not, I'm sure somebody can
> > > > > resend...
> > > >
> > > > I must have fat-fingered a delete...sorry!
> > > >
> > > > A repost would be most welcome...
> > >
> > > I think Pavel just resent the patch with a "(repost)" at the end of the
> > > subject line.
> >
> > Hmmm...Randy Dunlap said offline that he had reposted, but I haven't
> > seen one from him either...is it a big patch?
>
> Two liner...
>
> From: Pavel Roskin <proski@gnu.org>
>
> The original code was doing arithmetics on a little-endian value.
> Reported by Stelios Koroneos <stelios@stelioscellar.com>
>
> Signed-off-by: Pavel Roskin <proski@gnu.org>
> ---
Got this one...thanks!
--
John W. Linville
linville@tuxdriver.com
^ permalink raw reply
* Re: softmac: semantics of SIOCSIWFREQ
From: Jean Tourrilhes @ 2006-04-17 16:37 UTC (permalink / raw)
To: Johannes Berg; +Cc: netdev, softmac-dev
In-Reply-To: <1145190888.6560.22.camel@localhost>
On Sun, Apr 16, 2006 at 02:34:48PM +0200, Johannes Berg wrote:
> [breaking out to a new thread so discussion on this doesn't get too
> hidden, CC Jean since he designed this]
>
> > - Is SIOCSIWFREQ allowed while associated?
>
> No idea.
Usually no, but...
If you are in managed mode, SIOCSIWFREQ usually should return
an error, because it is not allowed.
If you are in ad-hoc mode, SIOCSIWFREQ is used if a IBSS needs
to be created. After scanning is done, if you did not find any
network, you will create your own, and you will use the frequency that
was set. You should never return an error.
If you are in Master mode... Well, this case is obvious ;-)
> > - If the flag IW_FREQ_FIXED is set, should all activitity
> > including scanning only be allowed on this frequency? (Actually
> > a better would even be to work with channel/frequency sets.
> > These sets would make a lot of sense for parallel scanning
> > whith more than one device.)
>
> Yeah, but that's impossible to code on top of the current wext
> structures I'd say.
The struct iw_scan_req has all the goodies you need to control
scanning.
The IW_FREQ_FIXED is mostly use for SIOCGIWFREQ, when
getting. It tells you if the frequency was set by the user or
automatically picked as the result of scanning.
I don't think any driver/hardware has the ability to set the
frequency to auto, so IW_FREQ_FIXED is the default.
> > - Is there any use of the control, if the frequency is not fixed?
>
> Good question :)
In managed mode, no.
> > SIOCSIWFREQ and SIOCGIWFREQ appear to be good candidates to be
> > included in the softmac. If I would have a rough idea, what the
> > semantics should be, I would even volunteer to implement it.
>
> Yes, they definitely could/should be moved into softmac, but when
> writing softmac I had no real incentive to do it because I didn't want
> to dig up the info for all the above points :)
It's because softmac only implements managed mode.
> I was thinking of adding all the 'what is this ioctl supposed to do'
> things we came up with to the softmac or netdev wiki. Would that be
> good/useful, or should we just put it into that driver writers guide?
I've heard the call, I'll try to find some time for that.
> johannes
Jean
^ permalink raw reply
* Re: [PATCH 12/18] ipw2200: version string rework
From: Stephen Hemminger @ 2006-04-17 16:37 UTC (permalink / raw)
To: James Ketrenos; +Cc: yi.zhu, netdev, John W. Linville
In-Reply-To: <4443C2EE.6030302@linux.intel.com>
On Mon, 17 Apr 2006 11:31:42 -0500
James Ketrenos <jketreno@linux.intel.com> wrote:
> Stephen Hemminger wrote:
> > On Thu, 13 Apr 2006 17:20:34 +0800
> > Zhu Yi <yi.zhu@intel.com> wrote:
> >
> >
> >>Added version string fields so the version string indicates what is
> >>configured (ie, you'll see 1.1.1kpmd if you are using a GIT snapshot
> >>(Kernel.. previously -git), promiscuous (p), monitor (m), debug (d) build.
> >
> >
> > No, this is completely the wrong direction.
> >
> > Stop with the config option nonsense. It makes it impossible for linux distributions
> > and others that want to ship one kernel and modules.
>
> How does it make it impossible for someone to ship one kernel?
>
> There are are various configuration options to enable, some of which are
> experimental and/or unstable, some add code and/or impact performance
> when enabled, etc. Not all users want all features.
>
> Easily determining what is enabled in the driver is a requirement.
>
> The distributors should default to not enabling any feature that does
> not default to =y or =m in Kconfig. In the default configuration, there
> shouldn't be any post-fix fields appended to the version string. If
> there is, we need to either fix the version string or the default
> Kconfig setting.
>
> Is there an alternative method for quickly and easily determining what
> all features are enabled in a module--even if the module isn't loaded?
> We didn't see one, and using the fields post-fixed to the version string
> has quickly resolved various support issues.
>
> Thanks,
> James
The version string is good idea, it is just the NxM complexity of possibilities
that gets nasty. Also, is this a permanent fixture of these drivers, or just
some transitional stage as new features get added that aren't stable yet?
^ permalink raw reply
* Re: want to randomly drop packets based on percent
From: George Nychis @ 2006-04-17 22:30 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: linux-kernel, netdev, matt.keenan
In-Reply-To: <20060417091915.67e28361@localhost.localdomain>
Stephen Hemminger wrote:
>On Mon, 17 Apr 2006 03:38:33 -0400
>George Nychis <gnychis@cmu.edu> wrote:
>
>
>
>>Hey,
>>
>>I'm using the 2.4.32 kernel with madwifi and iproute2 version
>>2-2.6.16-060323.tar.gz
>>
>>I wanted to insert artificial packet loss based on a percent so i found:
>>network emulab qdisc could do it, so i compiled support into the kernel
>>and tried:
>>tc qdisc change dev eth0 root netem loss .1%
>>
>>
>
>Most likely, you the version of the kernel you are running was not
>configured with netem enabled.
>
>
>
Hey Stephen,
I have netem enabled in the kernel... I've checked this numerous times.
I enabled it under Networking Options -> QoS -> Network emulator. I
even did a make clean, make mrproper, and rebuilt from scratch.
Maybe I'll try compiling it as a module and see if anything changes.
Any other ideas?
----
In response to Matt:
Thank you!
One last question, if I take this route, what is the easiest way to
allow me to change the packet loss without hard coding a percent into
the kernel?
^ permalink raw reply
* Re: [PATCH 12/18] ipw2200: version string rework
From: James Ketrenos @ 2006-04-17 16:31 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: yi.zhu, netdev, John W. Linville
In-Reply-To: <20060413102820.4fabf028@localhost.localdomain>
Stephen Hemminger wrote:
> On Thu, 13 Apr 2006 17:20:34 +0800
> Zhu Yi <yi.zhu@intel.com> wrote:
>
>
>>Added version string fields so the version string indicates what is
>>configured (ie, you'll see 1.1.1kpmd if you are using a GIT snapshot
>>(Kernel.. previously -git), promiscuous (p), monitor (m), debug (d) build.
>
>
> No, this is completely the wrong direction.
>
> Stop with the config option nonsense. It makes it impossible for linux distributions
> and others that want to ship one kernel and modules.
How does it make it impossible for someone to ship one kernel?
There are are various configuration options to enable, some of which are
experimental and/or unstable, some add code and/or impact performance
when enabled, etc. Not all users want all features.
Easily determining what is enabled in the driver is a requirement.
The distributors should default to not enabling any feature that does
not default to =y or =m in Kconfig. In the default configuration, there
shouldn't be any post-fix fields appended to the version string. If
there is, we need to either fix the version string or the default
Kconfig setting.
Is there an alternative method for quickly and easily determining what
all features are enabled in a module--even if the module isn't loaded?
We didn't see one, and using the fields post-fixed to the version string
has quickly resolved various support issues.
Thanks,
James
^ permalink raw reply
* Re: [PATCH] ipw2100: wraps the debug module param within #ifdefs
From: Stephen Hemminger @ 2006-04-17 16:24 UTC (permalink / raw)
To: Zhu Yi; +Cc: netdev, John W. Linville
In-Reply-To: <1145240263.968.203.camel@debian.sh.intel.com>
On Mon, 17 Apr 2006 10:17:43 +0800
Zhu Yi <yi.zhu@intel.com> wrote:
> On Fri, 2006-04-14 at 09:33 -0700, Stephen Hemminger wrote:
> > I meant get rid of CONFIG_IPW2200_DEBUG completely. Having the debug code isn't
> > bad, and there is no reason not to have it always there.
>
> There are lots of IPW_DEBUG_XXX in the driver, even in TX and RX paths.
> It cause extra cycles for those who really don't need it.
>
> Thanks,
> -yi
IMHO. There is never a reason for a driver specific config option for debugging.
Either it the debug option is generally useful for support (ie distro's will want it on),
in which case the debugging should be runtime settable but always available;
or the debug option is so meant for the driver developers in which case it should
be enabled by a source modification (see #define DEBUG and pr_debug).
But, those are opinions only and certainly, you can do what you want with your
driver.
^ permalink raw reply
* Re: want to randomly drop packets based on percent
From: Stephen Hemminger @ 2006-04-17 16:19 UTC (permalink / raw)
To: George Nychis; +Cc: linux-kernel, netdev
In-Reply-To: <444345F9.4090100@cmu.edu>
On Mon, 17 Apr 2006 03:38:33 -0400
George Nychis <gnychis@cmu.edu> wrote:
> Hey,
>
> I'm using the 2.4.32 kernel with madwifi and iproute2 version
> 2-2.6.16-060323.tar.gz
>
> I wanted to insert artificial packet loss based on a percent so i found:
> network emulab qdisc could do it, so i compiled support into the kernel
> and tried:
> tc qdisc change dev eth0 root netem loss .1%
Most likely, you the version of the kernel you are running was not
configured with netem enabled.
^ permalink raw reply
* Re: Kernel error
From: Stephen Hemminger @ 2006-04-17 16:12 UTC (permalink / raw)
To: Saurabh Jain; +Cc: netdev
In-Reply-To: <3a1eedb70604152343u2f720781o40fbd910f6558041@mail.gmail.com>
On Sun, 16 Apr 2006 01:43:08 -0500
"Saurabh Jain" <jassduec@gmail.com> wrote:
> Hi Guys,
>
> I am getting the following kernel error while doing some experiments.
> Any idea where things are going wrong. To me it looks like there is an
> error while copying data from user space to kernel space. The
> application which i am running is iperf. However i also have netem
> module for emulating some wide area network characteristics like
> delay. I am using delay of 100ms.
>
> ##################Error Message#############################
> Unable to handle kernel NULL pointer dereference at virtual address 00000004
> printing eip:
> c02fee3c
> *pde = 7ded4067
> Oops: 0002 [#5]
> Modules linked in: setparam(U) sch_netem(U) nfs(U) lockd(U) autofs4(U)
> sunrpc(U)CPU: 0
> EIP: 0060:[<c02fee3c>] Not tainted VLI
> EFLAGS: 00010286 (2.6.12-1.1390_FC4-emulab-1)
> EIP is at tcp_transmit_skb+0x3ef/0x8de
> eax: 00000000 ebx: f71a1a40 ecx: ed64f960 edx: ed64ff60
> esi: 00000000 edi: f2f98500 ebp: ed71b780 esp: f47bddd4
> ds: 007b es: 007b ss: 0068
> Process iperf (pid: 2443, threadinfo=f47bc000 task=f71a1a40)
> Stack: f2f9854c c02d1019 ed71b7b8 f2f98500 ed15cc80 00000282 ed71b780 00000100
> c02ce99f f71a1a40 f2f98500 f71a1a40 00000000 f2f98500 f2f9854c c02f53ad
> 00000000 ed335db8 f2f98500 f2f98500 f47bdeb8 00000000 00000000 002ce99f
> Call Trace:
> [<c02d1019>] skb_copy_datagram_iovec+0x180/0x1f8
> [<c02ce99f>] alloc_skb+0x31/0xc1
> [<c02f53ad>] tcp_recvmsg+0x2b1/0x74e
> [<c02fd83f>] tcp_rcv_established+0x5d2/0x77a
> [<c02ce2e0>] sock_common_recvmsg+0x41/0x57
> [<c02cb052>] sock_aio_read+0xf9/0x12b
> [<c014fccb>] do_sync_read+0x9e/0xec
> [<c01291ae>] autoremove_wake_function+0x0/0x37
> [<c014fe23>] vfs_read+0x10a/0x10e
> [<c0150064>] sys_read+0x41/0x6a
> [<c0102d29>] syscall_call+0x7/0xb
> Code: a1 04 07 39 c0 e8 c0 e5 e3 ff 89 c2 85 c0 74 2d 83 87 08 04 00 00 01 8b 8
> #############################################################
Please provide full info: kernel version and configuration as well
as hardware information (lspci).
Since it looks like a Fedora Core kernel, you may have to ask the fedora
list.
^ permalink raw reply
* Re: [PATCH] Fix crash on big-endian systems during scan
From: Dan Williams @ 2006-04-17 15:36 UTC (permalink / raw)
To: John W. Linville; +Cc: netdev, hostap, Pavel Roskin
In-Reply-To: <20060417151659.GL5042@tuxdriver.com>
On Mon, 2006-04-17 at 11:17 -0400, John W. Linville wrote:
> On Mon, Apr 17, 2006 at 11:01:29AM -0400, Dan Williams wrote:
> > On Mon, 2006-04-17 at 10:45 -0400, John W. Linville wrote:
> > > On Mon, Apr 17, 2006 at 10:34:03AM -0400, Dan Williams wrote:
> > >
> > > > Pavel posted to netdev originally on Friday April 14th with the patch
> > > > included in the email, with the title "[PATCH] Fix crash on big-endian
> > > > systems during scan"...
> > > >
> > > > http://www.spinics.net/lists/netdev/msg03023.html
> > > >
> > > > Sure you don't have it somewhere? If not, I'm sure somebody can
> > > > resend...
> > >
> > > I must have fat-fingered a delete...sorry!
> > >
> > > A repost would be most welcome...
> >
> > I think Pavel just resent the patch with a "(repost)" at the end of the
> > subject line.
>
> Hmmm...Randy Dunlap said offline that he had reposted, but I haven't
> seen one from him either...is it a big patch?
Two liner...
From: Pavel Roskin <proski@gnu.org>
The original code was doing arithmetics on a little-endian value.
Reported by Stelios Koroneos <stelios@stelioscellar.com>
Signed-off-by: Pavel Roskin <proski@gnu.org>
---
drivers/net/wireless/hostap/hostap_ioctl.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/hostap/hostap_ioctl.c b/drivers/net/wireless/hostap/hostap_ioctl.c
index 8b37e82..8399de5 100644
--- a/drivers/net/wireless/hostap/hostap_ioctl.c
+++ b/drivers/net/wireless/hostap/hostap_ioctl.c
@@ -1860,7 +1860,7 @@ static char * __prism2_translate_scan(lo
memset(&iwe, 0, sizeof(iwe));
iwe.cmd = SIOCGIWFREQ;
if (scan) {
- chan = scan->chid;
+ chan = le16_to_cpu(scan->chid);
} else if (bss) {
chan = bss->chan;
} else {
@@ -1868,7 +1868,7 @@ static char * __prism2_translate_scan(lo
}
if (chan > 0) {
- iwe.u.freq.m = freq_list[le16_to_cpu(chan - 1)] * 100000;
+ iwe.u.freq.m = freq_list[chan - 1] * 100000;
iwe.u.freq.e = 1;
current_ev = iwe_stream_add_event(current_ev, end_buf, &iwe,
IW_EV_FREQ_LEN);
^ permalink raw reply related
* Re: [1/1] netlink: fix broadcasting to the wrong group.
From: Patrick McHardy @ 2006-04-17 15:35 UTC (permalink / raw)
To: Evgeniy Polyakov; +Cc: David S. Miller, netdev
In-Reply-To: <20060417093632.GA29057@2ka.mipt.ru>
Evgeniy Polyakov wrote:
> When application is bound to group N and it is less than 32
> and has first bit set (I tested with 1, 3, 5) and kernel broadcasts
> events to group number 1, application will receive messages, even if
> 1. it was not subscribed to that group
> 2. it was bound to different group
>
> Attached trivial test module and userspace program.
> make
> insmod nltest.ko
> ./nluser -g5
>
> see the dmesg.
> Test module sends data to group number 1, but application is bound and
> subscribed to group 5, but still receives messages.
>
> This issue happens due to the following check in do_one_broadcast():
>
> if (nlk->pid == p->pid || p->group - 1 >= nlk->ngroups ||
> !test_bit(p->group - 1, nlk->groups))
>
> nlk->groups is set at bind time to the userspace provided bind group.
> So in above case it will be 5.
> But above test_bit() is supposed to check subscribed groups, which are
> set using set_bit(users_group - 1, nlk->groups).
> So when kernelspace broadcasts to group 1 above test_bit() returns true
> and message is delivered to the wrong socket.
>
> Attached patch removes nlk->groups[0] assignment at bind time since it
> is completely meaningless due to subscription introduction.
> nltest.c - simple test module which broadcasts events to group 1.
> nluser.c - userspace application which receives data from socket bound
> to specified group.
This seems to be a misunderstanding, subscribing to groups using bind()
is kept for compatibility and doesn't use group numbers but bitmasks.
^ 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