uhhu,
Thanks, again, for the log. It shows that the ozerocdoff should have occurred -- at least that the rule for the 7401 must have run. Did you see a /tmp/ozerocdoff.log file?
For the ttyHS3 issue, let's try brute force. In the script, /etc/init.d/Hso that I provided you in the PMed dotpet (not for anyone else!), change line 44, to replace only the word, "break", with:
APP_PORT="/sys/class/tty/ttyHS3"
I see on the pharscape (option modem support) forum that ttyHS3 is what to use for a ppp connection, which is what we are doing. My only concern is whether that is true for all Option HSDPA modems.
Be sure to wait a few minutes before concluding the test and capturing the log, in case it takes a while for the modem to switch in response to the ozerocdoff.
Richard
Integration of 3G Wireless Modem Detection - 4.1.2 & 4.2.1
No /tmp/ozerocdoff.log file. However, I guessed that I could force ozerocdoff to run by removing thererwin wrote:It shows that the ozerocdoff should have occurred -- at least that the rule for the 7401 must have run. Did you see a /tmp/ozerocdoff.log file?
Code: Select all
ATTRS{idProduct}=="7401",Code: Select all
/usr/sbin/ozerocdoff -wi 0x -l /tmp/ozerocdoff.log
ERROR: Device ID missing.EDIT: Actually, it must be caused by running the script at the wrong time when the device is not ready.
I then changed the 0x%s{idProduct} to 0x7401 and got the following log file entry (twice):
Code: Select all
/usr/sbin/ozerocdoff -wi 0x7401 -l /tmp/ozerocdoff.log
ERROR: No Zero-CD device found.If I run ozerocdoff manually after startup, pupdial modem probe can now find the modem at port /dev/ttyHS3.For the ttyHS3 issue, let's try brute force. In the script, /etc/init.d/Hso that I provided you in the PMed dotpet (not for anyone else!), change line 44, to replace only the word, "break", with:
APP_PORT="/sys/class/tty/ttyHS3"
uhhu,
Apparently, although the device is detected, generating the uevent and triggering loading of driver hso, the device delays in identifying itself as a storage device -- it seems ready by the time you enter the same command.
With the other modems and usb_modeswitch, I introduced delays, which seem to have made those modems work. I need to look into doing that for the HSDPA modems, I expect. That may take a little time, so I cannot have you holding your customer's computer while I figure that out.
I may be in "over my head" without even knowing it. There may be more to add (that the GPRS option apparently does) to get it working. Thanks for all your help (and many hours) with this.
Richard
AFTERTOUGHT:
Richard
Good work! That is cosistent with the script's not seeing the ttyHS name, too.ERROR: No Zero-CD device found.
Apparently, although the device is detected, generating the uevent and triggering loading of driver hso, the device delays in identifying itself as a storage device -- it seems ready by the time you enter the same command.
With the other modems and usb_modeswitch, I introduced delays, which seem to have made those modems work. I need to look into doing that for the HSDPA modems, I expect. That may take a little time, so I cannot have you holding your customer's computer while I figure that out.
I may be in "over my head" without even knowing it. There may be more to add (that the GPRS option apparently does) to get it working. Thanks for all your help (and many hours) with this.
Richard
AFTERTOUGHT:
This implies that the product ID is not present in the uevent! How can that be? To verify this, you could edit the /etc/udev/rules.d/51-hso.rules file (from the debug dotpet) to list the product ID in one of the trace rules. In line 16, just ahead of the "_GOTO" part, insert "_P%s{idProduct}" (without the quotes). I expect the log to show "_P__" if the value is really missing. If true, what to make of it? Thanks./usr/sbin/ozerocdoff -wi 0x -l /tmp/ozerocdoff.log
Richard
For BarryK,
Hi Barry, I noticed on the link you posted you said your modem had not been activated yet. I don't know if this applies to all USB modems or just particular ISP's, but on my Sprint 598U ( made by Sierra Wireless) when I went to the Sierra website to get instructions to set the modem up in Linux it said I had to activate the unit in Windows before trying to set it up to use in Linux. This may be the case with your's as well. Anyway hope this helps and I'm lovin 4.2.1.
Hi Barry, I noticed on the link you posted you said your modem had not been activated yet. I don't know if this applies to all USB modems or just particular ISP's, but on my Sprint 598U ( made by Sierra Wireless) when I went to the Sierra website to get instructions to set the modem up in Linux it said I had to activate the unit in Windows before trying to set it up to use in Linux. This may be the case with your's as well. Anyway hope this helps and I'm lovin 4.2.1.
OK, this is getting odd. I have now verified that on line 16, {idProduct} is 7401. But it either disappears or something is wrong with the syntax of this line:rerwin wrote:AFTERTOUGHT:This implies that the product ID is not present in the uevent! How can that be?/usr/sbin/ozerocdoff -wi 0x -l /tmp/ozerocdoff.log
Code: Select all
ATTRS{idProduct}=="7401", RUN+="/usr/sbin/ozerocdoff -wi 0x%s{idProduct} -l /tmp/ozerocdoff.log"I replaced the "/bin/sh -c ..." on line 16 with "/usr/sbin/ozerocdoff -wi 0x%s{idProduct} -l /tmp/ozerocdoff.log" and ozerocdoff is run successfully. (But now puppy modem probe thinks the modem is at port /dev/ttyHS1.)
There seems to be some new information - at least for me - in the log file that is generated (with the modified line 16 in the hso-rules):
Code: Select all
/sys/class/tty/ttyHS0/hsotype: Diagnostic
/sys/class/tty/ttyHS1/hsotype: Application
/sys/class/tty/ttyHS2/hsotype: Control
/sys/class/tty/ttyHS3/hsotype: Modem- Attachments
-
- udevtrace-modem.log.bz2
- (895 Bytes) Downloaded 329 times
uhhu,
This is getting good! The line:
/sys/class/tty/ttyHS3/hsotype: Modem
is just what I was hoping for. Those lines are from the initialization script, confirming that I should make it look for that line instead of the Application line. I can now fix the ttyHS3 problem!
The rest of the log shows several lines I did not expect, especially one containing "ATTR" instead of the usual "ATTRS". Since it's an easy thing to try, edit the original line for the "7401" and change the ATTRS to ATTR. Gotta at least rule that out.
I have updated the debug dotpet and will PM it to you. It fixes ttyHS3 and adds more logging from the rules file, to look for valid combinations of attributes to use. The vanishing idProduct is baffling! There has to be a reason somewhere, but I will need to wait until morning (or later), to pursue that.
I hope you can make use of the new dotpet. Thanks.
Richard
This is getting good! The line:
/sys/class/tty/ttyHS3/hsotype: Modem
is just what I was hoping for. Those lines are from the initialization script, confirming that I should make it look for that line instead of the Application line. I can now fix the ttyHS3 problem!
The rest of the log shows several lines I did not expect, especially one containing "ATTR" instead of the usual "ATTRS". Since it's an easy thing to try, edit the original line for the "7401" and change the ATTRS to ATTR. Gotta at least rule that out.
I have updated the debug dotpet and will PM it to you. It fixes ttyHS3 and adds more logging from the rules file, to look for valid combinations of attributes to use. The vanishing idProduct is baffling! There has to be a reason somewhere, but I will need to wait until morning (or later), to pursue that.
I hope you can make use of the new dotpet. Thanks.
Richard
The cause of the vanishing idProduct is this line in block LABEL="hso_zerocd_disabler":
I commented it out and now everything works: ozerocdoff runs successfully and pupdial modem probe finds the modem at port /dev/ttyHS3.
BTW, according to the /tmp/ozerocdoff.log file, ozerocdoff is run four times at startup:
The modem and computer will be picked up in a few hours. So this is my last test and log file.
Code: Select all
ATTRS{idVendor}!="0af0", GOTO="hso_end"BTW, according to the /tmp/ozerocdoff.log file, ozerocdoff is run four times at startup:
Code: Select all
/usr/sbin/ozerocdoff -wi 0x7401 -l /tmp/ozerocdoff.log
ERROR: No Zero-CD device found
/usr/sbin/ozerocdoff -wi 0x7401 -l /tmp/ozerocdoff.log
Successfully ZERO-CD disabled
/usr/sbin/ozerocdoff -wi 0x7401 -l /tmp/ozerocdoff.log
ERROR: No Zero-CD device found
/usr/sbin/ozerocdoff -wi 0x7401 -l /tmp/ozerocdoff.log
ERROR: No Zero-CD device found- Attachments
-
- udevtrace-modem.log.bz2
- (880 Bytes) Downloaded 326 times
uhhu,
I can't thank you enough for supporting me (and the community) by running those tests of the HS modem and experimenting with fixes. This moves implementation of the HS-modem logic much further than just waiting for me to guess at the correct logic. This last run gives me good information for preparing the HS part of the next 3G-pupdial (-11).
I hope we can work together, again, if you should get access to a wireless modem.
Richard
UPDATE: After examining your log and seeing some lines that shouldn't be there, and taking into account your experience with the line you deleted, I conclude that the "!=" test is not a valid option. It is always true, that is, ignored. That explains why the idProduct tests are never made. I have recoded the hso rules to avoid the "!=" and am including that in 3G-pupdial-11, coming shortly. Thanks for holding my feet to the fire on that issue.
Richard
I can't thank you enough for supporting me (and the community) by running those tests of the HS modem and experimenting with fixes. This moves implementation of the HS-modem logic much further than just waiting for me to guess at the correct logic. This last run gives me good information for preparing the HS part of the next 3G-pupdial (-11).
I hope we can work together, again, if you should get access to a wireless modem.
Richard
UPDATE: After examining your log and seeing some lines that shouldn't be there, and taking into account your experience with the line you deleted, I conclude that the "!=" test is not a valid option. It is always true, that is, ignored. That explains why the idProduct tests are never made. I have recoded the hso rules to avoid the "!=" and am including that in 3G-pupdial-11, coming shortly. Thanks for holding my feet to the fire on that issue.
Richard
Last edited by rerwin on Sat 20 Jun 2009, 14:48, edited 1 time in total.
Stupid mode makes it quicker, otherwise it "waits for prompt" first, but eventually connects.puttingan,
Interesting that you need to use the "-chat" edit. I notice in your wvdial.conf file that you did not check the "Stupid mode" option. Others have reported that stupid mode is essential. So please try that and without the -chat entry. If that doesn't work, please tell me how you arrived at the "-chat" solution. I would like to know how "real" and common that requirement is, so I can consider automating that, too, If I can know when it is needed. Thanks.
The -chap (sorry not chat) comes from installing the modem in ubuntu where someone from their forum correctly stated that this was necessary for connecting to virginbroadband..--it will not connect without this alteration to /etc/ppp/options.
Hello rerwin
Firstly, thanks for this great work you are doing getting 3G support for Puppy.
I have a Huwiei 169 with VirginBroadband in Australia. I downloaded the pupdial pet and the usb_modeswitch pet.I'm running 4.2 on an IBM R31 thinkpad with an onboard modem. I tried to connect with pupdial but I could only see the onboard modem. According to pupscan the module for it is slamr. I didn't see it to blacklist so I couldn't get pupdial to see ttyUSB0.
Ok, no worries, I'll try PGPRS Connect. Put in the APN and phone number, blanked the pin, left the login details as default and it connected second go.
BTW, the modem is dectected on bootup, did an lsmod and "option" is there.
Am posting from said modem now. And it seems very fast, as fast as in Windows.
Thankyou.
Mick
Firstly, thanks for this great work you are doing getting 3G support for Puppy.
I have a Huwiei 169 with VirginBroadband in Australia. I downloaded the pupdial pet and the usb_modeswitch pet.I'm running 4.2 on an IBM R31 thinkpad with an onboard modem. I tried to connect with pupdial but I could only see the onboard modem. According to pupscan the module for it is slamr. I didn't see it to blacklist so I couldn't get pupdial to see ttyUSB0.
Ok, no worries, I'll try PGPRS Connect. Put in the APN and phone number, blanked the pin, left the login details as default and it connected second go.
BTW, the modem is dectected on bootup, did an lsmod and "option" is there.
Am posting from said modem now. And it seems very fast, as fast as in Windows.
Thankyou.
Mick
Puppy Linux Blog - contact me for access
puttingau,
Thanks for the clarification. It sounds like I need to test for that particular provider and insert the "-chap", which means to not use the chap authentication method. Does anyone know of any other providers with this constraint? If so, please let me know; PM is OK.
01micko,
Thanks for your report. My goal is to make it possible to use the USB modem without blacklisting the driver for the built-in modem. I suspect that slamr is not the driver being used.
You can still blacklist slamr even if you don't find it in BootManager's left pane, although it should be there. Just select any module name, add it, click OK. Then, when prompted for arguments, replace the name with "slamr". For built-in SmartLink modems, the driver is actually part of the sound driver. There are several "snd-" modules that handle these modems. But you don't want to disable sound!
As I have mentioned earlier, the option modems are usually hybrid devices that take a little time to get started. I have delayed the initialzation script to give the modem some time, but maybe that is not enough. I would like to work with to to get all that right.
The procedural workaround I have come up with so far, requires a second boot. Leaving GPRS out of the game. boot up fresh with the modem plugged in. Go ahead and go to pupdial for the built-n modem, the do a probe > erase, then reboot. I would hope the USB modem would be found at that time. It it doesn't, please attach (or PM) the /tmp/udevtrace-modem.log file for me to examine. If it does work, you may need to do what puttingau describes, above.
Richard
Thanks for the clarification. It sounds like I need to test for that particular provider and insert the "-chap", which means to not use the chap authentication method. Does anyone know of any other providers with this constraint? If so, please let me know; PM is OK.
01micko,
Thanks for your report. My goal is to make it possible to use the USB modem without blacklisting the driver for the built-in modem. I suspect that slamr is not the driver being used.
You can still blacklist slamr even if you don't find it in BootManager's left pane, although it should be there. Just select any module name, add it, click OK. Then, when prompted for arguments, replace the name with "slamr". For built-in SmartLink modems, the driver is actually part of the sound driver. There are several "snd-" modules that handle these modems. But you don't want to disable sound!
As I have mentioned earlier, the option modems are usually hybrid devices that take a little time to get started. I have delayed the initialzation script to give the modem some time, but maybe that is not enough. I would like to work with to to get all that right.
The procedural workaround I have come up with so far, requires a second boot. Leaving GPRS out of the game. boot up fresh with the modem plugged in. Go ahead and go to pupdial for the built-n modem, the do a probe > erase, then reboot. I would hope the USB modem would be found at that time. It it doesn't, please attach (or PM) the /tmp/udevtrace-modem.log file for me to examine. If it does work, you may need to do what puttingau describes, above.
Richard
3G_pupdial_wireless-11 uploaded for testing
Testers/Users,
As a result of uhhu's extensive testing and experimentation with a high-speed modem, where he identified a problematic udev rule statement, I have recoded the rules to avoid using the "!=" comparison, which appeared to always be true. I did this even though some instances of it seem to work. But since it is not documented in the guide I reference, and find nowhere else supporting it, I fell back to my practice of "follow the rules and avoid trouble".
Dougal has suggested that there are changes to those rules (regarding another factor) that are not yet documented, but I may have already been burned once, and will wait for documentation. Since uhhu can no longer test with the modem he had, could anyone with such a modem, that uses the "hso" driver module, try out the new "-11" 3G-pupdial, to determine whether the mode switch occurs? (The downloads are in the first posting of this thread.)
The new usb_modeswitch 1.0.2 fixes a few bugs and lists a description of the modem it switches, which might be useful for those with modems requiring them to edit one of the modem-specific /etc/udev/rules.d/51-usb_modeswitch rules files identified by the vendor and product IDs that are ambiguous. Currently, the user must choose one of several rules in the file, based on outside knowledge about the modem (such as its model name). With luck, the descriptions might help automatically differentiate among the possibilities. Anyway, that is what the usb_modeswitch developer has in mind. Beyond that, the functionality remains the same as for 0.9.7.
I also hope that by my correcting the "!=" test in the rules files other than those requiring editing (which did not use it), the several cases reported where a built-in modem prevents Puppy from selecting the USB wireless modem might benefit from that correction. Maybe the mode switching was simply not being done, due to the "!=" test. Could those of you having that problem please try again with the new 3G-pupdial and usb_modeswitch (without any blacklisting)? Because the hybrid modems take a while to get recognized and get going, their initialization scripts wait before checking for their presence. I need to know whether that is effective and how long is needed. If a script has to wait, it will report that in the /tmp/udevtrace-modem.log file, on lines beginning with "Script". Please report any such lines. So far, when all is working, no waiting seems to be required.
Although I have also posted these upgrades for Puppy 4.2.1 and Puppy 5, please tell me ASAP if you find any problems with this version. I need more feedback to focus my troubleshooting. While waiting, I may look into dealing with special cases requiring modification of the /etc/ppp/options file that controls some details of connecting. The need for adding a "-chap" line for a particular APN is such a case. Please tell about any such cases that need attention, so I can work out a means of handling them. I hope we are now at the point of "fine tuning" to support some of the unique characteristics of particular modem models.
On an unrelated subject: Does anyone actually need the nozomi driver module, for the oldest of the GlobeTrotter modems? And does it work? I ask this because it appears to be omitted from the Puppy5 series. Does anybody care whether it gets included? If so, I can advocate for its inclusion.
Good news is encouraging, but bad news is cause for action to correct problems. I hope you will continue to provide both. Thank you, all.
Richard
As a result of uhhu's extensive testing and experimentation with a high-speed modem, where he identified a problematic udev rule statement, I have recoded the rules to avoid using the "!=" comparison, which appeared to always be true. I did this even though some instances of it seem to work. But since it is not documented in the guide I reference, and find nowhere else supporting it, I fell back to my practice of "follow the rules and avoid trouble".
Dougal has suggested that there are changes to those rules (regarding another factor) that are not yet documented, but I may have already been burned once, and will wait for documentation. Since uhhu can no longer test with the modem he had, could anyone with such a modem, that uses the "hso" driver module, try out the new "-11" 3G-pupdial, to determine whether the mode switch occurs? (The downloads are in the first posting of this thread.)
The new usb_modeswitch 1.0.2 fixes a few bugs and lists a description of the modem it switches, which might be useful for those with modems requiring them to edit one of the modem-specific /etc/udev/rules.d/51-usb_modeswitch rules files identified by the vendor and product IDs that are ambiguous. Currently, the user must choose one of several rules in the file, based on outside knowledge about the modem (such as its model name). With luck, the descriptions might help automatically differentiate among the possibilities. Anyway, that is what the usb_modeswitch developer has in mind. Beyond that, the functionality remains the same as for 0.9.7.
I also hope that by my correcting the "!=" test in the rules files other than those requiring editing (which did not use it), the several cases reported where a built-in modem prevents Puppy from selecting the USB wireless modem might benefit from that correction. Maybe the mode switching was simply not being done, due to the "!=" test. Could those of you having that problem please try again with the new 3G-pupdial and usb_modeswitch (without any blacklisting)? Because the hybrid modems take a while to get recognized and get going, their initialization scripts wait before checking for their presence. I need to know whether that is effective and how long is needed. If a script has to wait, it will report that in the /tmp/udevtrace-modem.log file, on lines beginning with "Script". Please report any such lines. So far, when all is working, no waiting seems to be required.
Although I have also posted these upgrades for Puppy 4.2.1 and Puppy 5, please tell me ASAP if you find any problems with this version. I need more feedback to focus my troubleshooting. While waiting, I may look into dealing with special cases requiring modification of the /etc/ppp/options file that controls some details of connecting. The need for adding a "-chap" line for a particular APN is such a case. Please tell about any such cases that need attention, so I can work out a means of handling them. I hope we are now at the point of "fine tuning" to support some of the unique characteristics of particular modem models.
On an unrelated subject: Does anyone actually need the nozomi driver module, for the oldest of the GlobeTrotter modems? And does it work? I ask this because it appears to be omitted from the Puppy5 series. Does anybody care whether it gets included? If so, I can advocate for its inclusion.
Good news is encouraging, but bad news is cause for action to correct problems. I hope you will continue to provide both. Thank you, all.
Richard
sony ericsson md300 Comcel-Colombia ( South Am)
Hi:
I am illiterate in linux and I do not speak English, from a few weeks ago I have been trying to migrate to Linux from W-xp. I installed Puppy on the hard drive and I've been trying to understand and learn. My internet connection is through the usb-modem md300 Sony Ericsson. I have not found this model in the content of this thread. Maybe itis the same md400?
I have not tried the attachments to the original post, because I'm browsing from Windows because I have no connection in Puppy. Which files should I install?
Thank you.
Sorry for the mistakes, this is a translation through google.
I am illiterate in linux and I do not speak English, from a few weeks ago I have been trying to migrate to Linux from W-xp. I installed Puppy on the hard drive and I've been trying to understand and learn. My internet connection is through the usb-modem md300 Sony Ericsson. I have not found this model in the content of this thread. Maybe itis the same md400?
I have not tried the attachments to the original post, because I'm browsing from Windows because I have no connection in Puppy. Which files should I install?
Thank you.
Sorry for the mistakes, this is a translation through google.
I add the previous post with the result that the windows tool devcon.exe delivery about the identification device for sony ericsson md300 :
Some help please
g000g1e
The system (Puppy) does not recognize or mount any usb pen drive.USB\VID_0FCE&PID_D0CF\3534460211209670 : SEMC WMC Composite Device
USB\VID_0FCE&PID_D0CF&MI_01\3534460211209670_01 : SEMC Reserved Interface
USB\VID_0FCE&PID_D0CF&MI_02\3534460211209670_02 : Dispositivo de almacenamiento masivo USB
USB\VID_0FCE&PID_D0CF&MI_03\3534460211209670_03 : Sony Ericsson MD300 Wireless Modem
USB\VID_0FCE&PID_D0CF&MI_05\3534460211209670_05 : Sony Ericsson MD300 Mobile Broadband Device Management
USB\VID_0FCE&PID_D0CF&MI_06\3534460211209670_06 : Sony Ericsson MD300 Mobile Broadband Ethernet Control
USB\VID_0FCE&PID_D0CF&MI_07\3534460211209670_07 : Sony Ericsson MD300 Mobile Broadband Command Interface (COM5)
USB\VID_0FCE&PID_D0CF&MI_09\3534460211209670_09 : Sony Ericsson MD300 Mobile Broadband Network Adapter (WDM)
8 matching device(s) found.
Some help please
g000g1e
How to reduce manual steps
I have noticed that this works (a bit different story from what I describe above):zgp152 wrote:This was remedied as I left PIN field empty.
Rgds zgp152
zgp152 wrote:Hi,
Thanks for the help from rerwin and others!
I have partial success in getting to web with Huawei E220.
Now the access sequence sometimes works with pupdial, sometimes not.
The latest finding is that the connection is cut off sometimes.
This is my compact description of the sequence.
Carrier is detected and ppp is started.
However modem hangs up with exit code 16.
I looked at var/log/messages which shows that the last operations were CHAP challenge and response, CHAP succeeded, PPP BSD Compression operations starts, and in the end Protocol-Reject for 'Compression Control Protocol' (0x80fd) is received. This leads to hangup (SIGHUP) and to exit.
When restart of the modem occurs (apparently because of the events as above described) and it sends AT+CPIN=<mycode>, it is regarded as a bad init string and there is no way out of the loop.
The latter one is what the user sees, and an inexperienced person does not know what to do. If I do not have PIN in use in the first place, the configuration exhibits other problems, which I did not write down in enough detail to report them here.
Any advice would be appreciated. This way of getting to network is not robust enough to give into inexperienced hands. I intend to give the pc to an elderly couple for very basic internet use.
Rgds, zgp152
1) Turn power ON, wait until the start screen is opened
2) Start Pupdial
3) Insert PIN
4) Launch dialing
5) Wait until pppdaemon dies (with exit code 16)
6) Click the "disconnect" bar but keep window open
7) Remove PIN
8) Launch dialing (now without PIN)
9) pppd daemon stays alive
10) web browsing may be started
It seems to me that the PIN must be passed only once after power is turned on, and it may remain functional if I reboot with power ON (not quite sure about it, sorry).
Using pupdial this way is still a bit clumsy. As I gave this PC to an elderly couple, I was somewhat disappointed that I could not configure it in any more automated way. In another installation which I first tested everything with internet wizard, I could use scripting so that the connection became transparent requiring no manual operation.
So to questions:
Q1. Have I missed some alternative method that can be script based ?
Q2. Are my pupdial parameter values just in wrong order so that the redundant launching (steps 5 to 8) could be avoided ?
Rgds
zgp152
zgp152,
I have seen reports that the entire PIN thing can be disabled in the modem, under Windows, so that the PIN is not needed under Linux. Is that an option for your customer? Or do they need the security of PIN protection?
Maybe there is a better way to implement the PIN issuance. I cannot get to it immediately, but if I can depend on your testing help, I would like to try setting the PIN information before starting wvdial. If that works, I can rip out the logic about reserving Init1 for the PIN. It would certainly be a better technique.
Richard
I have seen reports that the entire PIN thing can be disabled in the modem, under Windows, so that the PIN is not needed under Linux. Is that an option for your customer? Or do they need the security of PIN protection?
Maybe there is a better way to implement the PIN issuance. I cannot get to it immediately, but if I can depend on your testing help, I would like to try setting the PIN information before starting wvdial. If that works, I can rip out the logic about reserving Init1 for the PIN. It would certainly be a better technique.
Richard
Vodafone K3760
Hi,
So I've just inherited a laptop running Puppy Linux 4.2.1 and have been trying to get the USB modem to work. So far I have installed the latest version of the main package and the hso thingy and have tried using connect through pupdial and am seeing no modem. I edited the modeswitch.conf to uncomment the lines relating to k3760; tried several reboots and can't see a modem. Any ideas? BTW - in case it isn't obvious i'm new to linux though am not new to it/unix etc....
thanks for any pointers / assistance.
Alex
So I've just inherited a laptop running Puppy Linux 4.2.1 and have been trying to get the USB modem to work. So far I have installed the latest version of the main package and the hso thingy and have tried using connect through pupdial and am seeing no modem. I edited the modeswitch.conf to uncomment the lines relating to k3760; tried several reboots and can't see a modem. Any ideas? BTW - in case it isn't obvious i'm new to linux though am not new to it/unix etc....
thanks for any pointers / assistance.
Alex
Magicbus,
Thanks for joining us. You said you installed the hso thingy, but you also need the hso-udev dotpet. The usb_modeswitch.conf file is not used in Puppy, so modifying it has no effect. Besides, any entry there that says a modem is supported by the hso driver indicates that in Puppy it is not handled by usb_modeswitch.
All "hso" modems get supported by the hso driver and hso-udev dotpet that contains the hso equivalent of usb_modeswitch. So, the only dotpets you need are 3G-pupdial, hso and hso-udev. No editing is required. (But having usb_modeswitch installed is not a problem.)
If the modem still does not work after installing the three dotpets, please attach the file /tmp/udevtrace-modem.log to your report, so I can see what's going on. Maybe I still don't have all the rules correct. Thanks for working with me on this.
Richard
Thanks for joining us. You said you installed the hso thingy, but you also need the hso-udev dotpet. The usb_modeswitch.conf file is not used in Puppy, so modifying it has no effect. Besides, any entry there that says a modem is supported by the hso driver indicates that in Puppy it is not handled by usb_modeswitch.
All "hso" modems get supported by the hso driver and hso-udev dotpet that contains the hso equivalent of usb_modeswitch. So, the only dotpets you need are 3G-pupdial, hso and hso-udev. No editing is required. (But having usb_modeswitch installed is not a problem.)
If the modem still does not work after installing the three dotpets, please attach the file /tmp/udevtrace-modem.log to your report, so I can see what's going on. Maybe I still don't have all the rules correct. Thanks for working with me on this.
Richard
Hi there
Can someone kindly tell me which files I need to download/install to be able to use my ZT 626 usb modem?
I read a 'How To' but it appears these files have been 'superseded' and am now at a crossroads to figure out which ones I need.
I have tried:
3G PupDial Wireless-1.1.pet
Option-patched-01April09-k2,6.25.16.pet
Your co-operation would be greatly appreciated.
Regards
BTW I have tried to install all the files and cannot get an error message when using PGRS connect, just tells me to reinstall the packages.
Can someone kindly tell me which files I need to download/install to be able to use my ZT 626 usb modem?
I read a 'How To' but it appears these files have been 'superseded' and am now at a crossroads to figure out which ones I need.
I have tried:
3G PupDial Wireless-1.1.pet
Option-patched-01April09-k2,6.25.16.pet
Your co-operation would be greatly appreciated.
Regards
BTW I have tried to install all the files and cannot get an error message when using PGRS connect, just tells me to reinstall the packages.
chrome307,
Thanks for posting to this thread. You do not mention that you also installed usb-storage-ZTE-patch-k2.6.25.16.pet from the same place you got the patched option package. Also install the usb_modeswitch dotpet. You need both of those, to get things going. One more thing: You need to edit the file: /etc/udev/rules.d/51-usb_modeswitch-option-ZTE-Onda . . . line 15, to remove the initial "#" from the line starting with #SYSSYSTEM==. That should do it, after a reboot. (The edit is necessary because several modems with the same IDs get treated differently, and there is no way, yet, to differentiate these cases.)
Keep in mind that this project thread relates only to the use of PupDial with wireless modems. It is intended to supersede the PGRS option. Any use of the PGRS option may complicate diagnosing any problems, so please avoid it. It is only useful to me if it is the only way a modem will operate, so that I can refer to that experience in attempting to improve the PupDial support of such modems.
Richard
Thanks for posting to this thread. You do not mention that you also installed usb-storage-ZTE-patch-k2.6.25.16.pet from the same place you got the patched option package. Also install the usb_modeswitch dotpet. You need both of those, to get things going. One more thing: You need to edit the file: /etc/udev/rules.d/51-usb_modeswitch-option-ZTE-Onda . . . line 15, to remove the initial "#" from the line starting with #SYSSYSTEM==. That should do it, after a reboot. (The edit is necessary because several modems with the same IDs get treated differently, and there is no way, yet, to differentiate these cases.)
Keep in mind that this project thread relates only to the use of PupDial with wireless modems. It is intended to supersede the PGRS option. Any use of the PGRS option may complicate diagnosing any problems, so please avoid it. It is only useful to me if it is the only way a modem will operate, so that I can refer to that experience in attempting to improve the PupDial support of such modems.
Richard