fopen/fwrite bei Bluetooth seriellen Ports (/dev/rfcomm0)

[Jürgen W. (lovos)]

ich wollte per Bluetooth eine virtuell-serielle Verbindung zwischen zwei 
Linux-PC aufbauen.
Üblicherweise verwende ich bei wired-seriellen Leitungen die 
open()/write() Funktionen. Das stand bei Richard Stevens und das habe 
ich immer so gemacht.
Bei rfcomm hat open() nicht funktioniert, zu viele Daten gingen 
verloren.
Auf der Console konnte ich mit "echo blabla >/dev/rfcomm0" und "cat 
/dev/rfcomm0" sicher kommunizieren, aber da fiel mir schon auf, dass 
viele NEwlines reinwanderten.

Ich habe dann das C-Programm für die Kommunikation mit fopen realisiert,
  FILE *fh=fopen("/dev/rfcomm0","rb+"); fwrite(buf,1,len,fd);
Die Kommunikationen lief gut, aber CR wurden in NL übersetzt und NL 
zunächst verdoppelt, trotz der des Binär-Modus "rb+".

Kennt jemand das Problem und die Lösung?
Muss man das vielleicht bei den Bluez-Einstellungen (hcitools, 
hciconfig, rfcomm) machen?


Nachtrag:
http://www.tapr.org/pipermail/aprssig/2011-May/036156.html
verwenden die:
stty -F /dev/rfcomm0 4800 raw

Aber mir ist nicht klar, an welcher Stelle man den Befehl hat.
Vor "rfcomm accept" kennt er das Device "rfcomm0" noch nicht.

[apr (Gast)]

INLCR
http://www.kernel.org/doc/man-pages/online/pages/man3/tcflush.3.html

[Jürgen W. (lovos)]

Nee, tcflush hatte ich auch schon ausprobiert.
Negativ.

tcflush ist dazu da, Daten im Buffer sofort rauszuschreiben.
Hat aber auf CR/NL Umwandlung keinen Einfluss.


stty war ja i.O.
Allerdings funktioniert es jetzt immer auch nach Neustart beider 
Rechner, das System hat sich das irgendwie gemerkt.

[apr (Gast)]

"INLCR  Translate NL to CR on input." und es ist nicht tcflush, sondern 
termios(3) und dort genauer tcsetattr und tcgetattr.

[Jürgen W. (lovos)]

> sondern termios(3) und dort genauer tcsetattr und tcgetattr.

Liesst Du eigentlich die Posts von den anderen oder nur die 
Überschriften?
Ich hatte doch im ersten Post genau beschrieben, dass ich bei RS232 
immer mit open()/read()/write() verwendete (und DAMIT AUCH tcsetattr, 
..., da man NUR DAMIT Baudrate, Stoppbits, ... einstellen kann).
tcsetattr-Einstellungen, die mit wired-serial (/dev/ttyUSB0) 
funtionieren, funktionieren aber bei Bluetooth Ports NICHT.
Bluetooth comm funktioniert aber super mit fopen/fwrite, aber FILE * 
stellt kein tcsetattr zur Verfügung (ausgenommen fileno())

[Klaus W. (mfgkw)]

Hi,

ist ja schon eine Weil eher, aber vielleicht hilft es jemandem:

Ggf. kann man sich mit fileno() zu einem FILE* den low-level-fd holen 
und darauf dann mit tcgetattr() etc. losgehen.

[Georg A. (georga)]

> Bei rfcomm hat open() nicht funktioniert, zu viele Daten gingen
> verloren.

Beim Lesen oder beim Schreiben? Beim Schreiben könnte es aufgrund zu 
kleiner Buffer durchaus sein, dass das write mit weniger Bytes 
zurückkehrt als als Länge übergeben wurden.