Die übliche Rückmeldung ist bloß: »Sending SMS 1/1….waiting for network answer..OK, message reference=[...]«. Das Problem trat nur bei SMS an manche Rufnummern auf, im vorliegenden Fall bei einer Nummer mit (deutscher) Vorwahl
0170. In diesen Fällen war die dort ankommende SMS entweder leer oder unlesbar. SMS an die eigene Rufnummer funktionierten problemlos.

Beim ThinkPadT23 befindet sich der IrDA-Port neben dem Lautsprecher-Ausgang und beim Nokia 6610i auf der Oberseite neben dem Einschaltknopf. Legt man das Handy dagegen vor den Laptop kann keine erfolgreiche Verbindung erstellt werden. Am besten ist Plazierung in ggs. Sichtkontakt, Abstand 5cm. IR-Empfang im Nokia 6610i einschalten (zeitnah bis max. 2min zum Verbinden, weil er sich wieder abschaltet wenn keine Verbindung erfolgt).

kmobiletools: Installieren: kmobiletools. In der Konfiguration eintragen: Generisches Nokia-Handy, Device /dev/ircomm0. SMS Slot 2 aktivieren. Wenn eine gespeicherte SMS-Liste Teile in falscher Kodierung enthält öffne man sie in kedit (!) um das zu korrigieren. kmobiletools verwendet man um SMS zu empfangen, auf dem Computer zu archivieren und zu senden. Senden von SMS funktioniert mit dem Nokia 6610i bisher leider nicht, auch nicht das empfohlene vorherige Speichern.

gnokii und xgnokii: Paket gnokii installieren. Konfiguationsdatei entsprechend /etc/gnokiirc und wiki.gnokii.org/index.php/Config anlegen. Aber: »model = AT« statt »model = 6510« damit »–monitor« und »–identify« funktionieren.
Wie kann man mit xgnokii oder gnokii mehr als eine Telefonnummer pro Name aus dem Adressbuch erhalten? Angabe eines anderes Telefontyps funktioniert nicht: es wurden alle probiert die in den Kommentaren in ~/.gnokiirc stehen und nur »AT« funktioniert. Es scheint dass wegen dieses Treibers »AT« nur die allereinfachsten Funktionen in gnokii funktionieren: Kontakte mit Namen und einer Telefonnummer, und SMS, »gnokii –getnetworkinfo«, »gnokii –monitor«. Sonst nichts. Gemäß der Dokumentation ist das Modell »6510« zu verwenden: das funktioniert wohl über Kabel aber bisher nicht mit »connection = irda«; man sollte wohl mit »connection = infrared« experimentieren. Siehe auch: www.dev-thomynet.de/nokworld/gnokii-infrared-howto/gnokii-ir-howto.txt und article.gmane.org/gmane.linux.drivers.gnokii/3312 . Danach muss man zuerst einmal das Notebook so konfigurieren dass SIR als Modus für die Infrarot-Schnittstelle genutzt wird. Eine von mehreren Voraussetzungen ist dazu, alle IrDA-Kernelmodule zu entfernen. Aber:
»Going into the deailes, Nokia 61X0 didn’t have the real irda stack implemented, and they didn’t work with Linux IrDA stack. Therefore we created the infrared driver that allowed to communicate linux with the phone over the inrared. The only phones with this feature were 6110, 6130 and 6150 (and probably their nonGSM versions). For all other phones you can use the regular irda to communicate. See gnokii-IrDA-Linux and gnokii-ir-howto from Docs/ subdir for more defaules.«
( article.gmane.org/gmane.linux.drivers.gnokii/3325 ). Gnokii erzeugt, wenn man den (korrekten) Treiber 6510 und (ebenfalls korrekt) IrDA verwendet, die folgende Fehlermeldung: »Sorry, this function is known to break your phone (Nokia phones series 40 v1). Refusing to do it. You may try to use AT driver.«. Es scheint dass hier Funktionen vorsichtshalber gesperrt wurden und bisher (seit 2005) nicht wieder freigegeben wurden ( savannah.nongnu.org/bugs/?func=detailitem&item_id=14464 usw.). Man sollte besser eine andere Software versuchen.

