1. 01 2月, 2008 1 次提交
  2. 29 1月, 2008 2 次提交
  3. 07 11月, 2007 1 次提交
  4. 24 10月, 2007 1 次提交
  5. 22 10月, 2007 1 次提交
  6. 16 10月, 2007 1 次提交
  7. 11 10月, 2007 3 次提交
    • G
      [DCCP]: Twice the wrong reset code in receiving connection-Requests · 4a5409a5
      Gerrit Renker 提交于
      This fixes two bugs in processing of connection-Requests in
      v{4,6}_conn_request:
      
       1. Due to using the variable `reset_code', the Reset code generated
          internally by dccp_parse_options() is overwritten with the
          initialised value ("Too Busy") of reset_code, which is not what is
          intended.
      
       2. When receiving a connection-Request on a multicast or broadcast
          address, no Reset should be generated, to avoid storms of such
          packets. Instead of jumping to the `drop' label, the
          v{4,6}_conn_request functions now return 0. Below is why in my
          understanding this is correct:
      
          When the conn_request function returns < 0, then the caller,
          dccp_rcv_state_process(), returns 1. In all instances where
          dccp_rcv_state_process is called (dccp_v4_do_rcv, dccp_v6_do_rcv,
          and dccp_child_process), a return value of != 0 from
          dccp_rcv_state_process() means that a Reset is generated.
      
          If on the other hand the conn_request function returns 0, the
          packet is discarded and no Reset is generated.
      
      Note: There may be a related problem when sending the Response, due to
      the following.
      
      	if (dccp_v6_send_response(sk, req, NULL))
      		goto drop_and_free;
      	/* ... */
      	drop_and_free:
      		return -1;
      
      In this case, if send_response fails due to transmission errors, the
      next thing that is generated is a Reset with a code "Too Busy". I
      haven't been able to conjure up such a condition, but it might be good
      to change the behaviour here also (not done by this patch).
      Signed-off-by: NGerrit Renker <gerrit@erg.abdn.ac.uk>
      Signed-off-by: NIan McDonald <ian.mcdonald@jandi.co.nz>
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4a5409a5
    • G
      [DCCP]: Factor out common code for generating Resets · e356d37a
      Gerrit Renker 提交于
      This factors code common to dccp_v{4,6}_ctl_send_reset into a separate function,
      and adds support for filling in the Data 1 ... Data 3 fields from RFC 4340, 5.6.
      
      It is useful to have this separate, since the following Reset codes will always
      be generated from the control socket rather than via dccp_send_reset:
       * Code 3, "No Connection", cf. 8.3.1;
       * Code 4, "Packet Error" (identification for Data 1 added);
       * Code 5, "Option Error" (identification for Data 1..3 added, will be used later);
       * Code 6, "Mandatory Error" (same as Option Error);
       * Code 7, "Connection Refused" (what on Earth is the difference to "No Connection"?);
       * Code 8, "Bad Service Code";
       * Code 9, "Too Busy";
       * Code 10, "Bad Init Cookie" (not used).
      
      Code 0 is not recommended by the RFC, the following codes would be used in
      dccp_send_reset() instead, since they all relate to an established DCCP connection:
       * Code 1, "Closed";
       * Code 2, "Aborted";
       * Code 11, "Aggression Penalty" (12.3).
      Signed-off-by: NGerrit Renker <gerrit@erg.abdn.ac.uk>
      Signed-off-by: NArnaldo Carvalho de Melo <acme@ghostprotocols.net>
      e356d37a
    • G
      [DCCP]: Sequence number wrap-around when sending reset · 9bf55cda
      Gerrit Renker 提交于
      This replaces normal addition with mod-48 addition so that sequence number
      wraparound is respected.
      Signed-off-by: NGerrit Renker <gerrit@erg.abdn.ac.uk>
      Signed-off-by: NIan McDonald <ian.mcdonald@jandi.co.nz>
      Signed-off-by: NArnaldo Carvalho de Melo <acme@ghostprotocols.net>
      9bf55cda
  8. 11 7月, 2007 1 次提交
  9. 25 5月, 2007 1 次提交
    • D
      [XFRM]: Allow packet drops during larval state resolution. · 14e50e57
      David S. Miller 提交于
      The current IPSEC rule resolution behavior we have does not work for a
      lot of people, even though technically it's an improvement from the
      -EAGAIN buisness we had before.
      
      Right now we'll block until the key manager resolves the route.  That
      works for simple cases, but many folks would rather packets get
      silently dropped until the key manager resolves the IPSEC rules.
      
      We can't tell these folks to "set the socket non-blocking" because
      they don't have control over the non-block setting of things like the
      sockets used to resolve DNS deep inside of the resolver libraries in
      libc.
      
      With that in mind I coded up the patch below with some help from
      Herbert Xu which provides packet-drop behavior during larval state
      resolution, controllable via sysctl and off by default.
      
      This lays the framework to either:
      
      1) Make this default at some point or...
      
      2) Move this logic into xfrm{4,6}_policy.c and implement the
         ARP-like resolution queue we've all been dreaming of.
         The idea would be to queue packets to the policy, then
         once the larval state is resolved by the key manager we
         re-resolve the route and push the packets out.  The
         packets would timeout if the rule didn't get resolved
         in a certain amount of time.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      14e50e57
  10. 26 4月, 2007 2 次提交
  11. 11 2月, 2007 1 次提交
  12. 09 2月, 2007 1 次提交
  13. 12 12月, 2006 1 次提交
  14. 03 12月, 2006 17 次提交
  15. 22 11月, 2006 1 次提交
  16. 25 10月, 2006 1 次提交
  17. 22 10月, 2006 2 次提交
    • D
      [DCCP] ipv6: Fix opt_skb leak. · fd169f15
      David S. Miller 提交于
      Based upon a patch from Jesper Juhl.  Try to match the
      TCP IPv6 code this was copied from as much as possible,
      so that it's easy to see where to add the ipv6 pktoptions
      support code.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      fd169f15
    • G
      [DCCP]: Fix Oops in DCCPv6 · 82709531
      Gerrit Renker 提交于
      I think I got the cause for the Oops observed in
      http://www.mail-archive.com/dccp@vger.kernel.org/msg00578.html
      
      The problem is always with applications listening on PF_INET6 sockets. Apart
      from the mentioned oops, I observed another one one, triggered at irregular
      intervals via timer interrupt:
      
          run_timer_softirq -> dccp_keepalive_timer
                            -> inet_csk_reqsk_queue_prune
                            -> reqsk_free
                            -> dccp_v6_reqsk_destructor
      
      The latter function is the problem and is also the last function to be called
      in said kernel panic.
      
      In any case, there is a real problem with allocating the right request_sock
      which is what this patch tackles.
      
      It fixes the following problem:
       - application listens on PF_INET6
       - DCCPv4 packet comes in, is handed over to dccp_v4_do_rcv, from there
         to dccp_v4_conn_request
      
      Now: socket is PF_INET6, packet is IPv4. The following code then furnishes the
      connection with IPv6 - request_sock operations:
      
         req = reqsk_alloc(sk->sk_prot->rsk_prot);
      
      The first problem is that all further incoming packets will get a Reset since
      the connection can not be looked up.
      
      The second problem is worse:
       --> reqsk_alloc is called instead of inet6_reqsk_alloc
       --> consequently inet6_rsk_offset is never set (dangling pointer)
       --> the request_sock_ops are nevertheless still dccp6_request_ops
       --> destructor is called via reqsk_free
       --> dccp_v6_reqsk_destructor tries to free random memory location (inet6_rsk_offset not set)
       --> panic
      
      I have tested this for a while, DCCP sockets are now handled correctly in all
      three scenarios (v4/v6 only/v4-mapped).
      
      Commiter note: I've added the dccp_request_sock_ops forward declaration to keep
                     the tree building and to reduce the size of the patch for 2.6.19,
                     later I'll move the functions to the top of the affected source
                     code to match what we have in the TCP counterpart, where this
                     problem hasn't existed in the first place, dumb me not to have
                     done the same thing on DCCP land 8)
      Signed-off-by: NGerrit Renker <gerrit@erg.abdn.ac.uk>
      Signed-off-by: NArnaldo Carvalho de Melo <acme@mandriva.com>
      82709531
  18. 12 10月, 2006 1 次提交
  19. 23 9月, 2006 1 次提交