Ticket #2298 (new defect)

Opened 9 years ago

Last modified 9 years ago

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

frameworkd.log (111.6 KB) - added by matthias 9 years ago.
log from gprs-shutdown-crash (with gps on)
dmesg.txt (15.2 KB) - added by matthias 9 years ago.
dmesg-output of the session with gprs-crash
paroli.log (81.8 KB) - added by matthias 9 years ago.
log from the session with gprs-crash

Change History

comment:1 Changed 9 years ago by Nytowl

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

comment:2 Changed 9 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 9 years ago by matthias

log from gprs-shutdown-crash (with gps on)

Changed 9 years ago by matthias

dmesg-output of the session with gprs-crash

Changed 9 years ago by matthias

log from the session with gprs-crash

comment:3 follow-up: ↓ 4 Changed 9 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 9 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 9 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 9 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
Note: See TracTickets for help on using tickets.