On Fri, Mar 24, 2006 at 09:24:53PM -0800, Jouni Malinen wrote:
> Please apply following two patches to Host AP driver in wireless-2.6.
> The second patch ("Fix EAPOL frame encryption") is a trivial bug fix for
> a somewhat unfortunate bug and it could be a good candidate for a
> 2.6.16.x stable rel
Hi Dave:
I was working on the ipip/xfrm problem and as usual I get side-tracked by
other problems.
As part of an attempt to change the IPv4 protocol handler calling
convention I found that SCTP violated the existing convention.
It's returning non-zero values after freeing the skb. This is doubl
Wouldn't the appropriate place to add the tunable for Stretch ACKs be as
a route attribute similar to RTAX_ADVMSS? Then system administrators
who are aware of the local network topology, netfilters, etc, could use
an "ip route" or whatever command to enable it on the route entry for
the loc
Please apply following two patches to Host AP driver in wireless-2.6.
The second patch ("Fix EAPOL frame encryption") is a trivial bug fix for
a somewhat unfortunate bug and it could be a good candidate for a
2.6.16.x stable release ([EMAIL PROTECTED] cc'ed).
--
Jouni Malinen
Fixed encrypted of EAPOL frames from wlan#ap interface (hostapd). This
was broken when moving to use new frame control field defines in
net/ieee80211.h. hostapd uses Protected flag, not protocol version
(which was cleared in this function anyway). This fixes WPA group key
handshake and re-authentic
hostap_tx_encrypt() is used only inside hostap_80211_tx.c and there
are no plans to use it elsewhere in the future either, so let's make
it static. As a bonus, this should silence Coverity scanner from
complaining about bogus FORWARD_NULL case (CID: 274).
Signed-off-by: Jouni Malinen <[EMAIL PROTE
Hi Dave:
The netdev notifier call chain is currently unregistered without taking
any locks outside the notifier system. Because the notifier system itself
does not synchronise unregistration with respect to the calling of the
chain, we as its user need to do our own locking.
We are supposed to t
x86 allmodconfig:
bix:/usr/src/25> make net/ipv6/netfilter/nf_conntrack_l3proto_ipv6.o
CC net/ipv6/netfilter/nf_conntrack_l3proto_ipv6.o
net/ipv6/netfilter/nf_conntrack_l3proto_ipv6.c: In function `ipv6_conntrack_in':
net/ipv6/netfilter/nf_conntrack_l3proto_ipv6.c:254: error: structure has
On Fri, Mar 24, 2006 at 06:22:06PM -0800, Greg KH wrote:
> ... a bit
> different from the traditional kernel coding style.
Sorry, this is due to inattention on my part; I get cross-eyed
after staring at the same code for too long. The patch below should
fix things.
--linas
[PATCH] PCI Error
On Fri, Mar 24, 2006 at 04:00:02PM -0600, Linas Vepstas wrote:
> + /* Perform card reset only on one instance of the card */
> + if(0 != PCI_FUNC (pdev->devfn))
> + return PCI_ERS_RESULT_RECOVERED;
You seem to have forgotton to put a ' ' after the 'if' in a number of
different
From: Jean Tourrilhes <[EMAIL PROTECTED]>
Date: Fri, 24 Mar 2006 15:47:51 -0800
> Actually, in 2.6.17, NET_RADIO and WIRELESS_EXT were
> separated. So, I would suggest the following instead :
>
> -
> config NET_WIRELESS_RTNETLINK
> bool "Wirele
On Fri, 2006-24-03 at 20:24 +0530, Balbir Singh wrote:
> Hmm... Would it be ok to send one message with the following format
>
> 1. TLV=TASKSTATS_TYPE_PID
> 2. TLV=TASKSTATS_TYPE_STATS
> 3. TLV=TASKSTATS_TYPE_TGID
> 4. TLV=TASKSTATS_TYPE_STATS
>
> It would still be one message, except that 3 and
From: Phil Oester <[EMAIL PROTECTED]>
Date: Fri, 24 Mar 2006 17:03:35 -0800
> Upgraded a number of heavily used squid boxes to 2.6.16 from 2.6.13
> this week, and noticed these errors in the logs:
>
> KERNEL: assertion (!sk->sk_forward_alloc) failed at net/core/stream.c (279)
> KERNEL: assertion
Upgraded a number of heavily used squid boxes to 2.6.16 from 2.6.13
this week, and noticed these errors in the logs:
KERNEL: assertion (!sk->sk_forward_alloc) failed at net/core/stream.c (279)
KERNEL: assertion (!sk->sk_forward_alloc) failed at net/ipv4/af_inet.c (148)
but then looked through the
On Fri, 2006-03-24 at 08:18 -0800, Jouni Malinen wrote:
> On Thu, Mar 23, 2006 at 10:43:38PM +, David Woodhouse wrote:
>
> > This patch makes us default to 11M, which ought to work for most people.
>
> Is this code supposed to work with IEEE 802.11a (which would also use
> OFDM modulation)? I
Hi all,
The "dev->get_wireless_stats" field is deprecated and slowly
be surely going away. Most drivers have been updated months
ago. Actually, there is an annoying message for driver still using it,
but it seems that user of zd1201 were not annoyed enough ;-)
Patch was com
> It would have been even worse, IMHO, to have two copies of
> nearly identical code sitting around which is basically what
> the alternative is.
We don't need two copies. We just need a function that does the real
work if there is a tunnel to be used (what xfrm6_tunnel needs), and
another on
From: Herbert Xu <[EMAIL PROTECTED]>
Date: Sat, 25 Mar 2006 11:36:36 +1100
> On Fri, Mar 24, 2006 at 04:31:15PM -0800, David S. Miller wrote:
> >
> > It would have been even worse, IMHO, to have two copies of
> > nearly identical code sitting around which is basically what
> > the alternative is.
On Fri, Mar 24, 2006 at 04:31:15PM -0800, David S. Miller wrote:
>
> It would have been even worse, IMHO, to have two copies of
> nearly identical code sitting around which is basically what
> the alternative is.
Actually, it might be cleaner to have wrappers around a common
(possibly inline as w
From: Hugo Santos <[EMAIL PROTECTED]>
Date: Sat, 25 Mar 2006 00:18:04 +
>I find it ugly that the same function, in this case ip6ip6_rcv(), is
> used in two contexts where the expected behaviour differs.
It would have been even worse, IMHO, to have two copies of
nearly identical code sitt
On Fri, 2006-03-24 at 14:14 -0800, Jouni Malinen wrote:
> wpa_supplicant does indeed require that the scan results are reported
> correctly. I don't see much point in the results if they are not
> correct.. It is unfortunate if you need to use this kind of patch since
> it would not work very well
> OK this is a bit ugly but will do for now. Could you please do it for
> the ICMP packet and IPv4 as well?
I find it ugly that the same function, in this case ip6ip6_rcv(), is
used in two contexts where the expected behaviour differs. Also, using
the current #ifdefs, ip6_tunnel is only load
From: Dave Jones <[EMAIL PROTECTED]>
Date: Fri, 24 Mar 2006 18:04:28 -0500
> I accidentally ended up with a config that set NET_RADIO off,
> and NET_WIRELESS_RTNETLINK on, which blew up thus..
>
> net/built-in.o: In function `do_setlink':net/core/rtnetlink.c:479: undefined
> reference to `wirele
Dave Jones wrote :
>
> I accidentally ended up with a config that set NET_RADIO off,
> and NET_WIRELESS_RTNETLINK on, which blew up thus..
Good catch !
Actually, in 2.6.17, NET_RADIO and WIRELESS_EXT were
separated. So, I would suggest the following instead :
On Fri, 24 Mar 2006, walt wrote:
> Michael Chan wrote:
> > Walt wrote:
> >
> >> Nope, it was the second one: Skip phy power down...
>
> > It doesn't make sense. This code should have no effect on your
> > 5702. With or without this patch, the 5702 will be powered down
> > the same with tg3_writ
On Fri, 24 Mar 2006 17:52:25 -0500, "John W. Linville" <[EMAIL PROTECTED]>
wrote:
> I should be able to take the master-based patches you sent me
> and massage them into wireless-2.6 -- no need for you to do it.
Thanks. BTW, I talked to DaveM a minute ago on an unrelated subject, and we
touched
On Fri, 2006-03-24 at 14:06 -0800, walt wrote:
>
> I confess I'm a bit confused by your question. I have no idea
> why an ifdown would be executed during boot, but the startup
> scripts are so complicated that I can't understand what they do.
The best thing to do is probably to disable all the
I accidentally ended up with a config that set NET_RADIO off,
and NET_WIRELESS_RTNETLINK on, which blew up thus..
net/built-in.o: In function `do_setlink':net/core/rtnetlink.c:479: undefined
reference to `wireless_rtnetlink_set'
net/built-in.o: In function `do_getlink':net/core/rtnetlink.c:521: u
On Fri, Mar 24, 2006 at 01:13:12PM -0800, Pete Zaitcev wrote:
> Would you just keep it on master without pushing to Linus? They way you
> manipulate branches of wireless-2.6 is bewildering for me, and "softmac"
I'm trying to get away from excessive branching. It gets to be a
big PITA, and it con
On Fri, Mar 24, 2006 at 09:27:21PM +0100, Michael Buesch wrote:
> But, I would like to push some more fixes from my repository, before the
> driver goes mainline. How much time do I have left to prepare it?
> Or should I wait with this until we enter the -rc phase?
Jeff is going to hold me to onl
On Fri, 24 Mar 2006 22:13:54 +
Michael Menegakis <[EMAIL PROTECTED]> wrote:
>
> were they any helpfull?
The first thing to look for is are packets showing up (and being transmitted)
by doing
ethtool -S eth0
Since in this driver stats come out of the PHY, it is possible for the PHY
to
On Fri, 2006-03-24 at 09:48 -0800, Jouni Malinen wrote:
> Is battery use more important than accuracy of results and the amount of
> time needed to perform the operation?
You're going to be using *more* battery when doing a passive scan
because the dwell time is much much larger, and you can't po
On Fri, Mar 24, 2006 at 09:31:56PM +, David Woodhouse wrote:
> wpa_supplicant appears to be aware of none of this -- it expects the
> SSID to be precisely correct in the scan results after it does an active
> probe for a specific SSID. Thus, it doesn't work when SSID broadcasting
> is turned o
On Fri, Mar 24, 2006 at 07:29:33PM +, fs wrote:
> On Fri, Mar 24, 2006 at 11:24:35AM -0800, Stephen Hemminger wrote:
> > On Fri, 24 Mar 2006 18:48:37 +
> > fs <[EMAIL PROTECTED]> wrote:
> >
> > > On Fri, Mar 24, 2006 at 10:40:00AM -0800, Stephen Hemminger wrote:
> > > > > Maybe the hang I
Michael Chan wrote:
> Walt wrote:
>
>> Nope, it was the second one: Skip phy power down...
> It doesn't make sense. This code should have no effect on your
> 5702. With or without this patch, the 5702 will be powered down
> the same with tg3_writephy(tp, MII_BMCR, BMCR_PDOWN) if WOL
> is not ena
Jeff,
Can you please review and forward this patch upstream? A previous
version of this patch has been ack'ed by Jesse Brandeburg, one
of the e1000 maintainers.
--linas
[PATCH] PCI Error Recovery: e1000 network device driver
Various PCI bus errors can be signaled by newer PCI controllers. T
Jean-Mickael Guerin <[EMAIL PROTECTED]> wrote:
> In ip6ip6_tnl_xmit(), we do not xfrm_lookup() when the dst has been
> stored in cache.
> If cache is filled before a security policy such ipsec transport mode on
> end points
> is added, and no routing changes happen, how to invalidate the cache to
Hugo Santos <[EMAIL PROTECTED]> wrote:
>
> This patch fixes a soft lockup in ip6_tunnel when not using
> xfrm6_tunnel (CONFIG_INET6_TUNNEL). It is triggered when an encapsula-
> ted packet reaches ip6ip6_rcv() and there is no tunnel associated with
> it. The error path returns a positive value (
On Fri, 2006-03-24 at 11:05 -0600, James Ketrenos wrote:
> Dan Williams wrote:
> > this is something that ieee80211 does that's completely wrong.
>
> Because it is not a part of the 802.11 specification, AP vendors have
> each implemented their own method for disguising the SSID. Some set the
>
On Fri, Mar 24, 2006 at 01:00:24PM +, Hugo Santos wrote:
>
>When ip6_tunnel discards a packet because there is no tunnel
> associated with it, it sends a ICMPV6_DEST_UNREACH error to the packet
> source. However, when using ip6_tunnel and xfrm6_tunnel, if there is a
> a tunnel spi alloc
On Fri, Mar 24, 2006 at 03:38:50PM -0500, Dan Williams wrote:
> On Fri, 2006-03-24 at 12:12 -0800, Jean Tourrilhes wrote:
> > Jouni Malinen wrote :
> > >
> > > On Thu, Mar 23, 2006 at 08:16:04PM -0500, Dan Williams wrote:
> > > > That's why wireless-tools and Wireless Extensions switched to
> > >
On Fri, Mar 24, 2006 at 12:28:45PM -0800, Jouni Malinen wrote:
>
> > But, before going into deep technical discussions, we may want
> > to remind us what is the goal of this API. The goal is to present the
> > user a list of potential networks that can be used by him, in the case
> > he doesn'
On Fri, 24 Mar 2006 08:15:24 -0500, "John W. Linville" <[EMAIL PROTECTED]>
wrote:
> Yes, sorry. I renamed the softmac branch as "devel" -- it has the
> stuff that was on the softmac branch, other than softmac component
> itself.
Aww dang, I already sent it to you diffed against "master".
> Wit
On Fri, 2006-03-24 at 12:12 -0800, Jean Tourrilhes wrote:
> Jouni Malinen wrote :
> >
> > On Thu, Mar 23, 2006 at 08:16:04PM -0500, Dan Williams wrote:
> > > That's why wireless-tools and Wireless Extensions switched to
> > > passive scanning.
> >
> > Can you please point to some documentation/em
On Fri, Mar 24, 2006 at 11:41:14AM -0800, Jean Tourrilhes wrote:
> I've seen time where people said SSID when referring to the
> BSSID, so I just wanted the terminology to be without ambiguity.
Well.. It is just somewhat funny to see ESSID being used in Linux
wireless discussion when most o
Jouni Malinen wrote :
>
> On Thu, Mar 23, 2006 at 08:16:04PM -0500, Dan Williams wrote:
> > That's why wireless-tools and Wireless Extensions switched to
> > passive scanning.
>
> Can you please point to some documentation/email thread/etc. describing
> this preference to use passive scanning? I
Jouni Malinen wrote :
>
> On Fri, Mar 24, 2006 at 10:57:22AM -0500, Dan Williams wrote:
>
> > this is something that ieee80211 does that's completely wrong.
> > Drivers need to report the _exact_ ESSID from the air in their scan
> > results. It's up to the user space app to deal with ESSID leng
On Fri, Mar 24, 2006 at 11:24:35AM -0800, Stephen Hemminger wrote:
> On Fri, 24 Mar 2006 18:48:37 +
> fs <[EMAIL PROTECTED]> wrote:
>
> > On Fri, Mar 24, 2006 at 10:40:00AM -0800, Stephen Hemminger wrote:
> > > > Maybe the hang I notice is different because it stays with this patch
> > > > and
On Fri, 24 Mar 2006 18:48:37 +
fs <[EMAIL PROTECTED]> wrote:
> On Fri, Mar 24, 2006 at 10:40:00AM -0800, Stephen Hemminger wrote:
> > > Maybe the hang I notice is different because it stays with this patch
> > > and appears primarily after using multiple connections.
> > >
> > > An easy way t
On Fri, 24 Mar 2006 10:58:44 -0800
"Ron Mercer" <[EMAIL PROTECTED]> wrote:
> > * Use existing MII code and interface
>
> Do you mean support for the get/set IOCTLS SIOCGMIIREG/SIOCSMIIREG?
>
>
>
If you can look at using mii.c and include/linux/mii.h.
Not all drivers can, and the interface is
- Original Message -
From: "Patrick McHardy" <[EMAIL PROTECTED]>
To: "Adrian Bunk" <[EMAIL PROTECTED]>
Cc: ; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; "Jing Min Zhao"
<[EMAIL PROTECTED]>;
Sent: Thursday, March 23, 2006 9:02 PM
Subject: Re: Two comments on the H.323 conntrack/NAT help
> * Use existing MII code and interface
Do you mean support for the get/set IOCTLS SIOCGMIIREG/SIOCSMIIREG?
-
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
On Fri, Mar 24, 2006 at 10:40:00AM -0800, Stephen Hemminger wrote:
> > Maybe the hang I notice is different because it stays with this patch
> > and appears primarily after using multiple connections.
> >
> > An easy way to reproduce it here is this
> >
> > axel -n 40 http://..file (a downloader
On Fri, 24 Mar 2006 18:18:57 +
michael <[EMAIL PROTECTED]> wrote:
> On Fri, Mar 24, 2006 at 09:38:44AM -0800, Stephen Hemminger wrote:
> > On Fri, 24 Mar 2006 17:14:49 +
> > michael <[EMAIL PROTECTED]> wrote:
> >
> > > transfer of data hangs with sky2 very often on a
> > >
> > > :02
On Fri, Mar 24, 2006 at 09:38:44AM -0800, Stephen Hemminger wrote:
> On Fri, 24 Mar 2006 17:14:49 +
> michael <[EMAIL PROTECTED]> wrote:
>
> > transfer of data hangs with sky2 very often on a
> >
> > :02:00.0 Ethernet controller: Marvell Technology Group
> > Ltd. 88E8036 Fast Ethernet Co
On Fri, Mar 24, 2006 at 12:38:40PM -0500, Dan Williams wrote:
> However, the problem with active scanning is that you have to power up
> the transmit components of the radio, while passive scanning, even
> though it takes a bit longer, doesn't necessarily require that. Active
> scanning takes mor
Stephen Hemminger wrote:
On Fri, 24 Mar 2006 11:47:29 -0500
John Heffner <[EMAIL PROTECTED]> wrote:
This patch sets the maximum TCP buffer sizes (available to automatic buffer
tuning, not to setsockopt) based on the TCP memory pool size. The maximum
sndbuf and rcvbuf each will be up to 4 MB,
James Ketrenos wrote:
> In light of the above, I started playing with a raw packet interface on
> the ipw2200 and ipw3945 projects that export all frames to user space in
> radiotap format through a 2nd network device. I am working on changing
> the way the raw packet interface is configured to b
On Fri, 2006-03-24 at 08:28 -0800, Jouni Malinen wrote:
> On Thu, Mar 23, 2006 at 08:16:04PM -0500, Dan Williams wrote:
>
> > fixed it. Active scanning has been out of vogue as the default scan
> > method for like 2 years with wireless-tools/WE, I'm not sure why softmac
> > thinks it should be di
On Fri, 24 Mar 2006 17:14:49 +
michael <[EMAIL PROTECTED]> wrote:
> transfer of data hangs with sky2 very often on a
>
> :02:00.0 Ethernet controller: Marvell Technology Group
> Ltd. 88E8036 Fast Ethernet Controller (rev 10)
>
> found on toshiba laptops,
>
> when using 2.6.16, which p
On Fri, Mar 24, 2006 at 11:05:02AM -0600, James Ketrenos wrote:
> Since the scan results are supposed to report networks found; the first
> agreement we need to make between user space and the kernel is how we
> define a 'network', and how do we determine when a network has been
> updated?
Whenev
transfer of data hangs with sky2 very often on a
:02:00.0 Ethernet controller: Marvell Technology Group
Ltd. 88E8036 Fast Ethernet Controller (rev 10)
found on toshiba laptops,
when using 2.6.16, which proves a critical problem since the proprietary
driver does not support .16 at the momen
On Fri, 2006-03-24 at 11:05 -0600, James Ketrenos wrote:
> Dan Williams wrote:
> > this is something that ieee80211 does that's completely wrong.
>
> See (untested) attached to change ieee80211 to expose the SSID as received.
Patch looks good to me in principle. All I'm objecting to is the
whe
On Fri, 24 Mar 2006 11:47:29 -0500
John Heffner <[EMAIL PROTECTED]> wrote:
> This patch sets the maximum TCP buffer sizes (available to automatic buffer
> tuning, not to setsockopt) based on the TCP memory pool size. The maximum
> sndbuf and rcvbuf each will be up to 4 MB, but no more than 1/12
Main thing is the ne2k-pci build fix.
Please pull from 'upstream-linus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git
to receive the following updates:
drivers/net/arm/Kconfig |8
drivers/net/arm/Makefile
Dan Williams wrote:
> this is something that ieee80211 does that's completely wrong.
Because it is not a part of the 802.11 specification, AP vendors have
each implemented their own method for disguising the SSID. Some set the
length to the actual SSID length but put fill the SSID with '\0', som
On Fri, 2006-03-24 at 10:57 -0500, Dan Williams wrote:
> this is something that ieee80211 does that's completely
> wrong. Drivers need to report the _exact_ ESSID from the air in their
> scan results. It's up to the user space app to deal with ESSID length
> of 0.
That makes a lot of sense.
On
On Fri, Mar 24, 2006 at 09:36:09PM +0500, Alexander E. Patrakov wrote:
> In linux-2.6.16, it is possible to compile spectrum_cs.ko without enabling
> firmware loader. Result:
>
> WARNING: /lib/modules/2.6.16/kernel/drivers/net/wireless/spectrum_cs.ko
> needs unknown symbol request_firmware
Than
This patch sets the maximum TCP buffer sizes (available to automatic buffer
tuning, not to setsockopt) based on the TCP memory pool size. The maximum
sndbuf and rcvbuf each will be up to 4 MB, but no more than 1/128 of the
memory pressure threshold.
Signed-off-by: John Heffner <[EMAIL PROTECTE
On Fri, Mar 24, 2006 at 10:57:22AM -0500, Dan Williams wrote:
> this is something that ieee80211 does that's completely wrong.
> Drivers need to report the _exact_ ESSID from the air in their scan
> results. It's up to the user space app to deal with ESSID length of 0.
I agree that "" should no
On Thu, Mar 23, 2006 at 08:16:04PM -0500, Dan Williams wrote:
> fixed it. Active scanning has been out of vogue as the default scan
> method for like 2 years with wireless-tools/WE, I'm not sure why softmac
> thinks it should be different here. Active scanning takes more power
> anyway, since yo
On Thu, Mar 23, 2006 at 10:43:38PM +, David Woodhouse wrote:
> This patch makes us default to 11M, which ought to work for most people.
Is this code supposed to work with IEEE 802.11a (which would also use
OFDM modulation)? If yes, please note that 11 Mbps is not a valid IEEE
802.11a TX rate.
Sorry the patch looks corrupted so I repost with attachment.
Jean-Mickael
--
[IPV6] ip6ip6_tnl_dst_check() : invalidate dst cache whenever xfrm
policies change
Signed-off-by: [EMAIL PROTECTED]
diff --git a/include/net/ip6_tunnel.h b/include/net/ip6_tunnel.h
index 29c9da7..5bc6e98 100644
---
this is something that ieee80211 does that's completely wrong.
Drivers need to report the _exact_ ESSID from the air in their scan
results. It's up to the user space app to deal with ESSID length of 0.
Signed-off-by: Dan Williams <[EMAIL PROTECTED]>
--- net/ieee80211/ieee80211_wx.c2006-
Hello evebody.
I get this error on linux vanilla 2.6.16
with via_rhine module loaded when
I run mii-tool:
cheduling while atomic: mii-tool/0x0001/923
[] schedule+0x632/0x640
[] schedule_timeout+0x57/0xb0
[] process_timeout+0x0/0x10
[] msleep+0x28/0x30
[] rhine_disable_linkmon+0xab/0x130 [via
In ip6ip6_tnl_xmit(), we do not xfrm_lookup() when the dst has been
stored in cache.
If cache is filled before a security policy such ipsec transport mode on
end points
is added, and no routing changes happen, how to invalidate the cache to
trigger a
new xfrm_lookup()?
I would check flow_cache
Walt wrote:
> Nope, it was the second one: Skip phy power down...
> Let me know if can test any patches, etc.
It doesn't make sense. This code should have no effect on your
5702. With or without this patch, the 5702 will be powered down
the same with tg3_writephy(tp, MII_BMCR, BMCR_PDOWN) if WOL
On Fri, 2006-03-24 at 14:08 +0100, Johannes Berg wrote:
> On Fri, 2006-03-24 at 07:58 -0500, Dan Williams wrote:
>
> > Ok, so why is softmac doing an active scan, per my previous email
> > message? Why is it not doing passive scan for normal SIOCSIWSCAN like
> > most every other driver? (to be h
On Fri, Mar 24, 2006 at 09:11:58AM -0500, jamal wrote:
> On Fri, 2006-24-03 at 07:02 +0530, Balbir Singh wrote:
> > On Thu, Mar 23, 2006 at 09:04:46AM -0500, jamal wrote:
>
> > 3. nlmsg_new() now allocates for 2*u32 + sizeof(taskstats)
>
> Not the right size; the u32 covers the V part of TLV. The
On Fri, Mar 24, 2006 at 09:04:21AM -0500, jamal wrote:
> On Thu, 2006-23-03 at 21:11 +0530, Balbir Singh wrote:
> > On Thu, Mar 23, 2006 at 09:04:46AM -0500, jamal wrote:
>
> > > Should there be at least either a pid or tgid? If yes, you need to
> > > validate here...
> > >
> >
> > Yes, you are c
On Fri, 2006-24-03 at 09:11 -0500, jamal wrote:
> Look at using proper macros instead of hard coding like you did.
> grep for something like RTA_SPACE and perhaps send a patch to make it
> generic for netlink.h
>
actually Thomas already has this in netlink.h
Look at using things like:
nla_attr_s
On Thu, 2006-23-03 at 21:11 +0530, Balbir Singh wrote:
> On Thu, Mar 23, 2006 at 09:04:46AM -0500, jamal wrote:
> > Should there be at least either a pid or tgid? If yes, you need to
> > validate here...
> >
>
> Yes, you are correct. One of my test cases caught it too.. But I did
> not want to un
On Fri, 2006-24-03 at 07:02 +0530, Balbir Singh wrote:
> On Thu, Mar 23, 2006 at 09:04:46AM -0500, jamal wrote:
> 3. nlmsg_new() now allocates for 2*u32 + sizeof(taskstats)
Not the right size; the u32 covers the V part of TLV. The T = 16 bits
and L = 16 bits. And if you nest TLVs, then it gets mo
On Fri, Mar 24, 2006 at 08:15:24AM -0500, John W. Linville wrote:
> If you think it is ready, go ahead and post the master-based branches
> here.
s/branches/patches/
--
John W. Linville
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message
On Thu, Mar 23, 2006 at 09:05:24PM -0800, Pete Zaitcev wrote:
> On Thu, 23 Mar 2006 14:06:24 -0500, "John W. Linville" <[EMAIL PROTECTED]>
> wrote:
>
> > Pete, I couldn't get this to apply. It seemed like there was a
> > mismatch between your codebase and mine.
>
> I removed my repository and c
On Fri, 2006-03-24 at 07:58 -0500, Dan Williams wrote:
> Ok, so why is softmac doing an active scan, per my previous email
> message? Why is it not doing passive scan for normal SIOCSIWSCAN like
> most every other driver? (to be honest, I'm not entirely sure what ipw
> is doing here, but I think
On Fri, 2006-03-24 at 10:18 +, David Woodhouse wrote:
> On Thu, 2006-03-23 at 20:16 -0500, Dan Williams wrote:
> > Ok, that's cool. Wasn't apparent to me from the initial message. But
> > does that mean that softmac is doing the scanning with _probe_ requests
> > on each channel? It's not do
Hi,
When ip6_tunnel discards a packet because there is no tunnel
associated with it, it sends a ICMPV6_DEST_UNREACH error to the packet
source. However, when using ip6_tunnel and xfrm6_tunnel, if there is a
a tunnel spi allocated for it, it may be processed dispite ip6_tunnel
having already
Michael Chan wrote:
> On Thu, 2006-03-23 at 14:16 -0800, walt wrote:
>
>> tg3.c:v3.53 (Mar 22, 2006)
>> PCI: Enabling device :00:09.0 (0014 -> 0016)
>> ACPI: PCI Interrupt :00:09.0[A] -> GSI 18 (level, low) -> IRQ 17
>> tg3: Could not obtain valid ethernet address, aborting.
>> ACPI: PCI i
On Thu, Feb 16, 2006 at 10:04:14PM +0200, Ilia Sotnikov wrote:
>
> Here it is, against 2.6.16-rc3.
OK, I've brought this patch up-to-date with 2.6.16 and got rid of a few
more references to tos in ip_rt_redirect. Please note that the author
of this patch is Ilia Sotnikov <[EMAIL PROTECTED]>.
Fr
Hi,
This patch fixes a soft lockup in ip6_tunnel when not using
xfrm6_tunnel (CONFIG_INET6_TUNNEL). It is triggered when an encapsula-
ted packet reaches ip6ip6_rcv() and there is no tunnel associated with
it. The error path returns a positive value (1) which will trigger
ip6_input to re-su
> When xfrm6_tunnel is in use you've just made it use a freed skb. Also
> IPv4 has the same problem so we shold fix them both.
I didn't hit this since i'm not currently using xfrm6_tunnel (which
is also why i got the soft lockup). I'll consider the case when
xfrm6_tunnel is being used, and s
On Thu, 2006-03-23 at 20:16 -0500, Dan Williams wrote:
> Ok, that's cool. Wasn't apparent to me from the initial message. But
> does that mean that softmac is doing the scanning with _probe_ requests
> on each channel? It's not doing passive scanning?
Right. It's an active scan.
--
dwmw2
-
T
This patch adds support for the Ethernet controller integrated in the
Atmel AT91RM9200 SoC processor.
Changes since the previous submission (01/02/2006) are:
- Make use of the clk.h clock infrastructure.
- The multicast hash function is not crc32. [Patch by Pedro Perez]
Signed-off-by: Andrew
David S. Miller wrote:
> From: Andrew Morton <[EMAIL PROTECTED]>
> Date: Thu, 23 Mar 2006 21:51:24 -0800
>
>
>>How come?
>
>
> Because you can't enable ebt_ulog and ebt_log at the same time.
>
> All of the ULOG targets are obsolete, but are kept around for
> compatability.
>
> It's problemati
On 3/24/06, Zhu Yi <[EMAIL PROTECTED]> wrote:
> On Thu, 2006-03-23 at 15:02 +0100, Alessandro Suardi wrote:
> > That scp test shows 50%ish - but that was a quickie. The VNC
> > client even reported a 719Kbps throughput down from the more
> > usual 11500Kbps it starts off with. The first scp I tri
David Boggs <[EMAIL PROTECTED]> writes:
> If you insist, I will run it through scripts/Lindent before submitting.
I will not but others may do. Standard formatting is just better and
the cost is near zero.
> The same two source files compile on Linux, FreeBSD, NetBSD and
> OpenBSD. I intend to
[patch 6/6] s390: remove tty support from ctc network device driver [2/2]
From: Peter Tiedemann <[EMAIL PROTECTED]>
[2/2]: remove ctctty.c and ctctty.h files .
Signed-off-by: Frank Pavlic <[EMAIL PROTECTED]>
diffstat:
drivers/s390/net/ctctty.c | 1259 --
[patch 5/6] s390: remove tty support from ctc network device driver [1/2]
From: Peter Tiedemann <[EMAIL PROTECTED]>
[1/2]:
tty support code will be removed from the ctc network device driver.
Today we have a couple of alternatives which are performing much
better.
On Wed, 22 Mar 2006 20:30:31 -0500
Jeff Garzik <[EMAIL PROTECTED]> wrote:
> Frank Pavlic wrote:
> > [patch 2/6] s390: qeth driver statistics fixes
> >
> > From: Ursula Braun <[EMAIL PROTECTED]>
> > - display "unsigned int" values in /proc/qeth_perf with %u instead of %i
> > - omit qdio h
1 - 100 of 101 matches
Mail list logo
