* Re: [PATCH][MCAST]IPv6: small fix for ip6_mc_msfilter(...)
From: Willy Tarreau @ 2005-11-02 5:47 UTC (permalink / raw)
To: Yan Zheng; +Cc: netdev, linux-kernel, David Stevens
In-Reply-To: <7e77d27c0511010237x775529b8h@mail.gmail.com>
Hi,
On Tue, Nov 01, 2005 at 06:37:43PM +0800, Yan Zheng wrote:
> You can reproduce this bug by follow codes. This program will cause a
> change to include report even though the first socket's filter mode is
> exclude.
I've not clearly understood the nature of the bug, does it also
affect 2.4 ? Marcelo will be releasing 2.4.32 in a few days, so
it would be wise to merge the fix soon.
Regards,
Willy
^ permalink raw reply
* [PATCH 2.6.13] airo.c: remove delay in airo_get_scan
From: Bill Moss @ 2005-11-02 3:47 UTC (permalink / raw)
To: linville, netdev; +Cc: linux-kernel
Remove 3 second delay in airo_get_scan. Testing shows this delay is unnecessary. Users of NetworkManager
find this delay make NetworkManager slow to connect.
--- a/drivers/net/wireless/airo.c 2005-11-01 21:21:04.000000000 -0500
+++ b/drivers/net/wireless/airo.c 2005-11-01 21:22:41.000000000 -0500
@@ -6918,7 +6918,7 @@
/* When we are associated again, the scan has surely finished.
* Just in case, let's make sure enough time has elapsed since
* we started the scan. - Javier */
- if(ai->scan_timestamp && time_before(jiffies,ai->scan_timestamp+3*HZ)) {
+ if(ai->scan_timestamp && time_before(jiffies,ai->scan_timestamp)) {
/* Important note : we don't want to block the caller
* until results are ready for various reasons.
* First, managing wait queues is complex and racy
Signed-off-by: Bill Moss <bmoss@clemson.edu>
^ permalink raw reply
* Re: ancient ieee80211/ipw2200 drivers in recent kernel (2.6.14)
From: Alejandro Bonilla Beeche @ 2005-11-02 3:44 UTC (permalink / raw)
To: Horms; +Cc: Mikhail Gusarov, debian-kernel, NetDev, James Ketrenos
In-Reply-To: <20051102020903.GG29803@verge.net.au>
Horms wrote:
>On Tue, Nov 01, 2005 at 11:30:09PM +0600, Mikhail Gusarov wrote:
>
>
>>Hello,
>>
>>I've encountered the problem with 2.6.14 kernels: they are shipped
>>with ancient version of ipw2200 drivers (1.0.0 while current version
>>is 1.0.7) and ancient version of ieee80211 subsystem (copyrighted as
>>2004, so also outdated).
>>
>>This breaks compilation of module from ipw2200-source package (because
>>it links against in-kernel ieee80211).
>>
>>
The .deb will need to run the remove-old script included in the new
versions of the driver/stack.
>
>I assume the problem you are seeing is a headers problem.
>
>
>
>>Is there way to modularize builds to exclude ieee80211 or just disable
>>it (along with ipw2200) because it is outdated and current vesion is
>>shipped in ieee80211-source package?
>>
>>
>
>Probably the best place to start is to ping netdev to find out if
>there are any plans to update IPW2200 in Linus's tree. I've CCed
>that list, hopefully someone can shed some light on this.
>
>
>
Not really. Basically, only stable versions of the driver make it into
Mainline, and currently 1.0.8 is being tested to move into mainline
(first -mm, then when people decide move to Linus)
Basically, when installing 1.0.8 and ieee80211-1.1.5, the .deb packages
or whatever will need to run the remove-old script that is included in
the source in order to make the new versions compile.
.Alejandro
^ permalink raw reply
* Re: ancient ieee80211/ipw2200 drivers in recent kernel (2.6.14)
From: Horms @ 2005-11-02 2:09 UTC (permalink / raw)
To: Mikhail Gusarov; +Cc: debian-kernel, NetDev
In-Reply-To: <873bmg9sym.fsf@vertex.dottedmag.net>
On Tue, Nov 01, 2005 at 11:30:09PM +0600, Mikhail Gusarov wrote:
> Hello,
>
> I've encountered the problem with 2.6.14 kernels: they are shipped
> with ancient version of ipw2200 drivers (1.0.0 while current version
> is 1.0.7) and ancient version of ieee80211 subsystem (copyrighted as
> 2004, so also outdated).
>
> This breaks compilation of module from ipw2200-source package (because
> it links against in-kernel ieee80211).
I assume the problem you are seeing is a headers problem.
> Is there way to modularize builds to exclude ieee80211 or just disable
> it (along with ipw2200) because it is outdated and current vesion is
> shipped in ieee80211-source package?
Probably the best place to start is to ping netdev to find out if
there are any plans to update IPW2200 in Linus's tree. I've CCed
that list, hopefully someone can shed some light on this.
--
Horms
^ permalink raw reply
* [2.6 patch] update S2IO help text
From: Adrian Bunk @ 2005-11-02 1:53 UTC (permalink / raw)
To: jgarzik; +Cc: netdev, linux-kernel
This patch contains the following updates to the S2IO help text:
- correct the patch to the README
- there is no information regarding compilation and installation of the
driver in the README
Signed-off-by: Adrian Bunk <bunk@stusta.de>
--- linux-2.6.14-rc5-mm1-modular-2.95/drivers/net/Kconfig.old 2005-11-02 02:46:21.000000000 +0100
+++ linux-2.6.14-rc5-mm1-modular-2.95/drivers/net/Kconfig 2005-11-02 02:50:13.000000000 +0100
@@ -2253,12 +2253,12 @@
config S2IO
tristate "S2IO 10Gbe XFrame NIC"
depends on PCI
---help---
This driver supports the 10Gbe XFrame NIC of S2IO.
- For help regarding driver compilation, installation and
- tuning please look into ~/drivers/net/s2io/README.txt.
+ For help regarding driver tuning please look into
+ <file:Documentation/networking/s2io.txt>.
config S2IO_NAPI
bool "Use Rx Polling (NAPI) (EXPERIMENTAL)"
depends on S2IO && EXPERIMENTAL
help
^ permalink raw reply
* [-mm patch] fix NET_RADIO=n, IEEE80211=y compile
From: Adrian Bunk @ 2005-11-02 0:53 UTC (permalink / raw)
To: Andrew Morton, jgarzik; +Cc: linux-kernel, netdev
In-Reply-To: <20051024014838.0dd491bb.akpm@osdl.org>
On Mon, Oct 24, 2005 at 01:48:38AM -0700, Andrew Morton wrote:
>...
> Changes since 2.6.14-rc4-mm1:
>...
> git-netdev-all.patch
>...
> Subsystem trees
>...
<-- snip -->
This patch fixes the following compile error with CONFIG_NET_RADIO=n and
CONFIG_IEEE80211=y:
LD .tmp_vmlinux1
net/built-in.o: In function `ieee80211_rx':
: undefined reference to `wireless_spy_update'
make: *** [.tmp_vmlinux1] Error 1
Signed-off-by: Adrian Bunk <bunk@stusta.de>
--- linux-2.6.14-rc5-mm1-full/net/ieee80211/ieee80211_rx.c.old 2005-11-01 22:17:45.000000000 +0100
+++ linux-2.6.14-rc5-mm1-full/net/ieee80211/ieee80211_rx.c 2005-11-01 22:17:01.000000000 +0100
@@ -370,6 +370,7 @@
/* Put this code here so that we avoid duplicating it in all
* Rx paths. - Jean II */
#ifdef IW_WIRELESS_SPY /* defined in iw_handler.h */
+#ifdef CONFIG_NET_RADIO
/* If spy monitoring on */
if (ieee->spy_data.spy_number > 0) {
struct iw_quality wstats;
@@ -396,6 +397,7 @@
/* Update spy records */
wireless_spy_update(ieee->dev, hdr->addr2, &wstats);
}
+#endif /* CONFIG_NET_RADIO */
#endif /* IW_WIRELESS_SPY */
#ifdef NOT_YET
^ permalink raw reply
* Re: [PATCH][MCAST]IPv6: small fix for ip6_mc_msfilter(...)
From: David Stevens @ 2005-11-01 23:55 UTC (permalink / raw)
To: Yan Zheng; +Cc: linux-kernel, netdev
In-Reply-To: <4367FF22.3030601@21cn.com>
Looks good. Thanks, Yan.
+-DLS
Acked-by: David L Stevens <dlstevens@us.ibm.com>
>
> Signed-off-by: Yan Zheng <yanzheng@21cn.com>
>
> Patch for IPv4
> Index:net/ipv4/igmp.c
> ============================================================
> --- linux-2.6.14/net/ipv4/igmp.c 2005-10-28 08:02:08.000000000 +0800
> +++ linux/net/ipv4/igmp.c 2005-11-02 07:31:01.000000000 +0800
> @@ -1908,8 +1908,11 @@ int ip_mc_msfilter(struct sock *sk, stru
> sock_kfree_s(sk, newpsl, IP_SFLSIZE(newpsl->sl_max));
> goto done;
> }
> - } else
> + } else {
> newpsl = NULL;
> + (void) ip_mc_add_src(in_dev, &msf->imsf_multiaddr,
> + msf->imsf_fmode, 0, NULL, 0)
> + }
> psl = pmc->sflist;
> if (psl) {
> (void) ip_mc_del_src(in_dev, &msf->imsf_multiaddr, pmc->sfmode,
>
>
>
>
> Patch for IPv6
> Index:net/ipv6/mcast.c
> ============================================================
> --- linux-2.6.14/net/ipv6/mcast.c 2005-10-30 23:09:33.000000000 +0800
> +++ linux/net/ipv6/mcast.c 2005-11-02 07:19:12.000000000 +0800
> @@ -545,8 +545,10 @@ int ip6_mc_msfilter(struct sock *sk, str
> sock_kfree_s(sk, newpsl, IP6_SFLSIZE(newpsl->sl_max));
> goto done;
> }
> - } else
> + } else {
> newpsl = NULL;
> + (void) ip6_mc_add_src(idev, group, gsf->gf_fmode, 0, NULL, 0);
> + }
> psl = pmc->sflist;
> if (psl) {
> (void) ip6_mc_del_src(idev, group, pmc->sfmode,
>
>
^ permalink raw reply
* Re: [PATCH][MCAST]IPv6: small fix for ip6_mc_msfilter(...)
From: Yan Zheng @ 2005-11-01 23:49 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel, David Stevens
In-Reply-To: <OF395F8772.5B834BF9-ON882570AC.0075ACD7-882570AC.0075DC3C@us.ibm.com>
David Stevens wrote:
> Yan,
> Please also make this equivalent change in IPv4 with
> ip_mc_msfilter() and ip_mc_add_src().
>
> +-DLS
>
> Acked-by: David L Stevens <dlstevens@us.ibm.com>
To keep code style, I also create a new patch for IPv6. :-)
Signed-off-by: Yan Zheng <yanzheng@21cn.com>
Patch for IPv4
Index:net/ipv4/igmp.c
============================================================
--- linux-2.6.14/net/ipv4/igmp.c 2005-10-28 08:02:08.000000000 +0800
+++ linux/net/ipv4/igmp.c 2005-11-02 07:31:01.000000000 +0800
@@ -1908,8 +1908,11 @@ int ip_mc_msfilter(struct sock *sk, stru
sock_kfree_s(sk, newpsl, IP_SFLSIZE(newpsl->sl_max));
goto done;
}
- } else
+ } else {
newpsl = NULL;
+ (void) ip_mc_add_src(in_dev, &msf->imsf_multiaddr,
+ msf->imsf_fmode, 0, NULL, 0)
+ }
psl = pmc->sflist;
if (psl) {
(void) ip_mc_del_src(in_dev, &msf->imsf_multiaddr, pmc->sfmode,
Patch for IPv6
Index:net/ipv6/mcast.c
============================================================
--- linux-2.6.14/net/ipv6/mcast.c 2005-10-30 23:09:33.000000000 +0800
+++ linux/net/ipv6/mcast.c 2005-11-02 07:19:12.000000000 +0800
@@ -545,8 +545,10 @@ int ip6_mc_msfilter(struct sock *sk, str
sock_kfree_s(sk, newpsl, IP6_SFLSIZE(newpsl->sl_max));
goto done;
}
- } else
+ } else {
newpsl = NULL;
+ (void) ip6_mc_add_src(idev, group, gsf->gf_fmode, 0, NULL, 0);
+ }
psl = pmc->sflist;
if (psl) {
(void) ip6_mc_del_src(idev, group, pmc->sfmode,
^ permalink raw reply
* Re: <REAL> iBurst (TM) compatible driver
From: Stephen Hemminger @ 2005-11-01 23:21 UTC (permalink / raw)
To: Nicholas Jefferson; +Cc: netdev, linux-kernel
In-Reply-To: <4cd031a50510312100n23bffa13jb48a6daa33bce80b@mail.gmail.com>
On Tue, 1 Nov 2005 16:00:19 +1100
Nicholas Jefferson <xanthophile@gmail.com> wrote:
> Hi Stephen,
>
> Thank you for your comments. A new version of the iBurst (TM) wireless
> compatible driver (and a patch against 2.6.13.4) is now available [1]
> under the linux-2.6-ibdriver-2.0 release.
>
> [1] http://sourceforge.net/projects/ibdriver
>
> > 1. Your network device registration code is wrong.
>
> Okay. ib_net_register now uses alloc_netdev with the appropriate
> changes elsewhere.
Where is updated code?
>
> > 2. Transmit routine is wrong. Drop packets if out of memory.
>
> Okay. ib_net_tx_start does not allocate memory now.
>
> > 3. You need to flow control the transmit queue.
>
> ib_net_tx_prepare already did netif_stop_queue and netif_wake_queue.
> Would you prefer this to be in ib_net_tx_start instead?
There is still a race with poll and tx_start.
Better to have tx_start check for space after queuing and have
poll wake_queue when space becomes available.
> > 4. WTF is the whole ib_net_tap file stuff, and why do you need it?
>
> The modem can return status information (signal strength, etc.). This
> information is accessed from usermode by device files. There is also
> an interactive "talk" channel to control the modem, but I don't know
> what it can do. The ib-file module implements these device files. It
> is not essential for the driver and we don't yet know the modem
> protocol anyway, so I've removed it.
Some possibilities:
1. Could you support a subset of the existing wireless functions. Then
all the cool tools like wireless strength stuff would work.
2. Or add a sysfs status files
3. Or a /proc file per device
It makes sense for the driver to give as much information to the user
as possible. Just try and use existing API's first.
> > 5. Why bother with a /proc interface?
> > 6. If you must then use seq_file.
> > 7. If you must then do one device per file.
>
> The /proc interface was for debugging and may later be used to provide
> the status information instead of the device files. It's not
> essential, so I've removed this as well.
One way I use is to keep a separate patch around that adds in the
/proc stuff for when debugging, but not put it in the main kernel.
> > 8. Then you can get rid of having a global array of device structures
> > which is hard to maintain properly.
>
> The global array was used to set up the correspondence between the
> device files (via the minor device file numbers) and the modem
> structures (via the index to the global array). It's gone now ;-)
>
> > 9. If you don't support ioctl's just leave dev->ioctl as NULL
> > 10. Error code's from call's like register_netdev() should propogate back out.
> > 11. ib_net_open, ib_net_close only called from user context don't need
> > irqsave use spin_lock_irq()
> > 12. Coding style: don't use u_long it's a BSDism
> > 13. Please have source code laid out as patch to kernel, not out of tree driver
>
Also.
* Default name should be "ib%d" so you can handle multiple cards without
getting an error.
* Why so many symbols exported?
* Ethtool and standard message level support would be cool (but not required).
--
Stephen Hemminger <shemminger@osdl.org>
OSDL http://developer.osdl.org/~shemminger
^ permalink raw reply
* Re: [PKT_SCHED]: Rework QoS and/or fair queueing configuration
From: Patrick McHardy @ 2005-11-01 21:47 UTC (permalink / raw)
To: Ian McDonald
Cc: Thomas Graf, Arnaldo Carvalho de Melo, bunk, jengelh,
linux-kernel, netdev
In-Reply-To: <cbec11ac0511011154r13e7b695g@mail.gmail.com>
Ian McDonald wrote:
> I keep meaning to submit a patch but low on my todo list. Feel free to
> do so if you wish or else I will get around to it one day. I know
> Arnaldo has also mentioned ktimers for the future (which I haven't yet
> read) which may help in this area as well.
AFAIK ktimers are another timer subsystem, but don't provide any
further clock sources. Having higher resolution timers would be
great however for improving accuracy when a qdisc is throttled.
^ permalink raw reply
* Re: [PATCH][MCAST]IPv6: small fix for ip6_mc_msfilter(...)
From: David Stevens @ 2005-11-01 21:27 UTC (permalink / raw)
To: Yan Zheng; +Cc: linux-kernel, netdev, netdev-owner
In-Reply-To: <436586F0.9080101@21cn.com>
Yan,
Please also make this equivalent change in IPv4 with
ip_mc_msfilter() and ip_mc_add_src().
+-DLS
Acked-by: David L Stevens <dlstevens@us.ibm.com>
>
> Signed-off-by: Yan Zheng <yanzheng@21cn.com>
>
> Index: net/ipv6/mcast.c
>
================================================================================
> --- linux-2.6.14/net/ipv6/mcast.c 2005-10-30 23:09:33.000000000 +0800
> +++ linux/net/ipv6/mcast.c 2005-10-31 10:37:36.000000000 +0800
> @@ -545,8 +545,10 @@ int ip6_mc_msfilter(struct sock *sk, str
> sock_kfree_s(sk, newpsl, IP6_SFLSIZE(newpsl->sl_max));
> goto done;
> }
> - } else
> + } else {
> newpsl = NULL;
> + ip6_mc_add_src(idev, group, gsf->gf_fmode, 0, NULL, 0);
> + }
> psl = pmc->sflist;
> if (psl) {
> (void) ip6_mc_del_src(idev, group, pmc->sfmode,
> -
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PKT_SCHED]: Rework QoS and/or fair queueing configuration
From: Ian McDonald @ 2005-11-01 19:54 UTC (permalink / raw)
To: Thomas Graf; +Cc: Arnaldo Carvalho de Melo, bunk, jengelh, linux-kernel, netdev
In-Reply-To: <20051101141302.GM23537@postel.suug.ch>
On 02/11/05, Thomas Graf <tgraf@suug.ch> wrote:
>
> Make "QoS and/or fair queueing" have its own menu, it's too big to be
> inlined into "Network options". Remove the obsolete NET_QOS option.
> Automatically select NET_CLS if needed. Do the same for NET_ESTIMATOR
> but allow it to be selected manually for statistical purposes. Add
> comments to separate queueing from classification. Fix dependencies
> and ordering of classifiers. Improve descriptions/help texts and
> remove outdated pieces.
>
Thomas I think the timing ones can be improved slightly out of the
discussion at here:
http://marc.theaimsgroup.com/?l=linux-netdev&m=112912015311659&w=2
I keep meaning to submit a patch but low on my todo list. Feel free to
do so if you wish or else I will get around to it one day. I know
Arnaldo has also mentioned ktimers for the future (which I haven't yet
read) which may help in this area as well.
Ian
--
Ian McDonald
http://wand.net.nz/~iam4
WAND Network Research Group
University of Waikato
New Zealand
^ permalink raw reply
* [PATCH] ibmveth fix panic in initial replenish cycle
From: Santiago Leon @ 2005-11-01 19:15 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Santiago Leon, netdev, lkml, Jeff Garzik
This patch fixes a panic in the current tree caused by a race condition between the initial replenish cycle and the rx processing of the first packets trying to replenish the buffers.
Signed-off-by: Santiago Leon <santil@us.ibm.com>
diff --git a/drivers/net/ibmveth.c b/drivers/net/ibmveth.c
--- a/drivers/net/ibmveth.c
+++ b/drivers/net/ibmveth.c
@@ -535,7 +535,7 @@ static int ibmveth_open(struct net_devic
}
ibmveth_debug_printk("initial replenish cycle\n");
- ibmveth_replenish_task(adapter);
+ ibmveth_interrupt(netdev->irq, netdev, NULL);
netif_start_queue(netdev);
^ permalink raw reply
* Re: [NF+IPsec 4/6]: Make IPsec input processing symetrical to output
From: Stephen Frost @ 2005-11-01 18:39 UTC (permalink / raw)
To: Yasuyuki KOZAKAI; +Cc: netdev, netfilter-devel, kaber, herbert
In-Reply-To: <200510310319.j9V3JHZK008295@toshiba.co.jp>
[-- Attachment #1: Type: text/plain, Size: 2105 bytes --]
* Yasuyuki KOZAKAI (yasuyuki.kozakai@toshiba.co.jp) wrote:
> I think pure transport mode is important, too. For example, for users of
> L2TP over IPsec.
>
> But I'm not sure that how many people wants to use netfilter hook together.
> At least, I don't need that. Because I can use IPsec policy instead of
> iptables rule and that's enough for me.
>
> I also think that it's the work for IPsec policy check to decide to
> accept or drop decrypted packets on input path of transport mode, that is
> not netfilter work.
Trying to compare IPsec policy to netfilter is just plain silly. IPsec
policy is *not* equivilant to a firewall system like netfilter. Not
even close. Not offering the ability to firewall transport-mode IPsec
packets shouldn't even be an option. :/ With 15 servers which all talk
transport-mode IPsec to each other I'd still want to be able to do
firewalling to hopefully reduce the impact of one of the servers being
compromised.
> On the other hand, for the users who want to use local NAT and IPsec
> transport mode together, we might have to add netfilter hook to input
> path. But I'm not sure how many such users are. If nobody want, hooks
> we need are only LOCAL_OUT and POST_ROUTING on output path per tunnel.
I had wanted to do this, in order to hide the network configuration of
the machines behind the gateway but ended up not being able to. :/ My
situation is perhaps not very common but I think it will become more
common in the future: I've got a VPN setup with multiple different
people who I don't completely trust and who don't entirely trust me or
the other people. This situation can exist for tunnel mode and
transport mode users. As use-ipsec-when-available transport mode
increases in use this need seems likely to grow.
Consider a corporate network where the whole thing is set up to do
transport-mode ipsec. Chances are the guys who run the corporate
servers are still going to want to be able to run firewalls on their
servers to cover things in case a given desktop is compromised.
Thanks,
Stephen
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [NF+IPsec 4/6]: Make IPsec input processing symetrical to output
From: Patrick McHardy @ 2005-11-01 18:23 UTC (permalink / raw)
To: Yasuyuki KOZAKAI; +Cc: netdev, netfilter-devel, herbert
In-Reply-To: <200510310319.j9V3JHNl019752@toshiba.co.jp>
Yasuyuki KOZAKAI wrote:
>>Patrick McHardy wrote:
>>
>>>Herbert Xu wrote:
>>>
>>>>I presume that you will be changing the output path so that LOCAL_OUT
>>>>does not see the plain-text packet. Otherwise it'll be asymmetric with
>>>>repsect to the inbound side which does not see plain-text packets for
>>>>transport mode SAs.
>
> I support this way.
Hiding the packets from the hooks dependant on the xfrm_state is always
a problem with NAT, because when we do a second xfrm lookup after NAT
it is already to late to hide the packets.
>>>Yes, that was the idea. But since people seem to consider this an
>>>important case to handle I'm going to try the per-SA flag you
>>>proposed. I'll send new patches in the next days.
>
> I think pure transport mode is important, too. For example, for users of
> L2TP over IPsec.
>
> But I'm not sure that how many people wants to use netfilter hook together.
> At least, I don't need that. Because I can use IPsec policy instead of
> iptables rule and that's enough for me.
>
> I also think that it's the work for IPsec policy check to decide to
> accept or drop decrypted packets on input path of transport mode, that is
> not netfilter work.
I agree that its the job of policy checks, but its often simpler to
add a policy which includes just IP addresses and use iptables for
filtering. Connection state, TCP flags, ..., can't be handled using
policy checks, and netfilter might also be used for marking, TCP MSS
rewriting, proxy redirection, ...
> On the other hand, for the users who want to use local NAT and IPsec
> transport mode together, we might have to add netfilter hook to input
> path. But I'm not sure how many such users are. If nobody want, hooks
> we need are only LOCAL_OUT and POST_ROUTING on output path per tunnel.
Yes, we could add new hooks and duplicate the relevant code from the
IP input path. But I think just sending the packets through the stack
again is cleaner.
>>Unfortunately hiding the plain-text packets on output when transport
>>mode SAs are used and the flag is not set adds a new inconsistency
>>with NAT. In my last patchsets NAT was handled by redoing the policy
>>lookup when a packet was NATed at LOCAL_OUT or POST_ROUTING and wasn't
>>already transformed. If the new lookup yielded a policy
>>ip_dst_output/__ip_dst_output was called again. The hooks were always
>>called in the normal order. With a per-SA flag however we don't know
>>if the packet should be hidden before the second lookup is done, so
>>with NAT a packet that would usually be hidden might be visible
>>on LOCAL_OUT and POST_ROUTING, or just LOCAL_OUT. This also affects
>>ip_queue.
>
> Sorry, maybe I don't understand. per-SA flag means that packets go through
> netfilter hook before handling of its SA on output path ? Why it isn't
> 'after' ?
The idea was to usually hide transport mode packets on the output path
from netfilter hooks, unless a special flag in the xfrm_state is set.
On input the flag would make a packet decapsulated from a transport mode
SA through the stack again. But it has the same problem wrt. NAT I
described above as hiding unconditionally.
^ permalink raw reply
* Re: (no subject)
From: Patrick McHardy @ 2005-11-01 17:47 UTC (permalink / raw)
To: Yasuyuki KOZAKAI; +Cc: laforge, netdev, netfilter-devel, acme
In-Reply-To: <200510311111.j9VBBU7n020516@toshiba.co.jp>
Yasuyuki KOZAKAI wrote:
> Subject: Re: nf_conntrack comments
> From: Yasuyuki KOZAKAI <kozakai@isl.rdc.toshiba.co.jp>
> Fcc: +backup
> In-Reply-To: <20051029135524.GQ4479@sunbeam.de.gnumonks.org>
> References: <20051018084924.GD20338@sunbeam.de.gnumonks.org>
> <39e6f6c70510282108i60d78df6w9728f40641dccf80@mail.gmail.com>
> <20051029135524.GQ4479@sunbeam.de.gnumonks.org>
> X-Mailer: Mew version 4.2 on Emacs 20.7 / Mule 4.0 (HANANOEN)
> ----
>
> Hi, Acme and all,
>
> Acme, thank you for reviewing of nf_conntrack.
>
> From: Harald Welte <laforge@netfilter.org>
> Date: Sat, 29 Oct 2005 15:55:24 +0200
>
>
>>>+ if (!h) {
>>>+ DEBUGP("icmpv6_error: no match\n");
>>>+ return NF_ACCEPT;
>>>+ } else {
>>>+ if (NF_CT_DIRECTION(h) == IP_CT_DIR_REPLY)
>>>+ *ctinfo += IP_CT_IS_REPLY;
>>>+ }
>>>+
>>>+ /* Update skb to refer to this connection */
>>>+ skb->nfct = &nf_ct_tuplehash_to_ctrack(h)->ct_general;
>>>+ skb->nfctinfo = *ctinfo;
>>>+ return -NF_ACCEPT;
>>>+}
>>>
>>>I noticed that some of the returns are NF_ACCEPT while at leat this last one
>>>returns -NF_ACCEPT, is this a special convention or should all be negative? or
>>>positive?
>>
>>I'll check that, looks like a bug to me, too.
>
>
> If we don't change, the result is same. If this function return NF_ACCEPT,
> connection tracking handles packet as normal packet. But it cannot find invert
> tuple for it and stop processing after all. Then no problem.
>
> But it may be better to replace NF_ACCEPT with -NF_ACCEPT in this function to
> stop processing early.
>
> BTW, this is common issue in nf_conntrack and ip_conntrack. Then it is
> necessary to both of them if we want.
>
> Signed-off-by: Yasuyuki Kozakai <yasuyuki.kozakai@toshiba.co.jp>
>
> Netfilter folks, do you have any problem if I change these return value ?
I think its a good idea, there is no point in continuing to process
these packets.
^ permalink raw reply
* [PKT_SCHED]: Rework QoS and/or fair queueing configuration
From: Thomas Graf @ 2005-11-01 14:13 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo; +Cc: bunk, jengelh, linux-kernel, netdev
In-Reply-To: <20051031132729.GK23537@postel.suug.ch>
Make "QoS and/or fair queueing" have its own menu, it's too big to be
inlined into "Network options". Remove the obsolete NET_QOS option.
Automatically select NET_CLS if needed. Do the same for NET_ESTIMATOR
but allow it to be selected manually for statistical purposes. Add
comments to separate queueing from classification. Fix dependencies
and ordering of classifiers. Improve descriptions/help texts and
remove outdated pieces.
Signed-off-by: Thomas Graf <tgraf@suug.ch>
Index: linux-2.6/net/sched/Kconfig
===================================================================
--- linux-2.6.orig/net/sched/Kconfig
+++ linux-2.6/net/sched/Kconfig
@@ -2,13 +2,15 @@
# Traffic control configuration.
#
-menuconfig NET_SCHED
+menu "QoS and/or fair queueing"
+
+config NET_SCHED
bool "QoS and/or fair queueing"
---help---
When the kernel has several packets to send out over a network
device, it has to decide which ones to send first, which ones to
- delay, and which ones to drop. This is the job of the packet
- scheduler, and several different algorithms for how to do this
+ delay, and which ones to drop. This is the job of the queueing
+ disciplines, several different algorithms for how to do this
"fairly" have been proposed.
If you say N here, you will get the standard packet scheduler, which
@@ -23,13 +25,13 @@ menuconfig NET_SCHED
To administer these schedulers, you'll need the user-level utilities
from the package iproute2+tc at <ftp://ftp.tux.org/pub/net/ip-routing/>.
That package also contains some documentation; for more, check out
- <http://snafu.freedom.org/linux2.2/iproute-notes.html>.
+ <http://linux-net.osdl.org/index.php/Iproute2>.
This Quality of Service (QoS) support will enable you to use
Differentiated Services (diffserv) and Resource Reservation Protocol
- (RSVP) on your Linux router if you also say Y to "QoS support",
- "Packet classifier API" and to some classifiers below. Documentation
- and software is at <http://diffserv.sourceforge.net/>.
+ (RSVP) on your Linux router if you also say Y to the corresponding
+ classifiers below. Documentation and software is at
+ <http://diffserv.sourceforge.net/>.
If you say Y here and to "/proc file system" below, you will be able
to read status information about packet schedulers from the file
@@ -42,7 +44,7 @@ choice
prompt "Packet scheduler clock source"
depends on NET_SCHED
default NET_SCH_CLK_JIFFIES
- help
+ ---help---
Packet schedulers need a monotonic clock that increments at a static
rate. The kernel provides several suitable interfaces, each with
different properties:
@@ -56,7 +58,7 @@ choice
config NET_SCH_CLK_JIFFIES
bool "Timer interrupt"
- help
+ ---help---
Say Y here if you want to use the timer interrupt (jiffies) as clock
source. This clock source is fast, synchronized on all processors and
handles cpu clock frequency changes, but its resolution is too low
@@ -64,7 +66,7 @@ config NET_SCH_CLK_JIFFIES
config NET_SCH_CLK_GETTIMEOFDAY
bool "gettimeofday"
- help
+ ---help---
Say Y here if you want to use gettimeofday as clock source. This clock
source has high resolution, is synchronized on all processors and
handles cpu clock frequency changes, but it is slow.
@@ -77,7 +79,7 @@ config NET_SCH_CLK_GETTIMEOFDAY
config NET_SCH_CLK_CPU
bool "CPU cycle counter"
depends on ((X86_TSC || X86_64) && !SMP) || ALPHA || SPARC64 || PPC64 || IA64
- help
+ ---help---
Say Y here if you want to use the CPU's cycle counter as clock source.
This is a cheap and high resolution clock source, but on some
architectures it is not synchronized on all processors and doesn't
@@ -95,134 +97,129 @@ config NET_SCH_CLK_CPU
endchoice
+comment "Queueing/Scheduling"
+ depends on NET_SCHED
+
config NET_SCH_CBQ
- tristate "CBQ packet scheduler"
+ tristate "Class Based Queueing (CBQ)"
depends on NET_SCHED
---help---
Say Y here if you want to use the Class-Based Queueing (CBQ) packet
- scheduling algorithm for some of your network devices. This
- algorithm classifies the waiting packets into a tree-like hierarchy
- of classes; the leaves of this tree are in turn scheduled by
- separate algorithms (called "disciplines" in this context).
+ scheduling algorithm. This algorithm classifies the waiting packets
+ into a tree-like hierarchy of classes; the leaves of this tree are
+ in turn scheduled by separate algorithms.
- See the top of <file:net/sched/sch_cbq.c> for references about the
- CBQ algorithm.
+ See the top of <file:net/sched/sch_cbq.c> for more details.
CBQ is a commonly used scheduler, so if you're unsure, you should
say Y here. Then say Y to all the queueing algorithms below that you
- want to use as CBQ disciplines. Then say Y to "Packet classifier
- API" and say Y to all the classifiers you want to use; a classifier
- is a routine that allows you to sort your outgoing traffic into
- classes based on a certain criterion.
+ want to use as leaf disciplines.
To compile this code as a module, choose M here: the
module will be called sch_cbq.
config NET_SCH_HTB
- tristate "HTB packet scheduler"
+ tristate "Hierarchical Token Bucket (HTB)"
depends on NET_SCHED
---help---
Say Y here if you want to use the Hierarchical Token Buckets (HTB)
- packet scheduling algorithm for some of your network devices. See
+ packet scheduling algorithm. See
<http://luxik.cdi.cz/~devik/qos/htb/> for complete manual and
in-depth articles.
- HTB is very similar to the CBQ regarding its goals however is has
+ HTB is very similar to CBQ regarding its goals however is has
different properties and different algorithm.
To compile this code as a module, choose M here: the
module will be called sch_htb.
config NET_SCH_HFSC
- tristate "HFSC packet scheduler"
+ tristate "Hierarchical Fair Service Curve (HFSC)"
depends on NET_SCHED
---help---
Say Y here if you want to use the Hierarchical Fair Service Curve
- (HFSC) packet scheduling algorithm for some of your network devices.
+ (HFSC) packet scheduling algorithm.
To compile this code as a module, choose M here: the
module will be called sch_hfsc.
-#tristate ' H-PFQ packet scheduler' CONFIG_NET_SCH_HPFQ
config NET_SCH_ATM
- tristate "ATM pseudo-scheduler"
+ tristate "ATM Virtual Circuits (ATM)"
depends on NET_SCHED && ATM
---help---
Say Y here if you want to use the ATM pseudo-scheduler. This
- provides a framework for invoking classifiers (aka "filters"), which
- in turn select classes of this queuing discipline. Each class maps
- the flow(s) it is handling to a given virtual circuit (see the top of
- <file:net/sched/sch_atm.c>).
+ provides a framework for invoking classifiers, which in turn
+ select classes of this queuing discipline. Each class maps
+ the flow(s) it is handling to a given virtual circuit.
+
+ See the top of <file:net/sched/sch_atm.c>) for more details.
To compile this code as a module, choose M here: the
module will be called sch_atm.
config NET_SCH_PRIO
- tristate "The simplest PRIO pseudoscheduler"
+ tristate "Multi Band Priority Queueing (PRIO)"
depends on NET_SCHED
- help
+ ---help---
Say Y here if you want to use an n-band priority queue packet
- "scheduler" for some of your network devices or as a leaf discipline
- for the CBQ scheduling algorithm. If unsure, say Y.
+ scheduler.
To compile this code as a module, choose M here: the
module will be called sch_prio.
config NET_SCH_RED
- tristate "RED queue"
+ tristate "Random Early Detection (RED)"
depends on NET_SCHED
- help
+ ---help---
Say Y here if you want to use the Random Early Detection (RED)
- packet scheduling algorithm for some of your network devices (see
- the top of <file:net/sched/sch_red.c> for details and references
- about the algorithm).
+ packet scheduling algorithm.
+
+ See the top of <file:net/sched/sch_red.c> for more details.
To compile this code as a module, choose M here: the
module will be called sch_red.
config NET_SCH_SFQ
- tristate "SFQ queue"
+ tristate "Stochastic Fairness Queueing (SFQ)"
depends on NET_SCHED
---help---
Say Y here if you want to use the Stochastic Fairness Queueing (SFQ)
- packet scheduling algorithm for some of your network devices or as a
- leaf discipline for the CBQ scheduling algorithm (see the top of
- <file:net/sched/sch_sfq.c> for details and references about the SFQ
- algorithm).
+ packet scheduling algorithm .
+
+ See the top of <file:net/sched/sch_sfq.c> for more details.
To compile this code as a module, choose M here: the
module will be called sch_sfq.
config NET_SCH_TEQL
- tristate "TEQL queue"
+ tristate "True Link Equalizer (TEQL)"
depends on NET_SCHED
---help---
Say Y here if you want to use the True Link Equalizer (TLE) packet
- scheduling algorithm for some of your network devices or as a leaf
- discipline for the CBQ scheduling algorithm. This queueing
- discipline allows the combination of several physical devices into
- one virtual device. (see the top of <file:net/sched/sch_teql.c> for
- details).
+ scheduling algorithm. This queueing discipline allows the combination
+ of several physical devices into one virtual device.
+
+ See the top of <file:net/sched/sch_teql.c> for more details.
To compile this code as a module, choose M here: the
module will be called sch_teql.
config NET_SCH_TBF
- tristate "TBF queue"
+ tristate "Token Bucket Filter (TBF)"
depends on NET_SCHED
- help
- Say Y here if you want to use the Simple Token Bucket Filter (TBF)
- packet scheduling algorithm for some of your network devices or as a
- leaf discipline for the CBQ scheduling algorithm (see the top of
- <file:net/sched/sch_tbf.c> for a description of the TBF algorithm).
+ ---help---
+ Say Y here if you want to use the Token Bucket Filter (TBF) packet
+ scheduling algorithm.
+
+ See the top of <file:net/sched/sch_tbf.c> for more details.
To compile this code as a module, choose M here: the
module will be called sch_tbf.
config NET_SCH_GRED
- tristate "GRED queue"
+ tristate "Generic Random Early Detection (GRED)"
depends on NET_SCHED
- help
+ ---help---
Say Y here if you want to use the Generic Random Early Detection
(GRED) packet scheduling algorithm for some of your network devices
(see the top of <file:net/sched/sch_red.c> for details and
@@ -232,9 +229,9 @@ config NET_SCH_GRED
module will be called sch_gred.
config NET_SCH_DSMARK
- tristate "Diffserv field marker"
+ tristate "Differentiated Services marker (DSMARK)"
depends on NET_SCHED
- help
+ ---help---
Say Y if you want to schedule packets according to the
Differentiated Services architecture proposed in RFC 2475.
Technical information on this method, with pointers to associated
@@ -244,9 +241,9 @@ config NET_SCH_DSMARK
module will be called sch_dsmark.
config NET_SCH_NETEM
- tristate "Network emulator"
+ tristate "Network emulator (NETEM)"
depends on NET_SCHED
- help
+ ---help---
Say Y if you want to emulate network delay, loss, and packet
re-ordering. This is often useful to simulate networks when
testing applications or protocols.
@@ -259,58 +256,23 @@ config NET_SCH_NETEM
config NET_SCH_INGRESS
tristate "Ingress Qdisc"
depends on NET_SCHED
- help
- If you say Y here, you will be able to police incoming bandwidth
- and drop packets when this bandwidth exceeds your desired rate.
+ ---help---
+ Say Y here if you want to use classifiers for incoming packets.
If unsure, say Y.
To compile this code as a module, choose M here: the
module will be called sch_ingress.
-config NET_QOS
- bool "QoS support"
+comment "Classification"
depends on NET_SCHED
- ---help---
- Say Y here if you want to include Quality Of Service scheduling
- features, which means that you will be able to request certain
- rate-of-flow limits for your network devices.
-
- This Quality of Service (QoS) support will enable you to use
- Differentiated Services (diffserv) and Resource Reservation Protocol
- (RSVP) on your Linux router if you also say Y to "Packet classifier
- API" and to some classifiers below. Documentation and software is at
- <http://diffserv.sourceforge.net/>.
-
- Note that the answer to this question won't directly affect the
- kernel: saying N will just cause the configurator to skip all
- the questions about QoS support.
-
-config NET_ESTIMATOR
- bool "Rate estimator"
- depends on NET_QOS
- help
- In order for Quality of Service scheduling to work, the current
- rate-of-flow for a network device has to be estimated; if you say Y
- here, the kernel will do just that.
config NET_CLS
- bool "Packet classifier API"
- depends on NET_SCHED
- ---help---
- The CBQ scheduling algorithm requires that network packets which are
- scheduled to be sent out over a network device be classified
- according to some criterion. If you say Y here, you will get a
- choice of several different packet classifiers with the following
- questions.
-
- This will enable you to use Differentiated Services (diffserv) and
- Resource Reservation Protocol (RSVP) on your Linux router.
- Documentation and software is at
- <http://diffserv.sourceforge.net/>.
+ boolean
config NET_CLS_BASIC
- tristate "Basic classifier"
- depends on NET_CLS
+ tristate "Elementary classification (BASIC)"
+ depends NET_SCHED
+ select NET_CLS
---help---
Say Y here if you want to be able to classify packets using
only extended matches and actions.
@@ -319,24 +281,25 @@ config NET_CLS_BASIC
module will be called cls_basic.
config NET_CLS_TCINDEX
- tristate "TC index classifier"
- depends on NET_CLS
- help
- If you say Y here, you will be able to classify outgoing packets
- according to the tc_index field of the skb. You will want this
- feature if you want to implement Differentiated Services using
- sch_dsmark. If unsure, say Y.
+ tristate "Traffic-Control Index (TCINDEX)"
+ depends NET_SCHED
+ select NET_CLS
+ ---help---
+ Say Y here if you want to be able to classify packets based on
+ traffic control indices. You will want this feature if you want
+ to implement Differentiated Services together with DSMARK.
To compile this code as a module, choose M here: the
module will be called cls_tcindex.
config NET_CLS_ROUTE4
- tristate "Routing table based classifier"
- depends on NET_CLS
+ tristate "Routing decision (ROUTE)"
+ depends NET_SCHED
select NET_CLS_ROUTE
- help
- If you say Y here, you will be able to classify outgoing packets
- according to the route table entry they matched. If unsure, say Y.
+ select NET_CLS
+ ---help---
+ If you say Y here, you will be able to classify packets
+ according to the route table entry they matched.
To compile this code as a module, choose M here: the
module will be called cls_route.
@@ -346,58 +309,45 @@ config NET_CLS_ROUTE
default n
config NET_CLS_FW
- tristate "Firewall based classifier"
- depends on NET_CLS
- help
- If you say Y here, you will be able to classify outgoing packets
- according to firewall criteria you specified.
+ tristate "Netfilter mark (FW)"
+ depends NET_SCHED
+ select NET_CLS
+ ---help---
+ If you say Y here, you will be able to classify packets
+ according to netfilter/firewall marks.
To compile this code as a module, choose M here: the
module will be called cls_fw.
config NET_CLS_U32
- tristate "U32 classifier"
- depends on NET_CLS
- help
- If you say Y here, you will be able to classify outgoing packets
- according to their destination address. If unsure, say Y.
+ tristate "Universal 32bit comparisons w/ hashing (U32)"
+ depends NET_SCHED
+ select NET_CLS
+ ---help---
+ Say Y here to be able to classify packetes using a universal
+ 32bit pieces based comparison scheme.
To compile this code as a module, choose M here: the
module will be called cls_u32.
config CLS_U32_PERF
- bool "U32 classifier performance counters"
+ bool "Performance counters support"
depends on NET_CLS_U32
- help
- gathers stats that could be used to tune u32 classifier performance.
- Requires a new iproute2
- You MUST NOT turn this on if you dont have an update iproute2.
-
-config NET_CLS_IND
- bool "classify input device (slows things u32/fw) "
- depends on NET_CLS_U32 || NET_CLS_FW
- help
- This option will be killed eventually when a
- metadata action appears because it slows things a little
- Available only for u32 and fw classifiers.
- Requires a new iproute2
- You MUST NOT turn this on if you dont have an update iproute2.
+ ---help---
+ Say Y here to make u32 gather additional statistics useful for
+ fine tuning u32 classifiers.
config CLS_U32_MARK
- bool "Use nfmark as a key in U32 classifier"
+ bool "Netfilter marks support"
depends on NET_CLS_U32 && NETFILTER
- help
- This allows you to match mark in a u32 filter.
- Example:
- tc filter add dev eth0 protocol ip parent 1:0 prio 5 u32 \
- match mark 0x0090 0xffff \
- match ip dst 4.4.4.4 \
- flowid 1:90
- You must use a new iproute2 to use this feature.
+ ---help---
+ Say Y here to be able to use netfilter marks as u32 key.
config NET_CLS_RSVP
- tristate "Special RSVP classifier"
- depends on NET_CLS && NET_QOS
+ tristate "IPv4 Resource Reservation Protocol (RSVP)"
+ depends on NET_SCHED
+ select NET_CLS
+ select NET_ESTIMATOR
---help---
The Resource Reservation Protocol (RSVP) permits end systems to
request a minimum and maximum data flow rate for a connection; this
@@ -410,31 +360,33 @@ config NET_CLS_RSVP
module will be called cls_rsvp.
config NET_CLS_RSVP6
- tristate "Special RSVP classifier for IPv6"
- depends on NET_CLS && NET_QOS
+ tristate "IPv6 Resource Reservation Protocol (RSVP6)"
+ depends on NET_SCHED
+ select NET_CLS
+ select NET_ESTIMATOR
---help---
The Resource Reservation Protocol (RSVP) permits end systems to
request a minimum and maximum data flow rate for a connection; this
is important for real time data such as streaming sound or video.
Say Y here if you want to be able to classify outgoing packets based
- on their RSVP requests and you are using the new Internet Protocol
- IPv6 as opposed to the older and more common IPv4.
+ on their RSVP requests and you are using the IPv6.
To compile this code as a module, choose M here: the
module will be called cls_rsvp6.
config NET_EMATCH
bool "Extended Matches"
- depends on NET_CLS
+ depends NET_SCHED
+ select NET_CLS
---help---
Say Y here if you want to use extended matches on top of classifiers
and select the extended matches below.
Extended matches are small classification helpers not worth writing
- a separate classifier.
+ a separate classifier for.
- You must have a recent version of the iproute2 tools in order to use
+ A recent version of the iproute2 package is required to use
extended matches.
config NET_EMATCH_STACK
@@ -468,7 +420,7 @@ config NET_EMATCH_NBYTE
module will be called em_nbyte.
config NET_EMATCH_U32
- tristate "U32 hashing key"
+ tristate "U32 key"
depends on NET_EMATCH
---help---
Say Y here if you want to be able to classify packets using
@@ -496,76 +448,120 @@ config NET_EMATCH_TEXT
select TEXTSEARCH_BM
select TEXTSEARCH_FSM
---help---
- Say Y here if you want to be ablt to classify packets based on
+ Say Y here if you want to be able to classify packets based on
textsearch comparisons.
To compile this code as a module, choose M here: the
module will be called em_text.
config NET_CLS_ACT
- bool "Packet ACTION"
- depends on EXPERIMENTAL && NET_CLS && NET_QOS
- ---help---
- This option requires you have a new iproute2. It enables
- tc extensions which can be used with tc classifiers.
- You MUST NOT turn this on if you dont have an update iproute2.
+ bool "Actions"
+ depends on EXPERIMENTAL && NET_SCHED
+ select NET_ESTIMATOR
+ ---help---
+ Say Y here if you want to use traffic control actions. Actions
+ get attached to classifiers and are invoked after a successful
+ classification. They are used to overwrite the classification
+ result, instantly drop or redirect packets, etc.
+
+ A recent version of the iproute2 package is required to use
+ extended matches.
config NET_ACT_POLICE
- tristate "Policing Actions"
+ tristate "Traffic Policing"
depends on NET_CLS_ACT
---help---
- If you are using a newer iproute2 select this one, otherwise use one
- below to select a policer.
- You MUST NOT turn this on if you dont have an update iproute2.
+ Say Y here if you want to do traffic policing, i.e. strict
+ bandwidth limiting. This action replaces the existing policing
+ module.
+
+ To compile this code as a module, choose M here: the
+ module will be called police.
config NET_ACT_GACT
- tristate "generic Actions"
+ tristate "Generic actions"
depends on NET_CLS_ACT
---help---
- You must have new iproute2 to use this feature.
- This adds simple filtering actions like drop, accept etc.
+ Say Y here to take generic actions such as dropping and
+ accepting packets.
+
+ To compile this code as a module, choose M here: the
+ module will be called gact.
config GACT_PROB
- bool "generic Actions probability"
+ bool "Probability support"
depends on NET_ACT_GACT
---help---
- Allows generic actions to be randomly or deterministically used.
+ Say Y here to use the generic action randomly or deterministically.
config NET_ACT_MIRRED
- tristate "Packet In/Egress redirecton/mirror Actions"
+ tristate "Redirecting and Mirroring"
depends on NET_CLS_ACT
---help---
- requires new iproute2
- This allows packets to be mirrored or redirected to netdevices
+ Say Y here to allow packets to be mirrored or redirected to
+ other devices.
+
+ To compile this code as a module, choose M here: the
+ module will be called mirred.
config NET_ACT_IPT
- tristate "iptables Actions"
+ tristate "IPtables targets"
depends on NET_CLS_ACT && NETFILTER && IP_NF_IPTABLES
---help---
- requires new iproute2
- This allows iptables targets to be used by tc filters
+ Say Y here to be able to invoke iptables targets after succesful
+ classification.
+
+ To compile this code as a module, choose M here: the
+ module will be called ipt.
config NET_ACT_PEDIT
- tristate "Generic Packet Editor Actions"
+ tristate "Packet Editing"
depends on NET_CLS_ACT
---help---
- requires new iproute2
- This allows for packets to be generically edited
+ Say Y here if you want to mangle the content of packets.
-config NET_CLS_POLICE
- bool "Traffic policing (needed for in/egress)"
- depends on NET_CLS && NET_QOS && NET_CLS_ACT!=y
- help
- Say Y to support traffic policing (bandwidth limits). Needed for
- ingress and egress rate limiting.
+ To compile this code as a module, choose M here: the
+ module will be called pedit.
config NET_ACT_SIMP
- tristate "Simple action"
+ tristate "Simple Example (Debug)"
depends on NET_CLS_ACT
---help---
- You must have new iproute2 to use this feature.
- This adds a very simple action for demonstration purposes
- The idea is to give action authors a basic example to look at.
- All this action will do is print on the console the configured
- policy string followed by _ then packet count.
+ Say Y here to add a simple action for demonstration purposes.
+ It is meant as an example and for debugging purposes. It will
+ print a configured policy string followed by the packet count
+ to the console for every packet that passes by.
+
+ If unsure, say N.
+
+ To compile this code as a module, choose M here: the
+ module will be called simple.
+
+config NET_CLS_POLICE
+ bool "Traffic Policing (obsolete)"
+ depends on NET_SCHED && NET_CLS_ACT!=y
+ select NET_ESTIMATOR
+ ---help---
+ Say Y here if you want to do traffic policing, i.e. strict
+ bandwidth limiting. This option is obsoleted by the traffic
+ policer implemented as action, it stays here for compatibility
+ reasons.
+
+config NET_CLS_IND
+ bool "Incoming device classification"
+ depends on NET_SCHED && (NET_CLS_U32 || NET_CLS_FW)
+ ---help---
+ Say Y here to extend the u32 and fw classifier to support
+ classification based on the incoming device. This option is
+ likely to disappear in favour of the metadata ematch.
+
+config NET_ESTIMATOR
+ bool "Rate estimator"
+ depends on NET_SCHED
+ ---help---
+ Say Y here to allow using rate estimators to estimate the current
+ rate-of-flow for network devices, queues, etc. This module is
+ automaticaly selected if needed but can be selected manually for
+ statstical purposes.
+endmenu
^ permalink raw reply
* Re: [PATCH][MCAST]IPv6: small fix for ip6_mc_msfilter(...)
From: Yan Zheng @ 2005-11-01 10:37 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel, David Stevens
In-Reply-To: <436586F0.9080101@21cn.com>
You can reproduce this bug by follow codes. This program will cause a
change to include report even though the first socket's filter mode is
exclude.
Please adjust IFINDEX first.
========================================
#include <stdio.h>
#include <unistd.h>
#include <netinet/in.h>
#include <arpa/inet.h>
#include <sys/socket.h>
#include <sys/types.h>
#define IFINDEX 6
int main(int argc, char argv[])
{
int i, sockfds[3];
struct ipv6_mreq req;
struct group_filter filter;
struct sockaddr_in6 *psin6;
req.ipv6mr_interface = IFINDEX;
inet_pton(PF_INET6, "FF02::2", &req.ipv6mr_multiaddr);
for (i = 0; i < 3; ++i) {
sockfds[i] = socket(PF_INET6, SOCK_DGRAM, 0);
setsockopt(sockfds[i], SOL_IPV6, IPV6_ADD_MEMBERSHIP, &req, sizeof(req));
}
filter.gf_interface = IFINDEX;
filter.gf_fmode = MCAST_INCLUDE;
filter.gf_numsrc = 1;
psin6 = (struct sockaddr_in6 *)&filter.gf_group;
psin6->sin6_family = AF_INET6;
inet_pton(PF_INET6, "FF02::2", &psin6->sin6_addr);
psin6 = (struct sockaddr_in6 *)&filter.gf_slist[0];
psin6->sin6_family = AF_INET6;
inet_pton(PF_INET6, "2002:de12:1780::1", &psin6->sin6_addr);
setsockopt(sockfds[1], SOL_IPV6, MCAST_MSFILTER, &filter, sizeof(filter));
filter.gf_fmode = MCAST_EXCLUDE;
filter.gf_numsrc = 0;
setsockopt(sockfds[2], SOL_IPV6, MCAST_MSFILTER, &filter, sizeof(filter));
setsockopt(sockfds[2], SOL_IPV6, MCAST_MSFILTER, &filter, sizeof(filter));
pause();
}
^ permalink raw reply
* Re: <REAL> iBurst (TM) compatible driver
From: Nicholas Jefferson @ 2005-11-01 5:00 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev, linux-kernel
In-Reply-To: <20051027153104.1a6531db@dxpl.pdx.osdl.net>
Hi Stephen,
Thank you for your comments. A new version of the iBurst (TM) wireless
compatible driver (and a patch against 2.6.13.4) is now available [1]
under the linux-2.6-ibdriver-2.0 release.
[1] http://sourceforge.net/projects/ibdriver
> 1. Your network device registration code is wrong.
Okay. ib_net_register now uses alloc_netdev with the appropriate
changes elsewhere.
> 2. Transmit routine is wrong. Drop packets if out of memory.
Okay. ib_net_tx_start does not allocate memory now.
> 3. You need to flow control the transmit queue.
ib_net_tx_prepare already did netif_stop_queue and netif_wake_queue.
Would you prefer this to be in ib_net_tx_start instead?
> 4. WTF is the whole ib_net_tap file stuff, and why do you need it?
The modem can return status information (signal strength, etc.). This
information is accessed from usermode by device files. There is also
an interactive "talk" channel to control the modem, but I don't know
what it can do. The ib-file module implements these device files. It
is not essential for the driver and we don't yet know the modem
protocol anyway, so I've removed it.
> 5. Why bother with a /proc interface?
> 6. If you must then use seq_file.
> 7. If you must then do one device per file.
The /proc interface was for debugging and may later be used to provide
the status information instead of the device files. It's not
essential, so I've removed this as well.
> 8. Then you can get rid of having a global array of device structures
> which is hard to maintain properly.
The global array was used to set up the correspondence between the
device files (via the minor device file numbers) and the modem
structures (via the index to the global array). It's gone now ;-)
> 9. If you don't support ioctl's just leave dev->ioctl as NULL
> 10. Error code's from call's like register_netdev() should propogate back out.
> 11. ib_net_open, ib_net_close only called from user context don't need
> irqsave use spin_lock_irq()
> 12. Coding style: don't use u_long it's a BSDism
> 13. Please have source code laid out as patch to kernel, not out of tree driver
Okay.
Kind regards,
Nicholas
^ permalink raw reply
* Re: [PATCH][MCAST]IPv6: Check packet size when process Multicast Address and Source Specific Query
From: Yan Zheng @ 2005-11-01 4:20 UTC (permalink / raw)
To: David Stevens; +Cc: Yan Zheng, linux-kernel, netdev
In-Reply-To: <OF1A55BA31.24DA7F68-ON882570AB.006BBA0E-882570AB.006C3CFC@us.ibm.com>
> I think this should be modelled after the equivalent code in IGMPv3.
> See igmp_heard_query() in net/ipv4/igmp.c. For ease of maintenance,
> the code should be structured exactly the same way, except for
> necessary differences, of course.
>
> I haven't seen enough context yet, but I think you need to check
> for the query header itself, too (as done in IGMPv3).
>
> I'm reviewing your other patches as well.
>
> +-DLS
Yes . It's better to drop invalid query earlier.
^ permalink raw reply
* Re: [PATCH][MCAST]IPv6: doubt about ipv6_sk_mc_lock usage.
From: David Stevens @ 2005-10-31 21:37 UTC (permalink / raw)
To: Yan Zheng; +Cc: linux-kernel, netdev
In-Reply-To: <4365775B.9080209@21cn.com>
> I have one more question.
> Why ip6_mc_source() uses read_lock_bh(&ipv6_sk_mc_lock) and
ip6_mc_msfilter()
> doesn't use ipv6_sk_mc_lock at all.
> when ipv6_mc_list's sflist are accessed by inet6_mc_check(), Can it be
> modified by ip6_mc_source() or ip6_mc_msfilter() ?
> (For example ipv6_mc_list's sflist is freed up by sock_kfree_s(), when
> inet6_mc_check() uses it)
Yan,
There certainly may be a bug, but removing the lock isn't the fix. :-)
inet6_mc_check() does not have the socket locked, but is acquiring a
read lock on ipv6_sk_mc_lock.
I've looked some more into this, and I believe ip6_mc_msfilter() needs
at least a read lock on ipv6_sk_mc_lock to protect it from races with
changes to the list, just as ip6_mc_source() has.
I convinced myself at the time that the sflist does not require an
additional lock, but I don't see that now. It seems to me now that
there should be a lock on each individual socklist entry and changes
to the socket source filter should be protected by that. A simpler,
but less performant, fix would be to make both ipv6_mc_source() and
ip6_mc_msfilter() acquire ipv6_sk_mc_lock for writing, to prevent
races with inet6_mc_check's search of the sflist.
It'd be much better if only that socklist entry is locked, of course.
I'll look some more.
+-DLS
^ permalink raw reply
* Re: airo.c patches
From: John W. Linville @ 2005-10-31 21:25 UTC (permalink / raw)
To: Bill Moss; +Cc: netdev, breed
In-Reply-To: <43667B36.3000200@clemson.edu>
On Mon, Oct 31, 2005 at 03:14:46PM -0500, Bill Moss wrote:
> Below are three patches to
> /usr/src/kernels/2.6.13-1.1532_FC4-i686/drivers/net/wireless/airo.c for
> your consideration.
The intended changes look ok at first glance. However, your mailer
has mangled the patches beyond usability. There is tons of whitespace
damage, including the removal of the initial space that should preced
every unchanged line in the patch.
Also, we need a Signed-off-by: line. http://linux.yyz.us/patch-format.html
Thanks,
John
--
John W. Linville
linville@tuxdriver.com
^ permalink raw reply
* Re: [PATCH] kill 8139too kernel thread (sorta)
From: Herbert Xu @ 2005-10-31 21:11 UTC (permalink / raw)
To: Jeff Garzik; +Cc: netdev, linux-kernel
In-Reply-To: <E1EWgcG-0001dZ-00@gondolin.me.apana.org.au>
On Tue, Nov 01, 2005 at 07:50:52AM +1100, Herbert Xu wrote:
>
> However, in this case it's much easier than that. Simply change
> rtl8139_thread to do
>
> rtnl_lock();
> if (tp->time_to_die == 0) {
> rtl8139_thread_iter(dev, tp, tp->mmio_addr);
> schedule_delayed_work(&tp->thread, next_tick);
> }
> rtnl_unlock();
Actually this is no good either. The reason is that rtl8139_stop_thread
never relinquinshes the RTNL so it has no way of waiting for this to
complete.
So I suppose we will have to use cancel_rearming_delayed_workqueue or
create an rtl-specific semaphore for this.
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
* Re: [PATCH] kill 8139too kernel thread (sorta)
From: Herbert Xu @ 2005-10-31 20:50 UTC (permalink / raw)
To: Jeff Garzik; +Cc: netdev, linux-kernel
In-Reply-To: <20051031130255.GA26626@havoc.gtf.org>
Jeff Garzik <jgarzik@pobox.com> wrote:
>
> + if ((tp->time_to_die == 0) &&
> + (rtnl_lock_interruptible() == 0)) {
> rtl8139_thread_iter (dev, tp, tp->mmio_addr);
> rtnl_unlock ();
> }
>
> - complete_and_exit (&tp->thr_exited, 0);
> + if (tp->time_to_die == 0)
> + schedule_delayed_work(&tp->thread, next_tick);
> }
...
> +static void rtl8139_stop_thread(struct rtl8139_private *tp)
> +{
> + if (tp->time_to_die < 0)
> + return;
> +
> + tp->time_to_die = 1;
> + wmb();
> +
> + if (cancel_delayed_work(&tp->thread) == 0)
> + flush_scheduled_work();
> }
Race alert:
CPU0 CPU1
rtl8139_thread
rtnl_lock
rtl8139_thread_iter
rtnl_unlock
tp->time_to_die == 0
rtl8139_stop_thread
tp->time_to_die = 1
cancel_delayed_work == 0
flush_scheduled_work
schedule_delayed_work
So by the time rtl8139_stop_thread returns, the work is still scheduled.
The standard way to solve this is to get rid of the time_to_die check
in rtl8139_thread before the rescheduling and then use the horrible
cancel_rearming_delayed_workqueue function.
However, in this case it's much easier than that. Simply change
rtl8139_thread to do
rtnl_lock();
if (tp->time_to_die == 0) {
rtl8139_thread_iter(dev, tp, tp->mmio_addr);
schedule_delayed_work(&tp->thread, next_tick);
}
rtnl_unlock();
This is not racy because rtl8139_stop_thread is also run under the
RTNL. Furthermore, you don't need the interruptible version anymore
since you are no longer using kill to kill the thread.
This also fixes the bug that if you fail to acquire RTNL the Work
is delayed by another next_tick ticks.
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
* airo.c patches
From: Bill Moss @ 2005-10-31 20:14 UTC (permalink / raw)
To: netdev; +Cc: breed
Below are three patches to
/usr/src/kernels/2.6.13-1.1532_FC4-i686/drivers/net/wireless/airo.c for
your consideration.
Patch one. Remove 3 second delay in returning scan results. This delay
appears to be unnecessary. Users of NetworkManager have found that this
delay makes NetworkManager slow to connect in certain scenarios. Testing
has shown no ill effect of removing this delay. This delay does not
appear in other drivers such as ipw2200/ieee80211
--- airo.c_orig 2005-10-28 20:06:40.000000000 -0400
+++ airo.c 2005-10-28 20:08:16.000000000 -0400
@@ -6918,7 +6918,7 @@
/* When we are associated again, the scan has surely finished.
* Just in case, let's make sure enough time has elapsed since
* we started the scan. - Javier */
- if(ai->scan_timestamp &&
time_before(jiffies,ai->scan_timestamp+3*HZ)) {
+ if(ai->scan_timestamp && time_before(jiffies,ai->scan_timestamp)) {
/* Important note : we don't want to block the caller
* until results are ready for various reasons.
* First, managing wait queues is complex and racy
Patch two. Report the channel correctly in the output from iwlist.
--- airo.c_orig 2005-10-28 20:06:40.000000000 -0400
+++ airo.c 2005-10-28 20:16:59.000000000 -0400
@@ -6846,7 +6846,7 @@
/* Add frequency */
iwe.cmd = SIOCGIWFREQ;
iwe.u.freq.m = le16_to_cpu(bss->dsChannel);
- iwe.u.freq.m = frequency_list[iwe.u.freq.m] * 100000;
+ iwe.u.freq.m = frequency_list[iwe.u.freq.m-1] * 100000;
iwe.u.freq.e = 1;
current_ev = iwe_stream_add_event(current_ev, end_buf, &iwe,
IW_EV_FREQ_LEN);
Patch three. Introduce minimal ethtool support. Report driver name and
version. Report link (association). This code was cloned from
ipw2200/ieee80211. Ethtool support is used by NetworkManager.
--- airo.c_orig 2005-10-28 20:06:40.000000000 -0400
+++ airo.c 2005-10-28 20:21:55.000000000 -0400
@@ -39,6 +39,7 @@
#include <asm/system.h>
#include <linux/netdevice.h>
+#include <linux/ethtool.h>
#include <linux/etherdevice.h>
#include <linux/skbuff.h>
#include <linux/if_arp.h>
@@ -46,6 +47,10 @@
#include <linux/pci.h>
#include <asm/uaccess.h>
+#define DRV_NAME "airo"
+#define AIRO_VERSION "0.6 (Ben Reed & Javier Achirica)"
+#define DRV_VERSION AIRO_VERSION
+
#ifdef CONFIG_PCI
static struct pci_device_id card_ids[] = {
{ 0x14b9, 1, PCI_ANY_ID, PCI_ANY_ID, },
@@ -65,7 +70,7 @@
static int airo_pci_resume(struct pci_dev *pdev);
static struct pci_driver airo_driver = {
- .name = "airo",
+ .name = DRV_NAME,
.id_table = card_ids,
.probe = airo_pci_probe,
.remove = __devexit_p(airo_pci_remove),
@@ -1069,7 +1074,7 @@
static const struct iw_handler_def airo_handler_def;
#endif /* WIRELESS_EXT */
-static const char version[] = "airo.c 0.6 (Ben Reed & Javier Achirica)";
+static const char version[] = DRV_VERSION;
struct airo_info;
@@ -2318,6 +2323,28 @@
return 0;
}
+static void airo_ethtool_get_drvinfo(struct net_device *dev,
+ struct ethtool_drvinfo
*info)
+{
+ strcpy(info->driver, DRV_NAME);
+ strcpy(info->version, DRV_VERSION);
+}
+
+static u32 airo_ethtool_get_link(struct net_device *dev)
+{
+ struct airo_info *local = dev->priv;
+ StatusRid status_rid;
+
+ readStatusRid(local, &status_rid, 1);
+
+ return (status_rid.assocStatus == STAT_ASSOCIATED);
+}
+
+static struct ethtool_ops airo_ethtool_ops = {
+ .get_link = airo_ethtool_get_link,
+ .get_drvinfo = airo_ethtool_get_drvinfo,
+};
+
static int airo_change_mtu(struct net_device *dev, int new_mtu)
{
if ((new_mtu < 68) || (new_mtu > 2400))
@@ -2757,6 +2784,7 @@
dev->change_mtu = &airo_change_mtu;
dev->open = &airo_open;
dev->stop = &airo_close;
+ dev->ethtool_ops = &airo_ethtool_ops;
dev->irq = irq;
dev->base_addr = port;
--
Bill Moss
Professor, Mathematical Sciences
Clemson University
--
Bill Moss
Professor, Mathematical Sciences
Clemson University
^ 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