Skip to content

L
linux
Switch branch/tag
  1. 23 Dec, 2011 1 commit
    • Florian Westphal's avatar
      netfilter: xt_connbytes: handle negation correctly · 0354b48f
      Florian Westphal authored 
      "! --connbytes 23:42" should match if the packet/byte count is not in range.

As there is no explict "invert match" toggle in the match structure,
userspace swaps the from and to arguments
(i.e., as if "--connbytes 42:23" were given).

However, "what <= 23 && what >= 42" will always be false.

Change things so we use "||" in case "from" is larger than "to".

This change may look like it breaks backwards compatibility when "to" is 0.
However, older iptables binaries will refuse "connbytes 42:0",
and current releases treat it to mean "! --connbytes 0:42",
so we should be fine.
Signed-off-by: default avatarFlorian Westphal <fw@strlen.de>
Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      0354b48f
  3. 13 Dec, 2011 1 commit
  5. 12 Dec, 2011 2 commits
    • Ted Feng's avatar
      ipip, sit: copy parms.name after register_netdevice · 72b36015
      Ted Feng authored 
      Same fix as 731abb9c for ipip and sit tunnel.
Commit 1c5cae81 removed an explicit call to dev_alloc_name in
ipip_tunnel_locate and ipip6_tunnel_locate, because register_netdevice
will now create a valid name, however the tunnel keeps a copy of the
name in the private parms structure. Fix this by copying the name back
after register_netdevice has successfully returned.

This shows up if you do a simple tunnel add, followed by a tunnel show:

$ sudo ip tunnel add mode ipip remote 10.2.20.211
$ ip tunnel
tunl0: ip/ip  remote any  local any  ttl inherit  nopmtudisc
tunl%d: ip/ip  remote 10.2.20.211  local any  ttl inherit
$ sudo ip tunnel add mode sit remote 10.2.20.212
$ ip tunnel
sit0: ipv6/ip  remote any  local any  ttl 64  nopmtudisc 6rd-prefix 2002::/16
sit%d: ioctl 89f8 failed: No such device
sit%d: ipv6/ip  remote 10.2.20.212  local any  ttl inherit

Cc: stable@vger.kernel.org
Signed-off-by: default avatarTed Feng <artisdom@gmail.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      72b36015
    • Li Wei's avatar
      ipv6: Fix for adding multicast route for loopback device automatically. · 4af04aba
      Li Wei authored 
      There is no obvious reason to add a default multicast route for loopback
devices, otherwise there would be a route entry whose dst.error set to
-ENETUNREACH that would blocking all multicast packets.

====================

[ more detailed explanation ]

The problem is that the resulting routing table depends on the sequence
of interface's initialization and in some situation, that would block all
muticast packets. Suppose there are two interfaces on my computer
(lo and eth0), if we initailize 'lo' before 'eth0', the resuting routing
table(for multicast) would be

# ip -6 route show | grep ff00::
unreachable ff00::/8 dev lo metric 256 error -101
ff00::/8 dev eth0 metric 256

When sending multicasting packets, routing subsystem will return the first
route entry which with a error set to -101(ENETUNREACH).

I know the kernel will set the default ipv6 address for 'lo' when it is up
and won't set the default multicast route for it, but there is no reason to
stop 'init' program from setting address for 'lo', and that is exactly what
systemd did.

I am sure there is something wrong with kernel or systemd, currently I preferred
kernel caused this problem.

====================
Signed-off-by: default avatarLi Wei <lw@cn.fujitsu.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4af04aba
  7. 09 Dec, 2011 1 commit
  9. 08 Dec, 2011 1 commit
    • Hauke Mehrtens's avatar
      ssb: fix init regression with SoCs · 329456d1
      Hauke Mehrtens authored 
      This fixes a Data bus error on some SoCs. The first fix for this
problem did not solve it on all devices.
    commit 6ae8ec27
    Author: Rafał Miłecki <zajec5@gmail.com>
    Date:   Tue Jul 5 17:25:32 2011 +0200
        ssb: fix init regression of hostmode PCI core

In ssb_pcicore_fix_sprom_core_index() the sprom on the PCI core is
accessed, but the sprom only exists when the ssb bus is connected over
a PCI bus to the rest of the system and not when the SSB Bus is the
main system bus. SoCs sometimes have a PCI host controller and there
this code will not be executed, but there are some old SoCs with an PCI
controller in client mode around and ssb_pcicore_fix_sprom_core_index()
should not be called on these devices too. The PCI controller on these
devices are unused, but without this fix it results in an Data bus
error when it gets initialized.

Cc: Michael Buesch <m@bues.ch>
Cc: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: default avatarHauke Mehrtens <hauke@hauke-m.de>
Cc: stable@vger.kernel.org
Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      329456d1
  11. 07 Dec, 2011 6 commits
  13. 06 Dec, 2011 16 commits
  15. 05 Dec, 2011 12 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7