As some of you may already know, Noisebridge received a donation of
somewhere in the neighborhood of 250 "Meraki Outdoor" routers. I moved most
of them to sudo mesh so they wouldn't disappear from Noisebridge. I expect
we'll have around 150 of them once we've given some out to everyone who has
declared interest.
They're nearly the same specs and chipset as the picostations. The chipset
is an AR2317 instead of an AR2315 and it has an extra ethernet adapter and
only 200 mW of output power.
Here's a datasheet:
https://meraki.cisco.com/lib/pdf/meraki_datasheet_outdoor.pdf
To use them, we need to solve four problems:
* Antennas. They use the same connectors as mini-pci cards. I took apart
a broken laptop at sudo room and extracted two antennas, but that's
probably not a viable solution for all of them. We need a source for these
antennas, but I don't know the official name of that type of connector.
* PoE injectors. They take 5 to 22 volts.
* Cases: For indoor use we can use dollar store food storage cases. For
outdoor we can use cases design for outdoor electrical installations
(Mitar's suggestion). If someone's handy with 3D modeling we could also 3D
print cases. PLA is fine for indoor, but for outdoor we need ABS plastic
which requires a heated print bed.
* Software: I've been trying to get OpenWRT running on these, but it has
proven difficult.
The watchdog reboots the routers after 5 minutes and nothing can be done to
stop that from within the built-in RedBoot. Unfortunately it takes longer
than 5 minutes to flash them with OpenWRT. I've written a script that
flashes the routers in four stages, using a serial console and tftp over
ethernet and it works:
https://github.com/sudomesh/merakiflasher
There are two remaining problems. One is that the sudomesh firmware boots
up and then immediately issues a shutdown command. This should be fairly
simple to solve but I haven't delved into it.
The second issue is the watchdog. The official meraki firmware that comes
with the routers correctly talks to the watchdog. Normal OpenWRT does not.
The kernel driver for the AR2315 watchdog is supposed to create the
/dev/watchdog device and the watchdog can be controlled from userland by
the watchdog daemon (part of busybox utilities) by writing to /dev/watchdog
or issuing ioctls. I've spent some time debugging the issue.
The relevant files are:
drivers/watchdog/ar2315-wtd.c
arch/mips/ar231x/ar2315.c
arch/mips/ar231x/devices.c
arch/mips/include/asm/mach-ar231x.h
The watchdog is being controlled by writing to memory-mapped registers
defined in mach-ar231x.h and by compiling a kernel with lots of printk
statements inserted into these files I have verified that the register
write functions are being called at the correct times.
I can imagine three things that may be going wrong:
1. The memory mapped register addresses in mach-ar231x.h are different
for the AR2317 chipset (this seems unlikely based on the info I've been
able to find).
2. The registers are not being mapped into memory correctly. I don't know
where to find the code that deals with the MMU and mapping registers.
3. There is some additional initialization required for the AR2317
watchdog that isn't being handled correctly.
4. The register read/write functions are not implemented correctly. These
seem to be implemented in arch/mips/include/asm/mipsregs.h as assembly, but
the actual ar231x_write_reg function is defined as:
static inline void
ar231x_write_reg(u32 reg, u32 val)
{
__raw_writel(val, (u32 *) KSEG1ADDR(reg));
}
and __raw_write is defined in include/asm-generic/io.h as:
static inline void __raw_writel(u32 b, volatile void __iomem *addr)
{
*(volatile u32 __force *) addr = b;
}
So it's just an assignment. Maybe if the registers are not getting memory
mapped (no idea how to check if they are) we should instead be using
something like:
#define __write_32bit_c0_register(register, sel, value) \
do { \
if (sel == 0) \
__asm__ __volatile__( \
"mtc0\t%z0, " #register "\n\t" \
: : "Jr" ((unsigned int)(value))); \
else \
__asm__ __volatile__( \
".set\tmips32\n\t" \
"mtc0\t%z0, " #register ", " #sel "\n\t" \
".set\tmips0" \
: : "Jr" ((unsigned int)(value))); \
} while (0)
from mipsregs.h
I'm not sure. I'm speculating at this point.
Adrian: I could really use some help on this. Do you have time to join us
for a hack night soon? or maybe we can just meet on irc?
--
marc/juul
Inspired by last week's conversation, I experimented with MAC
randomization on my laptop. And I DoS'd my own network by exhausting
its DHCP pool.
My very naive script reset the MAC after every network hiccup, so the
router kept seeing an entirely new device and giving it a new IP
address. Slowly. Until they were all gone. I "solved" my problem the
stupid way by rebooting the router and lowering the DHCP timeout from
24 to 3 hours.
A production script would be clever about resetting it only on new
associations, and not on every brief reassociation. However, still
something to keep in mind when deploying networks that encourage this
sort of thing. ;)
Hi!
I remember you had some discussion about how to flash routers. I think
there are several options:
- having a generic firmware you configure by hand/webinterface
- having a image generator which generates image with all configuration
included for a particular node
- having an generic autoconfiguring firmware, which
- does everything by itself
- optionally fetches additional/configuration data from the
network/central server
- registers at first boot with networks/central server
Am I missing any?
Some possible relevant links for flashing and ideas:
- https://github.com/battlemesh/openwrt-config-system
- https://dev.wlan-si.net/ticket/1135
- https://dev.wlan-si.net/ticket/654
- https://dev.wlan-si.net/ticket/1153
Some ideas we were playing around as well:
- a phone app which you install, connect to the existing original
wireless network of the node you want to flash, press a button and it
flashes
- entering your public IP of your home router you want to flash and some
server flashes the node for you over the Internet
Mitar
--
http://mitar.tnode.com/https://twitter.com/mitar_m
Here are my tweaks to the firmware from a few days back.
Changes made:
* build script uses /bin/bash instead of /bin/sh
* Patches the openwrt telnetd to accept a -I interfacename option
(in openwrt_addons/package/busybox/patches/960-telnetd-bindtodevice.diff)
* refactored check to see if root PW is set into files/lib/functions/auth.sh
* files/etc/init.d/telnet now sets the -I eth0 option, and will set the
IP default TTL to 1 if the root PW isn't set.
* files/etc/hotplug.d/iface/20-ntpclient will only be run if the root PW has
been set.
* prepare - copies openwrt_addons into built_firmware/openwrt/ before
building; now just copies openwrt_config/feeds.conf into the build dir,
moving the old one to feeds.conf.old if they differed. This fixes the
bug where re-running prepare would cause piles of spurious errors as
feeds.conf grew.
Hi folks,
I have the following gear available for donation to worthwhile causes,
like community mesh networks :) Please let me know if any of it'd be
useful.
1 × Asus RT-N53
1 × Belkin N450 DB
1 × Linksys WRT54GL
1 × Linksys WRT54GL v1.1
1 × Linksys WRT300N v1
1 × Netgear WNDR3300
5 × Netgear WNDR4000
1 × Netgear WG311v3 (PCI card)
--mark B.
hey guys n gals,
I just discovered your mesh project, and I'd like to contribute somehow.
Are you still in need of hardware?
https://sudoroom.org/wiki/Mesh/Wishlist
What would be most useful?
best,
Jared
The attachments are of particular interest to the history of WiFi efforts in Oakland and the political economy surrounding the different initiatives.
Deborah Acosta, as many know, is now the Chief Innovation Officer of San Leandro.
There are also some documents that are not for public distribution outlining how things fell apart within the Oakland municipal government.
> From: "Deborah Acosta" <dacosta(a)idotconnect.net>
> Subject: RE: [sudo-discuss] Freedom of Information requests
> Date: January 25, 2013 3:42:52 PM EST
> To: "'Eddan Katz'" <eddan(a)eddan.com>, "'mark burdett'" <mark(a)510pen.org>
> Cc: <sudo-discuss(a)lists.sudoroom.org>, "'Susan Mernit'" <mernit(a)gmail.com>
>
> Eddan: Here, let me help to make it easier. I’ve attached a City RFP issued in 2006, the final report issued by the consultant and the final staff report that resulted from four years of work on the city wide wi-fi project. The stories I could tell you. Ultimately, the report found that the City’s fiber infrastructure was inadequate to implement such a project – and the City Council didn’t “get it” anyway.
>
> The next story is about the public/private partnership (City, IP Network and Cisco) that applied for a federal ARRA grant in 2010 to build a $35 million fiber optic network throughout the City. Didn’t get the grant. Then my subsequent efforts to pick up the pieces (see attached Executive Summary and powerpoint completed 2 weeks before I left in June 2011). No one has picked up this project since I left.
>
> See Mark – you just have to ask the right person!!! Call me if you have questions.
>
> Work wasn’t wasted – San Leandro has hired me to become its first Chief Innovation Officer to represent Lit San Leandro and create a tech business development strategy in that City.
>
> Debbie
>
> Deborah V. Acosta
> Principal, iDOTconnect
> Co-Chair, 2.Oakland
> Tel: (510) 508-7926
> Email: dacosta(a)iDOTconnect.net
> Web: www.iDOTconnect.net
> Web: www.twopointoakland.com
> Facebook: https://www.facebook.com/TwoPointOak
>
> sudo-discuss mailing list
> sudo-discuss(a)lists.sudoroom.org
> http://lists.sudoroom.org/listinfo/sudo-discuss
>
>
>
