Multilink PPP dies on LCP reconfigure

All:

I'm trying to install a pair of T1s using Multilink PPP to connect my
RH 9 + Sangoma Wanpipe firewall/router to my ISP's Cisco 12016/GRP
running v12.0 of (I assume) IOS.

The PPP sessions all establish just fine, but anywhere from thirty seconds
to ten minutes from the initial connect, and occurring fairly frequently
thereafter, the Cisco starts sending LCP ConfReqs with a new magic number.

Unfortunately, this ends up killing the ppp daemon:

Nov 4 08:17:56 rhad-new ppp_debug: rcvd [LCP ConfReq id=0x4b <magic 0xe23a8f46> <mrru 1500> <endpoint [local:73.6c.2d.67.77.35.2d.74.61.63]>]
Nov 4 08:17:56 rhad-new ppp_debug: Script /etc/ppp/ip-down started (pid 27171)
Nov 4 08:17:56 rhad-new ppp_debug: sent [LCP ConfReq id=0x2 <asyncmap 0x0> <magic 0x583b2b6> <mrru 1500> <endpoint [MAC:00:02:a5:8a:35:64]>]
Nov 4 08:17:56 rhad-new ppp_debug: sent [LCP ConfAck id=0x4b <magic 0xe23a8f46> <mrru 1500> <endpoint [local:73.6c.2d.67.77.35.2d.74.61.63]>]
Nov 4 08:17:56 rhad-new ppp_debug: rcvd [LCP ConfAck id=0x1 <asyncmap 0x0> <magic 0x7191a1c5> <mrru 1500> <endpoint [MAC:00:02:a5:8a:35:64]>]
Nov 4 08:17:56 rhad-new ppp_debug: rcvd [LCP ConfAck id=0x1 <asyncmap 0x0> <magic 0x7191a1c5> <mrru 1500> <endpoint [MAC:00:02:a5:8a:35:64]>]
Nov 4 08:17:56 rhad-new ppp_debug: Script /etc/ppp/ip-down finished (pid 27171), status = 0x0
Nov 4 08:17:58 rhad-new ppp_debug: rcvd [LCP ConfReq id=0x4c <magic 0xe23a8f46> <mrru 1500> <endpoint [local:73.6c.2d.67.77.35.2d.74.61.63]>]
Nov 4 08:17:58 rhad-new ppp_debug: sent [LCP ConfAck id=0x4c <magic 0xe23a8f46> <mrru 1500> <endpoint [local:73.6c.2d.67.77.35.2d.74.61.63]>]
Nov 4 08:17:59 rhad-new ppp_debug: sent [LCP ConfReq id=0x2 <asyncmap 0x0> <magic 0x583b2b6> <mrru 1500> <endpoint [MAC:00:02:a5:8a:35:64]>]
Nov 4 08:18:00 rhad-new ppp_debug: rcvd [LCP ConfReq id=0x4d <magic 0xe23a8f46> <mrru 1500> <endpoint [local:73.6c.2d.67.77.35.2d.74.61.63]>]
Nov 4 08:18:00 rhad-new ppp_debug: sent [LCP ConfAck id=0x4d <magic 0xe23a8f46> <mrru 1500> <endpoint [local:73.6c.2d.67.77.35.2d.74.61.63]>]
Nov 4 08:18:02 rhad-new ppp_debug: sent [LCP ConfReq id=0x2 <asyncmap 0x0> <magic 0x583b2b6> <mrru 1500> <endpoint [MAC:00:02:a5:8a:35:64]>]
Nov 4 08:18:02 rhad-new ppp_debug: rcvd [LCP ConfReq id=0x4e <magic 0xe23a8f46> <mrru 1500> <endpoint [local:73.6c.2d.67.77.35.2d.74.61.63]>]
Nov 4 08:18:02 rhad-new ppp_debug: sent [LCP ConfAck id=0x4e <magic 0xe23a8f46> <mrru 1500> <endpoint [local:73.6c.2d.67.77.35.2d.74.61.63]>]
Nov 4 08:18:04 rhad-new ppp_debug: rcvd [IPCP ConfReq id=0x36 <addr
x.x.x.x>]
Nov 4 08:18:05 rhad-new ppp_debug: sent [LCP ConfReq id=0x2 <asyncmap 0x0> <magic 0x583b2b6> <mrru 1500> <endpoint [MAC:00:02:a5:8a:35:64]>]
Nov 4 08:18:05 rhad-new ppp_debug: rcvd [LCP ConfReq id=0x4f <magic 0xe23ab33a> <mrru 1500> <endpoint [local:73.6c.2d.67.77.35.2d.74.61.63]>]
Nov 4 08:18:05 rhad-new ppp_debug: sent [LCP ConfAck id=0x4f <magic 0xe23ab33a> <mrru 1500> <endpoint [local:73.6c.2d.67.77.35.2d.74.61.63]>]
Nov 4 08:18:05 rhad-new pppd[27149]: Couldn't attach to interface unit 0: Inappropriate ioctl for device
Nov 4 08:18:05 rhad-new ppp_debug: rcvd [LCP ConfAck id=0x2 <asyncmap 0x0> <magic 0x583b2b6> <mrru 1500> <endpoint [MAC:00:02:a5:8a:35:64]>]
Nov 4 08:18:05 rhad-new ppp_debug: Couldn't attach to interface unit 0: Inappropriate ioctl for device
Nov 4 08:18:06 rhad-new pppd[27149]: Exit.

If I turn off multilink, then the daemon successfully reconfigures and
reestablishes the ppp0 interface.

Can anybody provide some insight as to why this is happening?

Versions and such:

Redhat Linux 9.0
2.4.20-31.9smp kernel from the fedoralegacy site
ppp-2.4.1-10
Sangoma Wanpipe S514-7-PCI dual T1/E1 card
WANPIPE Hardware Support Module Stable 2.3.1-2

http://bugzilla.fedora.us/show_bug.cgi?id=2229

Thanks for any help.

--
John Hardin KA7OHZ <(E-Mail Removed)>
Internal Systems Administrator voice: (425) 672-1304
Apropos Retail Management Systems, Inc. fax: (425) 672-0192
-----------------------------------------------------------------------
If you smash a computer to bits with a mallet, that appears to count
as encryption in the state of Nevada.
- CRYPTO-GRAM 12/2001
-----------------------------------------------------------------------