Advent Vega kernel source code now available!

[Guest MikhailM]

There are no errors , except that the pppd daemon is not getting a response from the network provider :S ... I slightly changed the timings, and rverted the connection method to the one we were using in the huawei ril as we got it from the androidx86 project (only the connection procedure, as all the other methods work way better on our version...) ...

Hope this time it works as expected :)

Maybe it would be better if it worked "as desired", rather than "as expected"? :)

[Guest univall]

There are no errors , except that the pppd daemon is not getting a response from the network provider :S ... I slightly changed the timings, and rverted the connection method to the one we were using in the huawei ril as we got it from the androidx86 project (only the connection procedure, as all the other methods work way better on our version...) ...

Hope this time it works as expected :)

Sorry, no 3g still. I have added full and radio logs from 3 service providers (MTNL, Airtel and Vodafone). MTNL gives a username - password, the other two do not. Please see compressed file.

Note: We still do not get a Service Provider name on the taskbar until we switch wifi on and connect to it. Can Scanno inspect the framework files to make sure some bug from the wifi config is not affecting the 3g.

Note 2: I have added logs (full and radio) with wifi switched on and connected. Maybe these additional logs reveal something new.

ril-24082012-v1-logs.tar.gz

ril-wifi-onmtnl-full-log-24082012-v1.txt

ril-wifi-on-mtnl-radio-log-24082012-v1.txt

Edited August 24, 2012 by univall

[Guest ejtagle]

Sorry, no 3g still. I have added full and radio logs from 3 service providers (MTNL, Airtel and Vodafone). MTNL gives a username - password, the other two do not. Please see compressed file.

Note: We still do not get a Service Provider name on the taskbar until we switch wifi on and connect to it. Can Scanno inspect the framework files to make sure some bug from the wifi config is not affecting the 3g.

Note 2: I have added logs (full and radio) with wifi switched on and connected. Maybe these additional logs reveal something new.

According to the logs, you are connected ! :D

I/pppd ( 1055): pppd options in effect:

I/pppd ( 1055): debug # (from command line)

I/pppd ( 1055): nodetach # (from command line)

I/pppd ( 1055): linkname ril1 # (from command line)

I/pppd ( 1055): connect-delay 5000 # (from command line)

I/pppd ( 1055): dump # (from command line)

I/pppd ( 1055): user mtnl # (from command line)

I/pppd ( 1055): password ?????? # (from command line)

I/pppd ( 1055): /dev/ttyUSB0 # (from command line)

I/pppd ( 1055): 115200 # (from command line)

I/pppd ( 1055): mru 1280 # (from command line)

I/pppd ( 1055): lcp-echo-failure 0 # (from command line)

I/pppd ( 1055): lcp-echo-interval 0 # (from command line)

I/pppd ( 1055): novj # (from command line)

I/pppd ( 1055): novjccomp # (from command line)

I/pppd ( 1055): ipcp-accept-local # (from command line)

I/pppd ( 1055): ipcp-accept-remote # (from command line)

I/pppd ( 1055): noipdefault # (from command line)

I/pppd ( 1055): ipcp-max-terminate 10 # (from command line)

I/pppd ( 1055): ipcp-max-configure 30 # (from command line)

I/pppd ( 1055): ipcp-max-failure 30 # (from command line)

I/pppd ( 1055): defaultroute # (from command line)

I/pppd ( 1055): usepeerdns # (from command line)

D/pppd ( 1055): using channel 1

I/pppd ( 1055): Using interface ppp0

I/pppd ( 1055): Connect: ppp0 <--> /dev/ttyUSB0

D/pppd ( 1055): sent [LCP ConfReq id=0x1 <mru 1280> <asyncmap 0x0> <magic 0x4bda75f2> <pcomp> <accomp>]

D/pppd ( 1055): rcvd [LCP ConfReq id=0x0 <asyncmap 0x0> <auth chap MD5> <magic 0xf5b8e5> <pcomp> <accomp>]

D/pppd ( 1055): sent [LCP ConfAck id=0x0 <asyncmap 0x0> <auth chap MD5> <magic 0xf5b8e5> <pcomp> <accomp>]

D/pppd ( 1055): rcvd [LCP ConfAck id=0x1 <mru 1280> <asyncmap 0x0> <magic 0x4bda75f2> <pcomp> <accomp>]

D/pppd ( 1055): rcvd [LCP DiscReq id=0x1 magic=0xf5b8e5]

