Sothere *is* an usb-storage function here. Thus it is possible that the detection is based on the usb-storage driver attaching to this interface. It is quite possible that the firmware assumes an OS will see this as either an MBIM device or a storage device. I could be wrong, but I believe that is what Windows will do? So do try to blacklist the usb-storage driver.
If that works then we have to figure out some way to make that happen automatically for just this device. Might require a quirk in the storage driver, unless someone has a better idea? But let's see how the testing goes first..
no matter what was in the menuconfig... it had a swing and a miss with the ath9k driver.. didn't read the eprom on both radio0 and radio1..
I will try reverting to the suggested revision see how it accepts the new scripts...
I haven't but pepe2k has figured out that it is a timing problem from using Lua for the script. He will rewrite it in C since Lua doesn't have exactly what is needed in this case. This has something to do with the x86 architecture I think.
All phones use the same drivers, RNDIS or Ethernet. There are no drivers specific to any phone.
Once it is detected and the drivers attach it should continue to work unless the provider is doing something.
bought a HAME mpr-A2 2 weeks ago and got stuck with the factory FW cause my HUAWEI E3276 (german speedstick LTE III) wouldnt work with it. No connection.
Had a research and finally found this great forum. With the help of you guys esp.
"hungdl" (terrific tip with program ) and of course "dairyman" I managed it to the Huntsman.red 2014-01-25.
Runs like hell !!
Now Im quite curious about the funnelweb for the HAME cause Id like to try it as a media server as well with a SSD connected to the USB-port. May I ask about the status for development.
Awsome, thank you for the explanation. I already had an idea of some of them but i was a little confused as to what the * meant and also what would happen if a modem did have all 3. I guess they are displayed in order of how the router is accessing them?
openwrt devs might say the scripts are causing it.... Reason the unbrick firmware didn't have them.. Will revert the svn to see at least for the 40mhs of 2.4.....will continue looking at it another problem is the gpio pins......
I have no idea at this stage....basically what it is and does would be a good start.
I am getting some inside tips from a company as to what gear they will use and what languages they will run etc. So as of a few days ago this is all new to me but i really want to learn it as it could mean a new job for me.
Its already been developed and I have been running it and it works well.
However it will only be released when Dairyman is ready to release the next firmware update (im not too sure how far along that is).
If you hunt through these pages back a month or so you will find the beta version for a 703n 8mb flash router. I will have to look if he has included this on the later release of the 4mb flash mr3420 router which was also posted but im not sure if he managed to squeeze it in.
What modeswitch does for most modems is, in a different way, tell the modem what configuration to use. Most modems have a storage configuration and a modem configuration and modeswitch forces it into modem configuration.
It seems today my brain need more flash ram. I have that many things on the "GO" that i feel mentally overloaded. Respawn. One can only learn so much.
See i need to move from Jack of all traded to a master of 1 or 2.
I have a problem with the "openwrt-wr1043nd-v1-HM2014-01-25red.bin". The wifi scheduled on/off function isn't working properly. The router switches off the radio at the off time, but at the on time the wifi module remains decativated. In this case i need to reboot the rooter for the normal state.
What happens if you change the "Allow Medium Removal" message into "Prevent Medium Removal", ie the first message in a Standard Eject and with the prevent bit set in the message. Don't send the 2nd message, the "Eject"
You should do this on a router which doesn't have the usb_storage driver installed so we can be sure that nothing accesses the virtual cd-rom and cancels the prevent by sending an allow.
Will that stop the device from auto switching, will it now remain in initial 19d2:1257 mode forever?
Yup.... at the risk of going a little offtopic.... those of us on 3G have the long standing problem of not having unlimited download capabilities. This really sucks if you want to download anything big....
And these little routers are so flexible.. .that you can set one up as download client. So if you have a friend that has DSL or cable... you just hook it to his router.. plug in a usb data stick.. .and get your downloads without eating up all your 3G :)
The download client uses an OpenWRT package called "Transmission" So you would need to convert from original TP-link. Apparently it is a very flexible package that you can remotely control over the net.
Yea.. your method is alot more invasive...and requires a computer always on. Easy enough if it is a family member with the DSL connection.... not so easy if you are borrowing a "friends" bandwidth. :)
No, not really. The later cdc-ether attachment is to a "new device" appearing after mode switching. This device has a new identity and might have completely different configurations (and likely has). The cdc-ether driver will not attach to a ff/ff/ff function.
The 3rd configuration you see before this mode switch is something different, and could be RNDIS. Or just a debug serial function. Or something else. It's vendor specific, so we do not know until someone has tested it.
Yes, it could be qmi but that would be very strange. This cfg won't be used by default, so any "legacy" system would have to switch cfg to make it work. And if that's how it is supposed to work, what's then the point of the storage mode switching and the automatic mode switching?
And the last one here caught my interest. It uses the 68a2 product ID which is shared by many QMI Sierra devices, but the vendor ID was new to me. Searching tells me that this is a Netgear vendor ID, which makes sense. But I guess we should add that to the driver as well.
BTW, if you want a good laugh then take a look at the GobiNetDriverLteRxFixup function in the GobiNet/GobiUSBNet.c file, and compare it to the qmi_wwan_rx_fixup function in qmi_wwan.c. The verbatim copy of the comment in front of the function makes it extra fun. I wrote that comment to remember why the heck I wrote something as strange looking as that myself :-)
It's nice to see that Qualcomm/Sierra/Netgear can make use of some of the code I write. But if I were working for any of these companies then I would have seen it as quite a defeat to have to copy a workaround for bugs in my own firmware.... How about just fixing the firmware instead?
Yes it is (he says confidently) :-}
This is an eval sample so we can expect that they wanted to test it with various firmware versions. There are no serial interfaces for diag/re-flash in mbim mode, nor in cdc_ether mode or in rndis mode. Makes much sense then to include them under an own config.
We should probably not pay too much attention about the dongles auto switch behaviour, the other 2 K-xxx vodafone dongles from ZTE did not have the problem with falling out of mbim mode as far as I remember.
How about them skipping their vendor-specific version of linux qmi drivers and instead contributed work to the linux general qmi drivers?
I like their hardware but their software engineers must be smoking some strange stuff..
Initially I ran the OpenWRT configuration back-up from my existing client (TL-WA701ND) to configure the TL-WR741ND, but it did not work out of the box. Whilst it did the basics, I think it screwed something up. Probably a pretty foolish thing to do. :(
just checking but i may have found the culprit... timing............. scripts are 88 in a straight openwrt same file 20 confused i hope is all........... maybe just doesn't like them all together.... copied them in ok...........
hotplug call was a little different too.....
I will ask what they smoke and see how they respond. Actually the lead driver guy is very into Linux and going open would be "Cool" but there is always business pressures that mean any change like this is not likely to happen quickly.
It would be pretty good to get the ball rolling here, we all know linux /open source is the future (If not already the present....the way android is going). Maybe ZTE can be the first to make the leap.
Hi SD,
that comment of mine was actually for Sierra but I will take you up on your kind offer of passing over questions to ZTE now that you have confirmed there is someone at ZTE caring for the linux platform.
Yes, but there were some very interesting parts around that as well. Surprising to me was the fact that Windows *does* load a driver for the storage function and actually talks storage commands with the modem after switching it to cfg #2.
3a8082e126