-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi all,
Marc and I are currently tap-tap-tapping away on a grant application
for $100/250/500k due tomorrow at midnight. We have the honor of being
fiscally sponsored for this application by Media Alliance, an Oakland
nonprofit supporting citizen media, advocacy and youth technology
education. They are awesome!
I've been diving deep back into the Oakland broadband feasibility
study published in 2009: https://sudoroom.org/wiki/Mesh/Oakland#Research
In pursuit of more recent information on the state of Oakland
organizations addressing the digital divide, and Internet access more
generally, here's what I've been reading:
*
http://www.ebbroadband.org/PDF/Cities_-_graded/Alameda_County_Oakland_Grade…
*
http://www.insidebayarea.com/opinion/ci_25010367/must-make-investment-make-…
*
http://oaklandlocal.com/2013/12/the-wifi-scorecard-connecting-the-dots-of-o…
*
http://oaklandlocal.com/2014/02/get-fast-oakland-east-bay-broadband-summit-…
^ This one even mentions the Oakland North article on Sudo Mesh, with
the accompanying phrase "has largely been met with political
gridlock." I've written to Susan Mernit asking for a correction to the
article and updating her on where we're actually at - and offering to
write an article on our project.
I'm going to reach out to Kevin at the East Bay Broadband Consortium,
and set up a meeting to talk about how we could work together.
Your feedback, links to other articles/studies, appreciated.
I'll be documenting the local stuff here:
https://sudoroom.org/wiki/Mesh/Oakland
Mesh the planet!
- --
Jenny
http://jennyryan.nethttp://sudomesh.orghttp://thevirtualcampfire.orghttp://technomadic.tumblr.com
`~`~`~`~`~`~`~`~`~`~`~`~`~`~`~`~`~`~`
"Technology is the campfire around which we tell our stories."
- -Laurie Anderson
"Storytelling reveals meaning without committing the error of defining
it."
-Hannah Arendt
"To define is to kill. To suggest is to create."
- -Stéphane Mallarmé
~`~`~`~`~`~`~`~`~`~`~`~`~`~`~`~`~`~`
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJTORWrAAoJEHTWWpBUSeDhyX4IALmpbUE3fKXZ8oOkqnq6Q7mB
wWat5rpOGgVX1EgfVgTiP81X2w6/36BFDU7rk1d7y4hvAO775oqKFxsAxjDvrHR5
PkJKPvaEHmnCuRpJSHWrBr7XVbTD7K2WqC4C+Zvwcj7/1KoPoSPY5DpFp2kKYMLH
RZzajqS4GFD4ptXfuFB64G5F3ZYDqwoQ2QhODKADgvkduDwZym4B6bDmDNhkWGRz
QyLjjvUqKvjtpn0+aTgjH/nLN/MvJXVuo0uQ9S9PDQlRWNhdG6fSSutdCi+6PVlE
xGS8TKVbQGpdOAEwvtyjRzl2yV54HtsF17QtNWFoQ2CtPnwpd+6DygNL9O0qTGk=
=jpV3
-----END PGP SIGNATURE-----
peoplesopen.net is telling folks at Sudoroom to use 10.0.99.1 for DNS,
but that nameserver is not working. IP connectivity works but regular
users can't resolve names. Is this a nameserver that mesh controls?
Any way we can help? :)
Hi!
Anyone interested? Probably I could connect.
"Roger Dingledine, the creator of Tor, plans a Q&A session for this
Wednesday or Friday as part of his Berkeley visit. This is great
opportunity to hear about the current state at the intersection of
privacy, anonymity, and censorship. Please let me (or Roger directly)
know if you would be interested in attending, with an indication of
which day would work better for you. He's may also be available for
potential lunches and dinners, if you are interested in meeting with
him in person."
Mitar
--
http://mitar.tnode.com/https://twitter.com/mitar_m
Hey all,
First version of the network diagram for technical documentation. Hopefully
folks can use a derivative of this to create other graphic diagrams and
drawings for paper manuals, online instructions, etc.
The font is Anaheim, it's open source and online.
// Matt
Thanks to this hack, we should be able to use a noisebridge-donated lot of ~200 sparky routers for https://peoplesopen.net/
Cheers!
// Matt
----- Reply message -----
From: "Adrian Chadd" <adrian.chadd(a)gmail.com>
To: "mesh(a)lists.sudoroom.org" <mesh(a)lists.sudoroom.org>
Subject: [Mesh] So, about those Meraki Sparky boards
Date: Wed, Mar 26, 2014 18:34
A little drinking at Noisebridge and some poking from JC got me
thinking about the Sparky boards. So I came up to Sudo and worked with
Marc to figure it out.
The TL;DR version: It's an AR2317 and you have a watchdog timer, but
it doesn't actually reset the unit. It just posts an interrupt. It
turns out GPIO6 is the "pat to stop it resetting" line.
So, the details:
I first did "help" at the redboot prompt. I found "bdshow", which is
the "Atheros board info."
RedBoot> bdshow
name: Meraki Outdoor 1.0
magic: 35333131
cksum: 2a1b
rev: 10
major: 1
minor: 0
pciid: 0013
wlan0: yes 00:18:0a:50:7b:ae
wlan1: no 00:00:00:00:00:00
enet0: yes 00:18:0a:50:7b:ae
enet1: no 00:00:00:00:00:00
uart0: yes
sysled: no, gpio 0
factory: no, gpio 0
serclk: internal
cpufreq: calculated 184000000 Hz
sysfreq: calculated 92000000 Hz
memcap: disabled
watchdg: disabled (WARNING: for debugging only!)
serialNo: Q2AJYS5XMYZ8
Watchdog Gpio pin: 6
secret number: e2f019a200ee517e30ded15cdbd27ba72f9e30c8
.. hm. Watchdog GPIO pin 6? What's that?
After manually checking out the watchdog registers via 'x', we
discovered that it would count down to 0 and not reset.
So, hm. Maybe the GPIO 6 wire is actually the right thing to pat. And
yes, the board doesn't reset when you pat GPIO 6.
Board: ap61
RAM: 0x80000000-0x82000000, [0x8003ddd0-0x80fe1000] available
FLASH: 0xa8000000 - 0xa87e0000, 128 blocks of 0x00010000 bytes each.
== Executing boot script in 2.000 seconds - enter ^C to abort
^C
RedBoot> # set direction of gpio6 to out
RedBoot> mfill -b 0xb1000098 -l 4 -p 0x00000043
RedBoot> x -b 0xb1000098
B1000098: 00 00 00 43 00 00 00 00 00 00 00 00 00 00 00 03 |...C............|
B10000A8: FF EF F7 B9 7D DF 5F FF 00 00 00 00 00 00 00 00 |....}._.........|
RedBoot> # pat gpio6 - set it high, then low.
RedBoot> mfill -b 0xb1000090 -l 4 -p 0x00000042
RedBoot> mfill -b 0xb1000090 -l 4 -p 0x00000002
.. then I manually did this every minute or so.
RedBoot>
RedBoot> mfill -b 0xb1000090 -l 4 -p 0x00000042
RedBoot> mfill -b 0xb1000090 -l 4 -p 0x00000002
RedBoot> mfill -b 0xb1000090 -l 4 -p 0x00000042
RedBoot> mfill -b 0xb1000090 -l 4 -p 0x00000002
.. so, the solution here seems to be to "set gpio6 to be output", then
"pat it every 60 seconds."
-a
_______________________________________________
mesh mailing list
mesh(a)lists.sudoroom.org
https://lists.sudoroom.org/listinfo/mesh
A little drinking at Noisebridge and some poking from JC got me
thinking about the Sparky boards. So I came up to Sudo and worked with
Marc to figure it out.
The TL;DR version: It's an AR2317 and you have a watchdog timer, but
it doesn't actually reset the unit. It just posts an interrupt. It
turns out GPIO6 is the "pat to stop it resetting" line.
So, the details:
I first did "help" at the redboot prompt. I found "bdshow", which is
the "Atheros board info."
RedBoot> bdshow
name: Meraki Outdoor 1.0
magic: 35333131
cksum: 2a1b
rev: 10
major: 1
minor: 0
pciid: 0013
wlan0: yes 00:18:0a:50:7b:ae
wlan1: no 00:00:00:00:00:00
enet0: yes 00:18:0a:50:7b:ae
enet1: no 00:00:00:00:00:00
uart0: yes
sysled: no, gpio 0
factory: no, gpio 0
serclk: internal
cpufreq: calculated 184000000 Hz
sysfreq: calculated 92000000 Hz
memcap: disabled
watchdg: disabled (WARNING: for debugging only!)
serialNo: Q2AJYS5XMYZ8
Watchdog Gpio pin: 6
secret number: e2f019a200ee517e30ded15cdbd27ba72f9e30c8
.. hm. Watchdog GPIO pin 6? What's that?
After manually checking out the watchdog registers via 'x', we
discovered that it would count down to 0 and not reset.
So, hm. Maybe the GPIO 6 wire is actually the right thing to pat. And
yes, the board doesn't reset when you pat GPIO 6.
Board: ap61
RAM: 0x80000000-0x82000000, [0x8003ddd0-0x80fe1000] available
FLASH: 0xa8000000 - 0xa87e0000, 128 blocks of 0x00010000 bytes each.
== Executing boot script in 2.000 seconds - enter ^C to abort
^C
RedBoot> # set direction of gpio6 to out
RedBoot> mfill -b 0xb1000098 -l 4 -p 0x00000043
RedBoot> x -b 0xb1000098
B1000098: 00 00 00 43 00 00 00 00 00 00 00 00 00 00 00 03 |...C............|
B10000A8: FF EF F7 B9 7D DF 5F FF 00 00 00 00 00 00 00 00 |....}._.........|
RedBoot> # pat gpio6 - set it high, then low.
RedBoot> mfill -b 0xb1000090 -l 4 -p 0x00000042
RedBoot> mfill -b 0xb1000090 -l 4 -p 0x00000002
.. then I manually did this every minute or so.
RedBoot>
RedBoot> mfill -b 0xb1000090 -l 4 -p 0x00000042
RedBoot> mfill -b 0xb1000090 -l 4 -p 0x00000002
RedBoot> mfill -b 0xb1000090 -l 4 -p 0x00000042
RedBoot> mfill -b 0xb1000090 -l 4 -p 0x00000002
.. so, the solution here seems to be to "set gpio6 to be output", then
"pat it every 60 seconds."
-a
