[Bluez-devel] socket connect returns EAGAIN

Jose Vasconcellos

author

2006-09-12 00:47 UTC #0 lore raw

Hello,

I'm wondering why bluetooth sockets return EAGAIN on connect quite frequently for both RFCOMM and SCO when O_NONBLOCK is set. Is this the correct behavior?

-Jose

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Peter Wippich

2006-09-12 08:40 UTC #1 lore raw

Hi Jose,

see my last post on this subject about 4 days ago. From my understanding they shall return EINPROGRESS when the connection to the remote device is pending. Returning EAGAIN looks like a small bug. See also man 2 connect or man 7 socket.

Ciao,

Peter

Quoted 9 lines · Jose Vasconcellos

Hello,
I'm wondering why bluetooth sockets return EAGAIN on connect quite frequently for both RFCOMM and SCO when O_NONBLOCK is set. Is this the correct behavior?
-Jose

Quoted 10 lines

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

|       Peter Wippich                   Voice: +49 30 46776411          |
|       G&W Instruments GmbH            fax:   +49 30 46776419          |
|       Gustav-Meyer-Allee 25, Geb. 12  Email: [email protected]   |
|       D-13355 Berlin  / Germany                                       |

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Marcel Holtmann

maintainer

2006-09-12 08:43 UTC #2 lore raw

Hi Peter,

Quoted 4 lines

see my last post on this subject about 4 days ago. From my understanding they shall return EINPROGRESS when the connection to the remote device is pending. Returning EAGAIN looks like a small bug. See also man 2 connect or man 7 socket.

this has been raised a long time ago. However the Bluetooth core inside the kernel doesn't sets the wrong error. It is one of the network functions we use.

Regards

Marcel

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Peter Wippich

2006-09-12 10:13 UTC #3 lore raw

Hi Marcel,

Quoted 10 lines · Marcel Holtmann

Hi Peter,
Quoted 4 lines
see my last post on this subject about 4 days ago. From my understanding they shall return EINPROGRESS when the connection to the remote device is pending. Returning EAGAIN looks like a small bug. See also man 2 connect or man 7 socket.
this has been raised a long time ago. However the Bluetooth core inside the kernel doesn't sets the wrong error. It is one of the network functions we use.

Are you sure ?!?

I think the problem is in bt_sock_wait_state(...). This always returns -EAGAIN if timeout is zero (which it is if the socket is set non blocking). But may be I'm missing something.

Ciao,

Peter

|       Peter Wippich                   Voice: +49 30 46776411          |
|       G&W Instruments GmbH            fax:   +49 30 46776419          |
|       Gustav-Meyer-Allee 25, Geb. 12  Email: [email protected]   |
|       D-13355 Berlin  / Germany                                       |

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Marcel Holtmann

maintainer

2006-09-12 10:29 UTC #4 lore raw

Hi Peter,

Quoted 9 lines

Quoted 8 lines
Quoted 4 lines
see my last post on this subject about 4 days ago. From my understanding they shall return EINPROGRESS when the connection to the remote device is pending. Returning EAGAIN looks like a small bug. See also man 2 connect or man 7 socket.
this has been raised a long time ago. However the Bluetooth core inside the kernel doesn't sets the wrong error. It is one of the network functions we use.

Quoted 5 lines

Are you sure ?!?
I think the problem is in bt_sock_wait_state(...). This always returns -EAGAIN if timeout is zero (which it is if the socket is set non blocking). But may be I'm missing something.

not 100% sure, but last time I tracked this down. Feel free to propose a patch that changes the behavior and brings it in sync with the manual page.

Regards

Marcel

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Jose Vasconcellos

author

2006-09-13 14:21 UTC #5 lore raw

In reply to Peter Wippich

Quoted 20 lines · Peter Wippich

Hi Marcel,
Quoted 12 lines · Marcel Holtmann
Hi Peter,
Quoted 5 lines
see my last post on this subject about 4 days ago. From my understanding they shall return EINPROGRESS when the connection to the remote device is pending. Returning EAGAIN looks like a small bug. See also man 2 connect or man 7 socket.
this has been raised a long time ago. However the Bluetooth core inside the kernel doesn't sets the wrong error. It is one of the network functions we use.
Are you sure ?!?

Quoted 9 lines

