Slashdot Mirror

Just run the speed test against another node in another country or state. That would indicate if the ISP is slowing down explicit traffic or not. Even better to run a bandwidth test with a less common service than Speedtest. Like http://www.bredbandskollen.se/ (You can switch from Swedish to English on that page). Just be aware that the further away the server is the more likely you'd get bad figures since you have to share the channel with others.

Also try to locate the speed test servers on the same net as the service you like to access, that can also give you a good indication if it's throttling or just shitty network.

On YouTube you also can right-click on the video and select "Stats for nerds" to see the connection speed as well as dropped frames.

Tools like traceroute (in Windows tracert) and ping are your friends. hrping is an alternative to ping.

Also see more test variants here: https://www.digitaltrends.com/...

If you can - also look at if there are ping responses from the net using wireshark. Look for source quench messages. However those are usually presented to the streaming service and not to the client unless you do an upload of data.

A ping is an ICMP echo request.

Give me a ping, Vasili. One ping only, please.

A ping is an ICMP echo request.

Thanks for the 411 Rain Man. :-)

The evidence we're given is this:

"What the researcher saw "was a bank in Moscow that kept irregularly pinging a server registered to the Trump Organization on Fifth Avenue": "

A ping is an ICMP echo request. They can have data, but it's the same both ways and it's generally nothing meaningful. I get random pings and crap from everywhere, including Russia, China, etc. along with port scans and everything else. Frankly this is utter BS without more evidence than a random server responding to some pings and not others.

It's also not clear how they were able to spy on this traffic without working at an ISP (where spying on your customers is generally frowned upon). But if they were in the middle of this, they could simply have inserted their own pings by spoofing the source address of some traffic. The article was a sad waste of time. There are lots of allegations that are based on nothing at all.

I concur with the AC above me who justifies most of those, but I'll add my own opinions as well.

Mission creep. Your init system now has a logon shell, and handles DHCPD tasks. Why is init handling logons and dhcpds?

...Because it should. When the system's done initializing, I want a logon shell available. If something fails, I want a shell as a fallback. I also have a particular application where I need authentication before allowing the system to begin its automatic operations, but after certain services have started. Maybe this will help that, but I haven't explored the design enough to know.

As for DHCP, it's about time. DHCP has been a part of initrd and init scripts for many years, often with lots of implementation-specific bugs. It stems from Unix's history as an OS predating networks, and now DHCP is an add-on to most systems, where it was designed to be a central configuration mechanism (including options for pushing NTP, IRC, LDAP, and even time zone information from the server). By coincidence, a lot of my academic research and professional work involves centralized self-configuring systems, so seeing hope for DHCP is actually a very good thing, by my standards. I'd love to see computers stop duplicating configuration settings.

Binary log files (PUKE)

...which are really the first step towards a proper database holding log files, which I'd also love to see someday. Windows has its event service, which uses binary logs to fairly good effect, though it can get very slow for sorting and searching. A proper database is much better for that sort of thing, but I digress. As I understand, the binary format is trying to avoid being a full database, while still supporting filtering. It also seems to do a fairly decent job of separating user and system logs, and would allow filtering a single service or seeing the whole system's logs, without the current hassle of dealing with applications that don't properly declare who they are when logging.

Extremely poor documentation

This seems pretty subjective to me, so you'll need to do better for a complaint. When I've had to look up systemd documentation, it's been no worse (or much better) than any other GNU/Linux documentation.

Rushed to market with little objective testing

What, exactly, is "objective" testing for a completely different software architecture? The software managers I work with have been debating the essence of that question for the past few decades. That said, it's been out for five years. It is in active use, and working well enough for all normal purposes.

Bugs pile up with no resolution in sight, they just keep going for another dameon.

...So it's like any other software project? New development is usually the priority once something works well enough. I'll also note that within the last month, 60 bug reports have been closed on systemd's github tracker, and only 44 opened. The oldest bug is from June.

And then when you ask a fan of it why they like it, the response is "My system boots faster."

How about instead you tell me why systemd is so much better then everything we had before? And no cheating you dont reboot servers typically so boot time is meaningless.

No, you don't reboot servers, so your boot time is meaningless, but you have no justification to project that onto me. I actually work on a system with a requirement to cold-start the entire site in 15 minutes, from turning on the circuit breaker to being 100% ready for operation. My boot time is very meaningful.

