* Raw ieee802154 socket
@ 2015-04-08 8:54 Matteo Petracca
2015-04-08 10:30 ` Alexander Aring
0 siblings, 1 reply; 3+ messages in thread
From: Matteo Petracca @ 2015-04-08 8:54 UTC (permalink / raw)
To: linux-wpan
Dear all,
I want to create a raw ieee802154 socket, and I'm
following the test1.c example of lowpan-tools.
I succeeded in sending data packets, when I put in the buffer
a packet (header+payload) it is sent trough the channel as it
is (I checked with the sniffer). When I receive a data packet
I get in the buffer only the payload, without the header. Is there
any way to get back the header too?
I am using kernel 3.8.
Best,
Matteo
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Raw ieee802154 socket
2015-04-08 8:54 Raw ieee802154 socket Matteo Petracca
@ 2015-04-08 10:30 ` Alexander Aring
2015-04-08 10:46 ` Alexander Aring
0 siblings, 1 reply; 3+ messages in thread
From: Alexander Aring @ 2015-04-08 10:30 UTC (permalink / raw)
To: Matteo Petracca; +Cc: linux-wpan
Hi,
On Wed, Apr 08, 2015 at 10:54:00AM +0200, Matteo Petracca wrote:
> Dear all,
> I want to create a raw ieee802154 socket, and I'm
> following the test1.c example of lowpan-tools.
>
I need to admit, I never used the socket functionality extremely and I
can't guarantee that this is fully working.
This should be a new entry on the "Open Task" list...
> I succeeded in sending data packets, when I put in the buffer
> a packet (header+payload) it is sent trough the channel as it
> is (I checked with the sniffer). When I receive a data packet
> I get in the buffer only the payload, without the header. Is there
> any way to get back the header too?
>
1.
yea, I know why this happens (maybe)... because the frame is parsed into the
"not fully supported parsing mechanism" which drops frames which we
don't currently supported like cmd, beacons, etc. See [1], this is the
reason why you receive dataframes only. Solution would be to insert
stuff to parse other frameformats, but I planed a rework of the full
parsing frame stuff.
2.
The reason why you don't see the mac header is maybe because that [2]
will skip the header. On a raw socket this should be recovered by a
skb_push at [3] after share check, then we are sure that the skb is
not shared anymore.
A shoot into the dark would be:
diff --git a/net/ieee802154/socket.c b/net/ieee802154/socket.c
index b60c65f..c1c0681 100644
--- a/net/ieee802154/socket.c
+++ b/net/ieee802154/socket.c
@@ -365,6 +365,8 @@ static int raw_rcv_skb(struct sock *sk, struct sk_buff *skb)
if (!skb)
return NET_RX_DROP;
+ skb_push(skb, skb->mac_len);
+
if (sock_queue_rcv_skb(sk, skb) < 0) {
kfree_skb(skb);
return NET_RX_DROP;
and hopefully that doesn't occur other sideeffects for later parsing mechanism
and the "start" buffer was not overwritten before.
If you test it then please let us know if it's working or not. For my
knowledge is that we want also raw frames on receiving and I would
accept patches for this.
Another question would be "What exactly do you want to do". With the
above situation you see frames which belongs to your node only (matching
address, etc.). Or if you want to have "everything" raw inside
userspace also frames which doesn't belong to your node, but this would
be more complicated, then it's some kind of monitor interface in
promiscous mode which allow transmit handling. Some transceiver
disable AACK handling in promiscous mode so monitor interface with send
functionality would be never supported. :-(
> I am using kernel 3.8.
>
Such an old kernel? There are some fixed bugs, it's recommended to use
bluetooth-next with wpan-tools, see [0]. I also believe that the upper
diff doesn't apply anymore on this release. :-)
- Alex
[0] http://wpan.cakelab.org/
[1] http://git.kernel.org/cgit/linux/kernel/git/bluetooth/bluetooth-next.git/tree/net/mac802154/rx.c#n104
[2] http://git.kernel.org/cgit/linux/kernel/git/bluetooth/bluetooth-next.git/tree/net/ieee802154/header_ops.c#n266
[3] http://git.kernel.org/cgit/linux/kernel/git/bluetooth/bluetooth-next.git/tree/net/ieee802154/socket.c#n362
^ permalink raw reply related [flat|nested] 3+ messages in thread
* Re: Raw ieee802154 socket
2015-04-08 10:30 ` Alexander Aring
@ 2015-04-08 10:46 ` Alexander Aring
0 siblings, 0 replies; 3+ messages in thread
From: Alexander Aring @ 2015-04-08 10:46 UTC (permalink / raw)
To: Matteo Petracca; +Cc: linux-wpan
On Wed, Apr 08, 2015 at 12:30:17PM +0200, Alexander Aring wrote:
...
> 2.
> The reason why you don't see the mac header is maybe because that [2]
> will skip the header. On a raw socket this should be recovered by a
> skb_push at [3] after share check, then we are sure that the skb is
> not shared anymore.
doh! The argument is wrong here, because skb_push doesn't manipulate the
buffer. :-) I just want to clarify this, you can still to that in this
place after the share_check.
- Alex
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2015-04-08 10:46 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-04-08 8:54 Raw ieee802154 socket Matteo Petracca
2015-04-08 10:30 ` Alexander Aring
2015-04-08 10:46 ` Alexander Aring
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.