Re: ipsec tunnel asymmetrical mtu
Marco Berizzi <[EMAIL PROTECTED]> wrote:
>
> Running 'tcpdump -p -n -v ip net 10.16.24.117' on mimosa
> resolves the problem: sapgui clients can connect to sap
> servers while tcpdump is running on mimosa.
> Is this a bug?
Very strange. Could you perhaps move the tcpdump to another machine
so that we can observe what's going on without disturbing the bug?
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
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] net drivers: fix section attributes for gcc
From: Randy Dunlap <[EMAIL PROTECTED]>
If CONFIG_HOTPLUG=n, gcc doesn't like some __initdata to be
const (rodata) and other __initdata not const, so make the
non-const __initdata const.
gcc errors:
drivers/net/bnx2.c:66: error: version causes a section type conflict
drivers/net/starfire.c:338: error: version causes a section type conflict
drivers/net/typhoon.c:137: error: version causes a section type conflict
drivers/net/natsemi.c:241: error: version causes a section type conflict
Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]>
---
drivers/net/bnx2.c |2 +-
drivers/net/natsemi.c |2 +-
drivers/net/starfire.c |2 +-
drivers/net/typhoon.c |2 +-
4 files changed, 4 insertions(+), 4 deletions(-)
--- linux-2617-rc1.orig/drivers/net/bnx2.c
+++ linux-2617-rc1/drivers/net/bnx2.c
@@ -63,7 +63,7 @@
/* Time in jiffies before concluding the transmitter is hung. */
#define TX_TIMEOUT (5*HZ)
-static char version[] __devinitdata =
+static const char version[] __devinitdata =
"Broadcom NetXtreme II Gigabit Ethernet Driver " DRV_MODULE_NAME " v"
DRV_MODULE_VERSION " (" DRV_MODULE_RELDATE ")\n";
MODULE_AUTHOR("Michael Chan <[EMAIL PROTECTED]>");
--- linux-2617-rc1.orig/drivers/net/natsemi.c
+++ linux-2617-rc1/drivers/net/natsemi.c
@@ -238,7 +238,7 @@ static int full_duplex[MAX_UNITS];
#define NATSEMI_RX_LIMIT 2046/* maximum supported by hardware */
/* These identify the driver base version and may not be removed. */
-static char version[] __devinitdata =
+static const char version[] __devinitdata =
KERN_INFO DRV_NAME " dp8381x driver, version "
DRV_VERSION ", " DRV_RELDATE "\n"
KERN_INFO " originally by Donald Becker <[EMAIL PROTECTED]>\n"
--- linux-2617-rc1.orig/drivers/net/starfire.c
+++ linux-2617-rc1/drivers/net/starfire.c
@@ -335,7 +335,7 @@ do { \
/* These identify the driver base version and may not be removed. */
-static char version[] __devinitdata =
+static const char version[] __devinitdata =
KERN_INFO "starfire.c:v1.03 7/26/2000 Written by Donald Becker <[EMAIL
PROTECTED]>\n"
KERN_INFO " (unofficial 2.2/2.4 kernel port, version " DRV_VERSION ", "
DRV_RELDATE ")\n";
--- linux-2617-rc1.orig/drivers/net/typhoon.c
+++ linux-2617-rc1/drivers/net/typhoon.c
@@ -134,7 +134,7 @@ static const int multicast_filter_limit
#include "typhoon.h"
#include "typhoon-firmware.h"
-static char version[] __devinitdata =
+static const char version[] __devinitdata =
"typhoon.c: version " DRV_MODULE_VERSION " (" DRV_MODULE_RELDATE ")\n";
MODULE_AUTHOR("David Dillow <[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] softmac uses Wiress Ext.
I still get this on 2.6.17-rc1... Did anyone on netdev pick it up last week? Date: Mon, 27 Mar 2006 14:53:41 -0800 From: "Randy.Dunlap" <[EMAIL PROTECTED]> To: netdev Cc: [EMAIL PROTECTED] Subject: [PATCH] softmac uses Wiress Ext. From: Randy Dunlap <[EMAIL PROTECTED]> softmac uses wireless extensions, so let it SELECT that config option; WARNING: "wireless_send_event" [net/ieee80211/softmac/ieee80211softmac.ko] undefined! Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]> --- net/ieee80211/softmac/Kconfig |1 + 1 files changed, 1 insertion(+) --- linux-2616-g13.orig/net/ieee80211/softmac/Kconfig +++ linux-2616-g13/net/ieee80211/softmac/Kconfig @@ -1,6 +1,7 @@ config IEEE80211_SOFTMAC tristate "Software MAC add-on to the IEEE 802.11 networking stack" depends on IEEE80211 && EXPERIMENTAL + select WIRELESS_EXT ---help--- This option enables the hardware independent software MAC addon for the IEEE 802.11 networking stack. --- - 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
[IPSEC]: Check x->encap before dereferencing it
On Mon, Apr 03, 2006 at 11:33:16PM +0200, Christophe Saout wrote:
>
> I'm getting a crash in xfrm4_rcv_encap few seconds after setting up my
> IPSEC connection (tunnel for default route 0.0.0.0/0 to next router).
Sorry about that. This patch should fix the problem.
[IPSEC]: Check x->encap before dereferencing it
We need to dereference x->encap before dereferencing it for encap_type.
If it's absent then the encap_type is zero.
Signed-off-by: Herbert Xu <[EMAIL PROTECTED]>
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
diff --git a/net/ipv4/ipip.c b/net/ipv4/ipip.c
diff --git a/net/ipv4/tunnel4.c b/net/ipv4/tunnel4.c
diff --git a/net/ipv4/xfrm4_input.c b/net/ipv4/xfrm4_input.c
index e1b8f4b..7a0b952 100644
--- a/net/ipv4/xfrm4_input.c
+++ b/net/ipv4/xfrm4_input.c
@@ -90,7 +90,7 @@
if (unlikely(x->km.state != XFRM_STATE_VALID))
goto drop_unlock;
- if (x->encap->encap_type != encap_type)
+ if ((x->encap ? x->encap->encap_type : 0) != encap_type)
goto drop_unlock;
if (x->props.replay_window && xfrm_replay_check(x, seq))
diff --git a/net/ipv6/ip6_tunnel.c b/net/ipv6/ip6_tunnel.c
diff --git a/net/ipv6/tunnel6.c b/net/ipv6/tunnel6.c
Re: [e1000 debug] KERNEL: assertion (!sk_forward_alloc) failed...
Hello, Phil Oester. On 04.04.2006 01:39 you said the following: On Mon, Apr 03, 2006 at 04:01:23PM -0500, Mark Nipper wrote: After three days and some hours, I finally saw another event: Ack, same here. Looked hopeful, but finally saw the error today. Phil [EMAIL PROTECTED] ~]# dmesg |grep assertion |wc -l 176 [EMAIL PROTECTED] ~]# uptime 02:00:01 up 3 days, 7:31, 2 users, load average: 1.32, 0.59, 0.41 -- Boris B. Zhmurov mailto: [EMAIL PROTECTED] "wget http://kernelpanic.ru/bb_public_key.pgp -O - | gpg --import" - 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: [e1000 debug] KERNEL: assertion (!sk_forward_alloc) failed...
On Mon, Apr 03, 2006 at 04:01:23PM -0500, Mark Nipper wrote: > After three days and some hours, I finally saw another > event: Ack, same here. Looked hopeful, but finally saw the error today. Phil - 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
2.6.17-rc1 crash in xfrm4_rcv_encap
Hello,
I'm getting a crash in xfrm4_rcv_encap few seconds after setting up my
IPSEC connection (tunnel for default route 0.0.0.0/0 to next router).
The call chain is:
softirq
...
net_rx_action
process_backlog
netif_receive_skb
ip_rcv
ip_local_deliver
xfrm4_rcv
xfrm4_rcv_encap
The crash occurs here:
87: 0f 85 5f 01 00 00 jne1ec
8d: 8b 80 dc 00 00 00 mov0xdc(%eax),%eax
93: 8b 55 c8mov0xffc8(%ebp),%edx
> 96: 66 39 10cmp%dx,(%eax)
99: 0f 85 4d 01 00 00 jne1ec
9f: 80 7f 71 00 cmpb $0x0,0x71(%edi)
a3: 74 12 je b7
With %eax being 0 at that point.
This corresponds to line 93 in xfrm4_input.c:
if (x->encap->encap_type != encap_type)
Where x->encap is NULL.
This line has been added there (moved around from esp_input) in this
patch titled "[IPSEC]: Kill unused decap state argument":
http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=e695633e21ffb6a443a8c2f8b3f095c7f1a48eb0
The check "(encap->encap_type != decap->decap_type)" removed from
esp_input was just inside an if block that checked for whether x->encap
was set: "if (x->encap) {...}" whereas the checked moved to
xfrm4_rcv_encap doesn't check for validity of x->encap.
So, my guess is that the check should be added there too (?)
--- linux.orig/net/ipv4/xfrm4_input.c 2006-04-03 16:24:47.0 +0200
+++ linux/net/ipv4/xfrm4_input.c2006-04-03 23:31:00.0 +0200
@@ -90,7 +90,7 @@
if (unlikely(x->km.state != XFRM_STATE_VALID))
goto drop_unlock;
- if (x->encap->encap_type != encap_type)
+ if (x->encap && x->encap->encap_type != encap_type)
goto drop_unlock;
if (x->props.replay_window && xfrm_replay_check(x, seq))
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
Re: [PATCH 2/9] NetXen 1G/10G driver
O
> > +static int
> > +netxen_nic_set_wol(struct net_device *netdev, struct ethtool_wolinfo *wol)
> > +{
> > +// can't implement as WOL register is not known !!
> > +return 0;
>
> If it can not be implemented, it should return something < 0, say -EINVAL.
>
ethtool does the right thing if you just leave that entry NULL in
the ethtool_ops structure.
-
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: [e1000 debug] KERNEL: assertion (!sk_forward_alloc) failed...
On 31 Mar 2006, Herbert Xu wrote: > If it still fails, here is a debugging patch which should tell us > whether we need to look elsewhere. After three days and some hours, I finally saw another event: --- Apr 3 13:40:53 king kernel: KERNEL: assertion (!sk->sk_forward_alloc) failed at net/core/stream.c (283) Apr 3 13:40:53 king kernel: KERNEL: assertion (!sk->sk_forward_alloc) failed at net/ipv4/af_inet.c (150) --- but as with the other person who reported recently, I also did not receive the extra debugging output from Herbert's latest patch. Anyway, this happened with 2.6.16.1 and Herbert's three patches. Let me know if you want me to try anything different. I guess all of this will just go away with the latest driver version since those of us running at 100Mbps will no longer have TSO enabled? -- Mark Nippere-contacts: 832 Tanglewood Drive[EMAIL PROTECTED] Bryan, Texas 77802-4013 http://nipsy.bitgnome.net/ (979)575-3193 AIM/Yahoo: texasnipsy ICQ: 66971617 -BEGIN GEEK CODE BLOCK- Version: 3.1 GG/IT d- s++:+ a- C++$ UBL$ P--->+++ L+++$ !E--- W++(--) N+ o K++ w(---) O++ M V(--) PS+++(+) PE(--) Y+ PGP t+ 5 X R tv b+++@ DI+(++) D+ G e h r++ y+(**) --END GEEK CODE BLOCK-- ---begin random quote of the moment--- He hoped and prayed that there wasn't an afterlife. Then he realized there was a contradiction involved here and merely hoped that there wasn't an afterlife. -- Douglas Adams end random quote of the moment - 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 9/9] NetXen 1G/10G driver
Linsys Contractor Amit S. Kale <[EMAIL PROTECTED]> :
> diff -Naru linux-2.6.16_orig/drivers/net/netxen/netxen_brdcfg.h
> linux-2.6.16/drivers/net/netxen/netxen_brdcfg.h
> --- linux-2.6.16_orig/drivers/net/netxen/netxen_brdcfg.h 1969-12-31
> 16:00:00.0 -0800
> +++ linux-2.6.16/drivers/net/netxen/netxen_brdcfg.h 2006-03-24
> 14:13:57.0 -0800
[...]
> +typedef struct {
Yuck, typedef !
> +U32 header_version;
> +
> +U32 board_mfg;
> +//netxen_brdid_t board_id;
> +U32 board_type;
> +U32 board_num;
> +//netxen_chipid_t chip_id;
> +U32 chip_id;
> +U32 chip_minor;
> +U32 chip_major;
> +U32 chip_pkg;
> +U32 chip_lot;
The code uses U32, uint32_t, __uint32_t, u32.
What about always using the same type, especially the shortest one ?
[elsewhere in code]
> +#define PCI_DMA_64BIT0xULL
> +#define PCI_DMA_32BIT0xULL
DMA_{32/64}BIT_MASK should do the same.
--
Ueimor
-
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 3/9] NetXen 1G/10G driver
Linsys Contractor Amit S. Kale <[EMAIL PROTECTED]> :
> diff -Naru linux-2.6.16_orig/drivers/net/netxen/netxen_nic_hw.c
> linux-2.6.16/drivers/net/netxen/netxen_nic_hw.c
> --- linux-2.6.16_orig/drivers/net/netxen/netxen_nic_hw.c 1969-12-31
> 16:00:00.0 -0800
> +++ linux-2.6.16/drivers/net/netxen/netxen_nic_hw.c 2006-03-24
> 14:13:57.0 -0800
[...]
> +int
> +netxen_nic_hw_write_wx(netxen_adapter *adapter, u64 off, void *data, int len)
> +{//This is modified from _netxen_nic_hw_write()._netxen_nic_hw_write does
> not exist now.
> +void *addr;
Add some __iomem annotation ?
[...]
> +void netxen_nic_set_link_parameters(struct netxen_port *port)
> +{
> +struct netxen_adapter_s *adapter = port->adapter;
> +netxen_niu_phy_status_t status;
> +uint16_t autoneg;
> +netxen_niu_control_t mode;
> +
> + netxen_nic_read_w0(adapter, NetXen_NIU_MODE, (uint32_t *)&mode);
> +if(mode.enable_ge) { // Gb 10/100/1000 Mbps mode
> +if (netxen_nic_phy_read(port->adapter,port->portnum,
> +NetXen_NIU_GB_MII_MGMT_ADDR_PHY_STATUS,
> +(netxen_crbword_t *)&status) == 0) {
> +if(status.link) {
Please use goto and shift everything left...
[...]
> +} else {
> +port->state = -1;
> +port->link_speed = -1;
> +port->link_duplex = -1;
> +}
> +} else {
> +port->state = -1;
> +port->link_speed = -1;
> +port->link_duplex = -1;
> +}
... it should help factoring this stuff.
--
Ueimor
-
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] acenic: fix section mismatches
On Mon, 3 Apr 2006 19:27:25 +0200 Sam Ravnborg wrote:
> On Mon, Apr 03, 2006 at 10:27:32AM -0700, Randy.Dunlap wrote:
> > On Sun, 2 Apr 2006 23:12:03 +0200 Sam Ravnborg wrote:
> >
> > > On Mon, Mar 27, 2006 at 02:32:14PM -0800, Randy.Dunlap wrote:
> > > > >
> > > > > Sam, I am now seeing this error (not a WARNING like the previous ones
> > > > > were):
> > > > >
> > > > > drivers/net/typhoon.c:137: error: version causes a section type
> > > > > conflict
> > > > >
> > > > > but I don't see a real problem in the driver source file.
> > > > > Ideas, anyone?
> > > >
> > > > This happens for typhoon (above) as well as:
> > > >
> > > > drivers/net/natsemi.c:241: error: version causes a section type conflict
> > >
> > > I have taken a look at natsemi.c.
> > > Following patch fixes the error:
> > >
> > > diff --git a/drivers/net/natsemi.c b/drivers/net/natsemi.c
> > > index 7826afb..a36a15e 100644
> > > --- a/drivers/net/natsemi.c
> > > +++ b/drivers/net/natsemi.c
> > > @@ -372,7 +372,7 @@ enum pcistuff {
> > > static const struct {
> > > const char *name;
> > > unsigned long flags;
> > > -} natsemi_pci_info[] __devinitdata = {
> > > +} natsemi_pci_info[] /*__devinitdata*/ = {
> > > { "NatSemi DP8381[56]", PCI_IOTYPE },
> > > };
> > >
> > > The reason why gcc barfs over it seems to be conflicting sections
> > > between the function natsemi_probe1() where natsemi_pci_info[] is used
> > > and the section of natsemi_pci_info.
> > > But putting them in same section did not help.
> > >
> > > I'm a bit puzzeled what is going on. Randy - any insight in this?
> >
> > How weird. I can't reproduce this at all now. Tried several times.
> You need to build with CONFIG_HOTPLUG undefined to see it..
Thanks for the reminder. I see the problem.
gcc doesn't like for some __initdata to be const and others not, which is
what it's complaining about. Marking the driver as 'const'
also fixes this problem. This needs to be done in:
typhoon, starfire, natsemi, and bnx2
Any volunteers to do this?
---
~Randy
-
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/9] NetXen 1G/10G driver
Linsys Contractor Amit S. Kale <[EMAIL PROTECTED]> :
> diff -Naru linux-2.6.16_orig/drivers/net/netxen/netxen_nic_ethtool.c
> linux-2.6.16/drivers/net/netxen/netxen_nic_ethtool.c
> --- linux-2.6.16_orig/drivers/net/netxen/netxen_nic_ethtool.c 1969-12-31
> 16:00:00.0 -0800
> +++ linux-2.6.16/drivers/net/netxen/netxen_nic_ethtool.c 2006-03-24
> 14:13:57.0 -0800
[...]
> +static const struct netxen_nic_stats netxen_nic_gstrings_stats[] = {
> +{ "rcvd bad skb", NetXen_NIC_STAT(stats.rcvdbadskb) },
> +{ "xmit called", NetXen_NIC_STAT(stats.xmitcalled) },
> +{ "xmited frames",NetXen_NIC_STAT(stats.xmitedframes) },
> +{ "xmit finished",NetXen_NIC_STAT(stats.xmitfinished) },
> +{ "bad skb len", NetXen_NIC_STAT(stats.badskblen) },
> +{ "no cmd desc", NetXen_NIC_STAT(stats.nocmddescriptor) },
> +{ "polled", NetXen_NIC_STAT(stats.polled) },
> +{ "uphappy", NetXen_NIC_STAT(stats.uphappy) },
> +{ "updropped",NetXen_NIC_STAT(stats.updropped) },
> +{ "uplcong", NetXen_NIC_STAT(stats.uplcong) },
> +{ "uphcong", NetXen_NIC_STAT(stats.uphcong) },
> +{ "upmcong", NetXen_NIC_STAT(stats.upmcong) },
> +{ "updunno", NetXen_NIC_STAT(stats.updunno) },
> +{ "skb freed",NetXen_NIC_STAT(stats.skbfreed) },
> +{ "tx dropped", NetXen_NIC_STAT(stats.txdropped) },
> +{ "tx null skb", NetXen_NIC_STAT(stats.txnullskb) },
> +{ "csummed", NetXen_NIC_STAT(stats.csummed) },
> +{ "no rcv", NetXen_NIC_STAT(stats.no_rcv) },
> +{ "rx bytes", NetXen_NIC_STAT(stats.rxbytes) },
> +{ "tx bytes", NetXen_NIC_STAT(stats.txbytes) },
> +};
Please use "_" instead of " " (see drivers/net/).
[...]
> +static int
> +netxen_nic_get_eeprom_len(struct net_device *netdev)
> +{
> +struct netxen_port *port = netdev->priv;
s/netdev->priv/netdev_priv(netdev)/
Btw it is quite common to use 'dev' instead of 'netdev'. Your call.
[...]
> +static void
> +netxen_nic_get_regs(struct net_device *netdev, struct ethtool_regs *regs,
> void *p)
> +{
> +struct netxen_port*port = netdev->priv;
> +struct netxen_adapter_s *adapter = port->adapter;
> +netxen_crbword_t mode, *regs_buff = p;
> +unsigned long flags;
> +void *addr;
> +
> +memset(p, 0, NetXen_NIC_REGS_LEN);
> +regs->version = (1 << 24) | (adapter->ahw.revision_id << 16) |
> +adapter->ahw.device_id;
> +write_lock_irqsave(&adapter->adapter_lock, flags);
> +// which mode
> +NetXen_NIC_LOCKED_READ_REG(NetXen_NIU_MODE, ®s_buff[0]);
> +mode = regs_buff[0];
> +
> +// Common registers to all the modes
> +NetXen_NIC_LOCKED_READ_REG(NetXen_NIU_STRAP_VALUE_SAVE_HIGHER,
> ®s_buff[2]);
> +switch(mode) {
> +case 4: {//XGB Mode
> +NetXen_NIC_LOCKED_READ_REG(NetXen_NIU_XG_SINGLE_TERM,
> ®s_buff[3]);
> +NetXen_NIC_LOCKED_READ_REG(NetXen_NIU_XG_DRIVE_HI,
> ®s_buff[4]);
> +NetXen_NIC_LOCKED_READ_REG(NetXen_NIU_XG_DRIVE_LO,
> ®s_buff[5]);
[snip]
No need to unroll the loop: please use some data array + a for loop.
[...]
> +static int
> +netxen_nic_set_wol(struct net_device *netdev, struct ethtool_wolinfo *wol)
> +{
> +// can't implement as WOL register is not known !!
> +return 0;
If it can not be implemented, it should return something < 0, say -EINVAL.
--
Ueimor
-
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: [NETFILTER]: Fix fragmentation issues with bridge netfilter
Op ma, 03-04-2006 te 15:43 +0200, schreef Patrick McHardy: > Fix a regression from the netfilter/IPsec patches with bridging. > Bart, please review this patch, if everything is fine I think it > should also go in -stable. Looks fine to me. Thanks, Bart - 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
Changes to neigh_forced_gc in neighbour.c
Hi,
We've been running 2.4.27 as routers for some time now with good success.
(Yes, yes, I need to reply to those emails about newer kernels being
slower...) Anyway, I was noticing that neigh_lookup was taking a bunch of
CPU and noticed that the hash table size was fixed to 16 buckets in these
kernel versions...Whoops. 2.4.28 (and 2.6.9) seem to allow for dynamic
growth, which is good.
When looking at other changes made to neighbour.c, I noticed something
which stood out: the minimum hold time for entries was removed. See
these partial chunks from patch-2.4.28:
- - (NEW and probably wrong)
-INCOMPLETE entries are kept at least for
-n->parms->retrans_time, otherwise we could
-flood network with resolution requests.
-It is not clear, what is better table overflow
-or flooding.
...
if (atomic_read(&n->refcnt) == 1 &&
- !(n->nud_state&NUD_PERMANENT) &&
- (n->nud_state != NUD_INCOMPLETE ||
-jiffies - n->used > n->parms->retrans_time)) {
+ !(n->nud_state&NUD_PERMANENT)) {
*np = n->next;
n->dead = 1;
I think this can cause a larger problem than perhaps expected. Because
routers don't keep any reference to neighbour entries other than from the
rtcache, and because routers running BGP with full tables can get
frequent table updates thus toasting the rtcache, I think it can be very
easy for the occasional neigh_forced_gc() run to toast a bunch of active
(but not referenced) ARP entries, causing a bunch of ARP lookup flooding.
Are there any other mechanisms for keeping neigh entries around if the
rtcache is no longer pointing to them? It seems that this could easily
result in a lot of ARP flooding for routers where gc_thresh2 hasn't been
raised above the expected number of entries.
Simon-
-
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] acenic: fix section mismatches
On Mon, Apr 03, 2006 at 10:27:32AM -0700, Randy.Dunlap wrote:
> On Sun, 2 Apr 2006 23:12:03 +0200 Sam Ravnborg wrote:
>
> > On Mon, Mar 27, 2006 at 02:32:14PM -0800, Randy.Dunlap wrote:
> > > >
> > > > Sam, I am now seeing this error (not a WARNING like the previous ones
> > > > were):
> > > >
> > > > drivers/net/typhoon.c:137: error: version causes a section type conflict
> > > >
> > > > but I don't see a real problem in the driver source file.
> > > > Ideas, anyone?
> > >
> > > This happens for typhoon (above) as well as:
> > >
> > > drivers/net/natsemi.c:241: error: version causes a section type conflict
> >
> > I have taken a look at natsemi.c.
> > Following patch fixes the error:
> >
> > diff --git a/drivers/net/natsemi.c b/drivers/net/natsemi.c
> > index 7826afb..a36a15e 100644
> > --- a/drivers/net/natsemi.c
> > +++ b/drivers/net/natsemi.c
> > @@ -372,7 +372,7 @@ enum pcistuff {
> > static const struct {
> > const char *name;
> > unsigned long flags;
> > -} natsemi_pci_info[] __devinitdata = {
> > +} natsemi_pci_info[] /*__devinitdata*/ = {
> > { "NatSemi DP8381[56]", PCI_IOTYPE },
> > };
> >
> > The reason why gcc barfs over it seems to be conflicting sections
> > between the function natsemi_probe1() where natsemi_pci_info[] is used
> > and the section of natsemi_pci_info.
> > But putting them in same section did not help.
> >
> > I'm a bit puzzeled what is going on. Randy - any insight in this?
>
> How weird. I can't reproduce this at all now. Tried several times.
You need to build with CONFIG_HOTPLUG undefined to see it..
Sam
-
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] acenic: fix section mismatches
On Sun, 2 Apr 2006 23:12:03 +0200 Sam Ravnborg wrote:
> On Mon, Mar 27, 2006 at 02:32:14PM -0800, Randy.Dunlap wrote:
> > >
> > > Sam, I am now seeing this error (not a WARNING like the previous ones
> > > were):
> > >
> > > drivers/net/typhoon.c:137: error: version causes a section type conflict
> > >
> > > but I don't see a real problem in the driver source file.
> > > Ideas, anyone?
> >
> > This happens for typhoon (above) as well as:
> >
> > drivers/net/natsemi.c:241: error: version causes a section type conflict
>
> I have taken a look at natsemi.c.
> Following patch fixes the error:
>
> diff --git a/drivers/net/natsemi.c b/drivers/net/natsemi.c
> index 7826afb..a36a15e 100644
> --- a/drivers/net/natsemi.c
> +++ b/drivers/net/natsemi.c
> @@ -372,7 +372,7 @@ enum pcistuff {
> static const struct {
> const char *name;
> unsigned long flags;
> -} natsemi_pci_info[] __devinitdata = {
> +} natsemi_pci_info[] /*__devinitdata*/ = {
> { "NatSemi DP8381[56]", PCI_IOTYPE },
> };
>
> The reason why gcc barfs over it seems to be conflicting sections
> between the function natsemi_probe1() where natsemi_pci_info[] is used
> and the section of natsemi_pci_info.
> But putting them in same section did not help.
>
> I'm a bit puzzeled what is going on. Randy - any insight in this?
How weird. I can't reproduce this at all now. Tried several times.
---
~Randy
-
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
Fw: [Bug 6322] New: Kernel Panic (i think nf_br component)
Begin forwarded message: Date: Mon, 3 Apr 2006 04:26:21 -0700 From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: [Bug 6322] New: Kernel Panic (i think nf_br component) http://bugzilla.kernel.org/show_bug.cgi?id=6322 Summary: Kernel Panic (i think nf_br component) Kernel Version: 2.6.16.0 Status: NEW Severity: high Owner: [EMAIL PROTECTED] Submitter: [EMAIL PROTECTED] Most recent kernel where this bug did not occur: in 2.6.15.x not see. Distribution: Slackware 10.2 updated to current Hardware Environment: 00:00.0 Host bridge: Intel Corporation 915G/P/GV/GL/PL/910GL Processor to I/O Controller (rev 04) 00:1c.0 PCI bridge: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) PCI Express Port 1 (rev 03) 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev d3) 00:1f.0 ISA bridge: Intel Corporation 82801FB/FR (ICH6/ICH6R) LPC Interface Bridge (rev 03) 00:1f.1 IDE interface: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) IDE Controller (rev 03) 00:1f.2 IDE interface: Intel Corporation 82801FR/FRW (ICH6R/ICH6RW) SATA Controller (rev 03) 00:1f.3 SMBus: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) SMBus Controller (rev 03) 01:09.0 Ethernet controller: 3Com Corporation 3c905C-TX/TX-M [Tornado] (rev 78) 01:0a.0 Ethernet controller: 3Com Corporation 3c905C-TX/TX-M [Tornado] (rev 78) 01:0b.0 VGA compatible controller: ATI Technologies Inc 3D Rage II+ 215GTB [Mach64 GTB] (rev 9a) Software Environment: Problem Description: now 2.6.16.1 and normaly work 2 days. in 2.6.16.0 - have 2 kernel panic for 1 week. This last Server used how Bridge + Traffic Shaper... have more than 10k tc rules (used hash tables) and over 4k iptables rules. TC used: htc red class, sfq qdisc, u32 filter only iptables use psydev module. Channel have 60 mbs any time. 2k+ clients. Steps to reproduce: I try attach .config and screenshots (from photo) --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - 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
Fw: [Bug 6295] New: unregister_netdevice loops indefinitely when bringing down an interface if static ARP entries are present
Begin forwarded message: Date: Mon, 27 Mar 2006 23:12:50 -0800 From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: [Bug 6295] New: unregister_netdevice loops indefinitely when bringing down an interface if static ARP entries are present http://bugzilla.kernel.org/show_bug.cgi?id=6295 Summary: unregister_netdevice loops indefinitely when bringing down an interface if static ARP entries are present Kernel Version: 2.6.16 Status: NEW Severity: normal Owner: [EMAIL PROTECTED] Submitter: [EMAIL PROTECTED] Most recent kernel where this bug did not occur: 2.6.8 Distribution: Debian unstable, bug reproduced with vanilla kernel from kernel.org Problem Description: When using a VPN client, such as openvpn or gvpe, killing the client (which should result in bringing down of the VPN interface) deadlocks it in D+ state, if static ARP entries are present for the interface. Kernel periodically emits messages "unregister_netdevice: waiting for to become free. Usage count = 1". The usage count number is equal to the number of the static ARP entries. Thanks a lot to Marc Lehmann for patient debugging of this problem and constructing the test case. Steps to reproduce (using openvpn, all mentioned addresses are non-existent): # modprobe tun # openvpn --remote 192.168.1.111 --dev tun1 --ifconfig 10.0.0.1 10.0.0.2 In another console: # ip neigh add to 10.0.0.3 dev tun1 nud permanent Return to the console in which openvpn is running and press Ctrl-C. The openvpn process hangs in D+ state (can't be killed), error messages mentioned above are periodically produced on the console. Best regards, Jurij Smakov[EMAIL PROTECTED] Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - 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 0/9] NetXen 1G/10G driver
> diff -Naru linux-2.6.16_orig/drivers/net/netxen/Makefile > linux-2.6.16/drivers/net/netxen/Makefile > --- linux-2.6.16_orig/drivers/net/netxen/Makefile 1969-12-31 > 16:00:00.0 -0800 > +++ linux-2.6.16/drivers/net/netxen/Makefile 2006-03-24 14:25:53.0 > -0800 > @@ -0,0 +1,40 @@ > +# Copyright (C) 2003 - 2006 NetXen Inc. > +# All rights reserved. > > + > +BUILD_PLATFORM=$(shell uname -p) > + > +CFLAGS += -DP2 No magic hidden defines? > + > +ifeq ($(BUILD_PLATFORM),x86_64) > + CFLAGS += -mcmodel=kernel -mno-red-zone -fno-unit-at-a-time > -fno-reorder-blocks > +endif Why? what did you do wrong? > + > +obj-$(CONFIG_NetXen_NIC) += netxen_nic.o > + > +netxen_nic-objs := netxen_nic_hw.o netxen_nic_main.o netxen_nic_ethtool.o > niu.o netxen_nic_init.o netxen_nic_isr.o xge_mdio.o > diff -Naru linux-2.6.16_orig/drivers/net/netxen/README > linux-2.6.16/drivers/net/netxen/README > --- linux-2.6.16_orig/drivers/net/netxen/README 1969-12-31 > 16:00:00.0 -0800 > +++ linux-2.6.16/drivers/net/netxen/README2006-03-24 14:10:24.0 > -0800 > @@ -0,0 +1,10 @@ > +This contains the source file for the NetXen Linux driver. It is released > +under the GPL license. This is released without any warrany. See the > +GPL notice in the individual files for more details. > + > + > +To build the driver, do the following: > + > +1. untar the archive. > +2. cd /lib/modules/$(uname -r)/build (or wherever your kernel tree is) > +3. make SUBDIRS=dir-path-to-netxen-driver modules > Don't put out of tree build instructions in kernel tree! - 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 1.1/9] NetXen 1G/10G driver
On
> +#undef NetXen_LOOPBACK
> +#undef SINGLE_DMA_BUF
> +#define NetXen_NIC_HW_CSUM
> +#define NetXen_NIC_NAPI
> +// #undef NetXen_NIC_NAPI
> +
> +#define NetXen_NETIF_F_TSO
Ugh. MixedCase define's and ifdef configuration message.
Remember, either keep the code or remove it.
> +// for cmd line parameteres--
> +#define NetXen_PARAM(X,S) \
> +static int X=0; \
> +MODULE_PARM(X,"i"); \
> +MODULE_PARM_DESC(X,S);
>
More macro crap.
> +
> +
> +MODULE_AUTHOR("NetXen");
Author is a human, not a company.
> +MODULE_DESCRIPTION("NetXen Multi port (1/10) Gigabit Network Driver");
> +MODULE_LICENSE("GPL");
> +
> +/*static int netxen_nic_debug = NETIF_MSG_DRV | NETIF_MSG_PROBE; TODO */
> +int netxen_nic_debug;
"static int debug" is good better.
> +
> +MODULE_PARM(netxen_nic_debug, "i");
> +MODULE_PARM_DESC(netxen_nic_debug, "Debug level (0=none,...,16=all)");
> +
> +
> +char netxen_nic_driver_name[] = "netxen";
can be "static const char"
> +char netxen_nic_driver_string[] = "NetXen Network Driver version "
> + NetXen_NIC_LINUX_VERSIONID
> + "-"
> + NetXen_NIC_BUILD_NO
> + " generated "
> + NetXen_NIC_TIMESTAMP;
> +
> +#ifndef ARCH_KMALLOC_MINALIGN
> +#define ARCH_KMALLOC_MINALIGN 0
> +#endif
> +#ifndef ARCH_KMALLOC_FLAGS
> +#define ARCH_KMALLOC_FLAGS SLAB_HWCACHE_ALIGN
> +#endif
More macro obfuscation.
> +
> +#define NetXen_NETDEV_WEIGHT 120
> +#define ADAPTER_UP_MAGIC 777
> +
> +kmem_cache_t *cmd_desc_cache = NULL;
> +kmem_cache_t *cmd_buff_cache = NULL;
> +cmdDescType0_t *cmd_desc_array[NR_CPUS];
> +struct netxen_cmd_buffer *cmd_buff_array[NR_CPUS];
> +
> +static int netxen_nic_probe_err = 0;
> +
> +#define RCV_DESC_RINGSIZE (sizeof(rcvDesc_t) *
> adapter->MaxRxDescCount)
> +#define STATUS_DESC_RINGSIZE(sizeof(statusDesc_t)*
> adapter->MaxRxDescCount)
Don't use structure obscuring typedef's (rcvDesc_t) ...
> +#define JUMBO_DESC_RINGSIZE (sizeof(rcvDesc_t) *
> adapter->MaxJumboRxDescCount)
> +#define TX_RINGSIZE (sizeof(struct netxen_cmd_buffer) *
> adapter->MaxTxDescCount)
> +#define RCV_BUFFSIZE (sizeof(struct netxen_rx_buffer) *
> rcv_desc->MaxRxDescCount)
> +
> +#define NetXen_NIC_INT_RESET 0x2004
> +
> +/* Local functions to NetXen NIC driver */
> +static int __devinit netxen_nic_probe(struct pci_dev *pdev,
> +const struct pci_device_id *ent);
> +static void __devexit netxen_nic_remove(struct pci_dev *pdev);
> +static void netxen_nic_hw_reset (struct netxen_adapter_s *adapter);
> +static intnetxen_nic_open(struct net_device *netdev);
> +static intnetxen_nic_close(struct net_device *netdev);
> +static intnetxen_nic_xmit_frame(struct sk_buff *, struct net_device *);
> +static intnetxen_nic_set_mac(struct net_device *netdev, void *p);
> +static intnetxen_nic_change_mtu(struct net_device *netdev, int new_mtu);
> +static intnetxen_nic_hw_resources(struct netxen_adapter_s *adapter);
> +static void netxen_nic_set_multi(struct net_device *netdev);
> +static void initialize_adapter_sw(struct netxen_adapter_s *adapter);
> +static void netxen_post_rx_buffers(struct netxen_adapter_s *adapter,
> uint32_t ctx,
> +uint32_t num, uint32_t type);
> +static void netxen_process_rcv(struct netxen_adapter_s *adapter,int ctx,
> +statusDesc_t *desc);
> +static void netxen_tx_timeout(struct net_device *netdev);
> +static void netxen_tx_timeout_task(struct net_device *netdev);
> +static void netxen_process_cmd_ring(unsigned long data);
> +static void netxen_nic_down(struct netxen_port *port);
> +static intnetxen_nic_do_ioctl(struct netxen_adapter_s *adapter,
> void*u_data,
> + struct netxen_port *port);
> +static intinitialize_adapter_hw(struct netxen_adapter_s *adapter);
> +static void netxen_watchdog(unsigned long);
> +static void netxen_watchdog_task(unsigned long adapter);
> +static void netxen_nic_tune_phantom(struct pci_dev *pdev,
> +struct netxen_adapter_s*);
> +static void netxen_nic_enable_int(netxen_adapter *adapter);
> +static void netxen_nic_disable_int(netxen_adapter *adapter);
> +static uint32_t netxen_process_rcv_ring(struct netxen_adapter_s *, int, int);
> +static void netxen_nic_clear_stats(struct netxen_adapter_s *);
> +static struct net_device_stats *netxen_nic_get_stats(struct net_device
> *netdev);
> +static void netxen_nic_irq_enable(struct netxen_adapter_s *adapter);
> +static intnetxen_handle_int(netxen_adapter *, struct net_device *);
> +static intnetxen_nic_ioctl(struct net_device *netdev,
> +struct ifreq *ifr, int cmd);
> +static intnetxen_nic_read_proc(char *buf, char **start, off_t offset,
> +
gcc warnings on 2.6.17-rc1: wireless
on x86-64 and gcc 4.0.2: drivers/net/wireless/bcm43xx/bcm43xx_debugfs.c:456: warning: format ‘%u’ expects type ‘unsigned int’, but argument 3 has type ‘size_t’ drivers/net/wireless/bcm43xx/bcm43xx_debugfs.c:460: warning: format ‘%08x’ expects type ‘unsigned int’, but argument 2 has type ‘size_t’ drivers/net/wireless/bcm43xx/bcm43xx_debugfs.c:476: warning: format ‘%u’ expects type ‘unsigned int’, but argument 3 has type ‘size_t’ drivers/net/wireless/bcm43xx/bcm43xx_debugfs.c:480: warning: format ‘%08x’ expects type ‘unsigned int’, but argument 2 has type ‘size_t’ drivers/net/wireless/bcm43xx/bcm43xx_dma.c:200: warning: format ‘%08x’ expects type ‘unsigned int’, but argument 2 has type ‘dma_addr_t’ drivers/net/wireless/bcm43xx/bcm43xx_dma.c:311: warning: format ‘%08x’ expects type ‘unsigned int’, but argument 2 has type ‘dma_addr_t’ drivers/net/wireless/bcm43xx/bcm43xx_dma.c:733: warning: format ‘%08x’ expects type ‘unsigned int’, but argument 2 has type ‘dma_addr_t’ --- ~Randy - 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: RX processing order for packet sockets and bridge
On Wed, Mar 29, 2006 at 01:16:30PM -0800, [EMAIL PROTECTED] wrote: > >> With STP disabled it is still possible to use the same type of packet > >> socket to receive EAPOL frames. However, the frames will now end up > >> being received from the bridge interface (e.g., br0), not Ethernet > >> (eth0). In other words, the supplicant will need to know that it needs > >> to bind to another interface. > > That is fixed in 2.6.17, STP and other link local frames go up > through the stack, but are not forwarded. Thanks! This does indeed fix the issue I was seeing and does it nicely without requiring complex workarounds for being able to process EAPOL frames. -- Jouni MalinenPGP id EFC895FA - 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
[NETFILTER]: Fix fragmentation issues with bridge netfilter
Fix a regression from the netfilter/IPsec patches with bridging.
Bart, please review this patch, if everything is fine I think it
should also go in -stable.
[NETFILTER]: Fix fragmentation issues with bridge netfilter
The conntrack code doesn't do re-fragmentation of defragmented packets
anymore but relies on fragmentation in the IP layer. Purely bridged
packets don't pass through the IP layer, so the bridge netfilter code
needs to take care of fragmentation itself.
Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]>
---
commit 5d7b9a2f312fa867fa99adc5fd9cfb6d841f6fb6
tree 6a63c9cfe9804aa9d8050a14f8c6aed6ba1fbf84
parent 683aa4012f53b2ada0f430487e05d37b0d94e90a
author Patrick McHardy <[EMAIL PROTECTED]> Mon, 03 Apr 2006 11:58:33 +0200
committer Patrick McHardy <[EMAIL PROTECTED]> Mon, 03 Apr 2006 11:58:33 +0200
include/net/ip.h |1 +
net/bridge/br_netfilter.c | 13 +++--
net/ipv4/ip_output.c |6 +++---
3 files changed, 15 insertions(+), 5 deletions(-)
diff --git a/include/net/ip.h b/include/net/ip.h
index 8fe6156..3d2e5ca 100644
--- a/include/net/ip.h
+++ b/include/net/ip.h
@@ -95,6 +95,7 @@ extern intip_local_deliver(struct sk_b
extern int ip_mr_input(struct sk_buff *skb);
extern int ip_output(struct sk_buff *skb);
extern int ip_mc_output(struct sk_buff *skb);
+extern int ip_fragment(struct sk_buff *skb, int (*output)(struct
sk_buff *));
extern int ip_do_nat(struct sk_buff *skb);
extern voidip_send_check(struct iphdr *ip);
extern int ip_queue_xmit(struct sk_buff *skb, int ipfragok);
diff --git a/net/bridge/br_netfilter.c b/net/bridge/br_netfilter.c
index f29450b..3da9264 100644
--- a/net/bridge/br_netfilter.c
+++ b/net/bridge/br_netfilter.c
@@ -765,6 +765,15 @@ out:
return NF_STOLEN;
}
+static int br_nf_dev_queue_xmit(struct sk_buff *skb)
+{
+ if (skb->protocol == htons(ETH_P_IP) &&
+ skb->len > skb->dev->mtu &&
+ !(skb_shinfo(skb)->ufo_size || skb_shinfo(skb)->tso_size))
+ return ip_fragment(skb, br_dev_queue_push_xmit);
+ else
+ return br_dev_queue_push_xmit(skb);
+}
/* PF_BRIDGE/POST_ROUTING /
static unsigned int br_nf_post_routing(unsigned int hook, struct sk_buff
**pskb,
@@ -824,7 +833,7 @@ static unsigned int br_nf_post_routing(u
realoutdev = nf_bridge->netoutdev;
#endif
NF_HOOK(pf, NF_IP_POST_ROUTING, skb, NULL, realoutdev,
- br_dev_queue_push_xmit);
+ br_nf_dev_queue_xmit);
return NF_STOLEN;
@@ -869,7 +878,7 @@ static unsigned int ip_sabotage_out(unsi
if ((out->hard_start_xmit == br_dev_xmit &&
okfn != br_nf_forward_finish &&
-okfn != br_nf_local_out_finish && okfn != br_dev_queue_push_xmit)
+okfn != br_nf_local_out_finish && okfn != br_nf_dev_queue_xmit)
#if defined(CONFIG_VLAN_8021Q) || defined(CONFIG_VLAN_8021Q_MODULE)
|| ((out->priv_flags & IFF_802_1Q_VLAN) &&
VLAN_DEV_INFO(out)->real_dev->hard_start_xmit == br_dev_xmit)
diff --git a/net/ipv4/ip_output.c b/net/ipv4/ip_output.c
index f75ff1d..8dcba38 100644
--- a/net/ipv4/ip_output.c
+++ b/net/ipv4/ip_output.c
@@ -86,8 +86,6 @@
int sysctl_ip_default_ttl = IPDEFTTL;
-static int ip_fragment(struct sk_buff *skb, int (*output)(struct sk_buff*));
-
/* Generate a checksum for an outgoing IP datagram. */
__inline__ void ip_send_check(struct iphdr *iph)
{
@@ -421,7 +419,7 @@ static void ip_copy_metadata(struct sk_b
* single device frame, and queue such a frame for sending.
*/
-static int ip_fragment(struct sk_buff *skb, int (*output)(struct sk_buff*))
+int ip_fragment(struct sk_buff *skb, int (*output)(struct sk_buff*))
{
struct iphdr *iph;
int raw = 0;
@@ -673,6 +671,8 @@ fail:
return err;
}
+EXPORT_SYMBOL(ip_fragment);
+
int
ip_generic_getfrag(void *from, char *to, int offset, int len, int odd, struct
sk_buff *skb)
{
Re: ipsec tunnel asymmetrical mtu
Marco Berizzi wrote: Herbert Xu wrote: Marco Berizzi <[EMAIL PROTECTED]> wrote: > > Thanks a lot for the reply Herbert. > Is there a way to tell netkey to frag packets like klips > ignoring the DF bit? Thinking about this again, there is actually a bug in our various tunneling implementations when the user chooses to disable PMTU discovery. We should be turning local_df on in that case but we're not so forwarded packets with DF enabled still get bounced even if they fit in the nominal MTU. Could this bug trigger the behaviour described here http://marc.theaimsgroup.com/?l=linux-netdev&m=114373067423528&w=2 ? Herbert, I think I have found the problem. Problem description: sapgui client (172.16.0.222) cannot connect from 172.16.0.0/23 network to sap server (10.16.24.117) on customer network 10.0.0.0/8; tcp socket is established but there is no packet flow or extremely slow. However sapgui clients can connect to the customer network from 172.18.1.0/24 network. This problem has been appeared after mimosa upgrade from 2.4.29/KLIPS to 2.6.16.1/NETKEY Running 'tcpdump -p -n -v ip net 10.16.24.117' on mimosa resolves the problem: sapgui clients can connect to sap servers while tcpdump is running on mimosa. Is this a bug? customer private network 10.0.0.0/8 | | +ipsec customer gateway (nokia/checkpoint) |==MTU=1444 | | |---ipsec tunnel 10.0.0.0/8<->172.29.128.0/28 (3DES/MD5) | | |+---ipsec gateway (pleiadi)---priv net (172.16.0.0/23) | / | /---ipsec tunnel 10.0.0.0/8<->172.16.0.0/23(AES/MD5/IPCOMP) | /ipsec tunnel 172.18.1.0/24<->172.16.0.0/23(AES/MD5/IPCOMP) |/=MTU=1428 +upgraded ipsec gateway (mimosa) from klips to 2.6.16 | | | priv network (172.18.1.0/24) - 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: ipsec tunnel asymmetrical mtu
John Heffner wrote: Marco Berizzi wrote: Herbert Xu wrote: Marco Berizzi <[EMAIL PROTECTED]> wrote: > > If I run 'ping 172.16.1.52 -M do -s 1472' from a 172.25.5.0 > host I got this result: > > PING 172.16.1.52 (172.16.1.52) 1472(1500) bytes of data. > 1480 bytes from 172.16.1.52: icmp_seq=1 ttl=62 time=74.1 ms > 1480 bytes from 172.16.1.52: icmp_seq=2 ttl=62 time=69.5 ms > 1480 bytes from 172.16.1.52: icmp_seq=3 ttl=62 time=48.0 ms > > Is this a normal behaviour? KLIPS may be fragmenting your packet. A tcpdump will tell for sure. If you pass '-M want'? I get echo reply from both side with any packet size. - 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: ipsec tunnel asymmetrical mtu
Herbert Xu wrote: Marco Berizzi <[EMAIL PROTECTED]> wrote: > > Thanks a lot for the reply Herbert. > Is there a way to tell netkey to frag packets like klips > ignoring the DF bit? Thinking about this again, there is actually a bug in our various tunneling implementations when the user chooses to disable PMTU discovery. We should be turning local_df on in that case but we're not so forwarded packets with DF enabled still get bounced even if they fit in the nominal MTU. Could this bug trigger the behaviour described here http://marc.theaimsgroup.com/?l=linux-netdev&m=114373067423528&w=2 ? Please file a bug in bugzilla and give me the number so I don't forget about this. Bug 6319. Will be it be fixed before 2.6.17? Thanks again for the support. - 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
