Re: [PATCH]:[XFRM] BEET mode
The patch which introduces the BEET mode and which previously was sent to this
mailing list is valid also for
http://www.kernel.org/git/?p=linux/kernel/git/davem/net-2.6.19.git;a=summary
branch.
However there are probably some errors in attaching inline the patch to the
mail.
I retry to reattach it. In any case, if there would be some errors, the same
patch can be found at the following URL and it works just fine:
http://infrahip.hiit.fi/beet/tmp/simple-beet-ph-patch-2.6.18
For those who haven't been following this discussion, the patch introduces the
BEET mode (Bound End-to-End Tunnel) as specified by the ietf draft at the
following link:
http://www.ietf.org/internet-drafts/draft-nikander-esp-beet-mode-06.txt
Signed-off-by: Diego Beltrami [EMAIL PROTECTED]
Signed-off-by: Miika Komu [EMAIL PROTECTED]
Signed-off-by: Herbert Xu [EMAIL PROTECTED]
Signed-off-by: Abhinav Pathak [EMAIL PROTECTED]
Signed-off-by: Jeff Ahrenholz [EMAIL PROTECTED]
Thanks,
--
Diego Beltrami
diff --git a/include/linux/in.h b/include/linux/in.h
index bcaca83..f1ae3cc 100644
--- a/include/linux/in.h
+++ b/include/linux/in.h
@@ -40,6 +40,7 @@ enum {
IPPROTO_ESP = 50,/* Encapsulation Security Payload protocol */
IPPROTO_AH = 51, /* Authentication Header protocol */
+ IPPROTO_BEETPH = 94,/* IP option pseudo header for BEET */
IPPROTO_PIM= 103,/* Protocol Independent Multicast
*/
IPPROTO_COMP = 108,/* Compression Header protocol */
diff --git a/include/linux/ip.h b/include/linux/ip.h
index 2f46001..7a3aee8 100644
--- a/include/linux/ip.h
+++ b/include/linux/ip.h
@@ -80,6 +80,8 @@
#defineIPOPT_TS_TSANDADDR 1 /* timestamps and
addresses */
#defineIPOPT_TS_PRESPEC3 /* specified modules
only */
+#define IPV4_BEET_PHMAXLEN 8
+
struct iphdr {
#if defined(__LITTLE_ENDIAN_BITFIELD)
__u8ihl:4,
@@ -123,4 +125,11 @@ struct ip_comp_hdr {
__u16 cpi;
};
+struct ip_beet_phdr {
+ __u8 nexthdr;
+ __u8 hdrlen;
+ __u8 padlen;
+ __u8 reserved;
+};
+
#endif /* _LINUX_IP_H */
diff --git a/include/linux/ipsec.h b/include/linux/ipsec.h
index d3c5276..d17a630 100644
--- a/include/linux/ipsec.h
+++ b/include/linux/ipsec.h
@@ -12,7 +12,8 @@
enum {
IPSEC_MODE_ANY = 0,/* We do not support this for SA */
IPSEC_MODE_TRANSPORT= 1,
- IPSEC_MODE_TUNNEL = 2
+ IPSEC_MODE_TUNNEL = 2,
+ IPSEC_MODE_BEET = 3
};
enum {
diff --git a/include/linux/xfrm.h b/include/linux/xfrm.h
index 14ecd19..a745cb3 100644
--- a/include/linux/xfrm.h
+++ b/include/linux/xfrm.h
@@ -129,7 +129,8 @@ enum
#define XFRM_MODE_TUNNEL 1
#define XFRM_MODE_ROUTEOPTIMIZATION 2
#define XFRM_MODE_IN_TRIGGER 3
-#define XFRM_MODE_MAX 4
+#define XFRM_MODE_BEET 4
+#define XFRM_MODE_MAX 5
/* Netlink configuration messages. */
enum {
diff --git a/net/ipv4/Kconfig b/net/ipv4/Kconfig
index 90f9136..c5e3b17 100644
--- a/net/ipv4/Kconfig
+++ b/net/ipv4/Kconfig
@@ -433,6 +433,15 @@ config INET_XFRM_MODE_TUNNEL
If unsure, say Y.
+config INET_XFRM_MODE_BEET
+ tristate IP: IPsec BEET mode
+ default y
+ select XFRM
+ ---help---
+ Support for IPsec BEET mode.
+
+ If unsure, say Y.
+
config INET_DIAG
tristate INET: socket monitoring interface
default y
diff --git a/net/ipv4/Makefile b/net/ipv4/Makefile
index f66049e..15645c5 100644
--- a/net/ipv4/Makefile
+++ b/net/ipv4/Makefile
@@ -23,6 +23,7 @@ obj-$(CONFIG_INET_AH) += ah4.o
obj-$(CONFIG_INET_ESP) += esp4.o
obj-$(CONFIG_INET_IPCOMP) += ipcomp.o
obj-$(CONFIG_INET_XFRM_TUNNEL) += xfrm4_tunnel.o
+obj-$(CONFIG_INET_XFRM_MODE_BEET) += xfrm4_mode_beet.o
obj-$(CONFIG_INET_TUNNEL) += tunnel4.o
obj-$(CONFIG_INET_XFRM_MODE_TRANSPORT) += xfrm4_mode_transport.o
obj-$(CONFIG_INET_XFRM_MODE_TUNNEL) += xfrm4_mode_tunnel.o
diff --git a/net/ipv4/esp4.c b/net/ipv4/esp4.c
index 9628de9..c846f13 100644
--- a/net/ipv4/esp4.c
+++ b/net/ipv4/esp4.c
@@ -241,7 +241,8 @@ static int esp_input(struct xfrm_state *
*as per draft-ietf-ipsec-udp-encaps-06,
*section 3.1.2
*/
- if (x-props.mode == XFRM_MODE_TRANSPORT)
+ if (x-props.mode == XFRM_MODE_TRANSPORT ||
+ x-props.mode == XFRM_MODE_BEET)
skb-ip_summed = CHECKSUM_UNNECESSARY;
}
@@ -259,17 +260,28 @@ static u32 esp4_get_max_size(struct xfrm
{
struct esp_data *esp = x-data;
u32 blksize = ALIGN(crypto_tfm_alg_blocksize(esp-conf.tfm), 4);
+ int enclen = 0;
- if (x-props.mode == XFRM_MODE_TUNNEL) {
- mtu = ALIGN(mtu + 2, blksize);
- } else {
- /* The worst case. */
+ switch (x-props.mode) {
+ case XFRM_MODE_TUNNEL:
+ mtu = ALIGN(mtu +2, blksize);
+
Re: [d80211] connecting to B-mode AP
On Saturday 16 September 2006 01:50, mabbas wrote: I see your point here, although some one will file some bugs against the driver about showing G while associating with B-mode AP. By the way how can you figure if the AP is B/G other than the rates? I don't think this will happen. This never happened with bcm43xx, for example. The PHY description of the card is something _completely_ different than the AP's PHY. People know that G is backwards compatible to B. And people who don't even know that, don't care anyway. ;) -- Greetings Michael. - 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.18-rc[67] crashes in TCP ack handling
The bad news is that I haven't yet been able to capture traces. Once every three days or so I get a crash of 2.6.18-rc[67] which *probably* end in tcp_ack(), but I don't have the exact dump. My .config is indeed heavy on TCP congestion stuff: $ zcat /proc/config.gz | grep -i tcp CONFIG_INET_TCP_DIAG=y CONFIG_TCP_CONG_ADVANCED=y # TCP congestion control CONFIG_TCP_CONG_BIC=y CONFIG_TCP_CONG_CUBIC=y CONFIG_TCP_CONG_WESTWOOD=y CONFIG_TCP_CONG_HTCP=y CONFIG_TCP_CONG_HSTCP=y CONFIG_TCP_CONG_HYBLA=y CONFIG_TCP_CONG_VEGAS=y CONFIG_TCP_CONG_SCALABLE=y CONFIG_TCP_CONG_LP=y CONFIG_TCP_CONG_VENO=y CONFIG_IP_VS_PROTO_TCP=y CONFIG_NETFILTER_XT_MATCH_TCPMSS=m CONFIG_IP_NF_TARGET_TCPMSS=y # CONFIG_NET_TCPPROBE is not set # CONFIG_ISCSI_TCP is not set # CONFIG_NFSD_TCP is not set However, I haven't specifically configured anything. $ dmesg | grep -i tcp [ 33.106317] TCP established hash table entries: 131072 (order: 8, 1048576 bytes) [ 33.107086] TCP bind hash table entries: 65536 (order: 7, 524288 bytes) [ 33.107476] TCP: Hash tables configured (established 131072 bind 65536) [ 33.107605] TCP reno registered [ 40.985770] IPVS: Registered protocols (TCP, UDP, AH, ESP) [ 41.105710] TCP bic registered [ 41.105833] TCP cubic registered [ 41.105957] TCP westwood registered [ 41.106080] TCP highspeed registered [ 41.106203] TCP hybla registered [ 41.106328] TCP htcp registered [ 41.106452] TCP vegas registered [ 41.106574] TCP veno registered [ 41.106698] TCP scalable registered [ 41.106822] TCP lp registered $ cat ipv4/tcp_congestion_control lp I hope to follow up this message with the actual backtrace, but this is already an heads up. Sorry for not yet being able to be more specific. bert -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source services - 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 1/3][ATM]: [he] he_init_one() is declared __devinit, but calls __init functions
please consider for 2.6.18 -- thanks!
[ATM]: [he] he_init_one() is declared __devinit, but calls __init functions
he_init_one() is declared __devinit, but calls lots of init functions
that are marked __init. However, if CONFIG_HOTPLUG is enabled,
__devinit functions go into normal .text, which leads to
WARNING: drivers/atm/he.o - Section mismatch: reference to .init.text:
from .text between 'he_start' (at offset 0x2130) and 'he_service_tbrq'
Fix this by changing the __init functions to __devinit.
Signed-off-by: Roland Dreier [EMAIL PROTECTED]
Signed-off-by: Chas Williams [EMAIL PROTECTED]
---
commit c0361a8558796e5af9c5d4e8d4900e4dc44c2e4e
tree 9ad8e4378eb731b220f1e91f1d92b3122f4d6565
parent 96086141b3a9dcde8f0946ae01f9faa55ac0bf4d
author chas williams - CONTRACTOR [EMAIL PROTECTED] Sat, 16 Sep 2006 15:44:55
-0400
committer chas williams - CONTRACTOR [EMAIL PROTECTED] Sat, 16 Sep 2006
15:44:55 -0400
drivers/atm/he.c | 16
1 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/atm/he.c b/drivers/atm/he.c
index dd96123..4598b1f 100644
--- a/drivers/atm/he.c
+++ b/drivers/atm/he.c
@@ -454,7 +454,7 @@ #define NONZERO (1 14)
return (NONZERO | (exp 9) | (rate 0x1ff));
}
-static void __init
+static void __devinit
he_init_rx_lbfp0(struct he_dev *he_dev)
{
unsigned i, lbm_offset, lbufd_index, lbuf_addr, lbuf_count;
@@ -485,7 +485,7 @@ he_init_rx_lbfp0(struct he_dev *he_dev)
he_writel(he_dev, he_dev-r0_numbuffs, RLBF0_C);
}
-static void __init
+static void __devinit
he_init_rx_lbfp1(struct he_dev *he_dev)
{
unsigned i, lbm_offset, lbufd_index, lbuf_addr, lbuf_count;
@@ -516,7 +516,7 @@ he_init_rx_lbfp1(struct he_dev *he_dev)
he_writel(he_dev, he_dev-r1_numbuffs, RLBF1_C);
}
-static void __init
+static void __devinit
he_init_tx_lbfp(struct he_dev *he_dev)
{
unsigned i, lbm_offset, lbufd_index, lbuf_addr, lbuf_count;
@@ -546,7 +546,7 @@ he_init_tx_lbfp(struct he_dev *he_dev)
he_writel(he_dev, lbufd_index - 1, TLBF_T);
}
-static int __init
+static int __devinit
he_init_tpdrq(struct he_dev *he_dev)
{
he_dev-tpdrq_base = pci_alloc_consistent(he_dev-pci_dev,
@@ -568,7 +568,7 @@ he_init_tpdrq(struct he_dev *he_dev)
return 0;
}
-static void __init
+static void __devinit
he_init_cs_block(struct he_dev *he_dev)
{
unsigned clock, rate, delta;
@@ -664,7 +664,7 @@ he_init_cs_block(struct he_dev *he_dev)
}
-static int __init
+static int __devinit
he_init_cs_block_rcm(struct he_dev *he_dev)
{
unsigned (*rategrid)[16][16];
@@ -785,7 +785,7 @@ #define RTGTBL_OFFSET 0x400
return 0;
}
-static int __init
+static int __devinit
he_init_group(struct he_dev *he_dev, int group)
{
int i;
@@ -955,7 +955,7 @@ #endif
return 0;
}
-static int __init
+static int __devinit
he_init_irq(struct he_dev *he_dev)
{
int i;
-
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][ATM]: [he] don't hold the device lock when upcalling
please consider for 2.6.18 -- thanks! [ATM]: [he] don't hold the device lock when upcalling This can create a deadlock/lock ordering problem with other layers that want to use the transmit (or other) path of the card at that time. Signed-off-by: Chas Williams [EMAIL PROTECTED] --- commit fc6b6284e9383bd8d9fd95210fbc5e3c54ccc65d tree cfb6beef3334433e331d27f453d0c3901bd7c5c2 parent c0361a8558796e5af9c5d4e8d4900e4dc44c2e4e author chas williams - CONTRACTOR [EMAIL PROTECTED] Sat, 16 Sep 2006 15:49:53 -0400 committer chas williams - CONTRACTOR [EMAIL PROTECTED] Sat, 16 Sep 2006 15:49:53 -0400 drivers/atm/he.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/atm/he.c b/drivers/atm/he.c index 4598b1f..55ca7d8 100644 --- a/drivers/atm/he.c +++ b/drivers/atm/he.c @@ -1928,7 +1928,9 @@ #endif #ifdef notdef ATM_SKB(skb)-vcc = vcc; #endif + spin_unlock(he_dev-global_lock); vcc-push(vcc, skb); + spin_lock(he_dev-global_lock); atomic_inc(vcc-stats-rx); - 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 3/3][ATM]: potential NULL pointer dereference in clip_mkip()
please consider for 2.6.18 -- thanks!
[ATM]: potential NULL pointer dereference in clip_mkip()
http://article.gmane.org/gmane.linux.kernel/445717
When re-processing received data, a struct sk_buff pointer skb may be
dereferenced after a free operation.
From: Frederik Deweerdt [EMAIL PROTECTED]
Signed-off-by: Chas Williams [EMAIL PROTECTED]
---
commit 87409562aeed5fb2b85dc2f9bddca0a1bbde8c37
tree 0885b8bd2b8881201de422877abd8979861c44de
parent fc6b6284e9383bd8d9fd95210fbc5e3c54ccc65d
author chas williams - CONTRACTOR [EMAIL PROTECTED] Sat, 16 Sep 2006 15:55:01
-0400
committer chas williams - CONTRACTOR [EMAIL PROTECTED] Sat, 16 Sep 2006
15:55:01 -0400
net/atm/clip.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/atm/clip.c b/net/atm/clip.c
index 7ce7bfe..0dfa3a4 100644
--- a/net/atm/clip.c
+++ b/net/atm/clip.c
@@ -500,9 +500,9 @@ static int clip_mkip(struct atm_vcc *vcc
} else {
unsigned int len = skb-len;
- clip_push(vcc, skb);
PRIV(skb-dev)-stats.rx_packets--;
PRIV(skb-dev)-stats.rx_bytes -= len;
+ clip_push(vcc, skb);
}
return 0;
}
-
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 Detected Tx Unit Hang
Jesse, today the server froze and was not able to see anything in the logs. Nothing at all about any error, just plain froze. Just in case, this is a different unit altogether, still the same model as the units having the Tx Unit Hang, but different memory, motherboard and CPU. The only 1 thing that is the same is the hard drive a regular IDE... The only one thing I noticed that is very weird to me at least is that in powering off the unit from the crash and rebooting it I saw some lines like this in the logs.. Sep 16 11:08:03 www kernel: checking if image is initramfs... it is Sep 16 07:05:19 www sysctl: kernel.msgmnb = 65536 The odd part is the diff in the time stamps between one entry and the very next one in the log. Any ideas what can cause this? Also, any way to get a dump or some way to prevent the system from locking without any log entries? Regards, Paul - Original Message - From: Jesse Brandeburg [EMAIL PROTECTED] To: Paul Aviles [EMAIL PROTECTED] Cc: netdev@vger.kernel.org Sent: Tuesday, September 05, 2006 12:09 PM Subject: Re: e1000 Detected Tx Unit Hang On 9/3/06, Paul Aviles [EMAIL PROTECTED] wrote: Hey Jesse, thanks for your reply. Here is the stuff on /procs. The weird no problem, part is that I have several other identical systems and only one is affected. Today I moved the hard drive to another similar system and I am not seeing the problem so I am wondering if is something maybe wrong with the card eeprom? Is there a way to check that? I doubt it is an eeprom problem. you can dump the eeproms with ethtool -e eth0 from both machines and compare them . Odd that only one system is having the problem. Could it be that the hardware on that box is having issues? Are you sure the machines are running the same bios version with the same settings? Any overclocking? cat /proc/interrupts CPU0 CPU1 16: 70540 0 IO-APIC-level uhci_hcd:usb4, eth0 this could contribute to your problem, were you able to test without NAPI? 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 - 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: [RFT] sky2 vs iptables
Stephen Hemminger wrote: On Tue, 05 Sep 2006 21:36:24 -0400 Daniel Drake [EMAIL PROTECTED] wrote: There's a strange sky2 bug on the Gentoo bugzilla: http://bugs.gentoo.org/show_bug.cgi?id=136508 sky2 seems to work OK, but breaks as soon as the iptables ruleset is loaded. Nothing can be pinged, etc. Can someone try and reproduce this? The iptables rule script has been uploaded here: http://bugs.gentoo.org/attachment.cgi?id=95694action=view The very last command in that file is the one which produces an error and stops everything working: iptables: Unknown error 18446744073709551615 Apparently a sky2 null deref has also been seen at this point, although I don't have further details on that. It might be an artifact of the way sky2 was allocating receive buffers. Bridge-netfilter was assuming header space in the buffer, and would corrupt other memory, maybe iptables is assuming as well. This makes sky2 use dev_alloc_skb that reserves space. --- Subject: sky2: use dev_alloc_skb for receive buffers Unfortunately the problem still exists with this patch. Any other ideas? Daniel - 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: [d80211] connecting to B-mode AP
The extended rates element is only needed if there are more than 8 rates to report - which is normal for G operation, but not necessary. It only exists because a particularly popular old 11b MAC codebase crashed when the normal rate element had more than 8 elements, and this hurt interoperability with early G AP implementations - so the spec was changed. Simon -Original Message- From: Michael Wu [mailto:[EMAIL PROTECTED] Sent: Saturday, September 16, 2006 10:05 AM To: mabbas Cc: Simon Barber; netdev@vger.kernel.org Subject: Re: [d80211] connecting to B-mode AP On Friday 15 September 2006 19:50, mabbas wrote: I see your point here, although some one will file some bugs against the driver about showing G while associating with B-mode AP. By the way how can you figure if the AP is B/G other than the rates? IIRC, only 802.11g APs will send the extended rate information element, though I don't know if forcing 802.11b on the AP will cause it to stop sending that. (but it might still be okay if it doesn't - it's still a 802.11g AP, with the faster speeds turned off..) -Michael Wu - 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
