I am writing a linux kernel module for some tunnelling activity. The module will get packets from the networking stack and perform some operations on it. What is the best possible way to inject packets into the stack from the bottom(emulate ethernet packet arrival on wire) so that the packet traverses the entire receive path and is delivered to my module.
My module uses the kernel br_handle_frame_hook hook to get the packet which means that it cannot co-reside with the linux native bridge module. Any ideas will be appreciated.
Consider using NetFilter
http://www.phrack.org/issues.html?issue=61&id=13
TAP would be great, if you're working in user space, which you're not
I believe that TAP device is what you are looking for - a nice way to send/receive Ethernet packets from user-space
I recommend tap like #raber before me. I also recommend reading this excelet tutorial: http://backreference.org/2010/03/26/tuntap-interface-tutorial/ .
You asked whether you can make the tap non-programatically and then replay traffic into it. The answer is yes. Look for the 'persistency' options (which b.t.w. can also be done programatically with a short tool you can write yourself if you prefer not to download tools that can already do it). You may also want/need to define the user that may use the tap (or otherwise just sudo your operations).
Related
I'm searching for help and an opinion-advice for a network project, in which I'm working lately. This requires a Linux machine to be a passive network appliance.
Network packets come in from one network interface and come out from another interface ( net--eth0-->Linux PC--eth1-->net) without making any modifications on data.
The application, which is going to run on the Linux system, will change only the order of the packets. It is going to be a "silly" network emulator application.
The first implementation was made with RAW sockets, where read() is called every time a packet arrives to user space and write() is called when an Ethernet packet should be sent down to the NIC.
I would like to know if there is a more practical and direct way than RAW sockets, bypassing Linux's network stack.
If what you want is to bypass the kernel, DPDK in Linux and NetMap in FreeBSD are options to do just that.
Indeed this can be done in dpdk in Linux. There are l3fw and l2fwd sample applications in the examples folder of the dpdk tree, which may inspire you. Also consider using vpp, a fd.io project hosted by Linux Foundation, which can use dpdk.
Rami Rosen
I am trying to inject a packet into the network using raw sockets, but somehow can't seem to get a receiver to capture this packet. How do i check whether the packet is being dropped by the linux network stack? Could someone point out some tools for doing this?
I don't know about accessing the network stack directly (not saying it's impossible, just that I don't know how to do it if you can), but you could probably use Wireshark or something similar to see if the NIC on the receiving end is receiving the packets. You could also use it on the sending end to check if the packets are being sent out properly (or are actually being sent out in the first place, if that's the issue), as it allows you to examine the fields/etc. of individual packets. Quite a useful tool, really.
http://www.wireshark.org/
Note that the website doesn't have direct downloads for Linux builds, but does list third-party packages for various Linux distros.
Options include wireshark and tcpdump, or tcpdumping into a pcap file and then analyzing that using wireshark. One option probably is also to use strace or similar tool to trace the system calls that do the sending.
Another option is to use BPF to instrument the TCP stack in the kernel. You can take a look at some of the already existent scripts for TCP, e.g. tcplife:
https://github.com/iovisor/bcc/blob/master/tools/tcplife.py
http://manpages.ubuntu.com/manpages/bionic/man8/tcplife-bpfcc.8.html
http://www.brendangregg.com/blog/2016-11-30/linux-bcc-tcplife.html
My question is:
How to captuare an incoming IP packet from a network interface, change its content and resend it from another network interface?
The choice is yours, there is no preference (and hence no "normal").
using libnetfilter_queue to deliver to userspace and do extensive modification there.
or an xtables module, also works (since it's called by NF anyway). Allows for sufficient fine-grained configuration with help from userspace.
nfhook module, if you must. All configuration you must implement yourself.
well and finally, if you like things that hurt, you might as well implement your own virtual NIC driver.
The usual way of doing something like this is to create a netfilter hook module.
See this example for a quick start.
You don't mention what you intend to change exactly, which makes it difficult to answer your question properly.
For content substitution on a router kind of device (guess), netsed might be the simplest approach available.
I spent the last days reading through man pages, documentations and anything else google brought up, but I suppose I'm even more confused now than I was at the beginning.
Here is what I want to do: I want to send and receive data packets with my own layer 3-x protocol(s) via a wireless interface (802.11) on Linux systems with C/C++.
So far, so good. I do not require beacons, association or any AP/SSID related stuff. However, for data transmissions I'd like the MAC layer to behave "as usual", meaning unicast packets are ACK'd, retransmissions, backoff etc. I'd also like to enjoy the extended QoS capabilites (802.11e with 4 queues and different access categories). Promiscuous mode on the other hand is not a concern, I require only broadcast packets and packets sent to the specific station.
What would be the right way to go about it? Most of the documentation out there on raw socket access seems to be focused on network sniffing and that does not help. I've been playing around with the monitor mode for some time now, but from what I've read so far, received packets are not ACK'd in monitor mode etc.
Without monitor mode, what would be the alternative? Using ad hoc mode and unix raw sockets? Or do I have to fiddle around with the drivers?
I'm not looking for a complete solution, just some good ideas, where to start. I read through the man pages for socket(2), socket(7) and packet(7) but that did not help concerning the behaviour of the MAC layer in different modes.
Thanks in advance.
802.11 is layer 2 (and 1) protocol specification. It was designed in a way, which allows higher-layer protocols to treat it as Ethernet network. Addressing and behaviour is generally the same. So for a layer 3 protocol you should not be concerned about 802.11 at all and write your code as if you were expecting it to run on Ethernet network.
To make it work you should first connect to a wireless network of some sort (which is conceptually equal to plugging a wire into a Ethernet card). Here you may choose ad-hoc (aka IBSS) or infrastructural (aka BSS) network (or PBSS once 802.11ad is approved ;).
Operating cards without any sort of association with network (just spitting out packets on air) is not a good idea for a couple of reasons. Most importantly it's very hardware dependent and unreliable. You can still do it using RF mon (AKA monitor mode) interface on one side and packet injection (using radiotap header) on the other but I don't recommend that. Even if you have a set of identical cards you'll most likely encounter hard to explain and random behaviour at some point. 802.11 NICs are just not designed for this kind of operation and keep different mount of state inside firmware (read about FullMAC vs. SoftMAC cards). Even SoftMAC cards differ significantly. For example theoretically in monitor mode, as you said, card should not ACK received packets. There are cards though that will ACK received frame anyway, because they base their decision exclusively on the fact that said frame is addressed to them. Some cards may even try to ACK all frames they see. Similar thing will happen with retransmissions: some cards will send injected packet only once (that's how it should work). In other NICs, retransmissions are handled by hardware (and firmware) and driver cannot turn it off, so you will get automatic retransmission even with injected data.
Sticking with layer 3 and using existing modes (like ad hoc), will give you all capabilities you want and more (QoS etc.). Ethernet frame that you send to interface will be "translated" by the kernel to 802.11 format with QoS mapping etc.
If you want to find out about MAC behaviour in various modes you'll have to either read the mac80211 code or 802.11 standard itself. http://linuxwireless.org wiki my help you with a few things, but kernel hackers are usually to busy to write documentation other than comments in the code ;)
L3 protocol implementation itself can be also done either in kernel or user mode (using raw sockets). As usual kernel-side will be harder to do, but more powerful.
Because you want to create own network layer protocol (replacement for IP), the keyword is: "raw ethernet socket". So ignore "Raw IP socket" stuff.
This is where to start:
int sockfd = socket( PF_PACKET, SOCK_RAW, htons(XXX) );
Correct man page is: packet(7).
Find more information by googling with the keyword.
One quite complete example here.
Edit: The link to the example seems to be currently broken: another examples
Probably you want something like libpcap.
Libpcap allows you to read/inject raw packets from/into a network interface.
First, there’s something you should be aware of when trying to transmit raw 802.12 frames- the device driver must support packet injection.
You mentioned monitor mode, which is at a high level the rx equivalent of the injection capability- which is not a “mode”, jist a capability/feature. I say this because some 892.11 device drivers on Linux either:
Support monitor mode and frame injection
Support monitor mode and not frame injection
Support neither
I don’t know any straightforward way to check if the driver supports frame injection aside from attempting frame injection and sniffing the air on another device to confirm it was seen.
Monitor mode is usually easy to check by using sudo wlan0 set monitor and seeing what the return code and/or output is.
It’s been a few years since I’ve worked on this but at the time, very few devices supported monitor mode and frame injection “out of the box”. Many only supported monitor mode with a modified version of the vendor or kernel driver
You’ll want to make sure your device has a driver available that fully supports both. This sort of task (frame monitoring and injection) is common for Penetration Testers who tend to use Kali Linux, which is really just an Ubuntu distribution with a bunch of “hacking” tools and (modified) 802.11 device drivers preloaded and in its repositories. You can often save time finding a well supported card by using a search engine to find the device and driver recommended for Kali users
I’m bringing this monitor/injection capability up explicitly because when I first worked on a similar project a few years ago, I needed to use a patched version of the official kernel driver to support monitor mode- it was an rtl8812au chipset. At that time, I made an incorrect assumption that monitor mode support in the driver implied full injection support. I spent 2 days banging my head against the wall, convinced my frames weren’t built correctly in my application, causing no frames to leave the card. Turned out I needed a more recent branch of the driver I was using to get the full injection support. This driver in particular supports both monitor mode and frame injection now. The most frustrating thing about diagnosing that problem was that I did not receive any errors from system calls or in kernel messages while trying to transmit the frames- they were just being silently discarded somewhere, presumably in the driver
To your main question about how to do this- the answer is almost certainly libpcap if you’re writing your application in C/C++ as libpcap provides not only packet capture APIs but also packet injection APIs
If you do it in Python, scapy is an excellent option. The benefit of Python/scapy is that
Python code is much quicker to write than C
scapy provides a significant amount of classes that you can use to intuitively create a frame layer by layer
Because the layers are implemented as classes, you can also extend and “register” existing classes to make certain frames easier to create (or parse when received)
You can do this in straight C using the UNIX sockets API with raw sockets directly- but you’ll have to deal with things that libpcap exists to abstract from you- like underlying system calls that may be required when doing raw frame transmission, aside from the standard socket(), send(), recv() calls. I’m speculating that there are a handful of ioctl calls you may need at the least, specific to the kernel 802.11x subsystem/framework- and these ioctl() calls and their values may not be completely portable across different major kernel versions. I’ll admit I ended up not using the pure C (without libpcap) approach, so I’m not 100% sure about this potential problem. It’s something you should look more into if you plan to do it without libpcap. I don’t recommend it unless you have a really good reason to
It sounds like you are getting the media and transport layers mixed up.
802.11 is what's commonly referred to as a "link", "physical", or "media" layer, meaning it only deals with the transmission of raw datagrams.
Concepts like ACKs, retransmissions, backoff (flow control) apply to the "transport" layer, and those particular terms are strongly associated with TCP/IP.
Implementing your own complete transport layer from scratch is very difficult and almost certainly not what you want to do. If instead you want to use the existing TCP/IP stack on top of your own custom interpretation of 802.11, then you probably want to create a virtual network interface. This would act as an intermediary between TCP/IP and the media layer.
Hopefully this gives you some better context and keywords to look for.
I want to determine if a network card is enabled, up, and plugged in. Basically, I want to know if the network card will work. I need this information from with a C++ program, and would like to display an error message when the network isn't working properly. If possible I would like to avoid using shell commands to determine this information.
You can look at /sys/class/net/eth0/operstate where eth0 is your interface to see if it's up.
Look at /sys/class/net/eth0/carrier to see if there is a carrier.
Though I guess executing ifconfig and friends will give you more compatibility to *BSDs.
open AF_NETLINK socket
bind it to sockaddr_nl with nl_groups = RTMGRP_LINK
send message RTM_GETLINK to kernel
make poll/epoll on socket to read RTM_NEWLINK and RTM_DELLINK messages
you will receive initial interfaces list and its changes in future
Remember, on Linux "everything" is a file.
The best way would be to use the approved kernel<->userspace communication, namely sysfs, mounted at /sys. Network devices are linked at /sys/class/net
If you wish to use the ioctl interface, look at man netdevice
How do you want to identify the network card? You might try taking a look at /etc/udev/rules.d/70-persistent-net.rules which maps hardware MAC addresses into nice names (like eth0).
Then, when you have the nicer name, you can run things like ethtool eth0 to determine if it is [physically] connected (last line), ifconfig eth0 to determine if it is up (look for "UP BROADCAST..."), and if it has an IP address.
I'm willing to guess there are automatic libraries for this though; have you looked around? I'm not sure if there's easily accessible code in NetworkManager, but that should be a good first place to look.
Run through the output of getifaddrs, you can use the link layer for the MAC address to identify an adapter and check the ifa_flags for IFF_UP. Use AF_NETLINK for notifications about interface changes.