pitter patter on the keyboard

If you encounter this error while compiling a newer kernel:

  CC      init/calibrate.o
  LD      init/built-in.o
  HOSTCC  usr/gen_init_cpio
  /usr/src/linux-3.2.12-gentoo/scripts/gen_initramfs_list.sh: Cannot open '/usr/share/v86d/initramfs'
make[1]: *** [usr/initramfs_data.cpio] Error 1
make: *** [usr] Error 2

Emerge v86d:

# emerge v86d

Credit due: big my secret: Problem of make kernel about v86d initramfs

UPDATE CoreNetworks.net has responded and reacted to my criticisms below. Please read the comments on this article to see our exchange.

It has been 30 days since I first told you about CoreNetworks’ unfortunate bandwidth test file placement, which they have still not bothered to correct. Against my better judgement I decided to give them a second chance this morning when, upon configuring my order for 100mbit/s port (+$10) and 3300GB (+$55) add-on I was surprised with this error:

NOTICE: You cannot select 3300 GB transfer and 100Mbps transfer. Your selection has been updated.

Well, why not? That doesn’t seem to make much sense. Since they called the 100 meg port “transfer” and the amount of bandwidth “transfer” as well I assumed some dolt that didn’t know what he was doing was behind this glitch in the order process. So I called.

“3300GB is by definition an unlimited 10mbps port”

In the same breath their rep told me:

• I couldn’t get more than the 2000GB package plus per-GB overages on 100mbit/s despite the fact that they could “technically” give 3300GB to 10mbps port users
  • I guess we are to assume their network is so poorly constructed the extra TB at 100mbit/s would crush them
• If you went with the 10mbps port and the $55 1.3T add-on (3300GB package) the only way to get your money’s worth would be to saturate the connection 100%, 24/7, all month long.
• If 3300GB is synonymous with an unlimited 10mbps port we’re working in terms of egress traffic only

Let’s verify the math to make sure I’m not jumping to any conclusions:

Seconds in a month: 2629743.83
Bits in 3300GB: 28346784153600
Bits per second: 10779294.9
Mbits per second: 10.2799367 (binary) 10.7792949 (decimal)

The fact is no matter how you slice your megabits they are selling you more transit than you can possibly use on a 10mbit/s port. Even if we start with a decimal gigabyte you would have to transmit at 39Kbit/s faster than your port speed all month long just to reach your quota.

It’s not just false advertising. It’s a scam.

Made worse by the fact that their FAQ misconstrues the truth:

What type of connection will I have?
This depends on the type of connection you choose. All servers are connected to 10Mbps switch ports (100Mbps ports are available for certain plans). You are able to select flat-rate capped bandwidth on a per-Mbps basis, or you could opt for burstable metered bandwidth. We make both options available to help you find exactly what you’re looking for. You can upgrade from a 10Mbps port to a 100Mbps port for an added $10/month. This does not change your allowed data transfer amount, and care should be taken to avoid unexpected overages if you decide on this option.

It’s also interesting to note that “flat-rate capped bandwidth on a per-Mbps basis” no longer seems to be available (it was when I was with them aeons ago).

Despite all the nice things I’ve said about their support, their level of sloppiness and shadiness makes CoreNetworks.net inadequate for serious hosting.

You may find yourself in a position where it is necessary to remove all the entries in Netfilter’s connection tracking table (ip_conntrack) for a particular criterion, like the source or destination IP.

For example, I recently detected a user on one of my networks engaged in what was likely a TCP denial of service attack against root name servers (despite the odd fact that the destination port was 80). Being a NATted user, all of their connections were being tracked. The default time-out for tracking an established connection being 5 days, simply disconnecting the user at the second layer would not relieve the congestion on my routers within an acceptable time frame.

#  cat /proc/sys/net/ipv4/netfilter/ip_conntrack_count
98636

