In other news, given physical access a user can get root access to a Linux box. To accomplish this, the user renames/bin/sh to/sbin/init â" this is the program that makes sure that anything ever gets done on a Unix system. The person who discovered this security hole claims that XP, 2000, 2003 and NT are not vulnerable to it; only Unix-like systems are.
I considered Mara for our authoritative name server, then decided it has two significant limitations:
its support for IPv6 was nonexistent at the time, and is still very much limited;
it uses a non-standard format for zone files, which means that you cannot test it conveniently before comitting to switch.
The name server is the one place where you want to deploy IPv6 support as early as possible, since it will be needed as soon as you have a single IPv6 server. As to the zone file format, while RFC 1035 format is not the best format around, it's at least standard and mostly transportable between servers.
Would one of you kind folks please put this into non-kernel-programmer terms that explain what this does for software/hardware in terms of the user experience and how the proposed outcomes will affect said experience?
They're trying to make your mouse pointer move smoothly, your audio never skip, your FPS game never miss a beat and your Linux-driven coffee machine never burn a bean, even when there is some process opening a random device in the background.
If they want to blow me up, they're going to do it by setting up a bomb that reacts to the RFID in my "Real ID" card,
It doesn't harm to repeat this once again. I believe it's Bruce Schneier who came up with the line that fortunately for us the terrorists are stupid; if they weren't, they'd build a bomb that detonates when there are five American passports in range.
By mandating that we have RFID chips in our passports, our authorities are not only violating our civil liberties; they're actually risking our lives.
How does babel fix this? It seems like babel is just a routing mechanism, does it modify the MAC as well? This problem arises because of channel reservation messages & collisions, so not modifying the MAC is going to give limited improvement.
In case you didn't get the joke -- please mod sxpert as +1, Sarcastic.
Babel could potentially alleviate the problem, since its one of the few routing protocols that are flexible enough to take diversity into account, and hence use different radio frequencies for neighbouring hops. But as you rightly note, there's not much more that can be done for single-radio nodes as long as we stick with CSMA.
My personal hope is that multi-radio routers will become cheap enough to be used instead of our current single-radio nodes.
Interestingly, I was advised to disable one of the two omni-directional antennas (and disable diversity) to improve the overall connectivity of the mesh. I didn't try it with two antennas to investigate any the diffences though. Would this really help?
No, it probably wouldn't. First, it's only spacial diversity, which isn't particularly interesting with omnidirectional antennas. Second, the diversity algorithm is very primitive â" every packet is sent using the antenna that had the best reception of the previous packet. There's no way to control it from the higher layers (i.e. the routing protocol).
Sorry to follow up on myself, but there's third issue as well, specific to the Linksys routers.
The binary wl driver for the Broadcom chip has an annoying tendency to drop for a few seconds while it is performing a scan. If you were seeing massive jitter on fairly unloaded mesh networks, that's probably the cause.
I have no idea whether the new b43 driver has the same issue.
Over 3 hops, the number of calls greatly reduces as there is just too much random delay.
Yes, there are a number of issues with building multihop mesh networks over wifi.
If you're using omni-directional antennas, the most serious issue is that the multiple hops interfere with each other. Ideally, you'd have multi-radio nodes that use different frequencies, and a routing protocol that attempts to maximise path diversity, but the multiple radios increase total cost, and building a routing protocol that takes diversity into account is not completely trivial.
This issue doesn't happen with directional antennas, which is what the author of the article appears to be using.
The second issue is that 802.11 performs reemissions, which cause timing jitter when there is interference. The solution is to modify the link layer to send VoIP packets with lower reliability, which is supported in 802.11e. Unfortunately, current hardware doesn't do 802.11e in ad-hoc mode.
It's always nice to see a tech writer full of teenage enthusiasm, but this article goes a little over the top.
It's supposed to be an article about a performance enhancement, and there's barely any performance values at all (except for the theoretical peak throughputs on page 3, and we know how much that means).
I think what the guy really wanted was to write about planes, not about computer hardware.
DDR3 simply picks up speed where DDR2 left off... which is as accurate as saying an airplane picks up where a kite left off.
DDR2 technology is no better prepared to reach higher speeds than a propeller airplane is capable of breaking the sound barrier;
DDR3 is very similar to the advancement of jet propulsion over prop-style aircraft,
This is just another reason that people should be encrypting their chats with something like OTR
While I warmly recommend OTR (and use it myself whenever possible), the right solution is to switch to a peer-to-peer model for IM, where the clients connect to each other directly without going through the server. The server then only serves for locating clients, and for off-line messaging.
This can be done in addition to end-to-end encryption, as done by OTR.
I would think that the batteries and solar cells would be the more attractive things to steal, and if you can make them as cheap as plastic bags from a supermarket then you've solved a whole load more problems than community wireless:)
That's a very good point.
I don't think that using solar-powered devices is economically feasible; you really need access to external power.
In cities, there's power in every streetlamp, and we need to find ways to get the municipal authorities to give us access to that, and in every café or restaurant, and we need to explain to café owners that it's just a few watts. In the countryside, there's church towers (at least in Europe), so be nice to your local priest.
You want to make sure that traffic from the mesh network does not use your IP address, but one of the addresses assigned to the mesh network. This is not difficult to achieve, it just requires tunnels and careful design of your routing.
I've been wanting to try doing something like this, to make a large, community intranet.
...
Personally, I'd be willing to buy a router that relays for this purpose only to extend the mesh but not actually volunteer my paid ISP bandwidth or actually hook up any computers to bridge the two networks.
We, in Paris, have been experimenting with just such a network, based on a dynamic mesh routing protocol (Babel) and an autoconfiguration protocol similar to DHCP (AHCP).
The results are mixed. On the one hand, a lot of geeky types turn out to be willing to volunteer their (paid-for) ADSL line and even to buy a router with their own pennies. On the other hand, normal users are not willing to install software they don't understand -- they just want to use a normal AP, and don't understand why they need to install extra software just to use the Internet.
some people will have to set up tunnels to bridge the gaps between the mesh areas.
Yes, that's exactly what we are doing. Unfortunately, setting up tunnels (VPNs) is complicated and error-prone, and existing VPN software are designed with static routing in mind. We're actually thinking of designing our own VPN implementation that is convenient to use with dynamic routing protocols.
I thought OLPC was about using technology to help kids to learn technology so that they can do any number of things that technology can potentially offer them. I though that that was why Free software seemed to make so much sense.
The way I read it, the project was about giving educational tools to kids -- electronic textbooks, collaboration software, communication tools --, and that the technology was not the goal in itself.
There's no doubt that switching to Windows makes this goal much more difficult to achieve; see this posting by Scott Ananian.
Now... anybody got any interesting applications for this?
Enhancing Cisco's bottom line?
See, there's a lot of network engineers that are trained to mindlessly buy from Cisco whatever the cost. Right now, they're buying switches and routers from Cisco, but application servers from other suppliers. If Cisco starts making servers, they will buy the servers from Cisco, no matter whether they are twice as expensive as the same hardware from Dell.
Switch- Handles moving packets between endpoints on a single IP Subnet (layer 2 Device)
Yes, that's the terminology that honest people use. But Cisco's marketheads call "switch" anything that does forwarding in hardware, even if it's actually a router. Hence their somewhat quaint references to "layer 3 switches".
Slashdot Mirror
In other news, given physical access a user can get root access to a Linux box. To accomplish this, the user renames /bin/sh to /sbin/init â" this is the program that makes sure that anything ever gets done on a Unix system. The person who discovered this security hole claims that XP, 2000, 2003 and NT are not vulnerable to it; only Unix-like systems are.
It's possible, but it's silly. You get to manage both.
This is a large site, and the people running Vista are, by definition, not the same people as the ones running Unix.
Being a member of the latter crowd, I enjoy Windows users' discussions a lot.
While a root server handles a lot of traffic, it only serves a single zone with a few hundred entries.
I considered Mara for our authoritative name server, then decided it has two significant limitations:
The name server is the one place where you want to deploy IPv6 support as early as possible, since it will be needed as soon as you have a single IPv6 server. As to the zone file format, while RFC 1035 format is not the best format around, it's at least standard and mostly transportable between servers.
They're trying to make your mouse pointer move smoothly, your audio never skip, your FPS game never miss a beat and your Linux-driven coffee machine never burn a bean, even when there is some process opening a random device in the background.
It doesn't harm to repeat this once again. I believe it's Bruce Schneier who came up with the line that fortunately for us the terrorists are stupid; if they weren't, they'd build a bomb that detonates when there are five American passports in range.
By mandating that we have RFID chips in our passports, our authorities are not only violating our civil liberties; they're actually risking our lives.
(Sorry for the delay, I was busy rotating all of my ssh keys.)
In case you didn't get the joke -- please mod sxpert as +1, Sarcastic.
Babel could potentially alleviate the problem, since its one of the few routing protocols that are flexible enough to take diversity into account, and hence use different radio frequencies for neighbouring hops. But as you rightly note, there's not much more that can be done for single-radio nodes as long as we stick with CSMA.
My personal hope is that multi-radio routers will become cheap enough to be used instead of our current single-radio nodes.
No, it probably wouldn't. First, it's only spacial diversity, which isn't particularly interesting with omnidirectional antennas. Second, the diversity algorithm is very primitive â" every packet is sent using the antenna that had the best reception of the previous packet. There's no way to control it from the higher layers (i.e. the routing protocol).
Sorry to follow up on myself, but there's third issue as well, specific to the Linksys routers.
The binary wl driver for the Broadcom chip has an annoying tendency to drop for a few seconds while it is performing a scan. If you were seeing massive jitter on fairly unloaded mesh networks, that's probably the cause.
I have no idea whether the new b43 driver has the same issue.
The way I read the article, he's using carefully positioned directional antennas to get line-of-sight links.
Anyone know what he's using for routing?
How is ATM going to help, when you're suffering from jitter due to ARQ in the presence of interference?
Yes, there are a number of issues with building multihop mesh networks over wifi.
If you're using omni-directional antennas, the most serious issue is that the multiple hops interfere with each other. Ideally, you'd have multi-radio nodes that use different frequencies, and a routing protocol that attempts to maximise path diversity, but the multiple radios increase total cost, and building a routing protocol that takes diversity into account is not completely trivial.
This issue doesn't happen with directional antennas, which is what the author of the article appears to be using.
The second issue is that 802.11 performs reemissions, which cause timing jitter when there is interference. The solution is to modify the link layer to send VoIP packets with lower reliability, which is supported in 802.11e. Unfortunately, current hardware doesn't do 802.11e in ad-hoc mode.
It's always nice to see a tech writer full of teenage enthusiasm, but this article goes a little over the top.
It's supposed to be an article about a performance enhancement, and there's barely any performance values at all (except for the theoretical peak throughputs on page 3, and we know how much that means).
I think what the guy really wanted was to write about planes, not about computer hardware.
LANs are already fast -- when did you last saturate a GigE switch ? Right now, for most applications, the bottleneck is in the disk.
While I warmly recommend OTR (and use it myself whenever possible), the right solution is to switch to a peer-to-peer model for IM, where the clients connect to each other directly without going through the server. The server then only serves for locating clients, and for off-line messaging.
This can be done in addition to end-to-end encryption, as done by OTR.
The link was about SFSS, not TCP. SFSS is a link-layer protocol that has similar speed to MSNP.
(TCP doesn't use NAKs, although you might claim that SACKs are a form of NAK.)
That's a very good point.
I don't think that using solar-powered devices is economically feasible; you really need access to external power.
In cities, there's power in every streetlamp, and we need to find ways to get the municipal authorities to give us access to that, and in every café or restaurant, and we need to explain to café owners that it's just a few watts. In the countryside, there's church towers (at least in Europe), so be nice to your local priest.
You want to make sure that traffic from the mesh network does not use your IP address, but one of the addresses assigned to the mesh network. This is not difficult to achieve, it just requires tunnels and careful design of your routing.
We, in Paris, have been experimenting with just such a network, based on a dynamic mesh routing protocol (Babel) and an autoconfiguration protocol similar to DHCP (AHCP).
The results are mixed. On the one hand, a lot of geeky types turn out to be willing to volunteer their (paid-for) ADSL line and even to buy a router with their own pennies. On the other hand, normal users are not willing to install software they don't understand -- they just want to use a normal AP, and don't understand why they need to install extra software just to use the Internet.
Yes, that's exactly what we are doing. Unfortunately, setting up tunnels (VPNs) is complicated and error-prone, and existing VPN software are designed with static routing in mind. We're actually thinking of designing our own VPN implementation that is convenient to use with dynamic routing protocols.
You need to make sure that the boxes are cheap and plentiful, so that stealing them is about as exciting as stealing a plastic bag from a supermarket.
If it's done right (e.g. using mesh networking technology), breaking just a few nodes should not cause an outage.
The way I read it, the project was about giving educational tools to kids -- electronic textbooks, collaboration software, communication tools --, and that the technology was not the goal in itself.
There's no doubt that switching to Windows makes this goal much more difficult to achieve; see this posting by Scott Ananian.
Enhancing Cisco's bottom line?
See, there's a lot of network engineers that are trained to mindlessly buy from Cisco whatever the cost. Right now, they're buying switches and routers from Cisco, but application servers from other suppliers. If Cisco starts making servers, they will buy the servers from Cisco, no matter whether they are twice as expensive as the same hardware from Dell.
Yes, that's the terminology that honest people use. But Cisco's marketheads call "switch" anything that does forwarding in hardware, even if it's actually a router. Hence their somewhat quaint references to "layer 3 switches".
See them advertising their "Layer 3 switches".