gammu und wammu: gammu basiert auf gnokii, könnte also das fortgeschrittenere Programm sein;
www.pro-linux.de/berichte/mobiltelefone.html bestätigt dass gammu das umfangreichste erhältliche Programm zu Verwaltung von Mobiltelefonen ist. libgammu0 und gammu installieren und wammu. Konfigurationsdatei ~/.gammu anlegen:

Nach der gammu Phone Database unterstützt gammu für das Nokia 6610i folgende Features über IrDA: Telefon-Informationen, Senden und Speichern von SMS, einfaches Telefonbuch, erweitertes Telefonbuch, Dateisystem-Bearbeitung ( cihar.com/gammu/phonedb/nokia/152/ ). Das stimmt. Erstellen von Todo- und Kalender-Einträgen funktioniert z.B. (noch) nicht. (Einmal trat ein Totalabsturz auf beim (erfolgreichen) Sender einer SMS (an sich selbst).) Man beachte dass der Ablageort »SM« (SIM-Karte) für Telefonbucheinträge nur einfache Telefonbuch-Einträge unterstützt, der Ablageort »ME« (Handyspeicher) jedoch auch erweiterte. Außerdem funktioniert: Anzeigen und Bearbeiten von Anruflisten; Abrufen von Kalendereinträgen und Aufgaben; Löschen von Kalendereinträgen und Aufgaben. Was nicht funktioniert ist also nur: Erstellen und Bearbeiten von Kalendereinträgen und Aufgaben; Logos verwalten; Klingeltöne verwalten; Anrufe machen; Löschen von SMS am Speicherort »ME« (Handyspeicher).

Achtung: »gammu –getfiles« speichert die Datei im aktuellen Verzeichnis mit ihrem originalen Namen, dabei wird eine ggf. existierende gleichnamige Datei überschrieben! Die Dateien sind nicht vom Menü des Mobiltelefons aus zugreifbar, nicht einmal ihre Existenz ist dort sichtbar. Denn sie wurden in einem selbst erstellten Ordner angelegt, nicht im Galerie-Ordner o.ä.. Zugriff ist somit nur auf Dateisystemebene über einen Computer möglich.

»gammu –getfilesystem« usw. (nicht über wammu möglich).
Achtung: es kann stets nur ein Programm gleichzeitig zum Handy verbunden sein; wenn man z.B. gleichzeitig noch mit wammu verbunden ist erscheint bei obigem Befehl: »Funktion wird nicht vom Telefon unterstützt.«.

Um alle Bilder vom Telefon auf den eigenen Rechner zu verschieben verwende man: Ausgabe von
»gammu –getfilesystem« zu einem Skript mit »gammu –getfiles« editieren bei dem pro Befehl nicht mehr als
40 Parameter angegeben werden. Danach dasselbe mit »gammu –deletefiles«. Auch MMS-Dateien dürfen ohne weiteres gelöscht werden.

Besser: SnoFS, basiert auf gammu und ermöglicht Mounten.

Alternative: Man verwende das Debian-Paket p3nfs. Doku siehe www.koeniglich.de/p3nfs.html .

Funktioniert bisher nicht: Ein-/Ausgabefehler beim Listen von Verzeichnissen.

Weitere Alternative: bezogen auf das Nokia 6610i: »By the way, downloading files from the phone via OBEX using kioslaves works without problems.« ( blog.gmane.org/gmane.linux.drivers.gnokii ).

Synchronisation: Wenn auf dem Handy Einträge geändert werden sollten sie in einem speziellen Feld als verändert markiert werden (neues Detail »Notiz« anlegen mit Inhalt »*upd« für »update«); die Änderungen werden vor einem neuen Export aus kadressbook aufs Handy dann in kadressbook manuell aufgenommen indem man die vom Handy auf dem Computer übertragene vCard-Datei nach »*upd« durchsucht und die entsprechenden Einträge in kadressbook aktualisiert.

Transfer Zusammenfassung: verwende ~/Envirionment/Sprachkommunikation/Handy.Adressbuch/vcf2nokia.sh entsprechend der in diesem Script enthaltenen Anleitung.

