Simply use the Linux traffic control tools as follows. First enter:

tc qdisc add dev eth0 root handle 1: cbq avpkt 1000 bandwidth 100mbit

Now enter the following line. This line sets the bandwidth rate; note the “256kbit”. This will limit our server to 256Kbps.

tc class add dev eth0 parent 1: classid 1:1 cbq rate 256kbit allot 1500 prio 5 bounded isolated

And lastly:

tc filter add dev eth0 parent 1: protocol ip prio 16 u32 match ip dst 0/0 flowid 1:1

For more informtation on how this works, type ‘man tc’ at your console.

View Source: http://www.potato-people.com/code/misctools/spamhausdrop.phps

Download: http://www.potato-people.com/code/misctools/spamhausdrop.tar.gz

Unfortunately, virtually everytime someone calls me and mentions “packet loss” and “MTR” in the same breath, it’s because they do not understand the output.

I’m going to assume you already know what a traceroute is, and what it does. MTR runs a traceroute over and over for infinity in order to identify possible faulty routers or links. For example, this is an mtr from my server to www.linx.net:

My traceroute  [v0.72]
mashed (0.0.0.0)                                       Mon Sep  8 10:14:13 2008
Keys:  Help   Display mode   Restart statistics   Order of fields   quit
Packets               Pings
Host                                Loss%   Snt   Last   Avg  Best  Wrst StDev
1. gw0.potato-people.com             0.0%    11    0.6   1.0   0.5   1.4   0.4
2. gi0-3.br1.heron.bytel.net.uk      0.0%    11   98.8  13.9   0.5  98.8  31.1
3. vlan1.br0.heron.bytel.net.uk      0.0%    11    2.3   1.9   1.0   2.6   0.5
4. collector.linx.net                0.0%    10   19.6  18.4  17.3  20.0   1.0
5. pink.linx.net                     0.0%    10   18.5  18.1  17.2  19.3   0.7

Pretty simple - each hop is identified, and then MTR repeats this (note the “Snt”, or sent packets column) and records the loss and latencies.

Packet Loss

If we saw a sudden jump to 50% loss at hop 3 and beyond, then we know there is a problem between hops 2 and 3, or at 3 itself. Eg:

My traceroute  [v0.72]
mashed (0.0.0.0)                                       Mon Sep  8 10:14:13 2008
Keys:  Help   Display mode   Restart statistics   Order of fields   quit
Packets               Pings
Host                                Loss%   Snt   Last   Avg  Best  Wrst StDev
1. gw0.potato-people.com             0.0%    11    0.6   1.0   0.5   1.4   0.4
2. gi0-3.br1.heron.bytel.net.uk      0.0%    11   98.8  13.9   0.5  98.8  31.1
3. vlan1.br0.heron.bytel.net.uk     50.0%    11    2.3   1.9   1.0   2.6   0.5
4. collector.linx.net               50.0%    10   19.6  18.4  17.3  20.0   1.0
5. pink.linx.net                    50.0%    10   18.5  18.1  17.2  19.3   0.7

Measuring Routers

Unfortuantely what I more often than not see, is something like this:

My traceroute  [v0.72]
mashed (0.0.0.0)                                       Mon Sep  8 10:14:13 2008
Keys:  Help   Display mode   Restart statistics   Order of fields   quit
Packets               Pings
Host                                Loss%   Snt   Last   Avg  Best  Wrst StDev
1. gw0.potato-people.com             0.0%    11    0.6   1.0   0.5   1.4   0.4
2. gi0-3.br1.heron.bytel.net.uk      9.0%    11   98.8  13.9   0.5  98.8  31.1
3. vlan1.br0.heron.bytel.net.uk      3.0%    11    2.3   1.9   1.0   2.6   0.5
4. collector.linx.net                0.0%    10   19.6  18.4  17.3  20.0   1.0
5. pink.linx.net                     0.0%    10   18.5  18.1  17.2  19.3   0.7

This example shows lost packets at hops 2 and 3 but - and here’s the important part - not beyond hops 2 or 3. In this case, the MTR is measuring the CPU load of the router at those hops, not the packet loss on the connection. Check hop 5 - no packets have been dropped at the actual destination.

You see, nearly all routers, much like computers, have a list of priorities of things they have to deal with. Forwarding packets between ports is the highest priority. Things such as routing protocols come second, the management interface (whether it be by web, telnet or serial console) come second. Responding to packets sent directly to the router comes long after everything else.

