iptables mirror target for linux kernel 4.10

After my last kernel upgrade I tried to build the iptables mirror target published the last time here. The iptables mirror target takes the packet sent to your machine and returns the same packet to the machine the packet came from. Thus, let’s say someone tries to scan your machine or tries an attack he would scan his own machine or even attack his own machine. When I tried it with kernel version 4.12 , it did not build anymore with the current linux kernel. This time a struct changed in kernel 4.10 and some functions have got renamed in the kernel 4.11. Thus I had to update the ip_direct_send and ipt_mirror_target functions. You can download the newer release for kernel version 4.10 and probably future kernels here:

MIRROR.4.10.tar.gz (34) gplv3-127x51

The kernel module has been tested with kernel version 4.12.12-gentoo. To build the module, boot the kernel you want to use the module with. Afterwards unpack the archive and run the compile.sh script to build the module. Then run the install.sh script for installing the compiled module into the /lib/modules directory for your kernel.

Now you may use the mirror target in place of the REJECT or DROP target in the INPUT, FORWARD and PREROUTING chains, like this in your firewall script:

$IPTABLES -A INPUT -j MIRROR

Beware: The use of the mirror target may lead to strange results, in example if you want to connect to an iptables protected machine which uses the mirror target, you may end up connecting to the local machine without recognizing it. It also may use much bandwith. The worst case occurs if you have two machines using the module. These machines may end up playing ping pong. So you have been warned, use with caution and at your own risk. For more information see: MIRROR target.

Downloads for older kernel versions are below. Notice the version numbering 2.6.25 works for kernels up to 2.6.27. 2.6.28 also works for 2.6.29 and 2.6.30 kernels. The 2.6.13 version of the module should work up to kernel version 2.6.16.

MIRROR.2.6.13.tar.gz (2832)
MIRROR.2.6.24.tar.gz (3259)
MIRROR.2.6.25.tar.gz (2995)
MIRROR.2.6.28.tar.gz (3044)
MIRROR.2.6.31 (2856)
MIRROR.2.6.35.tar.gz (2791)
MIRROR.2.6.36.tar.gz (2876)
MIRROR.2.6.37.tar.gz (2645)
MIRROR.3.0.7.tar.gz (2348)
MIRROR.3.1.0.tar.gz (2037)
MIRROR.3.3.0.tar.gz (2065)
MIRROR.3.6.0.tar.gz (1761)
gplv3-127x51

regards
Jürgen

1 Star2 Stars3 Stars4 Stars5 Stars (No Ratings Yet)
Loading...

watching 3D stereo mpo images with ushare

Some months ago I got my brand new LG 55LA6608 3D TV. Of course I wanted to watch the 3d photos taken with the Fujifilm Finepix Real 3D camera with it. The images taken by the camera are being stored using the MPO file format. These images consist of two jpeg images and some metadata inside the exif header inside the MPO container. According to the specification the television is capable of playing this file format, which works fine when using in example an USB-stick. However, it is desireable to watch the images using a network connection, for example when the files are stored on a linux server.

For displaying videos or images from a server this and other television devices use the DLNA protocol, which is implemented by by various linux services like minidlna or ushare. None of the tested ones was capable to present the MPO files to the TV. The solution to enable ushare to do this is quite simple. The MPO mime type has to be added to ushares supported file formats. This can be done by adding the line

{ “mpo”,  UPNP_PHOTO, “http-get:*:image/mpo:”},

to the MIME_TYPE_LIST array in mime.c. This has been verified to work with the ushare-1.1a. For convenience one can download the patch for this from here:

ushare-mpo.patch (932)

One can download the ushare sources from SourceForge. After downloading patch the ushare sources with the mpo-patch and build it. Build and usage instructions can be found in the readme file included in the ushare download from SourceForge. Do not forget to run ./configure –enable-dlna before running make for use with recent devices like the mentioned LG TV.

As usually, for gentoo users there is a more easy way: Create the directory

