"bluetooth scan for nearby devices" finds nonexistent source / hardware AFTER it is removed
by jan128 from LinuxQuestions.org on (#59X9Y)
I hope this question is OK to post here.
If not, please just ignore it, pretty please.
This is a bluetooth technology issue as used in Linux.
Yes, bluetooth IS part of the Linux kernel.
Bluetooth is well defined communication technology, and as ANY communication technology it has basic parts, also well defined - source / sender , communication path / media , load/receiver.
All works as expected....
BUT , there is always BUT"...
The actual INITIAL process of identifying the source" is complex, but logical and works.
Again, to emphasize, whatever combination of hardware and software is involved works.
However , when source hardware is removed (!) and process of identifying the source" is
run, by software, again - the source" is magically identified again.
Again, to make clear, the source of non-existent hardware is identified.
As simplify as possible - where is this non-existent source data coming from ?"
Best guess - the identify source process software " does not actually scan for near-by bluetooth devices , it pick the data from unknown data source.
Yes, I have asked this (question) in many forums, some generic , some specialized in bluetooth technology.
The answers ranged from it's a bug...", it originates in blueZ" stack" , and nobody can identify the source code (blueZ is well documented ?...." )
Can anybody in this forum help to find the problem, and hopefully help to find the real solution ?
Posting a bug is not my choice.
I prefer to identify the offending code , anywhere, but preferably in an official Linux source code or in blueZ"stack.
Thanks for reading
If not, please just ignore it, pretty please.
This is a bluetooth technology issue as used in Linux.
Yes, bluetooth IS part of the Linux kernel.
Bluetooth is well defined communication technology, and as ANY communication technology it has basic parts, also well defined - source / sender , communication path / media , load/receiver.
All works as expected....
BUT , there is always BUT"...
The actual INITIAL process of identifying the source" is complex, but logical and works.
Again, to emphasize, whatever combination of hardware and software is involved works.
However , when source hardware is removed (!) and process of identifying the source" is
run, by software, again - the source" is magically identified again.
Again, to make clear, the source of non-existent hardware is identified.
As simplify as possible - where is this non-existent source data coming from ?"
Best guess - the identify source process software " does not actually scan for near-by bluetooth devices , it pick the data from unknown data source.
Yes, I have asked this (question) in many forums, some generic , some specialized in bluetooth technology.
The answers ranged from it's a bug...", it originates in blueZ" stack" , and nobody can identify the source code (blueZ is well documented ?...." )
Can anybody in this forum help to find the problem, and hopefully help to find the real solution ?
Posting a bug is not my choice.
I prefer to identify the offending code , anywhere, but preferably in an official Linux source code or in blueZ"stack.
Thanks for reading