I think the problem is in bt_sock_wait_state(...). This always returns -EAGAIN if timeout is zero (which it is if the socket is set non blocking). But may be I'm missing something.
Ciao,
Peter

Hi Peter,

I've come to a similar conclusion. I'm not sure why it's returning -EAGAIN. However, looking at the x25 transport (af_x25.c), it takes a different approach;
if O_NONBLOCK is set they don't call the blocking routine at all. Maybe a similar approach should be taken here.

Jose

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Peter Wippich

2006-09-14 09:01 UTC #6 lore raw

Hi Jose,

Quoted 9 lines · Jose Vasconcellos

Quoted 9 lines
I think the problem is in bt_sock_wait_state(...). This always returns -EAGAIN if timeout is zero (which it is if the socket is set non blocking). But may be I'm missing something.
Ciao,
Peter

Quoted 8 lines

Hi Peter,
I've come to a similar conclusion. I'm not sure why it's returning -EAGAIN. However, looking at the x25 transport (af_x25.c), it takes a different approach;
if O_NONBLOCK is set they don't call the blocking routine at all. Maybe a similar approach should be taken here.

returning EAGAIN is fine for a listening socket. I first thought the solution of not calling bt_sock_wait_state() for a non blocking connect would be the easiest solution, too. But then you have to correct it on several places. Just changing bt_sock_wait_state() will solve it for various socket types.

Ciao,

Peter

|       Peter Wippich                   Voice: +49 30 46776411          |
|       G&W Instruments GmbH            fax:   +49 30 46776419          |
|       Gustav-Meyer-Allee 25, Geb. 12  Email: [email protected]   |
|       D-13355 Berlin  / Germany                                       |

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Marcel Holtmann

maintainer

2006-09-15 09:49 UTC #7 lore raw

Hi Peter,

Quoted 10 lines

Quoted 10 lines
Quoted 3 lines
I think the problem is in bt_sock_wait_state(...). This always returns -EAGAIN if timeout is zero (which it is if the socket is set non blocking). But may be I'm missing something.
I've come to a similar conclusion. I'm not sure why it's returning -EAGAIN. However, looking at the x25 transport (af_x25.c), it takes a different approach;
if O_NONBLOCK is set they don't call the blocking routine at all. Maybe a similar approach should be taken here.

Quoted 5 lines

returning EAGAIN is fine for a listening socket. I first thought the solution of not calling bt_sock_wait_state() for a non blocking connect would be the easiest solution, too. But then you have to correct it on several places. Just changing bt_sock_wait_state() will solve it for various socket types.

sounds like a good idea. Anyone preparing a patch for it?

Regards

Marcel

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Ulisses Furquim

2006-09-20 14:48 UTC #8 lore raw

Quoted 10 lines · Marcel Holtmann

Quoted 10 lines
Quoted 10 lines
Quoted 3 lines
I think the problem is in bt_sock_wait_state(...). This always returns -EAGAIN if timeout is zero (which it is if the socket is set non blocking). But may be I'm missing something.
I've come to a similar conclusion. I'm not sure why it's returning -EAGAIN. However, looking at the x25 transport (af_x25.c), it takes a different approach;
if O_NONBLOCK is set they don't call the blocking routine at all. Maybe a similar approach should be taken here.

Quoted 7 lines

Quoted 5 lines
returning EAGAIN is fine for a listening socket. I first thought the solution of not calling bt_sock_wait_state() for a non blocking connect would be the easiest solution, too. But then you have to correct it on several places. Just changing bt_sock_wait_state() will solve it for various socket types.
sounds like a good idea. Anyone preparing a patch for it?

Sorry, but I'm failing to see why we can't just do a s/EAGAIN/EINPROGRESS/ inside bt_sock_wait_state(). Does anyone mind to explain, please?

Regards,

-- Ulisses

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Peter Wippich

2006-09-20 15:00 UTC #9 lore raw

Hi Ulisses,

Quoted 4 lines

Sorry, but I'm failing to see why we can't just do a s/EAGAIN/EINPROGRESS/ inside bt_sock_wait_state(). Does anyone mind to explain, please?

The only problem here is that somebody has to implement and test it ....

Ciao,
Peter

