accel-ppp-xebd.git/accel-pppd/ctrl/l2tp, branch 1.10

remove trailing whitespaces

2014-11-22T05:56:40+00:00

triton: improved epoll events handling

2014-05-12T09:50:15+00:00

l2tp: don't disconnect immediately when receiving StopCCN

2014-04-11T02:47:58+00:00

Wait for a full retransmission cycle after reception of a StopCCN. Introduce STATE_FIN_WAIT to identify tunnels which have received a StopCCN but are waiting for the disconnection timer to expire. A tunnel can go from STATE_FIN (i.e. StopCCN has been sent, waiting for acknowledgement) to STATE_FIN_WAIT (i.e. StopCCN has been received, waiting for full retransmission cycle), but not the other way around. Signed-off-by: Guillaume Nault

l2tp: improve configuration of retransmission options

2014-04-11T02:47:58+00:00

* Set default retransmission timeout to 1 second. Since we now have exponential backoff, we can afford a smaller value. * Add the rtimeout-cap option to set the maximum value the retransmission timer has to respect during exponential backoff. * Store the maximun number of retransmissions in tunnel's structure (like other retransmission parameters). * Describe all these changes in man page and reset them to their default values if they're removed from configuration file before a reload. Signed-off-by: Guillaume Nault

l2tp: implement exponential backoff (retransmit)

2014-04-11T02:47:58+00:00

Rework the l2tp_rtimeout() callback, so that time between retransmissions expands exponentially. This allows for faster retransmissions without without overwhelming the peer. A cap is set on the maximum retransmission time. For now it is set to 16 seconds. Signed-off-by: Guillaume Nault

l2tp: allow CDN reception with no Session ID

2014-04-11T02:47:58+00:00

If a peer needs to disconnect a session for which it didn't receive any reply, it sends a CDN with no Session ID. In this case, the Assigned Session ID AVP is the only data that can be used to find out which session has to be closed. Though it isn't supported for now, let's accept and ack these messages. Session will be deleted on our side thanks to the establishment timer. Signed-off-by: Guillaume Nault

l2tp: configure receive window in accel-ppp.conf

2014-04-11T02:47:42+00:00

Add the recv-window option in accel-ppp.conf. Signed-off-by: Guillaume Nault

l2tp: implement local receive window

2014-04-11T02:47:42+00:00

Add a fixed length receive queue to tunnels and adverdise its length to the peer using the Receive Window Size AVP. Incoming message handling is modified as follow: -Read as much messages as possible and store them in the receive queue. Messages are stored in order, based on their sequence number. Messages not fitting into the queue are discarded (doesn't happen if peer respects our Receive Window AVP). This is the job of the new l2tp_tunnel_store_msg() function. It also automatically finds out if there are new messages to acknowledge. -Once all incoming messages have been read, free acknowledged packets from retransmission queue (based on the highest received acknowledgement number). -Then process messages in the receive queue. This is done by l2tp_tunnel_reply(). Each packet is processed by l2tp_{tunnel,session}_recv() (or dropped in some particular cases). The send queue is then pushed. If there's no message in the send queue and an acknowledgement is necessary, a ZLB is sent instead. -Finally, detect if the peer has acknowledged a StopCCN. There are three components to this test: -Have we tried to send a StopCCN? Check with tunnel's state. -Has the StopCCN been pushed on the network? Check with tunnel's send queue. -Has the peer acknowledged the StopCCN? Check with tunnel's retransmission queue. For now, l2tp_tunnel_store_msg() doesn't perform fast retransmissions. So l2tp_retransmit() is removed. Signed-off-by: Guillaume Nault

l2tp: rework error handling in l2tp_tunnel_alloc

2014-04-11T02:47:42+00:00

Use stacked error labels for better extensibility. Signed-off-by: Guillaume Nault

l2tp: don't initiate new sessions when sending window is full

2014-04-11T02:47:42+00:00

Refuse to create new sessions when the local send queue is bigger than the peer's receive window (i.e. when there are already more outstanding messages than what the peer can currently accept). Only sessions initiated locally are affected, session requests from the peer are still handled normally. This avoids adding useless presure on the sending window when many sessions are created locally. If sessions were created, they'd add many ICRQ or OCRQ messages in the send queue and we'd have to wait for all these messages to be sent before being able to reply to messages from the peer. Signed-off-by: Guillaume Nault