Can I somehow set the 802.11 channel programmatically with the pcap library (or even anything else)?
I've written a sniffer and need to sniff on different channels, so I need to set the specific one first. I've been searching but I can't find anything, so I currently set it with the iw tool manually.
No, libpcap currently doesn't have an API to get a list of available 802.11 channels or set the current channel.
I infer from "iw tool" that you're doing this on Linux; you'll have to directly use netlink calls to set the channels - see, for example, the code in the ws80211_utils.c file in the top-level source directory of Wireshark.
Related
How exactly would one go about creating a raw socket on the MAC layer in Micropython?
The UNIX equivalent is:
eth_p_all=3
netif='wlan0'
s=socket.socket(socket.AF_PACKET,socket.SOCK_RAW,socket.htons(eth_p_all))
s.bind((netif,0))
For one, it is not clear how to get the interface name, and there is no socket.AF_PACKET or socket.htons.
So, if there is no way to do this with the stock libraries or firmware, which libraries should I choose, or if firmware modification is required, how exactly should I modify the firmware?
There have no raw socket implementation at current upy firmware. Yo can check the following line. The raw socket dispatch has been removed from modlwip.c
https://github.com/micropython/micropython/blob/68a5d6fe7746850ce049b8bf295bfce1382383f3/extmod/modlwip.c#L712
If you want to modify firmware by your self, you can follow the steps.
Check your platform's origin SDK support raw socket or not. (for example, cc3200 use TI's cc3200 SDK and it support raw socket)
Modify modlwip.c
There's an unofficial port(realtek's ameba series) support raw socket. You could start from this one.
https://github.com/wylinks/micropython-ameba/blob/ameba/ports/ameba/mphelper/mods/modlwip.c
I have been testing a connection to a TCP modbus device using the open source libmodbus library. The very first register I had to read was at 45001 on the device. It turns out that using libmodbus I have to give it an address of 0 to get this register. If I want register 45010 I use 9.
There is another register I want to read at 44001. I don't see anything in the documentation about changing the base address. Is it possible to use a negative offset? Am I going to have to recompile the library?
No, you're going to need to figure out how addresses described in your device's documentation map to actual Modbus addresses. This is extremely common.
The library you're using is just doing things the way the Modbus specification defines, and exposing that to you through its interface.
I was reading through the libpcap tutorial and was using some captures that I want to analyze (I didn't create them myself), so I am using the offline mode.
When applying the tutorial, nothing seemed to match. I didn't get valid MAC addresses from the ethernet frame and not even the preamble seemed to be correct. After some expirementing I fired up wireshark and noticed something odd. Each packet start with a 6: These are not packets on the ethernet (data link) layer, they are already one layer up on the IP (network) layer (They are IPv6 packets, which is expected).
Of course, I can now easily continue, but I am still wondering: How do I know at which layer the captured packages are? It seems there are at least two options: Saving at the data link layer and saving at the network layer. Could it also be that I receive packets on the transport layer? How do I differentiate? Must the user tell me? I'd really hate to have to guess, but seeing as wireshark gets it right, there must be a simple way to determine it.
The libpcap file format has a field in its global header called network that specifies the data link type. This corresponds to documentation over at the tcpdump project about various Link-Layer Header Types.
From there, you would be able to determine how many bytes the link layer consists (if any) and will be a sure fire way for you to parse pcap files created with the libpcap library.
I am not aware of a program options in the "libpcap family" that would allow you to just capture starting at the transport layer.
Is it possible to dump contents of tcp recv/send to a pcap file and then have wireshark analyse this. I want to do this because I want to log an applications conversations in order to debug issues but I don't want to have to write my own parsers (wireshark already supports it) and don't necessarily trust the application to parse frames correctly.
What follows is based on work that I've done exclusively on Windows.
I can't speak to how well any of this might apply to other systems.
FWIW, I would suggest editing your question (or at least tagging it)
to be more clear about what OS you're targeting.
If you are talking about writing what's received directly from a TCP client to a pcap file, the answer is no. The pcap file format requires at least some networking headers, e.g., the IP and TCP headers, in order for the file to be valid.
There are four approaches I see.
You could fake these headers for each read from the socket. This wouldn't necessarily require a lot of work, but it would require some knowledge of the relationships between the network header, the transport header, and the payload (i.e., your data) in order for everything to work right. If you're only interested in analysis of the payload in Wireshark, this might be a valid approach. However, if the analysis you're wanting to do in Wireshark is network analysis (i.e., analysis that includes the network headers), then you'll want to avoid this option and figure out how to capture the network headers directly.
You could use a raw socket to capture network traffic at the network layer. This will give you the IP packet - IP header, TCP header, and payload. You could dump this to a pcap file using LINKTYPE_RAW as the link-layer header type, and Wireshark will read the file fine. I've used this approach before.
The third approach would be to use WinPcap to collect your data. This is the same software that Wireshark uses behind the scenes to collect the data, and it's the approach I'm using now. If you have Wireshark installed, the WinPcap is already installed, too. WinPcap has a simple API with numerous examples for opening an interface, collecting the data, and dumping it to a pcap or pcap-ng file.
The fourth option is the simplest...just use Wireshark to collect the data simultaneously with your application.
HTH.
I would like to make a simple VST plugin that does this :
analyze an audio stream (volume, beat, etc...)
has triggers on the analyzer's output (e.g. do something when volume > threshold)
generate MIDI events based on the triggers
This is to be able to chain plugins, even if they are not designed for it. For example I could control the gain of a compressor with the envelope of an audio stream, simply by connecting the MIDI OUT of my plugin to the MIDI IN of the compressor's gain button.
The problem is I don't know how to do this. Is there support for direct MIDI connections like this in VSTs ? Or maybe I need some sort of "virtual midi device" for interconnects ?
Your hunch here is probably correct; this task will be easier to accomplish by writing a virtual MIDI device instead of a VST plugin. It is possible to send MIDI events to a sequencer using the sendVstEventsToHost() call, but the problem is that the documentation never specifies how the host is required to react to these events. Many hosts simply ignore them, and I certainly can't think of one which allows easy routing from a plugin to a MIDI channel (maybe plogue bidule?).
You might be able to accomplish this with Audio Units with the kAudioUnitType_Generator plugin type... though I've never written such a plugin, my impression was that this is what you'd use to generate MIDI to the host. But again, the problem here is that I'm not sure how the host would allow you to route audio to the plugin and accept MIDI from it.
At any rate, your idea implemented as a plugin will be the most difficult to implement when you want to standardize its behavior for the most widely used sequencers. I think that a far easier way to accomplish what you want is to create a virtual MIDI device, as you'd thought of already, and then use rewire to route an input signal to your program.
Edit: Here's some resources on writing MIDI drivers for various systems:
Audio device driver programming in OS X
Windows MIDI driver API guide
VST plugins do not support direct midi connections, they can only have midi in/out ports.
It is still possible to do it though, you just need a host that supports routing midi from one plugin to another. Modular hosts such as EnergyXT, Bidule, AudioMulch and Console excel here. They all allow audio and midi signals to be routed freely (except no feedback paths). But it also may be possible in hosts with more 'traditional' mixer style vst racks. (For example, AFAIK Reaper will forward any midi from one plugin to the next.)
If you want to build your plugin in .NET take a look at VST.NET