Hi Marcel=20
This is getting interesting looks like I am completing my Masters =
thesis & you are mentoring (or vice versa).=20
You don't need a scatterent to connect two piconet. Two piconets =
(basically piconet devices) can be connected via an ethernet wire or =
WLAN AP. I have done that its not magic. After connecting we can create =
an IP infrastructure make every device IP addressable (that is where I =
said there can be some IP addressing problem and I am trying to solve & =
publish it anyway its no concern here). Now the question comes sending =
SDP records - to know what kind of service each piconet device provides =
etc ?? If we have an IP infrastructure then why nt use UPnP protocol we =
don't need BTH SDP protocol (I guess UPnP protocol provides more =
flexibility than SDP (I am nt an expert in UPnP)). But if you still want =
BTH SDP then send SDP records in IP packets (not good). (Make IP =
connections between devices to transfer data etc no need to make RFCOMM =
connections run thousands of legacy IP applications without modifying a =
single line of code, I am nt able to understand why people are pushing =
for RFCOMM etc but nt what we are discussing here).=20
regards
Somil
-----Original Message-----
From: [email protected]
[mailto:[email protected]]On Behalf Of ext Marcel
Holtmann
Sent: Sunday, June 06, 2004 7:56 PM
To: Asthana Somil (EXT-Nokia-NRC/Boston)
Cc: [email protected]; BlueZ Mailing List
Subject: RE: [Bluez-users] Can you spoof/forge Bluetooth
Devices/Address?
Hi Somil,
> Why not use PAN profile instead of RFCOMM. We create an IP =
infrastructure (using Ethernet Bridging) route (or broadcast) packets =
between devices. If some BTH devices donot support PAN profile we can =
make devices attached to them as proxies. The adv of using PAN profile =
is that it can easily attached to IP back bone and this proj requires =
that (although it can result in some addressing issues). I am not sure =
if this is what David wants but you are correct there is no need to =
spoof addresses or try getting the raw BTH packets etc.
I haven't read his documents in detail, but as I understand it he want's
to connect from a PC in one piconet to a mobile phone in another
piconet. These piconets are connected through an IP backbone and not via
a scatternet. So he must make the SPD records of the phone visible in
both piconets and if needed route a L2CAP or RFCOMM connection between
them. However it is his master thesis and not mine.
Regards
Marcel
-------------------------------------------------------
This SF.Net email is sponsored by the new InstallShield X.
>From Windows to Linux, servers to mobile, InstallShield X is the one
installation-authoring solution that does it all. Learn more and
evaluate today! http://www.installshield.com/Dev2Dev/0504
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
On Mon 2004-06-07 (10:11), Marcel Holtmann wrote:
>
> However David mentioned he wants to talk to a phone and right now I
> haven't seen any phone with PAN or UPnP. To support legacy devices you
> need a distributed SDP database (you must keep it up-to-date) and use
> somekind of tunneling for the RFCOMM channels. The RFCOMM tunnel is very
> easy to achieve. It is a simple mapping from a TCP stream to a RFCOMM
> stream. You can also map it to different channel numbers on each side.
> The real problem here is the SDP database. Think about it.
>
Hi,
You are right in that we are wanting this to work with legacy devices, and
therefore there can be no modification to the phone's bluetooth stack. For
all intesnts and purposes the phone must think it communicating with the PC,
or the applications on the phone at least. I had thought that intial device
discovery would be the first and hardest problem to get around. Or am I
missing somthing in SDP? How to get a phone to talk to a repeater intailly
is the problem I think I will have. And that was why I was hopping to spoof
the PC by the repeater. Thanks for help and suggestions so far.
-dave
-------------------------------------------------------
This SF.Net email is sponsored by: GNOME Foundation
Hackers Unite! GUADEC: The world's #1 Open Source Desktop Event.
GNOME Users and Developers European Conference, 28-30th June in Norway
http://2004/guadec.org
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
Hi Somil,
> This is getting interesting looks like I am completing my Masters thesi=
s & you are mentoring (or vice versa).=20
> You don't need a scatterent to connect two piconet. Two piconets (basica=
lly piconet devices) can be connected via an ethernet wire or WLAN AP. I ha=
ve done that its not magic. After connecting we can create an IP infrastruc=
ture make every device IP addressable (that is where I said there can be so=
me IP addressing problem and I am trying to solve & publish it anyway its n=
o concern here). Now the question comes sending SDP records - to know what =
kind of service each piconet device provides etc ?? If we have an IP infras=
tructure then why nt use UPnP protocol we don't need BTH SDP protocol (I gu=
ess UPnP protocol provides more flexibility than SDP (I am nt an expert in =
UPnP)). But if you still want BTH SDP then send SDP records in IP packets (=
not good). (Make IP connections between devices to transfer data etc no nee=
d to make RFCOMM connections run thousands of legacy IP applications withou=
t modifying a single line of code, I am nt able to understand why people ar=
e pushing for RFCOMM etc but nt what we are discussing here).=20
actually I don't think the point here is building the scatternet or
using IP to extend it. We already know that if we use PAN this is
working perfect and with Linux bridging, VLAN and NAT it is possible to
create this in an easy way. I've done this before without Bluetooth so
am not really interested in this way, because it is the same and nothing
really new.
However David mentioned he wants to talk to a phone and right now I
haven't seen any phone with PAN or UPnP. To support legacy devices you
need a distributed SDP database (you must keep it up-to-date) and use
somekind of tunneling for the RFCOMM channels. The RFCOMM tunnel is very
easy to achieve. It is a simple mapping from a TCP stream to a RFCOMM
stream. You can also map it to different channel numbers on each side.
The real problem here is the SDP database. Think about it.
Regards
Marcel
-------------------------------------------------------
This SF.Net email is sponsored by the new InstallShield X.
>From Windows to Linux, servers to mobile, InstallShield X is the one
installation-authoring solution that does it all. Learn more and
evaluate today! http://www.installshield.com/Dev2Dev/0504
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users