On Mon, Jul 27, 2015 at 02:29:09PM +0200, Baptiste Clenet wrote: > 2015-07-27 13:30 GMT+02:00 Alexander Aring <alex.aring@xxxxxxxxx>: > > On Mon, Jul 27, 2015 at 12:52:42PM +0200, Baptiste Clenet wrote: > >> 2015-07-27 12:38 GMT+02:00 Alexander Aring <alex.aring@xxxxxxxxx>: > >> > On Mon, Jul 27, 2015 at 12:31:28PM +0200, Baptiste Clenet wrote: > >> >> 2015-07-27 12:21 GMT+02:00 Alexander Aring <alex.aring@xxxxxxxxx>: > >> >> > On Mon, Jul 27, 2015 at 12:08:18PM +0200, Baptiste Clenet wrote: > >> >> > ... > >> >> >> > >> >> >> Receiving side: > >> >> >> [ 176.921637] CID flag is set, increase header with one > >> >> >> [ 176.931640] NH flag is set, next header carried inline: 02 > >> >> >> [ 176.942502] SAC bit is set. Handle context based source address. > >> >> >> [ 176.954397] > >> >> >> [ 176.957352] ieee802154 phy0 wpan0: SAM value 0x3 not supported > >> >> >> > >> >> > > >> >> > Yes this is not what it was transmitted before from the other node. > >> >> > That's why I would ask for some sniffing device, somewhere in the lower > >> >> > layers mac or phy it will fill your frame with garbage. > >> >> > > >> >> > I can't tell you now if it's the transmitted node or the receiving node. > >> >> > You need to debug it there. > >> >> Yeah, I agree. > >> >> > >> >> > > >> >> > To ensure the transmitted node don't send garbage I would like to check > >> >> > it with some sniffer device. If you see garbage on the sniffer device > >> >> > then it's something wrong with the transmitting. > >> >> Ok, but I did sniffing with monitor0 on the receiver as I mentioned earlier. > >> >> How may I sniff a packet ont the sender? Because I can't set up > >> >> lowpan0 on top of monitor0. > >> >> How may I sniff on lower layers? > >> >> > >> > > >> > In short: > >> > > >> > Monitor is just for sniffing, we don't parse any payload data on it. You > >> > can't create a lowpan interface on it, please use the L2 interface > >> > (wpan0). See [0], you maybe need a third node which running as monitor. > >> > >> I don't think I've got it, you want me to set up a network of 3 nodes with: > >> 1 2 3 > >> sender receiver receiver > >> wpan0 wpan0 monitor0 > >> > >> But I will see exactly the same things as earlier. > > > > You can save the dump (e.g. tshark I think with -w $FILE) somewhere or > > doing pipe via ssh, refer [0]. > OpenWRT doesn't provide tshark. > I could use tcpdump instead but there is something I still don't get, > sorry. How can I sniff a packet I send? (Sniffing on the sender). If I > well-understand, to sniff I need to use monitor0 interface but when I > use it I can't use lowpan0 so I can't send ICMP packet and I can't > sniff. > This is correct. The transceiver goes into promiscuous mode and in short: you cannot operate as node in the same time then. 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 don't know what "But I will see exactly the same things as earlier" > it means that the receiver will receive the same things as earlier and > I have already given to you the details about the message that > Wireshark gave me (which comes from the receiver). Now with these sentence it looks like what I said above. The transmit buffer looks correct, but the receive buffer looks completely different. You cannot debug in upper layers and then say "It's the same whats was on the air". Please confirm this by debugging the driver layer and dumping the frame buffer on receiving and transmitting, which is the lowest layer which we can debug. (Maybe we should add some debug switch for that in at86rf230 driver). If transmit looks correct and the receiving buffer looks completely different than what was transmitted before. Then this is not an issue with mac802154/6LoWPAN stack. Something is broken then with spi/cable connectors/whatever I don't know. - Alex [0] http://lxr.free-electrons.com/source/include/linux/printk.h#L429 -- 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
