Re: Bluetooth DDI [Getting Interface via IRP_MN_QUERY_INTERFACE]

Tech-Archive recommends: Fix windows errors by optimizing your registry

1) you need to setup the next stack location
2) you need to call IoCallDriver() with the devobj returned from
IoAttachDeviceToDeviceStack, not the PDO itself. these could be the same,
but not necessarily.
3) did you initialize the Interface field?

this interface is to be notificated about remote devices connecting to your
PSM. it has nothing to do with incoming data on an already created
connection.

d

--
Please do not send e-mail directly to this alias. this alias is for
newsgroup purposes only.
This posting is provided "AS IS" with no warranties, and confers no rights.


"Bill McKenzie" <bkmckenzie_remove_@xxxxxxxxxxxxx> wrote in message
news:ODMSLIeXGHA.4144@xxxxxxxxxxxxxxxxxxxxxxx
Dude, post the entire structure setup you are using for the query
interface. It is almost a certainty that you are not setting this
structure up correctly.

I have never gotten back an empty structure though for a successful call,
that is a new one on me.

Bill McKenzie

"RichardMAN" <RichardMAN@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:13F32523-6682-407E-848C-6A1D8374F420@xxxxxxxxxxxxxxxx

Doron

After a good night sleep, it turns out that i were using device object
from
IoGetAttachedDeviceReference, which i know it always return device object
top
of the stack, and not the PDO I intend to, and which I know I shouldn't
make
a silly and careless mistake like this, but I did. I do apologies for
this.

Now the driver is enumerated by the bthport, sending brbs are ok, but my
IRP_MN_QUERY_INTERFACE is still having a problem though. If I send the
IRP_MN_QUERY_INTERFACE irp to the same stack location of the PDO
(828e4690),
I get OK from IoCallDriver, but the returned structure is empty; if I
send
the irp to the next stack location of PDO, I get STATUS_NOT
SUPPORT(0xc00000bbL) from IoCallDriver. The structure I passed down look
like
this:

=====================
typedef struct _L2CAP_SERVER_INTERFACE {
INTERFACE Interface;
BTH_ADDR BtAddress;
USHORT PSM;
ULONG IndicationFlags;
PFNBTHPORT_INDICATION_CALLBACK IndicationCallback;
OUT PFNBTHPORT_REMOVE_INDICATION_CALLBACK RemoveIndicationCallback;
OUT PVOID RemoveIndicationContext;

} L2CAP_SERVER_INTERFACE, *PL2CAP_SERVER_INTERFACE;
=====================

I filled in PSM, Btaddress(remote devie) and IndicationCallback before
passing down the irp, but everything else is empty and i don't get and
IndicationCallback on incoming data, e.g. after I send data with
ACL_TRANSFER brb and data received as confirmed by remote device, but no
indication on incoming data sent by remote device.

With limited documentation on DDI, I hope i get this idea right: Both
L2CAP
and SCO open channel BRB structure allows user to supply Callback pointer
for
connection indication, which I am successfully getting of. But for ACL
command data for everything else except RFCOMM, I need to register
L2CAP_SERVER_INTERFACE with the right PSM (no RFCOMM) and provide
IndicationCallback for incoming data indication, right?

Thank you.

RichardMAN

"Doron Holan [MS]" wrote:

when you are sending the BRB, are you sending it to the attached device
object that was returned from IoAttachDeviceToDeviceStack? in this
case,
828e4690.

bthusb is the bthport miniport for the usb HCI. are you sending i/o to
the
FDO of the stack?

d
--
Please do not send e-mail directly to this alias. this alias is for
newsgroup purposes only.
This posting is provided "AS IS" with no warranties, and confers no
rights.


"RichardMAN" <RichardMAN@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:E00C699E-CE88-4CE3-84DE-A59FEF45FBDF@xxxxxxxxxxxxxxxx

Doron

Yes I can confirm that the driver is enumerated by bthport:

===============
kd> !devstack 8296aa30
!DevObj !DrvObj !DevExt ObjectName
8296aa30 \Driver\BTHDDI 8296aae8 BTHDDI
828e4690 \Driver\BthEnum 828e4748 000000ac
!DevNode 82c165a8 :
DeviceInst is
"BTHENUM\{0000111a-0000-1000-8000-00805f9b34fb}\7&217db6bf&0&0013D368D0E2_C00000001"
ServiceName is "BTHDDI"
===============

Thing is, not only getting Interface back is the problem, sending BRBs
down
to the driver doesn't even work anymore now with the driver enumerated
by
bthport. The same BRBs WORK if the device stack is as following:

