On Mon, Jul 27, 2015 at 07:43:13PM +0200, Baptiste Clenet wrote: > 2015-07-27 19:28 GMT+02:00 Alexander Aring <alex.aring@xxxxxxxxx>: > > On Mon, Jul 27, 2015 at 05:55:27PM +0200, Baptiste Clenet wrote: > >> 2015-07-27 17:13 GMT+02:00 Baptiste Clenet <bapclenet@xxxxxxxxx>: > >> >>> Then forget that and make some at86rf230 driver debug messages. See > >> >>> "print_hex_dump" [0]. Add this add skb->data in at86rf230_xmit and > >> >>> at86rf230_rx_read_frame_complete (but after the skb is filled with data, > >> >>> otherwise it makes no sense). > >> >>> > >> >>> This will allow us to see what's the lowest layer is. If the transmit > >> >>> side looks correct, but receive side looks weird then I suppose > >> >>> something is wrong again with your spi setup. > >> >>> > >> >>> The reason is that we get the lowest dump of the transmitted and > >> >>> received buffer and nobody touched that buffer then. > >> > > >> > I dump the packet in at86rf230_xmit and > >> > at86rf230_rx_read_frame_complete (just before > >> > ieee802154_rx_irqsafe(lp->hw, skb, lqi)). This is wireshark analyse of > >> > the two packets. The first one is correct and comes from the sender, > >> > the second is from the receiver (I manually created the hex dump file) > >> > which is wrong! So something seem to occur when the frame goes to the > >> > transceiver. > > > > ah, sorry I misunderstood you. So you have capture the raw data for > > transmit and receiving and it differs. Then I have still no idea what's > > wrong on your side. :-) > > > > - Alex > > Yes it's what I did :-) > But you gave me an idea by saying that I should send only 0xabcd and > see if I receive the same. Which is the easiest way to send 0xabcd as > a raw value? at86rf230_xmit requires struct ieee802154_hw *hw, struct > sk_buff *skb and at86rf230_xmit_start a void *context. Why don't we > have a simple at86rf230_send_raw_data :-) > Your use case smells like a 802.15.4 raw socket for the raw data from userspace. But I would send only "0xabcd" this is an invalid 802.15.4 frame and will be filtered. Simple use some data like 6LoWPAN maybe your issue occurs on high payload only. This would clarify why your transceiver is right detected and such things (reading/writing registers). - 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