So, if a router is paticularly busy and has a lot of packets to forward, it’ll drop the lowest priority things to get a few more CPU cycles. This means the first thing to get dropped from it’s list of things to do, when under stress, is responding to packets sent directly to the router.

ICMP is lossy

Ping, traceroute and MTR all use the ICMP protocol, and ICMP is very, very lossy. That means that packets will and should be expected to drop. In the example below, we can see a level of packet loss across all hops. However, check the “Snt” column - this MTR has been running for some time, and sent over 1400 packets to each hop. This MTR measures nothing more than the lossy nature of ICMP over a long time period. Pure background noise.

My traceroute  [v0.72]
mashed (0.0.0.0)                                       Mon Sep  8 10:38:03 2008
Keys:  Help   Display mode   Restart statistics   Order of fields   quit
Packets               Pings
Host                                Loss%   Snt   Last   Avg  Best  Wrst StDev
1. gw0.potato-people.com             0.8%  1439    2.6   1.0   0.5  12.0   1.1
2. gi0-3.br1.heron.bytel.net.uk      1.4%  1439    1.1   4.3   0.3 217.2  21.5
3. vlan1.br0.heron.bytel.net.uk      1.3%  1438    1.6   6.0   0.6 208.5  24.2
4. collector.linx.net                1.3%  1438   18.3  27.5  16.2 395.3  36.0
5. pink.linx.net                     1.5%  1438   18.9  18.3  16.2  27.9   1.0

Turning off ICMP

It’s for these very reasons that an increasing number of ISPs are disabling the ability to do traceroutes across their network. It used to be that this was done for security - it’s much harder to hack into someone’s network if you do not know the addresses of any of the routers or switches - but now it’s done for a combination of security and to stop calls from customers who don’t know how to interpret the results of a tool that, for example, some VoIP company said they should run.

Dunluce Castle, Inner Courtyard

Carrick-a-rede Rope Bridge

Dunluce Castle, Entryway

Dunluce Castle, Entryway Parapet

Dunseverick Castle

Coastline West of Dunluce Castle

Coastline East of Dunluce Castle

White Bay, County Antrim

• When measuring bandwidth, attempt to use a site or tool that is close to your ISP. If you’re in the UK and you try to test your connection using a site hosted in the US it’s never going to give you a decent idea of your speed. I recommend Speedtest.net, as it’s a single tool that can test to a multitude of different locations and will give you a much better idea of exactly how your line is performing.
• Remember to allow around 10% for overheads. An 8Mb ADSL line will top out at 7.2Mbps. This is due to overheads for the ADSL line itself: a certain amount of bandwidth is required to manage your packets that will not be visible on any web-based bandwidth test.
• Any download requires a certain amount of packets to be sent in the opposite direction. Usually these are acknowledgement packets to assure the server you are downloading from that everything is being received okay (or not, as the case may be). Again, that magic 10% figure is the one to watch out for. A 1Mbps download will roughly need a 100Kbps upload. If you are using up all your upload bandwidth, your download bandwidth will be poor.

DISCLAIMER: I am not a solicitor.

The US DMCA act allows a copyright holder to issue what is commonly known as a DMCA takedown notice. In some cases, such as MediaSentry, they’ll even try to insist that you completely disconnect the user.

Unfortunately (or fortunately) the US DMCA act cannot be enforced in the UK. So the actual notice and demand is completely invalid. Does that mean you can ignore it? No. The US company could still pursue damages in a US court and most likely win. Once they have a judgement against you, they could then bring it to the UK - and as an ISP, you don’t want that to happen.

I handle it by contacting the user directly, informing them that we have a alleged copyright infringement against them and that the need to cease and desist using any Bittorrent, Limewire, eDonkey or whatever their flavour of Peer-2-Peer software is. After that, the response I send to the copyright holder is as follows:

Please note that we are a UK company and under UK law the DMCA act does not have a equivelent provision. However, in the intrests of protecting your represented copyright holder we have acted upon this notice and the user identified by IP address xx.xx.xx.xx has been reprimanded.

Under section 35 of the UK Data Protection Act of 1998, we cannot provide any additional information unless presented with a certified UK court order.

This fulfills two things: It informs the US company that you can’t apply US law to a UK company. Secondly, it shows that you’re still willing to comply and help out to the best of your ability. Section 35 of the UK Data Protection Act is real, and states that you cannot give information about your customers to a third party with a court order (or subpeona, for those in the US).

