I would like to know how to capture packets of a specific wireless network using wireshark.
I'm already able to capture all packets of different networks setting my wireless card in monitor mode but for a specific analysis i need to discard all the packets not related to my network during the capture procedure.
I know that exists display filters to do that but i need to filter them ahead (like with capture filters).
If i go to CAPTURE->OPTIONS i can set capture filters but i don't know the exact filter because they are different from display filter infact wlan.bssid==xx:xx:xx:xx:xx:xx
does not work.
any suggestions?
thanks
You could use an index from the start of the wlan packet.
It needs some coaxing, but the BSSID field is in a fixed, predictable position. By using brackets, you should be able to reference the proper positions in the packet.
The BSSID is at position 16, so if you wanted to emulate something like:
wlan.bssid=12:34:56:78:9a:bc
you would have to do something like this:
wlan[16:4] == 0x12345678 and wlan[20:2] == 0x9abc
You have to convert the first 4 octets into a int32 and the last 2 into an int16 and use 2 clauses, as BPF cannot express a 6 byte number, but I've used it and it works fine. This can also be adapted to other uses as well (you just need the offset).
Excellent question and something I've been trying to figure out also.
The short answer is the wireshark tools cannot filter on BSSID. Wireshark uses pcap, which uses the kernel Linux Socker Filter (based on BPF) via the SO_ATTACH_FILTER ioctl. There is no BPF filter for BSSID.
Another tool, airodump-ng, CAN capture by BSSID because it passes all 802.11 frames into user space and decodes/filters frames there. It works surprisingly well considering all the user-space processing.
But even a low-volume 80211 network is fairly noisy. For example, my SOHO captures 11K frames in under two minutes; and I still drop frames. Grabbing all the 80211 frames for the five visible (but small!) BSSIDs near me and I receive 141K frames (104MB) in just under three minutes.
I'm looking to do an embedded frame sniffer/injector using EMMC or SD flash so I need to be careful about pushing the limits.
So I'm trying to write a custom BDF filter to filter only the local BSSID frames. And I hope to extend it to drop a good amount of the "noisy" frames - most of the control and management frames can be filtered.
The BSSID address location in the frame is based on ToDS and FromDS control bits.
Anyway, hope I provided some breadcrumbs to the solution. It may just be an airodump user-space solution is the easiest.
Related
When a computer X sends data through a network to computer Y the data goes down through the OSI layer. This is ok. I understand. But once the data is put on the media as eletric signals then how does the computer Y know what to reassmble, given the headers and trailers of the data model generated in OSI, once it is put on the electric media at layer 1 does not exist any more?
The physical layer is just 1's and 0's as you say - the trick is that there is a pattern that tells the receiver that this is the start of a packet. This is usual referred to as 'Framing'.
Once the receiver knows that, it simply reads in as many bits as its needs for the Layer 2 header and it then has that and so on.
The headers are clear in a typical OSI or networking diagrams, e.g. (https://www.ciscopress.com/articles/article.asp?p=2738463):
So the way the first two layers work on the receiver is:
layer 1 just recognises whether the signal is a one or a zero and creates the stream of ones and zeros.
layer 2 reads this stream and when it recognises the start pattern it then know the following bits are the header and so on and hence it can identify the frames.
You can see examples of start and stop patterns online e.g. (http://sinauonline.50webs.com/Cisco/Cisco%20Exploration%20Sem1Chap7.html):
I am broadcasting Hello using one Xbee (say A).....Xbee (say B) and Xbee (say C) are receiving a lot of garbage values before and after Hello.
All the baudrates are 9600...where am I going wrong?
It would help if you posted an example of the data you see, perhaps the hex values of each byte.
My guess is that you've configured the modules for "API mode" which wraps payloads with a header (starting with 0x7E, the character ~) and footer. It's useful for "smart" devices because it supports multiple packet types.
Check your settings, and make sure you're using ATAP=0. You can use XCTU to change the settings, or from a terminal use the escape sequence (1 second pause, +++, 1 second pause then module should respond with OK) to enter command mode. In command mode, first set ATAP0 and then ATWR to save the changes.
I am using XBee Digimesh Modules in API-Mode to send data between different industrial machines allowing them to share data, information and commands.
The API-Mode offers some basic commands, mainly to perform addressing and talk with the XBee Module itself in order to do configuration, etc.
Sending user data is done via a corresponding XBee API-Command which allows to send user-defined data with a maximum payload of 72 Bytes.
Since I want to expand this communication to allow integration of more machines, etc. I am thinking about how to implement a basic communication system that's tailored perfectly to the super small payload of just 72 Bytes.
Coming from the web, I normally would use some sort of JSON here but that would fill up the payload very quickly.
Also it's not possible to send a frame with lot's of information since this also fills up the payload very quickly.
So I came up with a different way of communicating. Instead of transmitting frames packed with information, what about sending some sort of Messages like this:
Machine-A Broadcasts: Who's there?
Machine-B Answers: It's me I am a xxx-Machine
Machine-C Answers: It's me I am a xxx-Machine
Machine-A now evaluates the replies and decides to work with Machine-B (because Machine-C does not match As interface):
Machine-A to B: Hello B, Give me some Value, please!
Machine-B to A: There you go: 2.349590
This can be extended to different short messages. After each message the sender holds the type of message in a state and the reply will be evaluated in relation to the state / context.
What I was trying to avoid was defining a bit-based protocol (like MIDI) which defines all events as bit based flags. Since we do not now what type of hardware there will be added in the future I want a communication protocol that's very flexible and does not need a coordinator or message broker, etc.
But since this is the first time I am thinking about communication protocols I am curious to know if there might be some existing frameworks that can handle complex communication on a light payload.
You might want to read through the ZigBee Cluster Library specification with a focus on the general commands. It describes a system of attribute discovery and retrieval. Each attribute has a 16-bit ID and a datatype (integers of various sizes, enumerated types, bitmaps) that determines its size.
It's a protocol designed for the small payloads of an 802.15.4 network, and you could potentially based your protocol off of a subset of it. Other ZigBee specifications are simply a list of defined attributes (and commands) for a given 16-bit cluster ID.
Your master device can go through a discovery process to get a list of attribute IDs, and then send a request to get values for multiple IDs in one shot. The response will be packed tight with a 16-bit ID, 8-bit attribute type and then variable length data. Even if your master device doesn't know what the ID corresponds to, it can pass the data along to other systems (like a web server) that do know.
I am studying VLAN. After hours of searching, I know 802.1Q doesn't encapsulate the original frame, instead it adds a 32-bit field between the source MAC address and the“EtherType” field of the original frame. But I can't figure out why. Can somebody explain to me why 802.1Q doesn't encapsulate the original frame? Thanks a lot.
The predecessor to 802.1q was Cisco's ISL. ISL did fully encapsulate the frame. Which means when any device was receiving an ISL frame, it must be able to understand the ISL tag, or else the whole frame is considered malformed.
In 802.1q, the first 12 bytes of the frame, whether it is tagged or not, is always the same.
To illustrate exactly what the tag modifies, here is the Packet Capture of a frame without the tag, then the same frame with the tag:
The bracketed portion in orange is all from the original frame. The bracketed portion in green is what the 802.1q tag adds to the frame.
Notice that in both cases, the first 12 bytes are the Destination MAC address and the Source MAC address.
Moreover, in both cases, the next 2 bytes of the frame are a "EtherType" field, which indicate the next protocol encapsulated in the datagram.
This means that whether a transit device understands 802.1q tags or not, the processing for that frame does not change. Which means 802.1q tags will still "work" through a device that...
is older, and doesn't support or understand 802.1q tags
is not configured to read/look for a particular tag
is built to only inspect the first 12 bytes of any frame so it can make a line-speed decision on how to forward the packet, which is the strategy in Cut-Through switching.
Overall, it allows the implementation and standardization of VLANs and VLAN Tagging without having to patch every device ever created that does Layer 2 processing to teach them how to interpret a "fully encapsulated VLAN tagging strategy" (like ISL). Instead, the devices that need to support VLANs can be patched to understand 802.1q, and all the other devices in transit can simply continue to operate without any fuss.
Granted, these days it is pretty rare to come across a host or switch that doesn't understand VLANs, but consider it from the perspective from when the concept of VLANs and Tagging were first invented.
I'm designing a game server and I have never done anything like this before. I was just wondering what a good structure for a packet would be data-wise? I am using TCP if it matters. Here's an example, and what I was considering using as of now:
(each value in brackets is a byte)
[Packet length][Action ID][Number of Parameters]
[Parameter 1 data length as int][Parameter 1 data type][Parameter 1 data (multi byte)]
[Parameter 2 data length as int][Parameter 2 data type][Parameter 2 data (multi byte)]
[Parameter n data length as int][Parameter n data type][Parameter n data (multi byte)]
Like I said, I really have never done anything like this before so what I have above could be complete bull, which is why I'm asking ;). Also, is passing the total packet length even necessary?
Passing the total packet length is a good idea. It might cost two more bytes, but you can peek and wait for the socket to have a full packet ready to sip before receiving. That makes code easier.
Overall, I agree with brazzy, a language supplied serialization mechanism is preferrable over any self-made.
Other than that (I think you are using a C-ish language without serialization), I would put the packet ID as the first data on the packet data structure. IMHO that's some sort of convention because the first data member of a struct is always at position 0 and any struct can be downcast to that, identifying otherwise anonymous data.
Your compiler may or may not produce packed structures, but that way you can allocate a buffer, read the packet in and then either cast the structure depending on the first data member. If you are out of luck and it does not produce packed structures, be sure to have a serialization method for each struct that will construct from the (obviously non-destination) memory.
Endiannes is a factor, particularly on C-like languages. Be sure to make clear that packets are of the same endianness always or that you can identify a different endian based on a signature or something. An odd thing that's very cool: C# and .NET seems to always hold data in little-endian convention when you access them using like discussed in this post here. Found that out when porting such an application to Mono on a SUN. Cool, but if you have that setup you should use the serialization means of C# anyways.
Other than that, your setup looks very okay!
Start by considering a much simpler basic wrapper: Tag, Length, Value (TLV). Your basic packet will look then like this:
[Tag] [Length] [Value]
Tag is a packet identifier (like your action ID).
Length is the packet length. You may need this to tell whether you have the full packet. It will also let you figure out how long the value portion is.
Value contains the actual data. The format of this can be anything.
In your case above, the value data contains a further series of TLV structures (parameter type, length, value). You don't actually need to send the number of parameters, as you can work it from the data length and walking the data.
As others have said, I would put the packet ID (Tag) first. Unless you have cross-platform concerns, I would consider wrapping your application's serialised object in a TLV and sending it across the wire like that. If you make a mistake or want to change later, you can always create a new tag with a different structure.
See Wikipedia for more details on TLV.
To avoid reinventing the wheel, any serialization protocol will work for on the wire data (e.g. XML, JSON), and you might consider looking at BEEP for the basic protocol framework.
BEEP is summed up well in its FAQ document as 'kind of a "best hits" album of the tricks used by experienced application protocol designers since the early 80's.'
There's no reason to make something so complicated like that. I see that you have an action ID, so I suppose there would be a fixed number of actions.
For each action, you would define a data structure, and then you would put each one of those values in the structure. To send it over the wire, you just allocate sum(sizeof(struct.i)) bytes for each element in your structure. So your packet would look like this:
[action ID][item 1 (sizeof(item 1 bytes)][item 1 (sizeof(item 2 bytes)]...[item n (sizeof(item n bytes)]
The idea is, you already know the size and type of each variable on each side of the connection is, so you don't need to send that information.
For strings, you can just throw 'em in in a null terminated form, and then when you 'know' to look for a string based on your packet type, start reading and looking for a null.
--
Another option would be to use '\r\n' to delineate your variables. That would require some overhead, and you would have to use text, rather then binary values for numbers. But that way you could just use readline to read each variable. Your packets would look like this
[action ID]
[item 1 (as text)]
...
[item n (as text)]
--
Finally, simply serializing objects and passing them down the wire is a good way to do this too, with the least amount of code to write. Remember that you don't want to prematurely optimize, and that includes network traffic as well. If it turns out you need to squeeze out a little bit more performance later on you can go back and figure out a more efficient mechanism.
And check out google's protocol buffers, which are supposedly an extreemly fast way to serialize data in a platform-neutral way, kind of like a binary XML, but without nested elements. There's also JSON, which is another platform neutral encoding. Using protocol buffers or JSON would mean you wouldn't have to worry about how to specifically encode the messages.
Do you want the server to support multiple clients written in different languages? If not, it's probably not necessary to specify the structure exactly; instead use whatever facility for serializing data your language offers, simply to reduce the potential for errors.
If you do need the structure to be portable, the above looks OK, though you should specify stuff like endianness and text encoding as well in that case.