/etc/portage/patches/media-video/ushare/

and place the patch file in it. Make sure that the dlna USE-flag is set in /etc/make.conf or /etc/portage/package.use. Afterwards emerge ushare again and enjoy watching your 3D MPO images stored on your linux box using your TV.

regards

Jürgen

1 Star2 Stars3 Stars4 Stars5 Stars (1 votes, average: 5.00 out of 5)
Loading...

iptables mirror target for linux kernel 3.6

After my last kernel upgrade I tried to build the iptables mirror target published the last time here. The iptables mirror target takes the packet sent to your machine and returns the same packet to the machine the packet came from. Thus, let’s say someone tries to scan your machine or tries an attack he would scan his own machine or even attack his own machine. When I tried it with kernel version 3.6 , it did not build anymore with the current linux kernel. This time some functions have got removed from the kernel. Thus I had to update the ip_direct_send function. You can download the newer release for kernel version 3.6 and probably future kernels here:

MIRROR.3.6.0.tar.gz (1761) gplv3-127x51

The kernel module has been tested with kernel version 3.7.0-vs2.3.5.1. To build the module, boot the kernel you want to use the module with. Afterwards unpack the archive and run the compile.sh script to build the module. Then run the install.sh script for installing the compiled module into the /lib/modules directory for your kernel.

Now you may use the mirror target in place of the REJECT or DROP target in the INPUT, FORWARD and PREROUTING chains, like this in your firewall script:

$IPTABLES -A INPUT -j MIRROR

Beware: The use of the mirror target may lead to strange results, in example if you want to connect to an iptables protected machine which uses the mirror target, you may end up connecting to the local machine without recognizing it. It also may use much bandwith. The worst case occurs if you have two machines using the module. These machines may end up playing ping pong. So you have been warned, use with caution and at your own risk. For more information see: MIRROR target.

Downloads for older kernel versions are below. Notice the version numbering 2.6.25 works for kernels up to 2.6.27. 2.6.28 also works for 2.6.29 and 2.6.30 kernels. The 2.6.13 version of the module should work up to kernel version 2.6.16.

MIRROR.2.6.13.tar.gz (2832)
MIRROR.2.6.24.tar.gz (3259)
MIRROR.2.6.25.tar.gz (2995)
MIRROR.2.6.28.tar.gz (3044)
MIRROR.2.6.31 (2856)
MIRROR.2.6.35.tar.gz (2791)
MIRROR.2.6.36.tar.gz (2876)
MIRROR.2.6.37.tar.gz (2645)
MIRROR.3.0.7.tar.gz (2348)
MIRROR.3.1.0.tar.gz (2037)
MIRROR.3.3.0.tar.gz (2065)
gplv3-127x51

regards
Jürgen

 

 

1 Star2 Stars3 Stars4 Stars5 Stars (2 votes, average: 5.00 out of 5)
Loading...

iptables mirror target for linux kernel 3.3

After my last kernel upgrade I tried to build the iptables mirror target published here. The iptables mirror target takes the packet sent to your machine and returns the same packet to the machine the packet came from. Thus, let’s say someone tries to scan your machine or tries an attack he would scan his own machine or even attack his own machine. When I tried it with kernel version 3.3 , it did not build anymore with the current linux kernel. However, this time only a minor modification has been neccesary. Another header file had to be included and a function name has changed.  You can download the newer release for kernel version 3.3 and probably future kernels here:

MIRROR.3.3.0.tar.gz (2065) gplv3-127x51

The kernel module has been tested with kernel version linux-3.3-vserver-2.3.3.1. To build the module, boot the kernel you want to use the module with. Afterwards unpack the archive and run the compile.sh script to build the module. Then run the install.sh script for installing the compiled module into the /lib/modules directory for your kernel.

Now you may use the mirror target in place of the REJECT or DROP target in the INPUT, FORWARD and PREROUTING chains, like this in your firewall script:

$IPTABLES -A INPUT -j MIRROR

