1. 07 3月, 2014 1 次提交
    • G
      l2tp: fix manual sequencing (de)activation in L2TPv2 · bb5016ea
      Guillaume Nault 提交于
      Commit e0d4435f "l2tp: Update PPP-over-L2TP driver to work over L2TPv3"
      broke the PPPOL2TP_SO_SENDSEQ setsockopt. The L2TP header length was
      previously computed by pppol2tp_l2t_header_len() before each call to
      l2tp_xmit_skb(). Now that header length is retrieved from the hdr_len
      session field, this field must be updated every time the L2TP header
      format is modified, or l2tp_xmit_skb() won't push the right amount of
      data for the L2TP header.
      
      This patch uses l2tp_session_set_header_len() to adjust hdr_len every
      time sequencing is (de)activated from userspace (either by the
      PPPOL2TP_SO_SENDSEQ setsockopt or the L2TP_ATTR_SEND_SEQ netlink
      attribute).
      Signed-off-by: NGuillaume Nault <g.nault@alphalink.fr>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      bb5016ea
  2. 14 1月, 2014 1 次提交
  3. 20 10月, 2013 1 次提交
  4. 03 10月, 2013 1 次提交
    • F
      l2tp: fix kernel panic when using IPv4-mapped IPv6 addresses · e18503f4
      François Cachereul 提交于
      IPv4 mapped addresses cause kernel panic.
      The patch juste check whether the IPv6 address is an IPv4 mapped
      address. If so, use IPv4 API instead of IPv6.
      
      [  940.026915] general protection fault: 0000 [#1]
      [  940.026915] Modules linked in: l2tp_ppp l2tp_netlink l2tp_core pppox ppp_generic slhc loop psmouse
      [  940.026915] CPU: 0 PID: 3184 Comm: memcheck-amd64- Not tainted 3.11.0+ #1
      [  940.026915] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2007
      [  940.026915] task: ffff880007130e20 ti: ffff88000737e000 task.ti: ffff88000737e000
      [  940.026915] RIP: 0010:[<ffffffff81333780>]  [<ffffffff81333780>] ip6_xmit+0x276/0x326
      [  940.026915] RSP: 0018:ffff88000737fd28  EFLAGS: 00010286
      [  940.026915] RAX: c748521a75ceff48 RBX: ffff880000c30800 RCX: 0000000000000000
      [  940.026915] RDX: ffff88000075cc4e RSI: 0000000000000028 RDI: ffff8800060e5a40
      [  940.026915] RBP: ffff8800060e5a40 R08: 0000000000000000 R09: ffff88000075cc90
      [  940.026915] R10: 0000000000000000 R11: 0000000000000000 R12: ffff88000737fda0
      [  940.026915] R13: 0000000000000000 R14: 0000000000002000 R15: ffff880005d3b580
      [  940.026915] FS:  00007f163dc5e800(0000) GS:ffffffff81623000(0000) knlGS:0000000000000000
      [  940.026915] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [  940.026915] CR2: 00000004032dc940 CR3: 0000000005c25000 CR4: 00000000000006f0
      [  940.026915] Stack:
      [  940.026915]  ffff88000075cc4e ffffffff81694e90 ffff880000c30b38 0000000000000020
      [  940.026915]  11000000523c4bac ffff88000737fdb4 0000000000000000 ffff880000c30800
      [  940.026915]  ffff880005d3b580 ffff880000c30b38 ffff8800060e5a40 0000000000000020
      [  940.026915] Call Trace:
      [  940.026915]  [<ffffffff81356cc3>] ? inet6_csk_xmit+0xa4/0xc4
      [  940.026915]  [<ffffffffa0038535>] ? l2tp_xmit_skb+0x503/0x55a [l2tp_core]
      [  940.026915]  [<ffffffff812b8d3b>] ? pskb_expand_head+0x161/0x214
      [  940.026915]  [<ffffffffa003e91d>] ? pppol2tp_xmit+0xf2/0x143 [l2tp_ppp]
      [  940.026915]  [<ffffffffa00292e0>] ? ppp_channel_push+0x36/0x8b [ppp_generic]
      [  940.026915]  [<ffffffffa00293fe>] ? ppp_write+0xaf/0xc5 [ppp_generic]
      [  940.026915]  [<ffffffff8110ead4>] ? vfs_write+0xa2/0x106
      [  940.026915]  [<ffffffff8110edd6>] ? SyS_write+0x56/0x8a
      [  940.026915]  [<ffffffff81378ac0>] ? system_call_fastpath+0x16/0x1b
      [  940.026915] Code: 00 49 8b 8f d8 00 00 00 66 83 7c 11 02 00 74 60 49
      8b 47 58 48 83 e0 fe 48 8b 80 18 01 00 00 48 85 c0 74 13 48 8b 80 78 02
      00 00 <48> ff 40 28 41 8b 57 68 48 01 50 30 48 8b 54 24 08 49 c7 c1 51
      [  940.026915] RIP  [<ffffffff81333780>] ip6_xmit+0x276/0x326
      [  940.026915]  RSP <ffff88000737fd28>
      [  940.057945] ---[ end trace be8aba9a61c8b7f3 ]---
      [  940.058583] Kernel panic - not syncing: Fatal exception in interrupt
      Signed-off-by: NFrançois CACHEREUL <f.cachereul@alphalink.fr>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e18503f4
  5. 03 7月, 2013 2 次提交
    • J
      l2tp: make datapath resilient to packet loss when sequence numbers enabled · a0dbd822
      James Chapman 提交于
      If L2TP data sequence numbers are enabled and reordering is not
      enabled, data reception stops if a packet is lost since the kernel
      waits for a sequence number that is never resent. (When reordering is
      enabled, data reception restarts when the reorder timeout expires.) If
      no reorder timeout is set, we should count the number of in-sequence
      packets after the out-of-sequence (OOS) condition is detected, and reset
      sequence number state after a number of such packets are received.
      
      For now, the number of in-sequence packets while in OOS state which
      cause the sequence number state to be reset is hard-coded to 5. This
      could be configurable later.
      Signed-off-by: NJames Chapman <jchapman@katalix.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a0dbd822
    • J
      l2tp: make datapath sequence number support RFC-compliant · 8a1631d5
      James Chapman 提交于
      The L2TP datapath is not currently RFC-compliant when sequence numbers
      are used in L2TP data packets. According to the L2TP RFC, any received
      sequence number NR greater than or equal to the next expected NR is
      acceptable, where the "greater than or equal to" test is determined by
      the NR wrap point. This differs for L2TPv2 and L2TPv3, so add state in
      the session context to hold the max NR value and the NR window size in
      order to do the acceptable sequence number value check. These might be
      configurable later, but for now we derive it from the tunnel L2TP
      version, which determines the sequence number field size.
      Signed-off-by: NJames Chapman <jchapman@katalix.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8a1631d5
  6. 21 3月, 2013 4 次提交
  7. 06 2月, 2013 1 次提交
  8. 30 1月, 2013 1 次提交
    • T
      l2tp: prevent l2tp_tunnel_delete racing with userspace close · 80d84ef3
      Tom Parkin 提交于
      If a tunnel socket is created by userspace, l2tp hooks the socket destructor
      in order to clean up resources if userspace closes the socket or crashes.  It
      also caches a pointer to the struct sock for use in the data path and in the
      netlink interface.
      
      While it is safe to use the cached sock pointer in the data path, where the
      skb references keep the socket alive, it is not safe to use it elsewhere as
      such access introduces a race with userspace closing the socket.  In
      particular, l2tp_tunnel_delete is prone to oopsing if a multithreaded
      userspace application closes a socket at the same time as sending a netlink
      delete command for the tunnel.
      
      This patch fixes this oops by forcing l2tp_tunnel_delete to explicitly look up
      a tunnel socket held by userspace using sockfd_lookup().
      Signed-off-by: NTom Parkin <tparkin@katalix.com>
      Signed-off-by: NJames Chapman <jchapman@katalix.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      80d84ef3
  9. 31 8月, 2012 1 次提交
  10. 17 5月, 2012 1 次提交
  11. 11 5月, 2012 1 次提交
    • J
      l2tp: fix reorder timeout recovery · 38d40b3f
      James Chapman 提交于
      When L2TP data packet reordering is enabled, packets are held in a
      queue while waiting for out-of-sequence packets. If a packet gets
      lost, packets will be held until the reorder timeout expires, when we
      are supposed to then advance to the sequence number of the next packet
      but we don't currently do so. As a result, the data channel is stuck
      because we are waiting for a packet that will never arrive - all
      packets age out and none are passed.
      
      The fix is to add a flag to the session context, which is set when the
      reorder timeout expires and tells the receive code to reset the next
      expected sequence number to that of the next packet in the queue.
      
      Tested in a production L2TP network with Starent and Nortel L2TP gear.
      Signed-off-by: NJames Chapman <jchapman@katalix.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      38d40b3f
  12. 01 5月, 2012 2 次提交
  13. 16 4月, 2012 1 次提交
  14. 25 10月, 2010 1 次提交
  15. 04 4月, 2010 8 次提交