USB device disabled after dial failure

[Rick Jones <rick activeservice co uk>]

Using NM 0.7.1, I'm often getting a problem where NM disables the USB device if the dial-up fails. This means the dongle has to be unplugged and re-plugged to try again. Given the time these things take to initialise it's a bit of a pain :(

The log says what it's doing:

Jun 12 11:40:07 dad NetworkManager: <debug> [1244803207.802978] nm_serial_debug(): Sending: 'ATD*99***1# ' 
Jun 12 11:40:39 dad NetworkManager: <WARN>  dial_done(): Dialing timed out 
Jun 12 11:40:39 dad NetworkManager: <info>  (ttyUSB1): device state change: 4 -> 9 
Jun 12 11:40:39 dad NetworkManager: <debug> [1244803239.005096] nm_serial_device_close(): Closing device 'ttyUSB1' 
Jun 12 11:40:39 dad NetworkManager: <info>  Marking connection '3' invalid. 
Jun 12 11:40:39 dad NetworkManager: <info>  Activation (ttyUSB1) failed. 
Jun 12 11:40:39 dad NetworkManager: <info>  (ttyUSB1): device state change: 9 -> 3 
Jun 12 11:40:39 dad NetworkManager: <info>  (ttyUSB1): deactivating device (reason: 0). 
Jun 12 11:40:39 dad NetworkManager: <info>  Policy set 'Auto eth0' (eth0) as default for routing and DNS. 
Jun 12 11:40:39 dad NetworkManager: nm_system_device_flush_ip4_routes_with_iface: assertion `iface_idx >= 0' failed
Jun 12 11:40:39 dad NetworkManager: nm_system_device_flush_ip4_addresses_with_iface: assertion `iface_idx >= 0' failed
Jun 12 11:40:39 dad NetworkManager: <info>  (ttyUSB0): now unmanaged 
Jun 12 11:40:39 dad NetworkManager: <info>  (ttyUSB0): device state change: 3 -> 1 
Jun 12 11:40:39 dad NetworkManager: <info>  (ttyUSB0): cleaning up... 
Jun 12 11:40:39 dad NetworkManager: <info>  (ttyUSB0): taking down device. 
Jun 12 11:40:39 dad NetworkManager: <info>  (ttyUSB1): now unmanaged 
Jun 12 11:40:39 dad NetworkManager: <info>  (ttyUSB1): device state change: 3 -> 1 
Jun 12 11:40:39 dad NetworkManager: <info>  (ttyUSB1): cleaning up... 
Jun 12 11:40:39 dad NetworkManager: <info>  (ttyUSB1): taking down device. 

I suspect the flush-routes assertion is actually the trigger, but I don't see why it should assert.

After this the USB port is actually in an invalid state. E.g. If you run lsusb it hangs until the device is unplugged.

Rick Jones