Project

General

Profile

Bug #186

pluto hangs when system changes and command "ipsec statusall" commands executed at same time.

Added by ujjal raj over 13 years ago. Updated over 13 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Tobias Brunner
Category:
-
Target version:
4.6.3
Start date:
22.03.2012
Due date:
Estimated time:
Affected version:
4.5.3
Resolution:
Fixed

Description

Problem description :
1) Set up the connection with ikev1 (pluto) .Tunnel will be established properly (system time is Jan 01 2012)
2) Now change the system time to Jan 01 2011 . Pluto will reinititate the connection properly.
3) At the same time execute the ipsec statusall command .

Repeated the step 2 continuously with an interval of 10 sec. (i.e change from Jan 01 2012 to Jan 01 2011 and vice versa)

Pluto hangs and there is no response and also logs are not logged. Then after some time it resumes normally.

Please help me regarding this.

0001-pluto-Use-time_monotonic-instead-of-a-custom-impleme.patch (875 Bytes) 0001-pluto-Use-time_monotonic-instead-of-a-custom-impleme.patch Tobias Brunner, 22.03.2012 14:12

History

#1 Updated by ujjal raj over 13 years ago

Here is the ps output which shows the process list of ipsec 

root        500 S   /usr/lib/ipsec/starter
  root       1896 R   /usr/lib/ipsec/pluto --nofork --debug-none
 root        240 S   _pluto_adns
 root       1800 S   /usr/lib/ipsec/charon --use-syslog --debug-dmn 1 --de
root        552 S   sh -c /usr/sbin/ipsec status
root        648 S   /bin/sh /usr/sbin/ipsec status
root        496 S   /usr/lib/ipsec/whack --status
root        348 S   sleep 5
root        636 R   ps

#2 Updated by Tobias Brunner over 13 years ago

Not sure what exactly causes it to hang but I don't think pluto was ever intended for a situation like this.

Unfortunately, pluto does not use CLOCK_MONOTONIC to get the system wide monotonic time stamp, but instead implements something similar itself with calls to time() and keeping track of the values returned last. This can easily get messy.

Let's assume the current date is "Sun, Jan 1 01:01:00 UTC 2012", time() will return 1325379660. This is stored and now you set the date back to "Sat, Jan 1 01:01:00 UTC 2011", the next time pluto checks the time, time() will return something around 1293843660. The difference is about 31536000 seconds which is what pluto reports in the log message (the exact time will vary as pluto does not constantly check the time).

You'll see a message like

"pluto[450]: time moved backwards 31537759 seconds"
in the logs.

Pluto now stores this difference as delta (actually it adds it to a static variable) and returns current + delta = 1325379660 (i.e. about the first time stamp, thus it is seemingly monotonic). If you now set the time back to "Sun, Jan 1 01:01:00 UTC 2012" i.e. the time stamp is again around 1325379660, pluto now adds the same delta to this value. That is, the time stamp returned is now 1356915660 (Mon, Dec 31 01:01:00 UTC 2013).

If you do this repeatedly the time stamp will jump ahead in years and finally the delta value, which is of type time_t, will overflow and get negative, which means the time stamp returned is now way in the past. I suppose this causes some serious problems when calculating scheduling times and other stuff (like the times in the output of ipsec statusall).

We could try to replace the current implementation of the now() function in source:src/pluto/timer.c with a call to time_monotonic() defined in libstrongswan (see source:src/libstrongswan/utils.h#L420).

Could you please try if the attached patch fixes this.

#3 Updated by Tobias Brunner over 13 years ago

  • Target version set to 4.6.3

#4 Updated by Tobias Brunner over 13 years ago

  • Status changed from Feedback to Closed
  • Resolution set to Fixed