I've now done a lot more investigating and I'm pretty sure this is a problem in usb_modeswitch. If I knew how to modify this bug report to point the finger at usb_modeswitch rather than network-manager I would do so, but I can't see an obvious way to do so. Perhaps someone more familiar with Launchpad could do so for me. Thanks.
From my investigations I believe that this is what is supposed to happen when the mobile broadband dongle is pugged in:
A: udev finds a matching rule in /lib/udev/rules.d/40-usb_modeswitch.rules (the rule matches based on key-value pairs for idVendor and idProduct and specifies the assignment pair RUN+="usb_modeswitch '%b/%k'")
B: that causes udev to run the shell script lib/udev/usb_modeswitch
C: the shell script execs the executable /usr/sbin/usb_modeswitch_dispatcher
D: the executable consults information somewhere (in older versions of usb_modeswitch it was a collection of files in /etc/usb_modeswitch.d, but now I believe it is a single tar file somewhere) to determine the usb_modeswitch options required to switch the dongle out of usb storage mode
E: the executable invokes /usr/sbin/usb_modeswitch with the appropriate options
F: /usr/sbin/usb_modeswitch switches the dongle out of usb storage mode
G: udev finds matching rules in /lib/udev/rules.d/40-usb_modeswitch.rules for the new device (i.e. the dongle switched out of usb storage mode); these rules specify the assignment pairs PROGRAM="usb_modeswitch --symlink-name %p %s{idVendor} %s{idProduct} %E{PRODUCT}", SYMLINK="%c" and RUN+="usb_modeswitch --driver-bind %p %s{idVendor} %s{idProduct} %E{PRODUCT}"
H: that causes udev to run the shell script /lib/udev/usb_modeswitch
I: the shell script loads the option driver (using modprobe) if it not already loaded and adds the dongle to the devices managed by the option driver (by writing the vendor id and product id to /sys/bus/usb-serial/drivers/option1/new_id)
In practice that's not what is happening. Either D or E is not happening correctly with the result that steps F to I are not occurring.
My original workaround did the equivalent of I and E manually. In the course of my further investigations I discovered that only E needed to be done. Once the dongle is switched manually out of usb storage mode, steps G to I automatically occur successfully.
I have now come up with a new workaround based on a udev rules file that effectively bypasses steps B, C and D (i.e. it bypasses usb_modeswitch_dispatcher which I strongly suspect to be the culprit here). With this workaround in place my K3520-Z now switches mode automatically when plugged in.
Anyone who has been paying close attention might well be wondering "But if all that is the case, how come the K3770 works?" The answer seems to be that something other than usb_modeswitch is switching it out of usb storage mode, but I have yet to deduce what is doing it. It is, however, certainly the case that even though steps A to F are not occurring for the K3770 it is switching modes such that steps G to I are then occurring.
Over the course of the next day or so I shall post further comments that provide the supporting evidence for various of the above assertions and that present my new workaround.
I've now done a lot more investigating and I'm pretty sure this is a problem in usb_modeswitch. If I knew how to modify this bug report to point the finger at usb_modeswitch rather than network-manager I would do so, but I can't see an obvious way to do so. Perhaps someone more familiar with Launchpad could do so for me. Thanks.
From my investigations I believe that this is what is supposed to happen when the mobile broadband dongle is pugged in: rules.d/ 40-usb_ modeswitch. rules (the rule matches based on key-value pairs for idVendor and idProduct and specifies the assignment pair RUN+="usb_ modeswitch '%b/%k'") usb_modeswitch usb_modeswitch_ dispatcher modeswitch. d, but now I believe it is a single tar file somewhere) to determine the usb_modeswitch options required to switch the dongle out of usb storage mode usb_modeswitch with the appropriate options usb_modeswitch switches the dongle out of usb storage mode rules.d/ 40-usb_ modeswitch. rules for the new device (i.e. the dongle switched out of usb storage mode); these rules specify the assignment pairs PROGRAM= "usb_modeswitch --symlink-name %p %s{idVendor} %s{idProduct} %E{PRODUCT}", SYMLINK="%c" and RUN+="usb_ modeswitch --driver-bind %p %s{idVendor} %s{idProduct} %E{PRODUCT}" usb_modeswitch usb-serial/ drivers/ option1/ new_id)
A: udev finds a matching rule in /lib/udev/
B: that causes udev to run the shell script lib/udev/
C: the shell script execs the executable /usr/sbin/
D: the executable consults information somewhere (in older versions of usb_modeswitch it was a collection of files in /etc/usb_
E: the executable invokes /usr/sbin/
F: /usr/sbin/
G: udev finds matching rules in /lib/udev/
H: that causes udev to run the shell script /lib/udev/
I: the shell script loads the option driver (using modprobe) if it not already loaded and adds the dongle to the devices managed by the option driver (by writing the vendor id and product id to /sys/bus/
In practice that's not what is happening. Either D or E is not happening correctly with the result that steps F to I are not occurring.
My original workaround did the equivalent of I and E manually. In the course of my further investigations I discovered that only E needed to be done. Once the dongle is switched manually out of usb storage mode, steps G to I automatically occur successfully.
I have now come up with a new workaround based on a udev rules file that effectively bypasses steps B, C and D (i.e. it bypasses usb_modeswitch_ dispatcher which I strongly suspect to be the culprit here). With this workaround in place my K3520-Z now switches mode automatically when plugged in.
Anyone who has been paying close attention might well be wondering "But if all that is the case, how come the K3770 works?" The answer seems to be that something other than usb_modeswitch is switching it out of usb storage mode, but I have yet to deduce what is doing it. It is, however, certainly the case that even though steps A to F are not occurring for the K3770 it is switching modes such that steps G to I are then occurring.
Over the course of the next day or so I shall post further comments that provide the supporting evidence for various of the above assertions and that present my new workaround.