* Re: [PATCH][RFC] softmac: suggest TX rate
From: Ulrich Kunitz @ 2006-04-17 0:40 UTC (permalink / raw)
To: Ulrich Kunitz; +Cc: Daniel Drake, Johannes Berg, softmac-dev, netdev
In-Reply-To: <Pine.LNX.4.58.0604170230400.32281@p15091797.pureserver.info>
On Mon, 17 Apr 2006, Ulrich Kunitz wrote:
Oops! Sorry, but sometime ^X and ^C are to near to each other.
I just wanted to say, I agree with the approach, but wonder how
transmission timeouts come into play here, which should lead to a
decrease of the tranmission rate.
Daniel the patches on branch softmac-suggest-txrate look good!
Regards,
Uli
--
Ulrich Kunitz - kune@deine-taler.de
^ permalink raw reply
* Re: [PATCH][RFC] softmac: suggest TX rate
From: Daniel Drake @ 2006-04-17 1:02 UTC (permalink / raw)
To: Ulrich Kunitz; +Cc: Johannes Berg, softmac-dev, netdev
In-Reply-To: <Pine.LNX.4.58.0604170235020.32457@p15091797.pureserver.info>
Ulrich Kunitz wrote:
> I just wanted to say, I agree with the approach, but wonder how
> transmission timeouts come into play here, which should lead to a
> decrease of the tranmission rate.
That's a separate issue, to do with rate management, which I'm not
tackling yet. Note that the functions in my patch can easily be extended
to bring rate management into the equation.
Daniel
^ permalink raw reply
* Re: [PATCH] Fix crash on big-endian systems during scan
From: Jouni Malinen @ 2006-04-17 1:06 UTC (permalink / raw)
To: John W. Linville; +Cc: netdev, hostap, Pavel Roskin
In-Reply-To: <20060414215911.17273.40460.stgit@dv.roinet.com>
On Fri, Apr 14, 2006 at 05:59:11PM -0400, Pavel Roskin wrote:
> The original code was doing arithmetics on a little-endian value.
John, please apply this to wireless-2.6 tree. This code is triggered at
least for the case where WPA is not used. I had noticed it before, but I
think I've only tested WPA/WPA2 on big endian systems..
--
Jouni Malinen PGP id EFC895FA
^ permalink raw reply
* Re: how to do probabilistic packet loss in kernel?
From: Ian McDonald @ 2006-04-17 2:10 UTC (permalink / raw)
To: George P Nychis; +Cc: lartc, netdev
In-Reply-To: <4902.128.2.140.224.1145227461.squirrel@128.2.140.224>
On 4/17/06, George P Nychis <gnychis@cmu.edu> wrote:
> Hi,
>
> I am using iproute2 to setup fowarding, adding routes like "ip route add 192.168.1.3 via 192.168.1.2"
>
> I was wondering where in the kernel I can insert probabilistic packet loss only for forwarded packets? So that for instance I can drop 5% of all forwarded packets?
>
Have a look at:
http://linux-net.osdl.org/index.php/Netem
--
Ian McDonald
Web: http://wand.net.nz/~iam4
Blog: http://imcdnzl.blogspot.com
WAND Network Research Group
Department of Computer Science
University of Waikato
New Zealand
^ permalink raw reply
* Re: [PATCH] ipw2100: wraps the debug module param within #ifdefs
From: Zhu Yi @ 2006-04-17 2:17 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev, John W. Linville
In-Reply-To: <20060414093307.3ff1c016@localhost.localdomain>
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
^ permalink raw reply
* Re: skb diet
From: David S. Miller @ 2006-04-17 5:25 UTC (permalink / raw)
To: ak; +Cc: hkotry, netdev
In-Reply-To: <200604161716.31276.ak@suse.de>
From: Andi Kleen <ak@suse.de>
Date: Sun, 16 Apr 2006 17:16:31 +0200
> On Sunday 16 April 2006 14:56, Hisham Kotry wrote:
> > > Linux 2.0 did something like this, but that was removed for good
> > > reasons. Now TCP always clones skbs before sending it out.
> >
> > Do you remember what those reasons were? I couldn't find a related
> > discussion in the archives. I think the BSD mbuf tags approach is
> > sound enough to justify the move.
>
> From your description so far it seems to only have disadvantages.
I totally agree, tags are very stupid.
I only brought them up long as food-for-thought, not as a very
serious candidate for implementation.
Indirection is a performance killer, and we've seen this time and
time again in the past. Tags add more indirection for questionable
gains.
^ permalink raw reply
* Re: fixing sk_stream_rfree()
From: David S. Miller @ 2006-04-17 5:32 UTC (permalink / raw)
To: herbert; +Cc: netdev
In-Reply-To: <20060416111831.GA15093@gondor.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Sun, 16 Apr 2006 21:18:31 +1000
> Great eyes! Yes that bug seems to have been around forever. I'll
> look over the patch tomorrow as right now I'm still on west-coast
> time :)
Let me save you some time, later in the thread you'll find
out that this whole thing is a dead end.
The reason is that all SKBs are unshared when we receive them
into the TCP stack for sk->sk_receive_queue. (this is done
by ip_rcv()).
This means every __kfree_skb() call would happen in the context
of the TCP stack with the socket locked, so no concurrency issues
wrt. sk_forward_alloc as I originally thought.
In fact, this is what makes using __kfree_skb() explicitly legal
in the first place. If skb->users could be non-zero, from tcpdump
etc., then we'd be required to call kfree_skb() in the TCP code
that frees up used packets on the receive queue.
But all is not lost, this is an important datapoint. We've audited
the receive side accesses to sk_forward_alloc and it all looks good.
And again, as you mention, we go back again to TSO being the deciding
factor in triggering this or not.
So it nearly has to be a send side issue that can only trigger with
TSO enabled, and my next planned chore is to audit the TSO splitting
during ACK processing. We may be doing something stupid there.
^ permalink raw reply
* Re: fixing sk_stream_rfree()
From: Herbert Xu @ 2006-04-17 6:17 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev
In-Reply-To: <20060416.223203.47773632.davem@davemloft.net>
On Sun, Apr 16, 2006 at 10:32:03PM -0700, David S. Miller wrote:
>
> Let me save you some time, later in the thread you'll find
> out that this whole thing is a dead end.
Thanks. I even read the message but managed to miss your conclusion :)
> So it nearly has to be a send side issue that can only trigger with
> TSO enabled, and my next planned chore is to audit the TSO splitting
> during ACK processing. We may be doing something stupid there.
BTW, do we have a dmesg log from the machine that did this with tg3?
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* want to randomly drop packets based on percent
From: George Nychis @ 2006-04-17 7:38 UTC (permalink / raw)
To: linux-kernel; +Cc: netdev
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%
however i keep getting the error
RTNETLINK answer: Invalid argument
I am not sure how to go about solving this problem for now, so if anyone
has any suggestions i'd greatly appreciate it.
I really only need to drop random packets being forwarded through
ip_forward ... however randomly dropping any packet based on a % is
sufficient so I figured netem would be great.
So in the meantime I figured I would try to insert packet loss in
ip_forward.c by generating a random number and dropping based on that.
I could goto drop; depending on the number in the function int
ip_forward(struct sk_buff *skb)
But then I ran into the problem of properly seeding the random number
generator... srand(time(0)) is one way... however time() returns
seconds, therefore i would drop multiple packets in a single second if I
used this method which is very undesirable. What is the proper way to
generate a random number here?
Thanks!
George
^ permalink raw reply
* Re: [PATCH][RFC] softmac: suggest TX rate
From: Johannes Berg @ 2006-04-17 9:16 UTC (permalink / raw)
To: Daniel Drake; +Cc: netdev, softmac-dev, Ulrich Kunitz
In-Reply-To: <4442E13E.80507@gentoo.org>
[-- Attachment #1: Type: text/plain, Size: 959 bytes --]
On Mon, 2006-04-17 at 01:28 +0100, Daniel Drake wrote:
> Rather than having to explicitly call ieee80211softmac_suggest_tx_rate()
> from the driver's hard_start_xmit function, it would be nicer if the
> suggested rate was passed as a parameter. But not all drivers would need
> it, so maybe the extra calculations should be controlled by a new flag.
Couldn't we just initialise the softmac txrates substructure to
something useful when associating, and have drivers look into that
instead?
> + case IEEE80211_FTYPE_DATA:
> + if (unlikely(!mac->associated)) {
> + dprintkl(KERN_ERROR PFX "suggest_tx_rate: Not associated\n");
> + return IEEE80211_CCK_RATE_1MB;
> + }
> + return suggest_rate_from_associnfo(mac);
This isn't correct. Here, you have to take into account multicast frames
because those require clamping the rate to the highest rate from the
basic rateset.
I'll try to come up with an alternative.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]
^ permalink raw reply
* [1/1] netlink: fix broadcasting to the wrong group.
From: Evgeniy Polyakov @ 2006-04-17 9:36 UTC (permalink / raw)
To: David S. Miller; +Cc: Patrick McHardy, netdev
[-- Attachment #1: Type: text/plain, Size: 2056 bytes --]
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.
Tested with different groups (less than 32 though).
With patch applied it is required to subscribe to any group one wants to
listen to.
Patch is against 2.6.16
Signed-off-by: Evgeniy Polyakov <johnpol@2ka.mipt.ru>
diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c
index 59dc7d1..895958b 100644
--- a/net/netlink/af_netlink.c
+++ b/net/netlink/af_netlink.c
@@ -588,7 +588,6 @@ static int netlink_bind(struct socket *s
netlink_update_subscriptions(sk, nlk->subscriptions +
hweight32(nladdr->nl_groups) -
hweight32(nlk->groups[0]));
- nlk->groups[0] = (nlk->groups[0] & ~0xffffffffUL) | nladdr->nl_groups;
netlink_table_ungrab();
return 0;
--
Evgeniy Polyakov
[-- Attachment #2: nltest.c --]
[-- Type: text/plain, Size: 2533 bytes --]
/*
* nltest.c - netlink testing module.
*
* Copyright (c) 2006 Evgeniy Polyakov <johnpol@2ka.mipt.ru>
*
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
*/
#include <linux/module.h>
#include <linux/moduleparam.h>
#include <linux/skbuff.h>
#include <linux/netlink.h>
#include <net/sock.h>
static struct sock *nls;
static atomic_t nls_seq = ATOMIC_INIT(0);
static u32 nls_groups = 1;
module_param(nls_groups, uint, 0);
static unsigned int nls_pid;
static unsigned int nls_size = PAGE_SIZE;
static void nls_work_func(void *data);
static DECLARE_WORK(nls_work, nls_work_func, NULL);
static int nls_netlink_broadcast(void)
{
unsigned int size;
struct sk_buff *skb;
struct nlmsghdr *nlh;
unsigned int pid;
int ret;
size = NLMSG_SPACE(nls_size);
skb = alloc_skb(size, GFP_KERNEL);
if (!skb)
return -ENOMEM;
pid = nls_pid;
nlh = NLMSG_PUT(skb, pid, atomic_inc_return(&nls_seq), NLMSG_DONE, size - sizeof(*nlh));
NETLINK_CB(skb).dst_group = nls_groups;
ret = netlink_broadcast(nls, skb, pid, nls_groups, GFP_KERNEL);
printk("%s: group: %u, pid: %u, ret: %d.\n", __func__, nls_groups, pid, ret);
return ret;
nlmsg_failure:
kfree_skb(skb);
return -EINVAL;
}
static void nls_work_func(void *data)
{
nls_netlink_broadcast();
schedule_delayed_work(&nls_work, HZ);
}
static int nls_init(void)
{
nls = netlink_kernel_create(NETLINK_W1, 1, NULL, THIS_MODULE);
if (!nls) {
printk(KERN_ERR "Failed to create new netlink socket(%u).\n",
NETLINK_W1);
}
schedule_delayed_work(&nls_work, HZ);
return 0;
}
static void nls_fini(void)
{
cancel_rearming_delayed_work(&nls_work);
flush_scheduled_work();
if (nls && nls->sk_socket)
sock_release(nls->sk_socket);
}
module_init(nls_init);
module_exit(nls_fini);
MODULE_AUTHOR("Evgeniy Polyakov <johnpol@2ka.mipt.ru>");
MODULE_LICENSE("GPL");
MODULE_DESCRIPTION("Netlink testing module.");
[-- Attachment #3: nluser.c --]
[-- Type: text/plain, Size: 4085 bytes --]
/*
* nluser.c
*
* Copyright (c) 2006 Evgeniy Polyakov <johnpol@2ka.mipt.ru>
*
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
*/
#include <asm/types.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <sys/poll.h>
#include <sys/mman.h>
#include <sys/signal.h>
#include <sys/time.h>
#include <sys/resource.h>
#include <sys/wait.h>
#include <linux/netlink.h>
#include <linux/types.h>
#include <linux/rtnetlink.h>
#include <arpa/inet.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <string.h>
#include <errno.h>
#include <time.h>
static int need_exit;
static void usage(char *procname)
{
fprintf(stderr, "Usage: %s -l logfile -g group -p pid -s size -h\n", procname);
fprintf(stderr, " -l logfile - log file. Default stdout.\n");
fprintf(stderr, " -g group - group number used. Default 1.\n");
fprintf(stderr, " -p pid - pid number used. Default is process id.\n");
fprintf(stderr, " -s size - receiving buffer size. Default is 4096.\n");
fprintf(stderr, " -h - this help.\n");
}
static int nls_create_user(FILE *out, unsigned int size, unsigned int pid, unsigned int group)
{
struct pollfd pfd;
struct sockaddr_nl l_local;
char *buf;
int s, len, received = 0;
struct nlmsghdr *reply;
buf = malloc(size * 2); /* Should be enough to store netlink overhead. */
if (!buf)
return -ENOMEM;
s = socket(PF_NETLINK, SOCK_DGRAM, NETLINK_W1);
if (s == -1) {
perror("socket");
return -1;
}
l_local.nl_family = AF_NETLINK;
l_local.nl_groups = group;
l_local.nl_pid = pid;
if (bind(s, (struct sockaddr *)&l_local, sizeof(struct sockaddr_nl)) == -1) {
fprintf(out, "Failed to bind to pid %u: %s [%d].\n", pid, strerror(errno), errno);
close(s);
return -1;
}
len = l_local.nl_groups;
setsockopt(s, 270, 1, &len, sizeof(len));
pfd.fd = s;
while (!need_exit) {
pfd.events = POLLIN;
pfd.revents = 0;
switch (poll(&pfd, 1, -1)) {
case 0:
need_exit = 1;
break;
case -1:
if (errno != EINTR) {
need_exit = 1;
break;
}
continue;
}
if (need_exit)
break;
memset(buf, 0, 2 * size);
len = recv(s, buf, 2 * size, 0);
if (len == -1) {
perror("recv buf");
close(s);
return -1;
}
reply = (struct nlmsghdr *)buf;
fprintf(out, "%3d: pid=%u, seq=%u.\n", received, reply->nlmsg_pid, reply->nlmsg_seq);
switch (reply->nlmsg_type) {
case NLMSG_ERROR:
fprintf(out, "Error message received.\n");
break;
case NLMSG_DONE:
received++;
break;
default:
break;
}
}
close(s);
return 0;
}
int main(int argc, char *argv[])
{
int ch;
FILE *out;
char *logfile = NULL;
unsigned int size, pid, group;
size = 4096;
pid = getpid();
group = 1;
while ((ch = getopt(argc, argv, "l:g:s:p:h")) != -1) {
switch (ch) {
case 'l':
logfile = optarg;
break;
case 'g':
group = atoi(optarg);
break;
case 's':
size = atoi(optarg);
break;
case 'p':
pid = atoi(optarg);
break;
default:
case 'h':
usage(argv[0]);
return -1;
}
}
if (logfile == NULL) {
out = stdout;
logfile = "(stdout)";
} else {
out = fopen(argv[1], "a+");
if (!out) {
fprintf(stderr, "Unable to open %s for writing: %s\n",
argv[1], strerror(errno));
out = stdout;
logfile = "(stdout)";
}
}
printf("logfile: %s, size: %u, pid: %u, group: %u.\n", logfile, size, pid, group);
return nls_create_user(out, size, pid, group);
}
[-- Attachment #4: Makefile --]
[-- Type: text/plain, Size: 430 bytes --]
obj-m := nltest.o
KDIR := /lib/modules/$(shell uname -r)/build
#KDIR := /usr/local/src/linux/linux-2.6.9
#KDIR := /home/s0mbre/aWork/git/linux-2.6/linux-2.6.w1
PWD := $(shell pwd)
UCFLAGS := -I$(KDIR)/include -W -Wall
default:
$(MAKE) -C $(KDIR) SUBDIRS=$(PWD) MOD_ROOT=`pwd` modules
clean:
$(MAKE) -C $(KDIR) SUBDIRS=$(PWD) MOD_ROOT=`pwd` clean
@rm -f nluser *.o *~
nluser: nluser.c
$(CC) $(UCFLAGS) nluser.c -o nluser
^ permalink raw reply related
* Re: want to randomly drop packets based on percent
From: Bodo Eggert @ 2006-04-17 10:45 UTC (permalink / raw)
To: George Nychis, netdev, linux-kernel
In-Reply-To: <62wv1-U5-1@gated-at.bofh.it>
George Nychis <gnychis@cmu.edu> wrote:
> But then I ran into the problem of properly seeding the random number
> generator... srand(time(0)) is one way... however time() returns
> seconds, therefore i would drop multiple packets in a single second if I
> used this method which is very undesirable. What is the proper way to
> generate a random number here?
You seed the random generator once, not each time you use it.
--
Ich danke GMX dafür, die Verwendung meiner Adressen mittels per SPF
verbreiteten Lügen zu sabotieren.
^ permalink raw reply
* [PATCH] Add VLAN (802.1q) support to sis900 driver
From: Daniele Venzano @ 2006-04-17 11:25 UTC (permalink / raw)
To: NetDev
[-- Attachment #1: Type: text/plain, Size: 443 bytes --]
The attached patch adds support for VLANs to the sis900 driver and bumps
the version number. It is based on an old (2003) patch for the 2.4
series by Hamid Hashemi Golpayegani. It applies on top of 2.6.16(.5).
I have one report that it works and behaves as intended.
Please review and consider for inclusion.
Signed-off-by: Daniele Venzano <venza@brownhat.org>
--
------------------------------
Daniele Venzano
Web: http://teg.homeunix.org
[-- Attachment #2: 802q.diff --]
[-- Type: text/plain, Size: 3587 bytes --]
Index: sis900.c
===================================================================
--- a/drivers/net/sis900.c (revisione 130)
+++ b/drivers/net/sis900.c (copia locale)
@@ -1,6 +1,6 @@
/* sis900.c: A SiS 900/7016 PCI Fast Ethernet driver for Linux.
Copyright 1999 Silicon Integrated System Corporation
- Revision: 1.08.09 Sep. 19 2005
+ Revision: 1.08.10 Apr. 2 2006
Modified from the driver which is originally written by Donald Becker.
@@ -17,9 +17,10 @@
SiS 7014 Single Chip 100BASE-TX/10BASE-T Physical Layer Solution,
preliminary Rev. 1.0 Jan. 18, 1998
+ Rev 1.08.10 Apr. 2 2006 Daniele Venzano add vlan (jumbo packets) support
Rev 1.08.09 Sep. 19 2005 Daniele Venzano add Wake on LAN support
Rev 1.08.08 Jan. 22 2005 Daniele Venzano use netif_msg for debugging messages
- Rev 1.08.07 Nov. 2 2003 Daniele Venzano <webvenza@libero.it> add suspend/resume support
+ Rev 1.08.07 Nov. 2 2003 Daniele Venzano <venza@brownhat.org> add suspend/resume support
Rev 1.08.06 Sep. 24 2002 Mufasa Yang bug fix for Tx timeout & add SiS963 support
Rev 1.08.05 Jun. 6 2002 Mufasa Yang bug fix for read_eeprom & Tx descriptor over-boundary
Rev 1.08.04 Apr. 25 2002 Mufasa Yang <mufasa@sis.com.tw> added SiS962 support
@@ -77,7 +78,7 @@
#include "sis900.h"
#define SIS900_MODULE_NAME "sis900"
-#define SIS900_DRV_VERSION "v1.08.09 Sep. 19 2005"
+#define SIS900_DRV_VERSION "v1.08.10 Apr. 2 2006"
static char version[] __devinitdata =
KERN_INFO "sis900.c: " SIS900_DRV_VERSION "\n";
@@ -1400,6 +1401,11 @@
rx_flags |= RxATX;
}
+#if defined(CONFIG_VLAN_8021Q) || defined(CONFIG_VLAN_8021Q_MODULE)
+ /* Can accept Jumbo packet */
+ rx_flags |= RxAJAB;
+#endif
+
outl (tx_flags, ioaddr + txcfg);
outl (rx_flags, ioaddr + rxcfg);
}
@@ -1712,18 +1718,26 @@
while (rx_status & OWN) {
unsigned int rx_size;
+ unsigned int data_size;
if (--rx_work_limit < 0)
break;
- rx_size = (rx_status & DSIZE) - CRC_SIZE;
+ data_size = rx_status & DSIZE;
+ rx_size = data_size - CRC_SIZE;
+#if defined(CONFIG_VLAN_8021Q) || defined(CONFIG_VLAN_8021Q_MODULE)
+ /* ``TOOLONG'' flag means jumbo packet recived. */
+ if ((rx_status & TOOLONG) && data_size <= MAX_FRAME_SIZE)
+ rx_status &= (~ ((unsigned int)TOOLONG));
+#endif
+
if (rx_status & (ABORT|OVERRUN|TOOLONG|RUNT|RXISERR|CRCERR|FAERR)) {
/* corrupted packet received */
if (netif_msg_rx_err(sis_priv))
printk(KERN_DEBUG "%s: Corrupted packet "
- "received, buffer status = 0x%8.8x.\n",
- net_dev->name, rx_status);
+ "received, buffer status = 0x%8.8x/%d.\n",
+ net_dev->name, rx_status, data_size);
sis_priv->stats.rx_errors++;
if (rx_status & OVERRUN)
sis_priv->stats.rx_over_errors++;
Index: sis900.h
===================================================================
--- a/drivers/net/sis900.h (revisione 130)
+++ b/drivers/net/sis900.h (copia locale)
@@ -310,9 +310,15 @@
#define CRC_SIZE 4
#define MAC_HEADER_SIZE 14
-#define TX_BUF_SIZE 1536
-#define RX_BUF_SIZE 1536
+#if defined(CONFIG_VLAN_8021Q) || defined(CONFIG_VLAN_8021Q_MODULE)
+#define MAX_FRAME_SIZE (1518 + 4)
+#else
+#define MAX_FRAME_SIZE 1518
+#endif /* CONFIG_VLAN_802_1Q */
+#define TX_BUF_SIZE (MAX_FRAME_SIZE+18)
+#define RX_BUF_SIZE (MAX_FRAME_SIZE+18)
+
#define NUM_TX_DESC 16 /* Number of Tx descriptor registers. */
#define NUM_RX_DESC 16 /* Number of Rx descriptor registers. */
#define TX_TOTAL_SIZE NUM_TX_DESC*sizeof(BufferDesc)
^ permalink raw reply
* Re: [PATCH] Fix crash on big-endian systems during scan
From: John W. Linville @ 2006-04-17 13:21 UTC (permalink / raw)
To: netdev, hostap, Pavel Roskin
In-Reply-To: <20060417010602.GL9551@jm.kir.nu>
On Sun, Apr 16, 2006 at 06:06:02PM -0700, Jouni Malinen wrote:
> On Fri, Apr 14, 2006 at 05:59:11PM -0400, Pavel Roskin wrote:
>
> > The original code was doing arithmetics on a little-endian value.
>
> John, please apply this to wireless-2.6 tree. This code is triggered at
> least for the case where WPA is not used. I had noticed it before, but I
> think I've only tested WPA/WPA2 on big endian systems..
Can someone repost this patch? I seem to have missed it.
Thanks,
John
--
John W. Linville
linville@tuxdriver.com
^ permalink raw reply
* Re:
From: Teresa Dewitt @ 2006-04-17 14:44 UTC (permalink / raw)
To: netdev
-Sensattional revolution in medicine!
-Enlarge your penis up to 10 cm or up to 4 inches!
-It's herbal solution what hasn't side effect, but has 100% guaranted results!
-Don't lose your chance and but know wihtout doubts, you will be i`mpressed with results!
Clisk here: http://beardeddragonworld.info
everybody photogenic roomy scenic crosslink part chaotic bravura asynchronous wichita
cloven avid testamentary antisemitism blackbody dauphin gear accuse kirchner
indium religion adulthood burma expenditure attract emasculate ashen magneto degumming manuel
endogamous courageous low landau transfinite pastiche abbott solitaire
vignette sooth delight coauthor bali auckland artisan chimera
brigade ellipsometer masonry vella childbear gloucester beat peppy
^ permalink raw reply
* Re: want to randomly drop packets based on percent
From: Jan Engelhardt @ 2006-04-17 14:21 UTC (permalink / raw)
To: George Nychis; +Cc: linux-kernel, netdev
In-Reply-To: <444345F9.4090100@cmu.edu>
>
> 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 could just use the 'random' match module from netfilter/POMng, but I
doubt it will compile out-of-the-box on 2.4.32. It would then be as simple
as
iptables -t mangle -I PREROUTING -m random --average 1 -j DROP
> I really only need to drop random packets being forwarded through ip_forward
> ... however randomly dropping any packet based on a % is sufficient so I
> figured netem would be great.
Jan Engelhardt
--
^ permalink raw reply
* Re: [PATCH] Fix crash on big-endian systems during scan
From: Dan Williams @ 2006-04-17 14:34 UTC (permalink / raw)
To: John W. Linville; +Cc: netdev, hostap, Pavel Roskin
In-Reply-To: <20060417132105.GF5042@tuxdriver.com>
On Mon, 2006-04-17 at 09:21 -0400, John W. Linville wrote:
> On Sun, Apr 16, 2006 at 06:06:02PM -0700, Jouni Malinen wrote:
> > On Fri, Apr 14, 2006 at 05:59:11PM -0400, Pavel Roskin wrote:
> >
> > > The original code was doing arithmetics on a little-endian value.
> >
> > John, please apply this to wireless-2.6 tree. This code is triggered at
> > least for the case where WPA is not used. I had noticed it before, but I
> > think I've only tested WPA/WPA2 on big endian systems..
>
> Can someone repost this patch? I seem to have missed it.
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...
Dan
^ permalink raw reply
* Re: [PATCH] Fix crash on big-endian systems during scan
From: John W. Linville @ 2006-04-17 14:45 UTC (permalink / raw)
To: Dan Williams; +Cc: netdev, hostap, Pavel Roskin
In-Reply-To: <1145284443.2212.5.camel@localhost.localdomain>
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...
John
--
John W. Linville
linville@tuxdriver.com
^ permalink raw reply
* Re: [PATCH] Fix crash on big-endian systems during scan
From: Dan Williams @ 2006-04-17 15:01 UTC (permalink / raw)
To: John W. Linville; +Cc: netdev, hostap, Pavel Roskin
In-Reply-To: <20060417144541.GK5042@tuxdriver.com>
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.
Dan
^ permalink raw reply
* Re: [PATCH] Fix crash on big-endian systems during scan
From: John W. Linville @ 2006-04-17 15:17 UTC (permalink / raw)
To: Dan Williams; +Cc: netdev, hostap, Pavel Roskin
In-Reply-To: <1145286089.2649.0.camel@localhost.localdomain>
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?
John
--
John W. Linville
linville@tuxdriver.com
^ permalink raw reply
* 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
* 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: 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: 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: [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
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