Permanently save Netlink Sockets changes - linux

In order to set Network Interfaces on Ubuntu 16.04 LTS I've recently developed a C program which takes advantage of Netlink Sockets for interprocess communication between User-Space and Kernel-Space.
After having successfully changed the ip/gateway/netmask addresses (emulating some iproute2 functions), I need to permanently save these changes. Indeed, after reboot these changes are dropped.
I don't want to change the /etc/network/interfaces file nor use Network Manager, but programmatically communicate with the Linux Kernel.
There is any way of doing it?
Regards

Related

passive os fingerprint change to MacOS

Ubuntu 16.04 server, proxy raised on the server (3proxy). When connected via a proxy with macbook, OS Fingerprint is defined as Linux 3.11 and never [fuzzy] (http://witch.valdikss.org.ru/)
At the moment, using non-complex manipulations with the /etc/sysctl.conf kernel settings, it turns out to change to Android (Linux 2.2.x-3.x [generic] [fuzzy]) and Windows NT.
Need to change the OS Fingerprint, so that http://witch.valdikss.org.ru/ defines the connection as Mac OS X [generic] [fuzzy]
According to p0f README "one of the most valuable TCP fingerprinting signal" is TCP options layout. Applied to MacOS and Linux fingerprint entries this means we should change layout from:
mss,sok,ts,nop,ws
to
mss,nop,ws,nop,nop,ts,sok,eol+1
This cannot be done by sysctl since Linux kernel hardcode this order into tcp_connect syscall: https://github.com/torvalds/linux/blob/bab5c80b211035739997ebd361a679fa85b39465/net/ipv4/tcp_output.c#L458
So you must write netfilter kernel module to mangle TCP options later like TCPMSS module does:
https://github.com/torvalds/linux/blob/master/net/netfilter/xt_TCPMSS.c.
Either patching tcp_connect or writing custom netfilter module requires strong kernel programming skills.
Another option is to somehow intercept TCP SYN/SYN+ACK packets by user-space program (maybe nfqueue or tproxy with raw sockets can help), mangle it and write back to kernel. This can significantly hurt performance but easier to implement.
UPD: I've googled some working and dirty example of this technique based on nfqueue/python: https://forums.hak5.org/topic/33532-p0f-mangler/

Ethernet frames from NIC

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

kgdboe kgdb kernel debugging at boot

I'm attempting to get kernel debugging to work during boot. I've followed all the steps to install it (how to use kgdb over ethernet(kgdboe)?) and can connect fine when I insmod after loading, but if I add this
BOOT_IMAGE=/vmlinuz-4.0.0-rc7+ root=UUID=<my_root> ro drm.debug=0x04 kgdbwait kgdboe=#<src_ip>/eth1,#<target_ip>/ vt.handoff=7
to the kernel boot line, I don't see the module loaded, and it doesn't kgdbwait.
When I look at my kern.log, I see the following:
kgdboe: eth0 does not have a in_ifaddr struct associated. Cannot get default IP address.
I have both eth0 and eth1 by the way, but only eth1 is connected.
Any suggestions? Is it just that the pcie network card isn't loaded until after boot and it's causing me issues?
Also, why would I need to specify the source or target ip addresses? Is there any way to have kgdboe accept all ip addresses, even when trying to load it at boot?
Thanks
Yes, for early kernel debug kgdboe does not really work. There are several issues, some easy to solve, some not solveable. You can hard link the required modules rather than demand load them to solve the easy issue. But the core problem is that the kgdb early wait will pause all worker threads, and nearly all of the Ethernet PCIe card drivers require worker threads, or else require IRQs. Even on the polled Ethernet driver support (very limited), the IRQ's can be preempted (or illegally hold locks), and prevent the polled Ethernet driver from functioning. As a result early kernel debug does not function with kgdboe reliably, and with some Ethernet drivers, at all. (e.g. kgdbwait on the GRUB2 boot line.) There has been occasional talk about hacking up various Ethernet driver sources to attempt to provide kgdboe support over a special purpose Ethernet driver, but none that I know of that is distributed. You are still best off with using a serial port, and for full functionality, a serial console, which can be multiplexed onto a single serial port if need be with kgdboc (agent-proxy). If true remote access is required, then remote into the debugging system that initiates the serial connection.
You can also use the USB port, but requires a specific USB<->serial USB dongle that is no longer sold. (Ajays Blue dongle). These were discontinued about 6 months ago, and there is no replacement yet. (It was a Windows debugging device adapted to Linux, and Windows has moved on to native USB3.0 debugging features, and Linux has yet to catch up to that.) So, unless you have the needed USB converter, or have another source, or have an alternative adapter, you are out of luck on USB2.0.
Serial is still your best option, sadly, even in 2016.
See: http://kdbg.wiki.kernel.org

Implementations of Mobile IP on linux

Are there any standard implementations of Mobile IP for Linux?
If I want to support mobile IP for a network, what all needs to be done?
If I have to write code from scratch, is it likely that a kernel module will suffice or I would have to make changes to the kernel code.
I just need a bit of headstart to know where to begin.
It appears likely to me that it can be done without requiring any kernel code at all, you can achieve it by having a userspace daemon create a tun interface (much like a VPN client would typically do) and then route or encapsulate packets in whatever way is required for mobile IP. The userspace daemon may have to modify the kernel's routing table but that's ok.
Examples of the tun interface users are openvpn and Qemu.

resume/suspend enery star linux from command line

I have an ssh connection to a linux machine which is hibernated after some non-activity time.
I want to make it resume, how do I do that?
(writing to /dev/mouse to simulate mouse movement didn't do the trick)
A machine that is hibernating cannot come out of sleep without pressing the power button, or sending a magic packet if the ethernet adaptor has Wake On Lan (WOL) capability and the motherboard supports that. WOL packets can only be generated on the local network, not remotely from other networks.
-Adam
In addition to what Adam has stated, some motherboards support waking from various states when an interrupt is triggered.
The key here is which state you are referring to as hibernation; are you talking about an extremely low-power mode in hardware, or software hibernation where core memory is written to disk and the machine is turned off completely? If the latter, WOL is the only possibility; if the former, than you can tell your motherboard to watch for interrupts from various sources and you can use some other means to trigger a wake-up.
A good starting point for reading is the Wake-On-LAN article on Wikipedia.
To accomplish WOL you need a few things:
First, check the BIOS of the machine you're waking to see if it supports WOL. If it does, make sure it's turned on.
Then get a program that can send WOL packets:
In linux: sudo apt-get install wakeonlan
For windows just find one to download using google. There are probably 100 different apps that do it, I don't use Windows so I don't have one to reference.
If you want to receive WOL packets from outside of your local network. Configure your router to forward port 9 to 255.255.255.255 (IP Broadcast-To-All address).
For some really useful info on the WOL protocol as well as a sample capture file that can be loaded in wireshark, see this article.

Resources