From: Alexander Aring <alex.aring@gmail.com>
To: Jukka Rissanen <jukka.rissanen@linux.intel.com>
Cc: Simon Vincent <simon.vincent@xsilon.com>,
linux-wpan@vger.kernel.org, varkabhadram@gmail.com,
marcel@holtmann.org
Subject: Re: [PATCH linux-wpan 0/3] Fix handling of skbs of type PACKET_OTHERHOST
Date: Thu, 2 Oct 2014 12:22:02 +0200 [thread overview]
Message-ID: <20141002102200.GA19732@omega> (raw)
In-Reply-To: <1412244764.13121.19.camel@jrissane-mobl.ger.corp.intel.com>
Hi Jukka,
On Thu, Oct 02, 2014 at 01:12:44PM +0300, Jukka Rissanen wrote:
> 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).
>
Okay, then maybe bluetooth 6lowpan need to set it to PACKET_HOST always.
Another idea would be:
We could also set PACKET_BROADCAST if the IPv6 address is a
multicast/broadcast addresss.
But it looks wrong, the PACKET_FOO values should be set by mac layer only.
What I deteced is at [0]. There it checks if the "mac frame" was
broadcast or multicast. I don't know when this occurs, I need to check
this but it seems to be broken, when we always set the PACKET_HOST.
Simon had issues with routing when IPv6 Layer gets a skb with PACKET_HOST and
it was PACKET_OTHERHOSTS before.
Simon:
Maybe only send patch:
[PATCH linux-wpan 3/3] ieee802154: 6lowpan: Drop PACKET_OTHERHOST skbs in 6lowpan
this should fix your routing problems, but issue with [0] still exists.
- Alex
[0] http://lxr.free-electrons.com/source/net/ipv6/mcast.c#L1413
next prev parent reply other threads:[~2014-10-02 10:22 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-02 8:56 [PATCH linux-wpan 0/3] Fix handling of skbs of type PACKET_OTHERHOST Simon Vincent
2014-10-02 8:56 ` [PATCH linux-wpan 1/3] 6lowpan: Ensure pkt_type is not lost Simon Vincent
2014-10-02 9:16 ` Alexander Aring
2014-10-02 8:56 ` [PATCH linux-wpan 2/3] ieee802154: " Simon Vincent
2014-10-02 8:56 ` [PATCH linux-wpan 3/3] ieee802154: 6lowpan: Drop PACKET_OTHERHOST skbs in 6lowpan Simon Vincent
2014-10-02 9:29 ` Alexander Aring
2014-10-05 18:17 ` Alexander Aring
2014-10-02 9:15 ` [PATCH linux-wpan 0/3] Fix handling of skbs of type PACKET_OTHERHOST Alexander Aring
2014-10-02 9:28 ` Alexander Aring
2014-10-02 9:36 ` Simon Vincent
2014-10-02 9:43 ` Jukka Rissanen
2014-10-02 9:54 ` Alexander Aring
2014-10-02 9:58 ` Alexander Aring
2014-10-02 10:12 ` Jukka Rissanen
2014-10-02 10:22 ` Alexander Aring [this message]
2014-10-02 10:37 ` Alexander Aring
2014-10-02 10:39 ` Simon Vincent
2014-10-02 10:43 ` Alexander Aring
2014-10-02 10:51 ` Alexander Aring
2014-10-02 10:58 ` Alexander Aring
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20141002102200.GA19732@omega \
--to=alex.aring@gmail.com \
--cc=jukka.rissanen@linux.intel.com \
--cc=linux-wpan@vger.kernel.org \
--cc=marcel@holtmann.org \
--cc=simon.vincent@xsilon.com \
--cc=varkabhadram@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).