32feet Work Item Rss Feed

Created Issue: [widcomm] comms stream can get stuck, need not to use upcall thread for downcall [25410]

alanjmcf — Fri, 20 Nov 2009 11:21:12 GMT

See http://32feetnetdev.wordpress.com/2009/08/13/widcomm-faults-in-obex-operations/ which finds that on Win32 that WidcommRfcommStream can get stuck after much data transfer in two ways: a) buffer-empty (TXEMPTY) event upcalls stop being sent by the stack, b) calls to Widcomm Write method never return.
The Widcomm documentation for Win32 says: "An additional implication of this guideline is that derived functions must not call back into the stack with another SDK API. Any SDK API that must be called as a result of a callback from the stack must be executed from the application main thread,not the callback execution context." This does not apply to the CE/WM Widcomm documentation.
We should implement some mechanism so that we use a new thread to stop this calling-back-into-the-stack behaviour.

Closed Issue: SDP AttributeId with MSB-set Dump prints as e.g. 0xFFFF9234 rather than as 0x9234 [25397]

alanjmcf — Thu, 19 Nov 2009 10:20:49 GMT

SDP AttributeId with MSB set prints as e.g. 0xFFFF9234 rather than as 0x9234

Created Issue: SDP AttributeId with MSB set prints as e.g. 0xFFFF9234 rather than as 0x9234 [25397]

alanjmcf — Thu, 19 Nov 2009 10:13:33 GMT

SDP AttributeId with MSB set prints as e.g. 0xFFFF9234 rather than as 0x9234

Commented Issue: [widcomm] BtCli.RemoteMachineName never returns a name [25362]

alanjmcf — Tue, 17 Nov 2009 19:27:17 GMT

In Widcomm there's apparently no API to find the name etc of a particular device. Therefore currently when WidcommBluetoothClient RemoteMachineName etc is called only address can be returned. We need to have a look in the registry to see if the device info is there (or maybe there's a hidden API!).

Created Issue: [widcomm] BtCli.RemoteMachineName never returns a name [25362]

alanjmcf — Mon, 16 Nov 2009 11:55:24 GMT

Commented Issue: ObexListener/ObexListenerContext [25320]

eruffing — Thu, 12 Nov 2009 19:13:25 GMT

I have the following piece of code listening for data in a dll. GetContext is listening for data.
Is there a way to signal olc to stop listening for data via say sending him a "QUIT" message from the same process?
I can issue ol.Stop() but the GetContext does not release (still waiting for data) and thus a hang situation.
See no relevant methods in ObexListenerContext.

private ObexListener ol;
public int ReceiveFile()
{
InTheHand.Net.Bluetooth.BluetoothRadio br = InTheHand.Net.Bluetooth.BluetoothRadio.PrimaryRadio;
br.Mode = InTheHand.Net.Bluetooth.RadioMode.Discoverable;

ol = new ObexListener(ObexTransport.Bluetooth);
ol.Start();

t = new System.Threading.Thread(new System.Threading.ThreadStart(DealWithRequest));
t.Start();

return 0;
}

public void DealWithRequest()
{
while (ol.IsListening)
{
System.Diagnostics.Trace.WriteLine("OBEX listening...");
try
{
System.Diagnostics.Trace.WriteLine("LISTENING START");
ObexListenerContext olc = ol.GetContext();
ObexListenerRequest olr = olc.Request;
}
}
}

Thank you,
Ed Ruffing

Created Issue: ObexListener/ObexListenerContext [25320]

eruffing — Thu, 12 Nov 2009 19:08:15 GMT

Commented Issue: BluetoothDeviceInfo.LastSeen LastUsed should be marked DateTimeKind.UTC [25173]

alanjmcf — Sat, 31 Oct 2009 19:12:28 GMT

These values (where valid) appear to use UTC, marks them as such.
Comments: Fixed by r60778.

Commented Issue: [widcomm] BluetoothListener doesn't listen without call to Begin-/Accept [23144]

alanjmcf — Sat, 31 Oct 2009 19:08:48 GMT

Comments: Fixed by r60218.

Created Issue: BluetoothDeviceInfo.LastSeen LastUsed should be marked DateTimeKind.UTC [25173]

alanjmcf — Sat, 31 Oct 2009 19:06:22 GMT

These values (where valid) appear to use UTC, marks them as such.

Closed Issue: Connected property (etc) NullRefEx when BluetoothClient disposed, also IrDAClient [25172]

