Hi, I just found that the patch "kill-pg.patch" breaks net-dialup/umtsmon. That package starts pppd as a child process with the 'updetach' option. After connection establishment, pppd exits immediately with message "Modem hangup". (Here, tested with connection to a USB modem device): [...] Nov 8 13:03:05 x pppd[27514]: rcvd [IPCP ConfReq id=0x5d] Nov 8 13:03:05 x pppd[27514]: sent [IPCP ConfAck id=0x5d] Nov 8 13:03:05 x pppd[27514]: local IP address 10.199.159.137 Nov 8 13:03:05 x pppd[27514]: remote IP address 10.64.64.64 Nov 8 13:03:05 x pppd[27514]: primary DNS address 193.254.160.1 Nov 8 13:03:05 x pppd[27514]: secondary DNS address 10.74.83.22 Nov 8 13:03:05 x pppd[27517]: Script /etc/ppp/ip-up started (pid 27518) Nov 8 13:03:05 x pppd[27517]: Modem hangup Nov 8 13:03:05 x pppd[27517]: Connect time 0.0 minutes. Nov 8 13:03:05 x pppd[27517]: Sent 0 bytes, received 0 bytes. Nov 8 13:03:05 x pppd[27517]: Connection terminated. [...] ppp-2.4.4-r25 without the kill-pg.patch works fine. I am not into the details of this patch, however, having a pppd in gentoo that breaks packages which work fine on other distros does not look good. Is there a way to fix this KDE-related issue rpeorted in 181145 without breaking "standard" ppp behaviour?
(In reply to comment #0) > ppp-2.4.4-r25 without the kill-pg.patch works fine. This should read "ppp-2.4.4-r24" - sorry for confusion.
kill-pg.patch fixes a pppd bug, it isn't a workaround for some faulty client (if you read bug 181145 carefully, you will understand the problem). Apparently umtsmon is not designed to cope with "updetach" pppd option. I have no idea why, but pppd definitely is not killed because of this patch - all it does is setting a new process group at pppd startup. Please investigate why umtsmon kills the pppd process (group).
> Apparently umtsmon is not designed to cope with "updetach" pppd option. I have > no idea why, but pppd definitely is not killed because of this patch Maybe this was not clear enough: umtsmon does *not* kill pppd. pppd (wrongly) reports a modem hangup and exits on its own. This behaviour *only* appears with the patch for bug 181145, it does *not* occur without that patch. The new process group setting with the patch probably has the side effect that when pppd is started by forking off pppd as a child process in detached mode, then for some reason pppd can no longer read its input, and subsequently reports a "modem hangup" and then exits. So I ran exactly into the problem that R. Müller indicated in discussion of 181145: the patch changes the default behaviour of pppd. It took me about two days to find that this is neither a problem with my modem device, nor with umtsmon, nor with pppd itself, but it's caused by exactly this patch. > kill-pg.patch fixes a pppd bug, it isn't a workaround for some faulty client If this is a bug with pppd, why it did not go into official pppd sources? I understood that the reason is exactly that the patch changes the documented standard behaviour of pppd. If pppd development does not consider this a bug, I suggest to remove patches from the Gentoo pppd package that break co-operation with other applications that rely on standard behaviour of pppd. So...I see the following ways to solve this: a) remove the patch, fix KDE-related problem outside pppd package, or b) re-design the patch so that it does not change standard behaviour (probably not possible), or c) introduce a USE flag for that patch, and disable the flag by default; whoever needs the non-standard pppd behaviour can still enable the flag.
Please don't make me repeat myself. Read all my comments in that bug and come with pertinent opinions. I would gladly submit kill-pg patch to upstream, but PPP upstream is dead (at least bug tracking page at ppp.samba.org is). Do the following test: capture pppd command line used by umtsmon (hint: ps -ef f | grep pppd), run it on a terminal and see if you get the same behaviour. Then repeat the test but with a command line trimmed of "updetach" and "nodetach".
(In reply to comment #4) > Do the following test: capture pppd command line used by umtsmon (hint: ps -ef > f | grep pppd), run it on a terminal and see if you get the same behaviour. > Then repeat the test but with a command line trimmed of "updetach" and > "nodetach". This is exactly what I did to find this bug. On the terminal, there is no difference. The side effect of the patch appears *only* when pppd is forked off as a child process. I've attached a small program (run-pppd-as-detached-child.c) that starts pppd in the same way as umtsmon: - fork parent process - child process exec's pppd with updetach option ---> with patch, pppd exits immediately with "modem hangup" ---> without patch, pppd runs as exepected. Please try the code with a PPP connection of your choice.
Created attachment 210310 [details] small program showing erroneous behaviour of patched pppd
You're right! For a reason that escapes me, read_packet() returns 0 (EOF) immediately after connection negotiation. I've redesigned kill-pg patch in revision 2.4.4-r25, now kill_my_pg() will act differently if detach() hasn't been called yet. Instead of killing the entire process group, it will kill all its known children. Conceptually is not as good as the previous solution (it will not kill the children's children), but I don't know how to fix this strange EOF side effect. If you have a better solution, please attach here your patch. Closed as FIXED.
Thanks for the patched patch :-) I switched to 2.4.4-r25; that version now works fine also with umtsmon.
