Linux 2.6.14.5

Linux 2.6.14.5

[Greg KH]

We (the -stable team) are announcing the release of the 2.6.14.5 kernel.

The diffstat and short summary of the fixes are below.

I'll also be replying to this message with a copy of the patch between
2.6.14.4 and 2.6.14.5, as it is small enough to do so.

The updated 2.6.14.y git tree can be found at:
 	rsync://rsync.kernel.org/pub/scm/linux/kernel/git/gregkh/linux-2.6.14.y.git
and can be browsed at the normal kernel.org git web browser:
	www.kernel.org/git/

thanks,

greg k-h

--------

 Makefile                                    |    2 -
 drivers/acpi/video.c                        |    2 -
 drivers/scsi/dpt_i2o.c                      |   25 ++++++++++++++++-----
 drivers/scsi/scsi_lib.c                     |   33 +++++++++++++++++-----------
 drivers/scsi/sd.c                           |   16 -------------
 drivers/scsi/sr.c                           |   20 ++--------------
 drivers/scsi/st.c                           |   19 ----------------
 drivers/usb/input/hid-input.c               |    1 
 fs/nfsd/nfs2acl.c                           |    2 -
 fs/nfsd/nfs3acl.c                           |    2 -
 include/linux/rtnetlink.h                   |    4 +++
 include/net/xfrm.h                          |    1 
 include/scsi/scsi_cmnd.h                    |    1 
 kernel/params.c                             |    2 -
 net/8021q/vlan_dev.c                        |    3 ++
 net/bridge/br_netfilter.c                   |   17 +++++---------
 net/ipv4/ip_gre.c                           |    2 -
 net/ipv4/netfilter/Makefile                 |    3 +-
 net/ipv4/netfilter/ip_conntrack_netlink.c   |    4 +--
 net/ipv4/netfilter/ip_conntrack_proto_tcp.c |    3 +-
 net/ipv6/addrconf.c                         |   16 ++++++++++---
 net/ipv6/netfilter/Kconfig                  |    2 -
 net/ipv6/route.c                            |    2 -
 net/xfrm/xfrm_policy.c                      |   19 +++++++++++-----
 net/xfrm/xfrm_state.c                       |    5 ++++
 25 files changed, 108 insertions(+), 98 deletions(-)

Summary of changes from v2.6.14.4 to v2.6.14.5
==============================================

Andreas Gruenbacher:
      setting ACLs on readonly mounted NFS filesystems (CVE-2005-3623)

Bart De Schuymer:
      Fix bridge-nf ipv6 length check

David S. Miller:
      Perform SA switchover immediately.

Dmitry Torokhov:
      Input: fix an OOPS in HID driver

Greg Kroah-Hartman:
      Linux 2.6.14.5

Herbert Xu:
      Fix hardware checksum modification

Jason Wessel:
      kernel/params.c: fix sysfs access with CONFIG_MODULES=n

Kristian Slavov:
      Fix RTNLGRP definitions in rtnetlink.h

Krzysztof Oledzki:
      Fix CTA_PROTO_NUM attribute size in ctnetlink

Patrick McHardy:
      Fix unbalanced read_unlock_bh in ctnetlink
      Fix NAT init order
      Fix incorrect dependency for IP6_NF_TARGET_NFQUEUE

Salyzyn, Mark:
      dpt_i2o fix for deadlock condition

Stefan Richter:
      SCSI: fix transfer direction in sd (kernel panic when ejecting iPod)
      SCSI: fix transfer direction in scsi_lib and st

Stephen Hemminger:
      Fix hardware rx csum errors

YOSHIFUJI Hideaki:
      Fix route lifetime.

Yu Luming:
      apci: fix NULL deref in video/lcd/brightness

Re: Linux 2.6.14.5

[Greg KH]

diff --git a/Makefile b/Makefile
index f00339c..ea6f2f9 100644
--- a/Makefile
+++ b/Makefile
@@ -1,7 +1,7 @@
 VERSION = 2
 PATCHLEVEL = 6
 SUBLEVEL = 14
-EXTRAVERSION = .4
+EXTRAVERSION = .5
 NAME=Affluent Albatross
 
 # *DOCUMENTATION*
