Re: [PATCH 1/1] [NETFILTER] ip_conntrack: fix ftp/irc/tftp helpers on ports = 32768
On Thu, 17 Nov 2005, David S. Miller wrote: From: Harald Welte [EMAIL PROTECTED] Date: Tue, 15 Nov 2005 11:03:51 +0100 [NETFILTER] ip_conntrack: fix ftp/irc/tftp helpers on ports = 32768 Since we've converted the ftp/irc/tftp helpers to use the new module_parm_array() some time ago, we ware accidentially using signed data types - thus preventing those modules from being used on ports = 32768. This patch fixes it by using 'ushort' module parameters. Thanks to Jan Nijs for reporting this bug. Signed-off-by: Harald Welte [EMAIL PROTECTED] Applied, thanks. I think this is definitely a 2.6.14-stable candidate? What about patch that fixes vlan with bonding? http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=8e3babcd69ec0fde874838e276eb0b211c6a5647 I think we should fix this in 2.6.14-stable also. Best regards, Krzysztof Olędzki
Re: [PATCH 1/1] [NETFILTER] ip_conntrack: fix ftp/irc/tftp helpers on ports = 32768
On Fri, 18 Nov 2005, David S. Miller wrote: From: Krzysztof Oledzki [EMAIL PROTECTED] Date: Fri, 18 Nov 2005 09:43:27 +0100 (CET) What about patch that fixes vlan with bonding? http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=8e3babcd69ec0fde874838e276eb0b211c6a5647 I think we should fix this in 2.6.14-stable also. That's network device stuff, ask Jeff Garzik and the patch submitter, I had already did that (15 Nov 2005) but it seems I was ignored. not me. OK, please excuse me. Best regards, Krzysztof Olędzki
netem undesired packet re-ordering bug
If packets are sent to the netem queue at the same time, they will be reversed, even if re-ordering has not been enabled. The problem is in sch_netem.c line 467: if (PSCHED_TLESS(cb-time_to_send, ncb-time_to_send)) The queue is being traversed from back to front. If A and B are sent at the same time, the queue will result in B, A. Logically the operation to find the queue position should be: = instead of . Replacing that line with: if (!PSCHED_TLESS(ncb-time_to_send, cb-time_to_send)) solves the problem. here is a diff: diff --git a/net/sched/sch_netem.c b/net/sched/sch_netem.c index cdc8d28..82fb07a 100644 --- a/net/sched/sch_netem.c +++ b/net/sched/sch_netem.c @@ -464,7 +464,7 @@ static int tfifo_enqueue(struct sk_buff const struct netem_skb_cb *cb = (const struct netem_skb_cb *)skb-cb; - if (PSCHED_TLESS(cb-time_to_send, ncb-time_to_send)) + if (!PSCHED_TLESS(ncb-time_to_send, cb-time_to_send)) break; } - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] LSM-IPSec Network Hooks
Thanks for all your help, Herbert.
Regards,
Trent.
On Nov 17, 2005, at 8:28 PM, Herbert Xu wrote:
On Thu, Nov 17, 2005 at 06:42:29PM -0500, Trent Jaeger wrote:
Patch with sock callback lock made unconditional. Previous send
(earlier today, 11/17) was not the latest patch -- please disregard
that patch.
Signed-off-by: Trent Jaeger [EMAIL PROTECTED]
Looks very good. Thank you Trent for working through this with me.
Signed-off-by: Herbert Xu [EMAIL PROTECTED]
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
Trent Jaeger, Associate Professor
Pennsylvania State University, CSE Dept
346A IST Bldg, University Park, PA 16802
Email: [EMAIL PROTECTED]
Ph: (814) 865-1042, Fax: (814) 865-3176
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC: 2.6 patch] remove drivers/net/eepro100.c
Russell King wrote: On Fri, Nov 18, 2005 at 04:33:02AM +0100, Adrian Bunk wrote: This patch removes the obsolete drivers/net/eepro100.c driver. Is there any reason why it should be kept? Tt's the only driver which works correctly on ARM CPUs. e100 is basically buggy. This has been discussed here on lkml and more recently on linux-netdev. If anyone has any further questions please read the archives of those two lists. After reading the archives, one discovers the current status is: waiting on ARM folks to test e100 Latest reference is public message-id [EMAIL PROTECTED], which was CC'd to you. There is a patch in netdev-2.6.git#e100-sbit and in Andrew's -mm tree that should solve the ARM problems, and finally allow us to kill eepro100. But it's waiting for feedback... Jeff - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC: 2.6 patch] remove drivers/net/eepro100.c
On Fri, Nov 18, 2005 at 11:12:28AM -0500, Jeff Garzik wrote: Russell King wrote: On Fri, Nov 18, 2005 at 04:33:02AM +0100, Adrian Bunk wrote: This patch removes the obsolete drivers/net/eepro100.c driver. Is there any reason why it should be kept? Tt's the only driver which works correctly on ARM CPUs. e100 is basically buggy. This has been discussed here on lkml and more recently on linux-netdev. If anyone has any further questions please read the archives of those two lists. After reading the archives, one discovers the current status is: waiting on ARM folks to test e100 Latest reference is public message-id [EMAIL PROTECTED], which was CC'd to you. There is a patch in netdev-2.6.git#e100-sbit and in Andrew's -mm tree that should solve the ARM problems, and finally allow us to kill eepro100. But it's waiting for feedback... So what you're saying is that it's down to me to test the thing. Ok. I've been extremely patient waiting for e100 to get fixed (it's been literally _years_), and I think it isn't surprising that the hardware it was noticed on has been packed away. Now I ask the same of others for when I'm (a) well enough to enter the cold environment in which this machine is currently stored and (b) can find the time to resurect the machine. -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: 2.6 Serial core - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [2.6 patch] move some code to net/ipx/af_ipx.c
On Fri, Nov 18, 2005 at 06:22:52AM +0100, Adrian Bunk wrote: This patch isn't bad, but looking closer we could move the contents of p8023.c as well as the contents of at least p8022.c and pe2.c into af_ipx.c. Is the contents of any of these three files expected to be used outside IPX (closest candidate would be appletalk)? Below is a patch implementing what I was thinking of. Looks reasonable. -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] smc91x: fix one source of spurious interrupts
Nicolas Pitre wrote: Not only SMC_ACK_INT(IM_TX_EMPTY_INT) in in smc_hardware_send_pkt) appears to be unnecessary (tested with an SMC91C94 and SMC91C111), but it seems to trigger spurious interrupts on some machines as well. Removed. While at it, let's log any remaining spurious interrupts if any (and clean usage of the max IRQ loop count value). Signed-off-by: Nicolas Pitre [EMAIL PROTECTED] applied this, and the bank mismatch patch - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH netdev-2.6 0/8] e1000: Driver update
Jeff Kirsher wrote: e1000 driver update Signed-off-by: Jeff Kirsher [EMAIL PROTECTED] Signed-off-by: John Ronciak [EMAIL PROTECTED] Signed-off-by: Jesse Brandeburg [EMAIL PROTECTED] Grumble! How many times has Intel been told to order fixes before new features? I have multiple Intel folks emailing me privately about the urgency of these fixes... and then I get a submission which contains changes inappropriate for the current bug fixes-only Release Candidate cycle. So please choose: 1) I merge these changes into 'upstream' branch, and e1000 misses 2.6.15 release. 2) I drop these patches, wait for a bug fixes-only rediff+resend from Intel, and e1000 makes 2.6.15. Regards, Jeff - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Pull request for halasa-hdlc branch of netdev-jwl
John W. Linville wrote: Jeff, As requested, I separated this from the other patches for individual consideration. John --- The following changes since commit cd52d1ee9a92587b242d946a2300a3245d3b885a: Linus Torvalds: Linux v2.6.15-rc1 are found in the git repository at: git://git.tuxdriver.com/git/netdev-jwl.git halasa-hdlc pulled into upstream-fixes branch (bound for 2.6.15), thanks Jeff - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2.6.15] s2io: UFO support
applied to 'upstream' branch - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] airo : reset card in init
matthieu castet wrote: Hi, without this patch after an rmmod, modprobe the card won't work anymore until the next reboot. This patch seem safe to apply for all cards as the bsd driver already do that. I had to add a timeout because strange things happen (issuecommand will fail) if the card is already reseted (after a reboot). Matthieu PS : it seems there are missing reset when leaving monitor mode... Signed-off-by: Matthieu CASTET [EMAIL PROTECTED] Can you please * resend this patch such that patch -sp1 patch will apply it * avoid MIME attachments Thanks, Jeff - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] airo : reset card in init
Hi,
Jeff Garzik wrote:
matthieu castet wrote:
Hi,
without this patch after an rmmod, modprobe the card won't work
anymore until the next reboot.
This patch seem safe to apply for all cards as the bsd driver already
do that.
I had to add a timeout because strange things happen (issuecommand
will fail) if the card is already reseted (after a reboot).
Matthieu
PS : it seems there are missing reset when leaving monitor mode...
Signed-off-by: Matthieu CASTET [EMAIL PROTECTED]
Can you please
* resend this patch such that patch -sp1 patch will apply it
* avoid MIME attachments
Here an update version of the patch.
Matthieu
Signed-off-by: Matthieu CASTET [EMAIL PROTECTED]
--- linux-2.6.14/drivers/net/wireless/airo.c.old 2005-09-28
20:43:02.0 +0200
+++ linux-2.6.14/drivers/net/wireless/airo.c 2005-09-28
21:05:55.0 +0200
@@ -2769,8 +2769,8 @@
SET_NETDEV_DEV(dev, dmdev);
- if (test_bit(FLAG_MPI,ai-flags))
- reset_card (dev, 1);
+ reset_card (dev, 1);
+ msleep(400);
rc = request_irq( dev-irq, airo_interrupt, SA_SHIRQ, dev-name, dev );
if (rc) {
--- linux-2.6.14/drivers/net/wireless/airo.c.old 2005-09-28 20:43:02.0 +0200
+++ linux-2.6.14/drivers/net/wireless/airo.c 2005-09-28 21:05:55.0 +0200
@@ -2769,8 +2769,8 @@
SET_NETDEV_DEV(dev, dmdev);
- if (test_bit(FLAG_MPI,ai-flags))
- reset_card (dev, 1);
+ reset_card (dev, 1);
+ msleep(400);
rc = request_irq( dev-irq, airo_interrupt, SA_SHIRQ, dev-name, dev );
if (rc) {
Re: Pull request for netdev-jwl
On Fri, Nov 18, 2005 at 01:22:55PM -0500, Jeff Garzik wrote: John W. Linville wrote: James Ketrenos: ipw2100: Fix 'Driver using old /proc/net/wireless...' message John W. Linville: e1000: avoid leak when e1000_setup_loopback_test fails e1000: zero-out pointers in e1000_free_desc_rings fec_8xx: make CONFIG_FEC_8XX depend on CONFIG_8xx Alas, I would like to sync up with Intel on e1000. Could I further impose upon you to separate out the e1000 changes into a separate branch? e1000 stuff is here: git://git.tuxdriver.com/git/netdev-jwl.git linville-e1000 The other stuff is here: git://git.tuxdriver.com/git/netdev-jwl.git upstream-fixes Hth! John -- John W. Linville [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] LSM-IPSec Network Hooks
Removed KERN_DEBUG statements from patch (security/selinux/xfrm.c and security/selinux/include/xfrm.h). Not consistent with SELinux and not really useful anymore. Regards, Trent. This patch series implements per packet access control via the extension of the Linux Security Modules (LSM) interface by hooks in the XFRM and pfkey subsystems that leverage IPSec security associations to label packets. Extensions to the SELinux LSM are included that leverage the patch for this purpose. This patch implements the changes necessary to the SELinux LSM to create, deallocate, and use security contexts for policies (xfrm_policy) and security associations (xfrm_state) that enable control of a socket's ability to send and receive packets. Patch purpose: The patch is designed to enable the SELinux LSM to implement access control on individual packets based on the strongly authenticated IPSec security association. Such access controls augment the existing ones in SELinux based on network interface and IP address. The former are very coarse-grained, and the latter can be spoofed. By using IPSec, the SELinux can control access to remote hosts based on cryptographic keys generated using the IPSec mechanism. This enables access control on a per-machine basis or per-application if the remote machine is running the same mechanism and trusted to enforce the access control policy. Patch design approach: The patch's main function is to authorize a socket's access to a IPSec policy based on their security contexts. Since the communication is implemented by a security association, the patch ensures that the security association's negotiated and used have the same security context. The patch enables allocation and deallocation of such security contexts for policies and security associations. It also enables copying of the security context when policies are cloned. Lastly, the patch ensures that packets that are sent without using a IPSec security assocation with a security context are allowed to be sent in that manner. A presentation available at www.selinux-symposium.org/2005/presentations/session2/2-3-jaeger.pdf from the SELinux symposium describes the overall approach. Patch implementation details: The function which authorizes a socket to perform a requested operation (send/receive) on a IPSec policy (xfrm_policy) is selinux_xfrm_policy_lookup. The Netfilter and rcv_skb hooks ensure that if a IPSec SA with a securit y association has not been used, then the socket is allowed to send or receive the packet, respectively. The patch implements SELinux function for allocating security contexts when policies (xfrm_policy) are created via the pfkey or xfrm_user interfaces via selinux_xfrm_policy_alloc. When a security association is built, SELinux allocates the security context designated by the XFRM subsystem which is based on that of the authorized policy via selinux_xfrm_state_alloc. When a xfrm_policy is cloned, the security context of that policy, if any, is copied to the clone via selinux_xfrm_policy_clone. When a xfrm_policy or xfrm_state is freed, its security context, if any is also freed at selinux_xfrm_policy_free or selinux_xfrm_state_free. Testing: The SELinux authorization function is tested using ipsec-tools. We created policies and security associations with particular security contexts and added SELinux access control policy entries to verify the authorization decision. We also made sure that packets for which no security context was supplied (which either did or did not use security associations) were authorized using an unlabelled context. Signed-off-by: Trent Jaeger [EMAIL PROTECTED] --- security/selinux/Makefile|2 security/selinux/hooks.c | 39 +++ security/selinux/include/av_perm_to_string.h |2 security/selinux/include/av_permissions.h|2 security/selinux/include/xfrm.h | 44 +++ security/selinux/xfrm.c | 325 +++ 6 files changed, 414 insertions(+) diff -puN security/selinux/Makefile~lsm-selinux-nethooks security/selinux/Makefile --- linux-2.6.14/security/selinux/Makefile~lsm-selinux-nethooks 2005-11-17 08:54:38.0 -0500 +++ linux-2.6.14-root/security/selinux/Makefile 2005-11-17 08:54:38.0 -0500 @@ -8,5 +8,7 @@ selinux-y := avc.o hooks.o selinuxfs.o n selinux-$(CONFIG_SECURITY_NETWORK) += netif.o +selinux-$(CONFIG_SECURITY_NETWORK_XFRM) += xfrm.o + EXTRA_CFLAGS += -Isecurity/selinux/include diff -puN security/selinux/hooks.c~lsm-selinux-nethooks security/selinux/hooks.c --- linux-2.6.14/security/selinux/hooks.c~lsm-selinux-nethooks 2005-11-17 08:54:38.0 -0500 +++ linux-2.6.14-root/security/selinux/hooks.c 2005-11-17 08:54:38.0 -0500 @@ -73,6 +73,7 @@ #include avc.h #include objsec.h #include netif.h +#include xfrm.h #define XATTR_SELINUX_SUFFIX selinux #define
Re: [PATCH netdev-2.6 0/8] e1000: Driver update
On Fri, 18 Nov 2005, Jeff Garzik wrote: e1000 driver update Signed-off-by: Jeff Kirsher [EMAIL PROTECTED] Signed-off-by: John Ronciak [EMAIL PROTECTED] Signed-off-by: Jesse Brandeburg [EMAIL PROTECTED] Grumble! How many times has Intel been told to order fixes before new features? apologies, there aren't very many bug fixes in this release, most are new hardware and new features. I have multiple Intel folks emailing me privately about the urgency of these fixes... and then I get a submission which contains changes inappropriate for the current bug fixes-only Release Candidate cycle. So please choose: 1) I merge these changes into 'upstream' branch, and e1000 misses 2.6.15 release. We choose 1) Please merge these changes into upstream for 2.6.16, we realize we missed the merge window for 2.6.15, but should have said so. Our position is users who need the new hardware support or new features now can download our driver tarball from sf.net/projects/e1000. 2) I drop these patches, wait for a bug fixes-only rediff+resend from Intel, and e1000 makes 2.6.15. If I generate some bug fix only patches for 6.1.16, destined for 2.6.15, they will conflict with the upstream branch. Is that okay? You requested in another email that I diff against vanilla 2.6.14, but there are already e1000 changes accepted to 2.6.15 that may fuzz my vanilla diff. I'm struggling how to deal with that. Regenerating the 6.2.15 driver patches is a non-trival amount of work, but we'll do it in the next merge window if we need to. Thanks, Jesse - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Pull request for halasa-hdlc branch of netdev-jwl
Jeff Garzik [EMAIL PROTECTED] writes: git://git.tuxdriver.com/git/netdev-jwl.git halasa-hdlc pulled into upstream-fixes branch (bound for 2.6.15), thanks It's a bit sad we've to fix things such way, though. Thanks. -- Krzysztof Halasa - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] e1000: supply interface speed / duplex when no link-beat
Currently the e1000 driver only supplies the active link speed / duplex
when a link-beat is present to ethtool. This patch adds support for
supplying the configured speed / duplex when auto-negotiation is
disabled and no link-beat is present.
Signed-off-by: Martin Josefsson [EMAIL PROTECTED]
--- linux-2.6.15-rc1-git6.orig/drivers/net/e1000/e1000_ethtool.c
2005-11-18 20:06:57.0 +0100
+++ linux-2.6.15-rc1-git6/drivers/net/e1000/e1000_ethtool.c 2005-11-18
20:07:46.0 +0100
@@ -168,8 +168,32 @@ e1000_get_settings(struct net_device *ne
else
ecmd-duplex = DUPLEX_HALF;
} else {
- ecmd-speed = -1;
- ecmd-duplex = -1;
+ if (hw-autoneg == 1) {
+ ecmd-speed = -1;
+ ecmd-duplex = -1;
+ } else {
+ switch(adapter-hw.forced_speed_duplex) {
+ case e1000_10_half:
+ ecmd-speed = SPEED_10;
+ ecmd-duplex = DUPLEX_HALF;
+ break;
+ case e1000_10_full:
+ ecmd-speed = SPEED_10;
+ ecmd-duplex = DUPLEX_FULL;
+ break;
+ case e1000_100_half:
+ ecmd-speed = SPEED_100;
+ ecmd-duplex = DUPLEX_HALF;
+ break;
+ case e1000_100_full:
+ ecmd-speed = SPEED_100;
+ ecmd-duplex = DUPLEX_FULL;
+ break;
+ default:
+ ecmd-speed = -1;
+ ecmd-duplex = -1;
+ }
+ }
}
ecmd-autoneg = ((hw-media_type == e1000_media_type_fiber) ||
signature.asc
Description: This is a digitally signed message part
Re: [PATCH netdev-2.6 0/8] e1000: Driver update
Jesse Brandeburg wrote: We choose 1) Please merge these changes into upstream for 2.6.16, we realize we missed the merge window for 2.6.15, but should have said so. ok Our position is users who need the new hardware support or new features now can download our driver tarball from sf.net/projects/e1000. This position causes extra work, a split test base, and constant mini-forks whenever e1000 patches come in from the community. Can Intel be persuaded to do development in the netdev tree? We can keep stuff in a separate branch until it has adequate testing, then flush it into the upstream branch periodically. This way everybody's working on the same codebase, but Intel has time to do testing. 2) I drop these patches, wait for a bug fixes-only rediff+resend from Intel, and e1000 makes 2.6.15. If I generate some bug fix only patches for 6.1.16, destined for 2.6.15, they will conflict with the upstream branch. Is that okay? Not really, since its a unified history. 2.6.15-rc becomes 2.6.16. It's not a branch. It sounds like the bug fixes should be applied first, then the rest of the driver updates. You requested in another email that I diff against vanilla 2.6.14, but there are already e1000 changes accepted to 2.6.15 that may fuzz my vanilla diff. I'm struggling how to deal with that. Not a hard rule, use common sense [as you are already doing]. Think in terms of branches. Your e100 microcode changes stood alone, therefore should be diffed (and applied) against the vanilla upstream tree. For e1000, it should certainly be on top of anything currently in 2.6.15-rc1-git + netdev-2.6.git#upstream-fixes. I hope that wasn't too confusing :) In general, diff against vanilla upstream, unless there are additional dependencies. Jeff - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Pull request for halasa-hdlc branch of netdev-jwl
Krzysztof Halasa wrote: Jeff Garzik [EMAIL PROTECTED] writes: git://git.tuxdriver.com/git/netdev-jwl.git halasa-hdlc pulled into upstream-fixes branch (bound for 2.6.15), thanks It's a bit sad we've to fix things such way, though. Thanks. I'm sorry you feel that way. Your patch would go into upstream-fixes one way or another, since it was in my Pending folder. John just saved me a bit of work, that's all. Jeff - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Pull request for halasa-hdlc branch of netdev-jwl
Jeff Garzik [EMAIL PROTECTED] writes: I'm sorry you feel that way. Your patch would go into upstream-fixes one way or another, since it was in my Pending folder. John just saved me a bit of work, that's all. No, you misunderstood me. There was nothing sad about your or John's handling of this particular patch :-) It's sad we (i.e., Stefan, Thomas and Jamal, and me) haven't managed to do things cleanly yet and such workarounds are needed. -- Krzysztof Halasa - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[git patches] 2.6.x net driver fixes
Please pull from 'upstream-fixes' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git
to receive the following assorted fixes:
drivers/net/au1000_eth.c|1
drivers/net/e100.c | 273 ++--
drivers/net/fec_8xx/Kconfig |2
drivers/net/ioc3-eth.c |2
drivers/net/r8169.c |6
drivers/net/saa9730.h | 36 ++--
drivers/net/smc91x.c| 17 +
drivers/net/wan/hdlc_cisco.c|6
drivers/net/wan/hdlc_fr.c |4
drivers/net/wan/hdlc_generic.c |6
drivers/net/wireless/hermes.c |6
drivers/net/wireless/hermes.h |6
drivers/net/wireless/i82593.h | 11 -
drivers/net/wireless/ipw2100.c | 29 ++-
drivers/net/wireless/ipw2100.h |2
drivers/net/wireless/prism54/isl_38xx.c |4
include/net/ieee80211.h |2
17 files changed, 352 insertions(+), 61 deletions(-)
Andrew Morton:
git-netdev-all-ieee80211_get_payload-warning-fix
Francois Romieu:
r8169: fix printk_ratelimit in the interrupt handler
r8169: do not abort when the power management capabilities are disabled
Gabriel A. Devenyi:
drivers/net/wireless/hermes.c unsigned int comparision
James Ketrenos:
ipw2100: Fix 'Driver using old /proc/net/wireless...' message
Jeff Garzik:
[wireless hermes] build fix
Jesse Brandeburg:
e100: re-enable microcode with more useful defaults
John W. Linville:
i82593.h: make header comment GPL-compatible
fec_8xx: make CONFIG_FEC_8XX depend on CONFIG_8xx
Krzysztof Halasa:
Generic HDLC WAN drivers - disable netif_carrier_off()
Nicolas Pitre:
smc91x: fix one source of spurious interrupts
Ralf Baechle:
IOC3: Replace obsolete PCI API
au1000_eth: Include linux/config.h
SAA9730: Add missing header bits.
Roger While:
prism54 : Remove extraneous udelay/register read
Russell King:
smc91x: fix bank mismatch
diff --git a/drivers/net/au1000_eth.c b/drivers/net/au1000_eth.c
index 332e995..cd0b1dc 100644
--- a/drivers/net/au1000_eth.c
+++ b/drivers/net/au1000_eth.c
@@ -32,6 +32,7 @@
*
*/
+#include linux/config.h
#include linux/module.h
#include linux/kernel.h
#include linux/sched.h
diff --git a/drivers/net/e100.c b/drivers/net/e100.c
index 7a6aeae..22cd045 100644
--- a/drivers/net/e100.c
+++ b/drivers/net/e100.c
@@ -156,7 +156,7 @@
#define DRV_NAME e100
#define DRV_EXT-NAPI
-#define DRV_VERSION3.4.14-k2DRV_EXT
+#define DRV_VERSION3.4.14-k4DRV_EXT
#define DRV_DESCRIPTIONIntel(R) PRO/100 Network Driver
#define DRV_COPYRIGHT Copyright(c) 1999-2005 Intel Corporation
#define PFXDRV_NAME :
@@ -903,8 +903,8 @@ static void mdio_write(struct net_device
static void e100_get_defaults(struct nic *nic)
{
- struct param_range rfds = { .min = 16, .max = 256, .count = 64 };
- struct param_range cbs = { .min = 64, .max = 256, .count = 64 };
+ struct param_range rfds = { .min = 16, .max = 256, .count = 256 };
+ struct param_range cbs = { .min = 64, .max = 256, .count = 128 };
pci_read_config_byte(nic-pdev, PCI_REVISION_ID, nic-rev_id);
/* MAC type is encoded as rev ID; exception: ICH is treated as 82559 */
@@ -1007,25 +1007,264 @@ static void e100_configure(struct nic *n
c[16], c[17], c[18], c[19], c[20], c[21], c[22], c[23]);
}
+//
+/* Micro code for 8086:1229 Rev 8 */
+//
+
+/* Parameter values for the D101M B-step */
+#define D101M_CPUSAVER_TIMER_DWORD 78
+#define D101M_CPUSAVER_BUNDLE_DWORD65
+#define D101M_CPUSAVER_MIN_SIZE_DWORD 126
+
+#define D101M_B_RCVBUNDLE_UCODE \
+{\
+0x00550215, 0x0437, 0x, 0x06A70789, 0x, 0x0558, \
+0x000C0001, 0x00101312, 0x000C0008, 0x00380216, \
+0x0010009C, 0x00204056, 0x002380CC, 0x00380056, \
+0x0010009C, 0x00244C0B, 0x0800, 0x00124818, \
+0x00380438, 0x, 0x0014, 0x00380555, \
+0x00308000, 0x00100662, 0x00100561, 0x000E0408, \
+0x00134861, 0x000C0002, 0x00103093, 0x00308000, \
+0x00100624, 0x00100561, 0x000E0408, 0x00100861, \
+0x000C007E, 0x00222C21, 0x000C0002, 0x00103093, \
+0x00380C7A, 0x0008, 0x00103090, 0x00380C7A, \
+0x, 0x, 0x, 0x, \
+0x0010009C, 0x00244C2D, 0x00010004, 0x00041000, \
+0x003A0437, 0x00044010, 0x0038078A, 0x, \
+0x00100099, 0x00206C7A, 0x0010009C, 0x00244C48, \
+0x00130824, 0x000C0001, 0x00101213, 0x00260C75, \
+0x00041000, 0x00010004, 0x00130826, 0x000C0006, \
+0x002206A8, 0x0013C926, 0x00101313, 0x003806A8, \
+0x, 0x, 0x, 0x,
Re: [2.6 patch] move some code to net/ipx/af_ipx.c
On 11/18/05, Adrian Bunk [EMAIL PROTECTED] wrote: On Mon, Nov 14, 2005 at 02:57:07AM +0100, Adrian Bunk wrote: On Fri, Nov 11, 2005 at 02:35:51AM -0600, Matt Mackall wrote: trivial: drop unused 802.3 code if we compile without IPX (originally from http://wohnheim.fh-wedel.de/~joern/software/kernel/je/25/) Thanks Adrian, from a quick glance looks OK, I'll review it later today to see if everything is fine wrt appletalk, tr, etc. - Arnaldo - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Issue 0 WAS (Re: Oustanding issues WAS(IRe: Consensus? WAS(RFC 2863)
Am Freitag 18 November 2005 04:03 schrieb jamal:
ok, I'll produce a patch then - first version will be available tomorrow
evening.
beauty.
Ok, here is the first 'merger' patch. At this stage, it is only compilation
tested against 2.6.14.
This is the data flow:
-Device changes __LINK_STATE_(NOCARRIER|DORMANT) flag
-linkwatch is scheduled
-During linkwatch, the device is queried for it's operational state either
using a device specified method or a generic one
-Operational state is limited to IF_OPER_DORMANT if link mode tells so
-state is written to dev-operstate
-notification is sent out via netdev_state_change() as before
Userspace can intervene after setting link mode to IF_LINK_MODE_DORMANT
(implementation incomplete as I'm yet not familiar enough with writing values
through netlink, Thomas, can you help here?)
-Calls pseudo_set_operstate()
-operstate is either changed from DORMANT to UP or reverse
-notification is sent out via netdev_state_change()
linkwatch and pseudo* as serialized by rtnl and dev_base_lock.
To demonstrate a stacked device, I've implemented a private RFC2863 state
query for VLANs that goes to LOWERLAYERDOWN if the underlying device is DOWN.
With the device specific RFC2863 state query method, we could even limit
LINK_STATE_DORMANT to the devices that need it, but I have the impression
that this is generic enough to be part of struct net_device.
I'm currently emitting more netlink notifications than you've shown in your
state diagram. I'll comment on this later, still got other stuff to do for
today.
- UP-DORMANT; i am not sure if that transition is needed.
Anyway, this transition is needed. Switches can be configured to rerun 802.1X
regularly after initial authentication.
I will attempt some ascii art shortly. Actually if you agree with it
please include it in your patch so it is easier for people to make
changes in the future.
Yes, I think I have to write a short text for the Documentation/ directory
anyway.
Stefan
diff -X dontdiff -urp linux-2.6.14/include/linux/if.h linux-2.6.14-rfc2863/include/linux/if.h
--- linux-2.6.14/include/linux/if.h 2005-11-02 11:07:32.0 +0100
+++ linux-2.6.14-rfc2863/include/linux/if.h 2005-11-18 20:14:25.0 +0100
@@ -33,7 +33,7 @@
#define IFF_LOOPBACK 0x8 /* is a loopback net */
#define IFF_POINTOPOINT 0x10 /* interface is has p-p link */
#define IFF_NOTRAILERS 0x20 /* avoid use of trailers */
-#define IFF_RUNNING 0x40 /* interface running and carrier ok */
+#define IFF_RUNNING 0x40 /* interface RFC2863 OPER_UP */
#define IFF_NOARP 0x80 /* no ARP protocol */
#define IFF_PROMISC 0x100 /* receive all packets */
#define IFF_ALLMULTI 0x200 /* receive all multicast packets*/
@@ -43,12 +43,16 @@
#define IFF_MULTICAST 0x1000 /* Supports multicast */
-#define IFF_VOLATILE (IFF_LOOPBACK|IFF_POINTOPOINT|IFF_BROADCAST|IFF_MASTER|IFF_SLAVE|IFF_RUNNING)
-
#define IFF_PORTSEL 0x2000 /* can set media type */
#define IFF_AUTOMEDIA 0x4000 /* auto media select active */
#define IFF_DYNAMIC 0x8000 /* dialup device with changing addresses*/
+#define IFF_CARRIER 0x1 /* driver signals carrier */
+#define IFF_DORMANT 0x2 /* driver signals dormant */
+
+#define IFF_VOLATILE (IFF_LOOPBACK|IFF_POINTOPOINT|IFF_BROADCAST|\
+ IFF_MASTER|IFF_SLAVE|IFF_RUNNING|IFF_CARRIER|IFF_DORMANT)
+
/* Private (from user) interface flags (netdevice-priv_flags). */
#define IFF_802_1Q_VLAN 0x1 /* 802.1Q VLAN device. */
#define IFF_EBRIDGE 0x2 /* Ethernet bridging device. */
@@ -80,6 +84,22 @@
#define IF_PROTO_FR_ETH_PVC 0x200B
#define IF_PROTO_RAW0x200C /* RAW Socket */
+/* RFC 2863 operational status */
+enum {
+ IF_OPER_UNKNOWN,
+ IF_OPER_NOTPRESENT,
+ IF_OPER_DOWN,
+ IF_OPER_LOWERLAYERDOWN,
+ IF_OPER_TESTING,
+ IF_OPER_DORMANT,
+ IF_OPER_UP,
+};
+
+/* link modes */
+enum {
+ IF_LINK_MODE_DEFAULT,
+ IF_LINK_MODE_DORMANT, /* limit upward transition to dormant */
+};
/*
* Device mapping structure. I'd just gone off and designed a
diff -X dontdiff -urp linux-2.6.14/include/linux/netdevice.h linux-2.6.14-rfc2863/include/linux/netdevice.h
--- linux-2.6.14/include/linux/netdevice.h 2005-11-02 11:08:10.0 +0100
+++ linux-2.6.14-rfc2863/include/linux/netdevice.h 2005-11-18 19:53:32.0 +0100
@@ -230,7 +230,8 @@ enum netdev_state_t
__LINK_STATE_SCHED,
__LINK_STATE_NOCARRIER,
__LINK_STATE_RX_SCHED,
- __LINK_STATE_LINKWATCH_PENDING
+ __LINK_STATE_LINKWATCH_PENDING,
+ __LINK_STATE_DORMANT,
};
@@ -334,11 +335,14 @@ struct net_device
*/
- unsigned short flags; /* interface flags (a la BSD) */
+ unsigned int flags; /* interface flags (a la BSD) */
unsigned short gflags;
unsigned short priv_flags; /* Like 'flags' but invisible to userspace. */
unsigned short padded; /* How much padding added by alloc_netdev() */
+ unsigned char operstate; /* RFC2863 operstate */
+ unsigned char
[PATCH] sch_netem: correctly order packets to be sent simultaneously
From: Andrea Bittau [EMAIL PROTECTED] If two packets were queued to be sent at the same time in the future, their order would be reversed. This would occur because the queue is traversed back to front, and a position is found by checking whether the new packet needs to be sent before the packet being examined. If the new packet is to be sent at the same time of a previous packet, it would end up before the old packet in the queue. This patch places packets in the correct order when they are queued to be sent at a same time in the future. Signed-off-by: Andrea Bittau [EMAIL PROTECTED] --- diff --git a/net/sched/sch_netem.c b/net/sched/sch_netem.c index cdc8d28..82fb07a 100644 --- a/net/sched/sch_netem.c +++ b/net/sched/sch_netem.c @@ -464,7 +464,7 @@ static int tfifo_enqueue(struct sk_buff const struct netem_skb_cb *cb = (const struct netem_skb_cb *)skb-cb; - if (PSCHED_TLESS(cb-time_to_send, ncb-time_to_send)) + if (!PSCHED_TLESS(ncb-time_to_send, cb-time_to_send)) break; } - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Las mejores barbacoas, garajes, spas.
Maginificas barbacoas Magnigicos Spas Magnigicos garajes A unos precios increibles Mediante este enlace tiene toda la informacin. http://www.bestsevendiamonds.com/trigano/ Si es su deseo darse de baja, para no recibir ms publicidad es necesario lo haga en el siguiente enlace. http://www.bestsevendiamonds.com/trigano/bajas.asp Muchas gracias - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC: 2.6 patch] remove drivers/net/tulip/xircom_tulip_cb.c
Adrian Bunk wrote: This patch removes the obsolete drivers/net/tulip/xircom_tulip_cb.c driver. Is there any reason why it should be kept? Yes. It is the only driver that works without lockups on Xircom Cardbus cards. Or so has been the case any time I've tried the alternatives. Is there any good reason to nuke it? - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] sch_netem: correctly order packets to be sent simultaneously
From: Andrea Bittau [EMAIL PROTECTED] Date: Fri, 18 Nov 2005 21:48:47 + From: Andrea Bittau [EMAIL PROTECTED] If two packets were queued to be sent at the same time in the future, their order would be reversed. This would occur because the queue is traversed back to front, and a position is found by checking whether the new packet needs to be sent before the packet being examined. If the new packet is to be sent at the same time of a previous packet, it would end up before the old packet in the queue. This patch places packets in the correct order when they are queued to be sent at a same time in the future. Signed-off-by: Andrea Bittau [EMAIL PROTECTED] Applied, thanks Andrea. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH netdev-2.6 0/8] e1000: Driver update
On Fri, 18 Nov 2005, Jeff Garzik wrote: Our position is users who need the new hardware support or new features now can download our driver tarball from sf.net/projects/e1000. This position causes extra work, a split test base, and constant mini-forks whenever e1000 patches come in from the community. Can Intel be persuaded to do development in the netdev tree? We can keep stuff in a separate branch until it has adequate testing, then flush it into the upstream branch periodically. This way everybody's working on the same codebase, but Intel has time to do testing. At least for our unreleased hardware, we can't. However for fixes that apply to the base driver, we should be able to keep running track of issues we find and keep the external devel repository up to date. I'm going to try submitting mini-patches about once a week, and see if i burn out. 2) I drop these patches, wait for a bug fixes-only rediff+resend from Intel, and e1000 makes 2.6.15. If I generate some bug fix only patches for 6.1.16, destined for 2.6.15, they will conflict with the upstream branch. Is that okay? Not really, since its a unified history. 2.6.15-rc becomes 2.6.16. It's not a branch. It sounds like the bug fixes should be applied first, then the rest of the driver updates. Okay, lets do that for the next time. AFAIK none of the bugs fixed for 2.6.16 are fatal. You requested in another email that I diff against vanilla 2.6.14, but there are already e1000 changes accepted to 2.6.15 that may fuzz my vanilla diff. I'm struggling how to deal with that. Not a hard rule, use common sense [as you are already doing]. Think in terms of branches. Your e100 microcode changes stood alone, therefore should be diffed (and applied) against the vanilla upstream tree. For e1000, it should certainly be on top of anything currently in 2.6.15-rc1-git + netdev-2.6.git#upstream-fixes. I hope that wasn't too confusing :) In general, diff against vanilla upstream, unless there are additional dependencies. okay, thanks - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] TCP BIC: spelling and whitespace
Index: bic-2.6/net/ipv4/tcp_bic.c
===
--- bic-2.6.orig/net/ipv4/tcp_bic.c
+++ bic-2.6/net/ipv4/tcp_bic.c
@@ -210,14 +210,14 @@ static void bictcp_state(struct sock *sk
bictcp_reset(inet_csk_ca(sk));
}
-/* Track delayed acknowledgement ratio using sliding window
+/* Track delayed acknowledgment ratio using sliding window
* ratio = (15*ratio + sample) / 16
*/
static void bictcp_acked(struct sock *sk, u32 cnt)
{
const struct inet_connection_sock *icsk = inet_csk(sk);
- if (cnt 0 icsk-icsk_ca_state == TCP_CA_Open) {
+ if (cnt 0 icsk-icsk_ca_state == TCP_CA_Open) {
struct bictcp *ca = inet_csk_ca(sk);
cnt -= ca-delayed_ack ACK_RATIO_SHIFT;
ca-delayed_ack += cnt;
--
Stephen Hemminger [EMAIL PROTECTED]
OSDL http://developer.osdl.org/~shemminger
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/3] TCP BIC:
These patches update TCP BIC to version 2.0 (CUBIC). This is still experimental, and needs more refinement, so putting it into -mm for a release cycle makes sense. -- Stephen Hemminger [EMAIL PROTECTED] OSDL http://developer.osdl.org/~shemminger - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [RFT] ip_tables NUMA optimization
From: Eric Dumazet [EMAIL PROTECTED]
Date: Thu, 17 Nov 2005 16:21:45 +0100
It should probably use vfree() like :
+ for_each_cpu(cpu) {
+ if (info-size = PAGE_SIZE)
+ kfree(info-entries[cpu]);
+ else
+ vfree(info-entries[cpu]);
+ }
I've put the patch into the net-2.6.16 tree with the obvious
fix Eric points out.
Thanks.
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[NET]: Use unused bit for ipvs_property field in struct sk_buff
Save a few bytes in struct sk_buff.
[NET]: Use unused bit for ipvs_property field in struct sk_buff
Signed-off-by: Patrick McHardy [EMAIL PROTECTED]
---
commit 1b8712ac0db0863027a812d3d6558d21029e357a
tree 1e80d4049d28b7fdfb58ab1456c48d195d9f338d
parent 6b1de9161e973bac8c4675db608fe4f38d2689bd
author Patrick McHardy [EMAIL PROTECTED] Sat, 19 Nov 2005 06:48:43 +0100
committer Patrick McHardy [EMAIL PROTECTED] Sat, 19 Nov 2005 06:48:43 +0100
include/linux/skbuff.h |6 ++
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index 0a8ea8b..e797d9e 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -264,16 +264,14 @@ struct sk_buff {
nohdr:1,
nfctinfo:3;
__u8pkt_type:3,
- fclone:2;
+ fclone:2,
+ ipvs_property:1;
__be16 protocol;
void(*destructor)(struct sk_buff *skb);
#ifdef CONFIG_NETFILTER
__u32 nfmark;
struct nf_conntrack *nfct;
-#if defined(CONFIG_IP_VS) || defined(CONFIG_IP_VS_MODULE)
- __u8ipvs_property:1;
-#endif
#if defined(CONFIG_NF_CONNTRACK) || defined(CONFIG_NF_CONNTRACK_MODULE)
struct sk_buff *nfct_reasm;
#endif
[patch 1/3] atmel: save on array initialization
NET: atmel - do not initialize array over and over again
Signed-off-by: Dmitry Torokhov [EMAIL PROTECTED]
---
drivers/net/wireless/atmel.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
Index: work/drivers/net/wireless/atmel.c
===
--- work.orig/drivers/net/wireless/atmel.c
+++ work/drivers/net/wireless/atmel.c
@@ -826,12 +826,12 @@ static void tx_update_descriptor(struct
static int start_tx (struct sk_buff *skb, struct net_device *dev)
{
+ static const u8 SNAP_RFC1024[6] = { 0xaa, 0xaa, 0x03, 0x00, 0x00, 0x00
};
struct atmel_private *priv = netdev_priv(dev);
struct ieee80211_hdr_4addr header;
unsigned long flags;
u16 buff, frame_ctl, len = (ETH_ZLEN skb-len) ? skb-len : ETH_ZLEN;
- u8 SNAP_RFC1024[6] = {0xaa, 0xaa, 0x03, 0x00, 0x00, 0x00};
-
+
if (priv-card priv-present_callback
!(*priv-present_callback)(priv-card)) {
priv-stats.tx_errors++;
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
VLAN and bridging with xen
I'm trying to get a bridging and VLAN working together with an unexpected lack of success. ICMP pings are working well, but UDP traffic isn't working. Without the VLAN interface I can get my XEN/bridging networking working (but limited by the number of physical interfaces). Without the XEN interfaces I regularly setup VLAN interfaces, as well as using 802.3ad bonding. However I seem to be unable to get the bridges to XEN interfaces working with VLAN's. I'm trying to bridge the traffic from the VLAN interface to a xen vif interface. I only have IP addresses on the virtual Ethernet interfaces (in the xen vm's). I've got a default MTU of 1500. The machine is a dual Opteron, with PCIe SK-9E22 dual GbE (I also have a Intel Pro/1000 dual MT in the machine, but it seems to display the same issue). The kernel is 2.6.12.6 from xen 3.0 unstable. The installation is Fedora Core 4, x86_64. The switch is a Dell 5324. No firewall rules. No bridge filtering. I'm getting desperate to find a fix. I've been trying to work through this for a few weeks, and I've made very little progress. I can provide traffic dumps or any other information. Any help would be appreciated. I must be missing something simple. Thanks, Greg :-) This non-VLAN configuration works ok. eth0--br148--vif7.0--veth0 This VLAN configuration doesn't work. eth0--eth0.148--br148--vif7.0--veth0 This also doesn't work, but is the direction I would like to move towards once I can get the VLAN configuration above working. eth0--+--bond0--bond0.148--br148--vif7.0--veth0 eth1--+ 8- # cat /proc/net/vlan/config VLAN Dev name| VLAN ID Name-Type: VLAN_NAME_TYPE_RAW_PLUS_VID_NO_PAD eth0.148 | 148 | eth0 8- # cat /proc/net/vlan/eth0.148 eth0.148 VID: 148 REORDER_HDR: 1 dev-priv_flags: 1 total frames received 66 total bytes received 4312 Broadcast/Multicast Rcvd0 total frames transmitted 169 total bytes transmitted13801 total headroom inc0 total encap on xmit 169 Device: eth0 INGRESS priority mappings: 0:0 1:0 2:0 3:0 4:0 5:0 6:0 7:0 EGRESSS priority Mappings: 8- # brctl show bridge name bridge id STP enabled interfaces br133 8000.0007e9111f40 no eth2 vif0.0 br140 8000.0007e9111f41 no eth3 vif1.0 vif2.0 br148 8000.5a72a6b6 no eth0.148 vif7.0 br149 8000.5a72a6b7 no eth1 vif6.0 8- # ip addr show 1: lo: LOOPBACK,UP mtu 16436 qdisc noqueue link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo 2: vif0.0: BROADCAST,MULTICAST,UP mtu 1500 qdisc noqueue link/ether fe:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff 3: veth0: BROADCAST,MULTICAST,UP mtu 1500 qdisc noqueue link/ether 00:aa:00:01:33:01 brd ff:ff:ff:ff:ff:ff inet 192.168.133.1/24 brd 192.168.133.255 scope global veth0 5: eth0: BROADCAST,MULTICAST,UP mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:00:5a:72:a6:b6 brd ff:ff:ff:ff:ff:ff 6: eth1: BROADCAST,MULTICAST,UP mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:00:5a:72:a6:b7 brd ff:ff:ff:ff:ff:ff 7: eth2: BROADCAST,MULTICAST,UP mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:07:e9:11:1f:40 brd ff:ff:ff:ff:ff:ff 8: eth3: BROADCAST,MULTICAST,UP mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:07:e9:11:1f:41 brd ff:ff:ff:ff:ff:ff 12: br133: BROADCAST,MULTICAST,UP mtu 1500 qdisc noqueue link/ether 00:07:e9:11:1f:40 brd ff:ff:ff:ff:ff:ff 13: br140: BROADCAST,MULTICAST,UP mtu 1500 qdisc noqueue link/ether 00:07:e9:11:1f:41 brd ff:ff:ff:ff:ff:ff 14: br148: BROADCAST,MULTICAST,UP mtu 1500 qdisc noqueue link/ether 00:00:5a:72:a6:b6 brd ff:ff:ff:ff:ff:ff 15: br149: BROADCAST,MULTICAST,UP mtu 1500 qdisc noqueue link/ether 00:00:5a:72:a6:b7 brd ff:ff:ff:ff:ff:ff 16: eth0.148: BROADCAST,MULTICAST,PROMISC,SLAVE,UP mtu 1500 qdisc noqueue link/ether 00:00:5a:72:a6:b6 brd ff:ff:ff:ff:ff:ff 17: vif1.0: BROADCAST,MULTICAST,UP mtu 1500 qdisc noqueue link/ether fe:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff 18: vif2.0: BROADCAST,MULTICAST,UP mtu 1500 qdisc noqueue link/ether fe:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff 19: vif3.0: BROADCAST,MULTICAST,UP mtu 1500 qdisc noqueue link/ether fe:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff 21: vif5.0: BROADCAST,MULTICAST,UP mtu 1500 qdisc noqueue link/ether fe:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff 22: vif6.0: BROADCAST,MULTICAST,UP mtu 1500 qdisc noqueue link/ether fe:ff:ff:ff:ff:ff brd
Re: [PATCH 02/10]: [NETFILTER]: Defer fragmentation in ip_output when connection tracking is used
Patrick McHardy wrote:
Herbert Xu wrote:
On Fri, Nov 11, 2005 at 03:19:17AM +, Patrick McHardy wrote:
[NETFILTER]: Defer fragmentation in ip_output when connection
tracking is used
I'm slightly uneasy about this change because for POST_ROUTING, the
defragmentation occurs in the middle of the hook, NF_IP_PRI_NAT_SRC.
This means that things like the mangle table currently sees the
fragments as opposed to the whole packet. This patch will change
that.
Now I'm not saying that this is necessarily a bad thing. In fact,
for all I know it might make more sense to do this. But we should
consider the possible implications before embarking on it.
Good point. I would also prefer to have fragmentation occur after
POST_ROUTING in all cases. Looking at the in-tree targets, it means
loosing the ability to do a couple of things:
- CLASSIFY fragments differently
- MARK fragments differently
- DSCP/ECN/TOS mark fragments differently
- Change TTLs of fragments to differently values
None of them seems very important. The DSCP and ECN targets were
broken until not long ago without anyone noticing, the TTL target is
relatively new. So it comes down to loosing the ability to classify
fragments of one packet differently using iptables, which doesn't
make much sense too me. In fact I think it would make classification
easier if mangle would see the whole packet.
How about this patch that moves the POST_ROUTING hook before
fragmentation instead of defering it? Can anyone think of a
reason why mangle/POSTROUTING should see fragments?
[NETFILTER]: Call POST_ROUTING hook before fragmentation
Call POST_ROUTING hook before fragmentation to get rid of the okfn use
in ip_refrag and save the useless fragmentation/defragmentation step
when NAT is used.
The patch introduces one user-visible change, the POSTROUTING chain
in the mangle table gets entire packets, not fragments, which should
simplify use of the MARK and CLASSIFY targets for queueing as a nice
side-effect.
Signed-off-by: Patrick McHardy [EMAIL PROTECTED]
---
commit 1bead31b7e969e00bc5c043d34f20f9edb12a961
tree 16b82a0bedbb29b6a709140a7047ce2d52bb776f
parent 6dafdbcbf8b78409e4767ae30766826f21300a9f
author Patrick McHardy [EMAIL PROTECTED] Sat, 19 Nov 2005 07:58:46 +0100
committer Patrick McHardy [EMAIL PROTECTED] Sat, 19 Nov 2005 07:58:46 +0100
include/net/ip.h |1 -
net/ipv4/ip_output.c | 30 +++-
net/ipv4/netfilter/ip_conntrack_standalone.c | 26 +
net/ipv4/netfilter/ip_nat_standalone.c | 17 --
net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c | 26 +
5 files changed, 16 insertions(+), 84 deletions(-)
diff --git a/include/net/ip.h b/include/net/ip.h
index e4563bb..9f09882 100644
--- a/include/net/ip.h
+++ b/include/net/ip.h
@@ -310,7 +310,6 @@ enum ip_defrag_users
IP_DEFRAG_CALL_RA_CHAIN,
IP_DEFRAG_CONNTRACK_IN,
IP_DEFRAG_CONNTRACK_OUT,
- IP_DEFRAG_NAT_OUT,
IP_DEFRAG_VS_IN,
IP_DEFRAG_VS_OUT,
IP_DEFRAG_VS_FWD
diff --git a/net/ipv4/ip_output.c b/net/ipv4/ip_output.c
index 11c2f68..946e812 100644
--- a/net/ipv4/ip_output.c
+++ b/net/ipv4/ip_output.c
@@ -202,13 +202,11 @@ static inline int ip_finish_output2(stru
static inline int ip_finish_output(struct sk_buff *skb)
{
- struct net_device *dev = skb-dst-dev;
-
- skb-dev = dev;
- skb-protocol = htons(ETH_P_IP);
-
- return NF_HOOK(PF_INET, NF_IP_POST_ROUTING, skb, NULL, dev,
- ip_finish_output2);
+ if (skb-len dst_mtu(skb-dst)
+ !(skb_shinfo(skb)-ufo_size || skb_shinfo(skb)-tso_size))
+ return ip_fragment(skb, ip_finish_output2);
+ else
+ return ip_finish_output2(skb);
}
int ip_mc_output(struct sk_buff *skb)
@@ -265,21 +263,21 @@ int ip_mc_output(struct sk_buff *skb)
newskb-dev, ip_dev_loopback_xmit);
}
- if (skb-len dst_mtu(rt-u.dst))
- return ip_fragment(skb, ip_finish_output);
- else
- return ip_finish_output(skb);
+ return NF_HOOK(PF_INET, NF_IP_POST_ROUTING, skb, NULL, skb-dev,
+ ip_finish_output);
}
int ip_output(struct sk_buff *skb)
{
+ struct net_device *dev = skb-dst-dev;
+
IP_INC_STATS(IPSTATS_MIB_OUTREQUESTS);
- if (skb-len dst_mtu(skb-dst)
- !(skb_shinfo(skb)-ufo_size || skb_shinfo(skb)-tso_size))
- return ip_fragment(skb, ip_finish_output);
- else
- return ip_finish_output(skb);
+ skb-dev = dev;
+ skb-protocol = htons(ETH_P_IP);
+
+ return NF_HOOK(PF_INET, NF_IP_POST_ROUTING, skb, NULL, dev,
+ ip_finish_output);
}
int ip_queue_xmit(struct sk_buff *skb, int ipfragok)
diff --git a/net/ipv4/netfilter/ip_conntrack_standalone.c
