Hi,
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.
Thanks in advance,
Best Wishes,
Daehyung Jo
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