vendor.libs.zip (6.6 MB)
Please try this libril.so and libreference-ril.so
Oh this time its doing something 
Did you manage to apply all of the waydroid patches or just the one i sent you ?
So whats happening currently is that the driver is loading and starting up but it seems like the binder ioctls freeze for quite a while. I’ll need to investigate a bit more before i can say for sure. Also i didn’t have a sim card inserted while i tested so maybe that affects things as well.
For now here is an up to date log file:
RIL_1_6_with_waydroid_patch.txt (178.6 KB)
I might have also broken something with android.hardware.radio.config@1.1::IRadioConfig/default doing all the testing so i should probably revert some things and start again 
Before you do anything else let me play around with that driver version for a few days and also ask in the waydroid community about the patches they did to hwbinder. This incompatibility should not occur in the first place so there is some work that needs to be done in the waydroid project as well.
I Downloaded the source code and try to apply the patches.
Although the whole compilation is not possible now, the ril related libraries can be compiled separately.
From the log, at least the rild is running now.
Please insert a sim card and test it.
Sorry it took me so long to get around to fully testing the new driver.
Here is what i found:
I reverted a bunch of stuff that I added while testing, added a bunch more telephone related apps and services to the waydroid android build, inserted a SIM card this time, checked the APN configuration and loaded the usbmon kernel module and forwarded the relevant device files to the lxc container.
The result of all of that is unfortunately somewhat the same as in my previous post…
While the driver seems to initialize fine (which in itself is already a big step forward ) and i can see sim and network information in android using apps that display it the modem does not seem to actually connect to the voice / data network.
What i mean by that is neither USSD codes nor phone calls do anything and the pppd fails to dial into the carriers access point.
Could this maybe be an incompatibility between the RIL driver and the modem firmware ? The modem is currently running:
VERSION: EC25EFAR08A02M4G
Nov 19 2020 10:37:01
Authors: QCT
This time I’ll provide the log files to you in a direct message since they now contain a bunch of sensitive information like phone numbers and cell ids which i would rather not post publicly.
Sorry. Have you sent me the android log?
Yes i did. On Apr 27 at 6:18 PM as a direct message.
https://forums.quectel.com/t/logs-for-my-latest-post/33431?u=lukasgossmann
Hi sir
04-27 17:24:39.839 D/RILU ( 204): find quectel module /sys/bus/usb/devices/1-3 idVendor=2c7c idProduct=0125
04-27 17:24:39.839 D/RILU ( 204): find_usb_device is 1
04-27 17:24:40.839 D/RILU ( 204): find /sys/bus/usb/devices/1-3:1.2/ttyUSB2
04-27 17:24:40.839 D/RILU ( 204): ttyAT = ttyUSB2
04-27 17:24:40.839 D/RILU ( 204): find /sys/bus/usb/devices/1-3:1.3/ttyUSB3
04-27 17:24:40.839 D/RILU ( 204): ttyPPP = ttyUSB3
04-27 17:24:40.839 D/RILU ( 204): find /sys/bus/usb/devices/1-3:1.0/ttyUSB0
04-27 17:24:40.839 D/RILU ( 204): ttyDM = ttyUSB0
04-27 17:24:40.839 D/RILU ( 204): find /sys/bus/usb/devices/1-3:1.1/ttyUSB1
04-27 17:24:40.839 D/RILU ( 204): ttyGPS = ttyUSB1
04-27 17:24:40.839 E/RILU ( 204): unknow bInterfaceClass=ff, bInterfaceSubClass=ffff
04-27 17:24:40.839 D/RILC ( 204): quectel at port is /dev/ttyUSB2
Please show the
cat /sys/kernel/debug/usb/devices
The ppp failed with exit code 8 for EXIT_CONNECT_FAILED.
Is it IPV6 only?
This is the relevant part of the output.
I had the UAC device enabled while running this command and all previous tests.
T: Bus=01 Lev=01 Prnt=01 Port=02 Cnt=01 Dev#= 4 Spd=480 MxCh= 0
D: Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=2c7c ProdID=0125 Rev= 3.18
S: Manufacturer=Quectel
S: Product=EC25-E
C:* #Ifs= 8 Cfg#= 1 Atr=a0 MxPwr=500mA
A: FirstIf#= 5 IfCount= 3 Cls=01(audio) Sub=00 Prot=00
I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
E: Ad=83(I) Atr=03(Int.) MxPS= 10 Ivl=32ms
E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
E: Ad=85(I) Atr=03(Int.) MxPS= 10 Ivl=32ms
E: Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
E: Ad=87(I) Atr=03(Int.) MxPS= 10 Ivl=32ms
E: Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan
E: Ad=89(I) Atr=03(Int.) MxPS= 8 Ivl=32ms
E: Ad=88(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 5 Alt= 0 #EPs= 0 Cls=01(audio) Sub=01 Prot=00 Driver=snd-usb-audio
I:* If#= 6 Alt= 0 #EPs= 0 Cls=01(audio) Sub=02 Prot=00 Driver=snd-usb-audio
I: If#= 6 Alt= 1 #EPs= 1 Cls=01(audio) Sub=02 Prot=00 Driver=snd-usb-audio
E: Ad=8a(I) Atr=05(Isoc) MxPS= 16 Ivl=1ms
I:* If#= 7 Alt= 0 #EPs= 0 Cls=01(audio) Sub=02 Prot=00 Driver=snd-usb-audio
I: If#= 7 Alt= 1 #EPs= 1 Cls=01(audio) Sub=02 Prot=00 Driver=snd-usb-audio
E: Ad=06(O) Atr=09(Isoc) MxPS= 16 Ivl=1ms
So even though the RIL driver is complaining about an unknow bInterfaceClass=ff and bInterfaceSubClass=ffff its what the USB device is reporting all on its own…
Also i found a post where a colleague of yours provided a screenshot of the same command for what i believe is also and EC25.
The output there is exactly the same as with mine so i guess that is correct.
I did not specifically configure anything to be IPv6 only as far as i am aware.
The linux host supports both and the android image has settings in its properties file for enabling both. I dont know about the carrier though and how i should check that.
Do you have the qmi_wwan_q.c?
Please replace the qmi_wwan.c with the qmi_wwan_q.c from Quectel.
I will provide the libreference-ril.so later.
Because the qmi driver do not work and so it try the ppp.
But I don’t know the ppp failed from the log.
Yes i do have to qmi_wwan_q.c.
It’ll take me a couple of days to integrate that into the kernel and then I’ll report back.
I also noticed that i completely forgot to forward the qmi network interface to the LXC container… 
The network interface already exists with the default driver provided by the kernel so i tried that to see what would happen.
Doing that alone (without adding qmi_wwan_q.c) has not gotten me any different results yet though.
Do i understand correctly that qmi is the default the driver will try and PPP is only a fallback when qmi fails ?
Why do i need a different libreference-ril.so then ?
As for PPP not working. I think i may have an idea why that is.
There is in the log file:
04-27 17:24:45.140 D/SETUP_DATA_CALL( 204): s_default_pdp = 1
04-27 17:24:45.140 D/SETUP_DATA_CALL( 204): profile id = -1
04-27 17:24:45.140 D/SETUP_DATA_CALL( 204): pdp = 1
04-27 17:24:45.140 I/SETUP_DATA_CALL( 204): *************************************
04-27 17:24:45.140 I/SETUP_DATA_CALL( 204): USER:
04-27 17:24:45.140 I/SETUP_DATA_CALL( 204): PASS:
04-27 17:24:45.140 I/SETUP_DATA_CALL( 204): auth_type:(null)
04-27 17:24:45.140 I/SETUP_DATA_CALL( 204): pdp_type:IPV4V6
04-27 17:24:45.140 I/SETUP_DATA_CALL( 204): *************************************
The auth type for my carrier should be PAP / CHAP. (Thats whats configured in the APNs) Yet there its listed as (null).
Could that maybe be the issue ?
Not that it hugely matters when it should be using qmi instead of ppp anyway
By default it will try the qmi to set up data call.
But if there is any problems with qmi driver, it would try ppp.
You can set the authtype in the apns-conf.xml.
So i have some good news but also some bad news…
First of all the good news:
The qmi_wwan_q driver is working and i can now get both the new RIL 1.6 (V4.0.1-0507) and the old RIL 1.1 (V3.6.35) driver to use QMI instead of PPP so that’s awesome
However I’d strongly recommend that you update the driver for newer kernel versions (6.1.0 in my case) as it doesn’t build without some (minor) modifications.
I’m refering to the qmi_wwan_q.c file contained in the package that can be downloaded here btw:
https://www.quectel.com/ProductDownload/EC25.html
Now the bad news:
While the RIL 1.6 driver now works with cellular data using QMI its still unable to start a call and run USSD codes…
Some things i observed while testing:
Out of curiosity i went back and tried the RIL 1.1 driver again and noticed the same USER, PASS and auth output as in my previous post. However with that old version it actually printed different values:
05-08 21:22:50.983 I/SETUP_DATA_CALL( 201): *************************************
05-08 21:22:50.983 I/SETUP_DATA_CALL( 201): USER:
05-08 21:22:50.983 I/SETUP_DATA_CALL( 201): PASS:
05-08 21:22:50.983 I/SETUP_DATA_CALL( 201): auth_type:3
05-08 21:22:50.983 I/SETUP_DATA_CALL( 201): pdp_type:IPV4V6
05-08 21:22:50.983 I/SETUP_DATA_CALL( 201): *************************************
So it looks like something is not working properly in the RIL 1.6 driver since the auth_type gets lost somewhere…
The apns-config.xml is the one provided by google as apns-full-config.xml.
Nothing except the RIL driver has been changes about the android system between these tests.
As last time i sent you some logs through a private message.
Please see here:
https://forums.quectel.com/t/again-more-logs/33753
Here is the qmi_wwan_q.
That webpage is out of date.
Quectel_Linux_Android_QMI_WWAN_Driver_V1.2.7.zip (801.4 KB)
I will check the log.
Sorry I know little about the USSD and I will study it.
Could you tell the Android Java API of the USSD?
Oh ok thats good to know…
Well at least the up to date wwan driver build without issues and seems to work just fine so thanks a lot
For testing the USSD codes i just use the normal android Dialer app.
Typing in for example *100# will display a small popup message after a couple of seconds that shows my current prepaid balance. (This code is carrier specific).
Also as a follow up menu i can book prepaid options etc. through that as well.
Here is some screenshots of what that looks like on my OnePlus 3:
Here i typed in a 4 and pressed send
This is the result
Fun fact: A friend of mine still uses a Nokia 3310 (different carrier) and USSD codes even work on this old thing. *100# will get him a small message popup too showing his current prepaid balance (without the menu of my carrier though)
Besides that i don’t think that you need to specifically look into why USSD isn’t working as to me it seems like that’s just a symptom of the modem not doing the PAP / CHAP authentication with the 2G/GSM part of the network.
What makes me think that is that everything related to this part of the cellular network isn’t working.Calls (as long as they aren’t VoLTE) definitely do use GSM and USSD codes run on the GSM part of the network too as far as i know.
Would it be possible for you to make a test build of the RIL driver that has a hard coded auth_type:3 instead of getting it from the carrier config provider ?
That would prove if the information about the auth type getting lost somewhere / not being obtained properly in the RIL 1.6 diver is actually the case since the logs clearly show that happening (auth_type:(null))
So i was wondering.
Is it possible to obtain a copy of the RIL driver source code so i can do the debugging and fixing of any issues myself ?
I do really appreciate the effort on your side but going back and forth like this is not very time or cost effective for either quectel or myself.
If needed id be ok with signing a no disclosure agreement or the like and i would also provide any changes i make to the driver back to you guys.
Please let me know if that is somehow possible because getting this cellular modem working is holding up my entire project and there is still a lot of other things i need to get working after that that do depend on this basic functionality of a phone actually working.