D/pppd ( 1055): rcvd [CHAP Challenge id=0x1 <0cad33787a2ca688ac43b25528fd782a>, name = "UMTS_CHAP_SRVR"]

D/pppd ( 1055): sent [CHAP Response id=0x1 <db2b3bcbd162faea9908c42d058732ef>, name = "mtnl"]

D/pppd ( 1055): rcvd [CHAP Success id=0x1 ""]

I/pppd ( 1055): CHAP authentication succeeded

D/pppd ( 1055): sent [CCP ConfReq id=0x1 <deflate 15> <deflate(old#) 15> <bsd v1 15>]

D/pppd ( 1055): sent [iPCP ConfReq id=0x1 <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>]

D/pppd ( 1055): rcvd [LCP ProtRej id=0x2 80 fd 01 01 00 0f 1a 04 78 00 18 04 78 00 15 03 2f]

D/pppd ( 1055): rcvd [iPCP ConfNak id=0x1 <ms-dns1 10.11.12.13> <ms-dns3 10.11.12.14> <ms-wins 10.11.12.13> <ms-wins 10.11.12.14>]

D/pppd ( 1055): sent [iPCP ConfReq id=0x2 <addr 0.0.0.0> <ms-dns1 10.11.12.13> <ms-dns3 10.11.12.14>]

D/pppd ( 1055): rcvd [iPCP ConfNak id=0x2 <ms-dns1 10.11.12.13> <ms-dns3 10.11.12.14> <ms-wins 10.11.12.13> <ms-wins 10.11.12.14>]

D/pppd ( 1055): sent [iPCP ConfReq id=0x3 <addr 0.0.0.0> <ms-dns1 10.11.12.13> <ms-dns3 10.11.12.14>]

D/pppd ( 1055): rcvd [iPCP ConfNak id=0x3 <ms-dns1 10.11.12.13> <ms-dns3 10.11.12.14> <ms-wins 10.11.12.13> <ms-wins 10.11.12.14>]

D/pppd ( 1055): sent [iPCP ConfReq id=0x4 <addr 0.0.0.0> <ms-dns1 10.11.12.13> <ms-dns3 10.11.12.14>]

D/pppd ( 1055): rcvd [iPCP ConfReq id=0x0]

D/pppd ( 1055): sent [iPCP ConfNak id=0x0 <addr 0.0.0.0>]

D/pppd ( 1055): rcvd [iPCP ConfNak id=0x4 <addr 120.58.151.18> <ms-dns1 59.179.243.70> <ms-dns3 203.94.243.70>]

D/pppd ( 1055): sent [iPCP ConfReq id=0x5 <addr 120.58.151.18> <ms-dns1 59.179.243.70> <ms-dns3 203.94.243.70>]

D/pppd ( 1055): rcvd [iPCP ConfReq id=0x1]

D/pppd ( 1055): sent [iPCP ConfAck id=0x1]

D/pppd ( 1055): rcvd [iPCP ConfAck id=0x5 <addr 120.58.151.18> <ms-dns1 59.179.243.70> <ms-dns3 203.94.243.70>]

W/pppd ( 1055): Could not determine remote IP address: defaulting to 10.64.64.64

I/pppd ( 1055): local IP address 120.58.151.18

I/pppd ( 1055): remote IP address 10.64.64.64

I/pppd ( 1055): primary DNS address 59.179.243.70

I/pppd ( 1055): secondary DNS address 203.94.243.70

The problem seems now to be the RIL, not being able to detect that the IP is up... It takes about 20 seconds to detect that situation...

E/RIL ( 106): Timeout waiting net.ppp0.local-ip - giving up!

E/RIL ( 106): Unable to setup PDP

... This property net.ppp0.local-ip should be set in the ip-up script... Please, check the ip-up script, and alos, query using

getprop net.ppp0.local-ip

When a 3G network connection is established, this property should be set...

Edited August 24, 2012 by ejtagle

[Guest univall]

According to the logs, you are connected ! :D

I/pppd ( 1055): pppd options in effect:

I/pppd ( 1055): debug # (from command line)

I/pppd ( 1055): nodetach # (from command line)

I/pppd ( 1055): linkname ril1 # (from command line)

I/pppd ( 1055): connect-delay 5000 # (from command line)

I/pppd ( 1055): dump # (from command line)

I/pppd ( 1055): user mtnl # (from command line)

I/pppd ( 1055): password ?????? # (from command line)

I/pppd ( 1055): /dev/ttyUSB0 # (from command line)

I/pppd ( 1055): 115200 # (from command line)

I/pppd ( 1055): mru 1280 # (from command line)

I/pppd ( 1055): lcp-echo-failure 0 # (from command line)

I/pppd ( 1055): lcp-echo-interval 0 # (from command line)

I/pppd ( 1055): novj # (from command line)

I/pppd ( 1055): novjccomp # (from command line)

I/pppd ( 1055): ipcp-accept-local # (from command line)

I/pppd ( 1055): ipcp-accept-remote # (from command line)

I/pppd ( 1055): noipdefault # (from command line)

I/pppd ( 1055): ipcp-max-terminate 10 # (from command line)

I/pppd ( 1055): ipcp-max-configure 30 # (from command line)

I/pppd ( 1055): ipcp-max-failure 30 # (from command line)

I/pppd ( 1055): defaultroute # (from command line)

I/pppd ( 1055): usepeerdns # (from command line)

D/pppd ( 1055): using channel 1

I/pppd ( 1055): Using interface ppp0

I/pppd ( 1055): Connect: ppp0 <--> /dev/ttyUSB0

D/pppd ( 1055): sent [LCP ConfReq id=0x1 <mru 1280> <asyncmap 0x0> <magic 0x4bda75f2> <pcomp> <accomp>]

D/pppd ( 1055): rcvd [LCP ConfReq id=0x0 <asyncmap 0x0> <auth chap MD5> <magic 0xf5b8e5> <pcomp> <accomp>]

D/pppd ( 1055): sent [LCP ConfAck id=0x0 <asyncmap 0x0> <auth chap MD5> <magic 0xf5b8e5> <pcomp> <accomp>]

D/pppd ( 1055): rcvd [LCP ConfAck id=0x1 <mru 1280> <asyncmap 0x0> <magic 0x4bda75f2> <pcomp> <accomp>]

D/pppd ( 1055): rcvd [LCP DiscReq id=0x1 magic=0xf5b8e5]

D/pppd ( 1055): rcvd [CHAP Challenge id=0x1 <0cad33787a2ca688ac43b25528fd782a>, name = "UMTS_CHAP_SRVR"]

D/pppd ( 1055): sent [CHAP Response id=0x1 <db2b3bcbd162faea9908c42d058732ef>, name = "mtnl"]

D/pppd ( 1055): rcvd [CHAP Success id=0x1 ""]

I/pppd ( 1055): CHAP authentication succeeded

D/pppd ( 1055): sent [CCP ConfReq id=0x1 <deflate 15> <deflate(old#) 15> <bsd v1 15>]

D/pppd ( 1055): sent [iPCP ConfReq id=0x1 <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>]

D/pppd ( 1055): rcvd [LCP ProtRej id=0x2 80 fd 01 01 00 0f 1a 04 78 00 18 04 78 00 15 03 2f]

D/pppd ( 1055): rcvd [iPCP ConfNak id=0x1 <ms-dns1 10.11.12.13> <ms-dns3 10.11.12.14> <ms-wins 10.11.12.13> <ms-wins 10.11.12.14>]

D/pppd ( 1055): sent [iPCP ConfReq id=0x2 <addr 0.0.0.0> <ms-dns1 10.11.12.13> <ms-dns3 10.11.12.14>]

D/pppd ( 1055): rcvd [iPCP ConfNak id=0x2 <ms-dns1 10.11.12.13> <ms-dns3 10.11.12.14> <ms-wins 10.11.12.13> <ms-wins 10.11.12.14>]

D/pppd ( 1055): sent [iPCP ConfReq id=0x3 <addr 0.0.0.0> <ms-dns1 10.11.12.13> <ms-dns3 10.11.12.14>]

D/pppd ( 1055): rcvd [iPCP ConfNak id=0x3 <ms-dns1 10.11.12.13> <ms-dns3 10.11.12.14> <ms-wins 10.11.12.13> <ms-wins 10.11.12.14>]

D/pppd ( 1055): sent [iPCP ConfReq id=0x4 <addr 0.0.0.0> <ms-dns1 10.11.12.13> <ms-dns3 10.11.12.14>]

D/pppd ( 1055): rcvd [iPCP ConfReq id=0x0]

D/pppd ( 1055): sent [iPCP ConfNak id=0x0 <addr 0.0.0.0>]

D/pppd ( 1055): rcvd [iPCP ConfNak id=0x4 <addr 120.58.151.18> <ms-dns1 59.179.243.70> <ms-dns3 203.94.243.70>]

D/pppd ( 1055): sent [iPCP ConfReq id=0x5 <addr 120.58.151.18> <ms-dns1 59.179.243.70> <ms-dns3 203.94.243.70>]

D/pppd ( 1055): rcvd [iPCP ConfReq id=0x1]

D/pppd ( 1055): sent [iPCP ConfAck id=0x1]

D/pppd ( 1055): rcvd [iPCP ConfAck id=0x5 <addr 120.58.151.18> <ms-dns1 59.179.243.70> <ms-dns3 203.94.243.70>]

W/pppd ( 1055): Could not determine remote IP address: defaulting to 10.64.64.64

I/pppd ( 1055): local IP address 120.58.151.18

I/pppd ( 1055): remote IP address 10.64.64.64

I/pppd ( 1055): primary DNS address 59.179.243.70

I/pppd ( 1055): secondary DNS address 203.94.243.70

The problem seems now to be the RIL, not being able to detect that the IP is up... It takes about 20 seconds to detect that situation...

E/RIL ( 106): Timeout waiting net.ppp0.local-ip - giving up!

E/RIL ( 106): Unable to setup PDP

... This property net.ppp0.local-ip should be set in the ip-up script...

I can input commands in the android shell by hand if that would help determine the error ...?

[Guest ejtagle]

I can input commands in the android shell by hand if that would help determine the error ...?

That is the idea.. getprop and setprop are android command line tools ;)

[Guest ejtagle]

The idea to test and find out what is happening is to look at the logcat and do a grep pppd on it. If there is no message telling about modem hangup, it means pppd was able to connect to the 3g network.

We must find out if the ip-up script was executed by pppd at the end of the bring up process.

If you look at that script, you will find that the script sets the property net.ppp0.local-ip to the ip of the ppp0 network interface. That is what the ril waits for, and if it does not the property set to a value, then assumes the pppd daemon failed to establish a connection to the 3G networkitI find no reason for this to fail, so, either pppd is not executing the script, or it is not finding it, or has no permissions to execute it, or the script has no permissions to set those properties...

[Guest univall]

The idea to test and find out what is happening is to look at the logcat and do a grep pppd on it. If there is no message telling about modem hangup, it means pppd was able to connect to the 3g network.

We must find out if the ip-up script was executed by pppd at the end of the bring up process.

If you look at that script, you will find that the script sets the property net.ppp0.local-ip to the ip of the ppp0 network interface. That is what the ril waits for, and if it does not the property set to a value, then assumes the pppd daemon failed to establish a connection to the 3G networkitI find no reason for this to fail, so, either pppd is not executing the script, or it is not finding it, or has no permissions to execute it, or the script has no permissions to set those properties...

Tough to figure out what is working here...

# From /out/target/product/shuttle/system/etc/ppp/ip-up and /device/nvidia/shuttle/files/etc/ppp/ip-up following lines exist

/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 "net.$NAME.remote-ip" "$IPREMOTE"

/system/bin/setprop "net.$NAME.gw" "$IPREMOTE"

# After a few minutes of booting logcat logs the error below --

W/ThrottleService( 280): unable to find stats for iface ppp0

W/SocketClient( 104): write error (Broken pipe)

# getprop

getprop net.ppp0.local-ip # returns blank line

Please see getprop returned values in text file attached.

Hope this helps.

getprop.txt

[Guest ejtagle]

Tough to figure out what is working here...

# From /out/target/product/shuttle/system/etc/ppp/ip-up and /device/nvidia/shuttle/files/etc/ppp/ip-up following lines exist

/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 "net.$NAME.remote-ip" "$IPREMOTE"

/system/bin/setprop "net.$NAME.gw" "$IPREMOTE"

# After a few minutes of booting logcat logs the error below --

W/ThrottleService( 280): unable to find stats for iface ppp0

W/SocketClient( 104): write error (Broken pipe)

# getprop

getprop net.ppp0.local-ip # returns blank line

Please see getprop returned values in text file attached.

Hope this helps.

It would be interesting to modify the ip-up script to , for example, do a

touch /data/.wasexecd

Maybe the problem is that to execute the setprop command line, the script must be executed by root,or at least, be suid root...

There is an easy way to check manually if the ppp0 interface is up. Just do a

cat /sys/class/net/ppp0/operstate

It the interface ppp0 exists, and it is up, you will see 'up'

as the operstate

Edited August 25, 2012 by ejtagle

[Guest univall]

It would be interesting to modify the ip-up script to , for example, do a

touch /data/.wasexecd

Maybe the problem is that to execute the setprop command line, the script must be executed by root,or at least, be suid root...

There is an easy way to check manually if the ppp0 interface is up. Just do a

cat /sys/class/net/ppp0/operstate

It the interface ppp0 exists, and it is up, you will see 'up'

as the operstate

Results --

root@android:/ # su

root@android:/ # touch /data/.wasexecd

root@android:/ # cat /sys/class/net/ppp0/operstate

unknown

root@android:/ #

Another attempt after reboot --

manager@pc:~/android/platform-tools$ ./adb shell

root@android:/ # su

root@android:/ # touch /data/.wasexecd

root@android:/ # cat /sys/class/net/ppp0/operstate

sh: cat: /sys/class/net/ppp0/operstate: No such file or directory

1|root@android:/ #

Edited August 25, 2012 by univall

[Guest Scanno]

@All,

You can do a repo sync. JRO03L is added. Changes in the framework have been merged. The audio_policy.conf that fixes HDMI audio is added. The huaweigeneric from 24 aug has been added also.

[Guest univall]

@All,

You can do a repo sync. JRO03L is added. Changes in the framework have been merged. The audio_policy.conf that fixes HDMI audio is added. The huaweigeneric from 24 aug has been added also.

Logs from new build (with latest repo sync) -- no change in 3g data status and all other associated observations (cell network name appears on task bar only after wifi is switched on and connected).

r4-log.txt

radio-r4-log.txt

[Guest ejtagle]

Well, logs show that there is a 3G connection set up by the pppd daemon, but the huaweigenericril does not detect it, telling android no connection available. I modified the libhuaweigeneric and also the ip-up and ip-down scripts to try to fix it. Attached the new version ...

etc.rar

huawei-generic-26aug.rar

[Guest univall]

Well, logs show that there is a 3G connection set up by the pppd daemon, but the huaweigenericril does not detect it, telling android no connection available. I modified the libhuaweigeneric and also the ip-up and ip-down scripts to try to fix it. Attached the new version ...

I dare say that we seem to be nearly there. :-)

But, still no 3g data. Please see logs.

full-log-26812-v2.txt

radio-24812-v2.txt

[Guest ejtagle]

I dare say that we seem to be nearly there. :-)

But, still no 3g data. Please see logs.

The same ril, but reverting the way to start data context to the one used in androidx86. Use the latest ip-up/down scripts attached on my previous post. I see on logs that the ATD*99***1# is the only working way to start communications....

huawei-generic-26aug-v2.rar

[Guest Daedric1383]

Some time ago we were talking about moving /data to the sdcard.

Recently, this popped up, can it be coppied ? http://forum.xda-dev...d.php?t=1843062

Edited August 26, 2012 by Daedric1383

[Guest ejtagle]

Some time ago we were talking about moving /data to the sdcard.

Recently, this popped up, can it be coppied ? http://forum.xda-dev...d.php?t=1843062

Yes, it can be implemented, if needed... I would make it optional, nevertheless...

[Guest univall]

The same ril, but reverting the way to start data context to the one used in androidx86. Use the latest ip-up/down scripts attached on my previous post. I see on logs that the ATD*99***1# is the only working way to start communications....

Edit: Please ignore earlier error message.

Please see logs. We still do not have 3g data.

full-log-24812-v4.txt

radio-24812-v4.txt

Edited August 27, 2012 by univall

[Guest ejtagle]

Right now working on the voice call ... ;) ... I managed to get audio and send audio ... But, i have to improve synchronization between the huawei audio sampling rate and the shuttle mixer sampling rate... otherwise, they tend to begin skipping audio...

