How to make a node only overhear neighbor's packets and itself doesn't send or forward any packets? - iot

I want to make a node which can overhear neighbor's sending packets and print the information of the packet in Mote output cooja. And I also hope the node doesn't send or forward any packets. What can I do?

Sounds like you want a sniffer. Check out examples/sensniff for an example on how to implement that.
To go into more detail, you most likely need to disable the network layers above radio (use "nullnet") with MAKE_NET=MAKE_NET_NULLNET and implement a custom MAC layer, like the SenSniff example does.

Related

Can I remove a packet payload inside a .p4 program?

I would like to know if it's possible to completely remove a packet payload from a packet inside a .p4 program or at least modify it to random data. The reason behind this is that I'm cloning a packet and sending it to a different host (monitor) and this host does not need the packets payload.
Depends on what are you trying to do. If you would like to remove the some kind of header then it's enough to call
hdr.random_header.setInvalid()
if you call that in Egress it should remove fields of the header from the packet.
If you have len fields in headers you might also use
truncate(new_size)
when you know the size of packet without payload. If you already know easier option please share it here.

Wireshark: Filtering out uninteresting zigbee messages

Are there any Wireshark gurus?
I am debugging an issue on my home Zigbee network. I have a sniffer dongle and I can catch all the packets transmitted. Since my network has ~40 devices, the air is quite cluttered with packets I am not really interested in. I am looking for a ways to filter uninteresting messages
Questions:
Is there a way to filter out messages related to IEEE protocol (various Data Requests, and Acks), while leaving only upper layer messages (Zigbee, Zigbee HA)?
Is there a way to assign human readable labels for the devices on the network? e.g. 'Coordinator' instead of 0x0000, or 'Light Switch' instead of '0xc83a'?
I would propose making your own filters (whoah, relax, we are not animals, we do this the smart way) ... go to Statistics > Protocol Hierarchy, the panel should show you all the traffic by protocols. Then just identify which protocols you do not want to see, mark them (one by one), right-click and Prepare as Filter > ...and not Selected (to prepare a filter to exclude the highlighted protocol). Sadly wireshark does not allow you to select multiple protocols to exclude at once. After this simply save your filter and reuse it as much as you like
What you are trying to do is Name resolution. This is done via configuration files, more specifically ethers and hosts

Capture packet content using network analyzers

I need to capture https traffic. In particular the client hello messages. But I need to analyse their content. I learned about wireshark. How can I to extract the data from the packet content? i.e. the client hellp content? The tool displays the packets. If I click on them, I see more information but how to aggregate them. i.e. I need the field length (as shown in the picture) for all client hello messages?
Are there any tools to do so? Or can Wireshark do this function?
EDIT: In the picture, this is a client hello message. I need some data like the length. How to extract this and aggregate it for large traffic?
Image for illustration
You can do this with wireshark with a filter of "ssl.handshake.type == 1". This will give you all Client Hello packets. From there you can manually inspect the client hello message or you can even make any field in the client hello message a column in Wireshark. To do this, drill-down into one of the packets to the field you want to see. Right-click that field and select "Apply as Column".
If you want to do this programmatically, you could also write a program that uses libpcap to capture packets. This is more work though since you would have to manually dissect the packets yourself.

wireshark decode as ddp

I am using wireshark to look at ddp/rdma packets, which usually works fine.
Sometimes wireshark can't recognize that the next protocol after tcp is ddp/rdma (although I know it is), so I tried using "decode as" but there is no option for ddp/rdma in there.
Is there a way to force wireshark to parse the packet as ddp/rdma?
Thanks!
Is there a way to force wireshark to parse the packet as ddp/rdma?
The dissector for iWARP DDP/RDMA, if that's what you're referring to, is a "heuristic" dissector, which means that 1) it looks at otherwise-undissected TCP packets and tries to guess whether they're packets for it and 2) it doesn't have a "force this" option.
You should submit a bug to the Wireshark Bugzilla saying that Wireshark isn't recognizing the traffic as DDP/RDMA, and attach a sample capture.

regarding streaming, how does a program like skype work?

When programs such as Skype streams video from a user to another and vice versa, how is that usually accomplished?
Does client A stream to a server, and server sends it to client B?
or does it go directly from client A to B?
Feel free to correct me if i am way off and none of those is correct.
Skype is much more complicated than that, because it is Peer to Peer, meaning that your stream may travel through several other skype clients, acting as several servers. Skype does not have a huge central system for this. Skype always keeps track of multiple places that it can deliver your stream to, so that if one of these places disappear (that Skype client disappears), then it will continue sending through another server/skype-client. This is done so efficiently, that you don't notice the interruption.
Basically , this is how its achieved.
1) encode video / audio using the best compression you can get. Go lossy compression and plenty of aliasing to throw away portions of video and audio which is not usable. Like removing background hiss
2) pack video / audio into packets and put a timestamp on them. The packets are usually datagrams.
3) send packets directly to destination. Use the most appropriate route. You dont have to send all packets the same way. Use many routes if possible. P2P networks often use many routes to the same destination
4) re-encode on the destination. If a packet is too old , throw it away. If packets are lost , dont bother about it since its too late.
5) join the video back and fill in the missing frames the best you can.

Resources