diff --git a/drivers/acpi/video.c b/drivers/acpi/video.c
index e383d61..00fe1cd 100644
--- a/drivers/acpi/video.c
+++ b/drivers/acpi/video.c
@@ -813,7 +813,7 @@ acpi_video_device_write_brightness(struc
 
 	ACPI_FUNCTION_TRACE("acpi_video_device_write_brightness");
 
-	if (!dev || count + 1 > sizeof str)
+	if (!dev || !dev->brightness || count + 1 > sizeof str)
 		return_VALUE(-EINVAL);
 
 	if (copy_from_user(str, buffer, count))
diff --git a/drivers/scsi/dpt_i2o.c b/drivers/scsi/dpt_i2o.c
index 8a603ea..9aa2d02 100644
--- a/drivers/scsi/dpt_i2o.c
+++ b/drivers/scsi/dpt_i2o.c
@@ -660,7 +660,12 @@ static int adpt_abort(struct scsi_cmnd *
 	msg[2] = 0;
 	msg[3]= 0; 
 	msg[4] = (u32)cmd;
-	if( (rcode = adpt_i2o_post_wait(pHba, msg, sizeof(msg), FOREVER)) != 0){
+	if (pHba->host)
+		spin_lock_irq(pHba->host->host_lock);
+	rcode = adpt_i2o_post_wait(pHba, msg, sizeof(msg), FOREVER);
+	if (pHba->host)
+		spin_unlock_irq(pHba->host->host_lock);
+	if (rcode != 0) {
 		if(rcode == -EOPNOTSUPP ){
 			printk(KERN_INFO"%s: Abort cmd not supported\n",pHba->name);
 			return FAILED;
@@ -697,10 +702,15 @@ static int adpt_device_reset(struct scsi
 	msg[2] = 0;
 	msg[3] = 0;
 
+	if (pHba->host)
+		spin_lock_irq(pHba->host->host_lock);
 	old_state = d->state;
 	d->state |= DPTI_DEV_RESET;
-	if( (rcode = adpt_i2o_post_wait(pHba, msg,sizeof(msg), FOREVER)) ){
-		d->state = old_state;
+	rcode = adpt_i2o_post_wait(pHba, msg,sizeof(msg), FOREVER);
+	d->state = old_state;
+	if (pHba->host)
+		spin_unlock_irq(pHba->host->host_lock);
+	if (rcode != 0) {
 		if(rcode == -EOPNOTSUPP ){
 			printk(KERN_INFO"%s: Device reset not supported\n",pHba->name);
 			return FAILED;
@@ -708,7 +718,6 @@ static int adpt_device_reset(struct scsi
 		printk(KERN_INFO"%s: Device reset failed\n",pHba->name);
 		return FAILED;
 	} else {
-		d->state = old_state;
 		printk(KERN_INFO"%s: Device reset successful\n",pHba->name);
 		return SUCCESS;
 	}
@@ -721,6 +730,7 @@ static int adpt_bus_reset(struct scsi_cm
 {
 	adpt_hba* pHba;
 	u32 msg[4];
+	u32 rcode;
 
 	pHba = (adpt_hba*)cmd->device->host->hostdata[0];
 	memset(msg, 0, sizeof(msg));
@@ -729,7 +739,12 @@ static int adpt_bus_reset(struct scsi_cm
 	msg[1] = (I2O_HBA_BUS_RESET<<24|HOST_TID<<12|pHba->channel[cmd->device->channel].tid);
 	msg[2] = 0;
 	msg[3] = 0;
-	if(adpt_i2o_post_wait(pHba, msg,sizeof(msg), FOREVER) ){
+	if (pHba->host)
+		spin_lock_irq(pHba->host->host_lock);
+	rcode = adpt_i2o_post_wait(pHba, msg,sizeof(msg), FOREVER);
+	if (pHba->host)
+		spin_unlock_irq(pHba->host->host_lock);
+	if (rcode != 0) {
 		printk(KERN_WARNING"%s: Bus reset failed.\n",pHba->name);
 		return FAILED;
 	} else {
diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index 0074f28..a71ad5a 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -1129,6 +1129,26 @@ static void scsi_generic_done(struct scs
 	scsi_io_completion(cmd, cmd->result == 0 ? cmd->bufflen : 0, 0);
 }
 
+void scsi_setup_blk_pc_cmnd(struct scsi_cmnd *cmd, int retries)
+{
+	struct request *req = cmd->request;
+
+	BUG_ON(sizeof(req->cmd) > sizeof(cmd->cmnd));
+	memcpy(cmd->cmnd, req->cmd, sizeof(cmd->cmnd));
+	cmd->cmd_len = req->cmd_len;
+	if (!req->data_len)
+		cmd->sc_data_direction = DMA_NONE;
+	else if (rq_data_dir(req) == WRITE)
+		cmd->sc_data_direction = DMA_TO_DEVICE;
+	else
+		cmd->sc_data_direction = DMA_FROM_DEVICE;
+
+	cmd->transfersize = req->data_len;
+	cmd->allowed = retries;
+	cmd->timeout_per_command = req->timeout;
+}
+EXPORT_SYMBOL_GPL(scsi_setup_blk_pc_cmnd);
+
 static int scsi_prep_fn(struct request_queue *q, struct request *req)
 {
 	struct scsi_device *sdev = q->queuedata;
@@ -1264,18 +1284,7 @@ static int scsi_prep_fn(struct request_q
 				goto kill;
 			}
 		} else {
-			memcpy(cmd->cmnd, req->cmd, sizeof(cmd->cmnd));
-			cmd->cmd_len = req->cmd_len;
-			if (rq_data_dir(req) == WRITE)
-				cmd->sc_data_direction = DMA_TO_DEVICE;
-			else if (req->data_len)
-				cmd->sc_data_direction = DMA_FROM_DEVICE;
-			else
-				cmd->sc_data_direction = DMA_NONE;
-			
-			cmd->transfersize = req->data_len;
-			cmd->allowed = 3;
-			cmd->timeout_per_command = req->timeout;
+			scsi_setup_blk_pc_cmnd(cmd, 3);
 			cmd->done = scsi_generic_done;
 		}
 	}
diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c
index 9a1dc0c..3229961 100644
--- a/drivers/scsi/sd.c
+++ b/drivers/scsi/sd.c
@@ -231,24 +231,10 @@ static int sd_init_command(struct scsi_c
 	 * SG_IO from block layer already setup, just copy cdb basically
 	 */
 	if (blk_pc_request(rq)) {
-		if (sizeof(rq->cmd) > sizeof(SCpnt->cmnd))
-			return 0;
-
-		memcpy(SCpnt->cmnd, rq->cmd, sizeof(SCpnt->cmnd));
-		SCpnt->cmd_len = rq->cmd_len;
-		if (rq_data_dir(rq) == WRITE)
-			SCpnt->sc_data_direction = DMA_TO_DEVICE;
-		else if (rq->data_len)
-			SCpnt->sc_data_direction = DMA_FROM_DEVICE;
-		else
-			SCpnt->sc_data_direction = DMA_NONE;
-
-		this_count = rq->data_len;
+		scsi_setup_blk_pc_cmnd(SCpnt, SD_PASSTHROUGH_RETRIES);
 		if (rq->timeout)
 			timeout = rq->timeout;
 
-		SCpnt->transfersize = rq->data_len;
-		SCpnt->allowed = SD_PASSTHROUGH_RETRIES;
 		goto queue;
 	}
 
diff --git a/drivers/scsi/sr.c b/drivers/scsi/sr.c
index 561901b..ffdcd60 100644
--- a/drivers/scsi/sr.c
+++ b/drivers/scsi/sr.c
@@ -320,25 +320,11 @@ static int sr_init_command(struct scsi_c
 	 * these are already setup, just copy cdb basically
 	 */
 	if (SCpnt->request->flags & REQ_BLOCK_PC) {
-		struct request *rq = SCpnt->request;
+		scsi_setup_blk_pc_cmnd(SCpnt, MAX_RETRIES);
 
-		if (sizeof(rq->cmd) > sizeof(SCpnt->cmnd))
-			return 0;
-
-		memcpy(SCpnt->cmnd, rq->cmd, sizeof(SCpnt->cmnd));
-		SCpnt->cmd_len = rq->cmd_len;
-		if (!rq->data_len)
-			SCpnt->sc_data_direction = DMA_NONE;
-		else if (rq_data_dir(rq) == WRITE)
-			SCpnt->sc_data_direction = DMA_TO_DEVICE;
-		else
-			SCpnt->sc_data_direction = DMA_FROM_DEVICE;
-
-		this_count = rq->data_len;
-		if (rq->timeout)
-			timeout = rq->timeout;
+		if (SCpnt->timeout_per_command)
+			timeout = SCpnt->timeout_per_command;
 
-		SCpnt->transfersize = rq->data_len;
 		goto queue;
 	}
 
diff --git a/drivers/scsi/st.c b/drivers/scsi/st.c
index d001c04..6ded0f5 100644
--- a/drivers/scsi/st.c
+++ b/drivers/scsi/st.c
@@ -4196,27 +4196,10 @@ static void st_intr(struct scsi_cmnd *SC
  */
 static int st_init_command(struct scsi_cmnd *SCpnt)
 {
-	struct request *rq;
-
 	if (!(SCpnt->request->flags & REQ_BLOCK_PC))
 		return 0;
 
-	rq = SCpnt->request;
-	if (sizeof(rq->cmd) > sizeof(SCpnt->cmnd))
-		return 0;
-
-	memcpy(SCpnt->cmnd, rq->cmd, sizeof(SCpnt->cmnd));
-	SCpnt->cmd_len = rq->cmd_len;
-
-	if (rq_data_dir(rq) == WRITE)
-		SCpnt->sc_data_direction = DMA_TO_DEVICE;
-	else if (rq->data_len)
-		SCpnt->sc_data_direction = DMA_FROM_DEVICE;
-	else
-		SCpnt->sc_data_direction = DMA_NONE;
-
-	SCpnt->timeout_per_command = rq->timeout;
-	SCpnt->transfersize = rq->data_len;
+	scsi_setup_blk_pc_cmnd(SCpnt, 0);
 	SCpnt->done = st_intr;
 	return 1;
 }
diff --git a/drivers/usb/input/hid-input.c b/drivers/usb/input/hid-input.c
index 0b64522..f72d705 100644
--- a/drivers/usb/input/hid-input.c
+++ b/drivers/usb/input/hid-input.c
@@ -137,6 +137,7 @@ static void hidinput_configure_usage(str
 			switch (usage->hid & 0xffff) {
 				case 0xba: map_abs(ABS_RUDDER); break;
 				case 0xbb: map_abs(ABS_THROTTLE); break;
+				default:   goto ignore;
 			}
 			break;
 
diff --git a/fs/nfsd/nfs2acl.c b/fs/nfsd/nfs2acl.c
index 7cbf068..fc95c4d 100644
--- a/fs/nfsd/nfs2acl.c
+++ b/fs/nfsd/nfs2acl.c
@@ -107,7 +107,7 @@ static int nfsacld_proc_setacl(struct sv
 	dprintk("nfsd: SETACL(2acl)   %s\n", SVCFH_fmt(&argp->fh));
 
 	fh = fh_copy(&resp->fh, &argp->fh);
-	nfserr = fh_verify(rqstp, &resp->fh, 0, MAY_NOP);
+	nfserr = fh_verify(rqstp, &resp->fh, 0, MAY_SATTR);
 
 	if (!nfserr) {
 		nfserr = nfserrno( nfsd_set_posix_acl(
diff --git a/fs/nfsd/nfs3acl.c b/fs/nfsd/nfs3acl.c
index 64ba405..16e10c1 100644
--- a/fs/nfsd/nfs3acl.c
+++ b/fs/nfsd/nfs3acl.c
@@ -101,7 +101,7 @@ static int nfsd3_proc_setacl(struct svc_
 	int nfserr = 0;
 
 	fh = fh_copy(&resp->fh, &argp->fh);
-	nfserr = fh_verify(rqstp, &resp->fh, 0, MAY_NOP);
+	nfserr = fh_verify(rqstp, &resp->fh, 0, MAY_SATTR);
 
 	if (!nfserr) {
 		nfserr = nfserrno( nfsd_set_posix_acl(
diff --git a/include/linux/rtnetlink.h b/include/linux/rtnetlink.h
index c231e9a..d50482b 100644
--- a/include/linux/rtnetlink.h
+++ b/include/linux/rtnetlink.h
@@ -866,6 +866,7 @@ enum rtnetlink_groups {
 #define	RTNLGRP_IPV4_MROUTE	RTNLGRP_IPV4_MROUTE
 	RTNLGRP_IPV4_ROUTE,
 #define RTNLGRP_IPV4_ROUTE	RTNLGRP_IPV4_ROUTE
+	RTNLGRP_NOP1,
 	RTNLGRP_IPV6_IFADDR,
 #define RTNLGRP_IPV6_IFADDR	RTNLGRP_IPV6_IFADDR
 	RTNLGRP_IPV6_MROUTE,
@@ -876,8 +877,11 @@ enum rtnetlink_groups {
 #define RTNLGRP_IPV6_IFINFO	RTNLGRP_IPV6_IFINFO
 	RTNLGRP_DECnet_IFADDR,
 #define RTNLGRP_DECnet_IFADDR	RTNLGRP_DECnet_IFADDR
+	RTNLGRP_NOP2,
 	RTNLGRP_DECnet_ROUTE,
 #define RTNLGRP_DECnet_ROUTE	RTNLGRP_DECnet_ROUTE
+	RTNLGRP_NOP3,
+	RTNLGRP_NOP4,
 	RTNLGRP_IPV6_PREFIX,
 #define RTNLGRP_IPV6_PREFIX	RTNLGRP_IPV6_PREFIX
 	__RTNLGRP_MAX
diff --git a/include/net/xfrm.h b/include/net/xfrm.h
index 5beae1c..1cdb879 100644
--- a/include/net/xfrm.h
+++ b/include/net/xfrm.h
@@ -890,6 +890,7 @@ struct xfrm_state * xfrm_find_acq(u8 mod
 extern void xfrm_policy_flush(void);
 extern int xfrm_sk_policy_insert(struct sock *sk, int dir, struct xfrm_policy *pol);
 extern int xfrm_flush_bundles(void);
+extern void xfrm_flush_all_bundles(void);
 extern int xfrm_bundle_ok(struct xfrm_dst *xdst, struct flowi *fl, int family);
 extern void xfrm_init_pmtu(struct dst_entry *dst);
 
diff --git a/include/scsi/scsi_cmnd.h b/include/scsi/scsi_cmnd.h
index bed4b7c..ebb6a16 100644
--- a/include/scsi/scsi_cmnd.h
+++ b/include/scsi/scsi_cmnd.h
@@ -150,5 +150,6 @@ extern struct scsi_cmnd *scsi_get_comman
 extern void scsi_put_command(struct scsi_cmnd *);
 extern void scsi_io_completion(struct scsi_cmnd *, unsigned int, unsigned int);
 extern void scsi_finish_command(struct scsi_cmnd *cmd);
+extern void scsi_setup_blk_pc_cmnd(struct scsi_cmnd *cmd, int retries);
 
 #endif /* _SCSI_SCSI_CMND_H */
diff --git a/kernel/params.c b/kernel/params.c
index 1a8614b..fe8f1e9 100644
--- a/kernel/params.c
+++ b/kernel/params.c
@@ -618,7 +618,7 @@ static void __init param_sysfs_builtin(v
 
 
 /* module-related sysfs stuff */
-#ifdef CONFIG_MODULES
+#ifdef CONFIG_SYSFS
 
 #define to_module_attr(n) container_of(n, struct module_attribute, attr);
 #define to_module_kobject(n) container_of(n, struct module_kobject, kobj);
diff --git a/net/8021q/vlan_dev.c b/net/8021q/vlan_dev.c
index b748648..f2a8750 100644
--- a/net/8021q/vlan_dev.c
+++ b/net/8021q/vlan_dev.c
@@ -165,6 +165,9 @@ int vlan_skb_recv(struct sk_buff *skb, s
 
 	skb_pull(skb, VLAN_HLEN); /* take off the VLAN header (4 bytes currently) */
 
+	/* Need to correct hardware checksum */
+	skb_postpull_rcsum(skb, vhdr, VLAN_HLEN);
+
 	/* Ok, lets check to make sure the device (dev) we
 	 * came in on is what this VLAN is attached to.
 	 */
diff --git a/net/bridge/br_netfilter.c b/net/bridge/br_netfilter.c
index d8e36b7..43a0b35 100644
--- a/net/bridge/br_netfilter.c
+++ b/net/bridge/br_netfilter.c
@@ -295,7 +295,7 @@ static int check_hbh_len(struct sk_buff 
 	len -= 2;
 
 	while (len > 0) {
-		int optlen = raw[off+1]+2;
+		int optlen = skb->nh.raw[off+1]+2;
 
 		switch (skb->nh.raw[off]) {
 		case IPV6_TLV_PAD0:
@@ -308,18 +308,15 @@ static int check_hbh_len(struct sk_buff 
 		case IPV6_TLV_JUMBO:
 			if (skb->nh.raw[off+1] != 4 || (off&3) != 2)
 				goto bad;
-
 			pkt_len = ntohl(*(u32*)(skb->nh.raw+off+2));
-
+			if (pkt_len <= IPV6_MAXPLEN ||
+			    skb->nh.ipv6h->payload_len)
+				goto bad;
 			if (pkt_len > skb->len - sizeof(struct ipv6hdr))
 				goto bad;
-			if (pkt_len + sizeof(struct ipv6hdr) < skb->len) {
-				if (__pskb_trim(skb,
-				    pkt_len + sizeof(struct ipv6hdr)))
-					goto bad;
-				if (skb->ip_summed == CHECKSUM_HW)
-					skb->ip_summed = CHECKSUM_NONE;
-			}
+			if (pskb_trim_rcsum(skb,
+			    pkt_len+sizeof(struct ipv6hdr)))
+				goto bad;
 			break;
 		default:
 			if (optlen > len)
diff --git a/net/ipv4/ip_gre.c b/net/ipv4/ip_gre.c
index 896ce3f..fa64931 100644
--- a/net/ipv4/ip_gre.c
+++ b/net/ipv4/ip_gre.c
@@ -617,7 +617,7 @@ static int ipgre_rcv(struct sk_buff *skb
 
 		skb->mac.raw = skb->nh.raw;
 		skb->nh.raw = __pskb_pull(skb, offset);
-		skb_postpull_rcsum(skb, skb->mac.raw, offset);
+		skb_postpull_rcsum(skb, skb->h.raw, offset);
 		memset(&(IPCB(skb)->opt), 0, sizeof(struct ip_options));
 		skb->pkt_type = PACKET_HOST;
 #ifdef CONFIG_NET_IPGRE_BROADCAST
diff --git a/net/ipv4/netfilter/Makefile b/net/ipv4/netfilter/Makefile
index dab4b58..a76cb0d 100644
--- a/net/ipv4/netfilter/Makefile
+++ b/net/ipv4/netfilter/Makefile
@@ -12,6 +12,7 @@ ip_nat_pptp-objs	:= ip_nat_helper_pptp.o
 
 # connection tracking
 obj-$(CONFIG_IP_NF_CONNTRACK) += ip_conntrack.o
+obj-$(CONFIG_IP_NF_NAT) += ip_nat.o
 
 # conntrack netlink interface
 obj-$(CONFIG_IP_NF_CONNTRACK_NETLINK) += ip_conntrack_netlink.o
@@ -41,7 +42,7 @@ obj-$(CONFIG_IP_NF_IPTABLES) += ip_table
 # the three instances of ip_tables
 obj-$(CONFIG_IP_NF_FILTER) += iptable_filter.o
 obj-$(CONFIG_IP_NF_MANGLE) += iptable_mangle.o
-obj-$(CONFIG_IP_NF_NAT) += iptable_nat.o ip_nat.o
+obj-$(CONFIG_IP_NF_NAT) += iptable_nat.o
 obj-$(CONFIG_IP_NF_RAW) += iptable_raw.o
 
 # matches
diff --git a/net/ipv4/netfilter/ip_conntrack_netlink.c b/net/ipv4/netfilter/ip_conntrack_netlink.c
index 97fab76..e6d3b5c 100644
--- a/net/ipv4/netfilter/ip_conntrack_netlink.c
+++ b/net/ipv4/netfilter/ip_conntrack_netlink.c
@@ -506,7 +506,7 @@ nfattr_failure:
 }
 
 static const int cta_min_proto[CTA_PROTO_MAX] = {
-	[CTA_PROTO_NUM-1]	= sizeof(u_int16_t),
+	[CTA_PROTO_NUM-1]	= sizeof(u_int8_t),
 	[CTA_PROTO_SRC_PORT-1]	= sizeof(u_int16_t),
 	[CTA_PROTO_DST_PORT-1]	= sizeof(u_int16_t),
 	[CTA_PROTO_ICMP_TYPE-1]	= sizeof(u_int8_t),
@@ -532,7 +532,7 @@ ctnetlink_parse_tuple_proto(struct nfatt
 
 	if (!tb[CTA_PROTO_NUM-1])
 		return -EINVAL;
-	tuple->dst.protonum = *(u_int16_t *)NFA_DATA(tb[CTA_PROTO_NUM-1]);
+	tuple->dst.protonum = *(u_int8_t *)NFA_DATA(tb[CTA_PROTO_NUM-1]);
 
 	proto = ip_conntrack_proto_find_get(tuple->dst.protonum);
 
diff --git a/net/ipv4/netfilter/ip_conntrack_proto_tcp.c b/net/ipv4/netfilter/ip_conntrack_proto_tcp.c
index 0658e8f..73f2153 100644
--- a/net/ipv4/netfilter/ip_conntrack_proto_tcp.c
+++ b/net/ipv4/netfilter/ip_conntrack_proto_tcp.c
@@ -341,9 +341,10 @@ static int tcp_print_conntrack(struct se
 static int tcp_to_nfattr(struct sk_buff *skb, struct nfattr *nfa,
 			 const struct ip_conntrack *ct)
 {
-	struct nfattr *nest_parms = NFA_NEST(skb, CTA_PROTOINFO_TCP);
+	struct nfattr *nest_parms;
 	
 	read_lock_bh(&tcp_lock);
+	nest_parms = NFA_NEST(skb, CTA_PROTOINFO_TCP);
 	NFA_PUT(skb, CTA_PROTOINFO_TCP_STATE, sizeof(u_int8_t),
 		&ct->proto.tcp.state);
 	read_unlock_bh(&tcp_lock);
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index a970b47..99ca46d 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -1456,9 +1456,17 @@ void addrconf_prefix_rcv(struct net_devi
 	   not good.
 	 */
 	if (valid_lft >= 0x7FFFFFFF/HZ)
-		rt_expires = 0;
+		rt_expires = 0x7FFFFFFF - (0x7FFFFFFF % HZ);
 	else
-		rt_expires = jiffies + valid_lft * HZ;
+		rt_expires = valid_lft * HZ;
+
+	/*
+	 * We convert this (in jiffies) to clock_t later.
+	 * Avoid arithmetic overflow there as well.
+	 * Overflow can happen only if HZ < USER_HZ.
+	 */
+	if (HZ < USER_HZ && rt_expires > 0x7FFFFFFF / USER_HZ)
+		rt_expires = 0x7FFFFFFF / USER_HZ;
 
 	if (pinfo->onlink) {
 		struct rt6_info *rt;
@@ -1470,12 +1478,12 @@ void addrconf_prefix_rcv(struct net_devi
 					ip6_del_rt(rt, NULL, NULL, NULL);
 					rt = NULL;
 				} else {
-					rt->rt6i_expires = rt_expires;
+					rt->rt6i_expires = jiffies + rt_expires;
 				}
 			}
 		} else if (valid_lft) {
 			addrconf_prefix_route(&pinfo->prefix, pinfo->prefix_len,
-					      dev, rt_expires, RTF_ADDRCONF|RTF_EXPIRES|RTF_PREFIX_RT);
+					      dev, jiffies_to_clock_t(rt_expires), RTF_ADDRCONF|RTF_EXPIRES|RTF_PREFIX_RT);
 		}
 		if (rt)
 			dst_release(&rt->u.dst);
diff --git a/net/ipv6/netfilter/Kconfig b/net/ipv6/netfilter/Kconfig
index bb7ccfe..0f2e654 100644
--- a/net/ipv6/netfilter/Kconfig
+++ b/net/ipv6/netfilter/Kconfig
@@ -211,7 +211,7 @@ config IP6_NF_TARGET_REJECT
 
 config IP6_NF_TARGET_NFQUEUE
 	tristate "NFQUEUE Target Support"
-	depends on IP_NF_IPTABLES
+	depends on IP6_NF_IPTABLES
 	help
 	  This Target replaced the old obsolete QUEUE target.
 
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index 5d5bbb4..1e6f256 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -829,7 +829,7 @@ int ip6_route_add(struct in6_rtmsg *rtms
 	}
 
 	rt->u.dst.obsolete = -1;
-	rt->rt6i_expires = clock_t_to_jiffies(rtmsg->rtmsg_info);
+	rt->rt6i_expires = jiffies + clock_t_to_jiffies(rtmsg->rtmsg_info);
 	if (nlh && (r = NLMSG_DATA(nlh))) {
 		rt->rt6i_protocol = r->rtm_protocol;
 	} else {
diff --git a/net/xfrm/xfrm_policy.c b/net/xfrm/xfrm_policy.c
index cbb0ba3..27afded 100644
--- a/net/xfrm/xfrm_policy.c
+++ b/net/xfrm/xfrm_policy.c
@@ -1014,13 +1014,12 @@ int __xfrm_route_forward(struct sk_buff 
 }
 EXPORT_SYMBOL(__xfrm_route_forward);
 
-/* Optimize later using cookies and generation ids. */
-
 static struct dst_entry *xfrm_dst_check(struct dst_entry *dst, u32 cookie)
 {
-	if (!stale_bundle(dst))
-		return dst;
-
+	/* If it is marked obsolete, which is how we even get here,
+	 * then we have purged it from the policy bundle list and we
+	 * did that for a good reason.
+	 */
 	return NULL;
 }
 
@@ -1104,6 +1103,16 @@ int xfrm_flush_bundles(void)
 	return 0;
 }
 
+static int always_true(struct dst_entry *dst)
+{
+	return 1;
+}
+
+void xfrm_flush_all_bundles(void)
+{
+	xfrm_prune_bundles(always_true);
+}
+
 void xfrm_init_pmtu(struct dst_entry *dst)
 {
 	do {
diff --git a/net/xfrm/xfrm_state.c b/net/xfrm/xfrm_state.c
index 9d206c2..367b483 100644
--- a/net/xfrm/xfrm_state.c
+++ b/net/xfrm/xfrm_state.c
@@ -435,6 +435,8 @@ void xfrm_state_insert(struct xfrm_state
 	spin_lock_bh(&xfrm_state_lock);
 	__xfrm_state_insert(x);
 	spin_unlock_bh(&xfrm_state_lock);
+
+	xfrm_flush_all_bundles();
 }
 EXPORT_SYMBOL(xfrm_state_insert);
 
@@ -482,6 +484,9 @@ out:
 	spin_unlock_bh(&xfrm_state_lock);
 	xfrm_state_put_afinfo(afinfo);
 
+	if (!err)
+		xfrm_flush_all_bundles();
+
 	if (x1) {
 		xfrm_state_delete(x1);
 		xfrm_state_put(x1);

Re: Linux 2.6.14.5

[Grant Coady]

On Mon, 26 Dec 2005 16:53:27 -0800, Greg KH <gregkh@suse.de> wrote:

>We (the -stable team) are announcing the release of the 2.6.14.5 kernel.
>
>The diffstat and short summary of the fixes are below.
>
>I'll also be replying to this message with a copy of the patch between
>2.6.14.4 and 2.6.14.5, as it is small enough to do so.

netfilter is broken compared to 2.6.15-rc7 (first 2.6 kernel tested 
on this box) or 2.4.32 :(  Same ruleset as used for months.

Fails to recognise named chains with a useless error message:

"iptables: No chain/target/match by that name"

Grant.

Re: Linux 2.6.14.5

[David S. Miller]

From: Grant Coady <grant_lkml@dodo.com.au>
Date: Tue, 27 Dec 2005 14:06:03 +1100

> netfilter is broken compared to 2.6.15-rc7 (first 2.6 kernel tested 
> on this box) or 2.4.32 :(  Same ruleset as used for months.
> 
> Fails to recognise named chains with a useless error message:
> 
> "iptables: No chain/target/match by that name"

Please report it to the netfilter mailing list, which is
where the netfilter developers listen and can attend to
your report.

Thanks a lot.

Re: [stable] Re: Linux 2.6.14.5

[Greg KH]

On Tue, Dec 27, 2005 at 02:06:03PM +1100, Grant Coady wrote:
> On Mon, 26 Dec 2005 16:53:27 -0800, Greg KH <gregkh@suse.de> wrote:
> 
> >We (the -stable team) are announcing the release of the 2.6.14.5 kernel.
> >
> >The diffstat and short summary of the fixes are below.
> >
> >I'll also be replying to this message with a copy of the patch between
> >2.6.14.4 and 2.6.14.5, as it is small enough to do so.
> 
> netfilter is broken compared to 2.6.15-rc7 (first 2.6 kernel tested 
> on this box) or 2.4.32 :(  Same ruleset as used for months.

Is it broken compared to 2.6.14.4 and/or 2.6.14?  Care to figure out
which release broke it?

thanks,

greg k-h

Re: Linux 2.6.14.5

[Patrick McHardy]

Grant Coady wrote:
> netfilter is broken compared to 2.6.15-rc7 (first 2.6 kernel tested 
> on this box) or 2.4.32 :(  Same ruleset as used for months.
> 
> Fails to recognise named chains with a useless error message:
> 
> "iptables: No chain/target/match by that name"

Please give an example of a failing command.

Re: Linux 2.6.14.5

[Willy Tarreau]

On Tue, Dec 27, 2005 at 02:06:03PM +1100, Grant Coady wrote:
> On Mon, 26 Dec 2005 16:53:27 -0800, Greg KH <gregkh@suse.de> wrote:
> 
> >We (the -stable team) are announcing the release of the 2.6.14.5 kernel.
> >
> >The diffstat and short summary of the fixes are below.
> >
> >I'll also be replying to this message with a copy of the patch between
> >2.6.14.4 and 2.6.14.5, as it is small enough to do so.
> 
> netfilter is broken compared to 2.6.15-rc7 (first 2.6 kernel tested 
> on this box) or 2.4.32 :(  Same ruleset as used for months.
> 
> Fails to recognise named chains with a useless error message:
> 
> "iptables: No chain/target/match by that name"

Grant, please put a "set -x" at the top of your script so that you
can tell what rule causes this error.

> Grant.

Thanks,
Willy

Re: [stable] Re: Linux 2.6.14.5

[Grant Coady]

On Mon, 26 Dec 2005 19:46:23 -0800, Greg KH <greg@kroah.com> wrote:

>On Tue, Dec 27, 2005 at 02:06:03PM +1100, Grant Coady wrote:
>> On Mon, 26 Dec 2005 16:53:27 -0800, Greg KH <gregkh@suse.de> wrote:
>> 
>> >We (the -stable team) are announcing the release of the 2.6.14.5 kernel.
>> >
>> >The diffstat and short summary of the fixes are below.
>> >
>> >I'll also be replying to this message with a copy of the patch between
>> >2.6.14.4 and 2.6.14.5, as it is small enough to do so.
>> 
>> netfilter is broken compared to 2.6.15-rc7 (first 2.6 kernel tested 
>> on this box) or 2.4.32 :(  Same ruleset as used for months.
>
>Is it broken compared to 2.6.14.4 and/or 2.6.14?  Care to figure out
>which release broke it?

2.6.14.4 -> 2.6.14.5 broke it, 2.6.14 also runs okay, some more info 
on http://bugsplatter.mine.nu/test/boxen/deltree/ -- dmesg, `grep = 
.config`.

This box is the bugsplatter web server, currently running 2.6.14.4.

iptables/netfilter is rejecting constructs containing "state NEW", see:
http://bugsplatter.mine.nu/test/boxen/deltree/iptables-vnL-2.6.14.4-dt
vs
http://bugsplatter.mine.nu/test/boxen/deltree/iptables-vnL-2.6.14.5-dt
some numbers masked with 'zxcv' to protect the guilty :)

Grant.

Re: Linux 2.6.14.5

[Grant Coady]

On Tue, 27 Dec 2005 06:17:29 +0100, Willy Tarreau <willy@w.ods.org> wrote:

>On Tue, Dec 27, 2005 at 02:06:03PM +1100, Grant Coady wrote:
>> On Mon, 26 Dec 2005 16:53:27 -0800, Greg KH <gregkh@suse.de> wrote:
>> 
>> >We (the -stable team) are announcing the release of the 2.6.14.5 kernel.
>> >
>> >The diffstat and short summary of the fixes are below.
>> >
>> >I'll also be replying to this message with a copy of the patch between
>> >2.6.14.4 and 2.6.14.5, as it is small enough to do so.
>> 
>> netfilter is broken compared to 2.6.15-rc7 (first 2.6 kernel tested 
>> on this box) or 2.4.32 :(  Same ruleset as used for months.
>> 
>> Fails to recognise named chains with a useless error message:
>> 
>> "iptables: No chain/target/match by that name"
>
>Grant, please put a "set -x" at the top of your script so that you
>can tell what rule causes this error.

+ iptables -A INPUT -p all --match state --state ESTABLISHED,RELATED -j ACCEPT
iptables: No chain/target/match by that name
+ iptables -A INPUT -p tcp --match state --state NEW --dport ftp --match limit --limit 3/min -j ACCEPT
iptables: No chain/target/match by that name
+ iptables -A INPUT -p tcp --match state --state NEW --dport ftp -j DROP
iptables: No chain/target/match by that name
+ iptables -A INPUT -p tcp --match state --state NEW --dport http --match limit --limit 12/min -j ACCEPT
iptables: No chain/target/match by that name
+ iptables -A INPUT -p tcp --match state --state NEW --dport http -j DROP
iptables: No chain/target/match by that name
  FORWARD + iptables -A FORWARD -p all --match state --state ESTABLISHED,RELATED -j ACCEPT
iptables: No chain/target/match by that name
+ iptables -A egress -p tcp --match state --state NEW --match multiport --dports ftp,http,pop3,nntp,pop3s -j ACCEPT
iptables: No chain/target/match by that name
+ iptables -A egress -p tcp --match state --state NEW --match multiport --dports https,rsync -j ACCEPT
iptables: No chain/target/match by that name
+ iptables -A egress -p all --match state --state NEW --match limit --limit 12/min -j ACCEPT
iptables: No chain/target/match by that name

>
>> Grant.
>
>Thanks,
>Willy
>

Re: Linux 2.6.14.5

[Willy Tarreau]

On Tue, Dec 27, 2005 at 04:42:00PM +1100, Grant Coady wrote:
> On Tue, 27 Dec 2005 06:17:29 +0100, Willy Tarreau <willy@w.ods.org> wrote:
> 
> >On Tue, Dec 27, 2005 at 02:06:03PM +1100, Grant Coady wrote:
> >> On Mon, 26 Dec 2005 16:53:27 -0800, Greg KH <gregkh@suse.de> wrote:
> >> 
> >> >We (the -stable team) are announcing the release of the 2.6.14.5 kernel.
> >> >
> >> >The diffstat and short summary of the fixes are below.
> >> >
> >> >I'll also be replying to this message with a copy of the patch between
> >> >2.6.14.4 and 2.6.14.5, as it is small enough to do so.
> >> 
> >> netfilter is broken compared to 2.6.15-rc7 (first 2.6 kernel tested 
> >> on this box) or 2.4.32 :(  Same ruleset as used for months.
> >> 
> >> Fails to recognise named chains with a useless error message:
> >> 
> >> "iptables: No chain/target/match by that name"
> >
> >Grant, please put a "set -x" at the top of your script so that you
> >can tell what rule causes this error.
> 
> + iptables -A INPUT -p all --match state --state ESTABLISHED,RELATED -j ACCEPT
> iptables: No chain/target/match by that name

So it's not only the NEW state, it's every "--match state".

> + iptables -A INPUT -p tcp --match state --state NEW --dport ftp --match limit --limit 3/min -j ACCEPT
> iptables: No chain/target/match by that name
> + iptables -A INPUT -p tcp --match state --state NEW --dport ftp -j DROP
> iptables: No chain/target/match by that name
> + iptables -A INPUT -p tcp --match state --state NEW --dport http --match limit --limit 12/min -j ACCEPT
> iptables: No chain/target/match by that name
> + iptables -A INPUT -p tcp --match state --state NEW --dport http -j DROP
> iptables: No chain/target/match by that name
>   FORWARD + iptables -A FORWARD -p all --match state --state ESTABLISHED,RELATED -j ACCEPT
> iptables: No chain/target/match by that name
> + iptables -A egress -p tcp --match state --state NEW --match multiport --dports ftp,http,pop3,nntp,pop3s -j ACCEPT
> iptables: No chain/target/match by that name
> + iptables -A egress -p tcp --match state --state NEW --match multiport --dports https,rsync -j ACCEPT
> iptables: No chain/target/match by that name
> + iptables -A egress -p all --match state --state NEW --match limit --limit 12/min -j ACCEPT
> iptables: No chain/target/match by that name

Thanks,
Willy

Re: Linux 2.6.14.5

[Grant Coady]

On Tue, 27 Dec 2005 05:48:08 +0100, Patrick McHardy <kaber@trash.net> wrote:

>Grant Coady wrote:
>> netfilter is broken compared to 2.6.15-rc7 (first 2.6 kernel tested 
>> on this box) or 2.4.32 :(  Same ruleset as used for months.
>> 
>> Fails to recognise named chains with a useless error message:
>> 
>> "iptables: No chain/target/match by that name"
>
>Please give an example of a failing command.
+ iptables -A INPUT -p all --match state --state ESTABLISHED,RELATED -j ACCEPT
iptables: No chain/target/match by that name
+ iptables -A INPUT -p tcp --match state --state NEW --dport ftp --match limit --limit 3/min -j ACCEPT
iptables: No chain/target/match by that name
+ iptables -A INPUT -p tcp --match state --state NEW --dport ftp -j DROP
iptables: No chain/target/match by that name
+ iptables -A INPUT -p tcp --match state --state NEW --dport http --match limit --limit 12/min -j ACCEPT
iptables: No chain/target/match by that name
+ iptables -A INPUT -p tcp --match state --state NEW --dport http -j DROP
iptables: No chain/target/match by that name
  FORWARD + iptables -A FORWARD -p all --match state --state ESTABLISHED,RELATED -j ACCEPT
iptables: No chain/target/match by that name
+ iptables -A egress -p tcp --match state --state NEW --match multiport --dports ftp,http,pop3,nntp,pop3s -j ACCEPT
iptables: No chain/target/match by that name
+ iptables -A egress -p tcp --match state --state NEW --match multiport --dports https,rsync -j ACCEPT
iptables: No chain/target/match by that name
+ iptables -A egress -p all --match state --state NEW --match limit --limit 12/min -j ACCEPT
iptables: No chain/target/match by that name

See also: http://bugsplatter.mine.nu/bash/firewall/rc.firewall.gz
http://bugsplatter.mine.nu/test/boxen/deltree/iptables-vnL-2.6.14.4-dt
http://bugsplatter.mine.nu/test/boxen/deltree/iptables-vnL-2.6.14.5-dt

Grant.

Re: Linux 2.6.14.5

[Grant Coady]

On Tue, 27 Dec 2005 06:45:19 +0100, Willy Tarreau <willy@w.ods.org> wrote:

>On Tue, Dec 27, 2005 at 04:42:00PM +1100, Grant Coady wrote:
>> On Tue, 27 Dec 2005 06:17:29 +0100, Willy Tarreau <willy@w.ods.org> wrote:
>> 
>> >On Tue, Dec 27, 2005 at 02:06:03PM +1100, Grant Coady wrote:
>> >> On Mon, 26 Dec 2005 16:53:27 -0800, Greg KH <gregkh@suse.de> wrote:
>> >> 
>> >> >We (the -stable team) are announcing the release of the 2.6.14.5 kernel.
>> >> >
>> >> >The diffstat and short summary of the fixes are below.
>> >> >
>> >> >I'll also be replying to this message with a copy of the patch between
>> >> >2.6.14.4 and 2.6.14.5, as it is small enough to do so.
>> >> 
>> >> netfilter is broken compared to 2.6.15-rc7 (first 2.6 kernel tested 
>> >> on this box) or 2.4.32 :(  Same ruleset as used for months.
>> >> 
>> >> Fails to recognise named chains with a useless error message:
>> >> 
>> >> "iptables: No chain/target/match by that name"
>> >
>> >Grant, please put a "set -x" at the top of your script so that you
>> >can tell what rule causes this error.
>> 
>> + iptables -A INPUT -p all --match state --state ESTABLISHED,RELATED -j ACCEPT
>> iptables: No chain/target/match by that name
>
>So it's not only the NEW state, it's every "--match state".

Yep, hard evidence vs the early eyeball check (vs the wrong 
first impression :o)

Grant.

Re: Linux 2.6.14.5

[Phil Oester]

On Tue, Dec 27, 2005 at 06:45:19AM +0100, Willy Tarreau wrote:
> On Tue, Dec 27, 2005 at 04:42:00PM +1100, Grant Coady wrote:
> > + iptables -A INPUT -p all --match state --state ESTABLISHED,RELATED -j ACCEPT
> > iptables: No chain/target/match by that name
> 
> So it's not only the NEW state, it's every "--match state".

Odd...works fine here

# uname -r
2.6.14.5
# iptables -nL | grep state
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED 
DROP       all  --  0.0.0.0/0            0.0.0.0/0           state INVALID 
logdrop    tcp  --  0.0.0.0/0            0.0.0.0/0           tcp flags:!0x17/0x02 state NEW 
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED 
DROP       all  --  0.0.0.0/0            0.0.0.0/0           state INVALID 

Phil

Re: Linux 2.6.14.5

[Yasuyuki KOZAKAI]

Hi,

From: Phil Oester <kernel@linuxace.com>
Date: Mon, 26 Dec 2005 22:07:14 -0800

> On Tue, Dec 27, 2005 at 06:45:19AM +0100, Willy Tarreau wrote:
> > On Tue, Dec 27, 2005 at 04:42:00PM +1100, Grant Coady wrote:
> > > + iptables -A INPUT -p all --match state --state ESTABLISHED,RELATED -j ACCEPT
> > > iptables: No chain/target/match by that name
> > 
> > So it's not only the NEW state, it's every "--match state".
> 
> Odd...works fine here

Willy, which version of iptables is ?
And kernel config around netfilter would be helpful.

Regards,

-- Yasuyuki Kozakai

Re: Linux 2.6.14.5

[Grant Coady]

On Mon, 26 Dec 2005 22:07:14 -0800, Phil Oester <kernel@linuxace.com> wrote:

>On Tue, Dec 27, 2005 at 06:45:19AM +0100, Willy Tarreau wrote:
>> On Tue, Dec 27, 2005 at 04:42:00PM +1100, Grant Coady wrote:
>> > + iptables -A INPUT -p all --match state --state ESTABLISHED,RELATED -j ACCEPT
>> > iptables: No chain/target/match by that name
>> 
>> So it's not only the NEW state, it's every "--match state".
>
>Odd...works fine here
>
># uname -r
>2.6.14.5
># iptables -nL | grep state
>ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED 
>DROP       all  --  0.0.0.0/0            0.0.0.0/0           state INVALID 
>logdrop    tcp  --  0.0.0.0/0            0.0.0.0/0           tcp flags:!0x17/0x02 state NEW 
>ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED 
>DROP       all  --  0.0.0.0/0            0.0.0.0/0           state INVALID 

Oops, my apologies to all, just rebuilt kernel again (third time) 
from scratch, using the working .config from 2.6.14.4 -- I do not 
know how I muffed the .config twice in a row on one box without 
stuffing up the seven other boxen I built/tested 2.6.14.5 on :(

Can copying a working 2.6.15-rc7 .config to 2.6.14.5, then make 
oldconfig do this?

Grant.

Re: Linux 2.6.14.5

[Willy Tarreau]

On Tue, Dec 27, 2005 at 03:41:05PM +0900, Yasuyuki KOZAKAI wrote:
> 
> Hi,
> 
> From: Phil Oester <kernel@linuxace.com>
> Date: Mon, 26 Dec 2005 22:07:14 -0800
> 
> > On Tue, Dec 27, 2005 at 06:45:19AM +0100, Willy Tarreau wrote:
> > > On Tue, Dec 27, 2005 at 04:42:00PM +1100, Grant Coady wrote:
> > > > + iptables -A INPUT -p all --match state --state ESTABLISHED,RELATED -j ACCEPT
> > > > iptables: No chain/target/match by that name
> > > 
> > > So it's not only the NEW state, it's every "--match state".
> > 
> > Odd...works fine here
> 
> Willy, which version of iptables is ?
> And kernel config around netfilter would be helpful.

Hey, it's Grant who has the problem, not me. Anyway, he fixed it,
it seems it was related to an invalid .config.

> Regards,
> 
> -- Yasuyuki Kozakai

Regards,
willy

Re: Linux 2.6.14.5

[Yasuyuki KOZAKAI]

From: Willy Tarreau <willy@w.ods.org>

> On Tue, Dec 27, 2005 at 03:41:05PM +0900, Yasuyuki KOZAKAI wrote:
> > From: Phil Oester <kernel@linuxace.com>
> > Date: Mon, 26 Dec 2005 22:07:14 -0800
> > 
> > > On Tue, Dec 27, 2005 at 06:45:19AM +0100, Willy Tarreau wrote:
> > > > On Tue, Dec 27, 2005 at 04:42:00PM +1100, Grant Coady wrote:
> > > > > + iptables -A INPUT -p all --match state --state ESTABLISHED,RELATED -j ACCEPT
> > > > > iptables: No chain/target/match by that name
> > > > 
> > > > So it's not only the NEW state, it's every "--match state".
> > > 
> > > Odd...works fine here
> > 
> > Willy, which version of iptables is ?
> > And kernel config around netfilter would be helpful.
> 
> Hey, it's Grant who has the problem, not me. Anyway, he fixed it,
> it seems it was related to an invalid .config.

Sorry about this, and thanks for report.

-- Yasuyuki Kozakai

Re: Linux 2.6.14.5

[Grant Coady]

On Mon, 26 Dec 2005 19:33:35 -0800 (PST), "David S. Miller" <davem@davemloft.net> wrote:

>
>Please report it to the netfilter mailing list, which is
>where the netfilter developers listen and can attend to
>your report.
>
>Thanks a lot.

Why bother?

"
Your request to the netfilter-devel mailing list

    Posting of your message titled "Re: Linux 2.6.14.5"

has been rejected by the list moderator.  The moderator gave the
following reason for rejecting your request:

"Non-members are not allowed to post messages to this list."

Any questions or comments should be directed to the list administrator
at:

    netfilter-devel-owner@lists.netfilter.org
"

Grant.

Re: Linux 2.6.14.5

[Gene Heskett]

On Tuesday 27 December 2005 15:01, Grant Coady wrote:
>On Mon, 26 Dec 2005 19:33:35 -0800 (PST), "David S. Miller" 
<davem@davemloft.net> wrote:
>>Please report it to the netfilter mailing list, which is
>>where the netfilter developers listen and can attend to
>>your report.
>>
>>Thanks a lot.
>
>Why bother?
>
>"
>Your request to the netfilter-devel mailing list
>
>    Posting of your message titled "Re: Linux 2.6.14.5"
>
>has been rejected by the list moderator.  The moderator gave the
>following reason for rejecting your request:
>
>"Non-members are not allowed to post messages to this list."
>
>Any questions or comments should be directed to the list
> administrator at:
>
>    netfilter-devel-owner@lists.netfilter.org
>"
>
>Grant.
>
I too have been rejected at that address.  Like Grant, why bother seems 
to be the appropriate response.  If they want to here soonest when 
there is a problem, then the moderator should clear what is obviously 
not a spam message to the list in a reasonable time frame.  Its never 
happened to me but once and I was bascily told to "go away little 
boy." 

I'm already subbed to about 40 lists, and while there are some I could 
drop to make room for others, my interests are best described as 
ecclectic.

If the netfilter folks want to be artificialy quiet, shrug.

-- 
Cheers, Gene
People having trouble with vz bouncing email to me should add the word
'online' between the 'verizon', and the dot which bypasses vz's
stupid bounce rules.  I do use spamassassin too. :-)
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.

Re: Linux 2.6.14.5

[Denis Vlasenko]

On Tuesday 27 December 2005 22:40, Gene Heskett wrote:
> On Tuesday 27 December 2005 15:01, Grant Coady wrote:
> >On Mon, 26 Dec 2005 19:33:35 -0800 (PST), "David S. Miller" 
> <davem@davemloft.net> wrote:
> >>Please report it to the netfilter mailing list, which is
> >>where the netfilter developers listen and can attend to
> >>your report.
> >>
> >>Thanks a lot.
> >
> >Why bother?
> >
> >"
> >Your request to the netfilter-devel mailing list
> >
> >    Posting of your message titled "Re: Linux 2.6.14.5"
> >
> >has been rejected by the list moderator.  The moderator gave the
> >following reason for rejecting your request:
> >
> >"Non-members are not allowed to post messages to this list."
> >
> >Any questions or comments should be directed to the list
> > administrator at:
> >
> >    netfilter-devel-owner@lists.netfilter.org
> >"
> >
> >Grant.
> >
> I too have been rejected at that address.  Like Grant, why bother seems 
> to be the appropriate response.  If they want to here soonest when 
> there is a problem, then the moderator should clear what is obviously 
> not a spam message to the list in a reasonable time frame.  Its never 
> happened to me but once and I was bascily told to "go away little 
> boy." 

Moderators of mailing lists scale badly compared to number
China-hosted hosts spewing tons of TCP traffic to port 25...

> I'm already subbed to about 40 lists, and while there are some I could 
> drop to make room for others, my interests are best described as 
> ecclectic.
> 
> If the netfilter folks want to be artificialy quiet, shrug.

I guess they prefer bugs to be reported thru bugzilla.
I just reported one yesterday.
--
vda

Re: Linux 2.6.14.5

[Lee Revell]

On Wed, 2005-12-28 at 10:02 +0200, Denis Vlasenko wrote:
> On Tuesday 27 December 2005 22:40, Gene Heskett wrote:
> > On Tuesday 27 December 2005 15:01, Grant Coady wrote:
> > >On Mon, 26 Dec 2005 19:33:35 -0800 (PST), "David S. Miller" 
> > <davem@davemloft.net> wrote:
> > >>Please report it to the netfilter mailing list, which is
> > >>where the netfilter developers listen and can attend to
> > >>your report.
> > >>
> > >>Thanks a lot.
> > >
> > >Why bother?
> > >
> > >"
> > >Your request to the netfilter-devel mailing list
> > >
> > >    Posting of your message titled "Re: Linux 2.6.14.5"
> > >
> > >has been rejected by the list moderator.  The moderator gave the
> > >following reason for rejecting your request:
> > >
> > >"Non-members are not allowed to post messages to this list."
> > >
> > >Any questions or comments should be directed to the list
> > > administrator at:
> > >
> > >    netfilter-devel-owner@lists.netfilter.org
> > >"
> > >
> > >Grant.
> > >
> > I too have been rejected at that address.  Like Grant, why bother seems 
> > to be the appropriate response.  If they want to here soonest when 
> > there is a problem, then the moderator should clear what is obviously 
> > not a spam message to the list in a reasonable time frame.  Its never 
> > happened to me but once and I was bascily told to "go away little 
> > boy." 
> 
> Moderators of mailing lists scale badly compared to number
> China-hosted hosts spewing tons of TCP traffic to port 25...

So lose the moderation.  It works fine on 10-20 other lists I am on and
we are not buried in spam.

Lee