summaryrefslogtreecommitdiff
path: root/package/ppp/patches/100-debian_close_dev_ppp.patch
diff options
context:
space:
mode:
Diffstat (limited to 'package/ppp/patches/100-debian_close_dev_ppp.patch')
-rw-r--r--package/ppp/patches/100-debian_close_dev_ppp.patch34
1 files changed, 34 insertions, 0 deletions
diff --git a/package/ppp/patches/100-debian_close_dev_ppp.patch b/package/ppp/patches/100-debian_close_dev_ppp.patch
new file mode 100644
index 000000000..4e50118e8
--- /dev/null
+++ b/package/ppp/patches/100-debian_close_dev_ppp.patch
@@ -0,0 +1,34 @@
+From: Simon Peter <dn.tlp@gmx.net>
+Subject: Bug#306261: pppd does not properly close /dev/ppp on persist
+
+When using the kernel PPPoE driver, pppd never
+closes /dev/ppp when the link has come down.
+
+It opens superfluous fds to the device each time it re-opens the
+connection, with the unclosed ones falsely reported always ready for
+data by select().
+
+This makes pppd eat up 100% CPU time after the first persist because of
+the always instantly returning select() on the unclosed fds.
+
+The problem also occurs with the upstream version, but does not occur
+when a pty/tty device is used for the ppp connection.
+
+
+diff -u -r ppp-2.4.3/pppd/sys-linux.c ppp-2.4.3/pppd/sys-linux.c
+--- ppp-2.4.3/pppd/sys-linux.c 2005-04-29 20:08:37.000000000 +0200
++++ ppp-2.4.3/pppd/sys-linux.c 2005-04-29 20:07:03.000000000 +0200
+@@ -455,6 +455,13 @@
+ if (new_style_driver) {
+ int flags;
+
++ /* if a ppp_fd is already open, close it first */
++ if(ppp_fd > 0) {
++ close(ppp_fd);
++ remove_fd(ppp_fd);
++ ppp_fd = -1;
++ }
++
+ /* Open an instance of /dev/ppp and connect the channel to it */
+ if (ioctl(fd, PPPIOCGCHAN, &chindex) == -1) {
+ error("Couldn't get channel number: %m");