|       Peter Wippich                   Voice: +49 30 46776411          |
|       G&W Instruments GmbH            fax:   +49 30 46776419          |
|       Gustav-Meyer-Allee 25, Geb. 12  Email: [email protected]   |
|       D-13355 Berlin  / Germany                                       |

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Marcel Holtmann

maintainer

2006-09-20 15:05 UTC #10 lore raw

In reply to Ulisses Furquim

Hi Ulisses,

Quoted 16 lines

Quoted 16 lines
Quoted 15 lines
Quoted 10 lines
Quoted 3 lines
I think the problem is in bt_sock_wait_state(...). This always returns -EAGAIN if timeout is zero (which it is if the socket is set non blocking). But may be I'm missing something.
I've come to a similar conclusion. I'm not sure why it's returning -EAGAIN. However, looking at the x25 transport (af_x25.c), it takes a different approach;
if O_NONBLOCK is set they don't call the blocking routine at all. Maybe a similar approach should be taken here.
returning EAGAIN is fine for a listening socket. I first thought the solution of not calling bt_sock_wait_state() for a non blocking connect would be the easiest solution, too. But then you have to correct it on several places. Just changing bt_sock_wait_state() will solve it for various socket types.

Quoted 5 lines

Quoted 1 line
sounds like a good idea. Anyone preparing a patch for it?
Sorry, but I'm failing to see why we can't just do a s/EAGAIN/EINPROGRESS/ inside bt_sock_wait_state(). Does anyone mind to explain, please?

what about the server socket. In this case EAGAIN is fine.

Regards

Marcel

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Ulisses Furquim

2006-09-21 19:59 UTC #11 lore raw

Quoted 1 line · Marcel Holtmann

what about the server socket. In this case EAGAIN is fine.

Yes, in this case EAGAIN is fine. However, I don't think we are even calling bt_sock_wait_state() for a server socket (please, correct me if I'm wrong) so changing EAGAIN to EINPROGRESS inside bt_sock_wait_state() should just work, right? (we just need to fix rfcomm_session_create() too and that's it).

Regards,

-- Ulisses

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Marcel Holtmann

maintainer

2006-09-21 20:05 UTC #12 lore raw

Hi Ulisses,

Quoted 7 lines

Quoted 1 line
what about the server socket. In this case EAGAIN is fine.
Yes, in this case EAGAIN is fine. However, I don't think we are even calling bt_sock_wait_state() for a server socket (please, correct me if I'm wrong) so changing EAGAIN to EINPROGRESS inside bt_sock_wait_state() should just work, right? (we just need to fix rfcomm_session_create() too and that's it).

looks like it is okay, care to send a patch.

Regards

Marcel

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Ulisses Furquim

2006-09-22 17:47 UTC #13 lore raw

Quoted 11 lines · Marcel Holtmann

Hi Ulisses,
Quoted 7 lines
Quoted 1 line
what about the server socket. In this case EAGAIN is fine.
Yes, in this case EAGAIN is fine. However, I don't think we are even calling bt_sock_wait_state() for a server socket (please, correct me if I'm wrong) so changing EAGAIN to EINPROGRESS inside bt_sock_wait_state() should just work, right? (we just need to fix rfcomm_session_create() too and that's it).
looks like it is okay, care to send a patch.

Here is the patch. I'm running 2.6.18-mh1 plus the attached patch and I have no problems so far (but it needs more testing so we can be sure everything works).

Regards,

-- Ulisses

net/bluetooth/af_bluetooth.c +1 -1

index 788ea7a..305a099 100644
@@ -276,7 +276,7 @@ int bt_sock_wait_state(struct sock *sk, 
 		set_current_state(TASK_INTERRUPTIBLE);
 
 		if (!timeo) {
-			err = -EAGAIN;
+			err = -EINPROGRESS;
 			break;
 		}

net/bluetooth/rfcomm/core.c +1 -1

index 332dd8f..468df3b 100644
@@ -644,7 +644,7 @@ static struct rfcomm_session *rfcomm_ses
 	addr.l2_family = AF_BLUETOOTH;
 	addr.l2_psm    = htobs(RFCOMM_PSM);
 	*err = sock->ops->connect(sock, (struct sockaddr *) &addr, sizeof(addr), O_NONBLOCK);
-	if (*err == 0 || *err == -EAGAIN)
+	if (*err == 0 || *err == -EINPROGRESS)
 		return s;
 
 	rfcomm_session_del(s);

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel