Would someone mind setting reply to list instead of sender?
-------- Original Message --------
From: Charles N Wyble <charles(a)thefnf.org>
Sent: Fri Dec 06 08:29:40 CST 2013
To: Mitar <mitar(a)tnode.com>
Subject: Re: [Mesh] NSA and OpenWRT
Calea doesn't need to mod the end modem to do interception. If you are transiting the modem, you are going through the CO, where they can tap.
Tr069 is a really nice standard for mass configuration at scale. Open source bits exist, I've not been able to play with them yet.
So the linked technologies aren't really in support of the articles main point.
Now in the case of all in one residential gateways, internal traffic is very susceptible to intercept.
My home network is setup like this
Cable modem -> pfsense edge router -> core switch (cisco 3550) -> core ap (wndr3800 running openwrt).
I've also tapped the outside of the pfsense (modem Ethernet side) and seen very large amounts of neighborhood WAN traffic. So I don't even need to be the government or telco to spy. Just think, they only need to comp some modems per neighborhood to see everything.
I run all my DNS lookups over a VPN connection to a non logging resolver in an on net facility. I've considered running all my traffic out the Colo and via tor, but I'm not that paranoid yet. He he.
Interesting article for sure. Remember that openwrt can be comped as well and WiFi can be trivially tapped.
Mitar <mitar(a)tnode.com> wrote:
>Hi!
>
>Maybe of interest to some:
>
>https://forum.openwrt.org/viewtopic.php?id=47703
>
>
>Mitar
--
Charles Wyble charles(a)thefnf.org
818 280 7059
CTO / co founder thefnf.org and guifi.us
--
Charles Wyble charles(a)thefnf.org
818 280 7059
CTO / co founder thefnf.org and guifi.us
I've been having too much fun in the pacific northwest. If there's anything for me to do I'll be around tonight. I'll try to be on irc and you can always email.
Have a good meeting!
Maybe somebody can clear this up, but what does supported hardware mean? I
was expanding our walkthrough this weekend by trying to build my own
openWRT image with Buildroot. Please correct me if I'm wrong, but I thought
we mainly needed openWRT with the appropriate drivers in the image. If not,
then what else? (IPsec for tunneldigger, etc.)
Pete brought a router that wasn't on the supported hardware list because it
had been a revised router. It was a D-Link 601 B1 and he had a custom built
openWRT image he found on the internet. A lot of my interest with the
project is people being able to repurpose their routers, either
automatically with software, or manually through a comprehensive guide.
Ideally middle school/high school kids should be able to convert their
routers.
In other words, if you plan on not keeping these routers around, I would
rather use them to test firmware builds. Sorry Pete, I don't want to brick
your router. :P Also, I'm interested in expanding the walkthrough more at
this week's hack night if anybody is interested.
Jeremy
On Tue, Dec 3, 2013 at 12:00 PM, <mesh-request(a)lists.sudoroom.org> wrote:
> Send mesh mailing list submissions to
> mesh(a)lists.sudoroom.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.sudoroom.org/listinfo/mesh
> or, via email, send a message with subject or body 'help' to
> mesh-request(a)lists.sudoroom.org
>
> You can reach the person managing the list at
> mesh-owner(a)lists.sudoroom.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of mesh digest..."
>
>
> Today's Topics:
>
> 1. Re: Wi-Fi gear (mark burdett)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 2 Dec 2013 22:27:54 -0800
> From: mark burdett <mfburdett(a)gmail.com>
> To: "mesh(a)lists.sudoroom.org" <mesh(a)lists.sudoroom.org>
> Subject: Re: [Mesh] Wi-Fi gear
> Message-ID:
> <CALd=3MJ-6ANdtzm8=
> gZiMo5-0YQQrCMr8uip2bxd6Bc+Rp+m2A(a)mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Ok I looked up OpenWRT compatibility. I will start trying to find homes for
> this stuff, but let me know if it's useful.
>
> 1 ? Asus RT-N53
> >
> Don't think it supports OpenWRT
>
> > 1 ? Belkin N450 DB
> >
> Don't think it supports OpenWRT
>
> > 1 ? Linksys WRT54GL
> >
> Supports OpenWRT but maybe not worth keeping around?
>
> > 1 ? Linksys WRT54GL v1.1
> >
> Supports OpenWRT but maybe not worth keeping around?
>
> > 1 ? Linksys WRT300N v1
> >
> Supports OpenWRT
>
> > 1 ? Netgear WNDR3300
> >
> Supports OpenWRT
>
> > 5 ? Netgear WNDR4000
> >
> Supports OpenWRT
>
> > 1 ? Netgear WG311v3 (PCI card)
> >
> N/A it's a PCI card :)
>
> --mark
>
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.
