Oliver Herms

Have you ever tried doing webdevelopment on your Linux desktop with enabled SELinux? Then you problably saw this on opening your webapp: "Internal Server Error 500" and /var/log/httpd/error.log just telling you

Today someone on #denog on IRCnet asked into the channel why his 10GE interfaces are going down and coming back up when he enables IP forwarding on his Linux machines. I grepped through the kernel sources and found the reason:

When /proc/sys/net/ipv4/ip_forward is changed the kernel calls a function called inet_forward_change() in file net/ipv4/devinet.c. This function essentially does what we expect from it: Enable IP forwarding. But it does even more: On line 1933 (version 3.12.7) is a loop over all network devices which disable large receive offload (LRO) for all devices. This leads to a reload of the driver which triggers the interface to go down and up.

So if you don't want your interfaces to go down when enabling IP forwarding just disable LRO on boot.

I've just released a handy tool for network admins:Recursorscanner. It scans netblocks for open DNS recursors. Nothing more.There is good reason to find and restrict open DNS recursors on your network...

Today I've release a new version of AntiRootKit (ARK).The new version is now 0.7. However: The only thing changed is that opening of /dev/mem and /dev/kmem is now not being circumvented by comparing filenames, but by using device numbers.

I would be very pleased to get some feedbock on the idea of AntiRootKit.

But now imagine the case that the webserver behind the proxy delivers HTML content with absolute URLs.It is very likely that thoase absolute URLs will not work in the outside world.The solution is to rewrite the links in the HTML content forwarded by the proxy.

mod_proxy_html implements this functionality.Version 3.0 is included in the Debian 6.0 distribution.

Yesterday I've moved an internet connection from an existing GRE-Tunnel to an IP-IP tunnel.A Customer called and complained that he could not reach several websites, e.g. www.bundestag.de and www.bahn.de.

A ping to bundestag.de failed because they are blocking ICMP Type 8 Code 0. A ping to bahn.de was successful. So I tried to reach those websites from behind the tunnel: I saw that I don't see anything.

What happened?The MTU of the new tunnel was 1480 bytes (1500 bytes - 20 bytes for outter IP header, the old tunnel had a much larger MTU). Those webservers are setting the "Don't Fragment" (DF) bit in the IP header, telling our router not to fragment those packets.Instead our router generates an "ICMP destination unreachable (fragmentation needed, df set)" to the sender to inform him that he has to send smaller packets, so packets fit the MTU.

At the moment I am discovering a bug in the Linux Kernel.The scenario is as follows:

There is a router using virtual interfaces (e.g. VLANs) eth1.100 and eth1.200.Those interfaces share a MAC address. In IPv6 there are so called "link-local" addresses.These addresses are build from an static prefix + the MAC address.

On the router runs Quagga with its ospf6d (doing OSPFv3) configured with eth1.100 and eth1.200 in area 0. Quagga starts to send OSPF hello packets on both links. On eth1.100 it sends the packets with an interface ID of 4. On eth1.200 is sends the packets with an interface ID of 5.

As I've discovered in the Quagga source code, the packets are bound to an interface by using the struct in6_addr with its property sin6_scope_id.

So far, everything is ok.

When I now activate IPsec in transport mode with AH only (have not tested other setups yet) for protocol 89 (ospf) all OSPF packets have an AH added. But: The packets seem to loose their associated interfaces and are being sent on all interfaces. The problem reside somewhere in the XFRM stack of the Linux Kernel.

UPDATE:

In the mean time I found out that1. the problem does not exist in kernel version 3.4 but in 2.6.322. the problem resides in net/xfrm/xfrm_policy.c in the __xfrm_policy function where it calls xfrm_find_bundle(fl, policy, family).

xfrm_find_bundle returns a struct dst_entry. dst_entry is a linkes list and the last element is being used for routing. xfrm_find_bundle gets the fl parameter where fl.oif is the number of the outgoing interface that should be used. However that interfaces seems to be ignored in some cases, so the dev structure in dst_entry does not equal the fl.oif interface.

I don't think I'll invest more energy on this bug as it does not exist in 3.4 anymore. However, here is a hotfix for the problem (in case you have this problem and can not easily upgrade your kernel):