===============
kd> !devstack \Device\USBPDO-4
!DevObj !DrvObj !DevExt ObjectName
82b74020 \Driver\BTHUSB 82b740d8
82a61030 \Driver\usbhub 82a610e8 USBPDO-4
!DevNode 829839c0 :
DeviceInst is "USB\Vid_0db0&Pid_a970\5&12f0edd2&0&2"
ServiceName is "BTHUSB"
===============

USBPDO-4 is the actual Bluetooth USB device. I must be doing something
silly, by sending BRB to BthUSB and not BthPort, right? But I do get
success
responses (open/close L2cap channel) this way, as confirmed by the
remote
device.

So what have I misunderstood here?

Regards
RichardMAN

"Doron Holan [MS]" wrote:

INTERFACE is just the header (e.g. first set of fields) to the rest
of
the
structure. you need to pass the correct structure (which i don't
remember
offhand).

to check to see if your PDO is enumerated by bthport (bthenum
actually),
execute !devstack <your FDO> and see what the device instance path
is,
read
http://blogs.msdn.com/doronh/archive/2006/03/15/552301.aspx for more
info

d

--
Please do not send e-mail directly to this alias. this alias is for
newsgroup purposes only.
This posting is provided "AS IS" with no warranties, and confers no
rights.


"RichardMAN" <RichardMAN@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:414BCAC2-8A5F-4417-933B-CF2D330BF44F@xxxxxxxxxxxxxxxx
Does anyone has any chance working on Bluetooth DDI so far?
STATUS_NOT_SUPPORT (0xc00000bb) returned by IoCallDriver when I
pass
down
IRP_MN_QUERY_INTERFACE irp to lower driver stack PDO (which is
BTHPORT).
The
driver is enumerated by BTHPORT all right, *I assumed*.

One way or another, I may get STATUS_INVALID_DEVICE_REQUEST with
various
attempt to send IRP_MN_QUERY_INTERFACE. Doron suggested that I
might
have
the
interface structure not well formed.

I'm not sure what may the interface structure I need to form. I
don't
think
I'm doing anything different to query interface. Has anyone had any
success
with getting Interface, or working on anything else, with Bluetooth
DDI?
Much
Appreciated.

==========
DEFINE_GUID(GUID_BTHDDI_SERVER_INTERFACE, 0x2caf6042, 0x3468,
0x4e46,
0xbf,
0xd6, 0x86, 0xd4, 0xbe, 0xf0, 0xb, 0x71);
PINTERFACE Interface;

irpStack->MinorFunction = IRP_MN_QUERY_INTERFACE;
irpStack->Parameters.QueryInterface.InterfaceType = (LPGUID)
&GUID_BTHDDI_SERVER_INTERFACE;
irpStack->Parameters.QueryInterface.Size = sizeof(INTERFACE);
irpStack->Parameters.QueryInterface.Version = 1;
irpStack->Parameters.QueryInterface.Interface = (PINTERFACE)
Interface;
irpStack->Parameters.QueryInterface.InterfaceSpecificData = NULL;
==========

Thanks
RichardMAN










.

Relevant Pages

  • Re: Bluetooth DDI [Getting Interface via IRP_MN_QUERY_INTERFACE]
    ... If I attach FDO to PDO, i.e. IoAttachDeviceToDeviceStack, its ... I thought i need to send the irp to PDO?! ... did you initialize the Interface field? ... Now the driver is enumerated by the bthport, sending brbs are ok, but my ...
    (microsoft.public.development.device.drivers)
  • Re: Unexpected multicast IPv4 socket behavior
    ... Default route set, src INADDR_ANY: ... src bindto interface address: ... There's no way for the stack to know which interface to originate the traffic from in the case where there is no default route, and no IP layer source information elsewhere in the stack. ... the use of multicast requires that you create a socket and bind to the interface where you wish to send and receive the channel. ...
    (freebsd-net)
  • Re: Forth Frustrations
    ... I was working on an interface to my new window system in Ficl. ... I found it extremely frustrating to juggle around data on the stack, such as 2 RGBA color components when building a gradient. ... I've been accused of programming C in Forth, as if that's somehow terrible, but I digress... ... I was thinking that indexed keyed arrays might be an approach, or a completely different language. ...
    (comp.lang.forth)
  • C call interface (was: 2nd RfD: Separate FP Stack)
    ... It's not the only C-calling interface that does that; ... on IA-32 this is parameter passing on the stack. ... programmer just to make the system implementor's job slightly easier). ... the stack effect (target query v --). ...
    (comp.lang.forth)
  • Forth Frustrations
    ... I was working on an interface to my new window system in Ficl. ... have more than 3 or 4 items on the stack at once. ... Now unmotivated and realizing that the structure really sucks in my Ficl ... Data structures, not algorithms, are central to ...
    (comp.lang.forth)