* how to do probabilistic packet loss in kernel?
From: George P Nychis @ 2006-04-16 22:44 UTC (permalink / raw)
To: lartc, netdev
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?
I don't need help with the actual code, just need help finding where to insert this code :)
Thanks!
George
^ permalink raw reply
* Re: r8169 locks up in 2.6.16.5
From: Thomas A. Oehser @ 2006-04-16 22:58 UTC (permalink / raw)
To: Francois Romieu; +Cc: Thomas A. Oehser, netdev
In-Reply-To: <20060416195327.GA14173@electric-eye.fr.zoreil.com>
[-- Attachment #1: Type: text/plain, Size: 1430 bytes --]
> How much long was the card under load ? A few seconds ?
> The same 1500 bytes mtu is used everywhere and the issue can not be
> reproduced with a simple ping -f -q -l 64 -s what_you_want aimed at
> the 8169, right ?
Correct,
> > What next?
>
> ethtool -d/-S before and after failure, .config and /proc/interrupts.
Ok, here it all is, the attached archive has:
- .before is right after the interface came up
- .mid is after flooding it with ping -f commands from 2 machines at once
- .bad is after doing the cpio over nc that killed it after 170MB
- .back is after ifconfig down / ifconfig up that restored it
Note, the kernel config has SMP etc turned back on, as it doesn't
seem to affect things, and the eepro100 back on eth0, I'm testing
this against eth1 so that the machine can be normally useful as well...
r8169-bad/ifconfig.before
r8169-bad/dmesg.before
r8169-bad/arp-n.before
r8169-bad/ethtool-d.before
r8169-bad/ethtool-S.before
r8169-bad/config.gz
r8169-bad/proc-interrupts.before
r8169-bad/ping-during
r8169-bad/dmesg.mid
r8169-bad/arp-n.mid
r8169-bad/ifconfig.mid
r8169-bad/ethtool-d.mid
r8169-bad/ethtool-S.mid
r8169-bad/proc-interrupts.mid
r8169-bad/ifconfig.bad
r8169-bad/dmesg.bad
r8169-bad/ethtool-d.bad
r8169-bad/ethtool-S.bad
r8169-bad/proc-interrupts.bad
r8169-bad/ifconfig.back
r8169-bad/dmesg.back
r8169-bad/ethtool-d.back
r8169-bad/ethtool-S.back
r8169-bad/proc-interrupts.back
-Thanks, -Tom
[-- Attachment #2: r8169-bad.tar.bz2 --]
[-- Type: application/octet-stream, Size: 18535 bytes --]
^ permalink raw reply
* [PATCH][RFC] softmac: suggest TX rate
From: Daniel Drake @ 2006-04-17 0:28 UTC (permalink / raw)
To: Johannes Berg; +Cc: softmac-dev, netdev, Ulrich Kunitz
[-- Attachment #1: Type: text/plain, Size: 1520 bytes --]
While developing the ZD1211 driver we realised how much we'd like to be
advised from the upper layers which rate to transmit a packet at.
An example: We have a frame to transmit. What rate should we transmit it
at? While taking any user-specified rate into account too, we want to
transmit it at a rate supported by the access point, but that
information is not available to us (softmac handled all scanning and
association, so we don't know anything about the AP capabilities).
Here is a patch I cooked up, which implements some basic logic for
suggesting TX rates based on the packet type, whether it is
multicast/unicast, whether we are associated, and the current
user-specified default_rate.
I'm still uncertain where this functionality should fit into the stack.
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.
Passing an extra parameter to hard_start_xmit would involve modifying
ieee80211, and ieee80211 doesn't seem to have any concept of whether it
is associated or not (plus softmac only does that loosely). So that
might lead us on to do something silly like wrapping hard_start_xmit
inside softmac, etc etc...
Note that even in it's current form, this patch eliminates an annoying
(and inaccurate) chunk of code from our driver.
Ideas/comments?
[-- Attachment #2: patch --]
[-- Type: text/plain, Size: 3457 bytes --]
--- linux/net/ieee80211/softmac/ieee80211softmac_module.c.orig 2006-04-17 01:04:42.000000000 +0100
+++ linux/net/ieee80211/softmac/ieee80211softmac_module.c 2006-04-17 00:44:36.000000000 +0100
@@ -26,6 +26,7 @@
#include "ieee80211softmac_priv.h"
#include <linux/sort.h>
+#include <linux/etherdevice.h>
struct net_device *alloc_ieee80211softmac(int sizeof_priv)
{
@@ -315,6 +316,48 @@ static int rate_cmp(const void *a_, cons
return ((*a & ~IEEE80211_BASIC_RATE_MASK) - (*b & ~IEEE80211_BASIC_RATE_MASK));
}
+static u8 suggest_rate_from_associnfo(struct ieee80211softmac_device *mac)
+{
+ struct ieee80211softmac_ratesinfo *net_rates = &mac->associnfo.supported_rates;
+ u8 net_max;
+
+ if (unlikely(net_rates->count == 0)) {
+ dprintkl(KERN_ERROR PFX "suggest_rate: Network has no rates?\n");
+ return IEEE80211_CCK_RATE_1MB;
+ }
+
+ /* FIXME: we need to check that the rate is supported in mac->ratesinfo */
+ net_max = net_rates->rates[net_rates->count - 1];
+ return min(mac->txrates.default_rate, net_max);
+}
+
+u8 ieee80211softmac_suggest_tx_rate(struct ieee80211softmac_device *mac,
+ struct ieee80211_hdr_1addr *hdr)
+{
+ switch (WLAN_FC_GET_TYPE(le16_to_cpu(hdr->frame_ctl))) {
+ case IEEE80211_FTYPE_MGMT:
+ /*
+ * If we aren't associated, or we are multicasting, then
+ * stick to 1MB for safety.
+ */
+ if (!mac->associated || is_multicast_ether_addr(hdr->addr1))
+ return IEEE80211_CCK_RATE_1MB;
+
+ /* Otherwise, we can send at the speed of the AP. */
+ return suggest_rate_from_associnfo(mac);
+ 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);
+ default:
+ dprintkl(KERN_ERROR PFX "suggest_tx_rate: Unhandled ftype %x\n", ftype);
+ return IEEE80211_CCK_RATE_1MB;
+ }
+}
+EXPORT_SYMBOL_GPL(ieee80211softmac_suggest_tx_rate);
+
/* Allocate a softmac network struct and fill it from a network */
struct ieee80211softmac_network *
ieee80211softmac_create_network(struct ieee80211softmac_device *mac,
--- linux/net/ieee80211/softmac/ieee80211softmac_assoc.c.orig 2006-04-16 23:55:23.000000000 +0100
+++ linux/net/ieee80211/softmac/ieee80211softmac_assoc.c 2006-04-16 23:55:39.000000000 +0100
@@ -283,6 +283,7 @@ ieee80211softmac_associated(struct ieee8
struct ieee80211softmac_network *net)
{
mac->associnfo.associating = 0;
+ mac->associnfo.supported_rates = net->supported_rates;
mac->associated = 1;
if (mac->set_bssid_filter)
mac->set_bssid_filter(mac->dev, net->bssid);
--- linux/include/net/ieee80211softmac.h.orig 2006-04-16 23:37:32.000000000 +0100
+++ linux/include/net/ieee80211softmac.h 2006-04-17 00:44:47.000000000 +0100
@@ -86,6 +86,9 @@ struct ieee80211softmac_assoc_info {
/* BSSID we're trying to associate to */
char bssid[ETH_ALEN];
+
+ /* Rates supported by the network */
+ struct ieee80211softmac_ratesinfo supported_rates;
/* some flags.
* static_essid is valid if the essid is constant,
@@ -246,6 +249,8 @@ extern void ieee80211softmac_fragment_lo
* Note that the rates need to be sorted. */
extern void ieee80211softmac_set_rates(struct net_device *dev, u8 count, u8 *rates);
+extern u8 ieee80211softmac_suggest_tx_rate(struct ieee80211softmac_device *mac, struct ieee80211_hdr_1addr *hdr);
+
/* Start the SoftMAC. Call this after you initialized the device
* and it is ready to run.
*/
^ permalink raw reply
* Re: [PATCH][RFC] softmac: suggest TX rate
From: Ulrich Kunitz @ 2006-04-17 0:33 UTC (permalink / raw)
To: Daniel Drake; +Cc: Johannes Berg, softmac-dev, netdev, Ulrich Kunitz
In-Reply-To: <4442E13E.80507@gentoo.org>
On Mon, 17 Apr 2006, Daniel Drake wrote:
> While developing the ZD1211 driver we realised how much we'd like to be
> advised from the upper layers which rate to transmit a packet at.
>
> An example: We have a frame to transmit. What rate should we transmit it at?
> While taking any user-specified rate into account too, we want to transmit it
> at a rate supported by the access point, but that information is not available
> to us (softmac handled all scanning and association, so we don't know anything
> about the AP capabilities).
>
> Here is a patch I cooked up, which implements some basic logic for suggesting
> TX rates based on the packet type, whether it is multicast/unicast, whether we
> are associated, and the current user-specified default_rate.
>
> I'm still uncertain where this functionality should fit into the stack.
>
> 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.
>
> Passing an extra parameter to hard_start_xmit would involve modifying
> ieee80211, and ieee80211 doesn't seem to have any concept of whether it is
> associated or not (plus softmac only does that loosely). So that might lead us
> on to do something silly like wrapping hard_start_xmit inside softmac, etc
> etc...
>
> Note that even in it's current form, this patch eliminates an annoying (and
> inaccurate) chunk of code from our driver.
>
> Ideas/comments?
>
--
Ulrich Kunitz - kune@deine-taler.de
^ permalink raw reply
* 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
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