Transfer Diskussion: direkter Export aus kadressbook ist nicht möglich da »Datei -> Exportieren -> Export auf Mobiltelefon …« gnokii verwendet und dies keinen Upload durchführen kann. Auch »gammu –savefile VCARD10|VCARD21« ist nicht brauchbar, denn dieser Befehl dient dazu aus einer zuvor erzeugten Backup-Datei vCard-Dateien zu erzeugen. Aber es funktioniert hervorragend, ein Backup mit »gammu –backup backup.vcf -yes« zu erzeugen, dieses dann zu editieren und mit »gammu –restore backup.vcf« wieder aufzuspielen. Also ist es auch möglich, einen aus kadressbook exportierten Teil des Adressbuchs hochzuladen (das Telefon verwendet vCard 2.1). Dabei muss man allerdings einige Einschränkungen des vCard-Formats beachten sonst entsteht bei »gammu textall –restore adressbook.vcf« etwas wie:
Phonebook entry written - error
Too much entries
[ERROR 21: Function not supported by phone.]
Funktion wird nicht vom Telefon unterstützt.
[Closing]
Beschränkungen des vCard-Formats des Telefonbuchs:

• Zeilen dürfen nicht die VCF-typischen Umbrüche haben, denn Inhalte aus der zweiten und folgenden Zeilen werden nicht übernommen (oder nur dann nicht wenn UNIX-Zeilenumbrüche verwendet werden?)
• Es kann nur eine Adresse angelegt werden, weitere Adressen werden ignoriert.
• Die Informationen »Bild« und »Anrufergruppe« werden aus dem Telefon nicht in die vom Telefon exportierte vCard aufgenommen (sonst aber alle Informationen), es wird also schwierig sein sie mit dem Adressbuch abzugleichen.
• Man kann nur insgesamt 5 Telefonnummern zu einem Eintrag hinzufügen (ggf. darunter solche mit gleichem Typ), sonst erscheint »Speicher für diesen Eintrag voll«.
• Einträge können auch nicht eine beliebige Anzahl Details aufnehmen, sonst entsteht die Fehlermeldung »Too much entries«. Dabei werden evtl. nur die zulässigen Einträge gezählt. Es scheint dass die max. Anzahl der Datenbytes relevant ist, nicht die Anzahl von Einträgen an sich (meist sind 12-14 Einträge möglich).
• Die E-Mail-Adresse darf keinen Zusatz »;TYPE=PREF« haben sonst wird sie nicht mit aufgenommen (es ergibt sich aber auch kein Fehler).
• Die Einträge »FN:«, »UID:«, »BDAY:« dürfen enthalten sein, haben aber keinen Effekt.
• Ein Eintrag »ADR:« mit abweichendem Inhalt von »LABEL:« ist erlaubt, wird jedoch ignoriert. Auch der Adresstyp darf angegeben sein, wird jedoch ebenfalls ignoriert.
• »\n« darf in Einträgen enthalten sein, wird jedoch literal statt als Zeilenumbruch interpretiert
• Ein Eintrag »N:Nachname;Vorname;;;« erscheint später als »NachnameVorname« im Telefonbuch. Man sollte also den Eintrag »N:« entfernen und »FN:« zu »N:« machen vor einem Upload.
• Telefonnummern dürfen keine Leerzeichen, Buchstaben und Sonderzeichen enthalten sonst entsteht der Fehler »unknown 67«.
• Bei Telefonnummern muss der Typ ohne den Vorsatz »TYPE=« angegeben werden, sonst wird die Telefonnummer ignoriert.
• Der Zusatz »;VOICE« bei Telefonnummern wie er beim Backup aus dem Telefon generiert wird ist unnötig, es hat keinen Effekt wenn man ihn weglässt.
• Zeilen über einer bestimmten Menge Zeichen (etwa 200) führen bei der Vorverarbeitung in gammu zu Speicherzugriffsfehlern; es wird am besten sein alle Zeilen nach 76 Zeilen umzubrechen wie in kaddressbook gemacht
• Das Feld »ORG:« wird vom Telefon nicht unterstützt; es ist unnötig da sein Inhalt von kaddressbook auch noch in »FN:« aufgenommen wird.
• Es ist nicht klar was man in VCF-Dateien verwenden muss um Zeilenumbrüche in Feldern (z.B. in »LABEL:« und »NOTE:«) zu erzeugen; »\n« erscheinen als Literale, Unix-Newline-Zeichen (LF) oder DOS-Newline-Zeichen (CR+LF) bewirken dass nur die erste Zeile übernommen wird (selbst wenn die folgenden Zeilen VCF-typisch eingerückt sind). Beim Auslesen von im Telefon erzeugten Zeilenumbrüchen erscheinen diese als »=0A«, aber die Übertragung der ausgelesenen Datei zurück zum Telefon bewirkt dass dort dann »=0A« als Literal steht. Dasselbe passiert mit beliebigen Kombinationen von »=0A« (LF, ASCII 10) und »=0D« (CR, ASCII 13), alleine oder zusammen.
• Die Markierung »PREF« bei Telefonnummern hat keinen Effekt. Stattdessen wird die erste Telefonnummer jeder vCard als Standardnummer markiert. Und das obwohl bein Auslesen der vCards aus dem Telefon die Standardnummern mit »PREF« markiert sind!
• Wenn man »PREF« verwenden will (obwohl es keinen Effekt hat) so muss es als erstes verwendet werden: »TEL;HOME;PREF:2222222222« wird ignoriert, »TEL;PREF;HOME:2222222222« wird akzeptiert.
• Das Feld »LABEL:« darf kein (literales) Semikolon enthalten sonst wird es nicht akzeptiert; ein Semikolon kann auch nicht quoted printable kodiert werden (=3B), denn dann erscheint =3B als Literal.
• »LABEL:« und »NOTE:« werden nach 60 Zeichen abgeschnitten. Auch im Telefon können keine Zeichen hinzugefügt werden. Man sollte als »Straße« abkürzen und das Land nicht angeben.
• Felder mit einer zu langen Zeichenkette ohne Leerzeichen werden bereits nach 5 Zeichen abgeschnitten.
• Man sollte das Feld »PHOTO:« entfernen, nicht wegen des Telefons, sondern weil diese lange Zeile in gammu zu einem Speicherzugriffsfehler führt.
• Sonderzeichen werden UTF-8 kodiert und dann quoted-printable kodiert, “ß” hat deshalb zwei Bytes: “=C3=9F”. Siehe: www.utf8-zeichentabelle.de .
• Einbyte-Zeichen (bezogen auf UTF-8) können nicht quoted printable kodiert angegeben werden.