[Guest fosser2]

ejtagle,

I was wondering what you used as the "backbone" for the tegra_alc5624.c you wrote? Or did you write that entire file from scratch? We have tegra_alc5623.c and I'm looking for an updated version for our 3.1 kernel (hoping it will fix our mic issues). I found tegra_alc5632.c from the AC100 guys but that was the closest I could find. Are we stuck re-writing this file, or do you know of another source? Thanks.

-fosser2

[Guest ejtagle]

ejtagle,

I was wondering what you used as the "backbone" for the tegra_alc5624.c you wrote? Or did you write that entire file from scratch? We have tegra_alc5623.c and I'm looking for an updated version for our 3.1 kernel (hoping it will fix our mic issues). I found tegra_alc5632.c from the AC100 guys but that was the closest I could find. Are we stuck re-writing this file, or do you know of another source? Thanks.

-fosser2

It was written based on the tegra_*.c found in the nvidia git (rel15r7) ... You can also use the one i posted in the Advent vega2 thread on this forum... Maybe it is closer to what you need (rt5631 = alc5631) ... http://www.modaco.com/topic/356929-attempt-to-reverse-engineer-the-n10-kernel/

Your mic issues are probably caused by some codec registers not being initialized... You are probably depending on power up values, and those values do not always work... I also had those problems with the rt5631 codec, and was able to fix them by completely programming the audio capture route in the audio_hw.c android sound driver ;)

