Hi Alex, On to, 2014-10-02 at 11:58 +0200, Alexander Aring wrote: > On Thu, Oct 02, 2014 at 11:54:30AM +0200, Alexander Aring wrote: > > Jukka, > > > > On Thu, Oct 02, 2014 at 12:43:05PM +0300, Jukka Rissanen wrote: > > > Hi Simon, > > > > > > On to, 2014-10-02 at 10:36 +0100, Simon Vincent wrote: > > > > I will add this patch when I rebase on bluetooth-next. > > > > > > and thanks for doing that. > > > > > > > I see now, that the bluetooth layer never sets this value. I don't know > > how bluetooth deal with that. But you need to set PACKET_HOST if packet > > belongs to you, OTHERHOST if packets belongs not to you, or > > PACKET_BROADCAST if packet belongs to you, but is a broadcast. > > > > Also for PACKET_MULTICAST, if bluetooth support MULTICAST frames. > > > > > > I think you need handling for this in bluetooth 6lowpan layer. > > > > and this should be fixed before Simon's patches. I add Marcel here in > cc, maybe he can bring some new information if bluetooth ever set's the > pkt_type in sk_buff. > > Point is IPv6 needs this information and we should set it to a valid value. > ... and this is not always set PACKET_HOST, IPv6 also check on PACKET_BROADCAST. Hmm, bluetooth 6lowpan is a bit different from ieee802154 as the bluetooth link is a point-to-point one and typically only uses link local addresses so normally every packet is really meant for that host. I will investigate this a bit more, so perhaps it is best if Simon does not change the pkt_type field after all. Everything seems to work just fine with unicast and multicast packets at the moment (when pkt_type == PACKET_HOST). Cheers, Jukka -- To unsubscribe from this list: send the line "unsubscribe linux-wpan" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
