I'm trying to compile a C program that uses libpcap in statistical mode on OSX. The original code was written for Windows, using the winpcap library. The version of libpcap on my Mac has never heard of the pcap_setmode function that it uses - I've got a nasty feeling that it might be Windows-specific.
Is there any way to capture in stats-mode on OSX? If not, is there something about the architecture/capabilities of the OS that prevents this, or is this an extra feature added to WinPcap which has never been a feature of the main library?
pcap_setmode() only has a definition in the Win32 port, because the WinPcap driver for Windows is the only packet capture mechanism that supports statistical mode; BPF in Mac OS X and *BSD and AIX and Solaris 11 don't support it, PF_PACKET sockets in Linux don't support it, DLPI in Solaris and HP-UX don't support it, etc..
UN*Xes generally come with a mechanism that supports capturing packets, so libpcap can just use that, without adding its own kernel-mode code; this means it can't control what facilities those capture mechanisms have - if a capture mechanism doesn't have it, libpcap can't add it. Windows doesn't come with such a mechanism; it does come with NDIS, which can support such a mechanism, so WinPcap comes with a kernel-mode driver that uses NDIS to implement such a mechanism, and thus has some more control over what features it offers.
pcap_setmode() only has a definition in the Win32 port (for unknown reasons to me).
Related
I have a student task to read PCI info via 0xCF8 and 0xCFC ports using outl(), inl() functions. It assumes I use Linux x86, but can I do such things on macos with M1 chip?
I found <sys/uio.h> header but it does not define functions prototypes.
outl and inl are platform-specific functions for Linux. If it is an exercise, and you have to submit a code snippet, then I suggest installing some kind of virtual machine (VirtualBox or maybe Docker Desktop) and write a program for Linux, otherwise your code would be unlikely to be accepted, since it'd use completely different low-level API.
Can a user application on macOS receive raw ethernet packets? I have a piece of hardware that uses it's own custom ethernet protocol and has it's own ether type defined. Is there anyway I can create a user application that sends / receives these packets? Mac OS does not support AF_PACKET. I believe Berkeley Packet Filter requires root access. Are there any other options?
Install libpcap library - https://formulae.brew.sh/formula/libpcap
Then you could sniff and/or inject arbitrary packets.
Can a user application on macOS receive raw ethernet packets?
Yes. See, for example, /usr/sbin/tcpdump.
I believe Berkeley Packet Filter requires root access.
Yes, by default; that's what the "launch daemon that adjusts capture permissions at system startup" provided by Wireshark does (it's based on stuff from the libpcap source distribution) - it makes the BPF devices readable and writable by a group, so if your code runs with that group as one of the groups in its group set, it can read (capture) and write (transmit) on BPF devices.
Are there any other options?
PF_NDRV sockets might work. See, for example, this chapter from a macOS/iOS/etc. internal book and this StackOverflow answer.
Install libpcap library
Note that libpcap ships as part of macOS, and the headers ship as part of the macOS SDK, so that, on macOS, you can build programs that use it without installing anything other than Xcode (or the Xcode Command Line Tools), just as you can, on Linux, build programs that use libpcap without installing anything other than a compiler and your distribution's libpcap "developer package", and you can, on *BSD, build it without having installed anything other than whatever the installer says you need for developing software (it might even install the compiler/linker and the appropriate headers by default).
I have written a application in Qt and what is the best way to communicate with a custom USB device (does not belong to any class - need to write custom drivers for it) under Windows. In Linux I could just share the data with user space from the /dev or /sys filesystems. What are the equivalent alternative in Windows ?
There are a couple of user-space USB libraries for Windows. While Microsoft do provide WinUSB directly, I'd recommend using either libusbx or libusb and installing the driver for your device with zadig.
Using libusbx rather than the Microsoft driver directly has the advantage of being easier to port to other operating systems, which might be a consideration for you as you are using Qt.
I have some code that using UNIX sockets. But I need to compile it for winodws(using mingw32 on mac os x) but I don't want to use winsock because I'm worried about compatibility! Is there is a way to use UNIX sockets on windows?
If you stick to the BSD API that Winsock provides then you wont have that many problems. A small amount of start up and shutdown code will be Windows specific but most of the socket code will be cross platform.
I'd suggest looking into cygwin (http://www.cygwin.com/), they make every effort to be compatible. However, I have no idea how you would cross-compile for that environment on Mac OSX.
I am aware of windows kernel but new to linux kernel. I just need to know how its done in linux, i.e. the program development.
You can check there (free-electrons.com), it's a good informations source for kernel developement. (specialized in embedded linux, but most of the docs are available for standard development)
You have also the classical Linux Devices Drivers, which is very complete and detailled.
And last but not least, the Linux kernel documentation.
Linux does not have a stable kernel API. This is by design, so you should generally avoid writing kernel code if you can; it is unlikely to remain source-compatible indefinitely, and will definitely NOT be binary-compatible, even between minor releases.
This is less-or-more true for vendor kernels; Redhat etc DO maintain source & binary kernel compatibility between major revisions.
More work is gradually being done in the kernel to reduce the amount of kernel-code required to carry out various tasks, such as driver development (for example, USB drivers can typically be done in userspace with libusb), filesystem development (FUSE) and network filtering (NFQUEUE). However, there are still some cases where you need to; in particular, block devices still need to be in the kernel to be able to be usefully used for boot devices and swap.