• After 15+ years, we've made a big change: Android Forums is now Early Bird Club. Learn more here.

Root [DEV] Continuing Triumph ICS Development

NateMckn said:
I think I may have found how to fix the data limit issues (see http://androidforums.com/triumph-all-things-root/503210-data-usage-warning.html). Its definitely a kernel issue, but I have never built a kernel myself and I don't have the time today to figure that out, so I can't test this.

In the following file:
/net/netfilter/xt_socket.c

Comment out or delete lines 26-32:

Code: 
#if defined(CONFIG_IP6_NF_IPTABLES) || defined(CONFIG_IP6_NF_IPTABLES_MODULE)
#define XT_SOCKET_HAVE_IPV6 1
#include <linux/netfilter_ipv6/ip6_tables.h>
#include <net/ipv6.h>

#define nf_defrag_ipv6_enable()
#endif
My theory is that our kernel doesn't support nf_defrag_ipv6 and that part of the code is causing our data limit feature to be only half functional.

See here for an example:
https://github.com/CyanogenMod/andr...ory/blob/ics/Kernel/net/netfilter/xt_socket.c

If someone with kernel building ability could try that out for me, that would be great.

Disclaimer: I know very little about kernels so I could be completely off base here. Feel free to call me an idiot if this makes no sense.
Click to expand...

That part of the code should have 0 effect on our kernel. Here's the snippet again:

Code: 
#if defined(CONFIG_IP6_NF_IPTABLES) || defined(CONFIG_IP6_NF_IPTABLES_MODULE)
#define XT_SOCKET_HAVE_IPV6 1
#include <linux/netfilter_ipv6/ip6_tables.h>
#include <net/ipv6.h>

#define nf_defrag_ipv6_enable()
#endif

Neither CONFIG_IP6_NF_IPTABLES nor CONFIG_IP6_NF_IPTABLES_MODULE are defined so the IF statement should fail and bypass all of those defines.
 
mantera said:
That part of the code should have 0 effect on our kernel. Here's the snippet again:

Code: 
#if defined(CONFIG_IP6_NF_IPTABLES) || defined(CONFIG_IP6_NF_IPTABLES_MODULE)
#define XT_SOCKET_HAVE_IPV6 1
#include <linux/netfilter_ipv6/ip6_tables.h>
#include <net/ipv6.h>

#define nf_defrag_ipv6_enable()
#endif

Neither CONFIG_IP6_NF_IPTABLES nor CONFIG_IP6_NF_IPTABLES_MODULE are defined so the IF statement should fail and bypass all of those defines.
Click to expand...

Hmm... I'm kinda confused. When you say those two are not defined, that would be in the config file in /arch/arm/configs/, right?

If that's so, in there we have triumph_ics_defconfig and fb0_ics_config (among a ton of others). When you added net data quota three weeks ago, the changes were made to fb0_ics_config. That was because the commit was taken from edowar:

https://github.com/mantera/triumph-kernel-msm7x30/commit/942116ca30c86b3e50388fbe53c33068c8227efe

I assumed this meant that our kernel was using the fb0 config and it was close enough to work without any issues. If that is true, then CONFIG_IP6_NF_IPTABLES is defined and that snippet of code could be the problem. If my assumption is wrong, and we are using the triumph_ics_defconfig, then I think our problem is that the data limit config changes were not made to the correct config.

I'm having trouble finding where the config file is referenced so I can't confirm which one is being used.

I apologize if I'm way off track here. This is really the first time I've looked at kernel sources.
 
NateMckn said:
Hmm... I'm kinda confused. When you say those two are not defined, that would be in the config file in /arch/arm/configs/, right?

If that's so, in there we have triumph_ics_defconfig and fb0_ics_config (among a ton of others). When you added net data quota three weeks ago, the changes were made to fb0_ics_config. That was because the commit was taken from edowar:

https://github.com/mantera/triumph-kernel-msm7x30/commit/942116ca30c86b3e50388fbe53c33068c8227efe

I assumed this meant that our kernel was using the fb0 config and it was close enough to work without any issues. If that is true, then CONFIG_IP6_NF_IPTABLES is defined and that snippet of code could be the problem. If my assumption is wrong, and we are using the triumph_ics_defconfig, then I think our problem is that the data limit config changes were not made to the correct config.

I'm having trouble finding where the config file is referenced so I can't confirm which one is being used.

I apologize if I'm way off track here. This is really the first time I've looked at kernel sources.
Click to expand...

Yeah, I don't use those config files. Too much typing for my taste...

I use this one:

https://github.com/mantera/triumph-kernel-msm7x30/blob/2.6.32.9-chaos-ICS/config

Makes it easier for me after I have to do a hard revert. I just type

cp config .config

and then I'm gtg... Yeah, I know, laziness...

Edit: and regarding the fb0_ics_config, I just left that in there because it wasn't hurting anything and I could use it as a reference if needed.
 
mantera said:
Yeah, I don't use those config files. Too much typing for my taste...

I use this one:

https://github.com/mantera/triumph-kernel-msm7x30/blob/2.6.32.9-chaos-ICS/config

Makes it easier for me after I have to do a hard revert. I just type

cp config .config

and then I'm gtg... Yeah, I know, laziness...

Edit: and regarding the fb0_ics_config, I just left that in there because it wasn't hurting anything and I could use it as a reference if needed.
Click to expand...

Ok that makes sense. Now that I'm looking at the correct config, I'm thinking we need this:

https://github.com/edowar/FIH-msm7x30-ics/commit/ed08f65953db6765f6910800fecf43657e694196

(To our config file, not the fb0 one obviously)

And once that change is made, we still may need to comment out that section in xt_socket.c because we will have defined CONFIG_IP6_NF_IPTABLES
 
NateMckn said:
Ok that makes sense. Now that I'm looking at the correct config, I'm thinking we need this:

https://github.com/edowar/FIH-msm7x30-ics/commit/ed08f65953db6765f6910800fecf43657e694196

(To our config file, not the fb0 one obviously)

And once that change is made, we still may need to comment out that section in xt_socket.c because we will have defined CONFIG_IP6_NF_IPTABLES
Click to expand...

Yeah, that was on my list of things to try. Just hadn't gotten around to it yet. But I'll see if that makes any difference. Doing some kernel stuff now.
 
NateMckn said:
Progmanos is working on it. You can take a look at his work so far in the experimental branches of his github:

http://androidforums.com/triumph-al...g-triumph-ics-development-19.html#post3987115

Aside from assisting Progmanos or doing some coding yourself, there's nothing you can do but be patient.
Click to expand...

I think we should adopt Cyanogenmod's rule: Don't ask for ETAs (Estimated Time of Arrival)!

People are demanding features as if they are paying me to work on it full-time. I am a full-time student, a senior in fact. I have enough work as is on my hands with school and student organizations. Don't bother me with antsy questions about when the camera feature will be ready. It will be ready when someone fixes it. lol
 
progmanos said:
I think we should adopt Cyanogenmod's rule: Don't ask for ETAs (Estimated Time of Arrival)!

People are demanding features as if they are paying me to work on it full-time. I am a full-time student, a senior in fact. I have enough work as is on my hands with school and student organizations. Don't bother me with antsy questions about when the camera feature will be ready. It will be ready when someone fixes it. lol
Click to expand...

Thank you for even bothering with it :)
 