[Guest ejtagle]

Edit: Please ignore earlier error message.

Please see logs. We still do not have 3g data.

Really i have no idea on the causes... The network provider is refusing access to the 3G network... It accepts authentication, but then forces the modem to hang...

Attached a new version, but i am guessing.... There is no clue on the logs on the cause of that last problem...

huawei-generic-27aug.rar

[Guest univall]

Really i have no idea on the causes... The network provider is refusing access to the 3G network... It accepts authentication, but then forces the modem to hang...

Attached a new version, but i am guessing.... There is no clue on the logs on the cause of that last problem...

I am trying once with another network provider. Will get back.

Btw, I see the following message in the logs --

I/pppd ( 1143): defaultroute # (from command line)

I/pppd ( 1143): usepeerdns # (from command line)

D/pppd ( 1143): using channel 5

I/pppd ( 1143): Using interface ppp0

I/pppd ( 1143): Connect: ppp0 <--> /dev/ttyUSB0

D/pppd ( 1143): sent [LCP ConfReq id=0x1 <mru 1280> <asyncmap 0x0> <magic 0xe8dc0012> <pcomp> <accomp>]

D/pppd ( 1143): rcvd [LCP ConfReq id=0x0 <asyncmap 0x0> <auth chap MD5> <magic 0xf890fe> <pcomp> <accomp>]

