SO!
Max had some trouble last night with notdhcp not detecting link state.
There turned out to be two problems. The first one was that I'd used an int
where it should have been a uin8_t which caused link state detection not to
work on any ar71xx hardware. That's fixed now and I tested it on a Bullet
M2.
The second issue was not so easily defeated. It turns out that there are no
netlink notifications for physical link state on switches. Instead, the
kernel always reports the linkstate as connected since the internal
ethernet interface is always connected to the internal switch. The
N600/N750 boards have integrated switches, and so do the nanostations. I'm
not sure about the nanobridges or picostations (I'd think not).
It wouldn't be completely insane to extend the switch driver with the
ability to report link state changes using netlink (the switch driver
already communicates to userland with netlink), and I've outlined my
findings on how this could be done here if anyone is really curious:
https://github.com/sudomesh/notdhcp/issues/2
However, we have a deadline and it turns out that the link state info can
be gotten with the swlib library which exists only as part of the swconfig
utility. It's a bit ugly that we can only detect link state changes by
polling but real ethernet drivers actually just poll in-kernel for these
changes anyway. I've copied the swlib source into the notdhcp repository.
Unfortunately that utility uses libnl and libnl-gen so now notdhcp has
library dependencies (which needs to be added to the sudowrt-packages
makefile and to the packages list).
Writing notdhcp has been much more of a rabbit hole than expected. But! We
want to be able to query switch port link status for purposes of the GUI
anyway and now we know that this is currently impossible (short of allowing
the running of arbitrary commands from the gui). I think once we've gotten
all this working I'll go back and move the switch status polling code over
to a fork of netifd and then make notdhcp use ubus to listen for the link
state changes.
Now the skylights are no longer black and that's my queue to call it a
night. I'll try to get this working before Tuesday.
--
marc/juul
Hi there
I've been trying to reach out to folks and show them people's open, like
at a couple of conferences I just spoke at here on the east coast, but
we have no website.
It's not terribly crucial, but is there a timeline on restoring it? It'd
be great to know so that I don't keep trying to pull it up in front of a
bunch of people :)
Thanks everyone!! Hope all is well
April
--
0x54FC570B
Hey folks,
I'm running a little late, but it does look like I successfully compiled an
ar71xx binary of notdchpclient and notdhcpserver. I've attached the ipks to
this email in case anyone is super anxious to get running with them,
otherwise I'll be at sudo a little after 8.
See ya!
Max
With help from Jake and Emborg I think I now have an idea how to go about
making the garden nodes do what we want.
We'll use the ESP8266-07 version which has a number of useful features over
the cheaper versions:
* A single ADC input (cheaper versions have none)
* Many more GPIO pins
* Shielded wifi chips
* Both ceramic on-board antenna and u.fl connector (not that we really need
either)
And it's still only $3.34 including shipping:
http://www.ebay.com/itm/ESP8266-Remote-Serial-Port-WIFI-Transceiver-Wireles…
We'll then use a 4051 chip to switch between eight different analog inputs.
These are dirt cheap (about 13 cents apiece if you buy 100):
http://www.aliexpress.com/item/CD4051BE-CD4051-4051-Free-shipping-100PCS/32…
Selecting analog input will take up three GPIO pins, but we have plenty.
We'll use three one-dollar solar garden lights:
http://www.dollartree.com/household/outdoor-living/Stainless-Steel-Solar-Po…
We will connect them such that their batteries are hooked up in series,
providing a maximum of 3.6 volts total for the ESP8266 (which happens to be
the maximum it can handle). If we're worried about too much voltage then
that can be dealt with easily, and the minimum voltage is 1.7 volts, which
makes things easy.
The ADC is 0-1 volts, so we'll use a voltage divider to read the voltage of
the three series-coupled batteries.
The ESP8266 has a deep sleep feature where it basically uses no power. It
can be programmed to wake up after custom amount of elapsed time. We'll
program it to wake up e.g. every ten minutes, measure the voltage, then
shut down if there is not enough. If there is enough voltage it will read
sensor data, connect over wifi, report data, and go back into deep sleep
mode.
We will measure soil humidity using a capacitance measurement which
requires two GPIO pins and two analog inputs. Treehearder already has the
code for this, it just has to be ported from an Atmel attiny to the
ESP8266. The sensor consists of two long pieces of conductive metal wrapped
in thin non-conductive insulation (two long pieces of iron in heat-shrink
tube should be good) and a couple of simple support components.
Measuring door opening/closing is still up for grabs. I'm not sure how to
do this reliable on any type of door/gate in a way that will be reliable
and won't break. On top of that it's not clear whether we'd need to check
door status more frequently than every few minutes but if we do then we'll
need some way to save "the door was opened" such that the ESP8266 will know
about it when it wakes up. This could be done with a simple flip-flop/latch
circuit.
For directional antennas we can make a laser-cuttable Yagi template (using
online template-generators and some inkscape foo), cut and hot-glue copper
elements onto the template and fit the assembled yagi into a piece of PVC
pipe and seal with hot glue. It probably makes sense to fit the ESP8266
inside of that tube as well and cover it in hot glue to avoid
condensation-related failure. Jake suggested that we simply solder the
ESP8266 board straight onto the yagi active element.
All of this being said, I'm 100% for mcgyvering the first prototype using
whatever is fast and easy!
--
marc/juul
Thoughts? This seems like it should be backwards compatible with heterogeneous nodes in a network?
-------- Original Message --------
From: Juliusz Chroboczek <jch(a)pps.univ-paris-diderot.fr>
Sent: April 14, 2015 5:21:30 AM PDT
To: babel-users(a)lists.alioth.debian.org
Subject: [Babel-users] ANNOUNCE: babeld-1.6.0
Dear all,
I am happy to announce that babeld-1.6.0 is available from
http://www.pps.univ-paris-diderot.fr/~jch/software/files/babeld-1.6.0.tar.gzhttp://www.pps.univ-paris-diderot.fr/~jch/software/files/babeld-1.6.0.tar.g…
For more information about babeld and the Babel routing protocol, please see
http://www.pps.univ-paris-diderot.fr/~jch/software/babel/
The main news in this version is that source-specific routing is part of
the stock babeld daemon. This is a large change, and is due to Matthieu
Boutier. For more information about source-specific routing, please see
Matthieu Boutier and Juliusz Chroboczek.
Source-specific routing.
To appear in Proc. IFIP Networking 2015.
http://arxiv.org/pdf/1403.0445
Enjoy,
-- Juliusz Chroboczek
------------------------------------------------------------------------
_______________________________________________
Babel-users mailing list
Babel-users(a)lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
Today April and I spoke with Tim and Chris about our
problems with obtaining an uplink. The tl;dr version is that
we have two possibilities for circumventing the last-mile
shakedown: BART and radio links.
You probably don't need to read the rest. :)
First off, the prices quoted to us for a 1Gbit were fairly
normal. They are due to the last-mile being neither competitive
nor transparent. Zayo may still be an option, but getting the
building wired for fiber may be a huge ordeal and it still might
be very expensive.
The only workaround may be to find an alternative, cheaper
route to a data center; IP transit is cheap these days and
getting cheaper. There are two sources of problems
here: transport (the connection from our network to a
data center) and data center internals.
The data centers we have available to us are: "365 Main St."
in downtown Oakland, Evocative in Emeryville, and then
things further away such as Hurricane Electric. Unfortunately,
the AT&T CO near the Omni is probably not useful to us.
There's a whole lot of cost and complexity involved in getting into a
data center and it would be nice to avoid paying for co-location.
Transport is tricky. We learned that BART can provide transport
(not just dark fiber leases), but we don't know where we can
connect to them physically, so an additional radio or fiber link
may be necessary. Don't know how much it'll cost.
The other intriguing option is a two-hop radio link (up to the
hills and then down to a data center). We discussed using
licensed bands for this, and it seems feasible with some
perseverance. Again, don't know much it'll cost.
We also discussed my idea of attaching fiber to poles, which
seems to be feasible in theory but probably prohibitively expensive
for us.
Alex
http://192.241.217.196/smokeping/smokeping.cgi?displaymode=n;start=2014-10-…
That's a graph of delay times for a "cloud" server to reach the omni
network. The results are pretty awesomely clear. This translates to real
improvement in network performance at the omni. I imagine that most people
have already experienced this :-)
Anyhow - just a thanks to everyone who got this together - just the very
first step on improving connectivity in the east bay!