Example DMCA Takedown Notice

abuse@xxxxxxx.uk

Sunday, June 01, 2008
[company]
[address]

RE: Unauthorized Distribution of the following media:
XXXXXXXX

Dear Abuse Department:

We are writing this letter on behalf of XXXXXX. No one is authorized to perform, exhibit, reproduce, transmit, or otherwise distribute the above-mentioned work without the express written permission of the copyright owner, permission which has not been granted to XX.XX.XX.XX.

We have received information that an individual has utilized the above-referenced IP address at the noted date and time to offer downloads of the above-mentioned work through a “peer-to-peer” service. The included documentation specifies the location on your network where the infringement occurred, as well as any other available identifying information. The distribution of unauthorized copies of copyrighted media constitutes copyright infringement under the Copyright Act, Title 17 United States Code Section 106(3). This conduct may also violate the laws of other countries, international law, and/or treaty obligations.

Since you own this IP address, we request that you immediately do the following:

1) Disable access to the individual who has engaged in the conduct described above; and
2) Terminate any and all accounts that this individual has through you.

On behalf of XXXXXX, the owner of the exclusive rights to the copyrighted material at issue in this notice, we hereby state, pursuant to the Digital Millennium Copyright Act, Title 17 United States Code Section 512, that we have a good faith belief that use of the material in the manner complained of is not authorized by the copyright owner, its respective agents, or the law. Also pursuant to the Digital Millennium Copyright Act, we hereby state that we believe the information in this notification is accurate, and, under penalty of perjury, that we are authorized to act on behalf of the owner of the exclusive rights being infringed as set forth in this notification.

Please contact us at the above listed address or by replying to this email should you have any questions. We appreciate your assistance and thank you for your cooperation in this matter. In your future correspondence with us, please refer to Case ID XXXXXXXXX. Your prompt response is requested.

Respectfully,

XXXXXXXX
SafeNet Enfocement Coordinator

Data is traditionally measured in Bytes. A CD contains 650MBytes of data. Bandwidth is measured in bits however, and this is what most customers misunderstand. A CD measured in terms of bandwidth, is 5,200Mbits (there are 8 bits per byte). Note that in writing, you use a capital ‘B’ to denote Bytes, and a lower-case ‘b’ to denote bits.

The issue is that bandwidth is traditionally measured in bits, not bytes. A 1Mbit circuit lets you download at 100KBytes/second. A lot of people make the mistake of thinking that a 1Mbit circuit is the same as downloading at 1MBytes/second.

This becomes a problem when a customer - as has happened today - complains of a slow speed problem. The systems (which I built and maintain) show this customer as downloading up to 32Gbits per day. They dispute this via the phone, proclaiming that they only downloaded “4 gig” (in a 5 hour window, I’ll add). If you do the math: 4*8 = 32. 32Gbits. On a standard ADSL line, that’s a crazy amount of usage - averaging around 1.8Mbit/s for that 5 hour window. During peak hours, an ADSL Max line (due to contention) may only be able to achieve 2Mb/s. It’s a classic case of someone mistaking Bytes for bits… of course, explaining that to them is another matter.

Click through for a demo video of the progress so far…

However, there is a poorly documented hidden “half-bridge” mode in the ZyXEL 660R routers. These cheap little single-port routers have the ability to push the public IP address and all it’s traffic onto a single device connected to the LAN port.

To do this, set the router up as normal with the username and password for your connection, then logout from the web interface. You’ll now need to telnet to the device, and enter the following:

poe bridge switch on
ip dhcp enif0 server lease 120
sys save

After this, reboot the router. Once it boots up and logs into your ISP, you should find that it gives you a single IP address on DHCP and that address will be an external fully public IP address.

Update: IntoTheUnknown uses this to build a SIP VoIP system, which of course can have problems when passing through any firewall or NAT conversion.

But what if they couldn’t execute it?

This is an easy way to beef up your webserver server security a little. Create a 1GB partition on your system, and in your fstab file, add a “noexec flag” like so:

/dev/sda3 /tmp ext3 acl,user_xattr,noexec 1 1

Now, the system will prevent any executable in /tmp from being executed and thus sealing off the most common flaw that allows for most automated attacks to work.

No unallocated space on your disk and don’t want to risk resizing? Use a loopback filesystem.

/dev/loop0 /tmp ext3 acl,user_xattr,noexec 1 1