Add New Page: You are not allowed to add pages Select section/namespace. New page title.
 

4/13/2012 OTI Guardian

OTI/Commotion - 13/April/2012

User Scenarios for Android OLSRD

Josh - OTI status

  1. a lot of oti team is absorbed in project management (redmine, website etc)
    • on track for next quarterly report (Apr 30)
    • applications for a few other grants (additional commotion funding

for deployment and testing)

  1. tech support for field, feedback, research
    • interactions with testbeds - Mt Pleasant, Brooklyn, Detroit
  2. track down some unusual bugs
    • router wireless stack or commotion?
    • stock openWRT under 20mb/s throughput,max out the access point

(hardware for deployment “Ubiquity” - nano and pico stations) (some test on NetGear (possibly due to multiple radios), no test on Buffalo) trouble building a debug versions of openWRT-trunk

  1. recommend hardware to Guardian: Ubiquity M-Series nano series
  2. “TP link” hardware seems to be popular overseas due to variety and small form factor and may be something to look into in the future.

HC - status Guardian

  1. question; overlay mesh - what is this?
    • multiple layers of security involved
    • optional for any specific network
    • link-layer security
      • management frame security for casual protection from frame and packet injection
      • adding support for WPAnone for basic shared key security.
      • potentially adopting AuthSAE (from 802.11s) which acts much like WPA for mesh (session key exchange with either party able to initiate.
    • security routing traffic (olsr-secure plug-in modified to use longer key lengths for stronger cryptographic algorithms[NINIX project is a public key version of this])
      • does not protect from other devices on network
    • SO the overlay network is an approach to secure the traffic end-to-end
      • Serval proposed this, still under study and design
      • please contribute to list re designs!

HC - need a strong problem statement for additional security

Nathan - coming at this from a mobile space, with our own apps

  1. our apps have own encryption/security and we are excited to get android working and using the existing ip-based security models designed in our apps to work over it.
    • different problem space from Serval
    • Serval sort of monolithic, closed approach
    • we'd NOT want to re-write our apps to use the mesh
    • want to see net as open to apps that do own security

Josh - what Serval to be general and inter-operable

Question: private meshes possible, or just open meshes?

Josh

  1. not trying to create closed networks, but!
    • some use cases supported by grant MAY make sense to do “private”
    • activist use case
    • thus some of the “layers of security” research
    • people think very differently about mesh networks, we've found
    • so many possible use cases

Guardian Status: Hans

  1. troubleshooting on Android app
    • association and turn on/off
    • tablet testing (running ice-cream sandwich) - ad hoc mode not working
    • devices - ok, but needs more wide test on diff devices
  2. talking with olsrd team, but radically different stories from diff people!
  3. a bit ugly development picture unfortunately
  4. Henning - working on olsr version 2
    • Dutch Naval Contractor
    • folks are suggesting using what Henning is doing
      • but unclear what is going on with his status.
  5. What exists so far is a“really smart framework for writing routing daemons”
    • but, Josh can't find anything to use to build routing protocol. He has sent out some e-mails and will let the list know if he gets a response.

Josh: “Battle Mesh” - a hackfest and mesh protocol competition

  1. build a commitment to “vastly improving ad hoc mode” in Linux kernel
    • splitting out the wireless from the routing layer (olsr 2)
      • can send wireless routing data over the wire so multiple devices can act as antennas while routing on a paired device. This takes multiple low-cost devices and makes the cluster comparable to a far more expensive device.
      • They are working on a report and Josh will post this to the list when it is out.

HC : status on config

  1. also getting different stories from different people
    • seems like config needs to be done IN THE FILE with restart
    • not “live”

Josh:

  1. OK “for now” if this is best in olsr version 1
    • may have to wait for v2 for “live”
    • need to figure out what we need to support
    • similar to TXTINFO
    • “willingness” - based on battery power
    • he has found references, but not actually looked at the code.

Josh: unsure if this is true HC: simple rules( Plugged-in +1, un-plugged -1, low-battery -powers of x) looks at something in proc Josh will add some of this into his testing.

also want Android to share it's 3G connection as a network tether Josh: yes also, some way to use “smart gateway” plug in with

Would be great using smart-gateway (poss) to specify the amount of bandwidth provided. But, depending on complexity further down the line.

Smart-gateway functionality that is included in 6.2 that basically way for olsr to ip&ip-tunnel so if your gateway changs it tunnels back to your original gateway, so you bont break tcp sessions if you switch gateways and choose a gateway beyond olsr and specify how much up and down bandwidth the gateway has. (doesn't detect just specifies) More info can be found in olsr readme - extensions in git-tree.

README OLSR EXTENSIONS #5 Josh: no documented examples of actual use of this

Dave: how about based on app type, not low level? Josh: yes, possibly good idea others have tried

Dave: What is the actual user experience going to be? Maybe the fact that we will not have as dynamic a config as we like will be good for this trial. You know the scenario and can start up in a mode that is reasonable. Nothing that a real user can contemplate in the settings. So we need to encapsulate settings that make sense. We don't have any testing under out belt or real world use. What do we think about this mechanism about real world use.

Josh:

  1. thinking more generally now about connecting to the mesh
    • how do network manager and such work?
    • more generally, finding networks, etc
    • some way to store the SSID/Chan and give it a profile
    • generate an IP address from a certain range with defaults
    • how might a user DETECT a mesh network?
      • with config “scenario”?
    • should not aim to support “any scenario”
      • but make it extensible for future
  2. 802.11U - draft link level service advertisement
    • more network definition in the beacon

HC

  1. need a starting point
    • describing the network in the SSID?
    • BATMAN, BABEL, COMMOTION, etc

Josh: like it

HC: map out what data needs to be in the SSID “schema”

“Robin” project? “Confine” project? NY Resistor NOTE for Dave separation of “finding a suitable network” and “who to best use it”

protocol/parameters/addressing/channel/ssid/connect info/security and we should think about building extendability down the line if we want to support other protocols etc then we can build a characteristics of the network profile it makes it easier to extend info later on when we want to explore otehr features or 802.11U type link-level service advertisement so the beacons for a network contain information about the network type and they would already contain information about he network. FUCKING AWESOME! the device will automatically pick this up. a way of detecting mesh networks. A way of detecting and storing all info could be a good approach and this could include more specific stuff that describes how a network laid out

Now we can start describing a network by ssid “ad-hoc-olsrd2” tells you to start up olsrd etc and start chatting. So you would know that it is commotion network because it is “comm-olsr-dyn-ip-###(subnet)-” standardized approach for SSID's Hashing info in SSID or BSSID.

SSID gives a pretty long chunk to work with. What to put in there and configuration could be done with a shell script for network manager.

The different approaches would be 802.11U when it comes along, SSid encoding, Separate hidden SSid that nodes are always able to connect on to exchange info about the network (broadcast hidden BSSID like ROBIN networks does) exchange info by multi-cast DNS (significantly more complected and insecure) 802.11P?

Nate: test harness app? Josh: yes, need to come up with a testbed… working on instrumentation

Nate: finding the cheapest devices (Huawei) diversity of devices We need a starting point because merely connecting to a node may affect mbile devices. And all that comes after is what were working on. So we need that to work. In some scenarios for the guardian project the net might exist once, and never again. So connection is only one aspect of it, the parameters that come later make a difference. Mobile devices being connected to Internet through a mobile device or fixed aspect.

Maybe we can test out some specific parameters and how much they effect the characteristics of the network we connect to.

These scenarios try to address the conventional scenarios (crowds seeking a network, vs cafe, vs community, vs flash-mob, mobile has more scenarios where useful) Good idea to make a quick solution to discovery and connection service.

We will try to get them remote access to either test network or one of our deployed network. Combine project is also working on building a test network on the order of 100's or thousands of nodes. They reached to us to see what they have available.

Mobile nodes will appear and vanish and be flaky. Can we make nodes flaky? Or do we need 25 mobile phones working olsrd and test on that.

Josh: discussion about how to create a testbed HC: create packages (debian, etc) to allow people to start testing Josh: likes config profile ideas

Dave:

  1. proceed by
    • using HC's SSID idea
    • create static configs based on Dave's scenarios
    • so that future testing is “declarative” changes to config
      • rather than changes to the software itself

We have to have the REGIME of finding a suitable network. And a regime of how best to use it. We don't know the impact of the parameters so we have to delay the scenarios until we know net characteristics are. Next steps: develop test bed, or figure out type of test bed. We need to have a conversation about resources available. Some test beds can be used this way. Lets start a conversation on the list of available test beds. What information we need, what testing regiment need to be used to answer these questions, and what we need to add to test beds to make sure the testing regiment will work.

Josh: REDMINE - timeline stuff maybe not accurate will be sending note on this, talk to Andrew

Will get debian packages up to make it as easy as possible to get test bed. We can also get config profiles ready but without the profiles built in. Use case profiles with short descriptive names will be a good way to make profiles accessible to users who don't understand and a click for more information “this is a bunch of people with x connectivity” This may be good for restarting because it will be easier to create these static configs. we can create 5 configs that are all identical and check how parameters diversify. What does it mean to have 100 phones with on access vs 25 using one very fast fixed point. They would like to get as much as they can as soon as thy can.

profiles user pick commotion simple ssid network id rest is declarative Software and UX stays stable. Then we can say development is done and we need a lot of in field stuff.