From: Sahaja T. <Sah...@ac...> - 2007-10-19 17:43:57
|
Hello Marcel, Christian and All,=20 (I posted this on the forum, but due to urgency of my project delivery, = I am also mailing this to you hoping to get your attention sooner) =A0 I wrote a syncml obex client using tcpobex for transport; This client = can communicate with a local obex server; As I could see both are using = ipv6. However it can't connect with the SCTS OBEX server on different = machine which has windows and SCTS Server running; I suspect SCTS OBEX = server is using ipv6. I noticed that openobex(tcpobex) doesn't let you = use IP version4, even though the documentation says otherwise; If you = attempt to used ipv4, it resets all the parameter back to ipv6 in case = of client; And in case of server it server registration fails when ipv4 = is used.=20 Is ipv4 really supported and tested?=20 =A0 Thank you,=20 Sahaja Talla |
From: Sahaja T. <Sah...@ac...> - 2007-11-08 19:45:05
|
Hi Marcel, Christian and all - The SYNCML-OBEX binding (link provided in the following) http://www.openmobilealliance.org/release_program/docs/Common/V1_2-20040 601-C/OMA-SyncML-OBEXBinding-V1_2-20040601-C.pdf mandates that OBEX server should provide the proper responses during connection establishment (this contains the important information such as connection id that is used in all the subsequent communication) and when message is to be sent is large such that PUT request is fragmented among multiple requests, and when GET request is split. However the current openobex code doesn't properly handover that response data. =20 In case of connect response it does call the call back function registered during the OBEX_Init call. However it doesn't pass the correct data that was sent by the STCS OBEX server. In case of PUT and GET CONTNUE response the call back routines is not even called. I needed to make the following changes to the openobex source code, and all of them are related to this same issue. In obex_client.c : int obex_client(obex_t *self, buf_t *msg, int final) {=20 . . . // The following is to ensure that OBEX_RSP_CONTINUE responses from the obex // server are also passed on via event call back routine; Comment out the=20 // code to handle OBEX_RSP_CONTINUE differently than the case when=20 // OBEX_RSP_SUCCESS if (rsp =3D=3D OBEX_RSP_CONTINUE) { =3D=3D> if (0)//(rsp =3D=3D = OBEX_RSP_CONTINUE)=20 DEBUG(3, "Continue...\n"); if (0)//(rsp =3D=3D OBEX_RSP_CONTINUE)=20 =09 =09 =09 In obex_main.c : void obex_deliver_event(obex_t *self, int event, int cmd, int rsp, int del) { . . self->eventcb(self, object, OBEX_MODE_CLIENT, event, cmd, rsp); =3D=3D> self->eventcb(self, self->rx_msg->buffer, OBEX_MODE_CLIENT, event, cmd, rsp); =09 . . =09 =09 } In obex_tranport.c : int obex_transport_handle_input(obex_t *self, int timeout) { ..... if( (self->fd >=3D 0) && FD_ISSET(self->fd, &fdset)) { =09 DEBUG(4, "Data available on client socket\n"); // The following is to ensure that, when receiving continue response from=20 // the obex server, state machine is in receiving state; If you prefer // same thing could be done after calling obex_object_send even when the // message is not completely sent out self->state =3D MODE_CLI | STATE_REC; <=3D=3D=3D this line is added =09 Also in obex.c I had to add my own function to establish a tcp connection. The files with changes are also attached. Please advise as to how best to get these changes into openobex. Sahaja |
From: Hendrik S. <po...@he...> - 2007-11-08 20:57:14
|
Am Donnerstag 08 November 2007 schrieb Sahaja Talla: > The files with changes are also attached. Please advise as to how best > to get these changes into openobex. Send a proper patch? (I suggest using quilt for that) And maybe explain why you don't just give a proper struct sockaddr_in to TcpOBEX. HS |
From: Sahaja T. <Sah...@ac...> - 2007-11-15 03:06:09
|
Hello Marcel, and Christian, I saw my message been published on the mailing list and seems like later removed. Could you please explain? I was actually hoping for response! -Sahaja -----Original Message----- From: Sahaja Talla=20 Sent: Thursday, November 08, 2007 11:44 AM To: 'ope...@li...' Cc: Gerard Pallipuram; Ravi Duggaraju; Frederic Danis; Rene Pourtier; Diane Holt Subject: to minor fixes needed in the openobex code Hi Marcel, Christian and all - The SYNCML-OBEX binding (link provided in the following) http://www.openmobilealliance.org/release_program/docs/Common/V1_2-20040 601-C/OMA-SyncML-OBEXBinding-V1_2-20040601-C.pdf mandates that OBEX server should provide the proper responses during connection establishment (this contains the important information such as connection id that is used in all the subsequent communication) and when message is to be sent is large such that PUT request is fragmented among multiple requests, and when GET request is split. However the current openobex code doesn't properly handover that response data. =20 In case of connect response it does call the call back function registered during the OBEX_Init call. However it doesn't pass the correct data that was sent by the STCS OBEX server. In case of PUT and GET CONTNUE response the call back routines is not even called. I needed to make the following changes to the openobex source code, and all of them are related to this same issue. In obex_client.c : int obex_client(obex_t *self, buf_t *msg, int final) {=20 . . . // The following is to ensure that OBEX_RSP_CONTINUE responses from the obex // server are also passed on via event call back routine; Comment out the=20 // code to handle OBEX_RSP_CONTINUE differently than the case when=20 // OBEX_RSP_SUCCESS if (rsp =3D=3D OBEX_RSP_CONTINUE) { =3D=3D> if (0)//(rsp =3D=3D = OBEX_RSP_CONTINUE)=20 DEBUG(3, "Continue...\n"); if (0)//(rsp =3D=3D OBEX_RSP_CONTINUE)=20 =09 =09 =09 In obex_main.c : void obex_deliver_event(obex_t *self, int event, int cmd, int rsp, int del) { . . self->eventcb(self, object, OBEX_MODE_CLIENT, event, cmd, rsp); =3D=3D> self->eventcb(self, self->rx_msg->buffer, OBEX_MODE_CLIENT, event, cmd, rsp); =09 . . =09 =09 } In obex_tranport.c : int obex_transport_handle_input(obex_t *self, int timeout) { ..... if( (self->fd >=3D 0) && FD_ISSET(self->fd, &fdset)) { =09 DEBUG(4, "Data available on client socket\n"); // The following is to ensure that, when receiving continue response from=20 // the obex server, state machine is in receiving state; If you prefer // same thing could be done after calling obex_object_send even when the // message is not completely sent out self->state =3D MODE_CLI | STATE_REC; <=3D=3D=3D this line is added =09 Also in obex.c I had to add my own function to establish a tcp connection. The files with changes are also attached. Please advise as to how best to get these changes into openobex. Sahaja |
From: Hendrik S. <po...@he...> - 2007-11-15 08:34:13
|
Quoting Sahaja Talla <Sah...@ac...>: > I saw my message been published on the mailing list and seems like later > removed. Could you please explain? I was actually hoping for response! I did reply. > [some confusing stuff] > Also in obex.c I had to add my own function to establish a tcp > connection. Only because you didn't use the methods that are already provided. Programming IPv4-only just isn't the way anymore, it's 2007! > The files with changes are also attached. Please advise as to how best > to get these changes into openobex. Use quilt or another tool of your choice to create a proper diff/patch and file a ticket under www.openobex.org HS |
From: Hendrik S. <po...@he...> - 2007-10-19 21:01:52
|
Am Freitag 19 Oktober 2007 schrieb Sahaja Talla: > Hello Marcel, Christian and All, > > (I posted this on the forum, but due to urgency of my project delivery, I > am also mailing this to you hoping to get your attention sooner) > I wrote a syncml obex client using tcpobex for transport; This client can > communicate with a local obex server; As I could see both are using ipv6. > However it can't connect with the SCTS OBEX server on different machine > which has windows and SCTS Server running; I suspect SCTS OBEX server is > using ipv6. I noticed that openobex(tcpobex) doesn't let you use IP > version4, even though the documentation says otherwise; If you attempt to > used ipv4, it resets all the parameter back to ipv6 in case of client; And > in case of server it server registration fails when ipv4 is used. Is ipv4 > really supported and tested? If you use the CVS version of OpenOBEX and use the TcpOBEX_* functions there, IPv6 connectivity should work. Those function rely on a dual-IP stack in the OS. For Linux, the IPv4-mapped addresses work, meaning that IPv4 can be used but appear to the application as IPv6 connection. This has the advantage that only IPv6 must be supported but IPv4 is still usable. For usage on Windows, you may try my personal SVN repository which has additional patches for win32 support. However, Windows XP does not have a dual-IP stack and thus OpenOBEX is limited to IPv6 there. On Windows Vista (with its dual-IP stack), IPv4 should also work if you set the IPV6_V6ONLY socket option to 0 (use in conjunction with OBEX_GetFD()). HS |