I just bought one (E220) on ebay for my IBM lappy....
still have to get the icon225 sorted, though....
Will be seeing the owner of that next week, probably, keep you updated, Rich
Aitch
Integration of 3G Wireless Modem Detection - 4.1.2 & 4.2.1
kultex, Aitch,
Thanks for running the patch3 test, which confirms that a delayed modprobe of option is necessary. I took Aitch's suggestion and reviewed the usb_modeswitch intro page, to determine the extent of the issue.
I conclude that the delayed loading applies to modems that do not change product ID as part of switching. That appears to pertain to the older Huawei modems, which use the "-H 1" parameter with usb_modeswitch. The site also implies that the issue has been resolved in a later kernel, so our new 2.6.29.6-based test puppys should have the correction.
The new logic I propose applies only to the standard 2.6.25.16-kernel puppys, at least until we see how the advanced kernel handles these modems. I have cleaned up the modeswitch script to remove debug code that may have been slowing boot-up by 30 seconds. When the storage part of the device is detected and triggers loading of the usb-storage driver, the script will wait 5 seconds for usb-storage to connect with the device; then wait 1 second before running usbmodeswitch, which itself waits 4 seconds before testing for success; and then modprobe the option driver. That;s a total of 10 seconds between storage-part detection and loading of the modem driver. (If we need to wait longer, increasing the "-s" option in the usb_modeswitch command after the last 'else' in /usb/sbin/usb_modeswitch.sh would extend the delay before loading.)
The attached "patch4" replaces all of the previous three patches, so they should be uninstalled (if possible). Patch4 will work even if the others are not uninstalled. Please try the new patch with the E220 and any other Huawei modem, in puppy 4.1.2 or 4.2.1 (standard kernel) AND in Barry's new 4.3 beta1 with the advanced (2.6.29.6) kernel. Thanks.
Richard
Thanks for running the patch3 test, which confirms that a delayed modprobe of option is necessary. I took Aitch's suggestion and reviewed the usb_modeswitch intro page, to determine the extent of the issue.
I conclude that the delayed loading applies to modems that do not change product ID as part of switching. That appears to pertain to the older Huawei modems, which use the "-H 1" parameter with usb_modeswitch. The site also implies that the issue has been resolved in a later kernel, so our new 2.6.29.6-based test puppys should have the correction.
The new logic I propose applies only to the standard 2.6.25.16-kernel puppys, at least until we see how the advanced kernel handles these modems. I have cleaned up the modeswitch script to remove debug code that may have been slowing boot-up by 30 seconds. When the storage part of the device is detected and triggers loading of the usb-storage driver, the script will wait 5 seconds for usb-storage to connect with the device; then wait 1 second before running usbmodeswitch, which itself waits 4 seconds before testing for success; and then modprobe the option driver. That;s a total of 10 seconds between storage-part detection and loading of the modem driver. (If we need to wait longer, increasing the "-s" option in the usb_modeswitch command after the last 'else' in /usb/sbin/usb_modeswitch.sh would extend the delay before loading.)
The attached "patch4" replaces all of the previous three patches, so they should be uninstalled (if possible). Patch4 will work even if the others are not uninstalled. Please try the new patch with the E220 and any other Huawei modem, in puppy 4.1.2 or 4.2.1 (standard kernel) AND in Barry's new 4.3 beta1 with the advanced (2.6.29.6) kernel. Thanks.
Richard
- Attachments
-
- 3G_pupdial-wireless-11-patch4.pet
- Patch to add PIN correction, move APN to dialup accounts,
load modem driver if both modem and storage drivers selected for loading,
delay loading of driver for some Huawei modems. - (14.84 KiB) Downloaded 263 times
uninstalled all patches, installed patch 4 - still everything perfect
added 2 more files - e220-21 is plugging in at boot and e220-22 is plugging in afterwards.
added 2 more files - e220-21 is plugging in at boot and e220-22 is plugging in afterwards.
- Attachments
-
- huawei-E220-22.tar.gz
- (3.58 KiB) Downloaded 230 times
-
- huawei-E220-21.tar.gz
- (3.35 KiB) Downloaded 246 times
kultex,
This result gives me the green light to put together a package for Barry to add to the beta2 release. Thank you very much for your timely help in testing all these experiments.
Richard
That's music to my ears! Please ignore my request to try this with the new beta1. Barry left out a hotplug/usb piece of the kernel, so we cannot test 3G with it.uninstalled all patches, installed patch 4 - still everything perfect
This result gives me the green light to put together a package for Barry to add to the beta2 release. Thank you very much for your timely help in testing all these experiments.
Richard
kultex,
Thank you for your offer. It has been very rewarding working with you. And I have something more to test.
I am attaching patch5, which is actually patch4 with minor adjustments in preparation for submission to Barry for the 4.3 beta2 and to go into 3G_pupdial-12. I have shortened the wait times slightly and removed some debug options to adjust the times. Now it has 5 seconds for the usb-storage driver to get it together before the mode switch, and four seconds for modeswitch to wait before checking for success and proceeding to modprobe the option driver (because it probably did not see the modem the first time it was modprobed normally). I deleted 3 seconds total.
I need you to try that patch as with patch4, to verify that the modem still works the same. I was generous with the delay times as we were getting started, but now I want to trim out the excess. The main reason is that the initialization script was waiting up to a minute for the driver to get loaded. While the driver apparently loads quickly, if the modem is removed, each boot-up without it will have the script wait the maximum time, which I have now reduced to 15 seconds, compared to the 9 seconds for the modeswitch-modprobe process. That's round-about logic, but there it is.
Thinking ahead to attempting an automated way to determine which ttyUSB number to use, because a few modems apparently use ttyUSB2 instead of the usual ttyUSB0. And there may be other such cases. I have added logging of udev information of several kinds, to see if there is any data that might help. I do this because the hso driver seems to provide a way to determine the ttyHS#, which is already inside the hso initialization script. The logging goes the /tmp/udevtrace-modem.log. so that is the only file I need to see. There may not be anything useful, but I need to rule out that possibility.
I hope a few people with the modems using ttyUSB2 will run thepatch and post the log file. Thanks for any help.
Richard
Thank you for your offer. It has been very rewarding working with you. And I have something more to test.
I am attaching patch5, which is actually patch4 with minor adjustments in preparation for submission to Barry for the 4.3 beta2 and to go into 3G_pupdial-12. I have shortened the wait times slightly and removed some debug options to adjust the times. Now it has 5 seconds for the usb-storage driver to get it together before the mode switch, and four seconds for modeswitch to wait before checking for success and proceeding to modprobe the option driver (because it probably did not see the modem the first time it was modprobed normally). I deleted 3 seconds total.
I need you to try that patch as with patch4, to verify that the modem still works the same. I was generous with the delay times as we were getting started, but now I want to trim out the excess. The main reason is that the initialization script was waiting up to a minute for the driver to get loaded. While the driver apparently loads quickly, if the modem is removed, each boot-up without it will have the script wait the maximum time, which I have now reduced to 15 seconds, compared to the 9 seconds for the modeswitch-modprobe process. That's round-about logic, but there it is.
Thinking ahead to attempting an automated way to determine which ttyUSB number to use, because a few modems apparently use ttyUSB2 instead of the usual ttyUSB0. And there may be other such cases. I have added logging of udev information of several kinds, to see if there is any data that might help. I do this because the hso driver seems to provide a way to determine the ttyHS#, which is already inside the hso initialization script. The logging goes the /tmp/udevtrace-modem.log. so that is the only file I need to see. There may not be anything useful, but I need to rule out that possibility.
I hope a few people with the modems using ttyUSB2 will run thepatch and post the log file. Thanks for any help.
Richard
- Attachments
-
- 3G_pupdial-wireless-11-patch5.pet
- Same as patch5 but with shorter delay times and
some logging of data for use in selecting ttyUSB#. - (16.77 KiB) Downloaded 254 times
uninstalled patch 4, installed patch 5 - still everything perfect and much quicker ....
added 2 more files - e220-31 is plugging in at boot and e220-32 is plugging in afterwards.
added 2 more files - e220-31 is plugging in at boot and e220-32 is plugging in afterwards.
- Attachments
-
- huawei-E220-32.tar.gz
- (3.59 KiB) Downloaded 240 times
-
- huawei-E220-31.tar.gz
- (3.36 KiB) Downloaded 228 times
kultex,
Thanks for the good news! But I am puzzled by the fact that none of my debug info from the initialization script got logged. The installation process should have reset a value to cause the updated script to get placed where it executes.
Could you check the size of /etc/init.d/Option to verify it is "2776 B"? If it is not, try a run after editing a file entry to accomplish that? The file is /etc/modules/firmware.dep.2.6.25.16 (or whatever kernel you are using). There is an entry:
#option:option.ko
Just remove the #, save, reboot.
That should reload the "firmware", which is the script and maybe other files.
But in looking at the script, I suspect something else. It now waits 15 seconds for the driver to load, and exits if it hasn't by then. That is the simplest explanation for the absence of the debug info. You might edit that file to change line 12 from:
WAITMAX=15
to
WAITMAX=60
and check for debug data in /tmp/udevtrace-modem.log.
If the data is still absent, there may be a bigger issue. To be sure the script runs and selects the correct modem (ttyUSB0), please probe>ERASE in PupDial and reboot, to be sure puppy is not re-using the selection from before. If no modem is detected, that tells me that the script did not run or that it timed out waiting for the driver to load.
My expectation is that the line:should cause the driver to be loaded and set up the init script, but that the driver does not recognize the modem because the switching has not completed. The new additional modprobe then reattempts loading, and the driver does find the modem. I assume that the failure to find the modem the first time aborts the loading (but I am unsure of that). Even so, the second modprobe should complete within the 15 seconds.
Perhaps a cleaner test would be to simply make the edit to firmware.dep and delete the init script altogether. That would force re-installation of the script. If no modem is detected, with the modem plugged in at boot, that would mean either the script was not present where needed, or it timed out. Check for the existence of /etc/init.d/Option. I need to know whether the script makes it to /etc/init.d. If it is not, we need a redesign. Enough rambling. Please see what you can find. Thanks.
Richard
UPDATE: I am trying to imagine what might be happening with the modem startup. What if the device issues all of its device identification at once and that the presence of the entries containing icFF does not indicate that the device has switched modes? That should cause the modem driver to be modprobed, but maybe the driver does something special when it finds the modem not actually ready. On the chance that it refuses to load in that situation, maybe the modprobe instruction produces an error or status message. Although I have edited the modprobe in the script that issues it, to send errors to our log file, I may have coded that incorrectly. I have a better way to code that, so you might edit file /sbin/pup_event_backend_modprobe, line 151, to:by changing the "2>>" to ">>" and inserting the "2>&1".
Richard
Thanks for the good news! But I am puzzled by the fact that none of my debug info from the initialization script got logged. The installation process should have reset a value to cause the updated script to get placed where it executes.
Could you check the size of /etc/init.d/Option to verify it is "2776 B"? If it is not, try a run after editing a file entry to accomplish that? The file is /etc/modules/firmware.dep.2.6.25.16 (or whatever kernel you are using). There is an entry:
#option:option.ko
Just remove the #, save, reboot.
That should reload the "firmware", which is the script and maybe other files.
But in looking at the script, I suspect something else. It now waits 15 seconds for the driver to load, and exits if it hasn't by then. That is the simplest explanation for the absence of the debug info. You might edit that file to change line 12 from:
WAITMAX=15
to
WAITMAX=60
and check for debug data in /tmp/udevtrace-modem.log.
If the data is still absent, there may be a bigger issue. To be sure the script runs and selects the correct modem (ttyUSB0), please probe>ERASE in PupDial and reboot, to be sure puppy is not re-using the selection from before. If no modem is detected, that tells me that the script did not run or that it timed out waiting for the driver to load.
My expectation is that the line:
Code: Select all
usb_v12d1_p1003_d0000_dc00_icff_usb_interface_HUAWEI Technologies_HUAWEI Mobile_Perhaps a cleaner test would be to simply make the edit to firmware.dep and delete the init script altogether. That would force re-installation of the script. If no modem is detected, with the modem plugged in at boot, that would mean either the script was not present where needed, or it timed out. Check for the existence of /etc/init.d/Option. I need to know whether the script makes it to /etc/init.d. If it is not, we need a redesign. Enough rambling. Please see what you can find. Thanks.
Richard
UPDATE: I am trying to imagine what might be happening with the modem startup. What if the device issues all of its device identification at once and that the presence of the entries containing icFF does not indicate that the device has switched modes? That should cause the modem driver to be modprobed, but maybe the driver does something special when it finds the modem not actually ready. On the chance that it refuses to load in that situation, maybe the modprobe instruction produces an error or status message. Although I have edited the modprobe in the script that issues it, to send errors to our log file, I may have coded that incorrectly. I have a better way to code that, so you might edit file /sbin/pup_event_backend_modprobe, line 151, to:
Code: Select all
exec /sbin/modprobe $MODULE >> /tmp/udevtrace-modem.log 2>&1 #rseRichard
Hi rerwin,
I am sorry, I must report failure
And, also, I have lost access to the modem for a while (maybe a few months.) I've, however, managed to snatch the logs from the tmp folder, just in time:
Here I attach the rar, hope it is useful. I will not be able to test for some time, though!
Cheers
I am sorry, I must report failure
And, also, I have lost access to the modem for a while (maybe a few months.) I've, however, managed to snatch the logs from the tmp folder, just in time:Here I attach the rar, hope it is useful. I will not be able to test for some time, though!
Cheers
- Attachments
-
- logs.rar
- (10.5 KiB) Downloaded 267 times
What seems hard is actually easy, while what looks like impossible is in fact hard.
“Hard things take time to do. Impossible things take a little longer.†–Percy Cerutty
[url=http://droope.wordpress.com/]Mi blog[/url] (Spanish)
“Hard things take time to do. Impossible things take a little longer.†–Percy Cerutty
[url=http://droope.wordpress.com/]Mi blog[/url] (Spanish)
droope,
You do not indicate that you used the "Internet by dialup modem" option, but that is immaterial, judging by the content of the logs you attached. I see no indication that the modem was plugged in at all during that session. I am looking for vendor 19d2 and product ID 2000. The only USB device indicated is a Kingston DataTraveler 2.0. From that I conclude that you had only a flash drive plugged, and not the modem. The only indication there was ever a modem plugged in is the line: "Script Option: timeout", which comes from the leftover initialization script.
If that DataTraveler is actually the modem, that is a "whole new ballgame". I guess we will have to wait until you are ready, to resume experimentation. Just let me know when.
Richard
You do not indicate that you used the "Internet by dialup modem" option, but that is immaterial, judging by the content of the logs you attached. I see no indication that the modem was plugged in at all during that session. I am looking for vendor 19d2 and product ID 2000. The only USB device indicated is a Kingston DataTraveler 2.0. From that I conclude that you had only a flash drive plugged, and not the modem. The only indication there was ever a modem plugged in is the line: "Script Option: timeout", which comes from the leftover initialization script.
If that DataTraveler is actually the modem, that is a "whole new ballgame". I guess we will have to wait until you are ready, to resume experimentation. Just let me know when.
Richard
rerwin,
I am also a bit confused:
there is no file: /etc/init.d/Option
There is an entry: option:option.ko, but without # - so there is nothing to do
in which script I shall change the time?
I erased the Modem - and it is not found by the system - even with probe, it does not found.
But it is present - here dmesg.
only if I edit by hand wvdial.conf the modem to /dev/ttyUSB0 it is detected and I can connect.
I hope this helps a little bit .....
I am also a bit confused:
there is no file: /etc/init.d/Option
There is an entry: option:option.ko, but without # - so there is nothing to do
in which script I shall change the time?
I erased the Modem - and it is not found by the system - even with probe, it does not found.
But it is present - here dmesg.
Code: Select all
usbcore: registered new interface driver usbserial
drivers/usb/serial/usb-serial.c: USB Serial support registered for generic
usbcore: registered new interface driver usbserial_generic
drivers/usb/serial/usb-serial.c: USB Serial Driver core
drivers/usb/serial/usb-serial.c: USB Serial support registered for GSM modem (1-port)
option 1-2:1.0: GSM modem (1-port) converter detected
usb 1-2: GSM modem (1-port) converter now attached to ttyUSB0
option 1-2:1.1: GSM modem (1-port) converter detected
usb 1-2: GSM modem (1-port) converter now attached to ttyUSB1
usbcore: registered new interface driver option
drivers/usb/serial/option.c: USB Driver for GSM modems: v0.7.1 I hope this helps a little bit .....
- Attachments
-
- huawei-E220-6.tar.gz
- (3.36 KiB) Downloaded 402 times
kultex,
Thanks for running that test. It confirms my fear that we have not actually mastered the startup timing. The logs show that the mode-switch took place and that the option driver was probably loaded by our second modprobe. It might be that a second bootup would take, without touching wvdial.conf.
I am concerned that we don't see confirmation that the original modprobe of the option driver was actually done, although the script probably got placed where it should be. (because that happens before the actual modprobe). That's been nagging me for a while.
I know it is late for you tonight, so I will later add suggestions and maybe an updated patch5 for you to try at your convenience. But I will go ahead and submit something for the pending 4.3 beta and hope to update that once we figure this out.
Thanks for continuing with this. I know you are going to be busy for awhile, so please work this only when you can spare the time. There is no deadline for getting it right.
Richard
Thanks for running that test. It confirms my fear that we have not actually mastered the startup timing. The logs show that the mode-switch took place and that the option driver was probably loaded by our second modprobe. It might be that a second bootup would take, without touching wvdial.conf.
I am concerned that we don't see confirmation that the original modprobe of the option driver was actually done, although the script probably got placed where it should be. (because that happens before the actual modprobe). That's been nagging me for a while.
I know it is late for you tonight, so I will later add suggestions and maybe an updated patch5 for you to try at your convenience. But I will go ahead and submit something for the pending 4.3 beta and hope to update that once we figure this out.
Thanks for continuing with this. I know you are going to be busy for awhile, so please work this only when you can spare the time. There is no deadline for getting it right.
Richard
-
divisionmd
- Posts: 606
- Joined: Sat 14 Jul 2007, 20:42
Option Icon 225
Hello,
- Going bananas over my 3G device - spent alot of hours and now i am stuck.
- I have a 3G modem "Option Icon 225".
- And i have gotten so far that when i try to connect this happens:
--> WvDial: Internet dialer version 1.53
--> Initializing modem.
--> Sending: AT+CPIN=1234
AT+CPIN=1234
OK
--> Sending: ATZ
ATZ
OK
--> Modem initialized.
--> Sending: ATX1DT*99***1#
--> Waiting for carrier.
But nothing more happens... ?
- This is the log:
- /tmp/pup_event_module_devpath_log:
ODULE=hso DEVPATH=/devices/pci0000:00/0000:00:1d.0/usb3/3-1/3-1:1.0
# MODULE=fan DEVPATH=/devices/LNXSYSTM:00/LNXTHERM:00/PNP0C0B:00
# MODULE=usbhid DEVPATH=/devices/pci0000:00/0000:00:1d.0/usb3/3-2/3-2:1.0
# MODULE=usbhid DEVPATH=/devices/pci0000:00/0000:00:1d.0/usb3/3-2/3-2:1.1
# MODULE=evdev DEVPATH=/devices/platform/pcspkr/input/input2
# MODULE=evdev DEVPATH=/devices/LNXSYSTM:00/device:00/PNP0C0C:00/input/input4
# MODULE=evdev DEVPATH=/devices/LNXSYSTM:00/LNXPWRBN:00/input/input3
# MODULE=hso DEVPATH=/devices/pci0000:00/0000:00:1d.0/usb3/3-1/3-1:1.0
- /tmp/udevtrace-modem.log:
usb_v0af0_p6971_d0000_dcff_icff_usb_interface_Option N.V._Globetrotter HSDPA Modem_
tty__Add_device_node_link_for_HSOTYPE_Diagnostic
usb_v0af0_p6971_d0000_dcff_icff_usb_interface_Option N.V._Globetrotter HSDPA Modem_
tty_ttyHS2
tty__Add_device_node_link_for_HSOTYPE_Control
tty__Add_device_node_link_for_HSOTYPE_Application
tty_ttyHS1
tty_ttyHS0
- /tmp/udevtrace.log:
add_ttyHS2_tty_0x8086_3-1:1.1_usb:v0AF0p6971d0000dcFFdscFFdpFFicFFiscFFipFF
add_hso0_net_0x8086_3-1:1.0_usb:v0AF0p6971d0000dcFFdscFFdpFFicFFiscFFipFF
add_ttyHS1_tty_0x8086_3-1:1.0_usb:v0AF0p6971d0000dcFFdscFFdpFFicFFiscFFipFF
add_ttyHS0_tty_0x8086_3-1:1.0_usb:v0AF0p6971d0000dcFFdscFFdpFFicFFiscFFipFF
add_usbdev3.4_ep03_usb_endpoint_0x8086_3-1:1.0_usb:v0AF0p6971d0000dcFFdscFFdpFFicFFiscFFipFF
add_usbdev3.4_ep85_usb_endpoint_0x8086_3-1:1.0_usb:v0AF0p6971d0000dcFFdscFFdpFFicFFiscFFipFF
add_usbdev3.4_ep83_usb_endpoint_0x8086_3-1:1.0_usb:v0AF0p6971d0000dcFFdscFFdpFFicFFiscFFipFF
- /tmp/ozerocdoff.log:
/usr/sbin/ozerocdoff -wi 0x6971 -l /tmp/ozerocdoff.log
Successfully ZERO-CD disabled
- Before i connect i execute this:
modprobe hso
modprobe option
modprobe usbserial vendor=0x0af0 product=0x6971
echo "Echo PIN code ttyHS0"
echo AT+CPIN=1234 > /dev/ttyHS0
sleep 1
echo "AT+CPIN=1234" > /dev/ttyHS0
sleep 1
echo "Echo PIN code ttyHS2"
echo AT+CPIN=1234> /dev/ttyHS2
sleep 1
echo "AT+CPIN=1234" > /dev/ttyHS2
sleep 1
usb_modeswitch
then i get the message that the modem is switched.
- Modem works fine on Windows.
- Also tested to type "ATZ" to init string "2" but that did not help.
Thanks for all help,
Best regards,
Johan
- Going bananas over my 3G device - spent alot of hours and now i am stuck.
- I have a 3G modem "Option Icon 225".
- And i have gotten so far that when i try to connect this happens:
--> WvDial: Internet dialer version 1.53
--> Initializing modem.
--> Sending: AT+CPIN=1234
AT+CPIN=1234
OK
--> Sending: ATZ
ATZ
OK
--> Modem initialized.
--> Sending: ATX1DT*99***1#
--> Waiting for carrier.
But nothing more happens... ?
- This is the log:
- /tmp/pup_event_module_devpath_log:
ODULE=hso DEVPATH=/devices/pci0000:00/0000:00:1d.0/usb3/3-1/3-1:1.0
# MODULE=fan DEVPATH=/devices/LNXSYSTM:00/LNXTHERM:00/PNP0C0B:00
# MODULE=usbhid DEVPATH=/devices/pci0000:00/0000:00:1d.0/usb3/3-2/3-2:1.0
# MODULE=usbhid DEVPATH=/devices/pci0000:00/0000:00:1d.0/usb3/3-2/3-2:1.1
# MODULE=evdev DEVPATH=/devices/platform/pcspkr/input/input2
# MODULE=evdev DEVPATH=/devices/LNXSYSTM:00/device:00/PNP0C0C:00/input/input4
# MODULE=evdev DEVPATH=/devices/LNXSYSTM:00/LNXPWRBN:00/input/input3
# MODULE=hso DEVPATH=/devices/pci0000:00/0000:00:1d.0/usb3/3-1/3-1:1.0
- /tmp/udevtrace-modem.log:
usb_v0af0_p6971_d0000_dcff_icff_usb_interface_Option N.V._Globetrotter HSDPA Modem_
tty__Add_device_node_link_for_HSOTYPE_Diagnostic
usb_v0af0_p6971_d0000_dcff_icff_usb_interface_Option N.V._Globetrotter HSDPA Modem_
tty_ttyHS2
tty__Add_device_node_link_for_HSOTYPE_Control
tty__Add_device_node_link_for_HSOTYPE_Application
tty_ttyHS1
tty_ttyHS0
- /tmp/udevtrace.log:
add_ttyHS2_tty_0x8086_3-1:1.1_usb:v0AF0p6971d0000dcFFdscFFdpFFicFFiscFFipFF
add_hso0_net_0x8086_3-1:1.0_usb:v0AF0p6971d0000dcFFdscFFdpFFicFFiscFFipFF
add_ttyHS1_tty_0x8086_3-1:1.0_usb:v0AF0p6971d0000dcFFdscFFdpFFicFFiscFFipFF
add_ttyHS0_tty_0x8086_3-1:1.0_usb:v0AF0p6971d0000dcFFdscFFdpFFicFFiscFFipFF
add_usbdev3.4_ep03_usb_endpoint_0x8086_3-1:1.0_usb:v0AF0p6971d0000dcFFdscFFdpFFicFFiscFFipFF
add_usbdev3.4_ep85_usb_endpoint_0x8086_3-1:1.0_usb:v0AF0p6971d0000dcFFdscFFdpFFicFFiscFFipFF
add_usbdev3.4_ep83_usb_endpoint_0x8086_3-1:1.0_usb:v0AF0p6971d0000dcFFdscFFdpFFicFFiscFFipFF
- /tmp/ozerocdoff.log:
/usr/sbin/ozerocdoff -wi 0x6971 -l /tmp/ozerocdoff.log
Successfully ZERO-CD disabled
- Before i connect i execute this:
modprobe hso
modprobe option
modprobe usbserial vendor=0x0af0 product=0x6971
echo "Echo PIN code ttyHS0"
echo AT+CPIN=1234 > /dev/ttyHS0
sleep 1
echo "AT+CPIN=1234" > /dev/ttyHS0
sleep 1
echo "Echo PIN code ttyHS2"
echo AT+CPIN=1234> /dev/ttyHS2
sleep 1
echo "AT+CPIN=1234" > /dev/ttyHS2
sleep 1
usb_modeswitch
then i get the message that the modem is switched.
- Modem works fine on Windows.
- Also tested to type "ATZ" to init string "2" but that did not help.
Thanks for all help,
Best regards,
Johan
-
alix_board
- Posts: 64
- Joined: Fri 14 Aug 2009, 06:35
- Location: Austria
Hi @ all,
i have a Huawei E170 Wireless Modem and have already install the 3G pupdial wireless patch4. I do not have many experience with puppy, still !
How i can install now the modem? I have already try the Network Wizard (Autoload USB) - but it does not work. Maybe someone can give me an instruction?
Thanks a lot!
greets,
alix_board
i have a Huawei E170 Wireless Modem and have already install the 3G pupdial wireless patch4. I do not have many experience with puppy, still
!How i can install now the modem? I have already try the Network Wizard (Autoload USB) - but it does not work. Maybe someone can give me an instruction?
Thanks a lot!
greets,
alix_board
alix_board,
You have come to the right place to request help. I see that you earlier posted your information here: http://www.murga-linux.com/puppy/viewto ... 527#332131
That gives me something to work with.
The first problem is that the wireless modem support began on kernel 2.6.25.16. I have not tested on the "retro" 2.6.21.7 kernel and suspect that there is no "option" driver there. I have compiled updated drivers for the 2.6.25.16 kernel, but they won't help you until you upgrade to the "standard" 2.6.25.16 kernel.
Once you are on Puppy 4.1.2 or 4.2.1 "standard", please review the first post in this thread, to understand what to do. To summarize that, you need to download the "3G pupdial", "usb_modeswitch", patched option driver, patched usb-storage driver and 3G...patch4 dotpets mentioned there.
But be warned: we are having difficulties with the Huawei modems being recognized. Please reboot twice after installation, to give it a chance. If it doesn't work after you have done everything right, I will need your help/feedback to get the problem corrected. Be sure to have the modem plugged in when you boot up. You may need to unplug and replug it after you are up and running after two bootups.
Thanks for joining us.
Richard
You have come to the right place to request help. I see that you earlier posted your information here: http://www.murga-linux.com/puppy/viewto ... 527#332131
That gives me something to work with.
The first problem is that the wireless modem support began on kernel 2.6.25.16. I have not tested on the "retro" 2.6.21.7 kernel and suspect that there is no "option" driver there. I have compiled updated drivers for the 2.6.25.16 kernel, but they won't help you until you upgrade to the "standard" 2.6.25.16 kernel.
Once you are on Puppy 4.1.2 or 4.2.1 "standard", please review the first post in this thread, to understand what to do. To summarize that, you need to download the "3G pupdial", "usb_modeswitch", patched option driver, patched usb-storage driver and 3G...patch4 dotpets mentioned there.
But be warned: we are having difficulties with the Huawei modems being recognized. Please reboot twice after installation, to give it a chance. If it doesn't work after you have done everything right, I will need your help/feedback to get the problem corrected. Be sure to have the modem plugged in when you boot up. You may need to unplug and replug it after you are up and running after two bootups.
Thanks for joining us.
Richard
Re: Option Icon 225
divisionmd,
Thanks for moving our discussion of this subject from our PM exchanges to this thread, fo all to see. Because you began by attempting to use your modem in a non-puppy kernel, I requested you to start with this project on Puppy 4.1.2 and install the dotpets appropriate to your "HSO" modem (3G_pupdial-11, hso, hso-udev, and 3G...patch4). I also requested that you avoid confusing me by your entering your own modprobe and other commands.
Your posting shows that you are going in that direction, but I really cannot help you once you start improvising with your own script or commands. My goal is to help you and others to get the HSO modems working in Puppy without your having to do anything but tell PupDial what you need and let it try to do it. I need to know where that process fails, so I can solve it for everyone.
Please make a clean test run and attach a tarball containing the log files requested in the first post of the thread, the files you have listed parts of in your posting. Remember, you may be the first to try this, so there may still be a bug that gets in the way and needs to be squashed. The issue of the appropriate way to start the (hso, option) driver is still a "work in progress", as you can see in my dialog with kultex.
Thanks for helping us get this right.
Richard
Thanks for moving our discussion of this subject from our PM exchanges to this thread, fo all to see. Because you began by attempting to use your modem in a non-puppy kernel, I requested you to start with this project on Puppy 4.1.2 and install the dotpets appropriate to your "HSO" modem (3G_pupdial-11, hso, hso-udev, and 3G...patch4). I also requested that you avoid confusing me by your entering your own modprobe and other commands.
Your posting shows that you are going in that direction, but I really cannot help you once you start improvising with your own script or commands. My goal is to help you and others to get the HSO modems working in Puppy without your having to do anything but tell PupDial what you need and let it try to do it. I need to know where that process fails, so I can solve it for everyone.
Please make a clean test run and attach a tarball containing the log files requested in the first post of the thread, the files you have listed parts of in your posting. Remember, you may be the first to try this, so there may still be a bug that gets in the way and needs to be squashed. The issue of the appropriate way to start the (hso, option) driver is still a "work in progress", as you can see in my dialog with kultex.
Thanks for helping us get this right.
Richard
huawei e169
Hi rerwin / all
just checking whether I should post problems with the above modem here or start a new thread?
I've installed the 3G wireless 11 pet, and just downloaded patch 5 to see if that works, but up til now the best I can do is get my modem recognised (on tty/usb2) but only at a speed of 9600. Obviously, I'm not posting from puppy, so I'll finish this, log on to puppy and test the patch 5. If it still doesn't work, like I said, do i post here or in a new thread, and can I get an idea of the log file entries I should copy to the post?
cheers
mcalex
just checking whether I should post problems with the above modem here or start a new thread?
I've installed the 3G wireless 11 pet, and just downloaded patch 5 to see if that works, but up til now the best I can do is get my modem recognised (on tty/usb2) but only at a speed of 9600. Obviously, I'm not posting from puppy, so I'll finish this, log on to puppy and test the patch 5. If it still doesn't work, like I said, do i post here or in a new thread, and can I get an idea of the log file entries I should copy to the post?
cheers
mcalex
mcalex,
Thanks for joining this thread. I assume you refer to the Icon 225, which uses the hso driver. I am impressed that you do connect. Yes, this is the place to discuss problems with any of the wireless modems, so that I can perfect the support for them, to get you and others going.
From what I see in this thread and elsewhere, the indicated modem speed is of no consequence. The modems work fine even if the value is 9600. You might try a probe>PROBE to watch how the value is determined, but you may well end up with a different value, probably larger.
Could you attach the /tmp/udevtrace files and /tmp/ozerocdoff.log file, so I can see what happened to allow you some success? Keep in mind that I depend on others for feedback, because I cannot test any modem of my own (because I don't have any). Thanks.
Richard
Thanks for joining this thread. I assume you refer to the Icon 225, which uses the hso driver. I am impressed that you do connect. Yes, this is the place to discuss problems with any of the wireless modems, so that I can perfect the support for them, to get you and others going.
From what I see in this thread and elsewhere, the indicated modem speed is of no consequence. The modems work fine even if the value is 9600. You might try a probe>PROBE to watch how the value is determined, but you may well end up with a different value, probably larger.
Could you attach the /tmp/udevtrace files and /tmp/ozerocdoff.log file, so I can see what happened to allow you some success? Keep in mind that I depend on others for feedback, because I cannot test any modem of my own (because I don't have any). Thanks.
Richard
3G_pupdial-wireless-12 uploaded
I have consolidated the patches (except patch5) into an updated "-12" dotpet. It uses approximately the same mode-switching delay times as earlier; patch5 shortened them, but may have made things worse. Here is my update to the download posting:
UPDATE 8/22/09: I have replaced the main dotpet with 3G_pupdial-wireless-12. This includes the improvements in the "-11" patches and the 4.3 beta2 release (assuming they are accepted), plus support of a few additional modems. (I will remove the "-11" verson shortly.) This new version changes support of PINs and APNs, so that the PIN is issued only once per session and APNs are now associated with each dialup account. A pulse-dial (ATDP) setting is now retained. Certain Huawei modems may now be detected.
NOTE: I have not upgraded to usb_modeswitch-1.0.3 because it no longer appears to support command-line parameters, which Puppy uses. It stops with a segmentation fault.
This gives us a new baseline for trying debug patches to better understand the issues with detection of the Huawei modems that do not change IDs when mode-switching. I need to do some investigation of the loading process, because the option driver does not appear to be loaded when I think it ought to be, which impacts detection.
As usual, please report any problems you have with the updated package, but only if you do not interfere with the startup process by interjecting other commands. I need your cooperation, to make wireless-modem support better. Thanks.
Richard
UPDATE 8/22/09: I have replaced the main dotpet with 3G_pupdial-wireless-12. This includes the improvements in the "-11" patches and the 4.3 beta2 release (assuming they are accepted), plus support of a few additional modems. (I will remove the "-11" verson shortly.) This new version changes support of PINs and APNs, so that the PIN is issued only once per session and APNs are now associated with each dialup account. A pulse-dial (ATDP) setting is now retained. Certain Huawei modems may now be detected.
NOTE: I have not upgraded to usb_modeswitch-1.0.3 because it no longer appears to support command-line parameters, which Puppy uses. It stops with a segmentation fault.
This gives us a new baseline for trying debug patches to better understand the issues with detection of the Huawei modems that do not change IDs when mode-switching. I need to do some investigation of the loading process, because the option driver does not appear to be loaded when I think it ought to be, which impacts detection.
As usual, please report any problems you have with the updated package, but only if you do not interfere with the startup process by interjecting other commands. I need your cooperation, to make wireless-modem support better. Thanks.
Richard
hi rerwin, no, I've got a huawei e169 (I typed it in the subject, but it's very non-prominent - will remember to include all details in the body hence
Puppy can see my modem (with your -11.pet, it was on tty/USB2, but with the -12.pet it's now on tty/USB0), but when it tries to connect, I get a 'no carrier detected' error. I've switched the Carrier Detect option on and off, both in the pupdial gui and the wvconf file, but to no effect. Also, I'm not sure what to do with the PIN. When I add the 6-digit code I was given (which was called the pin by the virgin ppl), I get 'invalid connection string' (or similar) error messages. Am typing from memory at work, so not 100% sure of the error syntax.
I have been playing with settings, so I'll boot up a clean puppy, and install the latest pets. As I understand it, I want 3G_pupdial-wireless-12.pet, usb_modeswitch-1.0.2.pet but not the patch 5 that I had installed (against the -11.pet). Is this right?
cheers
mcalex
Puppy can see my modem (with your -11.pet, it was on tty/USB2, but with the -12.pet it's now on tty/USB0), but when it tries to connect, I get a 'no carrier detected' error. I've switched the Carrier Detect option on and off, both in the pupdial gui and the wvconf file, but to no effect. Also, I'm not sure what to do with the PIN. When I add the 6-digit code I was given (which was called the pin by the virgin ppl), I get 'invalid connection string' (or similar) error messages. Am typing from memory at work, so not 100% sure of the error syntax.
I have been playing with settings, so I'll boot up a clean puppy, and install the latest pets. As I understand it, I want 3G_pupdial-wireless-12.pet, usb_modeswitch-1.0.2.pet but not the patch 5 that I had installed (against the -11.pet). Is this right?
cheers
mcalex