Hi all,
I have a couple of question I was not able to give an answer to by
digging into the archives or FAQs.
My application uses standard linux tty primitives on the RFCOMM
devices to communicate with remote sensors. The application is
iteratively quering the device by writing command and reading back
answer. This is working fine.
I'm in the need of detecting when a link disconnection occur in order
to handle the situation. How can I do that? Is RFCOMM tty sending a
signal to my process that I can catch?
It would be a good thing also being able to manage when the link comes
back again. Shall I close and reopen the corresponding device or is
there a way to reuse the same file descriptor I was using before the
disconnection occurred?
One more bit...I see RFCOMM can be used also by a socket API. Is this
more flexible/powerfull than the standard tty? At moment I have to
stick to the legacy tty one, but for the future I should consider
switching to it, if there is any potential improvement.
Regards and TIA for help
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
Hi Andrea,
> > if you poll the TTY you should get a HUP signal. Keeping the same file
> > descriptor is not possible since on disconnect the TTY will be close. It
> > won't re-connect automatically. So you have to open it again to trigger
> > the actual re-connection.
>
> I'm trying to catch the HUP but with no luck. I'm probably doing
> something wrong. Basically I do the following:
not the HUP signal from the process. The HUP signal when using poll().
Regards
Marcel
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
Hi Marcel, thanks for your answers.
> if you poll the TTY you should get a HUP signal. Keeping the same file
> descriptor is not possible since on disconnect the TTY will be close. It
> won't re-connect automatically. So you have to open it again to trigger
> the actual re-connection.
I'm trying to catch the HUP but with no luck. I'm probably doing
something wrong. Basically I do the following:
void hangup_handler (int signal_number) {
/* terminate the process on link lost */
printf("Hello from my SIGHUP handler\n");
exit(2);
}
int main(void) {
struct sigaction sa;
/* Install the signal handler for disconnections */
memset(&sa, 0, sizeof(sa));
sa.sa_handler = &hangup_handler;
sigaction(SIGHUP, &sa, NULL);
poll_device();
}
The apllication process correctly catches and handle the signal if I
issue it by "kill -SIGHUP <pid>", but nothing happens if I switch off
my remote device causing the link loss.
> The socket API is much more flexible. Use that one.
I'm unexperienced in sockets programming. Can you suggest me a good
documentation on using sockets with bluez rfcomm?
Regards,
Andrea
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
Hi Andrea,
> I have a couple of question I was not able to give an answer to by
> digging into the archives or FAQs.
>
> My application uses standard linux tty primitives on the RFCOMM
> devices to communicate with remote sensors. The application is
> iteratively quering the device by writing command and reading back
> answer. This is working fine.
>
> I'm in the need of detecting when a link disconnection occur in order
> to handle the situation. How can I do that? Is RFCOMM tty sending a
> signal to my process that I can catch?
> It would be a good thing also being able to manage when the link comes
> back again. Shall I close and reopen the corresponding device or is
> there a way to reuse the same file descriptor I was using before the
> disconnection occurred?
if you poll the TTY you should get a HUP signal. Keeping the same file
descriptor is not possible since on disconnect the TTY will be close. It
won't re-connect automatically. So you have to open it again to trigger
the actual re-connection.
> One more bit...I see RFCOMM can be used also by a socket API. Is this
> more flexible/powerfull than the standard tty? At moment I have to
> stick to the legacy tty one, but for the future I should consider
> switching to it, if there is any potential improvement.
The socket API is much more flexible. Use that one.
Regards
Marcel
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users