After successful repair of my device, including the new motherboard with live USB port, returned to my experiments. The 3G modem is seen, it registers in the network, shows the correct APN... but does not connect. "No connection to the Internet". In the ADB I can see that PPP connection goes up, but neither the default route nor resolv.conf are created:
Code:
/ # ls /dev/ttyHS*
/dev/ttyHS0 /dev/ttyHS1 /dev/ttyHS2 /dev/ttyHS3 /dev/ttyHS4
/ # ifconfig
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:744 errors:0 dropped:0 overruns:0 frame:0
TX packets:744 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:54232 (52.9 KiB) TX bytes:54232 (52.9 KiB)
ppp1 Link encap:Point-to-Point Protocol
inet addr:10.195.192.232 P-t-P:10.64.64.65 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1280 Metric:1
RX packets:4 errors:0 dropped:0 overruns:0 frame:0
TX packets:4 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:3
RX bytes:52 (52.0 B) TX bytes:58 (58.0 B)
/ # ip route
10.64.64.65 dev ppp1 proto kernel scope link src 10.195.192.232
/ # ls -l /etc/resolv.conf
lrwxrwxrwx 1 1000 system 16 Jul 15 15:44 /etc/resolv.conf -> /tmp/resolv.conf
/ # ls /tmp
audiomixer.sock avshsocket powerd.sock
audiomixer_read.sock chap-secrets samba
audiomixer_write.sock inc
avos pap-secrets
/ #
Thus it looks like /etc/ppp/ip-up, or some its daughter scripts, is not executed as it should. Situation is the same for 4.0.7, 4.0.6, and even 3.2.80 - which definitely did work! And for any of the 4 operators available at my location.
If this were a software problem, it could be fixed by reflashing. If it were a hardware problem, then the modem would not connect at all. Any more ideas? Does anyone know where to look for logs, or how to enable PPP logging and debug?
iourine said:
After successful repair of my device, including the new motherboard with live USB port, returned to my experiments. The 3G modem is seen, it registers in the network, shows the correct APN... but does not connect. "No connection to the Internet". In the ADB I can see that PPP connection goes up, but neither the default route nor resolv.conf are created:
Code:
/ # ls /dev/ttyHS*
/dev/ttyHS0 /dev/ttyHS1 /dev/ttyHS2 /dev/ttyHS3 /dev/ttyHS4
/ # ifconfig
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:744 errors:0 dropped:0 overruns:0 frame:0
TX packets:744 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:54232 (52.9 KiB) TX bytes:54232 (52.9 KiB)
ppp1 Link encap:Point-to-Point Protocol
inet addr:10.195.192.232 P-t-P:10.64.64.65 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1280 Metric:1
RX packets:4 errors:0 dropped:0 overruns:0 frame:0
TX packets:4 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:3
RX bytes:52 (52.0 B) TX bytes:58 (58.0 B)
/ # ip route
10.64.64.65 dev ppp1 proto kernel scope link src 10.195.192.232
/ # ls -l /etc/resolv.conf
lrwxrwxrwx 1 1000 system 16 Jul 15 15:44 /etc/resolv.conf -> /tmp/resolv.conf10.64.64.65 dev ppp1 proto kernel scope link src 10.195.192.232
/ # ls /tmp
audiomixer.sock avshsocket powerd.sock
audiomixer_read.sock chap-secrets samba
audiomixer_write.sock inc
avos pap-secrets
/ #
Thus it looks like /etc/ppp/ip-up, or some its daughter scripts, is not executed as it should. Situation is the same for 4.0.7, 4.0.6, and even 3.2.80 - which definitely did work! And for any of the 4 operators available at my location.
If this were a software problem, it could be fixed by reflashing. If it were a hardware problem, then the modem would not connect at all. Any more ideas? Does anyone know where to look for logs, or how to enable PPP logging and debug?
Click to expand...
Click to collapse
Hi.
It's looks like your route has not been set up properly, I faced this or something similar while playing around the Huawei Stuff, It turned out that the gateway property net.ppp1.gw needed to be set to the remote ip.
I'll power up my archos and have a look for you, It's completely drained at the minute so it takes a while to come back to life..
In the mean time you can add the following to /etc/ppp/peers/datakey
Code:
debug
dump
kdebug 8
this will give a more verbose output on the logcat, I also like to use logcat with the following switches ( basically outputting all logs )
Code:
-b system -b main -b radio -b events
If you're still running into problems I'll post my properties and an example logcat if you want
Hope that helps
Trev
Thnx trevd,
the fact is that there are at least 3 opertaions to be done: defaultroute, resolv.conf, and some system-wide flag stating "internet connection present". Thus I suspect the entire ip-up script is not executed; in my case it is simply missing. Please could you look
Code:
ls -la /etc/ppp
both with the 3G connection on and off. No need to hurry, I'm unlikely to continue in the nearest days.
iourine said:
Thnx trevd,
the fact is that there are at least 3 opertaions to be done: defaultroute, resolv.conf, and some system-wide flag stating "internet connection present". Thus I suspect the entire ip-up script is not executed; in my case it is simply missing. Please could you look
Code:
ls -la /etc/ppp
both with the 3G connection on and off. No need to hurry, I'm unlikely to continue in the nearest days.
Click to expand...
Click to collapse
Hi. The directory layout looks the same either way
Code:
lrwxrwxrwx 1 root root 17 Jun 15 10:00 chap-secrets -> /tmp/chap-secrets
-rwxr-xr-x 1 root root 535 May 21 09:41 init_pppd_datakey
-rwxr-xr-x 1 root root 375 May 21 09:41 ip-down-datakey
-rwxr-xr-x 1 root root 408 May 21 09:41 ip-up-datakey
-rwxr-xr-x 1 root root 5596 May 21 09:56 ip-up-vpn
lrwxrwxrwx 1 root root 16 Jun 15 10:00 pap-secrets -> /tmp/pap-secrets
drwxr-xr-x 2 root root 30 May 21 09:41 peers
lrwxrwxrwx 1 root root 13 Jun 15 10:00 ppp0.pid -> /tmp/ppp0.pid
-rwxr-xr-x 1 root root 345 May 21 09:41 write_secrets
Here is the contents of /system/etc/ppp/ip-up-datakey
Code:
#!/system/bin/sh
NAME=ppp1
/system/bin/log -t pppd "start ip up ip remote=$IPREMOTE dns1=$DNS1 dns2=$DNS2 gateway=$IPLOCAL"
/system/bin/log -t pppd "NAME = $NAME"
/system/bin/setprop "net.$NAME.remote-ip" "$IPREMOTE"
/system/bin/setprop "net.$NAME.dns1" "$DNS1"
/system/bin/setprop "net.$NAME.dns2" "$DNS2"
/system/bin/setprop "net.$NAME.local-ip" "$IPLOCAL"
/system/bin/setprop "ril.pppd.state" "up"
Here is a list of system property which are set when the 3G Dongle is connected
Code:
[gsm.current.phone-type]: [1]
[gsm.defaultpdpcontext.active]: [true]
[gsm.network.type]: [UMTS:3]
[gsm.operator.alpha]: [Orange]
[gsm.operator.iso-country]: [gb]
[gsm.operator.isroaming]: [true]
[gsm.operator.numeric]: [23433]
[gsm.sim.operator.alpha]: [T-Mobile]
[gsm.sim.operator.iso-country]: [gb]
[gsm.sim.operator.numeric]: [23430]
[gsm.sim.state]: [READY]
[gsm.version.baseband]: [S21B47S1XX-RIL: 0.11]
[gsm.version.ril-impl]: [android TCL-ril 0.8]
[init.svc.pppd_datakey]: [running]
[init.svc.ril-daemon]: [running]
[net.dns1]: [149.254.230.7]
[net.dns2]: [149.254.192.126]
[net.dns1]: [149.254.230.7]
[net.dns2]: [149.254.192.126]
[net.dnschange]: [1]
[net.hostname]: [android-0016DC6B5408]
[net.ppp1.dns1]: [149.254.230.7]
[net.ppp1.dns2]: [149.254.192.126]
[net.ppp1.local-ip]: [31.113.123.214]
[net.ppp1.remote-ip]: [10.64.64.65]
[ril.pppd.state]: [up]
[ril.pppd_tty]: [/dev/ttyHS4]
[ril.use_data]: [yes]
[rild.libargs]: [-d /dev/ttyHS3]
[rild.libpath]: [/system/lib/libtcl-ril.so]
Obviously the ip's and networks are going to be different, but I'm sure you already figured that
Thnx trevd,
/etc/ppp looks the same; the problem appeasr to be in another place. Logcat says that PPP session is being established, and then immediatеly dropped with the following diagnostics:
Code:
I/pppd ( 4236): local IP address 10.227.119.86
I/pppd ( 4236): remote IP address 10.64.64.65
I/pppd ( 4236): primary DNS address 217.118.66.243
I/pppd ( 4236): secondary DNS address 217.118.66.244
I/pppd ( 4241): start ip up ip remote=10.64.64.65 dns1=217.118.66.243 dns2=217.118.66.244 gateway=10.227.119.86
I/pppd ( 4242): NAME = ppp1
D/AT ( 4216): AT> AT+CGACT?
D/AT ( 4216): AT< +CGACT: 1,1
D/AT ( 4216): AT< +CGACT: 2,0
D/AT ( 4216): AT< +CGACT: 3,0
D/AT ( 4216): AT< OK
D/AT ( 4216): AT> AT+CGDCONT?
D/AT ( 4216): AT< +CGDCONT: 1,"IP","internet.beeline.ru","0.0.0.0",0,0
D/AT ( 4216): AT< +CGDCONT: 2,"IP","","0.0.0.0",0,0
D/AT ( 4216): AT< +CGDCONT: 3,"IP","","0.0.0.0",0,0
D/AT ( 4216): AT< OK
E/RIL ( 4216): ppp_exit_code is 0
E/RIL ( 4216): ppp_exit_code is 0
E/RIL ( 4216): ppp_exit_code is 0
W/RILJ ( 703): [0052]< SETUP_DATA_CALL exception, possible invalid RIL response
W/RILJ ( 703): java.lang.RuntimeException: RIL_REQUEST_SETUP_DATA_CALL response expecting 1 RIL_Data_Call_response_v5 got 3
W/RILJ ( 703): at com.android.internal.telephony.RIL.responseSetupDataCall(RIL.java:3150)
W/RILJ ( 703): at com.android.internal.telephony.RIL.processSolicited(RIL.java:2235)
W/RILJ ( 703): at com.android.internal.telephony.RIL.processResponse(RIL.java:2125)
W/RILJ ( 703): at com.android.internal.telephony.RIL.access$500(RIL.java:202)
W/RILJ ( 703): at com.android.internal.telephony.RIL$RILReceiver.run(RIL.java:580)
W/RILJ ( 703): at java.lang.Thread.run(Thread.java:856)
D/GSM ( 703): [GsmDC-1] DcActivatingState msg.what=EVENT_SETUP_DATA_CONNECTION_DONE
D/GSM ( 703): [GsmDC-1] onSetupConnectionCompleted failed, ar.exception=java.lang.RuntimeException: RIL_REQUEST_SETUP_DATA_CALL response expecting 1 RIL_Data_Call_response_v5 got 3 response=null
D/GSM ( 703): [GsmDC-1] DcActivatingState onSetupConnectionCompleted result=ERR_GetLastErrorFromRil SetupResult.mFailCause=NONE
D/RILJ ( 703): [0053]> LAST_DATA_CALL_FAIL_CAUSE
D/RIL ( 4216): onRequest: LAST_DATA_CALL_FAIL_CAUSE
E/RIL ( 4216): ppp_exit_code is 0
D/AT ( 4216): AT> AT+CDFC?
D/AT ( 4216): AT< +CDFC:
D/AT ( 4216): AT< OK
D/RILJ ( 703): [0053]< LAST_DATA_CALL_FAIL_CAUSE error: com.android.internal.telephony.CommandException: GENERIC_FAILURE
D/GSM ( 703): [GsmDC-1] DcActivatingState msg.what=EVENT_GET_LAST_FAIL_DONE
D/GSM ( 703): [GsmDC-1] notifyConnectionCompleted at 1346266255724 cause=UNKNOWN
D/GSM ( 703): [GsmDC-1] clearSettings
D/GSM ( 703): [GsmDCT] handleMessage msg={ what=270336 when=-1ms arg1=-1 [email protected] }
D/GSM ( 703): [GsmDCT] isDataSetupCompleteOk return false, ar.result=UNKNOWN
D/GSM ( 703): [GsmDCT] onDataSetupComplete: error apn=internet.beeline.ru cause=UNKNOWN
D/GSM ( 703): [GsmDCT] onDataSetupComplete: WaitingApns.size=0 WaitingApnsPermFailureCountDown=1
D/GSM ( 703): [GsmDCT] onDataSetupComplete: Not all permanent failures, retry
D/GSM ( 703): [GsmDCT] notifyNoData: type=default
D/GSM ( 703): [ApnContext] setState: FAILED for type default, previous state:INITING
D/GSM ( 703): [GsmDCT] Schedule alarm for reconnect: activate failed. Scheduling next attempt for 5s
D/GSM ( 703): [GsmDCT] reconnectAfterFail: NOT Posting GPRS Unavailable notification -- likely transient error
then it loops.
Sometimes the session exists for a few seconds and then is dropped by LSP RST from the other end.
Still trying to understand if this is a software bug, or a modem hardware problem... the modem works on a regular PC, and the soft is brand new after reformat.
I doubt it's a hardware problem. You got a pretty clear error there in the logcat, "expecting 1 ril_v5 response, got 3", further corroborated by the three "ppp exited with 0" lines above. Mind posting your build.prop? I have a Huawei 3g stick, not an Archos 3g stick, so I have no idea how the connection is handled on the Archos 3G stick. Do you have a "datakey" file in etc/ppp/peers?
Sent from my Archos G9 running CM9
Yes, 3 times "ppp exited ..." is exacltly the point where something goes wrong.
Where is build.prop? Do I need root to find it? At the moment I deliberately have a brand fresh software installation, not rooted, to guarantee that everything is as provided by Archos.
etc/ppp/peers/datakey does exist but poses more questions... e.g. why "nodefaultroute"? is it the same in your case?
Actually the background is: the modem did work on my old Archos, then one day it stopped working (did not start on unblocking the screen) and the USB port turned out to be dead. It could equally be caused by h/w problem at either the modem or the port, and the other could also be damaged. Yet the modem still works on a regular PC. Now I have a new motherboard and try to run the modem on it.
iourine said:
Yes, 3 times "ppp exited ..." is exacltly the point where something goes wrong.
Where is build.prop? Do I need root to find it? At the moment I deliberately have a brand fresh software installation, not rooted, to guarantee that everything is as provided by Archos.
etc/ppp/peers/datakey does exist but poses more questions... e.g. why "nodefaultroute"? is it the same in your case?
Actually the background is: the modem did work on my old Archos, then one day it stopped working (did not start on unblocking the screen) and the USB port turned out to be dead. It could equally be caused by h/w problem at either the modem or the port, and the other could also be damaged. Yet the modem still works on a regular PC. Now I have a new motherboard and try to run the modem on it.
Click to expand...
Click to collapse
build.prop is in /system/. And yes, at least in CM9, the datakey peer is nodefaultroute... Does the datakey peer file end up with calling a chat script (should be the last line, something like "connect system/xbin/chat some_switches /system/etc/chatscripts/datakey"? If it does, check the contents of the chatscript...
As i said, im using CM9 with a Huawei modem, so i can only give some obvious pointers...
Hi omegaRED7
Good to hear the Huawei are still good, The Huawei Stuff uses the same method as the archos stock i.e init script call pppd which uses peers and call chat which if successfull calls ip-up. all of it being called from the RIL Library, Just change gprs and you've got the archos implementation. I think the peers scripts differ slightly but so do the RIL's.
EDIT
Oh yeah, the write_secrets part as well is different, but you already knew that :laugh:
@iourine
I'll post my datakey peers and chatscripts for you later on so you can compare, The error you're get is very strange Maybe the libtcl-ril is causing but I don't know.
EDIT: Below are the contents of my files, /etc/ppp/init_pppds_datakey , /etc/ppp/peers/datakey and /etc/chatscripts/datakey_start ; I don't there be any difference given the nature of the error, I suppose It'll be worth check that /system/bin/pppd is actual a binary file an not a script or something that starts pppd 3 times, also check the service definition for pppd_datakey which should be in /etc/init/init.<model>.rc e.g init.A101S.rc, this requires root to access and should look like this
Code:
service pppd_datakey /system/bin/logwrapper /system/etc/ppp/init_pppd_datakey
user root
group radio cache inet misc
disabled
oneshot
This service is started from within libtcl-ril.so and is the archos vendor ril used by the ril-daemon service.
As a test , using the root account
Code:
stop ril-daemon
start pppd_datakey
see if that bring up a connection
Code:
[B]cat /etc/ppp/peers/datakey[/B]
#!/system/bin/sh
# An unforunate wrapper script
# so that the exit code of pppd may be retrieved
# this is a workaround for issue #651747
#trap "/system/bin/sleep 1;exit 0" TERM
PPPD_PID=
PPPD_TTY=`/system/bin/getprop ril.pppd_tty`
/system/bin/setprop "net.datakey.ppp-exit" ""
/system/bin/log -t pppd "Starting pppd with tty [$PPPD_TTY]"
/system/bin/pppd $PPPD_TTY 115200 $* call datakey
PPPD_EXIT=$?
PPPD_PID=$!
/system/bin/log -t pppd "pppd exited with $PPPD_EXIT"
/system/bin/setprop "net.datakey.ppp-exit" "$PPPD_EXIT"
Code:
[B]cat /etc/ppp/peers/datakey[/B]
linkname datakey
mru 1280
mtu 1280
# dump
# debug
unit 1
# connection
# crtscts
connect-delay 3000
hide-password
nodetach
# peer parameters
# noauth
# most gprs phones don't reply to lcp echo
# lcp-echo-interval 0
# lcp-echo-failure 0
# dns, routing
ipcp-accept-remote
ipcp-accept-local
ipcp-max-failure 15
#defaultroute
nodefaultroute
#replacedefaultroute # not currently supported by our pppd
noipdefault
usepeerdns
# avoid compression
novj
novjccomp
noccp
nobsdcomp
nopcomp
noaccomp
# connect scripts
connect '/system/xbin/chat -v -t 3 -f /etc/chatscripts/datakey_start'
# disconnect '/system/xbin/chat -v -t 3 -f /etc/chatscripts/datakey_stop
Code:
[B]cat /etc/chatscripts/datakey_start[/B]
TIMEOUT 5
ECHO ON
ABORT BUSY
ABORT ERROR
ABORT 'NO CARRIER'
ABORT VOICE
ABORT 'NO DIALTONE'
ABORT 'NO DIAL TONE'
ABORT 'NO ANSWER'
ABORT DELAYED
TIMEOUT 12
'' ATD*99***1#
TIMEOUT 30
CONNECT ''
omegaRED7 said:
build.prop is in /system/. And yes, at least in CM9, the datakey peer is nodefaultroute... Does the datakey peer file end up with calling a chat script (should be the last line, something like "connect system/xbin/chat some_switches /system/etc/chatscripts/datakey"?
Click to expand...
Click to collapse
Here is my build.prop (original ICS 4.0.7), hardly it is very different from yours
Code:
# begin build properties
# autogenerated by buildinfo.sh
ro.build.id=MR1
ro.build.display.id=MR1.20120529.141046
ro.build.version.incremental=20120529.141046
ro.build.version.sdk=15
ro.build.version.codename=REL
ro.build.version.release=4.0.3
ro.build.date=Tue May 29 14:10:46 CEST 2012
ro.build.date.utc=1338293446
ro.build.type=user
ro.build.user=rd
ro.build.host=debian
ro.build.tags=release-keys
ro.product.brand=archos
ro.product.board=
ro.product.cpu.abi=armeabi-v7a
ro.product.cpu.abi2=armeabi
ro.product.manufacturer=archos
ro.product.locale.language=en
ro.product.locale.region=US
ro.wifi.channels=
ro.board.platform=omap4
# ro.build.product is obsolete; use ro.product.device
# Do not try to parse ro.build.description or .fingerprint
ro.build.description=G9A-user 4.0.3 MR1 20120529.141046 release-keys
ro.build.characteristics=nosdcard,tablet
ro.archos.hwswid=167
# end build properties
ro.kernel.android.checkjni=0
dalvik.vm.checkjni=false
dalvik.vm.verify-bytecode=false
persist.service.sv.enable=1
archos.tetherState=off
persist.archos.suspend=enabled
opencore.asmd=1
browser.tioptimization=true
connection.concurrent=10
dalvik.vm.heapstartsize=5m
dalvik.vm.heapgrowthlimit=48m
dalvik.vm.heapsize=256m
wifi.interface=wlan0
com.ti.omap_enhancement=true
ro.opengles.version=131072
tv.hdmi.uicloning.enable=true
media.avos.enable-rtsp=true
media.avos.enable-scanner=true
persist.archos.firmware_name=firmware_archos_it4.aos
ro.archos.daos.product=gen9
ro.com.google.mcc_fallback=262
enable.3d.bypass=0
ro.crypto.state=unsupported
ro.board.tsp_has_calibration=true
ro.telephony.default_network=3
#
# ADDITIONAL_BUILD_PROPERTIES
#
ro.com.android.dateformat=MM-dd-yyyy
ro.config.ringtone=Ring_Synth_04.ogg
ro.config.notification_sound=pixiedust.ogg
ro.config.alarm_alert=Alarm_Classic.ogg
ro.com.android.dataroaming=false
keyguard.no_require_sim=false
hwui.render_dirty_regions=false
drm.service.enabled=true
dalvik.vm.heapstartsize=5m
dalvik.vm.heapgrowthlimit=48m
dalvik.vm.heapsize=256m
ro.opengles.version=131072
ro.setupwizard.mode=DISABLED
ro.com.google.gmsversion=4.0.3_r0
dalvik.vm.dexopt-flags=m=y
net.bt.name=Android
dalvik.vm.stack-trace-file=/data/anr/traces.txt
Don't see anything special for 3G/ppp/dialup
The /etc/ppp/peers/datakey does exist and is exactly the same as quoted by trevd (except for the last line "# disconnect...." that obviously plays no role). So do /etc/ppp/init_pppd_datakey and /etc/chatscripts/datakey_start. But this is not the entire story... someone has to set up the APN, this is the only essential thing, isn't it? And indeed there is a long log of other AT commands (operator query, voice and data service query, etc.), fed to the modem by some other script - which one? And this script uses AT+ACT only, not ATD*99***1. Thus /etc/chatscripts/datakey_start is not actually run! Yet the modem goes online (probably automatically by setting an active content, this may be a feature of its firmware), otherwise LCP negotiation would never begin and IP addresses (correct and specific for the operator) would be never received.
/system/bin/pppd is really a binary file.
To try the tests that require root later...
Please could you get the complete logcat
Code:
logcat -b system -b main -b radio -b events *:V
from the modem plug-in till the successful connection (getting the IP addresses plus ~30 sec after that) and post it or send to my private mail (there will be a long dump).
Hey,
It could be that the connection is indeed established in the RIL itself, for example the huaweigeneric RIL includes commands to connect directly, of course it's a generic implementation, which in our case needs to be circumvented and the connection has to be established through pppd for the Huawei stuff...
Can you setup the APN? Can you force manual selection of the network operator? I really don't understand why, even if the connection is directly initiated by the RIL, it attempts 3 times, esp. since you're running a stock ROM....
Mind also posting the logcat part before the connection is established?
P.S. Trev I haven't forgotten, I'll PM you the changes in the libhuaweigeneric ril
Sent from my Archos G9 running CM9
iourine said:
/system/bin/pppd is really a binary file.
Click to expand...
Click to collapse
Ay, As expected, but always worth checking!
iourine said:
The /etc/ppp/peers/datakey does exist and is exactly the same as quoted by trevd (except for the last line "# disconnect...." that obviously plays no role). So do /etc/ppp/init_pppd_datakey and /etc/chatscripts/datakey_start. But this is not the entire story... someone has to set up the APN, this is the only essential thing, isn't it?
Click to expand...
Click to collapse
Yes and no, There a program in android called the SimToolkit which I believe manages a lot of that when a new sim card is inserted. You'll see I/STK on the logcat if that has been actioned. After that I think the vendor ril manages the APN setting although it cannot hurt to manually set the APN and also manually register on the network as this sometimes helps but that's doesn't seem to be the problem you're facing
iourine said:
And indeed there is a long log of other AT commands (operator query, voice and data service query, etc.), fed to the modem by some other script - which one? And this script uses AT+ACT only, not ATD*99***1. Thus /etc/chatscripts/datakey_start is not actually run! Yet the modem goes online (probably automatically by setting an active content, this may be a feature of its firmware), otherwise LCP negotiation would never begin and IP addresses (correct and specific for the operator) would be never received.
Click to expand...
Click to collapse
EDIT: You probably won't see ATD*99***1 on the logcat as /system/xbin/chat which calls datakey_start doesn't provide any logcat output as far as I'm aware, You can try remove the chat binary or the datakey_start script to confirm if it's needed although you'd need root and an ext4 image for that as I don't think squashfs can be mounted as r/w.
Archos Manage the full process through their USBKeyManager.apk, this switches the device to modem mode, sets the rild.libargs and rild.libpath to the correct values and starts the ril-daemon.
The rild daemon is a service wrapper for /system/bin/rild, this is Android's Radio Interface Layer native controller, Rild, when started looks for rild.libargs and rild.libpath if it has no parameters passed. The rild.libargs property is the tty device used for Control Flow ( /dev/ttyHS3.) The most important part of the jigsaw is the rild.libpath property, which is set to /system/lib/libtcl-rild.so, this is the library which initializes the modem and calls pppd via the pppd_datakey service.
The /system/lib/libtcl-rild.so has logcat symbols AT, GSM and RIL and is responsible for the "long log of other AT commands"
doing a "strings" on this library reveals a lot and does show reference to pppd_datakey service as well as numerous AT commands.
The /system/lib/libtcl-rild.so would be were the crux of the problem is, although To Be Honest i'm still at a loss as to why you get 3 pppd starting
Unfortunately I can't logcat for you right now as I'm in the middle of development on CM10. one thing you might want to try however is
Code:
adb shell watchprops &
adb shell logcat -b system -b main -b radio -b events *:V
This will show what system properties are being set in real time and mix the logcat to provide a context.
EDIT:
@omegaRED7 - Thanks - You got in while I was typing.... maybe should make my posts less verbose :laugh:
omegaRED7 said:
Can you setup the APN? Can you force manual selection of the network operator? I really don't understand why, even if the connection is directly initiated by the RIL, it attempts 3 times, esp. since you're running a stock ROM....
Mind also posting the logcat part before the connection is established?
Click to expand...
Click to collapse
Yes, there is corerct APN in the log. Yes, I can manually select the operator, but I also need to select the correct APN out of the two (internet service and MMS service ones). Another problem that may also be related: for one minor operator the APN is not selected automatically, and I cannot add it manually via the regular interface. I fill all the necessary fields, but this is not saved. Yet it did work in the past!
Attached is my logcat from modem plug-in till looping.
iourine said:
Yes, there is corerct APN in the log. Yes, I can manually select the operator, but I also need to select the correct APN out of the two (internet service and MMS service ones). Another problem that may also be related: for one minor operator the APN is not selected automatically, and I cannot add it manually via the regular interface. I fill all the necessary fields, but this is not saved. Yet it did work in the past!
Attached is my logcat from modem plug-in till looping.
Click to expand...
Click to collapse
Hi
After looking that logcat I'd put that down to an issue with the libril-tcl, I've never seen that before and i've had multiple COPS entries on my simcard/modem albeit different carriers but still.
I think that leaves only one option, Report the "bug" to archos and wait .................... Only Joking, :laugh: this is Xda, we're not going to do that.
Got a couple of options from what I can see,
1.Remove the extra operators of the modem using minicom or similar
2.Hack the init_pppd_datakey script to check if pppd already running and exit if it is.
3. Try a different ril implementation. after all you only need to make a datacall and all the ril does in reality is initialize the modem and call out to pppd, even if you have to compile on yourself it shouldn't take much.
I would check calling the pppd_datakey service on it's own, like I suggested, it will definetly rule it out. and have a google to see if anyone has anything similar with the modem, doesn't even have to be with android.
I could be way off the mark with all this but It's just how I'd tackle it .
One "strange" thing on that logcat. I was surprised by the ril version being a v5, i'll double check that on mine.
Tried all the debug recommended above; not much help. PPP connection is established, ip-up-datakey appears to be run without errors, IP properties appear to be set. And then pppd exits immediately.
Tried running the connection manually. It is established, the interface named ppp1 is created, yet no routes and no resolv.conf are set.
Attached is my log with a couple of loops.
omegaRED7, there are multiple revisions of hardware sold under the same name "Archos 3G modem", with different PID/VIDs, from different vendors - not to speak about other 3G products. Surely it is not an easy thing to manage all this zoo. Surely Archos programmers could set a bug for a particular model at some point. Yet 3.80 software does not work too - and it did!
Until I had this problem my wifi worked great. The issue seemed to be related to (but may have nothing to do with) switching on airplane mode, while on a flight. Since then I've been unable to get wifi to enable without doing the following:
Emailing myself a logcat (I guess it could be anything in an email, this is just to alert me of a state change).
Setting the tablet in clock mode (so that it does not sleep).
Waiting.
Eventually (I assume after a reboot). The email gets sent and then I know wifi is back up. This is less than ideal as it used to take several hours, now it takes several days.
I have this problem regardless of whether I'm using a new ROM or a backup with a previously working wifi.
Sometimes you can change the button from "Off" to "On" in settings. It remains grey, the status remains "connecting to wifi" and then after a couple of minutes the button changes back to "Off"
Code:
09-11 08:51:46.489 I/SystemServer(239): NetworkStats Service
09-11 08:51:46.489 I/SystemServer(239): NetworkPolicy Service
09-11 08:51:46.499 I/SystemServer(239): Wi-Fi P2pService
09-11 08:51:46.499 I/SystemServer(239): Wi-Fi Service
09-11 08:51:46.519 I/SystemServer(239): Connectivity Service
09-11 08:51:46.519 D/ConnectivityService(239): ConnectivityService starting up
09-11 08:51:46.519 E/ConnectivityService(239): Ignoring protectedNetwork 10
09-11 08:51:46.519 E/ConnectivityService(239): Ignoring protectedNetwork 11
09-11 08:51:46.519 E/ConnectivityService(239): Ignoring protectedNetwork 12
09-11 08:51:46.529 D/NetworkManagementService(239): Registering observer
09-11 08:51:46.529 D/NetworkManagementService(239): Registering observer
09-11 08:51:46.529 I/WifiService(239): WifiService starting up with Wi-Fi enabled
09-11 08:51:46.539 I/SystemServer(239): Throttle Service
09-11 08:51:46.539 I/SystemServer(239): Mount Service
09-11 08:51:48.579 D/NetworkManagementService(239): Registering observer
09-11 08:51:49.549 D/NetworkManagementService(239): Registering observer
09-11 08:51:49.609 I/ActivityManager(239): Start proc android.process.media for broadcast
09-11 08:51:50.319 D/WifiService(239): New client listening to asynchronous messages
09-11 08:51:50.609 W/ThrottleService(239): unable to find stats for iface rmnet0
09-11 08:51:50.919 I/ActivityManager(239): Start proc com.google.process.gapps for service com.google.android.location/.NetworkLocationService: pid=503 uid=10043 gids={3003, 1015, 1007, 1006, 2001, 3006}
09-11 08:51:51.029 I/ActivityManager(239): Start proc com.android.settings for broadcast
09-11 08:52:01.849 D/NetworkManagementService(239): rsp <213 00:00:00:00:00:00 0.0.0.0 0 [down]>
09-11 08:52:01.849 D/NetworkManagementService(239): flags <[down]>
09-11 08:52:58.119 E/WifiHW (239): Supplicant not running, cannot connect
09-11 08:53:02.119 E/WifiStateMachine(239): Failed to setup control channel, restart supplicant
09-11 08:53:02.129 E/WifiStateMachine(239): Failed to reload STA firmware java.lang.IllegalStateException: Error communicating to native daemon
09-11 08:53:02.129 W/CommandListener(155): Failed to retrieve HW addr for wlan0 (No such device)
09-11 08:53:02.129 D/CommandListener(155): Setting iface cfg
09-11 08:53:02.129 D/NetworkManagementService(239): rsp <213 00:00:00:00:00:00 0.0.0.0 0 [down]>
09-11 08:53:02.129 D/NetworkManagementService(239): flags <[down]>
09-11 08:53:02.139 E/WifiStateMachine(239): Unable to change interface settings: java.lang.IllegalStateException: Unable to communicate with native daemon to interface setcfg - com.android.server.NativeDaemonConnectorException: Cmd {interface setcfg wlan0 0.0.0.0 0 [down]} failed with code 400 : {Failed to set address (No such device)}
09-11 08:53:02.259 I/wpa_supplicant(2313): rfkill: Cannot open RFKILL control device
09-11 08:53:02.259 E/wpa_supplicant(2313): Could not read interface wlan0 flags: No such device
09-11 08:53:03.299 E/wpa_supplicant(2313): nl80211: Could not set interface 'wlan0' UP
09-11 08:53:03.299 E/wpa_supplicant(2313): wlan0: Failed to initialize driver interface
09-11 08:53:17.149 E/WifiStateMachine(239): Failed 6 times to start supplicant, unload driver
09-11 08:53:17.149 E/WifiStateMachine(239): Failed to reload STA firmware java.lang.IllegalStateException: Error communicating to native daemon
09-11 08:53:17.159 D/CommandListener(155): Setting iface cfg
09-11 08:53:17.159 E/WifiStateMachine(239): Unable to change interface settings: java.lang.IllegalStateException: Unable to communicate with native daemon to interface setcfg - com.android.server.NativeDaemonConnectorException: Cmd {interface setcfg wlan0 0.0.0.0 0 [down]} failed with code 400 : {Failed to set address (No such device)}
09-11 08:53:17.159 D/NetworkManagementService(239): rsp <213 00:00:00:00:00:00 0.0.0.0 0 [down]>
09-11 08:53:17.159 D/NetworkManagementService(239): flags <[down]>
09-11 08:53:17.259 I/wpa_supplicant(2353): rfkill: Cannot open RFKILL control device
09-11 08:53:18.289 E/wpa_supplicant(2353): nl80211: Could not set interface 'wlan0' UP
Things I've tried (that I can remember, I may have forgotten some!):
Changing the wifi channel on the router.
Cycling to router
Logging into WebOS - toggling the wifi (Wifi works fine in WebOS)
What I don't get is why even a fresh ROM does not work and yet, WebOS is still working fine.
(Are there some conf files I can check? Is it likely they got changed somehow?).
I am currently running jcsullins cm-10-20130418-EXPERIMENTAL
Thanks in advance.
OK, after scouring dmesg it appears there is a conflict between the ath6kl driver and sdio. (I think I have a couple of jcsullins test drivers on my sd card, so I will try those next).
I'll include a dmesg tomorrow, but the gist of it is as follows:
Code:
ath6kl: temporary war to avoid sdio crc error
ath6kl: firmware crashed
ath6kl: crash dump:
ath6kl: hw 0x30000582 fw
ath6kl: invalid address for debug_hdr_addr
ath6kl: Failed to start hardware: -5
ath6kl: Failed to init ath6kl core
ath6kl_sdio: probe of mmcl:0001:1 failed with error -5 board_sdio_wifi_disable
tenderloin_wifi_power: New regulator mode for 8058_s3:1
mmcl: card 00001 removed
Can anyone please offer a suggestion?
Is there another kernel I can try?
Is there a wifi fix now for the ath6kl driver?
Hi All,
Need some help in getting my wifi and bluetooth back to normal. It's over a month now and all my attempts have failed! I would really appreciate some ideas here. Thank you, and sorry for long thread.
Phone info:
Samsung galaxy S6 SM-G920T (T-Mobile), firmware version: NRD90M.G920TUVS6FRC1, stock OS with root and TWRP recovery
Situation:
Bluetooth does not turn ON at all
Wifi takes a long time to turn ON, and only way to turn it ON is from settings (quick access tile does not work)
Wifi does not remember any password
All other functions work correctly, and the phone is now lightning fast after factory reset
Details and Steps Taken:
Rooted my phone a month ago, and started changing config. Took OS and app backup only, but no EFS/other partition backup.
Turned OFF "Allow OEM Unlock" - don't ask why
This (I believe) resulted in WIFI not remembering passwords, so after reviewing potential solutions, I changed "Secure.Storage" value in build.prop to "0"
Took backup of WPA_supplicant.conf and deleted the file
Problem was not resolved, and I had to restart the phone
Restart resulted in FRP lock - to resolve this I re-installed the OS from stock firmware from Sammobile; Yet - no luck on wifi and bluetooth, error still persisted
I reviewed the system log and found tons of errors (listed below). Based on errors, I tried:
Copying libbluetooth_jni.so library file to '/system/lib' and '/system/vendor/lib' folders
Changing 'semGetAllowBluetoothMode' value to "True" - this reduced some errors (refer below)
Validating file / folder permissions for the /efs partition - they seem to be appropriate, but I cannot confirm since there is no reference
I have also tried using SmartSwitch - but it doesn't recognize phone in download mode. It backups the apps, etc. though
Also wiped the system partition once using TWRP, and re-imaged. Yet no luck.
My hunch currently for these errors is:
The /efs permissions became incorrect or partition became corrupt due to some configuration I performed
The system lost its encryption key when the "OEM unlock" was disabled, and thus cannot read any files from the /system and /efs partition (the device was NOT encrypted, but I am thinking /efs is always encrypted by system - correct me if I am wrong)
System log snippets:
Bluetooth Related Log:
Bluetooth GATT service:
Code:
BtGatt.GattService: [GSIM LOG]: gsimLogHandler: null, msg: MESSAGE_LOAD_PREF
Bluetooth Adapter Service:
Code:
BluetoothAdapterService: onProfileServiceStateChanged() serviceName=com.android.bluetooth.gatt.GattService, state=12, Message sending
semGetAllowBluetoothMode:
Resolved this error by updating the value to "True" in build.prop. Was this the right fix, or is it supposed to get value = 2.
Code:
DevicePolicyManagerService: semGetAllowBluetoothMode - value retunrs : 2
Wifi error log:
Code:
WifiHW : ##################### set firmware type 0 #####################
WifiHW : ==========[WIFI] SEMCO MODULE ===========
WifiHW : TEMP_FAILURE_RETRY complete
NetworkManagement: wifiFirmwareReload Error reloading wlan0 fw in STA mode: event = 200 208 Softap operation succeeded
WifiMonitor: killSupplicant p2ptrue init.svc.wpa_supplicant=unknown init.svc.p2p_supplicant=unknown
WifiHW : supplicant_name : p2p_supplicant
WifiHW : Unable to open connection to supplicant on "@android:wpa_wlan0": No such file or directory
WifiWatchdogStateMachine: Unhandled message { when=0 what=135173 arg1=2 target=com.android.internal.util.StateMachine$SmHandler } in state NotConnectedState
WifiMonitor: startMonitoring(wlan0) failed!
WifiStateMachine: Failed to setup control channel, restart supplicant
WifiHAL : wifi_event_loop: Read after POLL returned 4, error no = 0
WifiHAL : wifi_cleanup: Read after POLL returned 4, error no = 2
WifiHAL : Event processing terminated
NetworkManagement: wifiFirmwareReload Error reloading wlan0 fw in STA mode: event = 200 219 Softap operation succeeded
NetworkManagement: wifiFirmwareReload Error reloading wlan0 fw in STA mode: event = 200 229 Softap operation succeeded
NetworkManagement: wifiFirmwareReload Error reloading wlan0 fw in STA mode: event = 200 240 Softap operation succeeded
NetworkManagement: wifiFirmwareReload Error reloading wlan0 fw in STA mode: event = 200 248 Softap operation succeeded
WifiHAL : wifi_event_loop: Read after POLL returned 4, error no = 11
NetworkManagement: wifiFirmwareReload Error reloading wlan0 fw in STA mode: event = 200 256 Softap operation succeeded
WifiStateMachine: Failed 6 times to start supplicant, unload driver
WifiStateMachine: sendErrorBroadcast code:10
WifiController: WifiControllerWifi turn on failed