Ticket #2298 (new defect)
GPRS connection works only once
| Reported by: | niccolo | Owned by: | openmoko-devel |
|---|---|---|---|
| Priority: | normal | Milestone: | Om2009 |
| Component: | unknown | Version: | unspecified |
| Severity: | normal | Keywords: | GPRS |
| Cc: | Blocked By: | ||
| Blocking: | Estimated Completion (week): | ||
| HasPatchForReview: | no | PatchReviewResult: | |
| Reproducible: |
Description
I installed Om2009 testing5; I had to disinstall it because I found it unusable. Here a bug report:
The GPRS connection works only the first time it is launched. After closing the first connection, I was unable to connect again. Reboot the phone fix the problem.
To connect/disconnect I used the scripts provied in this page:
http://wiki.openmoko.org/wiki/GPRS_FSO
Attachments
Change History
comment:2 Changed 4 years ago by matthias
The same for me.
I tried it with the python-api of the fso-framework, namely the functions:
dbus.SystemBus?().get_object( 'org.freesmartphone.ogsmd', '/org/freesmartphone/GSM/Device' ).ActivateContext?( apn, user, passwd )
and
dbus.SystemBus?().get_object( 'org.freesmartphone.ogsmd', '/org/freesmartphone/GSM/Device' ).DeactivateContext?()
Paroli Crashed afterwards and no call to any fresmartphone-daemon worked.
I had to reboot or restart dbus-1, frameworkd and paroli.
Is it a bug in the framework or is it all about the gsm-modem?
log will be attached soon.
Changed 4 years ago by matthias
- Attachment frameworkd.log added
log from gprs-shutdown-crash (with gps on)
Changed 4 years ago by matthias
dmesg-output of the session with gprs-crash
comment:3 follow-up: ↓ 4 Changed 4 years ago by matthias
Just to be more concret:
It always happened after calling DeactivateContext().
It just took up to 20 minutes for paroli to come up with the requested window which reacted as slow as the former.
FYI: I had the same experience with shr-unstable from august.
So it seems to be something about the framework.
comment:4 in reply to: ↑ 3 Changed 4 years ago by zoff99
Replying to matthias:
Just to be more concret:
It always happened after calling DeactivateContext().
It just took up to 20 minutes for paroli to come up with the requested window which reacted as slow as the former.
FYI: I had the same experience with shr-unstable from august.
So it seems to be something about the framework.
i have the same problem. after disabling gprs i need to reboot neo, or else almost nay dbus calls freeze
comment:5 follow-up: ↓ 6 Changed 4 years ago by zoff99
also i needed this fix to get normal nameservers after shutting down GPRS.
otherwise 127.0.0.1 would be in /etc/resolv.conf
# grps down fix
cd /usr/lib/python2.6/site-packages/framework/subsystems/ogsmd/modems/abstract/
rm -f pdp.pyo
cat pdp.py |sed -e 's#echo nameserver 127.0.0.1 > /etc/resolv.conf#
echo nameserver 208.67.222.222 \> /etc/resolv.conf\;echo nameserver 208.67.220.220 \>\> /etc/resolv.conf#' > pdp.py_patched
mv pdp.py_patched pdp.py
# grps down fix
comment:6 in reply to: ↑ 5 Changed 4 years ago by zoff99
Replying to zoff99:
also i needed this fix to get normal nameservers after shutting down GPRS.
otherwise 127.0.0.1 would be in /etc/resolv.conf
ok better readable:
# grps down fix cd /usr/lib/python2.6/site-packages/framework/subsystems/ogsmd/modems/abstract/ rm -f pdp.pyo cat pdp.py |sed -e 's#echo nameserver 127.0.0.1 > /etc/resolv.conf# echo nameserver 208.67.222.222 \> /etc/resolv.conf\;echo nameserver 208.67.220.220 \>\> /etc/resolv.conf#' > pdp.py_patched mv pdp.py_patched pdp.py # grps down fix

Why did you not use the GPRS settings panel inside of paroli ?