I am capturing in C with libpcap on a device, that does not support to be set in monitor mode via pcap (pcap_can_set_rfmon returns -6). But i can set it in monitor mode with iw and iwconfig on command line, so I do that manually and then run the program.
I am also capturing on my Mac where I can set the network device to monitor mode with the pcap function pcap_set_rfmon.
I was wondering if there is a way with pcap to actually check if the device already is in monitor mode, just for error handling and convenience reasons. I didn't find an answer (either positive nor negative). So maybe someone here can answer this?
I am capturing in C with libpcap on a device, that does not support to be set in monitor mode via pcap (pcap_can_set_rfmon returns -6).
pcap_can_set_rfmon() returns -6? That's PCAP_ERROR_RFMON_NOTSUP, which pcap_can_set_rfmon() isn't supposed to return; it's only supposed to return an error value if a problem occurs, it's supposed to return 0 if it thinks you can't set monitor mode and 1 if it thinks you can. Do you mean that pcap_set_rfmon() returns -6? And does pcap_can_set_rfmon(), which means "pcap_set_rfmon() should work"?
But i can set it in monitor mode with iw and iwconfig on command line, so I do that manually and then run the program.
Do you run either of those commands as root, e.g. with sudo?
I was wondering if there is a way with pcap to actually check if the device already is in monitor mode,
No. The idea is that the result of pcap_can_set_rfmon() should correctly indicate whether pcap_set_rfmon() will succeed, and that programs should request monitor mode regardless of whether it's already on, just as they do with promiscuous mode.
Unfortunately, there are currently some issues with Linux - mostly a combination of the non-mac80211 mechanisms not working as well with libpcap as the mac80211 mechanisms (requiring more privileges, colliding with NetworkManager, etc.) and of the mac80211 mechanisms not being available to libpcap because libpcap currently requires the ever-changing-API libnl in order to use them (which may need to be fixed by directly using the netlink sockets). This causes pcap_set_rfmon() not to work in cases where it should be able to work.
Related
I am working a C program that is uses sockets to implement tcp networking in a server application that I am working on. I was wondering is it possible to disable the tcp/ip stack of the kernel so my system do not interfere with incoming connection sync requests and IP packets.
Or I must compile kernel to disable it please tell if this is the case.
On this question How to create a custom packet in c?
it says
Also note that if you are trying to send raw tcp/udp packets, one problem you will have is disabling the network stack automatically processing the reply (either by treating it as addressed to an existing IP address or attempting to forward it).
If thats the case then how can it be possible.
Or is there any tool or program in Linux that can be used to achieve this like this comment Disable TCP/IP Stack from user-space
There is of course the counterintuitive approach of using additional networking functionality to disable normal networking functionality: netfilter. There are a few iptables matches/targets which might prove beneficial to you (e.g., the “owner” match that may deny or accept based on PID or UID). This still means the functionality is in the kernel, it just limits it.
if someone knows from right above then how can this be done are there any commands?
Well, you could compile yourself a kernel without networking :)
A couple of options
Check out the DPDK project (https://www.linuxjournal.com/content/userspace-networking-dpdk). DPDK passes the Physical NIC to User space via UIO driver to igb_uio|uio_pci_generic|vfio-pci. Thus eliminates Kernel Stack.
Use XDP supported NIC with either Zero-Copy or Driver-mode. with eBPF running one can push the received packets directly to User space bypassing the kernel stack.
Unless this is a homework project, remember: don't invent, reuse.
[EDIT-based on comment] Userspace TCP-IP stack have custom sock-API to read/write into the socket. So with either LD_PRELOAD or source file change, one can use the same application.
I'm working on a Kext that runs under 10.12.4 VM (I use parallels) and I'd like to enable pointer printouts (currently all pointers are hidden and appears on /var/log/system.log as <ptr>)
Prior to 10.12 there was option to directly put away debugging restrictions by setting nvram csr-active-config=%ff%00%00%00. However, now it's impossible to set csr-active-config directly but through csrutil disable from recovery mode. unfortunately, it doesn't disable all SIP features and the pointers remain hidden.
luckily, the following thread that offers workaround :
Alternatively, CSR can be disabled entirely by setting csr-active-config=ff%00%00%00. For a VM this can be achieved by booting to the Recovery partition, running csrutil clear to delete the csr-active-config variable entirely and nvram Xsr-active-config=ff%00%00%00. Then shutdown the VM, and use a hex editor to change X -> c in the nvram file. This will allow the -show_pointers boot-arg to work.
I'm working with Parallels, and I try to find the location of nvram settings. I saw promising file called NVRAM.dat but unfortunately
I couldn't trace the string Xsr-active-config after I've followed the instructions in the quoted paragraph above.
Perhaps there's another place for the nvram settings ?
thanks
change doprnt_hide_pointers to false in a debugger
I don't have a direct answer to your question, but I have a workaround: the output to the kprintf() serial log is not pointer-sanitised. So if you enable the kprintf flag in the debug boot-args, activate a virtual serial port which writes to a host file in the VM setup and change your logging from printf/IOLog to kprintf, you can get raw logging to your serial port file.
I find the kprintf() logging mechanism more helpful than the kernel syslog in other ways too - it works right up to a panic, it's not rate-limited, and it's less noisy. The downside is it has a noticeable performance impact if you log a lot.
I've often found myself wanting to test various nonblocking socket code, but I'm unsure how to simulate (or otherwise intentionally cause) an event to test nonblocking reads/writes and the various buffers in play - in other words, to cause a 'blocking event' on a given socket.
How would this be done? I imagine that this would require low level control over the TCP session in order to intentionally cause an EWOULDBLOCK error on the receiving socket
If you have a set of exact scenario you wish to check you program against, you can use ScaPy to send arbitrary packets with desired delays. It is possible to start from a captured session in *.pcap format, so that you won't have to handcraft all the packets, just modify/add/delay some, maybe generate a testing script, etc. See Sending packets from pcap with changed src/dst in scapy. TCPReplay can also replay *.pcap file with desired speed (packets/sec).
If you want to test your program in harsh network environment (e. g. simulate packet loss and retransmission), there are readily available tools for this, e. g. for Linux take a look at Simulate delayed and dropped packets on Linux (and links to Windows tools from there).
I'm working with a USB device in Linux and have written a library to control this device.
Without going in to TOO many details, the device uses a standard UART protocol, so all I have to do is open a serial connection with open, configure the relevant parameters like baud rate, stop bit, parity, etc, etc, and start bit-banging registers.
The library works fine, however, it its hard coded to assume that this device is /dev/ttyUSB0. That is, this is what I pass to open. If open fails, I exit.
What I would like to do is detect that this device is present, regardless if it's /dev/ttyUSB0, /dev/ttyUSB1, etc. And even detect if there are multiple of these devices connected.
I can write code to poll certain registers on the device that will return serial number, product ID, etc, so I can detect that what is on the other end of the USB is indeed my device... but how can I find a list of connected USB devices, again, in native C?
OR is there a more elegant way of doing this, such as interfacing with it's kernel module, or something? I can provide the USB driver it actually uses, but I'm sort of lost when looking through the code.
Thanks for any insight.
The elegant method is to use udev to create a descriptive symlink for your device when it is connected. Add a line something like this to /etc/udev/rules.d
SUBSYSTEM=="tty",ENV{ID_MODEL}=="My_FlowMeter_Model",ENV{ID_USB_INTERFACE_NUM}=="00",SYMLINK+="flowmeter",RUN+="/bin/su pi -c /home/pi/record-flowmeter.sh
That's a very slightly modified version of an actual udev rule my research group uses to collect data from USB devices connected to battery-powered Raspberry Pi boxes. It also runs a script automatically, which has commands like
stty -F /dev/flowmeter 500000 -ixon -echo -icanon
If you want to know the "real" device filename, you could do readlink /dev/flowmeter. But for most uses you can just use the link: fd = open("/dev/flowmeter"); (or pass it as an argument to your program)
Naturally you should replace flowmeter with a short name for your own device, as well as updating the ID_MODEL based on the output from lsusb.
Multiple devices are a bit more complicated, but there are plenty of examples of udev rules out there.
On Linux, the information you are looking for is in the /sys filesystem, specifically under /sys/bus/usb/devices. From there you will need to search the filesystem to find your device.
For example, I just plugged a USB-serial dongle into my Linux (kernel version 2.6.35) and the device appeared under /sys/bus/usb/devices/2.1-8. Here, I am able to find that this is my device by vendorId:deviceId by checking the files idVendor and idProduct. Here, there is a directory named 2.1-8:1:0 which contains a directory named ttyUSB0.
Obviously, to find your device you will need code (or a shell script using find) to scan the directory tree, looking for the right entries.
How are you supposed to programatically detect when the remote modem on your call hangs up? I am writing a C program which interfaces with a SoftModem device /dev/ttySL0 in Ubuntu linux. I am able to configure the modem using Hayes AT commands and communicate with the remote modem. However, I haven't been able to determine how I'm supposed to detect that the other end has hung up the line.
I have the modem configured so that when the other end hangs up, the device prints NO CARRIER and switches to command mode. However, I can't use the NO CARRIER string because I can't guarantee that the modem won't receive that string while in data mode.
How do you "listen" for remote hang up?
This is a hardware signal on modems, the Carrier Detect (CD) line. You'll need to monitor it to know that the connection was lost. Basics in linux are described in this how-to, you obtain the signal state with ioctl() using the TIOCM_CAR command.
Testing for NO CARRIER as text will not suffice. This text frequently occurs on sites in the net, even on Q&A sites.
Coming from the modem, it should be enclosed in line breaks.
Besides, after you detect that text, you can try to switch to command mode with +++. If that works, your connection persists and you can reattach it and continue using it. If it doesn't (because you are already there and +++ is an invalid command), the connection has gone.