1. 12 6月, 2008 1 次提交
  2. 13 5月, 2008 1 次提交
  3. 12 4月, 2008 1 次提交
    • Y
      [IPV6]: Make address arguments const. · 9acd9f3a
      YOSHIFUJI Hideaki 提交于
      - net/ipv6/addrconf.c:
      	ipv6_get_ifaddr(), ipv6_dev_get_saddr()
      - net/ipv6/mcast.c:
      	ipv6_sock_mc_join(), ipv6_sock_mc_drop(),
      	inet6_mc_check(),
      	ipv6_dev_mc_inc(), __ipv6_dev_mc_dec(), ipv6_dev_mc_dec(),
      	ipv6_chk_mcast_addr()
      - net/ipv6/route.c:
      	rt6_lookup(), icmp6_dst_alloc()
      - net/ipv6/ip6_output.c:
      	ip6_nd_hdr()
      - net/ipv6/ndisc.c:
      	ndisc_send_ns(), ndisc_send_rs(), ndisc_send_redirect(),
      	ndisc_get_neigh(), __ndisc_send()
      Signed-off-by: NYOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
      9acd9f3a
  4. 05 4月, 2008 1 次提交
  5. 26 3月, 2008 2 次提交
  6. 25 3月, 2008 3 次提交
  7. 08 3月, 2008 1 次提交
  8. 06 3月, 2008 2 次提交
  9. 04 3月, 2008 1 次提交
  10. 29 2月, 2008 1 次提交
  11. 15 2月, 2008 1 次提交
  12. 13 2月, 2008 1 次提交
    • H
      [IPV6]: Fix IPsec datagram fragmentation · 28a89453
      Herbert Xu 提交于
      This is a long-standing bug in the IPsec IPv6 code that breaks
      when we emit a IPsec tunnel-mode datagram packet.  The problem
      is that the code the emits the packet assumes the IPv6 stack
      will fragment it later, but the IPv6 stack assumes that whoever
      is emitting the packet is going to pre-fragment the packet.
      
      In the long term we need to fix both sides, e.g., to get the
      datagram code to pre-fragment as well as to get the IPv6 stack
      to fragment locally generated tunnel-mode packet.
      
      For now this patch does the second part which should make it
      work for the IPsec host case.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      28a89453
  13. 01 2月, 2008 2 次提交
  14. 29 1月, 2008 7 次提交
  15. 23 1月, 2008 1 次提交
  16. 07 12月, 2007 1 次提交
  17. 07 11月, 2007 1 次提交
  18. 24 10月, 2007 1 次提交
  19. 16 10月, 2007 1 次提交
    • P
      [IPV6]: Uninline netfilter okfns · ad643a79
      Patrick McHardy 提交于
      Uninline netfilter okfns for those cases where gcc can generate tail-calls.
      
      Before:
         text    data     bss     dec     hex filename
      8994153 1016524  524652 10535329         a0c1a1 vmlinux
      
      After:
         text    data     bss     dec     hex filename
      8992761 1016524  524652 10533937         a0bc31 vmlinux
      -------------------------------------------------------
        -1392
      
      All cases have been verified to generate tail-calls with and without netfilter.
      Signed-off-by: NPatrick McHardy <kaber@trash.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ad643a79
  20. 11 10月, 2007 2 次提交
    • D
      [IPV6]: Add ICMPMsgStats MIB (RFC 4293) [rev 2] · 14878f75
      David L Stevens 提交于
      Background: RFC 4293 deprecates existing individual, named ICMP
      type counters to be replaced with the ICMPMsgStatsTable. This table
      includes entries for both IPv4 and IPv6, and requires counting of all
      ICMP types, whether or not the machine implements the type.
      
      These patches "remove" (but not really) the existing counters, and
      replace them with the ICMPMsgStats tables for v4 and v6.
      It includes the named counters in the /proc places they were, but gets the
      values for them from the new tables. It also counts packets generated
      from raw socket output (e.g., OutEchoes, MLD queries, RA's from
      radvd, etc).
      
      Changes:
      1) create icmpmsg_statistics mib
      2) create icmpv6msg_statistics mib
      3) modify existing counters to use these
      4) modify /proc/net/snmp to add "IcmpMsg" with all ICMP types
              listed by number for easy SNMP parsing
      5) modify /proc/net/snmp printing for "Icmp" to get the named data
              from new counters.
      [new to 2nd revision]
      6) support per-interface ICMP stats
      7) use common macro for per-device stat macros
      Signed-off-by: NDavid L Stevens <dlstevens@us.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      14878f75
    • M
      [IPV6] IPSEC: Omit redirect for tunnelled packet. · 1e5dc146
      Masahide NAKAMURA 提交于
      IPv6 IPsec tunnel gateway incorrectly sends redirect to
      router or sender when network device the IPsec tunnelled packet
      is arrived is the same as the one the decapsulated packet
      is sent.
      
      With this patch, it omits to send the redirect when the forwarding
      skbuff carries secpath, since such skbuff should be assumed as
      a decapsulated packet from IPsec tunnel by own.
      
      It may be a rare case for an IPsec security gateway, however
      it is not rare when the gateway is MIPv6 Home Agent since
      the another tunnel end-point is Mobile Node and it changes
      the attached network.
      Signed-off-by: NMasahide NAKAMURA <nakam@linux-ipv6.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1e5dc146
  21. 11 9月, 2007 1 次提交
    • Y
      [IPv6]: Fix NULL pointer dereference in ip6_flush_pending_frames · e1f52208
      YOSHIFUJI Hideaki 提交于
      Some of skbs in sk->write_queue do not have skb->dst because
      we do not fill skb->dst when we allocate new skb in append_data().
      
      BTW, I think we may not need to (or we should not) increment some stats
      when using corking; if 100 sendmsg() (with MSG_MORE) result in 2 packets,
      how many should we increment?
      
      If 100, we should set skb->dst for every queued skbs.
      
      If 1 (or 2 (*)), we increment the stats for the first queued skb and
      we should just skip incrementing OutDiscards for the rest of queued skbs,
      adn we should also impelement this semantics in other places;
      e.g., we should increment other stats just once, not 100 times.
      
      *: depends on the place we are discarding the datagram.
      
      I guess should just increment by 1 (or 2).
      Signed-off-by: NYOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e1f52208
  22. 22 8月, 2007 1 次提交
    • W
      [IPV6]: Fix kernel panic while send SCTP data with IP fragments · 8984e41d
      Wei Yongjun 提交于
      If ICMP6 message with "Packet Too Big" is received after send SCTP DATA,
      kernel panic will occur when SCTP DATA is send again.
      
      This is because of a bad dest address when call to skb_copy_bits().
      
      The messages sequence is like this:
      
      Endpoint A                             Endpoint B
                                     <-------  SCTP DATA (size=1432)
      ICMP6 message ------->
      (Packet Too Big pmtu=1280)
                                     <-------  Resend SCTP DATA (size=1432)
      ------------kernel panic---------------
      
       printing eip:
      c05be62a
      *pde = 00000000
      Oops: 0002 [#1]
      SMP
      Modules linked in: scomm l2cap bluetooth ipv6 dm_mirror dm_mod video output sbs battery lp floppy sg i2c_piix4 i2c_core pcnet32 mii button ac parport_pc parport ide_cd cdrom serio_raw mptspi mptscsih mptbase scsi_transport_spi sd_mod scsi_mod ext3 jbd ehci_hcd ohci_hcd uhci_hcd
      CPU:    0
      EIP:    0060:[<c05be62a>]    Not tainted VLI
      EFLAGS: 00010282   (2.6.23-rc2 #1)
      EIP is at skb_copy_bits+0x4f/0x1ef
      eax: 000004d0   ebx: ce12a980   ecx: 00000134   edx: cfd5a880
      esi: c8246858   edi: 00000000   ebp: c0759b14   esp: c0759adc
      ds: 007b   es: 007b   fs: 00d8  gs: 0000  ss: 0068
      Process swapper (pid: 0, ti=c0759000 task=c06d0340 task.ti=c0713000)
      Stack: c0759b88 c0405867 ce12a980 c8bff838 c789c084 00000000 00000028 cfd5a880
             d09f1890 000005dc 0000007b ce12a980 cfd5a880 c8bff838 c0759b88 d09bc521
             000004d0 fffff96c 00000200 00000100 c0759b50 cfd5a880 00000246 c0759bd4
      Call Trace:
       [<c0405e1d>] show_trace_log_lvl+0x1a/0x2f
       [<c0405ecd>] show_stack_log_lvl+0x9b/0xa3
       [<c040608d>] show_registers+0x1b8/0x289
       [<c0406271>] die+0x113/0x246
       [<c0625dbc>] do_page_fault+0x4ad/0x57e
       [<c0624642>] error_code+0x72/0x78
       [<d09bc521>] ip6_output+0x8e5/0xab2 [ipv6]
       [<d09bcec1>] ip6_xmit+0x2ea/0x3a3 [ipv6]
       [<d0a3f2ca>] sctp_v6_xmit+0x248/0x253 [sctp]
       [<d0a3c934>] sctp_packet_transmit+0x53f/0x5ae [sctp]
       [<d0a34bf8>] sctp_outq_flush+0x555/0x587 [sctp]
       [<d0a34d3c>] sctp_retransmit+0xf8/0x10f [sctp]
       [<d0a3d183>] sctp_icmp_frag_needed+0x57/0x5b [sctp]
       [<d0a3ece2>] sctp_v6_err+0xcd/0x148 [sctp]
       [<d09cf1ce>] icmpv6_notify+0xe6/0x167 [ipv6]
       [<d09d009a>] icmpv6_rcv+0x7d7/0x849 [ipv6]
       [<d09be240>] ip6_input+0x1dc/0x310 [ipv6]
       [<d09be965>] ipv6_rcv+0x294/0x2df [ipv6]
       [<c05c3789>] netif_receive_skb+0x2d2/0x335
       [<c05c5733>] process_backlog+0x7f/0xd0
       [<c05c58f6>] net_rx_action+0x96/0x17e
       [<c042e722>] __do_softirq+0x64/0xcd
       [<c0406f37>] do_softirq+0x5c/0xac
       =======================
      Code: 00 00 29 ca 89 d0 2b 45 e0 89 55 ec 85 c0 7e 35 39 45 08 8b 55 e4 0f 4e 45 08 8b 75 e0 8b 7d dc 89 c1 c1 e9 02 03 b2 a0 00 00 00 <f3> a5 89 c1 83 e1 03 74 02 f3 a4 29 45 08 0f 84 7b 01 00 00 01
      EIP: [<c05be62a>] skb_copy_bits+0x4f/0x1ef SS:ESP 0068:c0759adc
      Kernel panic - not syncing: Fatal exception in interrupt
      
      Arnaldo says:
      ====================
      Thanks! I'm to blame for this one, problem was introduced in:
      
      b0e380b1
      
      @@ -761,7 +762,7 @@ slow_path:
                      /*
                       *      Copy a block of the IP datagram.
                       */
      -               if (skb_copy_bits(skb, ptr, frag->h.raw, len))
      +               if (skb_copy_bits(skb, ptr, skb_transport_header(skb),
      len))
                              BUG();
                      left -= len;
      ====================
      Signed-off-by: NWei Yongjun <yjwei@cn.fujitsu.com>
      Acked-by: NYOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
      Signed-off-by: NArnaldo Carvalho de Melo <acme@ghostprotocols.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8984e41d
  23. 11 7月, 2007 2 次提交
    • J
      [NETFILTER]: x_tables: add TRACE target · ba9dda3a
      Jozsef Kadlecsik 提交于
      The TRACE target can be used to follow IP and IPv6 packets through
      the ruleset.
      Signed-off-by: NJozsef Kadlecsik <kadlec@blackhole.kfki.hu>
      Signed-off-by: NPatrick NcHardy <kaber@trash.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ba9dda3a
    • M
      [IPV6] MIP6: Loadable module support for MIPv6. · 59fbb3a6
      Masahide NAKAMURA 提交于
      This patch makes MIPv6 loadable module named "mip6".
      
      Here is a modprobe.conf(5) example to load it automatically
      when user application uses XFRM state for MIPv6:
      
      alias xfrm-type-10-43 mip6
      alias xfrm-type-10-60 mip6
      
      Some MIPv6 feature is not included by this modular, however,
      it should not be affected to other features like either IPsec
      or IPv6 with and without the patch.
      We may discuss XFRM, MH (RAW socket) and ancillary data/sockopt
      separately for future work.
      
      Loadable features:
      * MH receiving check (to send ICMP error back)
      * RO header parsing and building (i.e. RH2 and HAO in DSTOPTS)
      * XFRM policy/state database handling for RO
      
      These are NOT covered as loadable:
      * Home Address flags and its rule on source address selection
      * XFRM sub policy (depends on its own kernel option)
      * XFRM functions to receive RO as IPv6 extension header
      * MH sending/receiving through raw socket if user application
        opens it (since raw socket allows to do so)
      * RH2 sending as ancillary data
      * RH2 operation with setsockopt(2)
      Signed-off-by: NMasahide NAKAMURA <nakam@linux-ipv6.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      59fbb3a6
  24. 11 5月, 2007 1 次提交
  25. 26 4月, 2007 3 次提交