alanjmcf — Sat, 31 Oct 2009 19:04:15 GMT

Any property/method called after the instance is disposed should not fail with NullReferenceException for instance but check if disposed and throw ObjectDisposedException.
Comments: Resolved with changeset 60777.

Created Issue: Connected property (etc) NullRefEx when BluetoothClient disposed, also IrDAClient [25172]

alanjmcf — Sat, 31 Oct 2009 19:03:03 GMT

Any property/method called after the instance is disposed should not fail with NullReferenceException for instance but check if disposed and throw ObjectDisposedException.

Closed Issue: ObexListener not to use Socket [25164]

alanjmcf — Fri, 30 Oct 2009 20:39:31 GMT

ObexListener uses Socket for its communications so its can't be used on Widcomm. (There's also the second problem which won't be covered by this bug, that the built-in OPP service on Widcomm must be disabled for it to be of any use).
Anyway, there's no support for sockets on Widcomm so BluetoothListener.Client throws NotSupported. ObexListener needs to be changed to not use Socket.
Comments: Resolved with changeset 60743.

Created Issue: ObexListener not to use Socket [25164]

alanjmcf — Fri, 30 Oct 2009 20:22:28 GMT

Commented Feature: Add a helper class to adapt a Socket client to use BluetoothClient on Widcomm [25162]

alanjmcf — Fri, 30 Oct 2009 16:26:51 GMT

If consumer code uses BluetoothClient but communicates via the Socket instance returned by Client then it will not work as Widcomm does not support Sockets. We can create a class that has an interface like Socket, but wraps a BluetoothClient. The consumer code can then be simply changed to use SocketAdapter rather than Socket.
Comments: Associated with changeset 60732.

Closed Feature: Add a helper class to adapt a Socket client to use BluetoothClient on Widcomm [25162]

alanjmcf — Fri, 30 Oct 2009 16:18:21 GMT

Created Feature: Add a helper class to adapt a Socket client to use BluetoothClient on Widcomm [25162]

alanjmcf — Fri, 30 Oct 2009 16:17:29 GMT

Commented Issue: BluetoothDeviceInfo.LastSeen doesn't return documented value [10280]

alanjmcf — Tue, 20 Oct 2009 09:54:33 GMT

See description in forum post included below.
Fix is likely to be: change documentation to note that the property can't return what it should, because the native value returned by Win32 is wrong. Could contact MSFT to ask if bug.

From http://32feet.net/forums/ShowThread.aspx?PostID=3328#3328:

After some checking Peter and I have found that the native value that we use for the LastSeen property doesn't return what it is documented to return! It always just returns the time when the discovery was completed(?), we checked both XP SP2 and Vista. So this property sadly isn't useful to find whether a particular device is in range.

As evidence.. The new SdpBrowserDesktop sample displays information on discovery as follows. The two devices listed there are not in range, they are in fact both turned off, but it reports LastSeen as a time after the discovery started.
Discovery process started at 05/14/2007 11:01:46 UTC, 05/14/2007 12:01:46 local
* FooBar1
Address: 000999011B99
Remembered: True, Authenticated: True, Connected: False
LastSeen: 05/14/2007 11:01:56, LastUsed: 01/01/0001 00:00:00
CoD: (0x00020114)
Device: PdaComputer (0x00000114)
Service: Network (0x00000010)
* FooBar2
Address: 000999686599
Remembered: True, Authenticated: True, Connected: False
LastSeen: 05/14/2007 11:01:56, LastUsed: 01/01/0001 00:00:00
CoD: (0x00720104)
Device: DesktopComputer (0x00000104)
Service: Network, ObjectTransfer, Audio, Telephony (0x00000390)
As evidence that it is the native method which is wrong, when I go to the Windows Bluetooth Control panel and view the Device Properties dialog for the first of those devices it reports:
Last connected: 14 May 2007 at 12:07:51
So that gets it wrong too, presumably using the same value...
This is not how it is described in MSDN... At http://msdn2.microsoft.com/en-us/library/aa362924.aspx it says:
stLastSeen Last time the device was seen, in the form of a SYSTEMTIME structure.
Comments: Is supported correctly by Windows 7.

Closed Issue: Windows 7 support for BluetoothWin32Authentication [24969]

alanjmcf — Mon, 19 Oct 2009 17:43:35 GMT

Comments: Resolved with changeset 60274.

Created Issue: Windows 7 support for BluetoothWin32Authentication [24969]

alanjmcf — Mon, 19 Oct 2009 17:42:08 GMT