Leoppp
Aus Mobile-Wiki.org
StS:
Inhaltsverzeichnis |
[bearbeiten] Installation von leoppp
Voraussetzung ist die erfolgreiche Installation von linloader und ein Telnet-Zugriff.
Kopiere die Datei leoppp.tar in das Root-Verzeichnis des Telefons. Ändere den USB-Mode auf Modem. Per Telnet führe aus:
cd /diska tar xvf leoppp.tar
Per Explorer wechsele in das neue leoppp-Verzeichnis und klicke auf die LeoPopUp.jar Datei um die Java-Software zu installieren.
Wähle jetzt die Datei "selectme.sh" aus mit "Öffne mit" und wähle den linloader aus, damit er immer diese .sh Datei mit linloader öffnet.
Per Telnet-Verbindung führe jetzt in diesem Verzeichnis die install.sh aus. Nach dem das Telefon neu gestartet wurde sollten 3 leo-Icons und ein Java-Icon neu hinzugekommen sein.
...
[bearbeiten] Bluetooth PPP-Verbindung mit Linux
Testsystem: SUSE 9.3
Am Telefon wird Bluetooth eingeschaltet.
Jetzt wird die Datei /etc/bluetooth/rfcomm.conf editiert. Der Eintrag AA:BB:CC:DD:EE:FF muss durch die Bluetooth-Kennung des Telefons ersetzt werden! Diese Kennung erhält man über das Aktivieren von "Auffindbar" beim Telefon und am PC durch ausführen als root von "hcitools scan". Voraussetzung ist hier natürlich auch das am PC Bluetooth aktiviert ist.
rfcomm0 {
# Automatically bind the device at startup
bind yes;
# Bluetooth address of the device
device AA:BB:CC:DD:EE:FF;
# RFCOMM channel for the connection
channel 5;
# Description of the connection
comment "A780";
}
Nun wird am PC Bluetooth neugestartet.
Die PPP Verbindung wird durch den folgenden Befehl initialisiert:
pppd /dev/rfcomm0 192.168.1.3:192.168.1.4 oder pppd noauth /dev/rfcomm0 192.168.1.3:192.168.1.4
am Telefon wird SPP-Anfrage akzeptiert und in /var/log/messages sollte nun stehen:
... linux pppd[22239]: Using interface ppp0 linux pppd[22239]: Connect: ppp0 <--> /dev/rfcomm0
Nach dem Klick im Telefon auf das Icon BTPPP sollte in /var/log/messages folgendes stehen
linux kernel: PPP BSD Compression module registered linux kernel: PPP Deflate Compression module registered linux pppd[22239]: local IP address 192.168.1.3 linux pppd[22239]: remote IP address 192.168.1.4 linux pppd[22239]: Script /etc/ppp/ip-up finished (pid 22287)
Es wird vom PC aus per "telnet 192.168.1.4" eine Telnet-Verbindung zum Telefon aufgebaut. Login ist root, Passwort gibts keins.
Jetzt kann die Verbindung vom Telefon zum PC mit der Eingabe von "ping 192.168.1.3" getestet werden. Sollte auf diesen Ping keine Antworten kommen, so ggf. eine Firewall auf dem PC temporär ausschalten.
Die PPP-Verbindung wird am Telefon durch Klick auf das Icon PPP OFF abgebaut.
In /var/log/messages sollte nun stehen:
linux pppd[9051]: Script /etc/ppp/ip-down finished (pid 9387), status = 0x0 linux pppd[9051]: Connection terminated. linux pppd[9051]: Modem hangup linux pppd[9051]: Exit.
[bearbeiten] USB PPP-Verbindung
Ändere den USB-Mode auf Modem (falls er da nicht schon ist). Der usblan-Modus sollte nicht an sein: telnet müsste nicht funktionieren. Wenn telnet doch funktioniert, dort eingeben: echo MotACM > /proc/usbd-switch Danach ist die Telnet-Session tot.
Auf dem PC (als root):
pppd /dev/ttyACM0 noauth local
Auf dem Telefon klicke auf USBPPP
auf dem PC müsste jetzt
Using interface ppp0 Connect: ppp0 <--> /dev/ttyACM0 local IP address 192.168.1.1 remote IP address 192.168.1.2 Script /etc/ppp/ip-up finished (pid 23356), status = 0x0
zu sehen sein. Damit funktioniert eine PPP-Verbindung über USB, man kann (wie gewohnt) telnet auf 192.168.1.2 machen.
Jetzt fragt man sich vielleicht, wozu das gut ist, wenn telnet schon geht, wenn das USB im usblan-Mode ist.
Antwort: das mackconnectivity-Pack will eine ppp-Verbindung und arbeitet nicht mit usblan zusammen.
[bearbeiten] Offenes Problem (vielleicht weis jemand was dazu)
nfs will irgendwie nicht über die PPP-Verbindung (zumindest mit usb festgestellt). Das mounten selbst geht, aber sobald eine Datei darüber übertragen werden soll, hängt es. Im ethereal sieht man fast gar nichts, ausser gelegentlich ein Schubs fragmentierte Pakete. Scheint also evetuell ein MTU-Problem zu sein, aber blindes Verkleinern der MTU hat nichts genützt.
Auf einem ARM9tdmi mit Linux 2.6 (nommu) bin ich damals auf das gleiche Symptom gestoßen.
Problem dort: Der Host sendet zu große Fragmente, die Puffer des Clients laufen voll, dadurch erscheint das Paket fehlerhaft und wird verworfen.
Lösung dort: Mounten mit -wsize und -rsize zum Beispiel auf 4096 oder noch kleiner. Damit werden dem Host zu große Pakete verboten.
Vielleicht hilft dieser Weg auch hier (mein Telefon ist noch nicht gepatched).
Einordnung: Motorola_A780
