Right now makenode has configs that are trying to handle differences in
chipsets, frequency, etc. in a way that's agnostic of the actual router
model. That's cool, but maybe more trouble than it's worth (at least for
now).
Unless there are objections I'm going to change it so we have one
configuration per router model. I want us to get to a point, very soon,
where we have the following working and separate configurations:
* Nanobridge M5
** Bridging only
* Nanostation M5
** Bridging only (on both ethernet ports)
* Nanostation M2
** Bridging only (on both ethernet ports)
* Western Digital My Net N600/N750
** Full sudowrt firmware with the 5 GHz radio only having
pplsopen.net-node2node
The My Net has five ethernet ports. I'm thinking we can configure them like
so:
Port 1: To home DSL/Cable Internet connection (if any)
Port 2: Connect your local gear to the mesh (like peoplesopen.net ssid but
wired)
Port 3: Connect a Nanostation M2 which is basically like adding an antenna.
You'd use this to extend your coverage out onto the street (or you could
just add an actual antenna if that's feasible given distance between
routers and coaxial loss).
Port 4 and 5: Connect rooftop Nanobridge M5s or Nanostation M5s.
In the future we should consider making it possible to easily reconfigure
these, both at initial configuration time and through an "advanced" tab in
the GUI, but for now I think it's much easier to have ports dedicated to
each operation.
Here's how we'd use this in different scenarios:
# We're just relaying off someone's rooftop
We'd have two or more Nano(bridge/station) M5s on the roof and they'd just
connect to each-other. They're already bridging so no extra configuration
is needed.
# Someone just wants to be part of the mesh without paying a lot
They get a My Net N600 and hook it into their internet, if any.
# Someone wants a rooftop link and wants to use the mesh in their house
They get a My Net N600 and hook it into their internet, if any, and they
hook their rooftop-mounted Nano(bridge/station) into port 4 or 5 of the My
Net.
# Previous scenario but with more street-level coverage
They additionally hook in a Nanostation M2 to port 3 of the My Net or they
hook in one or more external antennas to the My Net using the internal u.fl
connectors. The second solution is definitely not something we should
encourage for people who aren't already comfortable with that level of DIY.
-----
One possible downside to this setup is that all of the CPU-intensive stuff
is handled by the My Net router and the other (very capable) devices are
just bridging. I think the solution is to accept this less-than-perfect
solution for now and rely on whatever future router we decide to use as a
My Net replacement to have a much faster CPU (this is probably a safe bet).
I should mention that Max and Adri today discovered that CPU _is_ a huge
limiting factor on the Picostation 2 routers, so if we put too much load on
the (granted much much faster, maybe 7-8 times faster) newer devices it may
become an issue again.
We just ordered five Western Digital My Net N750 routers for use in the
Omni test network, and I think the N600 version (same, but non-gigabit and
cheaper) is a good candidate for home-routers that we can give to people.
Thoughts?
--
marc/juul
On Thu, Mar 5, 2015 at 11:34 AM, yar <yardenack(a)gmail.com> wrote:
> It's at maybe the worst possible time (6pm tonight) but there's
> nothing we can do about it. We'll try to make it as quick & smooth as
> possible.
all done!
He said that they would want $2,200 per month for transport from pretty
much any location to us. brutal....
On the bright side, he did point me towards the CTF thing.
---------- Forwarded message ----------
From: Jones, MikeCA <Mike_Jones(a)cable.comcast.com>
Date: Thu, Mar 5, 2015 at 2:01 PM
Subject: RE: Transport Rates from Hurricane Electric Fremont
To: max b <maxb.personal(a)gmail.com>
Hi Max,
Here’s the link to the California Teleconnect Fund website and application
process. One or all of your non-profits may qualify. In that case, we can
give you a 50% discount on our fiber circuits. For Example, 100meg fiber
connection at $1000, would be $500. This is layer 2 dedicated enterprise
class fiber with sla’s.
http://www.cpuc.ca.gov/PUC/Telco/Public+Programs/CTF/Application.htm
Thanks
Mike
*Mike Jones | Enterprise Ethernet Fiber Division *
Comcast Business Services | Western Region
Cell: 916-903-3761 best | Office: 916-830-6719
mike_jones(a)cable.comcast.com
It's at maybe the worst possible time (6pm tonight) but there's
nothing we can do about it. We'll try to make it as quick & smooth as
possible.
---------- Forwarded message ----------
From: <support(a)linode.com>
Date: Sun, Mar 1, 2015 at 11:35 AM
Subject: Linode Support Ticket 4254236 - Critical Xen Maintenance /
Reboot Schedule
Hello,
Linode recently received several Xen Security Advisories (XSAs) that
require us to perform updates to our host servers. In order to apply
the updates, hosts and the Linodes running on them must be rebooted.
The XSAs will be publicly released by the Xen project team on March
10th, therefore we must complete the updates before that date.
These updates are required to protect the security and safe operations
of not only our infrastructure, but yours as well. We understand that
a disruption with such limited notice is inconvenient, and we hope you
understand that these measures are warranted due to the severity of
the XSAs.
Your Linodes have been assigned a maintenance window in which a reboot
will occur. These times are listed within the Linode Manager[1] in the
timezone set in your user's My Profile[2]. Your schedule in UTC
timezone is as follows:
* 2015-03-06 2:00:00 AM UTC - sudoserver
During the maintenance window Linode instances will be cleanly shut
down while we perform the updates. Your Linode will be inaccessible
during this time. A two-hour window is allocated, however the actual
downtime can be much less. After the maintenance, each Linode will
then be booted. See our Reboot Survival Guide[3] for tips and hints on
configuring and testing that your Linode services boot properly after
the maintenance.
Unfortunately, due the logistical demands of this effort, your
assigned windows are not changeable and the host reboots are
mandatory.
For general information, please see our status post:
<http://status.linode.com/incidents/2dyvn29ds5mz>
Please let us know if there is anything we can do to assist.
[1] <https://manager.linode.com/linodes>
[2] <https://manager.linode.com/profile>
[3] <https://www.linode.com/docs/uptime/reboot-survival-guide>
-Linode
On Tue, Mar 3, 2015 at 3:37 PM, niki <niki.shelley(a)gmail.com> wrote:
> I have the ip address and we're getting over 100Mbps down if what the LMI
> guy said is to be trusted.
Great. It's important that it configured to be a static IP address. Do
you know if it was?
It looks like we haven't touched our router, it's still connected to
the old uplink, so that will have to be migrated. Let's do that at a
less high traffic time than Tuesday night and also wait to cancel
Sonic service until we finish doing that?
Hey Niki,
Let me know if you can't get a hold of Marc, or if they're still looking
for someone. I wasn't aware that they were coming over today, but we
definitely need to get this together and I'd be happy to run over and hold
their hand and/or whatever they need.
Max
On Tue, Mar 3, 2015 at 2:56 PM, niki <niki.shelley(a)gmail.com> wrote:
> I guess we have new internet now!
>
> Someone from LMI came by looking for Marc.
>
> I'd like to ask people that if, in the future, you schedule a service like
> this you try to find someone to be here if you are not able to be, please.
>
> So anyway, let me know who I need to give the relevant information to.
>
> N
>
> _______________________________________________
> discuss mailing list
> discuss(a)lists.omnicommons.org
> https://omnicommons.org/lists/listinfo/discuss
>
>
Hey just wanted to mention that it does appear as though 100.0.0.0/12 does
get routed by a number of internet hosts:
traceroute -n 100.1.1.1
> 1 192.168.2.1 16.953 ms 18.672 ms 26.622 ms
> 2 192.168.1.1 63.993 ms 66.595 ms 67.210 ms
> 3 50.185.26.1 81.620 ms 84.669 ms 87.114 ms
> 4 68.87.196.89 91.254 ms 91.479 ms 92.388 ms
> 5 68.87.57.221 87.381 ms 68.87.55.229 104.986 ms 68.87.55.225 106.784
> ms
> 6 68.85.155.234 109.069 ms 68.85.155.238 91.181 ms 68.85.155.234
> 102.066 ms
> 7 * * *
> 8 68.86.86.102 106.262 ms 106.159 ms 106.481 ms
> 9 68.86.82.94 100.819 ms 104.484 ms 101.623 ms
> 10 23.30.206.94 139.012 ms 138.273 ms 158.165 ms
> 11 130.81.209.171 193.143 ms * *
> 12 * * *
> 13 100.1.1.1 159.241 ms 155.888 ms 156.733 ms
>
or
traceroute 100.1.1.1
> traceroute to 100.1.1.1 (100.1.1.1), 30 hops max, 60 byte packets
> 1 192.168.2.1 (192.168.2.1) 41.102 ms 41.890 ms 44.911 ms
> 2 192.168.1.1 (192.168.1.1) 50.067 ms 50.663 ms 51.156 ms
> 3 50.185.26.1 (50.185.26.1) 60.095 ms 61.839 ms 87.606 ms
> 4 GE-2-37-ur01.fremontcev2.ca.sfba.comcast.net (68.87.196.89) 103.734
> ms 104.030 ms 177.000 ms
> 5 te-0-7-0-21-sur03.oakland.ca.sfba.comcast.net (68.87.57.221) 176.024
> ms te-0-7-0-19-sur03.oakland.ca.sfba.comcast.net (68.85.57.141) 176.480
> ms te-0-7-0-21-sur03.oakland.ca.sfba.comcast.net (68.87.57.221) 176.684
> ms
> 6 te-0-2-0-5-ar01.sfsutro.ca.sfba.comcast.net (69.139.199.78) 178.344
> ms te-0-2-0-0-ar01.sfsutro.ca.sfba.comcast.net (68.85.155.234) 19.639 ms
> te-0-2-0-7-ar01.sfsutro.ca.sfba.comcast.net (68.87.194.50) 41.532 ms
> 7 * * *
> 8 he-2-9-0-0-cr01.losangeles.ca.ibone.comcast.net (68.86.86.102)
> 59.336 ms 98.858 ms 98.859 ms
> 9 be-13-pe02.11greatoaks.ca.ibone.comcast.net (68.86.82.94) 98.056 ms
> 102.286 ms 99.433 ms
> 10 23.30.206.94 (23.30.206.94) 273.404 ms 274.855 ms 276.308 ms
> 11 B200.NWRKNJ-LCR-22.verizon-gni.net (130.81.209.171) 301.458 ms
> P0-15-0-0.NWRKNJ-LCR-22.verizon-gni.net (130.81.199.17) 301.773 ms
> 302.699 ms
> 12 * * *
> 13 L101.NWRKNJ-VFTTP-142.verizon-gni.net (100.1.1.1) 378.294 ms
> 379.111 ms 378.479 ms
>
I think we agreed that this is okay as it's supposed to be strictly for
internal NAT only, and so any public routing is sort of incidental. Just
wanted folks to be apprised of the situation.
Hey just checking in to see what folks think about node mounting at Sudo
tomorrow. I'm a little nervous about how ready some of the firmware configs
are, but I could get over there early to try to get things in order if need
be.
Just let me know what people want to do?
Hi!
Just wanting to share some new stuff we have been using in wlan
slovenija network.
So for managing our servers, we started using Salt and Docker. You can
find our Salt configurations here:
https://github.com/wlanslovenija/servers-salt-stateshttps://github.com/tozd/salt
We are putting all stuff into Docker images. Like nodewatcher, routing, etc.
https://github.com/wlanslovenija/docker-router-olsrd
And interesting thing we started doing is putting OpenWrt firmware
generators for each platform into its own Docker image:
https://github.com/wlanslovenija/firmware-core
In this way it is easy to share already compiled firmware generators.
People do not have to compile them themselves. You can then simply SSH
into it and compile images for that platform. (We use nodewatcher to
connect to them and compile based on the set of packages our users want
and with configuration baked in into the image itself.)
For gateways and VPN servers, we are simply using (or planing to use)
OpenWrt images generated by nodewatcher. :-) For x86 platform and it
works. In this way it is easy to reuse the existing stack. The servers
above are mostly for website, nodewatcher itself, etc.
We have also quite few OpenWrt packages:
https://github.com/wlanslovenija/firmware-packages-opkg
So for OpenWrt we are trying to put everything into packages. For
servers into Docker images.
For configuring the network stack for Docker we are using:
https://github.com/wlanslovenija/netcfg
Some random apps we created:
https://github.com/wlanslovenija/wireless-infohttps://github.com/wlanslovenija/netmeasured
I am sharing all this stuff so that others see if there is anything
interesting so that we do not duplicate too much things. Or that we
might use the same patterns/tools to be easier to reuse. Like Salt,
Docker. The most interesting for me is that if we would agree upon a
simple format for generator images, it would be a great way to share
firmware builders one can simply plug into their own systems. We all use
OpenWrt based stuff, this is then just to make module around it so that
I can ship to somebody a firmware they are not used to, but they can
still generate it with tools they are used to.
Mitar
--
http://mitar.tnode.com/https://twitter.com/mitar_m