Beware: The use of the mirror target may lead to strange results, in example if you want to connect to an iptables protected machine which uses the mirror target, you may end up connecting to the local machine without recognizing it. It also may use much bandwith. The worst case occurs if you have two machines using the module. These machines may end up playing ping pong. So you have been warned, use with caution and at your own risk. For more information see: MIRROR target.

Downloads for older kernel versions are below. Notice the version numbering 2.6.25 works for kernels up to 2.6.27. 2.6.28 also works for 2.6.29 and 2.6.30 kernels. The 2.6.13 version of the module should work up to kernel version 2.6.16.

MIRROR.2.6.13.tar.gz (2832)
MIRROR.2.6.24.tar.gz (3259)
MIRROR.2.6.25.tar.gz (2995)
MIRROR.2.6.28.tar.gz (3044)
MIRROR.2.6.31 (2856)
MIRROR.2.6.35.tar.gz (2791)
MIRROR.2.6.36.tar.gz (2876)
MIRROR.2.6.37.tar.gz (2645)
MIRROR.3.0.7.tar.gz (2348)
MIRROR.3.1.0.tar.gz (2037)
gplv3-127x51

regards
Jürgen

 

 

1 Star2 Stars3 Stars4 Stars5 Stars (2 votes, average: 5.00 out of 5)
Loading...

udev-182 needs CONFIG_ DEVTMPFS in kernel

After the latest upgrades on my gentoo vserver system running a 3.3.0 Linux  vserver-kernel (vserver-sources-2.3.3.1), the system did not start up properly anymore. No kernel modules got loaded and even the network devices have not been available after a reboot. This is more or less the worst case, since then one has to be physically in front of the machine and can not repair the system via ssh remote login.

The kernel upgrade was not the reason for this,  but the upgrade to udev-182. This is what the log said:

Mar 21 17:20:05 mittelerde /etc/init.d/sshd[5563]: ERROR: cannot start sshd as net.eth0 would not start
Mar 21 17:20:09 mittelerde /etc/init.d/udev-mount[6075]: Udev uses a devtmpfs mounted on /dev to manage devices.
Mar 21 17:20:09 mittelerde /etc/init.d/udev-mount[6076]: This means that CONFIG_DEVTMPFS=y is required
Mar 21 17:20:09 mittelerde /etc/init.d/udev-mount[6077]: in the kernel configuration.
Mar 21 17:20:09 mittelerde /etc/init.d/udev-mount[6067]: ERROR: udev-mount failed to start
Mar 21 17:20:09 mittelerde /etc/init.d/udev[6066]: ERROR: cannot start udev as udev-mount would not start
Mar 21 17:21:06 mittelerde /etc/init.d/net.eth0[6463]: ERROR: interface eth0 does not exist

With the information “CONFIG_DEVTMPFS=y is required” the log contains the necessary hint to get things to work. The CONFIG_DEVTMPFS option had to be enabled in the kernel. Afterwards the kernel has to be recompiled. The option can be found in menuconfig under Device Drivers-> Generic Driver options and is called Maintain a devtmpfs filesystem to mount at /dev.  For getting the devfs automatically mounted at boot time it makes sense to also enable the option Automount devtmpfs at /dev, after the kernel mounted the rootfs (CONFIG_DEVTMPFS_MOUNT).

It is safe to enable these options with older udev versions. Doing so protects your system from not working any more when you get the udev update later.

Jürgen

1 Star2 Stars3 Stars4 Stars5 Stars (2 votes, average: 5.00 out of 5)
Loading...

zen-sources-3.2 with tuxonice

Starting with the 2.6.36 kernel, tuxonice has been removed from zen-sources. The latest official tuxonice patch, that is available at present, is for the linux kernel 3.0. In the meanwhile more recent patches, for kernel version 3.2.1 and 3.2.10, have appeared at crow202.org. So I patched the zen-stable-3.2 sources with the 3.2.1 tuxonice patch from there.

