ppp
ppp copied to clipboard
ppp-project
PPPd crashes with fatal signal 6 on 2.4.7 version
PPPd crashes with fatal signal 6 on 2.4.7 version soon after receiving a CHAP challenge request from the server. Corefile is not generated as this is packaged on a cisco device. Issue is only seen when using CHAP authentication.
pppd[4459]: Fatal signal 6
Version 2.4.7 is nearly 10 years old, and if this is packaged on a cisco device then the source may have been modified by Cisco.
If you can reproduce with the current source or with unmodified version 2.5.0, then we can take a look at it, otherwise we will need to reject this issue.
Cisco is using unmodified 2.4.7 code base. This is packaged on cisco sdwan device. The server used here is Mikrotik router and the cisco device is the ppp client. On disabling the mschap1 and mschap2 authentication and having just PAP and CHAP authentication enabled on the Mikrotik router (PPP server) resolves the issue and pppoe session is being formed with the server. On re-enabling the mschap1 and mschap2 also resolves the issue. I'm not sure if the issue is with the server or the client. im not aware of the pppd version used on the server. Could this be an inter-operability issue? Can you suggest how i can debug this issue?
Cisco is using unmodified 2.4.7 code base. This is packaged on cisco sdwan device. The server used here is Mikrotik router and the cisco device is the ppp client. On disabling the mschap1 and mschap2 authentication and having just PAP and CHAP authentication enabled on the Mikrotik router (PPP server) resolves the issue and pppoe session is being formed with the server. On re-enabling the mschap1 and mschap2 also resolves the issue. I'm not sure if the issue is with the server or the client. im not aware of the pppd version used on the server. Could this be an inter-operability issue? Can you suggest how i can debug this issue?
Ideally you would run pppd under gdb on the cisco device and get a backtrace when it crashes. I have no idea what the OS on the cisco device would provide, or how much access it allows. If you're able to modify the source, compile it and run it on the cisco device, then you could put code in bad_signal() to inspect the siginfo_t that gets passed to it (you would need to change its argument list) and at least print PC or whatever so you could work out where exactly it was hitting the signal.
Signal 6 on most architectures is SIGABRT. If that's what it is on whatever architecture the cisco device uses, then you could investigate possible sources of a SIGABRT. It seems like the abort() function sends a SIGABRT to the process, and apparently some C library implementations will call it if they encounter an internal error, hopefully after printing some sort of informative error message. Or there could be some other process on the cisco device sending pppd the SIGABRT signal.
I'd say close this issue. I don't think it make much sense to provide support for 2.4.7. They should upgrade to the latest release or run the latest code-base from mainline.
