Re: bcm43xx-d80211 broadcast reception with WPA
On Sunday 12 November 2006 02:24, Paul TBBle Hampson wrote: > On Sat, Nov 11, 2006 at 04:07:05PM +0100, Michael Buesch wrote: > > Please _don't_ remove CCs. > > Sorry, I was sending via the gmane web interface, I guess it doesn't > honour CCs. > > This one's via muttng's NNTP support to gmane, so I _think_ it's going > to the right places. > > > On Saturday 11 November 2006 07:32, Paul Hampson wrote: > >> Michael Buesch bu3sch.de> writes: > > > >> On Thursday 09 November 2006 23:23, Paul Hampson wrote: > > > >> I've been backporting the bcm43xx-d80211 driver to whatever the > > > >> released > > > >> 2.6 kernel was using the rt2x00 project's d80211 stack (equivalent to > > > >> current wireless-dev but with a workaround for not having a > > > >> ieee80211_dev > > > >> pointer and still using the _tfm interface instead of the _cypher > > > >> interface.) > > > > >> As of last night's wireless-dev tree bcm43xx, everything seems to be > > > >> operating fine except incoming broadcast traffic is coming in 14 bytes > > > >> too > > > >> long and scrambled. I presume this means it's not decrypting > > > >> properly... > > > >> It sounds like a bug in the hardware decryption setup. > > >> Are you using TKIP or not? > > >> Yes, it's using TKIP. The router docs and the loading of the tkip module > >> when I use the softmac driver agree on this. > > > TKIP is still software encryption. Did you try with WPA-AES, for example, > > which is hardware encryption? > > The router here only supports TKIP that I can see. There's another > network I'll be on on Monday night which I might be able to throw into > WPA2 mode... In fact, I was there yesterday and couldn't even get a > DHCP IP address, but didn't have the time to diagnose it. TKIP hw encryption needs some modifications to the d80211 stack. There are patches available, but I think they are not merged, yet. John, do you know the state on these patches? > > The problem might be that the card tries to decrypt mcast > > frames in the crypto hardware, although we did not set a key. > > So it uses a random key to decrypt. That obviously results in crap. > > Eww, yuck. Ah, and also note that you _need_ firmware from a v4 binary driver to have hardware encryption with bcm43xx. -- Greetings Michael. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-usb-devel] drivers/usb/gadget/ether.c: NULL dereference
On Sat, Nov 11, 2006 at 11:10:17PM -0800, David Brownell wrote:
>
> >
> > void dev_kfree_skb_any(struct sk_buff *skb)
> > {
> > if (in_irq() || irqs_disabled())
> > dev_kfree_skb_irq(skb);
> > else
> > dev_kfree_skb(skb);
> > }
> >
> >
> > And the first thing dev_kfree_skb_irq() does is to dereference skb...
>
> Yet dev_kfree_skb() --> kfree_skb() starts with the standard idiom
>
> if (unlikely(!skb))
> return
>
> Seems to me that the finger of blame is more appropriately pointed
> at either dev_kfree_skb_any() or dev_kfree_skb_irq() ...
>...
Adding the net maintainers to the Cc:
Is there any reason why dev_kfree_skb_irq() has no NULL check for "skb"?
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
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
airo driver: still can't deal with interface renames?
A long time ago, in kernel-2.4 days, I noticed that airo module (for various aironet etc cards) can't handle interface renames (at that time, the kernel crashed after `ip link set eth1 name xxx' command and some packets going to/from the interface). The problem seems to be that the driver uses some sort of private data in /proc/driver/airo/ethN/ which gets created when the driver discovers an interface and names it as usual, giving next available N in ethN scheme. And currently (2.6.18) the situation is still similar. Well, it does not crashes, but still keeps the directory in /proc/driver/airo named after the automatic interface name, which leads to confusion at least, especially if i load airo.ko, rename the iface, and next load some other network driver module, which grabs THE SAME ethN as was first grabbed by airo. The fix seems to be to follow interface renames with name change in /proc/driver/airo/. Or, better longterm but leads to incompatibilities, switch to using sysfs interface, where the change will be made automagically. I don't understand all the driver internals to a level when I can fix the problem in the right way. But I can fix it with a hack, which seems to be simple enouth and will suit at least my needs: by introducing another array of charp for module parameters, giving the name(s) of interface(s) it should create, just like currently it accepts "ssids" and "rates" parameters. Can someone comment on the situation, please? Thanks. /mjt - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 1/9] bonding: lockdep annotation
David Miller wrote: From: Jeff Garzik <[EMAIL PROTECTED]> Date: Fri, 10 Nov 2006 11:09:25 -0500 [EMAIL PROTECTED] wrote: From: Peter Zijlstra <[EMAIL PROTECTED]> = [ INFO: possible recursive locking detected ] 2.6.17-1.2600.fc6 #1 - applied; please CC me on this drivers/net stuff Jeff, I put this one in my net-2.6.20 tree already. Well, it was drivers/net/bonding/* which usually goes in through my tree, what did you expect? :) Jeff - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[take4 1/5] d80211: remove bitfields from ieee80211_tx_control
All one-bit bitfields have been subsumed into the new 'flags'
structure member and the new IEEE80211_TXCTL_* definitions. The
multiple bit members were converted to u8, s8 or u16 as appropriate.
Signed-off-by: David Kimdon <[EMAIL PROTECTED]>
Index: wireless-dev/include/net/d80211.h
===
--- wireless-dev.orig/include/net/d80211.h
+++ wireless-dev/include/net/d80211.h
@@ -141,36 +141,38 @@ struct ieee80211_tx_control {
int rts_cts_rate; /* Transmit rate for RTS/CTS frame, given as the hw
* specific value for the rate (from
* struct ieee80211_rate) */
- /* 1 = only first attempt, 2 = one retry, .. */
- unsigned int retry_limit:8;
- /* duration field for RTS/CTS frame */
- unsigned int rts_cts_duration:16;
- unsigned int req_tx_status:1; /* request TX status callback for this
- * frame */
- unsigned int do_not_encrypt:1; /* send this frame without encryption;
- * e.g., for EAPOL frames */
- unsigned int use_rts_cts:1; /* Use RTS-CTS before sending frame. */
- unsigned int use_cts_protect:1; /* Use CTS protection for the frame
-* (e.g., for combined 802.11g /
-* 802.11b networks) */
-unsigned int no_ack:1; /* Tell the low level not to wait for an ack */
- unsigned int rate_ctrl_probe:1;
- unsigned int clear_dst_mask:1;
- unsigned int requeue:1;
- unsigned int first_fragment:1; /* This is a first fragment of the
-* frame */
-unsigned int power_level:8; /* per-packet transmit power level, in dBm
-*/
- unsigned int antenna_sel:4; /* 0 = default/diversity,
-* 1 = Ant0, 2 = Ant1 */
- int key_idx:8; /* -1 = do not encrypt, >= 0 keyidx from hw->set_key()
- */
- int icv_len:8; /* Length of the ICV/MIC field in octets */
- int iv_len:8; /* Length of the IV field in octets */
- unsigned int queue:4; /* hardware queue to use for this frame;
- * 0 = highest, hw->queues-1 = lowest */
- unsigned int sw_retry_attempt:4; /* no. of times hw has tried to
- * transmit frame (not incl. hw retries) */
+
+#define IEEE80211_TXCTL_REQ_TX_STATUS (1<<0)/* request TX status callback for
+ * this frame */
+#define IEEE80211_TXCTL_DO_NOT_ENCRYPT (1<<1) /* send this frame without
+ * encryption; e.g., for EAPOL
+ * frames */
+#define IEEE80211_TXCTL_USE_RTS_CTS(1<<2) /* use RTS-CTS before sending
+ * frame */
+#define IEEE80211_TXCTL_USE_CTS_PROTECT(1<<3) /* use CTS protection
for the
+ * frame (e.g., for combined
+ * 802.11g / 802.11b networks) */
+#define IEEE80211_TXCTL_NO_ACK (1<<4) /* tell the low level not to
+ * wait for an ack */
+#define IEEE80211_TXCTL_RATE_CTRL_PROBE(1<<5)
+#define IEEE80211_TXCTL_CLEAR_DST_MASK (1<<6)
+#define IEEE80211_TXCTL_REQUEUE(1<<7)
+#define IEEE80211_TXCTL_FIRST_FRAGMENT (1<<8) /* this is a first fragment of
+ * the frame */
+ u32 flags; /* tx control flags defined
+ * above */
+ u16 rts_cts_duration; /* duration field for RTS/CTS frame */
+ u8 retry_limit; /* 1 = only first attempt, 2 = one retry, .. */
+ u8 power_level; /* per-packet transmit power level, in dBm */
+ u8 antenna_sel; /* 0 = default/diversity, 1 = Ant0, 2 = Ant1 */
+ s8 key_idx; /* -1 = do not encrypt, >= 0 keyidx from
+* hw->set_key() */
+ u8 icv_len; /* length of the ICV/MIC field in octets */
+ u8 iv_len; /* length of the IV field in octets */
+ u8 queue; /* hardware queue to use for this frame;
+* 0 = highest, hw->queues-1 = lowest */
+ u8 sw_retry_attempt;/* number of times hw has tried to
+* transmit frame (not incl. hw retries) */
int rateidx; /* internal 80211.o rateidx */
int alt_retry_rate; /* retry rate for the last retries, given as the
Index: wireless-dev/net/d80211/ieee80211.c
===
--- wireless-dev.orig/net/d80211/ieee80211.c
+++ wireless-dev/net/d80211/ieee80211.c
@@ -3
[take4 4/5] d80211: remove bitfields from ieee80211_hw
All twelve one-bit bitfields have been subsumed into the new 'flags'
structure member and the new IEEE80211_HW_* definitions.
Signed-off-by: David Kimdon <[EMAIL PROTECTED]>
Index: wireless-dev/drivers/net/wireless/d80211/adm8211/adm8211.c
===
--- wireless-dev.orig/drivers/net/wireless/d80211/adm8211/adm8211.c
+++ wireless-dev/drivers/net/wireless/d80211/adm8211/adm8211.c
@@ -2025,17 +2025,10 @@ static int __devinit adm8211_probe(struc
hw->version = 2;
hw->name = "adm8211";
- hw->host_gen_beacon = 0;
- hw->device_hides_wep = 0;
- hw->rx_includes_fcs = 0;// however, FCS is kept in promisc mode
- hw->host_broadcast_ps_buffering = 0;
- hw->wep_include_iv = 1;
- hw->data_nullfunc_ack = 0;
- hw->no_tkip_wmm_hwaccel = 1;
hw->extra_tx_headroom = 0;
- hw->device_strips_mic = 0;
- hw->monitor_during_oper = 0;
- hw->fraglist = 0;
+ hw->flags = IEEE80211_HW_WEP_INCLUDE_IV |
IEEE80211_HW_NO_TKIP_WMM_HWACCEL;
+ // however, IEEE80211_HW_RX_INCLUDES_FCS in promisc mode
+
hw->channel_change_time = 1000;
hw->num_modes = 1;
Index: wireless-dev/include/net/d80211.h
===
--- wireless-dev.orig/include/net/d80211.h
+++ wireless-dev/include/net/d80211.h
@@ -439,19 +439,19 @@ struct ieee80211_hw {
* configure the upper layer IEEE 802.11 module to generate beacons.
* The low-level driver can use ieee80211_beacon_get() to fetch the
* next beacon frame. */
- unsigned int host_gen_beacon:1;
+#define IEEE80211_HW_HOST_GEN_BEACON (1<<0)
/* The device needs to be supplied with a beacon template only. */
- unsigned int host_gen_beacon_template:1;
+#define IEEE80211_HW_HOST_GEN_BEACON_TEMPLATE (1<<1)
/* Some devices handle decryption internally and do not
* indicate whether the frame was encrypted (unencrypted frames
* will be dropped by the hardware, unless specifically allowed
* through) */
- unsigned int device_hides_wep:1;
+#define IEEE80211_HW_DEVICE_HIDES_WEP (1<<2)
/* Whether RX frames passed to ieee80211_rx() include FCS in the end */
- unsigned int rx_includes_fcs:1;
+#define IEEE80211_HW_RX_INCLUDES_FCS (1<<3)
/* Some wireless LAN chipsets buffer broadcast/multicast frames for
* power saving stations in the hardware/firmware and others rely on
@@ -459,14 +459,15 @@ struct ieee80211_hw {
* configure the IEEE 802.11 upper layer to buffer broadcast/multicast
* frames when there are power saving stations so that low-level driver
* can fetch them with ieee80211_get_buffered_bc(). */
- unsigned int host_broadcast_ps_buffering:1;
+#define IEEE80211_HW_HOST_BROADCAST_PS_BUFFERING (1<<4)
- unsigned int wep_include_iv:1;
- unsigned int data_nullfunc_ack:1; /* will data nullfunc frames get
proper
- * TX status callback */
+#define IEEE80211_HW_WEP_INCLUDE_IV (1<<5)
+
+ /* will data nullfunc frames get proper TX status callback */
+#define IEEE80211_HW_DATA_NULLFUNC_ACK (1<<6)
/* Force software encryption for TKIP packets if WMM is enabled. */
- unsigned int no_tkip_wmm_hwaccel:1;
+#define IEEE80211_HW_NO_TKIP_WMM_HWACCEL (1<<7)
/* Some devices handle Michael MIC internally and do not include MIC in
* the received packets passed up. device_strips_mic must be set
@@ -474,15 +475,17 @@ struct ieee80211_hw {
* be still set in the IEEE 802.11 header with this option unlike with
* the device_hides_wep configuration option.
*/
- unsigned int device_strips_mic:1;
+#define IEEE80211_HW_DEVICE_STRIPS_MIC (1<<8)
/* Device is capable of performing full monitor mode even during
* normal operation. */
- unsigned int monitor_during_oper:1;
+#define IEEE80211_HW_MONITOR_DURING_OPER (1<<9)
/* Set if the low-level driver supports skb fraglist (NETIF_F_FRAGLIST),
* i.e. more than one skb per frame */
- unsigned int fraglist:1;
+#define IEEE80211_HW_FRAGLIST (1<<10)
+
+ u32 flags; /* hardware flags defined above */
/* Set to the size of a needed device specific skb headroom for TX
skbs. */
unsigned int extra_tx_headroom;
Index: wireless-dev/drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c
===
--- wireless-dev.orig/drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c
+++ wireless-dev/drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c
@@ -3971,9 +3971,10 @@ static int __devinit bcm43xx_init_one(st
goto out;
ieee->version = IEEE80211_VERSION;
ieee->name = KBUILD_MODNAME;
- ieee->host_gen_beacon_template = 1;
- ieee->rx_includes
[take4 5/5] d80211: remove bitfields from ieee80211_conf
All four one-bit bitfields have been subsumed into the new 'flags'
structure member and the new IEEE80211_CONF_* definitions.
Signed-off-by: David Kimdon <[EMAIL PROTECTED]>
Index: wireless-dev/include/net/d80211.h
===
--- wireless-dev.orig/include/net/d80211.h
+++ wireless-dev/include/net/d80211.h
@@ -242,12 +242,12 @@ struct ieee80211_conf {
int beacon_int;
- /* Bitfields, grouped together */
-
- unsigned int sw_encrypt:1;
- unsigned int sw_decrypt:1;
- unsigned int short_slot_time:1; /* use IEEE 802.11g Short Slot Time */
- unsigned int ssid_hidden:1; /* do not broadcast the ssid */
+#define IEEE80211_CONF_SW_ENCRYPT (1<<0)
+#define IEEE80211_CONF_SW_DECRYPT (1<<1)
+#define IEEE80211_CONF_SHORT_SLOT_TIME (1<<2) /* use IEEE 802.11g Short Slot
+ * Time */
+#define IEEE80211_CONF_SSID_HIDDEN (1<<3) /* do not broadcast the ssid */
+ u32 flags; /* configuration flags defined above */
u8 power_level;/* transmit power limit for
current
* regulatory domain; in dBm */
Index: wireless-dev/drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c
===
--- wireless-dev.orig/drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c
+++ wireless-dev/drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c
@@ -3562,9 +3562,9 @@ static int bcm43xx_net_config(struct net
bcm43xx_radio_selectchannel(bcm, conf->channel_val, 0);
/* Enable/Disable ShortSlot timing. */
- if (conf->short_slot_time != bcm->short_slot) {
+ if (!!(conf->flags & IEEE80211_CONF_SHORT_SLOT_TIME) !=
bcm->short_slot) {
assert(phy->type == BCM43xx_PHYTYPE_G);
- if (conf->short_slot_time)
+ if (conf->flags & IEEE80211_CONF_SHORT_SLOT_TIME)
bcm43xx_short_slot_timing_enable(bcm);
else
bcm43xx_short_slot_timing_disable(bcm);
@@ -3577,7 +3577,7 @@ static int bcm43xx_net_config(struct net
}
/* Hide/Show the SSID (AP mode only). */
- if (conf->ssid_hidden) {
+ if (conf->flags & IEEE80211_CONF_SSID_HIDDEN) {
bcm43xx_write32(bcm->wlcore, BCM43xx_MMIO_STATUS_BITFIELD,
bcm43xx_read32(bcm->wlcore,
BCM43xx_MMIO_STATUS_BITFIELD)
| BCM43xx_SBF_NO_SSID_BCAST);
Index: wireless-dev/drivers/net/wireless/d80211/rt2x00/rt2400pci.c
===
--- wireless-dev.orig/drivers/net/wireless/d80211/rt2x00/rt2400pci.c
+++ wireless-dev/drivers/net/wireless/d80211/rt2x00/rt2400pci.c
@@ -742,7 +742,8 @@ static void rt2400pci_config_rate(struct
rt2x00_register_read(rt2x00dev, TXCSR1, ®[0]);
value = SIFS + PLCP
- + (2 * (conf->short_slot_time ? SHORT_SLOT_TIME : SLOT_TIME))
+ + (2 * ((conf->flags & IEEE80211_CONF_SHORT_SLOT_TIME) ?
+ SHORT_SLOT_TIME : SLOT_TIME))
+ preamble
+ get_duration(ACK_SIZE, 10);
rt2x00_set_field32(®[0], TXCSR1_ACK_TIMEOUT, value);
@@ -2088,7 +2089,8 @@ static int rt2400pci_config(struct net_d
conf->channel_val, conf->channel, conf->freq);
rt2400pci_config_txpower(rt2x00dev, conf->power_level);
rt2400pci_config_antenna(rt2x00dev, conf->antenna_sel);
- rt2400pci_config_duration(rt2x00dev, conf->short_slot_time);
+ rt2400pci_config_duration(rt2x00dev,
+ conf->flags & IEEE80211_CONF_SHORT_SLOT_TIME);
rt2400pci_config_phymode(rt2x00dev, conf->phymode);
/*
Index: wireless-dev/drivers/net/wireless/d80211/rt2x00/rt2500pci.c
===
--- wireless-dev.orig/drivers/net/wireless/d80211/rt2x00/rt2500pci.c
+++ wireless-dev/drivers/net/wireless/d80211/rt2x00/rt2500pci.c
@@ -808,7 +808,8 @@ static void rt2500pci_config_rate(struct
rt2x00_register_read(rt2x00dev, TXCSR1, ®[0]);
value = SIFS + PLCP
- + (2 * (conf->short_slot_time ? SHORT_SLOT_TIME : SLOT_TIME))
+ + (2 * ((conf->flags & IEEE80211_CONF_SHORT_SLOT_TIME) ?
+ SHORT_SLOT_TIME : SLOT_TIME))
+ preamble
+ get_duration(ACK_SIZE, 10);
rt2x00_set_field32(®[0], TXCSR1_ACK_TIMEOUT, value);
@@ -2238,7 +2239,8 @@ static int rt2500pci_config(struct net_d
conf->power_level);
rt2500pci_config_txpower(rt2x00dev, conf->power_level);
rt2500pci_config_antenna(rt2x00dev, conf->antenna_sel);
- rt2500pci_config_duration(rt2x00dev, conf->short_slot_time);
+ rt2500pci_config_duration(rt2x00dev,
+
[take4 0/5] d80211: remove bitfields from include/net/d80211.h
Continue d80211 bitfield removal. In general, compilers have difficulty generating efficient code for bitfields. This patchset removes all bitfields from include/net/d80211.h. I converted the 1 bit bitfields into a bit in a u32 flags structure member. Larger bitfields I converted into their u8/u16/whatever equivalent. This should be a no-op from a functionality standpoint. Changes from take3: Switch flags structure member to u32 for struct ieee80211_tx_control and struct ieee80211_key_conf. Refresh to apply to current wireless-dev - update p54 driver to new API - update patch based on various changes in bcm43xx and rt2x00 drivers - account for removal of extra_hdr_room bitfield Changes from take2: Refresh to apply to current wireless-dev. Changes from take1: Update rt2500usb.c and rt73usb.c drivers based on the new structures. Changes from take0: Update the patches to apply on top of the following patches: d80211: remove unused Super AG definitions, purge comment (http://marc.theaimsgroup.com/?l=linux-netdev&m=116102409931269&w=2) d80211: remove initialization of unused xr structure members (http://marc.theaimsgroup.com/?l=linux-netdev&m=116076811809305&w=4) d80211: remove unused xr structure members, interface, etc. (http://marc.theaimsgroup.com/?l=linux-netdev&m=115989929600617&w=4) For key_conf_bitfields.patch change the new flags member to u8 from u32. For tx_control_bitfields.patch move the rts_cts_duration and retry_limit members in ieee80211_tx_control to allow for smaller structure size and change the flags member from u32 to u16. For tx_status_bitfields.patch, in drivers/net/wireless/d80211/bcm43xx/bcm43xx_dma.c and drivers/net/wireless/d80211/bcm43xx/bcm43xx_pio.c note that ieee80211_tx_status is already zero'd, so the ack bit only needs to be set, not cleared. -- - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[take4 3/5] d80211: remove bitfields from ieee80211_key_conf
All three one-bit bitfields have been subsumed into the new 'flags'
structure member and the new IEEE80211_KEY_* definitions. The 8 bit
keyidx bitfield is converted to type s8.
Signed-off-by: David Kimdon <[EMAIL PROTECTED]>
Index: wireless-dev/drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c
===
--- wireless-dev.orig/drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c
+++ wireless-dev/drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c
@@ -3667,7 +3667,7 @@ static int bcm43xx_net_set_key(struct ne
}
if (bcm43xx_current_phy(bcm)->fw == BCM43xx_FW_3) {
/* No support for HW-crypto with v3 firmware. */
- key->force_sw_encrypt = 1;
+ key->flags |= IEEE80211_KEY_FORCE_SW_ENCRYPT;
err = 0;
goto out_unlock;
}
@@ -3678,7 +3678,7 @@ static int bcm43xx_net_set_key(struct ne
if (algorithm == BCM43xx_SEC_ALGO_TKIP) {
/* FIXME: No TKIP hardware encryption for now. */
err = 0;
- key->force_sw_encrypt = 1;
+ key->flags |= IEEE80211_KEY_FORCE_SW_ENCRYPT;
goto out_unlock;
}
@@ -3702,7 +3702,7 @@ static int bcm43xx_net_set_key(struct ne
bcm43xx_hf_read(bcm) &
~BCM43xx_HF_USEDEFKEYS);
}
- key->force_sw_encrypt = 0;
+ key->flags &= ~IEEE80211_KEY_FORCE_SW_ENCRYPT;
break;
case DISABLE_KEY:
if (is_broadcast_ether_addr(addr)) {
@@ -3735,7 +3735,8 @@ out:
if (!err) {
dprintk(KERN_DEBUG PFX "Using %s based encryption for keyidx:
%d, "
"mac: " MAC_FMT "\n",
- (key->force_sw_encrypt) ? "software" : "hardware",
+ (key->flags & IEEE80211_KEY_FORCE_SW_ENCRYPT) ?
+ "software" : "hardware",
key->keyidx, MAC_ARG(addr));
}
return err;
Index: wireless-dev/include/net/d80211.h
===
--- wireless-dev.orig/include/net/d80211.h
+++ wireless-dev/include/net/d80211.h
@@ -368,13 +368,19 @@ struct ieee80211_key_conf {
ieee80211_key_alg alg;
int keylen;
- unsigned int force_sw_encrypt:1;/* to be cleared by low-level driver */
- int keyidx:8; /* WEP key index */
- unsigned int default_tx_key:1; /* This key is the new default TX key
-* (used only for broadcast keys). */
- unsigned int default_wep_only:1;/* static WEP is the only configured
security
-* policy; this allows some low-level
drivers
-* to determine when hwaccel can be
used */
+#define IEEE80211_KEY_FORCE_SW_ENCRYPT (1<<0) /* to be cleared by low-level
+driver */
+#define IEEE80211_KEY_DEFAULT_TX_KEY (1<<1) /* This key is the new default TX
+key (used only for broadcast
+keys). */
+#define IEEE80211_KEY_DEFAULT_WEP_ONLY (1<<2) /* static WEP is the only
+configured security policy;
+this allows some low-level
+drivers to determine when
+hwaccel can be used */
+ u32 flags; /* key configuration flags defined above */
+
+ s8 keyidx; /* WEP key index */
u8 key[0];
};
Index: wireless-dev/net/d80211/ieee80211.c
===
--- wireless-dev.orig/net/d80211/ieee80211.c
+++ wireless-dev/net/d80211/ieee80211.c
@@ -64,10 +64,14 @@ ieee80211_key_data2conf(struct ieee80211
conf->hw_key_idx = data->hw_key_idx;
conf->alg = data->alg;
conf->keylen = data->keylen;
- conf->force_sw_encrypt = data->force_sw_encrypt;
+ conf->flags = 0;
+ if (data->force_sw_encrypt)
+ conf->flags |= IEEE80211_KEY_FORCE_SW_ENCRYPT;
conf->keyidx = data->keyidx;
- conf->default_tx_key = data->default_tx_key;
- conf->default_wep_only = local->default_wep_only;
+ if (data->default_tx_key)
+ conf->flags |= IEEE80211_KEY_DEFAULT_TX_KEY;
+ if (local->default_wep_only)
+ conf->flags |= IEEE80211_KEY_DEFAULT_WEP_ONLY;
memcpy(conf->key, data->key, data->keylen);
return conf;
Index: wireless-dev/net/d80211/ieee80211_ioctl.c
===
--- wireless-dev.orig/n
[take4 2/5] d80211: remove bitfields from ieee80211_tx_status
Both one-bit bitfields have been subsumed into the new 'flags'
structure member and the new IEEE80211_TX_STATUS_* definitions.
Signed-off-by: David Kimdon <[EMAIL PROTECTED]>
Index: wireless-dev/include/net/d80211.h
===
--- wireless-dev.orig/include/net/d80211.h
+++ wireless-dev/include/net/d80211.h
@@ -211,8 +211,10 @@ struct ieee80211_tx_status {
/* copied ieee80211_tx_control structure */
struct ieee80211_tx_control control;
- unsigned int tx_filtered:1;
- unsigned int ack:1; /* whether the TX frame was ACKed */
+#define IEEE80211_TX_STATUS_TX_FILTERED(1<<0)
+#define IEEE80211_TX_STATUS_ACK(1<<1) /* whether the TX frame
was ACKed */
+ u32 flags; /* tx staus flags defined above */
+
int ack_signal; /* measured signal strength of the ACK frame */
int excessive_retries;
int retry_count;
Index: wireless-dev/drivers/net/wireless/d80211/adm8211/adm8211.c
===
--- wireless-dev.orig/drivers/net/wireless/d80211/adm8211/adm8211.c
+++ wireless-dev/drivers/net/wireless/d80211/adm8211/adm8211.c
@@ -428,12 +428,14 @@ static void adm8211_interrupt_tci(struct
if (status & TDES0_STATUS_ES) {
stats->tx_errors++;
- priv->tx_buffers[entry].tx_status.ack = 0;
+ priv->tx_buffers[entry].tx_status.flags &=
+ ~IEEE80211_TX_STATUS_ACK;
if (status & (TDES0_STATUS_TUF | TDES0_STATUS_TRO))
stats->tx_fifo_errors++;
} else
- priv->tx_buffers[entry].tx_status.ack = 1;
+ priv->tx_buffers[entry].tx_status.flags |=
+ IEEE80211_TX_STATUS_ACK;
pci_unmap_single(priv->pdev, priv->tx_buffers[entry].mapping,
priv->tx_buffers[entry].skb->len,
PCI_DMA_TODEVICE);
Index: wireless-dev/drivers/net/wireless/d80211/bcm43xx/bcm43xx_dma.c
===
--- wireless-dev.orig/drivers/net/wireless/d80211/bcm43xx/bcm43xx_dma.c
+++ wireless-dev/drivers/net/wireless/d80211/bcm43xx/bcm43xx_dma.c
@@ -1127,7 +1127,8 @@ void bcm43xx_dma_handle_txstatus(struct
* status of the transmission.
* Some fields of txstat are already filled in dma_tx().
*/
- meta->txstat.ack = status->acked;
+ if (status->acked)
+ meta->txstat.flags |= IEEE80211_TX_STATUS_ACK;
meta->txstat.retry_count = status->frame_count - 1;
ieee80211_tx_status_irqsafe(bcm->net_dev, meta->skb,
&(meta->txstat));
/* skb is freed by ieee80211_tx_status_irqsafe() */
Index: wireless-dev/drivers/net/wireless/d80211/bcm43xx/bcm43xx_pio.c
===
--- wireless-dev.orig/drivers/net/wireless/d80211/bcm43xx/bcm43xx_pio.c
+++ wireless-dev/drivers/net/wireless/d80211/bcm43xx/bcm43xx_pio.c
@@ -500,7 +500,8 @@ void bcm43xx_pio_handle_txstatus(struct
queue->tx_devq_packets--;
queue->tx_devq_used -= (packet->skb->len + phy->txhdr_size);
- packet->txstat.ack = status->acked;
+ if (status->acked)
+ packet->txstat.flags |= IEEE80211_TX_STATUS_ACK;
packet->txstat.retry_count = status->frame_count - 1;
ieee80211_tx_status_irqsafe(bcm->net_dev, packet->skb,
&(packet->txstat));
Index: wireless-dev/drivers/net/wireless/d80211/rt2x00/rt2400pci.c
===
--- wireless-dev.orig/drivers/net/wireless/d80211/rt2x00/rt2400pci.c
+++ wireless-dev/drivers/net/wireless/d80211/rt2x00/rt2400pci.c
@@ -1749,10 +1749,11 @@ static void rt2400pci_txdone(void *data)
ack = rt2x00_get_field32(txd->word0, TXD_W0_ACK);
+ entry->tx_status.flags = 0;
/*
-* TODO: How can te below field be set correctly?
+* TODO: How can bit IEEE80211_TX_STATUS_TX_FILTERED of
+* entry->tx_status.flags be set correctly?
*/
- entry->tx_status.tx_filtered = 0;
entry->tx_status.queue_length = ring->stats.limit;
entry->tx_status.queue_number = entry->tx_status.control.queue;
@@ -1764,11 +1765,10 @@ static void rt2400pci_txdone(void *data)
* was succesfull.
*/
tx_status = rt2x00_get_field32(txd->word0, TXD_W0_RESULT);
- entry->tx_status.ack = 0;
entry->tx_status.excessive_retries = 0;
[patch] d80211: endian annotations for ieee80211_frame_info, etc.
Thanks to sparse for pointing out these missing endian annotations.
All the fields in the AVS capture header (struct ieee80211_frame_info) are in
network byte order.
The length in the ethernet header is in network byte order.
last_seq_ctrl is stored little endian.
Signed-off-by: David Kimdon <[EMAIL PROTECTED]>
Index: wireless-dev/include/net/d80211_common.h
===
--- wireless-dev.orig/include/net/d80211_common.h 2006-11-05
14:54:08.240747720 -0800
+++ wireless-dev/include/net/d80211_common.h2006-11-05 14:56:45.225882352
-0800
@@ -20,26 +20,26 @@
#define IEEE80211_FI_VERSION 0x80211001
struct ieee80211_frame_info {
-u32 version;
-u32 length;
-u64 mactime;
-u64 hosttime;
-u32 phytype;
-u32 channel;
-u32 datarate;
-u32 antenna;
-u32 priority;
-u32 ssi_type;
-u32 ssi_signal;
-u32 ssi_noise;
-u32 preamble;
-u32 encoding;
+ __be32 version;
+ __be32 length;
+ __be64 mactime;
+ __be64 hosttime;
+ __be32 phytype;
+ __be32 channel;
+ __be32 datarate;
+ __be32 antenna;
+ __be32 priority;
+ __be32 ssi_type;
+ __be32 ssi_signal;
+ __be32 ssi_noise;
+ __be32 preamble;
+ __be32 encoding;
/* Note: this structure is otherwise identical to capture format used
* in linux-wlan-ng, but this additional field is used to provide meta
* data about the frame to hostapd. This was the easiest method for
* providing this information, but this might change in the future. */
- u32 msg_type;
+ __be32 msg_type;
} __attribute__ ((packed));
Index: wireless-dev/net/d80211/ieee80211.c
===
--- wireless-dev.orig/net/d80211/ieee80211.c2006-11-05 14:48:09.808237744
-0800
+++ wireless-dev/net/d80211/ieee80211.c 2006-11-05 15:01:29.594651728 -0800
@@ -2427,7 +2427,7 @@
memcpy(skb_push(skb, ETH_ALEN), dst, ETH_ALEN);
} else {
struct ethhdr *ehdr;
-unsigned short len;
+ __be16 len;
skb_pull(skb, hdrlen);
len = htons(skb->len);
ehdr = (struct ethhdr *) skb_push(skb, sizeof(struct ethhdr));
Index: wireless-dev/net/d80211/ieee80211_ioctl.c
===
--- wireless-dev.orig/net/d80211/ieee80211_ioctl.c 2006-11-05
14:48:09.816236528 -0800
+++ wireless-dev/net/d80211/ieee80211_ioctl.c 2006-11-05 14:56:45.228881896
-0800
@@ -218,7 +218,7 @@
struct iapp_layer2_update {
u8 da[ETH_ALEN]; /* broadcast */
u8 sa[ETH_ALEN]; /* STA addr */
- u16 len; /* 6 */
+ __be16 len; /* 6 */
u8 dsap; /* 0 */
u8 ssap; /* 0 */
u8 control;
Index: wireless-dev/net/d80211/sta_info.h
===
--- wireless-dev.orig/net/d80211/sta_info.h 2006-11-05 14:48:09.823235464
-0800
+++ wireless-dev/net/d80211/sta_info.h 2006-11-05 14:56:45.229881744 -0800
@@ -74,7 +74,7 @@
void *rate_ctrl_priv;
/* last received seq/frag number from this STA (per RX queue) */
- u16 last_seq_ctrl[NUM_RX_DATA_QUEUES];
+ __le16 last_seq_ctrl[NUM_RX_DATA_QUEUES];
unsigned long num_duplicates; /* number of duplicate frames received
* from this STA */
unsigned long tx_fragments; /* number of transmitted MPDUs */
--
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch] d80211: fix usage of capability field for ibss mode
Thanks to sparse for pointing out these errors.
'capability' is stored in struct ieee80211_sta_bss in host byte order, do not
swap bytes.
Signed-off-by: David Kimdon <[EMAIL PROTECTED]>
Index: wireless-dev/net/d80211/ieee80211_sta.c
===
--- wireless-dev.orig/net/d80211/ieee80211_sta.c2006-11-05
14:53:19.602141912 -0800
+++ wireless-dev/net/d80211/ieee80211_sta.c 2006-11-05 15:12:52.937767784
-0800
@@ -1984,7 +1984,7 @@
sdata = IEEE80211_DEV_TO_SUB_IF(dev);
sdata->drop_unencrypted = bss->capability &
- cpu_to_le16(WLAN_CAPABILITY_PRIVACY) ? 1 : 0;
+ WLAN_CAPABILITY_PRIVACY ? 1 : 0;
memset(&rq, 0, sizeof(rq));
rq.m = bss->freq * 10;
@@ -2153,9 +2153,9 @@
bss->channel = local->conf.channel;
bss->freq = local->conf.freq;
bss->last_update = jiffies;
- bss->capability = cpu_to_le16(WLAN_CAPABILITY_IBSS);
+ bss->capability = WLAN_CAPABILITY_IBSS;
if (sdata->default_key) {
- bss->capability |= cpu_to_le16(WLAN_CAPABILITY_PRIVACY);
+ bss->capability |= WLAN_CAPABILITY_PRIVACY;
} else
sdata->drop_unencrypted = 0;
bss->supp_rates_len = local->num_curr_rates;
--
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] bonding: fix an oops when slave device does not provide get_stats
Bonding driver unconditionnaly dereference get_stats function pointer
for each of its slave device. This patch
- adds a check for NULL dev->get_stats pointer in bond_get_stats
- prints a notice when the bonding device enslave a device without
get_stats function.
Signed-off-by: Laurent Riffard <[EMAIL PROTECTED]>
---
drivers/net/bonding/bond_main.c | 61 ++--
1 file changed, 35 insertions(+), 26 deletions(-)
Index: linux-2.6-mm/drivers/net/bonding/bond_main.c
===
--- linux-2.6-mm.orig/drivers/net/bonding/bond_main.c
+++ linux-2.6-mm/drivers/net/bonding/bond_main.c
@@ -1336,6 +1336,13 @@ int bond_enslave(struct net_device *bond
goto err_undo_flags;
}
+ if (slave_dev->get_stats == NULL) {
+ printk(KERN_NOTICE DRV_NAME
+ ": %s: the driver for slave device %s does not provide "
+ "get_stats function, network statistics will be "
+ "inaccurate.\n", bond_dev->name, slave_dev->name);
+ }
+
new_slave = kmalloc(sizeof(struct slave), GFP_KERNEL);
if (!new_slave) {
res = -ENOMEM;
@@ -3605,33 +3612,35 @@ static struct net_device_stats *bond_get
read_lock_bh(&bond->lock);
bond_for_each_slave(bond, slave, i) {
- sstats = slave->dev->get_stats(slave->dev);
+ if (slave->dev->get_stats) {
+ sstats = slave->dev->get_stats(slave->dev);
- stats->rx_packets += sstats->rx_packets;
- stats->rx_bytes += sstats->rx_bytes;
- stats->rx_errors += sstats->rx_errors;
- stats->rx_dropped += sstats->rx_dropped;
-
- stats->tx_packets += sstats->tx_packets;
- stats->tx_bytes += sstats->tx_bytes;
- stats->tx_errors += sstats->tx_errors;
- stats->tx_dropped += sstats->tx_dropped;
-
- stats->multicast += sstats->multicast;
- stats->collisions += sstats->collisions;
-
- stats->rx_length_errors += sstats->rx_length_errors;
- stats->rx_over_errors += sstats->rx_over_errors;
- stats->rx_crc_errors += sstats->rx_crc_errors;
- stats->rx_frame_errors += sstats->rx_frame_errors;
- stats->rx_fifo_errors += sstats->rx_fifo_errors;
- stats->rx_missed_errors += sstats->rx_missed_errors;
-
- stats->tx_aborted_errors += sstats->tx_aborted_errors;
- stats->tx_carrier_errors += sstats->tx_carrier_errors;
- stats->tx_fifo_errors += sstats->tx_fifo_errors;
- stats->tx_heartbeat_errors += sstats->tx_heartbeat_errors;
- stats->tx_window_errors += sstats->tx_window_errors;
+ stats->rx_packets += sstats->rx_packets;
+ stats->rx_bytes += sstats->rx_bytes;
+ stats->rx_errors += sstats->rx_errors;
+ stats->rx_dropped += sstats->rx_dropped;
+
+ stats->tx_packets += sstats->tx_packets;
+ stats->tx_bytes += sstats->tx_bytes;
+ stats->tx_errors += sstats->tx_errors;
+ stats->tx_dropped += sstats->tx_dropped;
+
+ stats->multicast += sstats->multicast;
+ stats->collisions += sstats->collisions;
+
+ stats->rx_length_errors += sstats->rx_length_errors;
+ stats->rx_over_errors += sstats->rx_over_errors;
+ stats->rx_crc_errors += sstats->rx_crc_errors;
+ stats->rx_frame_errors += sstats->rx_frame_errors;
+ stats->rx_fifo_errors += sstats->rx_fifo_errors;
+ stats->rx_missed_errors += sstats->rx_missed_errors;
+
+ stats->tx_aborted_errors += sstats->tx_aborted_errors;
+ stats->tx_carrier_errors += sstats->tx_carrier_errors;
+ stats->tx_fifo_errors += sstats->tx_fifo_errors;
+ stats->tx_heartbeat_errors +=
sstats->tx_heartbeat_errors;
+ stats->tx_window_errors += sstats->tx_window_errors;
+ }
}
read_unlock_bh(&bond->lock);
--
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: bcm43xx-d80211 broadcast reception with WPA
Hi, 12 Kas 2006 Paz 10:34 tarihinde şunları yazmıştınız: > Ah, and also note that you _need_ firmware from a v4 binary driver > to have hardware encryption with bcm43xx. Last time I heard only v3 firmware was supported. Is that changed? Regards, ismail - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: bcm43xx-d80211 broadcast reception with WPA
On Sunday 12 November 2006 21:43, Ismail Donmez wrote: > Hi, > 12 Kas 2006 Paz 10:34 tarihinde şunları yazmıştınız: > > Ah, and also note that you _need_ firmware from a v4 binary driver > > to have hardware encryption with bcm43xx. > > Last time I heard only v3 firmware was supported. Is that changed? Yes, wireless-dev supports v4 firmware (and even requires it for advanced features like hw encryption) -- Greetings Michael. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: bcm43xx-d80211 broadcast reception with WPA
12 Kas 2006 Paz 23:47 tarihinde, Michael Buesch şunları yazmıştı: > On Sunday 12 November 2006 21:43, Ismail Donmez wrote: > > Hi, > > > > 12 Kas 2006 Paz 10:34 tarihinde şunları yazmıştınız: > > > Ah, and also note that you _need_ firmware from a v4 binary driver > > > to have hardware encryption with bcm43xx. > > > > Last time I heard only v3 firmware was supported. Is that changed? > > Yes, wireless-dev supports v4 firmware (and even requires it for > advanced features like hw encryption) Thanks for information, this firmware would also solve the recent roothole. Regards, ismail - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: bcm43xx-d80211 broadcast reception with WPA
13 Kas 2006 Pts 00:40 tarihinde şunları yazmıştınız: > 12 Kas 2006 Paz 23:47 tarihinde, Michael Buesch şunları yazmıştı: > > On Sunday 12 November 2006 21:43, Ismail Donmez wrote: > > > Hi, > > > > > > 12 Kas 2006 Paz 10:34 tarihinde şunları yazmıştınız: > > > > Ah, and also note that you _need_ firmware from a v4 binary driver > > > > to have hardware encryption with bcm43xx. > > > > > > Last time I heard only v3 firmware was supported. Is that changed? > > > > Yes, wireless-dev supports v4 firmware (and even requires it for > > advanced features like hw encryption) > > Thanks for information, this firmware would also solve the recent roothole. s/roothole/security vulnerability would be better =) /ismail - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: bcm43xx-d80211 broadcast reception with WPA
On Mon, 2006-11-13 at 00:41 +0200, Ismail Donmez wrote: > > Thanks for information, this firmware would also solve the recent roothole. > > s/roothole/security vulnerability would be better =) Ummm, the problem was in the driver, not the firmware. You can't have security problems like that in the firmware. johannes signature.asc Description: This is a digitally signed message part
Re: [patch 1/9] bonding: lockdep annotation
From: Jeff Garzik <[EMAIL PROTECTED]> Date: Sun, 12 Nov 2006 11:40:02 -0500 > David Miller wrote: > > Jeff, I put this one in my net-2.6.20 tree already. > > Well, it was drivers/net/bonding/* which usually goes in through my > tree, what did you expect? :) It's not problem, it will all come out in the wash :) - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bugme-new] [Bug 7483] New: Unable to handle kernel paging request for data at address 0x5a5a5a5a5a5a5a5a
Quoting Andrew Morton <[EMAIL PROTECTED]>:
(switching to email - please follow up via reply-to-all and not via bugzilla)
On Fri, 10 Nov 2006 00:48:31 -0800
[EMAIL PROTECTED] wrote:
http://bugzilla.kernel.org/show_bug.cgi?id=7483
Summary: Unable to handle kernel paging request for data at
address 0x5a5a5a5a5a5a5a5a
Kernel Version: 2.6.19-rc5
Status: NEW
Severity: normal
Owner: [EMAIL PROTECTED]
This could be a networking bug.
Submitter: [EMAIL PROTECTED]
CC: [EMAIL PROTECTED],[EMAIL PROTECTED]
Most recent kernel where this bug did not occur: 2.6.19-rc5
You misunderstand. We're asking what is the most recent version of the
kernel which *did not* have this bug.
Sorry.
Distribution: SLES10 GA
Hardware Environment: IBM p-series server (POWER5+)
Software Environment: SLES10 GA + 2.6.19-rc5
Problem Description:
I mount a local samba directory and run fsstress in it. Several
minutes later,
the machine is no response and entered xmon(a debug mode in Power arch).
Dmesg as following:
CIFS VFS: close with pending writes
CIFS VFS: No task to wake, unknown frame rcvd! NumMids 8
Received Data is: : dump of 37 bytes of data at 0xc0003a6d9300
003a ff534d42 3200 008041c0 . . . : _ S M B 2 . . . . . A _
0100cf08 . . . . . . . . . . . . . . _ .
6400422f 0a02 d . B / .
CIFS VFS: No task to wake, unknown frame rcvd! NumMids
..
CIFS VFS: close with pending writes.
..
Unable to handle kernel paging request for data at address
0x5a5a5a5a5a5a5a5a.
Faulting instruction address: 0xc00a2e04..
xmon output:
5:mon> e
cpu 0x5: Vector: 300 (Data Access) at [c75b7470]
pc: c00a2e04: .put_page+0x2c/0x16c
lr: c042f238: .skb_release_data+0x84/0xe4
sp: c75b76f0
msr: 80009032
dar: 5a5a5a5a5a5a5a5a
dsisr: 4000
current = 0xc3000ad0
paca= 0xc062ce00
pid = 4419, comm = syslog-ng
5:mon> t
[c75b7790] c042f238 .skb_release_data+0x84/0xe4
[c75b7820] c042ef04 .kfree_skbmem+0x20/0xd4
[c75b78a0] c0431c48 .skb_free_datagram+0x14/0x28
[c75b7920] c04a7018 .unix_dgram_recvmsg+0x238/0x294
[c75b7a10] c0427b4c .sock_recvmsg+0xd0/0x110
[c75b7c10] c0428e18 .sys_recvfrom+0xcc/0x14c
[c75b7d90] c044784c .compat_sys_socketcall+0x194/0x214
[c75b7e30] c0008724 syscall_exit+0x0/0x40
--- Exception: c01 (System Call) at 07edffdc
SP (fa4df720) is in userspace
5:mon> r
R00 = c042f238 R16 = 1002
R01 = c75b76f0 R17 = 1002
R02 = c0848180 R18 = 1001
R03 = 5a5a5a5a5a5a5a5a R19 = 0003
R04 = 0002 R20 = fbe5fe96
R05 = 00020002 R21 = 1002
R06 = R22 = c3f184b0
R07 = R23 = c3de96e8
R08 = 3520336320633000 R24 = 0050
R09 = c00021f18e20 R25 = c3f181c8
R10 = c75bb8e8 R26 = 0040
R11 = c00021f18e20 R27 = c0007b165e60
R12 = fa4df78cfa4df788 R28 = c75b7a80
R13 = c062ce00 R29 = c0007b165e60
R14 = R30 = c0662d10
R15 = 1002 R31 = 5a5a5a5a5a5a5a5a
pc = c00a2e04 .put_page+0x2c/0x16c
lr = c042f238 .skb_release_data+0x84/0xe4
msr = 80009032 cr = 24044884
ctr = c04a7cb4 xer = 2001 trap = 300
dar = 5a5a5a5a5a5a5a5a dsisr = 4000
Steps to reproduce:
1.mkfs.ext3 /dev/sdb1
2.mount /dev/sdb1 /home
3.mkdir /home/public
4.add entry "public" (export directory /home/public) to /etc/samba/smb.conf,
then restart samba service
5.mount //localhost/public /mnt/test -o username=xxx,password=xxx
6.fsstress -l 500 -p 1000 -n 1000 -d /mnt/test
I guess skb_release_data() ran off the end of the ->frags array and passed
uninitialised, kmalloced data to put_page().
It's a pity that you're running both samba and the CIFS client on the same
machine. If you were to run them on two separate machines across the
network then we might be able to eliminate CIFS.
I separate them and run the same test case. The problem still appears
on the client end. And it seems no related with samba server.
But it does look like CIFS is involved.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ieee80211: Fix kernel panic when QoS is enabled
The 802.11 header length is affected by the wireless mode (WDS or not) and
type (QoS or not). We should use the variable hdr_len instead of the
hard coded IEEE80211_3ADDR_LEN, otherwise we may touch invalid memory.
Signed-off-by: Zhu Yi <[EMAIL PROTECTED]>
---
net/ieee80211/ieee80211_tx.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
97f244c8efd9a30f0e63e71709ee0142e85307f6
diff --git a/net/ieee80211/ieee80211_tx.c b/net/ieee80211/ieee80211_tx.c
index ae25449..854fc13 100644
--- a/net/ieee80211/ieee80211_tx.c
+++ b/net/ieee80211/ieee80211_tx.c
@@ -390,7 +390,7 @@ int ieee80211_xmit(struct sk_buff *skb,
* this stack is providing the full 802.11 header, one will
* eventually be affixed to this fragment -- so we must account
* for it when determining the amount of payload space. */
- bytes_per_frag = frag_size - IEEE80211_3ADDR_LEN;
+ bytes_per_frag = frag_size - hdr_len;
if (ieee->config &
(CFG_IEEE80211_COMPUTE_FCS | CFG_IEEE80211_RESERVE_FCS))
bytes_per_frag -= IEEE80211_FCS_LEN;
@@ -412,7 +412,7 @@ int ieee80211_xmit(struct sk_buff *skb,
} else {
nr_frags = 1;
bytes_per_frag = bytes_last_frag = bytes;
- frag_size = bytes + IEEE80211_3ADDR_LEN;
+ frag_size = bytes + hdr_len;
}
rts_required = (frag_size > ieee->rts
--
1.2.6
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bugme-new] [Bug 7502] New: sunhme not working with 2.6.18 on x86
On Sun, 12 Nov 2006 16:48:39 -0800 [EMAIL PROTECTED] wrote: > http://bugzilla.kernel.org/show_bug.cgi?id=7502 > >Summary: sunhme not working with 2.6.18 on x86 > Kernel Version: 2.6.18 > Status: NEW > Severity: normal > Owner: [EMAIL PROTECTED] > Submitter: [EMAIL PROTECTED] > > > Since Kernel 2.6.18 sunhme gives me a "irq nobody cared" and transmit > timeouts. 2.6.17 worked fine. The NIC is a Sun HappyMeal Quad-Port and my > architecture is x86. > > The same problem is described at > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=397460 and it seems the > problem is introduced by > http://www.kernel.org/git/?p=linux/kernel/git/stable/linux-2.6.18.y.git;a=commit;h=050bbb196392b9c178f82b1205a23dd2f915ee93 > > Relevant dmesg part: > > Oct 27 01:12:27 merkur eth0: Link is up using internal transceiver at > 100Mb/s, > Full Duplex. > Oct 27 01:12:29 merkur irq 19: nobody cared (try booting with the "irqpoll" > option) > Oct 27 01:12:29 merkur handlers: > Oct 27 01:12:29 merkur [<0031333e>] (0x31333e) > Oct 27 01:12:29 merkur Disabling IRQ #19 > Oct 27 01:12:32 merkur eth1: Link is up using internal transceiver at > 100Mb/s, > Full Duplex. > Oct 27 01:14:03 merkur NETDEV WATCHDOG: eth1: transmit timed out > Oct 27 01:14:03 merkur eth1: transmit timed out, resetting > Oct 27 01:14:03 merkur eth1: Happy Status 0303 TX[03ff:0301] > I'd have expected that this would have been caused by i386 platform borkage. But in the debian bug report, Michal has fingered davem's http://www.kernel.org/git/?p=linux/kernel/git/stable/linux-2.6.18.y.git;a=commit;h=050bbb196392b9c178f82b1205a23dd2f915ee93 as the cause. Michal, what makes you believe that this particualr patch is to blame? - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Generic Netlink HOW-TO based on Jamal's original doc
On Fri, Nov 10, 2006 at 06:36:42PM +0100, Thomas Graf wrote:
> * Jarek Poplawski <[EMAIL PROTECTED]> 2006-11-10 14:24
> > @@ -449,7 +449,7 @@
> >
> > The second step is to define the operations for the family, which we do by
> > creating at least one instance of the genl_ops structure which we
> > explained in
> > -section 3.1.2.. In this example we are only going to define one operation
> > but
> > +section 3.1.2. In this example we are only going to define one operation
> > but
> > you can define up to 255 unique operations for each family.
> >
> >/* handler */
> > @@ -465,7 +465,7 @@
> > DOC_EXMPL_C_ECHO,
> > __DOC_EXMPL_C_ECHO,
>
> Careful, the typo is here, not below.
>
> >};
> > - #define DOC_EXMPL_C_MAX (__DOC_EXMPL_C_MAX - 1)
> > + #define DOC_EXMPL_C_MAX (__DOC_EXMPL_C_ECHO - 1)
> >
> >/* operation definition */
> >struct genl_ops doc_exmpl_gnl_ops_echo = {
>
But there is more...
Jarek P.
PS: It is added to my first patch because I don't know
what is the current version.
---
--- netlink.txt-2006-11-10 10:53:50.0 +0100
+++ netlink.txt 2006-11-13 07:53:41.0 +0100
@@ -32,7 +32,7 @@
1.1. Document Overview
--
-This document gives is a brief introduction to Generic Netlink, some simple
+This document gives a brief introduction to Generic Netlink, some simple
examples on how to use it, and some recommendations on how to make the most of
the Generic Netlink communications interface. While this document does not
require that the reader have a detailed understanding of what Netlink is
@@ -55,21 +55,21 @@
channels are associated with families or "busses", where each bus deals with a
specific service; for example, different Netlink busses exist for routing,
XFRM, netfilter, and several other kernel subsystems. More information about
-Netlink can be found in RFC 3549[1].
+Netlink can be found in RFC 3549[2].
Over the years, Netlink has become very popular which has brought about a very
real concern that the number of Netlink family numbers may be exhausted in the
near future. In response to this the Generic Netlink family was created which
-acts as a Netlink multiplexer, allowing multiple service to use a single
+acts as a Netlink multiplexer, allowing multiple services to use a single
Netlink bus.
-[1] ftp://ftp.rfc-editor.org/in-notes/rfc3549.txt
+[2] ftp://ftp.rfc-editor.org/in-notes/rfc3549.txt
2. Architectural Overview
--
-Figure #1 illustrates how the basic Generic Netlink architecture which is
-composed of five different types of components.
+Figure #1 illustrates the basic Generic Netlink architecture which is
+composed of five different types of components:
1) The Netlink subsystem which serves as the underlying transport layer for
all of the Generic Netlink communications.
@@ -99,7 +99,7 @@
||
+---++---+
|: : | user-space
- =+: (5) Kernel socket API : +
+ =+: (5) kernel socket API : +
|: : | kernel-space
++---+---+
| |
@@ -112,7 +112,7 @@
+--+--+---++
| | |
+---+-+| |
- | (4) Controller | / \
+ | (4) controller | / \
+-+ / \
| |
+--+--+ +--+--+
@@ -141,15 +141,15 @@
--
The Generic Netlink mechanism is based on a client-server model. The Generic
-Netlink servers register families, which are a collection of well defined
-services, with the controller and the clients communicate with the server
+Netlink servers register with the controller families, which are a collection
+of well defined services, and the clients communicate with the servers
through these service registrations. This section explains how Generic Netlink
families are defined, created and registered.
3.1. Family Overview
--
-Generic Netlink family service registrations are defined by two structures,
+Generic Netlink family service registrations are defined by two structures:
genl_family and genl_ops. The genl_family structure defines the family and
it's associated communication channel. The genl_ops stru
Re: why do we mangle checksums for v6 ICMP?
From: Bill Fink <[EMAIL PROTECTED]> Date: Sat, 11 Nov 2006 13:07:24 -0500 > On a raw IPv6 socket, shouldn't the IP checksum just be left > unchanged, so you can test transmission of IPv6 packets with > an invalid zero IP checksum. Or is raw not fully raw? The code path where we do the "0 --> -1" conversion only executes when inet->hdrincl is false. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Generic Netlink HOW-TO based on Jamal's original doc
On Fri, Nov 10, 2006 at 06:36:42PM +0100, Thomas Graf wrote:
> * Jarek Poplawski <[EMAIL PROTECTED]> 2006-11-10 14:24
> > @@ -449,7 +449,7 @@
> >
> > The second step is to define the operations for the family, which we do by
> > creating at least one instance of the genl_ops structure which we
> > explained in
> > -section 3.1.2.. In this example we are only going to define one operation
> > but
> > +section 3.1.2. In this example we are only going to define one operation
> > but
> > you can define up to 255 unique operations for each family.
> >
> >/* handler */
> > @@ -465,7 +465,7 @@
> > DOC_EXMPL_C_ECHO,
> > __DOC_EXMPL_C_ECHO,
>
> Careful, the typo is here, not below.
>
> >};
> > - #define DOC_EXMPL_C_MAX (__DOC_EXMPL_C_MAX - 1)
> > + #define DOC_EXMPL_C_MAX (__DOC_EXMPL_C_ECHO - 1)
> >
> >/* operation definition */
> >struct genl_ops doc_exmpl_gnl_ops_echo = {
>
Sorry! Typo in @@ -436,20 part. Forget the earlier message.
So there is more...
Jarek P.
PS: It is added to my first patch because I don't know
what is the current version.
---
--- netlink.txt-2006-11-10 10:53:50.0 +0100
+++ netlink.txt 2006-11-13 07:53:41.0 +0100
@@ -32,7 +32,7 @@
1.1. Document Overview
--
-This document gives is a brief introduction to Generic Netlink, some simple
+This document gives a brief introduction to Generic Netlink, some simple
examples on how to use it, and some recommendations on how to make the most of
the Generic Netlink communications interface. While this document does not
require that the reader have a detailed understanding of what Netlink is
@@ -55,21 +55,21 @@
channels are associated with families or "busses", where each bus deals with a
specific service; for example, different Netlink busses exist for routing,
XFRM, netfilter, and several other kernel subsystems. More information about
-Netlink can be found in RFC 3549[1].
+Netlink can be found in RFC 3549[2].
Over the years, Netlink has become very popular which has brought about a very
real concern that the number of Netlink family numbers may be exhausted in the
near future. In response to this the Generic Netlink family was created which
-acts as a Netlink multiplexer, allowing multiple service to use a single
+acts as a Netlink multiplexer, allowing multiple services to use a single
Netlink bus.
-[1] ftp://ftp.rfc-editor.org/in-notes/rfc3549.txt
+[2] ftp://ftp.rfc-editor.org/in-notes/rfc3549.txt
2. Architectural Overview
--
-Figure #1 illustrates how the basic Generic Netlink architecture which is
-composed of five different types of components.
+Figure #1 illustrates the basic Generic Netlink architecture which is
+composed of five different types of components:
1) The Netlink subsystem which serves as the underlying transport layer for
all of the Generic Netlink communications.
@@ -99,7 +99,7 @@
||
+---++---+
|: : | user-space
- =+: (5) Kernel socket API : +
+ =+: (5) kernel socket API : +
|: : | kernel-space
++---+---+
| |
@@ -112,7 +112,7 @@
+--+--+---++
| | |
+---+-+| |
- | (4) Controller | / \
+ | (4) controller | / \
+-+ / \
| |
+--+--+ +--+--+
@@ -141,15 +141,15 @@
--
The Generic Netlink mechanism is based on a client-server model. The Generic
-Netlink servers register families, which are a collection of well defined
-services, with the controller and the clients communicate with the server
+Netlink servers register with the controller families, which are a collection
+of well defined services, and the clients communicate with the servers
through these service registrations. This section explains how Generic Netlink
families are defined, created and registered.
3.1. Family Overview
--
-Generic Netlink family service registrations are defined by two structures,
+Generic Netlink family service registrations are defined by two structures:
genl_family and genl_ops. The genl_family structure defines the family a
Re: [PATCH 1/3] [NET]: Supporting UDP-Lite (RFC 3828) in Linux
Quoting David Miller:
|
| I can't apply any of this Gerrit.
|
| What makes net/ipv4/udplite.c get built at all? I see no
| changes to net/ipv4/Makefile, so you must have stuffed up
| the generation of your patches.
This is a misunderstanding: udplite.o will never be built,
it is #included in udp.c. Witness
==> net/ipv4/udp.c, line 1727:
/* the extensions for UDP-Lite (RFC 3828) */
#include "udplite.c"
==> net/ipv6/udp.c, line 1009:
/* the extensions for UDP-Lite (RFC 3828) */
#include "udplite.c"
| Please resubmit all 3 patches once you've corrected this
| and actually _tested_ the patch you submitted. You know,
I do not submit patches that I don't have tested myself. It
all works: no compile errors, all functions (UDPv4/v6 and
UDP-Litev4/v6) confirmed to work.
You can find test applications for UDP-Lite (IPPROTO=136) on
http://www.erg.abdn.ac.uk/users/gerrit/udp-lite/files/udplite_linux.tar.gz
(subdirectory apps/{sock,ttcp,vlc,client-server,perl_client-server}
Regards
Gerrit
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] [NET]: Supporting UDP-Lite (RFC 3828) in Linux
| > This code is does too much inlining (like existing network code). | > Should it be made configurable? | | It doesn't get built at all if you check his patches :-) See previous posting. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] [NET]: Supporting UDP-Lite (RFC 3828) in Linux
From: Gerrit Renker <[EMAIL PROTECTED]> Date: Mon, 13 Nov 2006 07:34:48 + > Quoting David Miller: > | > | I can't apply any of this Gerrit. > | > | What makes net/ipv4/udplite.c get built at all? I see no > | changes to net/ipv4/Makefile, so you must have stuffed up > | the generation of your patches. > This is a misunderstanding: udplite.o will never be built, > it is #included in udp.c. Witness > > ==> net/ipv4/udp.c, line 1727: > > /* the extensions for UDP-Lite (RFC 3828) */ > #include "udplite.c" > > ==> net/ipv6/udp.c, line 1009: > /* the extensions for UDP-Lite (RFC 3828) */ > #include "udplite.c" Sorry I misread this. I'm not a huge fan of source file inclusion like this. It's not a header file, it contains code. Is there a way to build this as a seperate object somehow? - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] [NET]: Supporting UDP-Lite (RFC 3828) in Linux
Quoting Stephen Hemminger: | On Fri, 10 Nov 2006 16:09:20 + | Gerrit Renker <[EMAIL PROTECTED]> wrote: | | > [NET/IPv4]: Support for the UDP-Lite protocol (RFC 3828) | > | > This adds support for UDP-Lite to the IPv4 stack, provided as an extension | > to the existing UDPv4 code: | >* generic routines are all located in net/ipv4/udp.c | >* UDP-Lite specific routines are in net/ipv4/udplite.c | >* MIB/statistics support in /proc/net/snmp and /proc/net/udplite | >* shared API with extensions for partial checksum coverage | >* consolidation of shared code | > | > | | This code is does too much inlining (like existing network code). | Should it be made configurable? That is a late question for a patch which has been in a RFC phase for several months. This patch had been submitted repeatedly for RFC between middle of September ... end of October. It used to be configurable and it also used to be much more bloated: ``The in-lining is a feature, not a bug!'' Reason: If you look at udplite.c (which is, despite #including, a fully self-contained protocol module), the inline functions all call generic code from udp.c. If you then look back at udp.c, you see that UDP almost does the same. What you have here is two protocols for the price of one; the inlines work as wrappers for both UDP and UDP-Lite. And considerable amount of extracting and minimising went into making it that way. Before: The patch used to be separate and was an `enormous mass of code reduplication'. Imagine udp.c reduplicated and modified to run UDP-Lite: then you have two highly similar code files, over 90% of code reduplication (bad ... very bad). Is there someone else supporting `make UDP-Lite' configurable -- in the end I am being asked to re-implement a feature I was asked to remove a couple of months ago. It is not a problem to do this, but this code has cost a lot of work and I would like to finally see it in 2.6.20. Gerrit - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