progmanos said:
I think we should adopt Cyanogenmod's rule: Don't ask for ETAs (Estimated Time of Arrival)!

People are demanding features as if they are paying me to work on it full-time. I am a full-time student, a senior in fact. I have enough work as is on my hands with school and student organizations. Don't bother me with antsy questions about when the camera feature will be ready. It will be ready when someone fixes it. lol
Click to expand...

My apologies, I wasn't trying to ask for an eta. Quite the opposite actually. I'm beyond grateful for all the work that goes into this and I was really just trying say that when the camera does work whoever figures it out will have my undying gratitude.
 
PieBob1010 said:
My apologies, I wasn't trying to ask for an eta. Quite the opposite actually. I'm beyond grateful for all the work that goes into this and I was really just trying say that when the camera does work whoever figures it out will have my undying gratitude.
Click to expand...

I assure you that, if the camera problems were fixed, one of the developers (most likely mantera) would have posted an updated ROM.

For future reference, if you are really anxious to know what developers are doing, check our github accounts. We post commit comments that indicate the purpose of changes to code.

I typically don't mind other developers asking me about the progress. I'm not being uppity, but end users typically want a date or an approximation of when something will be fixed. Honestly, I do not know when it will be fixed. However, developers usually ask because they want to help speed up development.
 
