RE: Wrong RFCOMM connection request in OPP/FTP

[Daehyung Jo <daehyung.jo@samsung.com>]

Hi, again,

> I have a weird test result with OPP using bluez 4.25 and obex-data-server (ODS) 0.4.2.
> If I try to send a file from Samsung SGH-P930 to my target via OPP, ODS recognizes the connection type
> as an FTP thus FTP server
> tries to deal the request. Even if I disable OPP service and enable FTP service only, the OPP request
> is accepted.
> 
> ODS makes separate OPP and FTP rfcomm socket servers with different channel number 9 and 10 each. When
> there comes an IO event to
> the specific channel, the connect callback is invoked for each server. ODS just links IO events from
> the RFCOMM channel to the
> OPP/FTP server call-backs. Thus I think SGH-P930, which has a CSR stack, tries to connect to a
> different rfcomm channel. This maybe
> the problem of the SGH-P930 side.
> 
> The thing is that other normal phones translate the OPP connect request from SGH-P930 correctly. I
> think commercial phones have a
> error handling or correcting routine for this kind of wrong connect request so that even SGH-P930
> tries to connect through a wrong
> channel, BT stack can redirect the request if we can able to know the connection type.
> 
> So my question is how we can correct the wrong connection request and redirect to the proper one as
> other stacks do? And I wonder if
> SGH-P930 really misbehaves. How can I verify that SGH-P930 tries to connect to a wrong rfcomm channel?
> 
> I didn't tested with obexd yet but think it's not the problem of ODS only.
> 


I verified that SGH-P930 sends a file using FTP profile not OPP using hcidump.
So far I have assumed that "send via Bluetooth" function in mobile phones uses a OPP profile but that was wrong.
Some phones using CSR stack sends a file using OPP.

Have a good day :)

Best wishes,
Daehyung Jo