Sure.

The classic paper every programmer (IMHO) should read is one by Danny Cohen who introduced the terms big-endian and little-endian is:
    ON HOLY WARS AND A PLEA FOR PEACE
http://www.networksorcery.com/enp/ien/ien137.txt

Here is a "abridged" summary:

Like most things, there are 2 (diametrically opposing) way of doing things. You can do it either A xor B; that is A, or B but not both. Neither is right; they are just (competing) standards. Oblg. http://xkcd.com/927/

Agin, neither is technically "right" - they both are; we may chose one or the other *simply* for convenience. As long as we pick one standard, and are consistent in our use, everything works. The problem arises when somebody picks a different "standard" and we need to interface with them. (i.e. share data.) :-)

Here is practical example that shows up all the time in computer graphics. Let's say we wish to define the world coordinate system. To the right we can call that positive X, we can call up positive Y, and for stuff off in the distance we have a choice:
a) call positive Z for things further away from us, (DirectX uses this) OR
b) call negative Zfor things further away from us (OpenGL uses this.)

Getting back to the function originally mentioned:

When we have the integer number 0x12345678 in a CPU register how the bytes are stored in memory / disk / "network" can be done either in:
a) Little Endian format:
i.e.
    unsigned char LE[] = { 0x78, 0x56, 0x34, 0x12 };
or
b) Big Endian format:
i.e.
  unsigned char BE[] = { 0x12, 0x34, 0x56, 0x78 };

How did this come about? Notice that we write bits from right-to-left
    bit31 bit30 ... bit 3 bit2 bit1 bit0
the same as we write the Aramaic numbers. Now which bit should we send first over a wire? bit31 or bit0? The hardware guys wanted it one way (because they could use a simple barrel shifter/latch), the software guys wanted it the opposite way.

Let's say you have this number stored on disk that was generated by a program running on a little endian CPU. If you have a big endian CPU try to naively read this data it will interpret it as the wrong value.
i.e.
  Little endian 0x12345678 (305,419,896) on disk is: 0x78563412
  Big endian will interpret it as: 0x78563412 (2,018,915,346)

Hence you need to "fix up" the bytes, that is byte swap them. The CPU instructions of shift-and-mask is the standard way to shuffle bits around.

It helps to label all 32 bits with unique names:
    ABCDEFGH IJKLMNOP QRSTUVWY abcdefgh

We want a function that, given the above, will generate this:
  abcdefgh QRSTUVWY IJKLMNOP ABCDEFGH

Or expressed in bytes:
    b3 b2 b1 b0
We want:
  b0 b1 b2 b3

Notice that the hex mask 0xFF (called a "byte mask") is a way to treat 8 consecutive bits (one byte) as one "logical number".

By inspection:
  b0 should be shifted Left 24 bits
  b1 should be shifted Left 8 bits
  b2 should be shifted Right 8 bits
  b3 should be shifted Right 24 bits

When you are talking about numbers in base 16, the idiom << 8 of shifting the bits by one byte, or multiplying by 256, is equivalent to a multiplying a decimal number by 10 because we want to shift all the digits over to make room for another "tens" unit place.
i.e.
  0x12 8 = 12 times 2^8 = 12 times 256 = 0x1200
  12 * 10 = 120

Does that answer your question sufficiently?

Just in case anyone wants more info:
http://www.networksorcery.com/enp/protocol/udp.htm
http://www.networksorcery.com/enp/protocol/tcp.htm

Just in case anyone wants more info:
http://www.networksorcery.com/enp/protocol/udp.htm
http://www.networksorcery.com/enp/protocol/tcp.htm

Without delving into it too much and providing an easy link to find:
Wikipedia is one:
http://en.wikipedia.org/wiki/Measuring_network_throughput

When you look into the overhead (especially if encrypted traffic is involved) that is involved with typical network routing, you aren't talking anymore about the specific data that you are transferring and how it can vary (padding etc). How do you get an accurate representation of how much data that can be pushed through a link? This is why they talk bits per second, it is the smallest common denominator.

Hell, looking at the IP protocol, it never once mentions Bytes
http://www.networksorcery.com/enp/protocol/ip.htm

You can use SRTP. It's been available in many VoIP implementations for years. For lawful interception, the call controller (cisco call manager or such) usually holds the key to the stream, but if you're in control of both ends and the controller, you're safe.

