Am 03.07.2011 22:13, schrieb Johan Hedberg: > On Sun, Jul 03, 2011, Nils Faerber wrote: >>> Hmm? So they don't use SDP do discover the RFCOMM channel but directly >>> connect to channel 1? >> >> Um...well I just checked that code. >> What the device does it look for the service name on the host and on the >> host side it is bound to channel 1 - I think. I borrowed that part of my >> code from some old BlueZ code, forgot which. > > So, the SDP service record is there so profiles can look up e.g. the > RFCOMM channel based on the profile UUID. If that's what the remote > device is doing you should be able to change the channel to something > else than 1 in the service record and then bind your server socket to > this new channel. However, if the remote side has a hard-coded channel > value of 1 and doesn't care what SDP says then there's really nothing > you can do (except make sure you don't have any other service on that > channel, like you now did). Looks like it is hardcoded, I just tried a different one and it fails. >> Tried that and now my device works again - yippie! > Good to hear! :) At least I can now continue playing with it... eventually I'll release my code once it reached a halfway usable state. Currently I still struggle a little with the protocol implementation which would need a state machine and I am still reluctant to implement one and wait for another inspiration instead ;) But it seems it is not coming... Thanks again! > Johan Cheers nils -- kernel concepts GbR Tel: +49-271-771091-12 Sieghuetter Hauptweg 48 D-57072 Siegen Mob: +49-176-21024535 http://www.kernelconcepts.de -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
