Timo Ter�s writes:I tracked down the reason: since the PPP link is between PC and remote computer, the mobile phone does not send any PPP packets that the link is dead. Instead it just sends '\r\nNO CARRIER\r\n'. And leaves the Bluetooth connection in AT command mode. Thus PPP stays happily up.
Why doesn't it de-assert DCD (Data Carrier Detect) and thus cause pppd to receive SIGHUP as expected?
In my opinion, we shouldn't really go too far out of our way to make fatally compromised interfaces work "right."
Actually this is a very good question. I now finally solved this bug. It appears that BlueZ correctly translates/transports the carrier detect signal from my mobile. However it does not call tty_hangup() when the carrier detect is de-asserted. I managed to get this working perfectly well by adding one if () and tty_hangup() call to net/bluetooth/rfcomm/tty.c.
So this is actually a BlueZ emulation bug. I'll post bug report / simple patch to appropriate list asap.
Thanks, Timo - To unsubscribe from this list: send the line "unsubscribe linux-ppp" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