He passed the rights to Melbourne IT, again for free, knowing they were worth a fortune. Melbourne IT went to be become a $100 million company.

I was lucky to have Paul Mockapetris as a professor in the early 80's before the widespread use of networks (UUCP was hot stuff at that point in time.)

One of the things I remember most, was his acronym for the OSI model: "All Professors Should Teach Networking Like Paul" so your could remember this. Of course, a lot has changed since then, but I was lucky to get a head start on it all -- thanks Paul!

Another cool thing about this class was that Marshall Rose was a fellow student. He's written a few RFCs since then.

-ch

Something smells and for once its not me. Here are some articles by the person that is supposed to have written this.

David Mankins tells a story about a German tourist who needed to buy dinner and only had 50 marks. He explained that he only had $5, and that the exchange would be unfair to the tourists. They needed to eat, though, and so he exchanged it.

Turned out it was a *Weimar* note (you know, German Hyperinflation during the 20's)

> If they reduce their reliance on foreign IP (or non-free foreign IP) [...]

"Intellectual Property" is a contradiction in terms.
the intellect deals with ideas and ideas cannot be anyone's property.

Unless you meant this IP.

Does BITTORRENT functionality finally let Mozilla support the evil bit?

1) let's clean up ftp. real security options, performance options, etc.

i really believe that a little key management at the isp level (if enough isp participated) could really make a difference.

3) dns. i would drop .com, .org, maybe even .edu and .net. use the ccTLD with other localizations below that.

4) more ip addresses. ip6 would be nice, but if i'm starting over from scratch, just increasing the ip address from 32 to 48 or to 64 would help.

5) the ability to do a number of things in a slow, throttled-back fashion to run nicely in the background.

6) better printing protocols. lpd is a mess and the other printing protocols seem to problematic.

7) snmp. this seems to be getting better via v3. the real problem seems to be the software, not the protocol.

Lots of server protocols prevent attacks by requesting a cookie before they do anything difficult or resource-consuming. Besides security, that's useful for basic reliability - it makes sure the IP routes are all working, the client can reach the server, the server's working, and the server can reach the client, before either side does any real work. Most exceptions to this are simple protocols like DNS that don't require any state or much work and would do more work building the connection than sending the real data, and things like NFS which have some reason for the client to trust the server's availability before sending big packets and which make sure that retries with the same data are ok.

Some of the crypto protocols, such as Photuris, do a cookie handshake first, because the first "real" step of the protocol comsumes lots of server CPU, and they'd be vulnerable to denial-of-service attacks otherwise. In this case, the attack is a forged-request attack on an unsuspecting client, but the server is still the only one that can provide any protection. Either way, the client firsts requests a cookie from the server, and the requests for real work need to include the cookie, or the cookie modified in a way that clearly indicates it was received.

A variation on cookies is to make the client perform non-trivial amounts of work using the cookie, which the server can verify quickly - this lets the server limit the rate of requests, and means an successful attacker needs lots more resources than the server. Hashcash is the canonical one - the client has to use brute-force search to find a string containing the cookie that has a hash value starting with a specified N bits, and the server can verify the hash quickly. This defense can be made stronger by including the sender's identification and a timestamp in the cookie string, making it harder to replay. While it's not possible to tune hashcash CPU consumption precisely (since different machines are different speeds, and the attacker may have a Beowulf cluster of Crays or a bunch of zombies to do calculations), the server can adjust the rate of requests by adjusting the hash length as needed. In addition to fullscale cookie-based hashcash, it's sometimes adequate to do a simple userid-and-timestamp version, or userid-and-counter, so the attacker has to do some work, e.g. burn a second of CPU time for every 2KB of response for a modem user, or 10KB for an online user, to prevent swamping.

In this environment, though, anything that requires client upgrades won't fly; you're stuck with upgrades to servers (tough enough) and handshakes that use the existing user interface.
Modifying the server to limit the number of responses per second for a given client (or of big responses) is probably a good start - it doesn't solve all the problems, and the attacker may be able to forge a stream of requests that prevents the victim from doing legitimate queries, but it protects the network connections. Another approach would be to do something password-like - the user queries for a password, or chooses a password, and has to use it to get any big queries, or more than N big queries.

look at it here.

Working link to RFC 3271. (Since the original seems Slashdotted.)