Luiz Augusto von Dentz wrote: >Actually mode has been separated from state since some time, I don't >think this patch even apply upstream anymore. But I agree that >switching to server mode is a bit odd, but maybe there is a reason for >that.
Oh gods. Switched to 1.4 to test some app which used an older ABI and forgot to switch back on master. Although updating the patch seems trivial. Hendrik Sattler wrote: >Indeed there is. MODE_SRV is also used as initial value for the mode >field. Unless you take that obex_t and register as server with it, the >MODE_SRV does nothing (there is no listening FD so nothing comes in >this route). MODE_CLI is automatically set once you send a request and >everything is set back to initial values once that request ends. Those nifty details aren't good; the constants should have clear and not-obscure, not-confusing meaning and usage, shouldn't they? Or else the development may become a nightmare: one will be obligated to know all the internal machinery in detail to be able to use it. > >Exactly which event is the problem here? The problem shows up e.g. in the test client; the event OBEX_EV_REQDONE gets handled in wrong way because of client having mode==OBEX_MODE_SERVER. I used the following test scenario: 1) Launch `apps/obex_test/obex_test -i` and make it listen on tcp loopback 2) Launch another instance and make it connect to the server Here is log of such a launch (client side): Using TCP transport OBEX Interactive test client/server. > c TcpOBEX_TransportConnect(): obex_create_socket(): inobex_connect_request(): peer addr = [::1]:650 inobex_connect_request(): transport mtu=1024 obex_object_setrsp(): obex_object_setcmd(): 00 obex_insert_connectframe(): obex_object_addheader(): obex_object_addheader(): BS header size 6 insert_byte_stream_header(): OBEX_Request(): obex_client(): obex_client_start(): STATE_START obex_object_send(): allowfinalcmd: 1 forcefinalbit:0 obex_object_send(): Adding 4 bytes of non-headerdata obex_object_send(): 4 obex_object_send(): Adding non-body header obex_object_send(): Sending package with opcode 128 Tx: 80 00 10 10 00 04 00 4A 00 09 4C 69 6E 75 78 00 obex_data_request(): len = 16 bytes obex_transport_do_send(): sending 16 bytes Made some progress... OBEX_HandleInput(): obex_transport_standard_handle_input(): obex_transport_standard_handle_input(): Data available on client socket obex_data_indication(): obex_transport_read(): Request to read max 3 bytes obex_data_indication(): Got 3 bytes obex_transport_read(): Request to read max 4 bytes obex_data_indication(): Got 4 bytes msg len=7 Rx: A0 00 07 10 00 04 00 obex_client(): obex_client_recv(): STATE_REC obex_client_recv(): We expect a connect-rsp obex_parse_connect_header(): obex_parse_connect_header(): Len: 7 obex_parse_connect_header(): version=10 obex_parse_connect_header(): requested MTU=400, used MTU=400 obex_object_receive(): obex_object_receive_nonhdr_data(): obex_object_receive_nonhdr_data(): Command has 4 bytes non-headerdata obex_object_receive_headers(): obex_object_receive(): Pulling 0 bytes obex_client_recv(): Done! Rsp=20! Server request finished! server_done() Command (00) has now finished obex_object_delete(): free_headerq(): free_headerq(): free_headerq(): OBEX_HandleInput(): obex_transport_standard_handle_input(): Timeout waiting for data. Aborting >From the log we can conclude that syncwait() function doesn't stop the loop in right time, because of clientdone flag not being set in client_done(), because server_done() is called instead of it in the event dispatcher (obex_test.c:78), and finally, that happens because the mode is OBEX_MODE_SERVER instead of OBEX_MODE_CLIENT. I can notice similar mode comparisons in other places, even in the core library: for example, obex_data_indication() in obex_main.c. I admit that such places in the code could turn out to be perfectly safe after deeper analysis of the code paths, but at the first glance it's just plain wrong. And it shouldn't be so, in my opinion. Please let me know what do you think about this and whether should I update the patch or not. P.S. Could the list moderator please approve my subscription? I don't receive new messages, have to refresh mailarchive in browser. ----- Regards, max ulidtko ------------------------------------------------------------------------------ Achieve Improved Network Security with IP and DNS Reputation. Defend against bad network traffic, including botnets, malware, phishing sites, and compromised hosts - saving your company time, money, and embarrassment. Learn More! http://p.sf.net/sfu/hpdev2dev-nov _______________________________________________ Openobex-users mailing list Openobex-users@lists.sourceforge.net http://lists.sourceforge.net/lists/listinfo/openobex-users