Suspend to RAM works with this kernel, at least on my Dell Precison M65 and my Desktop, as well as suspend to disk does. Furthermore I can confirm, that the 3.2.1 patch also works on the x86_64 architecture.

To get things to work, download the zen-stable-3.2 kernel tree from zen-kernel.org and extract it. Afterwards download the 3.2.1 tuxonice patch from crow202.org and apply it. After applying the patch you can continue with the standard kernel building process. As with zen-sources-3.1,  no additional patch is necessary for the zcache feature, the fix is already included in zen-stable-3.2. The zcache feature doubles RAM efficiency while providing a significant performance boosts on many workloads. The zcache feature is located under staging drivers in the kernel tree and depends on the cleancache feature, which is located under processor types and features. To enable the zcache feature, you have to pass the zcache keyword to your kernel, in example in your grub.conf.

Example: kernel /bzImage panic=60 root=/dev/hda3 zcache

For Gentoo users there is a more easy way: Download my modified overlay from zen-sources-3.2.tar.gz (918) and extract it in /usr/local/portage. The overlay contains all necessary patches. Be sure to include the following line in your /etc/make.conf:

PORTDIR_OVERLAY=”/usr/local/portage”

If you want to use tuxonice include tuxonice in your USE-flags. Then emerge zen-sources and build the kernel as you like.

Tuxonice is not officially supported in current zen-sources. So If you’re using the files above, don’t report any bugs to zen-sources.org. You are on your own.

For my Precision M65 I used the following kernel config: config_zen_3.2_dell_m65.zip (925)

For more information on the zen-sources patchset see www.zen-sources.org.

best regards

Jürgen

1 Star2 Stars3 Stars4 Stars5 Stars (No Ratings Yet)
Loading...

qemu-kvm with cache=none fails on ext4 filesystem with journal_data option

Kvm has become one of the major virtualization technologies the last years. For Redhat Linux it has even become the default virtualization solution. Kvm´s IO performance is hardly competitive to other virtualization solutions when using the default options. Especially when using qcow2 images, the IO performance of kvm/qemu can be greatly improved by disabling the cache of the underlying host filesystem. This can be done by starting kvm with the cache=none option, in example with the options

-drive file=my_image.qcow2,index=0,media=disk,cache=none

instead of just supplying the image file with -hda my_image.qcow2. Then the image file is being opened using the O_DIRECT flag, bypassing the page cache. If the underlying filesystem does not support the O_DIRECT flag, this fails with the error message:

could not open disk image my_image.qcow2: Invalid argument

This is the case for an ext4 filesystem with full journaling enabled. One can easily test if the O_DIRECT flag is supported by the underlying filesystem with a simple dd command on the host:

dd if=some_file of=/dev/null iflag=direct

If the O_DIRECT flag is not supported it results in the following error:

dd: opening `some_file’: Invalid argument

Thus, if safety concerns do not apply, one does not want to use full journaling, to increase performance. The journaling options can be set either in /etc/fstab or in the filesystem itself. For the fstab case the red marked part of the following example entry has to be removed.

/dev/sda7 / ext4 defaults,noatime,nodiratime,async, data=journal 0 1

If the journaling option is set in the filesystem, this can be shown and edited with the tune2fs command. In example tune2fs -l /dev/sda7 displays information on the filesystem on /dev/sda7. If full journaling is enabled, the output contains the journal_data mount option:

Default mount options:    journal_data

The option can be removed with tune2fs -o^journal_data /dev/sda7. Afterwards the output of tune2fs -l does not contain the journal_data mount option any more:

Default mount options:    (none)

In both cases the filesystem has to be remounted to activate the changes. Afterwards qemum-kvm works with the cache=none option, as described above, and with increased IO performance.

Jürgen

References:
[1] itscblog.tamu.edu
[2] blog.nkadesign.com

 

 

 

 

1 Star2 Stars3 Stars4 Stars5 Stars (1 votes, average: 5.00 out of 5)
Loading...