[Custom ROM] Nightly Builds CyanogenMod 7 (Android 2.3.7)

  • 7.187 Antworten
  • Letztes Antwortdatum
G00fY schrieb:
Versuchs doch einfach mal wie diginix es oben geschrieben hat. Durch das Löschen der wpa_supplicant.conf (unter system/etc/wifi/). Du musst dann wohl die Passwörter deiner WLAN Netze erneut eintragen.
Wenn das eine Antwort für Flip ist, dann hast du ihn missverstanden. Er will UMTS Daten vom Defy tethern, also das Defy selbst als WLAN Hotspot nutzen.

@Flip: Bei mir funktioniert der WLAN Hotspot mit WPA2 und es werden auch Daten durchgereicht.
 
diginix schrieb:
Wenn das eine Antwort für Flip ist, dann hast du ihn missverstanden. Er will UMTS Daten vom Defy tethern, also das Defy selbst als WLAN Hotspot nutzen.
Jup. Dann vergesst das. Hatte wohl zu schnell drüber gelesen.:D
 
Die bei manchen aktuell auftretenden Probleme kann ich zum Glück bei mir nicht sehen! Tethering ist auch bei mir problemlos!

gruß
 
Bei mir läuft soweit auch alles glatt.

Ich hab nur immer noch das Problem, dass teilweise keine PIN-Abfrage erscheint. Nach dem Flugmodus kommt die nicht und nach dem Neustarten auch nicht. Sollte doch eigentlich nicht so sein, oder?
 
Zuletzt bearbeitet:
nein.... das ist offensichtlich geändert worden! PIN nur noch beim richtigen Einschalten, auch bei mir! So war es früher unter Eclair auch und es haben sich viele beschwert als bei Froyo nach dem Flugmodus der PIN nötig wurde!

gruß
 
Nabend

Maniac kannst du was hierzu sagen??

"initial sources for kexec module"

bist du an kexec am "basteln"

Fortschritte??
 
Maniac hatte hier schonmal gepostet, dass die PIN-Abfrage eigentlich erscheinen sollte. Oder hat sich seit dem was geändert Maniac?? Dein Fix bezog sich doch nur auf die PIN-Abfrage bei deaktiviertem Logscreen, oder?

Also bei mir kommt außer nach dem kompletten Ausschalten - kurzer Pause - und erneutem Anschalten gar keine PIN-Abfrage mehr. Wirklich stören tut mich das zwar nicht, aber mich wunderts einfach (besonders das nach dem Neustart keine Abfrage kommt:D).
 
Zuletzt bearbeitet:
Ich fände es ja gut wenn die PIN Abfrage nach Flugmodus wegbleibt.
So kann ich ihn wieder nachts per Tasker aktivieren und morgens deakt.
Oder kann mir einer sagen ob ich wenn Tasker den Mode beendet auch die PIN mit übergeben kann? Brauche ich allerdings nur wenn sie wider Erwarten zurück kommt.
 
  • Danke
Reaktionen: bitboy0
Dirk64 schrieb:

Die habe ich gestern Nachmittag geflashed, der Akku ist seitdem von 90% auf 15% gefallen (hat mit der alten RC0 3 Tage durchgehalten), Datennetz bekomme ich kaum noch, das Handy zeigt zwar 3G an, dieses bleibt aber grau. Wenn ich einen Provider über die Einstellungen auswählen will bleibt er beim Scannen nach Netzen hängen (scannt endlos).
Ich geh erstmal wieder auf die alte RC0 zurück...

Bissi OT: Ich hatte vor der Nightly mal kurz die 7.1 drauf, da war statt des Motorola-"M" beim Einschalten ein wesentlich netterer Splash-Screen. Kann man den nicht wieder einbauen?
 
Den Splash-Screen kannst du mit entsprechendenen Apps sicher und beliebig wieder installieren!

Abgesehen davon bin ich ja überrascht das es angeblich solche Probleme mit den aktuellen ROM's geben soll ... ich hab von den vorgebrachten Problemen KEINE ... und ich hab nicht mal was gewiped oder so.

gruß
 
Diese Einzelfälle mit zB Akkuproblemen haben auch nichts mit den aktuellen builds zu tun. Sondern treten nur dummerweise zeitgleich auf. Mit bissel Know How und guten Willen würden die betroffenen Leute das auch gelöst bekommen. Aber es wird ja immer gleich wieder ein Downgrade gemacht weil die neue ROM ja so schlecht war.
Die DEVs arbeiten nur noch an Kleinigkeiten in den CM7 nightlys und dabei ändert sich nichts derart gravierend dass das ROM solche Effekte mitbringt.
 
Hallo,
ich wollte nur kurz eine Erfolgsmeldung verlauten: mein Tethering funktioniert wieder :thumbup:
Trick: führe einfach im Recovery unter Stable einen Cache-Wipe durch und schon geht die Schose wieder.
Sehr fein, ROM läuft wie immer perfekt!

Mfg
flip
 
diginix schrieb:
Diese Einzelfälle mit zB Akkuproblemen haben auch nichts mit den aktuellen builds zu tun. Sondern treten nur dummerweise zeitgleich auf. Mit bissel Know How und guten Willen würden die betroffenen Leute das auch gelöst bekommen. Aber es wird ja immer gleich wieder ein Downgrade gemacht weil die neue ROM ja so schlecht war.
Die DEVs arbeiten nur noch an Kleinigkeiten in den CM7 nightlys und dabei ändert sich nichts derart gravierend dass das ROM solche Effekte mitbringt.

