Sorry if I confused you, It is not a fakelb problem I get the same
problem if I run using real 802.15.4 hardware (mrf24j40). The packet is
put out by the driver but also sent to the RAW socket.
Simon
On 18/09/14 09:33, Alexander Aring wrote:
On Thu, Sep 18, 2014 at 08:46:55AM +0100, Simon Vincent wrote:
I think what is happening is similar to your theory. The packets are getting sent to the 802.15.4 driver and the compress header function but as we have the raw socket recvmsg the packet is also sent internally to this socket.
This is because a raw socket receives all messages that are sent and received.
It does appear to be a complex problem. I just need to prove that this is what is happening by inserting more debug.
mh, ok. Good to know that there is maybe such issue with the fakelb
driver and 6LoWPAN. Maybe there exists some netdev flag setting or
something else to avoid this.
You could describe this problem at netdev@xxxxxxxxxxxxxxx and maybe the
guys knows a solution.
At the moment we use's some callbacks for replacing IPv6 with 6LoWPAN
header which was not made to make this there. This seems to be a global
architecture problem of the 6LoWPAN stack.
Or we need a another fakelb driver solution, I remember the tun/tap
interfaces which allow to send/recv packets from/to userspace. They need
to have similar issues when they have two interfaces and link-local
addresses. I don't know how they deal with that. This idea is just a shoot
into the dark. ;-)
- Alex
--
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
