All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alexander Aring <alex.aring@gmail.com>
To: Simon Vincent <simon.vincent@xsilon.com>
Cc: linux-wpan@vger.kernel.org, werner@almesberger.net
Subject: Re: 6lowpan raw socket problems
Date: Thu, 18 Sep 2014 18:30:10 +0200	[thread overview]
Message-ID: <20140918163008.GC9262@omega> (raw)
In-Reply-To: <541B004D.1020609@xsilon.com>

On Thu, Sep 18, 2014 at 04:54:53PM +0100, Simon Vincent wrote:
> It looks like in 6lowpan_iphc.c lowpan_header_compress the original ipv6
> header is removed and the compressed header is attached.
> 
> These four lines are responsible.
>     skb_pull(skb, sizeof(struct ipv6hdr));
>     skb_reset_transport_header(skb);
>     memcpy(skb_push(skb, hc06_ptr - head), head, hc06_ptr - head);
>     skb_reset_network_header(skb);
> 
> I don't think we can do this as the skb is being used in other parts of the
> ip stack. Hence when the ipv6 header is read elsewhere the addresses become
> corrupt as they have been overwritten by the 6lowpan compressed header.
> 
> Any ideas on how to fix this?
> 
yes, but I don't believe that this makes trouble. <--- or only makes
trouble by replacing data, see below.

It's called by a callback of header_ops [0].

This is for generating the mac header with address information from
neighbor discovery cache (mainly destination address) and source
addresse (mainly netdev->dev_addr).

Another example of this function is ethernet. [1]

On [1] you will se that the ethernet header will created there.

- Get data from skb for ethhdr (ethernet header)
  struct ethhdr *eth = (struct ethhdr *)skb_push(skb, ETH_HLEN);

- memcpy(eth->h_source, saddr, ETH_ALEN); <-- source address

- memcpy(eth->h_dest, daddr, ETH_ALEN); <-- destination address.


So they using the callback there to manipulate the skb here.

Another idea is that, maybe we can ADD data but not REPLACING existing
data with that. I don't know right now.


But I moved this handling out of the create callback of header_ops. This
also fix the issue by running wireshark&co on a lowpan interface.

What I did is only to save the address information in the reserved room
of skb in this callback. [2]

Then running replacing header in the xmit callback of lowpan device. It
looks very different now! I have also splitted the lowpan implementation
in three files "main.c, tx.c, rx.c". Please note that. This code is part
of the rework and I want to fix the wireshark&co issue there.

I don't have a solution for this right now which applies on current
mainline, sorry! But the xmit callback is 100% secure by replacing skb
header data.

If you like you can try to apply it on mainline. What I said is that
this also fix the IPv6 capturing on a lowpan interface. I want also say
to you that I added a comment there "TODO ask david or marc if this run
into trouble", because I am not sure if the reserved skb room can be
overwritten sometimes, then we stuck into the same issue. (Worked on my
side currently), but I also don't do much raw socket RPL messages. ;-)

What I know is that we can't use skb->cb here to save the information,
this would be overwritten by traffic control.

- Alex

[0] http://lxr.free-electrons.com/source/include/linux/netdevice.h#L255
[1] http://lxr.free-electrons.com/source/net/ethernet/eth.c#L78
[2] https://github.com/linux-wpan/linux-wpan-next/blob/7ccf5a24a19a72b857bbcbc76342f4838dd85d6b/net/ieee802154/6lowpan/tx.c#L59
[3] https://github.com/linux-wpan/linux-wpan-next/blob/7ccf5a24a19a72b857bbcbc76342f4838dd85d6b/net/ieee802154/6lowpan/tx.c#L261

  reply	other threads:[~2014-09-18 16:30 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-18  7:46 6lowpan raw socket problems Simon Vincent
2014-09-18  8:33 ` Alexander Aring
2014-09-18  8:37   ` Simon Vincent
2014-09-18  8:45     ` Alexander Aring
2014-09-18  8:54       ` Alexander Aring
2014-09-18  9:03         ` Simon Vincent
2014-09-18  9:44           ` Alexander Aring
2014-09-18  9:45             ` Alexander Aring
2014-09-18 14:02               ` Simon Vincent
2014-09-18 14:19                 ` Alexander Aring
2014-09-18 15:54                   ` Simon Vincent
2014-09-18 16:30                     ` Alexander Aring [this message]
2014-09-18 16:37                       ` Alexander Aring
2014-09-18 17:03                       ` Simon Vincent
2014-09-18 17:09                         ` Alexander Aring
2014-09-19  8:27                           ` Simon Vincent
2014-09-19  9:33                             ` Alexander Aring
2014-09-19  9:57                               ` Simon Vincent
2014-09-19 10:15                                 ` Alexander Aring
2014-09-19 10:39                                   ` Alexander Aring
2014-09-19 11:08                   ` Alexander Aring
2014-09-19 11:27                     ` Simon Vincent
2014-09-19 11:45                       ` Alexander Aring
2014-09-19 11:50                         ` Alexander Aring
2014-09-19 11:59                           ` Alexander Aring
2014-09-19 12:00                         ` Simon Vincent
2014-09-19 12:06                           ` Alexander Aring
2014-09-19 12:38                             ` Alexander Aring
2014-09-19 12:44                               ` Simon Vincent
2014-09-19 12:55                                 ` Alexander Aring
2014-09-19 12:57                                   ` Alexander Aring
2014-09-19 14:14                                     ` Simon Vincent
2014-09-19 14:21                                       ` Alexander Aring
2014-09-19 14:22                                         ` Alexander Aring
     [not found] <5419ABD6.70607@xsilon.com>
2014-09-17 15:43 ` Simon Vincent
     [not found] <1409567774.3120.57.camel@jrissane-mobl.ger.corp.intel.com>
2014-09-01 11:38 ` 6lowpan status Alexander Aring
2014-09-02  6:08   ` Jukka Rissanen
2014-09-02  7:12     ` Alexander Aring
2014-09-02  7:26       ` Alexander Aring
2014-09-02 14:21         ` 6lowpan raw socket problems Simon Vincent
2014-09-02 14:43           ` Alexander Aring
2014-09-02 14:51             ` Simon Vincent
2014-09-02 15:18               ` Alexander Aring
2014-09-02 15:37               ` Alexander Aring
2014-09-02 16:06                 ` Simon Vincent
2014-09-02 16:26                   ` Alexander Aring
2014-09-02 18:53                     ` Martin Townsend
2014-09-08 10:43                       ` Alexander Aring
2014-09-17 13:30                         ` Simon Vincent
2014-09-17 13:57                           ` Alexander Aring
     [not found]                             ` <5419A9DD.5070804@xsilon.com>
2014-09-17 16:03                               ` Alexander Aring
2014-09-17 16:17                                 ` Alexander Aring
2014-09-18  7:55                                   ` Simon Vincent

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=20140918163008.GC9262@omega \
    --to=alex.aring@gmail.com \
    --cc=linux-wpan@vger.kernel.org \
    --cc=simon.vincent@xsilon.com \
    --cc=werner@almesberger.net \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.