linux-toradex.git/net, branch v2.6.24.4

BLUETOOTH: Fix bugs in previous conn add/del workqueue changes.

2008-03-24T18:48:33+00:00

Jens Axboe noticed that we were queueing &conn->work on both btaddconn
and keventd_wq.

Signed-off-by: Dave Young 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Chris Wright

NETFILTER: nfnetlink_log: fix computation of netlink skb size

2008-03-24T18:47:54+00:00

Upstream commit 7000d38d:

This patch is similar to nfnetlink_queue fixes. It fixes the computation
of skb size by using NLMSG_SPACE instead of NLMSG_ALIGN.

Signed-off-by: Eric Leblond 
Signed-off-by: Patrick McHardy 
Signed-off-by: Chris Wright 
Signed-off-by: Greg Kroah-Hartman

NETFILTER: nfnetlink_queue: fix computation of allocated size for netlink skb

2008-03-24T18:47:49+00:00

Upstream commit cabaa9bf:

Size of the netlink skb was wrongly computed because the formula was using
NLMSG_ALIGN instead of NLMSG_SPACE. NLMSG_ALIGN does not add the room for
netlink header as NLMSG_SPACE does. This was causing a failure of message
building in some cases.

On my test system, all messages for packets in range [8*k+41, 8*k+48] where k
is an integer were invalid and the corresponding packets were dropped.

Signed-off-by: Eric Leblond 
Signed-off-by: Patrick McHardy 
Signed-off-by: Chris Wright 
Signed-off-by: Greg Kroah-Hartman

NETFILTER: xt_time: fix failure to match on Sundays

2008-03-24T18:47:47+00:00

Upstream commit 4f4c9430:

xt_time_match() in net/netfilter/xt_time.c in kernel 2.6.24 never
matches on Sundays. On my host I have a rule like

iptables -A OUTPUT -m time --weekdays Sun -j REJECT

and it never matches. The problem is in localtime_2(), which uses

    r->weekday = (4 + r->dse) % 7;

to map the epoch day onto a weekday in {0,...,6}. In particular this
gives 0 for Sundays. But 0 has to be wrong; a weekday of 0 can never
match. xt_time_match() has

    if (!(info->weekdays_match & (1 << current_time.weekday)))
        return false;

and when current_time.weekday = 0, the result of the & is always
zero, even when info->weekdays_match = XT_TIME_ALL_WEEKDAYS = 0xFE.

Signed-off-by: Jan Engelhardt 
Signed-off-by: Patrick McHardy 
Signed-off-by: Chris Wright 
Signed-off-by: Greg Kroah-Hartman

NETFILTER: fix ebtable targets return

2008-03-24T18:47:23+00:00

Upstream commit 1b04ab459:

The function ebt_do_table doesn't take NF_DROP as a verdict from the targets.

Signed-off-by: Joonwoo Park 
Signed-off-by: Patrick McHardy 
Signed-off-by: David S. Miller 
Signed-off-by: Chris Wright 
Signed-off-by: Greg Kroah-Hartman

NETFILTER: Fix incorrect use of skb_make_writable

2008-03-24T18:47:23+00:00

Upstream commit eb1197bc0:

http://bugzilla.kernel.org/show_bug.cgi?id=9920
The function skb_make_writable returns true or false.

Signed-off-by: Joonwoo Park 
Signed-off-by: Patrick McHardy 
Signed-off-by: David S. Miller 
Signed-off-by: Chris Wright 
Signed-off-by: Greg Kroah-Hartman

NETFILTER: nfnetlink_queue: fix SKB_LINEAR_ASSERT when mangling packet data

2008-03-24T18:47:22+00:00

Upstream commit e2b58a67:

As reported by Tomas Simonaitis , inserting new
data in skbs queued over {ip,ip6,nfnetlink}_queue triggers a SKB_LINEAR_ASSERT
in skb_put().

Going back through the git history, it seems this bug is present since at
least 2.6.12-rc2, probably even since the removal of skb_linearize() for
netfilter.

Linearize non-linear skbs through skb_copy_expand() when enlarging them.
Tested by Thomas, fixes bugzilla #9933.

Signed-off-by: Patrick McHardy 
Signed-off-by: David S. Miller 
Signed-off-by: Chris Wright 
Signed-off-by: Greg Kroah-Hartman

IPCOMP: Disable BH on output when using shared tfm

2008-03-24T18:47:08+00:00

Upstream commit: 21e43188f272c7fd9efc84b8244c0b1dfccaa105

Because we use shared tfm objects in order to conserve memory,
(each tfm requires 128K of vmalloc memory), BH needs to be turned
off on output as that can occur in process context.

Previously this was done implicitly by the xfrm output code.
That was lost when it became lockless.  So we need to add the
BH disabling to IPComp directly.

Signed-off-by: Herbert Xu 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Chris Wright

IPCONFIG: The kernel gets no IP from some DHCP servers

2008-03-24T18:47:07+00:00

Upstream commit: dea75bdfa57f75a7a7ec2961ec28db506c18e5db

From: Stephen Hemminger 

Based upon a patch by Marcel Wappler:

   This patch fixes a DHCP issue of the kernel: some DHCP servers
   (i.e.  in the Linksys WRT54Gv5) are very strict about the contents
   of the DHCPDISCOVER packet they receive from clients.

   Table 5 in RFC2131 page 36 requests the fields 'ciaddr' and
   'siaddr' MUST be set to '0'.  These DHCP servers ignore Linux
   kernel's DHCP discovery packets with these two fields set to
   '255.255.255.255' (in contrast to popular DHCP clients, such as
   'dhclient' or 'udhcpc').  This leads to a not booting system.

Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Chris Wright

IPV4: Remove IP_TOS setting privilege checks.

2008-03-24T18:47:07+00:00

Upstream commit: e4f8b5d4edc1edb0709531bd1a342655d5e8b98e

Various RFCs have all sorts of things to say about the CS field of the
DSCP value.  In particular they try to make the distinction between
values that should be used by "user applications" and things like
routing daemons.

This seems to have influenced the CAP_NET_ADMIN check which exists for
IP_TOS socket option settings, but in fact it has an off-by-one error
so it wasn't allowing CS5 which is meant for "user applications" as
well.

Further adding to the inconsistency and brokenness here, IPV6 does not
validate the DSCP values specified for the IPV6_TCLASS socket option.

The real actual uses of these TOS values are system specific in the
final analysis, and these RFC recommendations are just that, "a
recommendation".  In fact the standards very purposefully use
"SHOULD" and "SHOULD NOT" when describing how these values can be
used.

In the final analysis the only clean way to provide consistency here
is to remove the CAP_NET_ADMIN check.  The alternatives just don't
work out:

1) If we add the CAP_NET_ADMIN check to ipv6, this can break existing
   setups.

2) If we just fix the off-by-one error in the class comparison in
   IPV4, certain DSCP values can be used in IPV6 but not IPV4 by
   default.  So people will just ask for a sysctl asking to
   override that.

I checked several other freely available kernel trees and they
do not make any privilege checks in this area like we do.  For
the BSD stacks, this goes back all the way to Stevens Volume 2
and beyond.

Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Chris Wright