Gute Befehle zum Testen:

Ein vollständiger, funktionierender Eintrag mit Details aller Arten und Nummern aller Arten sieht so aus
(mit Kommentaren):

BEGIN:VCARD
VERSION:2.1
N:Formatierter Name
  # alternative Form wenn Sonderzeichen (angehängtes »ö«):
  # N;CHARSET=UTF-8;ENCODING=QUOTED-PRINTABLE:Formatierter Name =C3=B6
  # Zusatz »;CHARSET=UTF-8;ENCODING=QUOTED-PRINTABLE« ist wohl auch bei anderen Textfeldern möglich.
TEL:0049123456789
  # allgemeine Nummer ohne Typ; Nummern mit gleichem Typ sind erlaubt und überschreiben sich nicht
  # die erste Nummer wird als Standardnummer verwendet
TEL;PREF;CELL:0049123456789
  # Mobiltelefon als Standardnummer; »;PREF« muss zuerst stehen, ist bei allen Typen möglich, hat keinen Effekt
TEL;FAX:0049123456789
TEL;HOME;VOICE:0049123456789
TEL;WORK;VOICE:0049123456789
EMAIL:user@example.org
URL:http://www.example.org
NOTE:Note
LABEL:Test1
ADR:Test1
  # LABEL und ADR: Postadresse 1
LABEL:Test2
ADR:Test2
  # LABEL und ADR: Postadresse 2
END:VCARD

