1. 21 4月, 2012 3 次提交
  2. 19 4月, 2012 1 次提交
  3. 18 4月, 2012 1 次提交
  4. 16 4月, 2012 2 次提交
  5. 05 4月, 2012 1 次提交
  6. 02 4月, 2012 1 次提交
  7. 29 3月, 2012 1 次提交
  8. 28 3月, 2012 1 次提交
    • B
      net/ipv4: fix IPv4 multicast over network namespaces · 4e7b2f14
      Benjamin LaHaise 提交于
      When using multicast over a local bridge feeding a number of LXC guests
      using veth, the LXC guests are unable to get a response from other guests
      when pinging 224.0.0.1.  Multicast packets did not appear to be getting
      delivered to the network namespaces of the guest hosts, and further
      inspection showed that the incoming route was pointing to the loopback
      device of the host, not the guest.  This lead to the wrong network namespace
      being picked up by sockets (like ICMP).  Fix this by using the correct
      network namespace when creating the inbound route entry.
      Signed-off-by: NBenjamin LaHaise <bcrl@kvack.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4e7b2f14
  9. 13 3月, 2012 1 次提交
  10. 12 3月, 2012 1 次提交
    • J
      net: Convert printks to pr_<level> · 058bd4d2
      Joe Perches 提交于
      Use a more current kernel messaging style.
      
      Convert a printk block to print_hex_dump.
      Coalesce formats, align arguments.
      Use %s, __func__ instead of embedding function names.
      
      Some messages that were prefixed with <foo>_close are
      now prefixed with <foo>_fini.  Some ah4 and esp messages
      are now not prefixed with "ip ".
      
      The intent of this patch is to later add something like
        #define pr_fmt(fmt) "IPv4: " fmt.
      to standardize the output messages.
      
      Text size is trivially reduced. (x86-32 allyesconfig)
      
      $ size net/ipv4/built-in.o*
         text	   data	    bss	    dec	    hex	filename
       887888	  31558	 249696	1169142	 11d6f6	net/ipv4/built-in.o.new
       887934	  31558	 249800	1169292	 11d78c	net/ipv4/built-in.o.old
      Signed-off-by: NJoe Perches <joe@perches.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      058bd4d2
  11. 08 3月, 2012 2 次提交
  12. 16 2月, 2012 1 次提交
  13. 27 1月, 2012 1 次提交
    • D
      ipv4/ipv6: Prepare for new route gateway semantics. · 39232973
      David S. Miller 提交于
      In the future the ipv4/ipv6 route gateway will take on two types
      of values:
      
      1) INADDR_ANY/IN6ADDR_ANY, for local network routes, and in this case
         the neighbour must be obtained using the destination address in
         ipv4/ipv6 header as the lookup key.
      
      2) Everything else, the actual nexthop route address.
      
      So if the gateway is not inaddr-any we use it, otherwise we must use
      the packet's destination address.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      39232973
  14. 23 12月, 2011 2 次提交
    • E
      net: introduce DST_NOPEER dst flag · e688a604
      Eric Dumazet 提交于
      Chris Boot reported crashes occurring in ipv6_select_ident().
      
      [  461.457562] RIP: 0010:[<ffffffff812dde61>]  [<ffffffff812dde61>]
      ipv6_select_ident+0x31/0xa7
      
      [  461.578229] Call Trace:
      [  461.580742] <IRQ>
      [  461.582870]  [<ffffffff812efa7f>] ? udp6_ufo_fragment+0x124/0x1a2
      [  461.589054]  [<ffffffff812dbfe0>] ? ipv6_gso_segment+0xc0/0x155
      [  461.595140]  [<ffffffff812700c6>] ? skb_gso_segment+0x208/0x28b
      [  461.601198]  [<ffffffffa03f236b>] ? ipv6_confirm+0x146/0x15e
      [nf_conntrack_ipv6]
      [  461.608786]  [<ffffffff81291c4d>] ? nf_iterate+0x41/0x77
      [  461.614227]  [<ffffffff81271d64>] ? dev_hard_start_xmit+0x357/0x543
      [  461.620659]  [<ffffffff81291cf6>] ? nf_hook_slow+0x73/0x111
      [  461.626440]  [<ffffffffa0379745>] ? br_parse_ip_options+0x19a/0x19a
      [bridge]
      [  461.633581]  [<ffffffff812722ff>] ? dev_queue_xmit+0x3af/0x459
      [  461.639577]  [<ffffffffa03747d2>] ? br_dev_queue_push_xmit+0x72/0x76
      [bridge]
      [  461.646887]  [<ffffffffa03791e3>] ? br_nf_post_routing+0x17d/0x18f
      [bridge]
      [  461.653997]  [<ffffffff81291c4d>] ? nf_iterate+0x41/0x77
      [  461.659473]  [<ffffffffa0374760>] ? br_flood+0xfa/0xfa [bridge]
      [  461.665485]  [<ffffffff81291cf6>] ? nf_hook_slow+0x73/0x111
      [  461.671234]  [<ffffffffa0374760>] ? br_flood+0xfa/0xfa [bridge]
      [  461.677299]  [<ffffffffa0379215>] ?
      nf_bridge_update_protocol+0x20/0x20 [bridge]
      [  461.684891]  [<ffffffffa03bb0e5>] ? nf_ct_zone+0xa/0x17 [nf_conntrack]
      [  461.691520]  [<ffffffffa0374760>] ? br_flood+0xfa/0xfa [bridge]
      [  461.697572]  [<ffffffffa0374812>] ? NF_HOOK.constprop.8+0x3c/0x56
      [bridge]
      [  461.704616]  [<ffffffffa0379031>] ?
      nf_bridge_push_encap_header+0x1c/0x26 [bridge]
      [  461.712329]  [<ffffffffa037929f>] ? br_nf_forward_finish+0x8a/0x95
      [bridge]
      [  461.719490]  [<ffffffffa037900a>] ?
      nf_bridge_pull_encap_header+0x1c/0x27 [bridge]
      [  461.727223]  [<ffffffffa0379974>] ? br_nf_forward_ip+0x1c0/0x1d4 [bridge]
      [  461.734292]  [<ffffffff81291c4d>] ? nf_iterate+0x41/0x77
      [  461.739758]  [<ffffffffa03748cc>] ? __br_deliver+0xa0/0xa0 [bridge]
      [  461.746203]  [<ffffffff81291cf6>] ? nf_hook_slow+0x73/0x111
      [  461.751950]  [<ffffffffa03748cc>] ? __br_deliver+0xa0/0xa0 [bridge]
      [  461.758378]  [<ffffffffa037533a>] ? NF_HOOK.constprop.4+0x56/0x56
      [bridge]
      
      This is caused by bridge netfilter special dst_entry (fake_rtable), a
      special shared entry, where attaching an inetpeer makes no sense.
      
      Problem is present since commit 87c48fa3 (ipv6: make fragment
      identifications less predictable)
      
      Introduce DST_NOPEER dst flag and make sure ipv6_select_ident() and
      __ip_select_ident() fallback to the 'no peer attached' handling.
      Reported-by: NChris Boot <bootc@bootc.net>
      Tested-by: NChris Boot <bootc@bootc.net>
      Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e688a604
    • S
  15. 22 12月, 2011 1 次提交
  16. 06 12月, 2011 2 次提交
  17. 03 12月, 2011 1 次提交
  18. 02 12月, 2011 1 次提交
  19. 01 12月, 2011 2 次提交
  20. 27 11月, 2011 5 次提交
  21. 19 11月, 2011 1 次提交
    • E
      ipv4: fix redirect handling · 9cc20b26
      Eric Dumazet 提交于
      commit f39925db (ipv4: Cache learned redirect information in
      inetpeer.) introduced a regression in ICMP redirect handling.
      
      It assumed ipv4_dst_check() would be called because all possible routes
      were attached to the inetpeer we modify in ip_rt_redirect(), but thats
      not true.
      
      commit 7cc9150e (route: fix ICMP redirect validation) tried to fix
      this but solution was not complete. (It fixed only one route)
      
      So we must lookup existing routes (including different TOS values) and
      call check_peer_redir() on them.
      Reported-by: NIvan Zahariev <famzah@icdsoft.com>
      Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
      CC: Flavio Leitner <fbl@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9cc20b26
  22. 09 11月, 2011 1 次提交
  23. 25 10月, 2011 1 次提交
  24. 24 10月, 2011 1 次提交
    • F
      route: fix ICMP redirect validation · 7cc9150e
      Flavio Leitner 提交于
      The commit f39925db
      (ipv4: Cache learned redirect information in inetpeer.)
      removed some ICMP packet validations which are required by
      RFC 1122, section 3.2.2.2:
      ...
        A Redirect message SHOULD be silently discarded if the new
        gateway address it specifies is not on the same connected
        (sub-) net through which the Redirect arrived [INTRO:2,
        Appendix A], or if the source of the Redirect is not the
        current first-hop gateway for the specified destination (see
        Section 3.3.1).
      Signed-off-by: NFlavio Leitner <fbl@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7cc9150e
  25. 04 10月, 2011 1 次提交
  26. 12 8月, 2011 1 次提交
  27. 11 8月, 2011 1 次提交
    • J
      ipv4: some rt_iif -> rt_route_iif conversions · 97a80410
      Julian Anastasov 提交于
      As rt_iif represents input device even for packets
      coming from loopback with output route, it is not an unique
      key specific to input routes. Now rt_route_iif has such role,
      it was fl.iif in 2.6.38, so better to change the checks at
      some places to save CPU cycles and to restore 2.6.38 semantics.
      
      compare_keys:
      	- input routes: only rt_route_iif matters, rt_iif is same
      	- output routes: only rt_oif matters, rt_iif is not
      		used for matching in __ip_route_output_key
      	- now we are back to 2.6.38 state
      
      ip_route_input_common:
      	- matching rt_route_iif implies input route
      	- compared to 2.6.38 we eliminated one rth->fl.oif check
      	because it was not needed even for 2.6.38
      
      compare_hash_inputs:
      	Only the change here is not an optimization, it has
      	effect only for output routes. I assume I'm restoring
      	the original intention to ignore oif, it was using fl.iif
      	- now we are back to 2.6.38 state
      Signed-off-by: NJulian Anastasov <ja@ssi.bg>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      97a80410
  28. 08 8月, 2011 1 次提交
    • J
      ipv4: fix the reusing of routing cache entries · d547f727
      Julian Anastasov 提交于
      	compare_keys and ip_route_input_common rely on
      rt_oif for distinguishing of input and output routes
      with same keys values. But sometimes the input route has
      also same hash chain (keyed by iif != 0) with the output
      routes (keyed by orig_oif=0). Problem visible if running
      with small number of rhash_entries.
      
      	Fix them to use rt_route_iif instead. By this way
      input route can not be returned to users that request
      output route.
      
      	The patch fixes the ip_rt_bug errors that were
      reported in ip_local_out context, mostly for 255.255.255.255
      destinations.
      Signed-off-by: NJulian Anastasov <ja@ssi.bg>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d547f727
  29. 07 8月, 2011 1 次提交
    • D
      net: Compute protocol sequence numbers and fragment IDs using MD5. · 6e5714ea
      David S. Miller 提交于
      Computers have become a lot faster since we compromised on the
      partial MD4 hash which we use currently for performance reasons.
      
      MD5 is a much safer choice, and is inline with both RFC1948 and
      other ISS generators (OpenBSD, Solaris, etc.)
      
      Furthermore, only having 24-bits of the sequence number be truly
      unpredictable is a very serious limitation.  So the periodic
      regeneration and 8-bit counter have been removed.  We compute and
      use a full 32-bit sequence number.
      
      For ipv6, DCCP was found to use a 32-bit truncated initial sequence
      number (it needs 43-bits) and that is fixed here as well.
      Reported-by: NDan Kaminsky <dan@doxpara.com>
      Tested-by: NWilly Tarreau <w@1wt.eu>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6e5714ea