progmanos said:
I assure you that, if the camera problems were fixed, one of the developers (most likely mantera) would have posted an updated ROM.

For future reference, if you are really anxious to know what developers are doing, check our github accounts. We post commit comments that indicate the purpose of changes to code.

I typically don't mind other developers asking me about the progress. I'm not being uppity, but end users typically want a date or an approximation of when something will be fixed. Honestly, I do not know when it will be fixed. However, developers usually ask because they want to help speed up development.
Click to expand...

Agreed, this is a contributing factor to us losing our original two devs. Come-on guys let's treat our devs right! Great work so far guys! Also you may not think your asking for an ETA, but others may see it differently. So just think about what your saying before you post.

Thanks guys!
 
Hey Mantera, awesome job on 0.6.8.9 (and interesting number choice).

When do you plan on pushing those changes to github? I'd like to do some tinkering with the OMX video stuff and wanted to make sure I've got your recent changes first.
 
Tried building last night (8:30 est) , maybe errors were due to 0.6.8.9 not being pushed yet.
Code: 
target Java: android.policy (out/target/common/obj/JAVA_LIBRARIES/android.policy_intermediates/classes)
packages/apps/Settings/src/com/android/settings/DisplaySettings.java:109: cannot find symbol
symbol  : variable config_intrusiveBatteryLed
location: class com.android.internal.R.bool
                    com.android.internal.R.bool.config_intrusiveBatteryLed) == false) {
                                               ^
packages/apps/Settings/src/com/android/settings/DisplaySettings.java:113: cannot find symbol
symbol  : variable BATTERY_LIGHT_PULSE
location: class android.provider.Settings.System
                        Settings.System.BATTERY_LIGHT_PULSE, 1) == 1);
                                       ^
packages/apps/Settings/src/com/android/settings/DisplaySettings.java:232: cannot find symbol
symbol  : variable BATTERY_LIGHT_PULSE
location: class android.provider.Settings.System
            Settings.System.putInt(getContentResolver(), Settings.System.BATTERY_LIGHT_PULSE,
                                                                        ^
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
3 errors
make: *** [out/target/common/obj/APPS/Settings_intermediates/classes-full-debug.jar] Error 41
make: *** Waiting for unfinished jobs....
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
 
piper_ said:
Tried building last night (8:30 est) , maybe errors were due to 0.6.8.9 not being pushed yet.
Code: 
target Java: android.policy (out/target/common/obj/JAVA_LIBRARIES/android.policy_intermediates/classes)
packages/apps/Settings/src/com/android/settings/DisplaySettings.java:109: cannot find symbol
symbol  : variable config_intrusiveBatteryLed
location: class com.android.internal.R.bool
                    com.android.internal.R.bool.config_intrusiveBatteryLed) == false) {
                                               ^
packages/apps/Settings/src/com/android/settings/DisplaySettings.java:113: cannot find symbol
symbol  : variable BATTERY_LIGHT_PULSE
location: class android.provider.Settings.System
                        Settings.System.BATTERY_LIGHT_PULSE, 1) == 1);
                                       ^