Achtung: manche VCF-Dateien führen beim versuchten Upload zum Absturz des Nokia 6610i und damit (über
Änderung des Netzwerkstatus der IR-verbindung und einen Treiber-Bug) möglicherweise auch zum Einfrieren
des Computers. Zum Beispiel diese VCF-Datei:
BEGIN:VCARD
N:Vorname Nachname
NOTE:Test1
NOTE:Test2
NOTE:Test3
NOTE:Test4
NOTE:Test5
NOTE:Test6
NOTE:Test7
NOTE:Test8
NOTE:Test9
NOTE:Test10
NOTE:Test11
NOTE:Test12
NOTE:Test13
NOTE:Test14
NOTE:Test15
NOTE:Test16
VERSION:2.1
END:VCARD

Ziel: Es macht praktisch keinen Sinn, Termine, Aufgaben und Erinnerungen mit dem Handy selbst zu erstellen: die Eingabemöglichkeiten sind viel zu ineffizient. Entweder verwende man Papier und Stift, übertrage die Aufgaben dann in kontact und exportiere von dort auf das Mobiltelefon. Oder man verwende ein PDA. Ziel ist also nur, Erinnerungen, Termine und Aufgaben von kontact auf das Mobiltelefon zu übernehmen und dort zu lesen, nicht aber zu verändern.

Diese Erkenntnis hat den Vorteil dass der Datenaustausch von Adressen, Terminen und Aufgaben nur in einer Richtung geschieht: vom PC auf das Mobiltelefon. Das ist einfach.

Bester (und funktionierender) Vorschlag bisher: mit »gammu –backup backup.ics -yes« den Kalender in eine Backup-Datei speichern, diese mit korganizer’s ics-Datei synchronisieren und dann mit
»gammu –restore backup.ics« wieder auf das Telefon hochladen.

Weitere Vorschläge zur Synchronisation zwischen Handy und kontact: probiere: opensync mit SyncML, opensyc zwischen Dateien, opensync über KDE PIM Integration (wie geht das?), pi-sync (www.pi-sync.net/), multisync (funktioniert nicht mit Nokia-Handys), MultiSynk (multisync für kontact?), ksync, kitchensync, gnome-pilot und evolution
(verwenden libpisync0 ?), die zukunftsweisende Lösung ist OpenSync, das to-be-Synchronisationsframework für KDE. Das KDE-Frontend ist kitchensync (bisher noch eine Entwicklungsversion und ohne kontact-Integration).

Eine Synchronisation (nur) des Adressbuchs ist evtl. über kandy möglich. Es funktioniert aber wohl nur über die serielle Schnittstelle, nicht über IRDA.
kpilot dient nur zur Synchronisation mit Palm-kompatiblen Geräten.

Alternativer Vorschlag: Synchronisation von Kalender, Aufgaben und Adressen über einen Internet-Server
(mit funambol) mit der im Telefon eingebauten Funktion (diese verwendet SyncML!). Nachteil: der Preis für die WAP-Übertragung.

Siehe auch:
Weitere Software: www.linuxsoft.cz/en/sw_list.php?id_kategory=72
VCalOne: myy.helia.fi/~karte/vcalone.html

wammu dagegen beherrscht keine Synchronisationsfunktionen, nicht einmal das Erstellen und Ändern von Kalendereinträgen und Aufgaben. Auch auf Dateisystemebene sollte man nicht arbeiten denn dort gibt es ebenfalls keine Synchronisationsfunktionen.

Z.B. beim Nokia 6610i kann man die Vibration so ansteuern (mit kurzen, schnell aufeinanderfolgenden Signalen) dass sie leise ist, nicht ebenso stört wie ein Klingelton selbst.

Die Auflösung des Displays ist 128×128 Pixel, also sollte das Hintergrundbild genauso groß sein. Wenn es mehr als 4096 Farben verwendet kann es sein dass das Handy Falschfarben anzeigt. Die Balken für Netzstärke und Akkustand machen sind am besten lesbar auf sehr dunklem oder sehr hellem Hintergrund. Man kann sie auch pixelgenau mit einem dunklen Rand hinterlegen oder die ungefüllten Bereiche des Balkens schattiert vorzeichnen. Die Bereiche in denen die (schwarze) Schrift erscheint sollten einen hellen Hintergrund haben. Das Hintergrundbild sollte zu einem der Farbschemata des Nokia 6610i passen.