I'm developing a basic program for multicasting frames on a wireless network to determined stations, based on some rules. I use lorcon to handle the injection part, but I also need to look for which stations are present (both APs and clients).
I've googled a lot about how to do this, and I found that iwlib.h and linux/wireless.h can do the trick, but I wasn't able to see any clear example of how to use that libs out there.
Which of them is better for my purpose? Or are the same thing?
If you could link/post some examples of scanning it would be awesome ^^
Best Regards
It looks that this is near impossible, so I decided to grab wireless packets with libpcap (pcap/pcap.h), and build a list based on its headers (src, dst, bssid).
This helped me a bit with the developing: http://www.tcpdump.org/pcap.html
Related
I have an obsolete hardware level/pressure transmitter that communicate with mcu using custom protocol (it appear to be similar to modbus RTU), that hardware comes along with an old commissioning software that works perfectly fine under latest windows, that software contain all communication protocol components that I try to extract and use in something like Arduino to pull data out of transmitter, anyone can help out?
Update - Didn't mentioned above that form of communication here is half-duplex serial communication where master hardware/software query slave transmitter.
Now mentioned to program Arduino mcu to pool data out of transmitter.
What best way of getting readable data out of it?
Again many thanks for all your comments and help!
What you need is called a sniffer. Use that as a keyword and you should be able to find plenty of info here at SO and around the web.
To set the record straight it is actually possible to use Wireshark to sniff on Modbus RTU over serial, see my answer here. If your protocol is similar to Modbus I would start with SerialPCAP.
If you prefer more Windows-friendly solutions you can check these out: 1, 2.
Since Modbus is pretty simple I would say reverse engineering a similar protocol should be, maybe not a piece of cake but just manageable, even if you are not very experienced.
These days when almost everyone is a maker or at least a wannabe, you might want to first take a good look around, maybe somebody else already reverse-engineered that protocol and published it somewhere.
The best tool to analyze a protocol is Wireshark. Run it on the communication link between the Windows machine and the radar. First possibility: the protocol is actually something that Wireshark knows (some trials and errors with the "Decode as" menu may be necessary.) Second possibility, less funny: the protocol is indeed completely proprietary and unknown to Wireshark. At least, Wireshark will make it easier to examine the binary data.
I am trying to get a CC2650 module to talk to an XBee S2c RF board. I have updated the XBee with the 802.15.4 driver. On the CC2650 end, I am using Contiki. Even as I was considering implementing the Rime stack, I am suspecting if the idea would even take off because XBee may not understand Rime. After all, the CC2650 is bei9ng flashed with a Contiki-based code, while XBee has its own internal firmware, which may not have been programmed to respond. Can somebody please correct me if I am wrong?
Also, kindly help me with answers to the Q's below:
Does the XBee use the Proprietary 802.15.4 protocol, which the CC2650RF layer is set to by Contiki?
I was looking at Contiki so that I need not have to change my code much if I migrated to another MuC. Contiki'platform layers take care of converting the common Contiki mechanisms to the underlying API. Is this assumption about Contiki being a generic layer correct?
Is there any communication method (runicast,broadcast et al supported by Contiki out of the box), to directly talk to the XBee?
Is there a single place where all protocolsof Contiki have been clearly explained? Iam having a hard timegoing thru the code alone and trying to make out the exact nature of each of these methods. I already went thru the Contiki wiki and a couple of other resources
Please help.
Can somebody kindly also tag this question with CC2650. It appears I am under-qualified to do that.
Thank you in advance,
Rahul
Ok. I should have done this before I posted the question. The answers lay in slightly more experimentation that I did after stumbling across this link:
http://knowledge.digi.com/articles/Knowledge_Base_Article/XBee-802-15-4-Addressing
Answer to Q1: Yes. It appears they both are talking of the same protocol
Answer to Q2: Yet to prove myself right. Opinions on this one are welcome.
Answer to Q3: This is slightly long.
Adam Dunkel's research paper on the Rime protocol presents the RIme as a way to minimize Code. Not as a new way of fiddling with the PHY or MAC layers of the 802.15.4. Therefore, my fears that the Rime protocol changes the way messages are transmitted is misplaced. Now for the actual paper, it can be easily found with some googling. But here is the easier click. So regardless of what part of the stack is used, an XBee would be able to receive it as long as it is configured following the first of the above two links.
Q4: The Adam Dunkels' Rime link is the one I was referring to in my initial question. It possibly takes some very detailed code inspection to interpret the Figure 1 of the RIme paper itself.
I want to get in the middle of packet forwarding (Not routing). For example, the system is a layer 2 bridge between hosts and their gateway. I want to check the layer 7 for string or whatever "foo" and forward/drop/delay the packet based on the result. What I am having trouble with is intercepting the packet.
What I have read so far:
I know I can get the copy of packet from BPF device (Usenix paper by Steven McCanne and Van Jacobson http://www.tcpdump.org/papers/bpf-usenix93.pdf ). that's good for sniffing but not for me.
I can access the PF device and set the filtering rules which is good for forwarding or dropping decisions, but not for inspection. man pf (4)
I can get packets into the ALTQ queues, BUT I do not know how to access the individual packets located in the queue. man altq(9)
I have also looking into the source code for PF(/usr/src/sys/contrib/pf/net ), PFCTL (/usr/src/contrib/pf/pfctl) and ALTQ(/usr/src/sys/contrib/altq/altq).
On FreeBSD 9.1 machine
I am not C expert, but I am good with it.
Maybe I am getting tired today with all the reading and missed something trivial. Please forgive me if so. Plus, this will be a very good find fro those looking into the subject.
P.S. There is a way of controlling the flow of "foo", by detecting "foo" in packet and denying the answer to that from coming back by setting up the filter for answer to that request. This is NOT what I am trying to achieve. I do not want the packet to leave the system if it should not.
EDIT 2 P.S. There is a great way of doing this on Linux. I can achieve everything I mentioned here on Linux with libnetfilter_queue. I will not bother posting solution here because there are many many many tutorials on how to do it on Linux.
In conclusion, I am still looking for answer on how to do this on BSD. As far as I can understand, I need to write a wrapper/library based on pf (because there is no such thing on the net - otherwise I should have found it already), that does the same thing as libnetfilter with it's libnetfilter_queue library. Or I could somehow dig into libnetfilter and port it to FreeBSD, but since it is based on iptables, only thing I can get from digging into libnetfilter library is logic and algorithms not the actual code itself, which by itself could prove to be of no use to me.
FreeBSD 9.1 has an userspace framework for packet access called netmap. It was recently introduced and has an amazing performance scale. It does very simple but powerful thing - just mmaps the NIC buffers to userspace portion of memory and detaches the packet processing from host stack, this was exactly what I needed the rest is on me.
If anyone needs any goods reference for this, please refer to man netmap (4)
Have a look at OpenDPI or nDPI.
Check out the "Divert Sockets" in BSD implementation as well. Unlike Netmap, it is not zero-copy (IMHO) however it can work with ipfw in order to implement the necessary filters in order to filter packages you want to process.
TL;DR available at the bottom
I've been trying to figure out a way to get two laptops (both running Ubuntu) to be able to pass basic messages back and forth without the need for them to be connected via a wireless network,either by an AP or ad-hoc. I want to reiterate here that ad-hoc networking is not what I'm looking for, I've seen many similar questions here with that as the answer.
I guess what I'm asking is: how do I achieve this? All I really need is for one computer to be able to send a packet, and then for another to pick it up via a packet sniffer of some kind.
Currently: I have both laptops in monitor mode (via a mon0 interface created from aircrack-ng's airmon-ng)so that they can sniff nearby traffic (with Wireshark, tcpdump,tcpcump.org's sample libpcap code, and opening a raw socket and just printing out all the packets. I tried each just because I thought one could be doing something differently/leaving something out). I also have a very basic program that consists of opening a raw socket to send crafted ethernet frames out to the air, but I can't get my two machines to see the other's packets. The sniffer running on each machine can only see the packets going out of that machine (in addition to nearby beacons/control traffic from wifi in the area).
Some things to note that might be important are:
-the packets I'm sending out appear in Wireshark (only on the sending machine) as malformed 802.11 packets (probably because I'm just filling them with junk data for now). I was under the impression that my other laptop would also see them as malformed packets, but it gets nothing
-the sockets I'm using are from a call to socket(PF_PACKET,SOCK_RAW,ETH_P_ALL). Raw sockets are something I just recently was aware of, so I could be misunderstanding how they work, but my impression is that I can craft a layer 2 packet by hand and ship out straight out to the wire/air.
If you're curious as to why I want to do something like this, it's part curiosity, part research for a project I'm working on. I want to streamline / automate the process of setting up an ad-hoc network, and what I'm trying to do here is for the laptops to do a small exchange to figure out the specifics of the adhoc network they are about to create and then make/join that network automatically, instead of either one person explicitly setting up the network OR having both people pre-decide the name, etc of the network and have both computers constantly trying to connect to that specific one.
I'm more interested if I'm going about this process in the right way rather than if my code works or not, if someone thinks me posting my (very basic, taken from another post on Stack Overflow) raw socket code will help, I can.
Edit: I am more than happy to post a complete set of code with instructions if I can get this working. I couldn't find much helpful info on this topic on the internet, and I'd love to put it up for future people trying to do the same thing.
TL;DR I want to send out a packet from one laptop and pick it up on another via a packent sniffer of some sort. No wifi network or ad-hoc network involved. Something akin to spoofing an AP's beacon frame (or similar) for the purpose of sending small amounts of data.
Edit 2:After some thought, perhaps what I'm looking for is some kind of raw 802.11 use? Having direct control of the wifi radio? Is such a thing possible?
I found out I was able to send packets out through my monitor mode interface as long as I had correct 802.11 with radiotap headers. I think the problem I was originally experiencing (not being able to sniff the packets) was because they were malformed and thus not actually getting sent out.
I was able to accomplish this by adapting the example code found here, courtesy of someone named Evan Jones, except I did not need to use an Atheros based card or Madwifi drivers, everything worked fine with the mon0 interface created with aircrack-ng.
I am certain that Apple Mac do this. Apple call it 'bonjour'. There may well be a proper IETF spec for it. This is an Article on Bonjour this is Wikipedia on an open component of bonjour which might help get you moving.
I am currently working on a wireless solution for my Arduino and computer. I am trying to connect a transmitter to my computer and a receiver to my Arduino. I have seen a lot of examples with Arduino to Arduino communication but none for computer to Arduino. What would I need to interface the transmitter with my computer, PIC?
Any insight or any links it would be greatly appreciated.
The jeenode is a good low-cost solution. It really depends on your needs, though.
Sparkfun has a Wireless Buyers guide. It's a couple of years old though. There's also this blog post, which seems to be a pretty comprehensive survey of the available options. It certainly listed every option I've ever heard of and several I'd never heard of before.
This Freakduino board looks interesting. It's an Arduino clone with a built in IEEE 802.15.4 radio (the same radio in the Xbee's). It's also priced very nicely. I wish I'd known about it before I ordered my Arduino Uno earlier this week!
You can use XBee from SparkFun.com. I think they sell a kit for $70 or so. I think they also have wifi solutions too.
Or you could easily connect the two using a Bluetooth module.
Sparkfun has a really good selection and tutorials on how to achieve what you want.
Worth a look in my opinion.
http://www.sparkfun.com/categories/115
There is another interesting low power RF protocol called Ant+. You can find more information at http://thisisant.com.