Der Akku kommt erschwerend hinzu - mein Hauptproblem ist, dass ich seit dem Update keine Datenverbindung mehr bekomme. Habe jetzt einen Neustart durchgeführt und die Caches gelöscht, habe nach dem Hochfahren meinen Provider auswählen können (simyo) aber nur einen grauen (Telefon-) Empfangsbalken und kein Datensymbol mehr. Catlog sagt in einem Eintrag "notifyDataConnection: state=0 isDataConnectivityPossible=false reason=simLoaded interfaceName=null networkType=8"
 
Ich würde jetzt sagen an den dafür beteiligten Code wurde schon Wochen/Monate nichts geändert. Du kannst das logcat mit bissel mehr Inhalt ja mal Maniac zukommen lassen. Alternativ wäre interessant wenn du von Null an nochmal aufbaust, Froyo SBF, root, 2ndInit, CM7 nightly.

Machst vorher ein CWM Backup und kannst so, sollte der Fehler dann immer noch auftreten, wieder auf deinen jetzigen Stand mit allen APPs und Einstellungen. Den Test ist es wert. Dauert ja auch keine 20min bis zum Erststart von CM7.
 
  • Danke
Reaktionen: bitboy0
So, ich schon wieder.
Nun hab ich doch erst vor ein paar Stunden mein Tethering-Problem gelöst.
Gerade ist schon das nächste aufgetaucht. Nicht weiter dramatisch, aber dennoch etwas nervig: Seit dem Update auf die nun nicht mehr aktuelle Nightly :tongue: vom 26.03. muss ich vor der Eingabe meiner PIN zum Entsperren des Displays noch die Bildschirmsperre entriegeln. Dies ist allerdings unter den CM-Einstellungen mit dem Haken unter Sperrbildschirm>Entsperroptionen>nur Sicherheitsperre deaktiviert worden, sprich der Haken ist gesetzt.
Das hat mit Sicherheit nichts mit der Nightly zu tun, aber irgendwie funzt es trotzdem nicht mehr wie zuvor... Hab die verschiedenen Optionen schon des öfteren aktiviert und deaktiviert, neugestartet usw.
Was tun?

Mfg
flip
 
diginix schrieb:
@Maniac: hattest du mein post bzgl wpa.conf gelesen:
https://www.android-hilfe.de/forum/...droid-2-3-7.109453-page-243.html#post-2935785

Du wolltest ja schon von anderen eine nicht funktionierende wpa.conf ohne Zugangsdaten. Alles was zum nicht funktionieren beitrug hab ich in dem Post geschrieben. Jedenfalls ging alles wieder als die Dinge nicht mehr drin standen.

Ok, danke. Dann ist's mit an Sicherheit grenzender Wahrscheinlichkeit der Eintrag 'ap_scan=2'.

Aus der Beispiel-wpa_supplicant.conf:
Code:
# AP scanning/selection
# By default, wpa_supplicant requests driver to perform AP scanning and then
# uses the scan results to select a suitable AP. Another alternative is to
# allow the driver to take care of AP scanning and selection and use
# wpa_supplicant just to process EAPOL frames based on IEEE 802.11 association
# information from the driver.
# 1: wpa_supplicant initiates scanning and AP selection
# 0: driver takes care of scanning, AP selection, and IEEE 802.11 association
#    parameters (e.g., WPA IE generation); this mode can also be used with
#    non-WPA drivers when using IEEE 802.1X mode; do not try to associate with
#    APs (i.e., external program needs to control association). This mode must
#    also be used when using wired Ethernet drivers.
# 2: like 0, but associate with APs using security policy and SSID (but not
#    BSSID); this can be used, e.g., with ndiswrapper and NDIS drivers to
#    enable operation with hidden SSIDs and optimized roaming; in this mode,
#    the network blocks in the configuration file are tried one by one until
#    the driver reports successful association; each network block should have
#    explicit security policy (i.e., only one option in the lists) for
#    key_mgmt, pairwise, group, proto variables
# ap_scan=1
Das heißt, dass in diesem Modus alle gespeicherten APs nacheinander durchprobiert werden, d.h. der Supplicant versucht direkt zu assoziieren anstatt zu scannen. Das (Assoziationsversuche ohne Scan-Ergebnisse) mag der Treiber anscheinend nicht.

Es gibt im Prinzip zwei API-Aufrufe, die im Zusammenspiel dafür verantwortlich sind. Der eine setzt diesen Wert um (zwischen 1 und 2), der andere speichert die wpa_supplicant.conf (inkl. dieses Wertes, wenn in dem Moment gesetzt). Ich vermute mal ins Blaue hinein, dass der Speicher-Aufruf zu einem unerwarteten Zeitpunkt gemacht wird (vielleicht eine Race Condition) und deshalb ap_scan=2 mit in die Config geschrieben wird, obwohl das nie passieren sollte. Ich überblicke aber ehrlich gesagt die Szenarien, in denen das passieren kann, nicht wirklich; der Code ist ziemlich komplex.

Ich kann da für meine Nightly drum rum hacken (ap_scan niemals in die wpa_supplicant.conf schreiben), aber eine Idee für eine ordentliche Lösung habe ich im Moment nicht.
 
  • Danke
Reaktionen: phynix5800

Ähnliche Themen

R
Antworten
110
Aufrufe
43.989
Julsen
J
P
Antworten
2
Aufrufe
4.083
pseudodeed
P
Android94
Antworten
745
Aufrufe
162.721
armalyte
A
Zurück
Oben Unten