D/pppd ( 1143): sent [LCP ConfAck id=0x0 <asyncmap 0x0> <auth chap MD5> <magic 0xf890fe> <pcomp> <accomp>]

D/pppd ( 1143): rcvd [LCP ConfAck id=0x1 <mru 1280> <asyncmap 0x0> <magic 0xe8dc0012> <pcomp> <accomp>]

D/pppd ( 1143): rcvd [LCP DiscReq id=0x1 magic=0xf890fe]

D/pppd ( 1143): rcvd [CHAP Challenge id=0x1 <142300270c0aff7966d8ec561e3d73d7>, name = "UMTS_CHAP_SRVR"]

D/pppd ( 1143): sent [CHAP Response id=0x1 <7586501ef6fc3ed57736f83e98d8c865>, name = "dummy"]

D/pppd ( 1143): rcvd [CHAP Success id=0x1 ""]

I/pppd ( 1143): CHAP authentication succeeded

D/pppd ( 1143): sent [CCP ConfReq id=0x1 <deflate 15> <deflate(old#) 15> <bsd v1 15>]

D/pppd ( 1143): sent [iPCP ConfReq id=0x1 <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>]

D/pppd ( 1143): rcvd [LCP ProtRej id=0x2 80 fd 01 01 00 0f 1a 04 78 00 18 04 78 00 15 03 2f]

I/pppd ( 1143): Modem hangup

I/pppd ( 1143): Connection terminated.

W/Netd ( 104): No subsystem found in netlink event

D/NetlinkEvent( 104): Unexpected netlink message. type=0x11

This is a new one. Or am I wrong?

I am adding 2 sets of logs. We are still not getting 3g data. These logs are with the 27-Aug RIL.

** BTW, I heard voice on a call dialed out from the tablet with a lot of crackling sound and fiddling with the speaker icon on the ui, saying that the called phone is not available, which may not be the case as the called phone was switched on and nearby. Otherwise calling and receiving calls is not as good as one of the earlier RIL versions (have to check the thread back in time to see which one actually worked well). Hanging up takes a long time and a reboot. Also, the tablet did not receive a call back from the phone. Some glitches, but voice on the call, for sure.

27augv1log-full.txt

27augv1log-radio.txt

2-27augv1log-full.txt

2-27augv1log-radio.txt

Edited August 27, 2012 by univall

[Guest ejtagle]

I am trying once with another network provider. Will get back.

Btw, I see the following message in the logs --

I/pppd ( 1143): defaultroute # (from command line)

I/pppd ( 1143): usepeerdns # (from command line)

D/pppd ( 1143): using channel 5

I/pppd ( 1143): Using interface ppp0

I/pppd ( 1143): Connect: ppp0 <--> /dev/ttyUSB0

D/pppd ( 1143): sent [LCP ConfReq id=0x1 <mru 1280> <asyncmap 0x0> <magic 0xe8dc0012> <pcomp> <accomp>]

D/pppd ( 1143): rcvd [LCP ConfReq id=0x0 <asyncmap 0x0> <auth chap MD5> <magic 0xf890fe> <pcomp> <accomp>]

D/pppd ( 1143): sent [LCP ConfAck id=0x0 <asyncmap 0x0> <auth chap MD5> <magic 0xf890fe> <pcomp> <accomp>]

D/pppd ( 1143): rcvd [LCP ConfAck id=0x1 <mru 1280> <asyncmap 0x0> <magic 0xe8dc0012> <pcomp> <accomp>]

D/pppd ( 1143): rcvd [LCP DiscReq id=0x1 magic=0xf890fe]

D/pppd ( 1143): rcvd [CHAP Challenge id=0x1 <142300270c0aff7966d8ec561e3d73d7>, name = "UMTS_CHAP_SRVR"]

D/pppd ( 1143): sent [CHAP Response id=0x1 <7586501ef6fc3ed57736f83e98d8c865>, name = "dummy"]

D/pppd ( 1143): rcvd [CHAP Success id=0x1 ""]

I/pppd ( 1143): CHAP authentication succeeded

D/pppd ( 1143): sent [CCP ConfReq id=0x1 <deflate 15> <deflate(old#) 15> <bsd v1 15>]

D/pppd ( 1143): sent [iPCP ConfReq id=0x1 <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>]

D/pppd ( 1143): rcvd [LCP ProtRej id=0x2 80 fd 01 01 00 0f 1a 04 78 00 18 04 78 00 15 03 2f]

I/pppd ( 1143): Modem hangup

I/pppd ( 1143): Connection terminated.

W/Netd ( 104): No subsystem found in netlink event

D/NetlinkEvent( 104): Unexpected netlink message. type=0x11

This is a new one. Or am I wrong?

I am adding 2 sets of logs. We are still not getting 3g data. These logs are with the 27-Aug RIL.

** BTW, I heard voice on a call dialed out from the tablet with a lot of crackling sound and fiddling with the speaker icon on the ui, saying that the called phone is not available, which may not be the case as the called phone was switched on and nearby. Otherwise calling and receiving calls is not as good as one of the earlier RIL versions (have to check the thread back in time to see which one actually worked well). Hanging up takes a long time and a reboot. Also, the tablet did not receive a call back from the phone. Some glitches, but voice on the call, for sure.

Yes, there is a bug in the audioloop implementation that routes audio from modem to speakers... It fails to disable the loop when the call ends, and , while trying to end the loop, it lock the RIL, so no more access to the 3g modem... I have to fix that ...

[Guest univall]

Yes, there is a bug in the audioloop implementation that routes audio from modem to speakers... It fails to disable the loop when the call ends, and , while trying to end the loop, it lock the RIL, so no more access to the 3g modem... I have to fix that ...

FYI, In this implementation maybe due to the same reason (randomly (?) locked RIL):

- there is an issue with receiving calls (the call does not come through - no ring or display on ui)

- making a call doesn't always work

- signal display goes blank even with a few seconds of inactivity

- sms send receive not working

- 3g issues persist

[Guest ejtagle]

FYI, In this implementation maybe due to the same reason (randomly (?) locked RIL):

- there is an issue with receiving calls (the call does not come through - no ring or display on ui)

- making a call doesn't always work

- signal display goes blank even with a few seconds of inactivity

- sms send receive not working

- 3g issues persist

Probably caused by the same thing: The bug in the voice calls... I am working on that also, not trivial to implement, though, as slight mismatches in sampling rate between 3G modem and Android audio subsystem tend to cause severe glitches. I have to implement a software fast resampler that self adjusts to fix the sampling rate issues on the fly... Working on it...