Re: [Freedombox-discuss] Freedombox Mesh Network Simulator
My mother past away in January. My brother and I spent some time this weekend putting her house in order for a sale. It's thrown all prior planned weekend activities off. I will work on the simulator as soon as I'm able to this week. All updates will remain at: https://www.github.com/RickCHodgin/fbxsim - Here are some nuggets to chew on regarding its design. I have solidified on a relative grid-based design, the coordinates of which can come from either some system of relative FBX positions, or, for a more agile, public, adhoc grid, true GPS coordinates. All nodes on the grid coordinate thusly: 1) No unnecessary communication. 2) Chirps initial position to determine neighbors. 3) Listens passively for updates. 4) Determines route to open up a channel / path to send streams of data. Note: Remember that since we're using grid-base communication, each node always knows from where it is to where it's going. So it's always looking for nodes which can get the information sent over that way, and in that direction. In the event of an obstacle (a downed portion of the mesh, a hole in active nodes there), it will seek alternate routes which go around the hole, but initially it tries the most direct route as each node as each node will know the location of nodes around itself. 5) If a node is mobile, it updates itself as it moves. 6) Communication of whatever comes in. 7) Broadcast to one or many. 8) Some other things too numerous to mention. :-) Best regards, Rick C. Hodgin On 06/19/2012 10:21 PM, Rick C. Hodgin wrote: All, I began working on the mesh network simulator. Will work on it more this week / weekend. Will put a video up on YouTube describing its operation. The source code is available here: https://github.com/RickCHodgin/fbxsim It's being written in Visual FoxPro 9.0 for rapid prototyping. I'd like to get it done by the end of this weekend. I will include an executable which can be run under Windows for anybody who wants to test it out themselves. Best regards, Rick C. Hodgin ___ Freedombox-discuss mailing list Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
Re: [Freedombox-discuss] Freedombox Mesh Network Simulator
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Ben, On 22/06/12 21:31, Ben Mendis wrote: Look at it this way, what you're talking about is already possible. Your ISP can already see all your traffic and they can analayze everything you're doing. If the government comes knocking they will have to turn over their logs or tap your line. With mesh networking, you are mitigating that risk by spreading your traffic among a large number of peer nodes. Sure, some of those nodes might be malicious, or some of them could be coercable, but it's less likely that any one of them will be the exclusive transport for all your traffic, so they are only seeing a part of your traffic. This is only true if the routing protocol prevents malicious nodes from attracting traffic to themselves. There are known attacks of that kind against various ad hoc/mesh protocols [1][2][3]. Also, the malicious nodes may genuinely have the best routes - if someone parks a van outside your house with an uncongested high-speed uplink, any sensible routing protocol will send most of your traffic through the van instead of spreading it around your neighbours. I don't mean to be totally pessimistic - if someone has to park a van outside your house that's better than if they can just ask the ISP for a copy of all your traffic. But I don't think we should pretend that mesh protocols provide privacy, anonymity or robustness against malicious nodes - they don't. Cheers, Michael [1] http://www.monarch.cs.cmu.edu/monarch-papers/tikreport.pdf [2] http://prisms.cs.umass.edu/brian/pubs/aran.icnp02.pdf [3] http://monarch.cs.rice.edu/monarch-papers/wise03orig.pdf -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBAgAGBQJP56uBAAoJEBEET9GfxSfMfloH/1HHuEQaG9U+PWahDvPsxVoQ 9FtUhe7+Mr/UEtXvL+STqMlfIQ/9U/JZsx/OWWyLgefOKlCZwgRHWztaHt6TJADT GSRqm4ezElbh7Y26ZLnphPdeCRMvjVRBjUWxgO5beIDJNAljaDZsYp8i2vkytJbq XXLT2t/MuiTuJy/3w3KGRRdyG2ShKo3RWjyJD+TDxMIgtQS+874FnVu+ykJN7S6x OM2slC7oJ6DDO9xshBU+YMbS446mf2W/Ng3wzPoXvuwonoVVf7EfG/Aq5J+DUm3f Kt/djtrBZk7o0jvvw42NABJyYLFKKx934wxk7bh9P+RWzTBMZiRSn5iPjdM8qe0= =4Gl/ -END PGP SIGNATURE- ___ Freedombox-discuss mailing list Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
Re: [Freedombox-discuss] Freedombox Mesh Network Simulator
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Rick, On Sun, 24 Jun 2012, Rick C. Hodgin wrote: My mother past away in January. My brother and I spent some time this weekend putting her house in order for a sale. It's thrown all prior planned weekend activities off. I'm sorry to hear that. You have my condolences. Here are some nuggets to chew on regarding its design. I have solidified on a relative grid-based design, the coordinates of which can come from either some system of relative FBX positions, or, for a more agile, public, adhoc grid, true GPS coordinates. I don't want to seem like I'm being negative, but I think your design is naive and impractical. For example, accurately determing the physical position of a node is difficult. Even with GPS, it can be a challenge as the GPS might report an inaccurate position or might fail to determine the position at all. And assuming you have an accurate way to determine the position, how do you know you can trust the positions reported by other nodes? And even then, if you have an accurate position and you know that other nodes are reporting accurate positions to you, physical location/proximity is not a reliable real-world indicator of whether or not there is connectivity between two nodes. Two nodes might be very near to each other, but not have any connectivity with each other, while having very good connectivity to other nodes which are further away. So in general, I think the idea of relying on physical location to route traffic is not a realistic approach. All nodes on the grid coordinate thusly: 1) No unnecessary communication. I think you falsely assume that the chatty communication that existing routing protocols rely on is unnecessary. Figuring out how to reduce that traffic would be a big optimization, and it's certainly an open problem in the field, but eliminating it is a mistake. 2) Chirps initial position to determine neighbors. Ok, but what about if it moves or goes off-line? How do the neighbors determine if the initial chirp is still valid if it doesn't update periodically? 4) Determines route to open up a channel / path to send streams of data. How does it do that? Are you suggesting it just does a calculation to determine which neighbor is the next closest in terms of physical distance to destination? As a said before, I believe that to be a mistake. The next physically closest node might not have any suitable routes to deliver that packet, meanwhile a node that is physically further away might have an appropriate route. Note: Remember that since we're using grid-base communication, each node always knows from where it is to where it's going. So it's always looking for nodes which can get the information sent over that way, and in that direction. In the event of an obstacle (a downed portion of the mesh, a hole in active nodes there), it will seek alternate routes which go around the hole, but initially it tries the most direct route as each node as each node will know the location of nodes around itself. The try a direct route first, then backtrack approach might be marginally faster when a direct route exists, but it could be much, much slower if it does not. I think you'll find that even in a relatively trivial example the cost of indirect routes will be prohibitively expensive. 5) If a node is mobile, it updates itself as it moves. Again, you're relying on having accurate positioning information, and an explicit correlation between position and connectivity. 6) Communication of whatever comes in. I'm not sure what you mean here. 7) Broadcast to one or many. You want to support multicast? How do you see that working here? 8) Some other things too numerous to mention. :-) Ok, well here's another question. How are you planning to map IPv4/IPv6 addresses to geographic node addresses? That's going to be key to a number of issues here, including how multicast routing will work. Or are you planning to just replace IPv4/6 addresses entirely? What are you going to do about directional antennas? And on that note, you seem to implicitly assume that Layer-1 is Wi-Fi, what if it's not? What if it's wired ethernet, or fiber-optics, or Ronja, or amateur radio, or a cellular modem? I realize that using geographic position seems like an obvious way to efficiently route packets, but for a variety of reasons, including those listed above, I don't believe it's a practical strategy. I think the answer will be to allow nodes to do neighbor discovery and build a virtual map of the network's topology, as the virtual topology often bears little or no relation to the physical topology. Understanding the virtual topology will result in the most efficient routes. Again, this criticism is meant to be constructive. I'm not trying to discourage you from experimenting with mesh networking protocols. I am certainly no expert, so it's conceivable that you might prove me wrong. Best regards, Ben the
Re: [Freedombox-discuss] Freedombox Mesh Network Simulator
Appreciate your feedback. You'll see the answers in time, Ben. Best regards, Rick C. Hodgin Original Message From: Ben Mendis dragonwis...@gmail.com Sent: Sun, Jun 24, 2012 08:51 PM To: freedombox-discuss@lists.alioth.debian.org freedombox-discuss@lists.alioth.debian.org CC: Subject: Re: [Freedombox-discuss] Freedombox Mesh Network Simulator -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Rick, On Sun, 24 Jun 2012, Rick C. Hodgin wrote: My mother past away in January. My brother and I spent some time this weekend putting her house in order for a sale. It's thrown all prior planned weekend activities off. I'm sorry to hear that. You have my condolences. Here are some nuggets to chew on regarding its design. I have solidified on a relative grid-based design, the coordinates of which can come from either some system of relative FBX positions, or, for a more agile, public, adhoc grid, true GPS coordinates. I don't want to seem like I'm being negative, but I think your design is naive and impractical. For example, accurately determing the physical position of a node is difficult. Even with GPS, it can be a challenge as the GPS might report an inaccurate position or might fail to determine the position at all. And assuming you have an accurate way to determine the position, how do you know you can trust the positions reported by other nodes? And even then, if you have an accurate position and you know that other nodes are reporting accurate positions to you, physical location/proximity is not a reliable real-world indicator of whether or not there is connectivity between two nodes. Two nodes might be very near to each other, but not have any connectivity with each other, while having very good connectivity to other nodes which are further away. So in general, I think the idea of relying on physical location to route traffic is not a realistic approach. All nodes on the grid coordinate thusly: 1) No unnecessary communication. I think you falsely assume that the chatty communication that existing routing protocols rely on is unnecessary. Figuring out how to reduce that traffic would be a big optimization, and it's certainly an open problem in the field, but eliminating it is a mistake. 2) Chirps initial position to determine neighbors. Ok, but what about if it moves or goes off-line? How do the neighbors determine if the initial chirp is still valid if it doesn't update periodically? 4) Determines route to open up a channel / path to send streams of data. How does it do that? Are you suggesting it just does a calculation to determine which neighbor is the next closest in terms of physical distance to destination? As a said before, I believe that to be a mistake. The next physically closest node might not have any suitable routes to deliver that packet, meanwhile a node that is physically further away might have an appropriate route. Note: Remember that since we're using grid-base communication, each node always knows from where it is to where it's going. So it's always looking for nodes which can get the information sent over that way, and in that direction. In the event of an obstacle (a downed portion of the mesh, a hole in active nodes there), it will seek alternate routes which go around the hole, but initially it tries the most direct route as each node as each node will know the location of nodes around itself. The try a direct route first, then backtrack approach might be marginally faster when a direct route exists, but it could be much, much slower if it does not. I think you'll find that even in a relatively trivial example the cost of indirect routes will be prohibitively expensive. 5) If a node is mobile, it updates itself as it moves. Again, you're relying on having accurate positioning information, and an explicit correlation between position and connectivity. 6) Communication of whatever comes in. I'm not sure what you mean here. 7) Broadcast to one or many. You want to support multicast? How do you see that working here? 8) Some other things too numerous to mention. :-) Ok, well here's another question. How are you planning to map IPv4/IPv6 addresses to geographic node addresses? That's going to be key to a number of issues here, including how multicast routing will work. Or are you planning to just replace IPv4/6 addresses entirely? What are you going to do about directional antennas? And on that note, you seem to implicitly assume that Layer-1 is Wi-Fi, what if it's not? What if it's wired ethernet, or fiber-optics, or Ronja, or amateur radio, or a cellular modem? I realize that using geographic position seems like an obvious way to efficiently route packets, but for a variety of reasons, including those listed above, I don't believe it's a practical strategy. I think the answer will be to allow nodes to do neighbor discovery and build a virtual map of the network's topology, as the virtual
Re: [Freedombox-discuss] Freedombox Mesh Network Simulator
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/20/2012 04:16 PM, Markus Sabadello wrote: I've been told though that olsr is still the way to go for large networks. Kind of. If the mesh nodes pushing the packets have a fair amount of RAM olsrd is okay. The thing about that particular protocol is that it tries to replicate the entire routing table to each node, which is inefficient because then you have nodes that have routes for machines they can't reach directly and have to count on closer nodes to relay for them anyway. They're also just getting loop avoidance working, and routing loops can deadlock a mesh. - -- The Doctor [412/724/301/703] [ZS] PGP: 0x807B17C1 / 7960 1CDC 85C9 0B63 8D9F DD89 3BD8 FF2B 807B 17C1 WWW: https://drwho.virtadpt.net/ No other race in the universe goes camping. Celebrate your uniqueness. --Jack Harkness -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/kvcwACgkQO9j/K4B7F8EFoQCgraYFPhXoQQQL/BhQfv+CQtFp Y3QAn0pP/F03K5Ku5D8ycZ7QzbyTndd7 =JwHc -END PGP SIGNATURE- ___ Freedombox-discuss mailing list Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
Re: [Freedombox-discuss] Freedombox Mesh Network Simulator
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/20/2012 10:12 AM, Dave Taht wrote: There are plenty of mesh protocols available - 802.11s, batman, olsr, and my own fav babel. 802.11s operates at layer 2, is limited to 32 There are over 70 mesh routing protocols; not all of them have been implemented (a lot are just whitepapers) but maybe a dozen have. nodes, and has other issues, so I tend to ignore it. batman-adv is also layer too but much more flexible and interesting. It's also a little wiggy in the field. Granted, this was in early 2011. But as for babel, I like it because it is a pure layer 3 protocol, it handles ipv6 and ipv4, and has a pluggable metric. It's also the most resilient we've tested in the field, as well as easy to troubleshoot. That's why Byzantium went with it. possible demo... build and install babeld and ahcp on all nodes It's also possible to use APIPA addressing on nodes and have it work. ifconfig wlan0 down iwconfig wlan0 mode ad-hoc channel 1 essid babel # channel and essid are arbitrary. Some devices won't let you do that in one pass The Atheros chipsets we've been testing on don't. It's fairly easy to make the configuration utility robust enough to work around that. Now, it's easier to just setup an ahcp server to hand out addresses, and use ahcp for setup, but that's too long to go into the margins here. If you're planning the construction of a mesh, ahcpd works well. If you're doing it more organically I don't recommend it. - -- The Doctor [412/724/301/703] [ZS] PGP: 0x807B17C1 / 7960 1CDC 85C9 0B63 8D9F DD89 3BD8 FF2B 807B 17C1 WWW: https://drwho.virtadpt.net/ Red Adair Linux, for what we do most of the time. --Paul Martin -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/kv5oACgkQO9j/K4B7F8HbvACfTpn+cb/Uj13u2ZVYpGl9hp5F cFoAn29gFDYBkgI25MejXu7tvB/8pcCm =QWdY -END PGP SIGNATURE- ___ Freedombox-discuss mailing list Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
Re: [Freedombox-discuss] Freedombox Mesh Network Simulator
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/20/2012 02:13 PM, John Gilmore wrote: Internet while the problem is happening, to debug it. Many, many OLPC mesh problems occurred in the field which could not be replicated in the lab, which made them 10x or 100x harder to fix. This meant that buggy mesh network firmware and software didn't improve at the usual rate (of the rest of their software). We were able to replicate some of the problems they had at HacDC (we have a stack of OLPCs on the shelf that we use as test systems sometimes). The result was that despite a lot of work addressing bugs and performance in the mesh firmware, they never got their automatic mesh network working with more than a handful of XO laptops. If you put 30 laptops in a classroom, they would burn up 100% of the radio bandwidth (and chew up their batteries) merely with overhead packets (Hi, i'm Yep. 30 nodes in a single classroom is catastrophically too many. One or two work are enough. I don't think they ever tried that particular set up in the lab before shipping. There ARE some mesh networks that I hear are working on a larger scale, such as B.A.T.M.A.N. I suspect that the large scale meshes are in largely static networks that are tuned by humans to work well (just Some are, some aren't. Battlemesh is, as I recall. it's not automatic). I do not know if other meshes support multicast (or other portable ways for high level software to find what nodes are on the network), nor whether they work in a network of mobile nodes Byzantium Linux does; we're testing it in the field right now. with limited battery life. All I can report on is the one project I Mobiles as mesh nodes? It's a dicey proposition due to power consumption. Mobiles as mesh clients are more workable. available bandwidth. Every connection you move off wireless onto a wire makes more radio bandwidth available for the folks who truly can't run a wire. This is true. Also, if the network topology involves patches of meshes connected with second radios (like USB wi-fi keys) it frees up bandwidth for the clients. PS: If you think a mesh protocol shouldn't use even a megabit/second of continuous overhead, please design and build one that doesn't, and that scales up and keeps working. It's harder than it looks. Babel doesn't. I think our biggest mesh pushed a couple of kilobits per second of overhead. - -- The Doctor [412/724/301/703] [ZS] PGP: 0x807B17C1 / 7960 1CDC 85C9 0B63 8D9F DD89 3BD8 FF2B 807B 17C1 WWW: https://drwho.virtadpt.net/ Red Adair Linux, for what we do most of the time. --Paul Martin -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/kwMkACgkQO9j/K4B7F8GSLACdFC4JOHhbvIaZH9NzikUrjxLz BdkAn0b01w4+vcTdq0oR5Rc6VHnpSPhU =qbya -END PGP SIGNATURE- ___ Freedombox-discuss mailing list Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
Re: [Freedombox-discuss] Freedombox Mesh Network Simulator
I'm having a hard time wrapping my head around the security implications of this discussion. I think that's in part because goals like censorship-resistant-connectivity and privacy seem in conflict. To the best of my understanding these routing protocols have not been designed with the goal of preventing a malicious party from capturing (that is observing and possibly modifying) traffic that party is interested in. Encryption and integrity protection can defend against modification assuming that is supported by the protocol in question. Services like VPN tunnels or TOR can be used to get enthcryption/integrity protection across the mesh when accessing services that support Internet but do not themselves support integrity/confidentiality. However, finding out what services someone is accessing is also a concern as well as monitoring access patterns and the like. These mesh technologies seem to present huge issues in that direction. Combining mesh technologies with things like TOR doesn't make these issues go away; it does make them harder to analyze. As I see all these conflicting requirements I become increasingly concerned that it will be difficult for technical folks to understand what security and privacy properties a Freedom Box actually provides. I think conveying that to an end-user may be beyond our capability. One thing that might be valuable to do at least for designers of the system to understand it is to focus on making available the best in privacy-defeating technology we can. That is, make it easy to find all you can about people using your mesh node, to combine that with others who are willing to share privacy-defeating information with you, etc. The goal would be to understand what the practical attacks and exposures are with various technologies we're using as we are combining them. ___ Freedombox-discuss mailing list Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
Re: [Freedombox-discuss] Freedombox Mesh Network Simulator
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Sam, I am one of the developers of Project Byzantium and heard about this discussion from The Doctor. Freedombox is not our project so we have no authority to direct which way the project goes, but we have done some significant research and development in this space. Our knowledge and experience might be relevant to the discussion. On Fri, 22 Jun 2012, Sam Hartman wrote: I'm having a hard time wrapping my head around the security implications of this discussion. I think that's in part because goals like censorship-resistant-connectivity and privacy seem in conflict. To the best of my understanding these routing protocols have not been designed with the goal of preventing a malicious party from capturing (that is observing and possibly modifying) traffic that party is interested in. You are correct. These routing protocols are designed to efficiently solve the OSI Layer 3 concern of routing packets from a source address to a destination address. Whether the packet is sniffed and observed in transit is outside the scope of a layer-3 routing protocol, and so they provide no protection against that. Of course, once you have a functioning layer-3 network you can do encryption and obfuscation of the traffic at layer-4 or higher, but that's not a concern of layer-3. As for packets being modified or not being delivered, these are both cases that can be partially handled at layer-3, or handled at layer-4 and above. Some routing protocols may recognize that a particular node is not routing traffic correctly and lower the metric for routes to that node, so subsequent traffic will automatically avoid the bad node. It also seems that recently the Quagga developers have been working on implementing packet authentication in their implementation of Babel to prevent corrupted routes from being propagated. Encryption and integrity protection can defend against modification assuming that is supported by the protocol in question. Services like VPN tunnels or TOR can be used to get enthcryption/integrity protection across the mesh when accessing services that support Internet but do not themselves support integrity/confidentiality. However, finding out what services someone is accessing is also a concern as well as monitoring access patterns and the like. These mesh technologies seem to present huge issues in that direction. Combining mesh technologies with things like TOR doesn't make these issues go away; it does make them harder to analyze. Correct, anyone who is operating a node will be able to monitor traffic across their node and analyze it for patterns of usage. This is because mesh nodes are effectively network infrastructure. That is, each node is like a mini-version of the the routers that form the Internet. Look at it this way, what you're talking about is already possible. Your ISP can already see all your traffic and they can analayze everything you're doing. If the government comes knocking they will have to turn over their logs or tap your line. With mesh networking, you are mitigating that risk by spreading your traffic among a large number of peer nodes. Sure, some of those nodes might be malicious, or some of them could be coercable, but it's less likely that any one of them will be the exclusive transport for all your traffic, so they are only seeing a part of your traffic. How much do you trust your ISP? Do you trust your ISP more than you trust your neighbors? How easy is it for an adversary to coerce your ISP into giving up your traffic? How easy would it be for the adversary to coerce ALL of your neighbors into giving up your traffic? In my opinion, we're safer when our neighbors, private citizens, own the infrastructuer than when it's controlled and operated by some central authority (even if it's a private business). The adversary would have to coerce a larger number of private individuals to get at your traffic then they do now. As I see all these conflicting requirements I become increasingly concerned that it will be difficult for technical folks to understand what security and privacy properties a Freedom Box actually provides. I think conveying that to an end-user may be beyond our capability. I agree, these are tough problems to analyze and explain to people who think of the Internet as a black box (in the shape of a fluffy white cloud) that connects people together. Without a solid understanding of how networking works at the lower levels of the OSI model, and the realistic threats the network faces at those levels, it's a tough converstaion to have. But it is still a fairly important one. Securing layer-3 by removing the traditional hierarchical routing infrastructure is a key step to improving privacy for everyone, but only if used appropriatly in conjunction with encryptions and other tools at layers 4 and up. One thing that might be valuable to do at least for designers of the system to understand it is to focus on
Re: [Freedombox-discuss] Freedombox Mesh Network Simulator
I have pushed out a RUNME\ directory. See for source code: https://github.com/RickCHodgin/fbxsim I was asked in private email what this program is. Basically, it's a protocol simulator describing a methodology of exactly how to establish and maintain a living / dynamic wireless mesh. In the app (fbxsim.exe), in the lower right-hand corner is a barely visible icon. :-) If you drag that and drop it on the form anywhere, you'll create multiple FBX instances. Each FBX (when the simulator is complete) will identify itself in the mesh and communicate with those devices near enough to it to be able to communicate through its WiFi radio. The protocol will establish what information is necessary to maintain a living, dynamic mesh, how to route packets, etc. I will also work on protocols for fixed placement FBXs (in a home, street lamp), as well as roaming FBXs (carrying one on a backpack, bicycle, car). The initial build is in runme\fbxsim.exe. It's little more than a small screen with drag-and-drop abilities to simulate where the FBXs will be located. Will work on it more this week. Linux users can use WINE to run Windows programs. I have tested it in Ubuntu 12.04 and it works. Don't know about other distros. Please contact me with any questions / suggestions. Thanks! :-) Best regards, Rick C. Hodgin ___ Freedombox-discuss mailing list Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
Re: [Freedombox-discuss] Freedombox Mesh Network Simulator
Matthias-Christian, I appreciate your response. If the research is available let's get it out there and find the software and steps to setup mesh networks on FBX. Best regards, Rick C. Hodgin On 06/20/2012 08:50 AM, Matthias-Christian Ott wrote: On 2012-06-20 14:23, Rick C. Hodgin wrote: The protocol will establish what information is necessary to maintain a living, dynamic mesh, how to route packets, etc. I will also work on protocols for fixed placement FBXs (in a home, street lamp), as well as roaming FBXs (carrying one on a backpack, bicycle, car). I don't fully understand what you are trying to do here and haven't looked at the software you created, but if you want to simulate wireless mesh networks, I found that ns-3 [1] works (I had to use it during a course on networks which included simulation wireless mesh networks and simple evaluations of routing algorithms), so I guess you don't have to write your own software. Regards, Matthias-Christian [1] http://www.nsnam.org/ ___ Freedombox-discuss mailing list Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss ___ Freedombox-discuss mailing list Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
Re: [Freedombox-discuss] Freedombox Mesh Network Simulator
Would it be useful to discuss requirements from scratch? On Wed, Jun 20, 2012 at 2:13 PM, John Gilmore g...@toad.com wrote: My wife and I are walking in mall with at least one other person every 40 feet or so. We decide to separate and go shopping. I walk this way, she walks that way. Before long we're out of direct WiFi communication range to each other. Now, if enough people there in the mall had WiFi-enabled devices running some mesh software, I'd like to be able to stay in contact with my wife as she moves about in her random way, and as they all move about in their random ways. The One Laptop per Child project also wanted to satisfy this goal. They wanted kids all over a village to be able to reach each other and to reach the Internet via a gateway at their school. They had the advantage of designing and building both the hardware and software. But they failed, partly due to system integration issues. They were using a buggy implementation of 802.11 meshing that preceded 802.11s. But they also used higher level user interface software, which used multicast packets to find and communicate with other nearby laptops. The mesh software worked poorly with multicast. Not only did it send multicasts at the slowest speed (1 megabit), which took up a lot of airtime, but the various nodes would repeat the multicasts to make sure that every node had heard them. This limited the size of the network that they could scale to. They did not discover this unfortunate interaction until very late in the hardware/software/firmware integration process (when the multicast-based application sharing software started working). Another major problem was that a mesh network is very hard to reproduce. If it does something unexpected or suboptimal, the developers can't just teleport themselves to the part of the world where that particular physical configuration of radio nodes, physical antennas, software versions, and firmware versions exists. In many cases they can't even reach into the nodes of that network over the Internet while the problem is happening, to debug it. Many, many OLPC mesh problems occurred in the field which could not be replicated in the lab, which made them 10x or 100x harder to fix. This meant that buggy mesh network firmware and software didn't improve at the usual rate (of the rest of their software). The result was that despite a lot of work addressing bugs and performance in the mesh firmware, they never got their automatic mesh network working with more than a handful of XO laptops. If you put 30 laptops in a classroom, they would burn up 100% of the radio bandwidth (and chew up their batteries) merely with overhead packets (Hi, i'm here. Hi you, I'm me; have you heard about Joe and Alice over there? In case you want to send a message to Joe, send it via me to Alice; I can hear Alice just fine.). There was no bandwidth left for the users to actually communicate; connections would time out, nodes would appear and disappear from the mesh, etc. So OLPC stopped using the mesh and recommended that each classroom install one or more 802.11 access points. Which has worked ok. They also switched to support ad-hoc 802.11 without meshing, for automatically networking a few students sitting around under a tree, which also works ok. There ARE some mesh networks that I hear are working on a larger scale, such as B.A.T.M.A.N. I suspect that the large scale meshes are in largely static networks that are tuned by humans to work well (just as the broader Internet's routing system is tuned by humans to work; it's not automatic). I do not know if other meshes support multicast (or other portable ways for high level software to find what nodes are on the network), nor whether they work in a network of mobile nodes with limited battery life. All I can report on is the one project I was involved in (OLPC), in which their mesh implementation failed to accomplish its goals, and was dropped from the next generation hardware and software. This is part of why I recommend using wired connections wherever possible. For FreedomBox to succeed, it needs to succeed at scale. A FreedomBox network that can't route packets for more than 500 nodes worldwide wouldn't be worth building. (Clue: this is why the Internet exists today: it scaled up and kept working, while the proprietary networks that preceded it didn't scale up to worldwide scale.) In a substantial network, your mesh and dynamic routing protocol could require a few megabits of traffic at all times on each node, just keeping track of everything. Over a 100-megabit Ethernet that's just 2 or 3% of the bandwidth. But over 802.11, that burns up most of the available bandwidth. Every connection you move off wireless onto a wire makes more radio bandwidth available for the folks who truly can't run a wire. I have some ideas about how FreedomBox nodes could provide
Re: [Freedombox-discuss] Freedombox Mesh Network Simulator
We won't carry FBXs around the mall because they use too much electricity. Agreed. However, we all have cell phones. Root a device, install a custom ROM or a custom FBX app which leverages the WiFi abilities of the device, and now we all have FBX conduits in cell phone form able to transfer data back and forth on the FBX mesh/network, one that's not part of a real FBX device, but one that is such in principle, and one that also doesn't drain batteries too fast. We have to look at what we're on about here: The ability to have little servers is one thing. But the ability to convey information outside of prying eyes is another. Other people have interests in hooking things up to long-distance communication forms, being able to do island-based social media, for example, where various servers are connected to the traditional Internet and distribute the load. That's not my interest. I want to be able to assemble an ad-hoc WiFi-based mesh network anywhere, at any time, even if it comes up at 6:00pm sharp, is up for two minutes, and goes down at 6:02pm. I want that network to have functioned in that short period of time to get the message out quickly by distributing in this geographic manner. I may be the only one who wants that ... and that's fine. It is my goal, and it's what I'm pursuing. Best regards, Rick C. Hodgin On 06/20/2012 01:28 PM, Kent Crispin wrote: On 06/20/2012 07:10 AM, Rick C. Hodgin wrote: Michael, I'd prefer not to write anything. :-) If these technologies already exist I'd like to use them. I've never heard of them being in existence. I've always known WiFi to communicate with a WiFi router / hub to get to other WiFi devices, or one-to-one with another device. Never the ability to communicate with multiple devices as part of a mesh / grid. What I'd like is something this flexible: My wife and I are walking in mall with at least one other person every 40 feet or so. We decide to separate and go shopping. I walk this way, she walks that way. Before long we're out of direct WiFi communication range to each other. Now, if enough people there in the mall had WiFi-enabled devices running some mesh software, I'd like to be able to stay in contact with my wife as she moves about in her randome way, and as they all move about in their random ways. The protocols involved would have to keep everyone abreast of where the devices are coming and going in this ever changing sea of WiFi meshes. If technology exists to do this, point me to it and show me the FAQ on how to install it on my FBX so I can begin using it today. :-) I'd even be willing to write a slick GUI to make it easier for the next guy. You wouldn't carry a fbx around a mall -- needs too much electricity. you do carry a cell phone -- everyone carries a cell phone, and a mesh protocol that opportunistically linked wifi-enabled smart phones would be cool. There might be a few mall shops running wifi or fbxs that could provide uplinks, while wandering shoppers w/ fbx-phone provided extended coverage... I don't think this would provide much bandwidth, though. Kent ___ Freedombox-discuss mailing list Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss ___ Freedombox-discuss mailing list Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
Re: [Freedombox-discuss] Freedombox Mesh Network Simulator
For a simple experiment of making 4 Guruplugs talk to each other via batman, see herehttp://projectdanube.pbworks.com/w/page/51790984/Guruplugs%20and%20BATMAN . I've been told though that olsr is still the way to go for large networks. Markus -- Project Danube: http://projectdanube.org Personal Data Ecosystem Consortium: http://personaldataecosystem.org/ On Wed, Jun 20, 2012 at 4:12 PM, Dave Taht dave.t...@gmail.com wrote: There are plenty of mesh protocols available - 802.11s, batman, olsr, and my own fav babel. 802.11s operates at layer 2, is limited to 32 nodes, and has other issues, so I tend to ignore it. batman-adv is also layer too but much more flexible and interesting. But as for babel, I like it because it is a pure layer 3 protocol, it handles ipv6 and ipv4, and has a pluggable metric. http://babelweb.kerneis.info:8080/ shows a live babel based mesh network. as is http://carme.lab.bufferbloat.net:8080/ (via this software. http://www.pps.univ-paris-diderot.fr/~kerneis/software/babelweb/ setting up a babel mesh on ad-hoc is simple, this is the simplest possible demo... build and install babeld and ahcp on all nodes All connected nodes share the same ssid and channel. (for diversity routing just change the channel) On all nodes, disable Network manager and anything else that automates ip getting ifconfig wlan0 down iwconfig wlan0 mode ad-hoc channel 1 essid babel # channel and essid are arbitrary. Some devices won't let you do that in one pass ifconfig wlan0 up babeld -D -z3 eth0 wlan0 ifconfig wlan0 172.20.0.1/32 # for the first node ifconfig wlan0 172.20.0.2/32 # for the second node ifconfig wlan0 172.20.0.3/32 # etc You can use the same ip addresses for your ethernet addresses as life is figured out via the address/interface tuple. If you do that, you can do transparent failover from ethernet to wireless. If you don't, like on any routed network, you need to make sure your address ranges/netmask are disjoint ifconfig eth0 172.20.0.1/32 # for the first node ifconfig eth0 172.20.0.2/32 # for the second node ifconfig eth0 172.20.0.3/32 # etc Now, it's easier to just setup an ahcp server to hand out addresses, and use ahcp for setup, but that's too long to go into the margins here. On Wed, Jun 20, 2012 at 9:28 AM, Rick C. Hodgin foxmuldrs...@yahoo.com wrote: Matthias-Christian, I appreciate your response. If the research is available let's get it out there and find the software and steps to setup mesh networks on FBX. Best regards, Rick C. Hodgin On 06/20/2012 08:50 AM, Matthias-Christian Ott wrote: On 2012-06-20 14:23, Rick C. Hodgin wrote: The protocol will establish what information is necessary to maintain a living, dynamic mesh, how to route packets, etc. I will also work on protocols for fixed placement FBXs (in a home, street lamp), as well as roaming FBXs (carrying one on a backpack, bicycle, car). I don't fully understand what you are trying to do here and haven't looked at the software you created, but if you want to simulate wireless mesh networks, I found that ns-3 [1] works (I had to use it during a course on networks which included simulation wireless mesh networks and simple evaluations of routing algorithms), so I guess you don't have to write your own software. Regards, Matthias-Christian [1] http://www.nsnam.org/ ___ Freedombox-discuss mailing list Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss ___ Freedombox-discuss mailing list Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss -- Dave Täht SKYPE: davetaht http://ronsravings.blogspot.com/ ___ Freedombox-discuss mailing list Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss ___ Freedombox-discuss mailing list Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
Re: [Freedombox-discuss] Freedombox Mesh Network Simulator
On 2012-06-20 at 14:55:52 -0400, Rick C. Hodgin wrote: We have to look at what we're on about here: The ability to have little servers is one thing. But the ability to convey information outside of prying eyes is another. What's there to stop your average three-letter-agency from walking around mayor malls with a malicious phone that works as a node, but forwards any data it has passed on to the same secret quantum computer they use to read any other encrypted message on the internet? I hope I'm joking about the quantum computer, but I doubt that a system that requires connecting to the devices of random strangers, expecially one that is desinged to work with short lived connections, is going to be any more outside of prying eyes than the current internet. -- Elena ``of Valhalla'' ___ Freedombox-discuss mailing list Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
Re: [Freedombox-discuss] Freedombox Mesh Network Simulator
I am going to proceed with my own discovery as I have a very clear idea in my head of how this will work. Great! Break a meg :-/ ! Here's the small insight that helped me refine my thinking: Sending packets from your node towards the Internet is not the hard part. Receiving packets from Internet sites to your node is the hard part. If the protocol you envision handles the hard part cheaply, not only will we get a great network, but you'll probably get a PhD or its equivalent. John ___ Freedombox-discuss mailing list Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
[Freedombox-discuss] Freedombox Mesh Network Simulator
All, I began working on the mesh network simulator. Will work on it more this week / weekend. Will put a video up on YouTube describing its operation. The source code is available here: https://github.com/RickCHodgin/fbxsim It's being written in Visual FoxPro 9.0 for rapid prototyping. I'd like to get it done by the end of this weekend. I will include an executable which can be run under Windows for anybody who wants to test it out themselves. Best regards, Rick C. Hodgin ___ Freedombox-discuss mailing list Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