#  cat /proc/net/ip_conntrack | grep "xxx.xxx.xxx.xxx"
tcp      6 416408 ESTABLISHED src=xxx.xxx.xxx.xxx dst=192.168.5.147 sport=58967 dport=80 packets=1 bytes=40 [UNREPLIED] src=192.168.5.147 dst=yyy.yyy.yyy.yyy sport=80 dport=58967 packets=0 bytes=0 mark=0 secmark=0 use=1
tcp      6 416406 ESTABLISHED src=xxx.xxx.xxx.xxx dst=192.168.9.239 sport=58967 dport=80 packets=1 bytes=40 [UNREPLIED] src=192.168.9.239 dst=yyy.yyy.yyy.yyy sport=80 dport=58967 packets=0 bytes=0 mark=0 secmark=0 use=1
tcp      6 416400 ESTABLISHED src=xxx.xxx.xxx.xxx dst=192.168.11.231 sport=58968 dport=80 packets=1 bytes=40 [UNREPLIED] src=192.168.11.231 dst=yyy.yyy.yyy.yyy sport=80 dport=58968 packets=0 bytes=0 mark=0 secmark=0 use=1
tcp      6 416387 ESTABLISHED src=xxx.xxx.xxx.xxx dst=192.168.14.37 sport=58968 dport=80 packets=1 bytes=40 [UNREPLIED] src=192.168.14.37 dst=yyy.yyy.yyy.yyy sport=80 dport=58968 packets=0 bytes=0 mark=0 secmark=0 use=1
tcp      6 416381 ESTABLISHED src=xxx.xxx.xxx.xxx dst=192.168.11.103 sport=58968 dport=80 packets=1 bytes=40 [UNREPLIED] src=192.168.11.103 dst=yyy.yyy.yyy.yyy sport=80 dport=58968 packets=0 bytes=0 mark=0 secmark=0 use=1
tcp      6 416275 ESTABLISHED src=xxx.xxx.xxx.xxx dst=192.168.9.57 sport=58967 dport=80 packets=1 bytes=40 [UNREPLIED] src=192.168.9.57 dst=yyy.yyy.yyy.yyy sport=80 dport=58967 packets=0 bytes=0 mark=0 secmark=0 use=1
tcp      6 415776 ESTABLISHED src=xxx.xxx.xxx.xxx dst=192.168.1.52 sport=58967 dport=80 packets=1 bytes=40 [UNREPLIED] src=192.168.1.52 dst=yyy.yyy.yyy.yyy sport=80 dport=58967 packets=0 bytes=0 mark=0 secmark=0 use=1
tcp      6 417319 ESTABLISHED src=xxx.xxx.xxx.xxx dst=192.168.43.60 sport=58967 dport=80 packets=1 bytes=40 [UNREPLIED] src=192.168.43.60 dst=yyy.yyy.yyy.yyy sport=80 dport=58967 packets=0 bytes=0 mark=0 secmark=0 use=1
tcp      6 417319 ESTABLISHED src=xxx.xxx.xxx.xxx dst=192.168.43.13 sport=58968 dport=80 packets=1 bytes=40 [UNREPLIED] src=192.168.43.13 dst=yyy.yyy.yyy.yyy sport=80 dport=58968 packets=0 bytes=0 mark=0 secmark=0 use=1

...

It is possible to clear tracking entries en masse by removing then reloading the iptables rule that requires them to be tracked in the first place, but on a production gateway this is even less acceptable than waiting for them to expire. Fortunately, we can interact with the ip_conntrack table via conntrack-tools.

Against common sense, conntrack-tools is not available in the repositories for (at least version 5.2) of ClearOS, my favourite router distro. I grabbed a couple recent versions in RPM form but they didn’t feel like playing ball so I ended up with version 0.9.5 from ftp://ftp.pbone.net/mirror/archive.fedoraproject.org/fedora/linux/updates/8/i386.newkey/conntrack-tools-0.9.5-3.fc8.i386.rpm

Apparently newer versions allow one to use -D intuitively, i.e.:

# conntrack -D -s xxx.xxx.xxx.xxx

But this is not the case for at least versions including and prior to 0.97 – these require the d, dport, s and sport flags.

This wonderful person provides a way to pipe the output of conntrack -L (which lists entries the way I’d like to delete them, i.e. -s only) into sed which then breaks the output lines up and awk runs them with conntrack -D appropriately. I had to do some cleanup to get it to work due to the way their blog software mangles punctuation (a lot of my first posts here are mangled in the same way – pobody’s nerfect!):

 conntrack -L -s xxx.xxx.xxx.xxx | sed 's/=/ /g'| awk '{system("conntrack -D -s "$6" -d "$8" -p "$1" --sport="$10" --dport="$12)}'

It should be pretty clear how conntrack -L -s can be modified to work with the destination address or more complicated pattern matching.

Now we can see the ip_conntrack table is at a more reasonable level:

[root@router ~]#  cat /proc/sys/net/ipv4/netfilter/ip_conntrack_count
46676