packages/apps/Settings/src/com/android/settings/DisplaySettings.java:232: cannot find symbol
symbol  : variable BATTERY_LIGHT_PULSE
location: class android.provider.Settings.System
            Settings.System.putInt(getContentResolver(), Settings.System.BATTERY_LIGHT_PULSE,
                                                                        ^
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
3 errors
make: *** [out/target/common/obj/APPS/Settings_intermediates/classes-full-debug.jar] Error 41
make: *** Waiting for unfinished jobs....
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Click to expand...

Same here this am.
 
Repo sync and try again. It looks like there were some updates upstream to frameworks/base. I just pulled in all of the updates and pushed them up.
 
Intercepter said:
I just can't leave the wifi auto connect issue alone (since it affects me) so I did a system dump while the phone will not auto connect and found this in the wifi section.


Locks acquired: 0 full, 0 full high perf, 2 scan
Locks released: 0 full, 0 full high perf, 2 scan

Locks held:


Then I found in the Android reference the following:

public static final int WIFI_MODE_FULL

Since: API Level 3
In this Wi-Fi lock mode, Wi-Fi will be kept active, and will behave normally, i.e., it will attempt to automatically establish a connection to a remembered access point that is within range, and will do periodic scans if there are remembered access points but none are in range.
Constant Value: 1 (0x00000001)
public static final int WIFI_MODE_FULL_HIGH_PERF

Since: API Level 12
In this Wi-Fi lock mode, Wi-Fi will be kept active as in mode WIFI_MODE_FULL but it operates at high performance with minimum packet loss and low packet latency even when the device screen is off. This mode will consume more power and hence should be used only when there is a need for such an active connection.
An example use case is when a voice connection needs to be kept active even after the device screen goes off. Holding the regular WIFI_MODE_FULL lock will keep the wifi connection active, but the connection can be lossy. Holding a WIFI_MODE_FULL_HIGH_PERF lock for the duration of the voice call will improve the call quality.
When there is no support from the hardware, this lock mode will have the same behavior as WIFI_MODE_FULL
Constant Value: 3 (0x00000003)
public static final int WIFI_MODE_SCAN_ONLY

Since: API Level 3
In this Wi-Fi lock mode, Wi-Fi will be kept active, but the only operation that will be supported is initiation of scans, and the subsequent reporting of scan results. No attempts will be made to automatically connect to remembered access points, nor will periodic scans be automatically performed looking for remembered access points. Scans must be explicitly requested by an application in this mode.
Constant Value: 2 (0x00000002)

From what it looks like to me is that it is in scan mode only.

I may be way off since I know next to nothing about the android system or c programming but this does raise a flag in my head. Hope this helps.

FWIW it shows the same in the system dump mwhen it does manage to connect automatically.
Click to expand...

This info looks like it's just an API for apps to talk to the wifi. Meaning that these are parameters that an app can pass to Android to tell it how to handle the wifi. So unfortunately, it doesn't really help us too much, I'm sorry to say.

Of course, i may be mistaken in how I'm reading this. However, usually anything that you see that is an "API" means it's for use when programming apps to talk to the device in question and usually doesn't help in updating the source of the OS itself since the OS is the one that provides the API.

For example, in super simplistic terms, think of an API like this:

Pretend that I am the OS and in my API to you the app, I only allow/understand 2 commands:

talk()
listen()

If you use any other word or phrase, I'll have no clue what you're talking about and probably throw an error saying "wtf are you talking about?". However, if you use talk() or listen(), then I'll understand since those are the commands that I told you that I understand.
 
Can somebody try this for me please to see if your wifi autoconnects better?

My wifi seems to autoconnect better using this updated attached file but just wanted to see if it was just me.

Instructions:

Either flash the attached zip in CWM.

OR

adb push the wpa_supplicant.conf to /system/etc/wifi/

OR

extract the file from the zip file onto your sdcard and using es file explorer or root explorer, copy and paste the wpa_supplicant.conf file into /system/etc/wifi/

Let me know if it helps.

Note that quickly turning off and then on wifi will NOT auto connect. To test, turn off wifi, wait at least 20-30 sec until you see the 3g bar become active and blue to make sure that all clean up processes are complete BEFORE you try to turn on wifi again.

Edit: removed the zip. Sounds like the updated conf file will not hurt anything at the very least and seems to work much better; so I'll add it to the next build.
 
@Mantera

I flashed that, it seems to auto connect better on my work wifi. I will do more testing throughout the day and at home tonight, but it looks promising. I cycled through that about 10 times (let 3g sync and cycled back to wifi) and it always auto connected which didn't happen reliably before.
 
agentc13 said:
@Mantera

I flashed that, it seems to auto connect better on my work wifi. I will do more testing throughout the day and at home tonight, but it looks promising. I cycled through that about 10 times (let 3g sync and cycled back to wifi) and it always auto connected which didn't happen reliably before.
Click to expand...

That sounds promising. Thanks.
 
OK, it doesn't seem to be doing as well with my home wifi. I think my work is WEP and home is WPA/WPA2 if that makes any difference. It worked superbly all day long at work though. :confused:
 
You must log in or register to reply here.
Back
Top Bottom