Hi John,

> The problem is that after successful connection between the Windows
> Bluetooth stack and the Linux Bluez stack, no packets from the device
> ever reach the PC running Windows XP Service Pack 2.  That is, a ping
> from the PC never receives a response, and a ping from BlueZ never
> reaches the PC (as shown by the PC packet statistics.)  Linux packet
> statistics (ifconfig) show that PC packets are received, but all return
> traffic seems to be routed over the lo interface.
> 
> Immediately after creating the BNEP connection with Bluez, the Windows
> Bluetooth stack sends a BNEP_FILTER_NET_TYPE_SET_MSG with an effective
> length of zero.  Bluez interprets this message (in
> bluetooth/bnep/core.c) to mean that no filter ranges should be allowed.
> Specifically, the code in bnep_ctrl_set_netfilter zeros the first entry
> in the filter list, which is interpreted by bnep_net_proto_filter in
> netdev.c as meaning that no ranges of acceptable packets are available.
> This interpretation leads to all packets being rejected by BNEP.
> 
> The Bluetooth BNEP specification clearly states the following:
> 
> The length (in octets) of this message is 4+4*N, where N is the number
> of disjoint ranges of Networking protocol types that form the complete
> set. Note that N=0 (empty set) denotes a reset to default filters (if
> any) supported by the remote device. 
> 
> Instead of resetting to default filters, Bluez eliminates all filters,
> disallowing all traffic.
> 
> Since the proper solution involves reorganizing the default filter
> initialization code, I am leaving to more capable hands the actual code
> changes to make the code operate according to the specification.
> 
> I supply the following one line hack for those interested in running
> with the Windows Bluetooth stack until the proper fix is available.
> Change the line in bnep_ctrl_set_netfilter from
> 
>             if (i < BNEP_MAX_PROTO_FILTERS)
> 
> to
> 
>             if (i > 0 && i < BNEP_MAX_PROTO_FILTERS)
> 
> 
> This works as long as explicit filters have not previously overridden
> the defaults.

why do you need a workaround like this ;)

The proper fix is not really hard, because we already set the default
filters at device creation and we only have to redo this here if N=0. A
patch for that is attached. Please report back if this work for you.

Regards

Marcel