tomesh project review

^{This initial comment is collaborative and open to modification by all.}

Task Summary

🎟️ Re-ticketed from: #
📅 Due date: N/A
🎯 Success criteria: Have an updated and accurate project page on website.

...

To Do

Review existing project
Mark projects inactive and add description about them
Update website
Prioritize Toronto community project

Routing Hardware - EspressoBIN 👎

^{This initial comment is collaborative and open to modification by all.}

Task Summary

🎟️ Re-ticketed from: #
📅 Due date: N/A
🎯 Success criteria: Instructions to build a working espressoBIN router for babeld

😕 Found u-boot hung a few times. I was messing with it at the time but still not a good thing
✔️ Able to re-flash from uboot
✔️ Almost full gig transfer when direct connection
✔️ Almost full gig transfer when bridging
❌ Routed dropped down to ~350Mbps
❌ A reboot can cause it to enter into a UBOOT freeze and requires to be power cycled.

To Do

Figure out how to flash without taking out SD card
Benchmark Router
Figure out config for roof-top router

Mesh Services - SDR

^{This initial comment is collaborative and open to modification by all.}

Task Summary

🎟️ Re-ticketed from: #
📅 Due date: N/A
🎯 Success criteria: Deploy SDR

Look into the possibility of a SDR on a roof top.

To Do

Use BAI as supernode inter-connections

^{This initial comment is collaborative and open to modification by all.}

Task Summary

🎟️ Re-ticketed from: #24
📅 Due date: N/A
🎯 Success criteria: Implement a BIA Link

...

To Do

Find a way to use them

Routing Hardware - WRT1900AC v1

^{This initial comment is collaborative and open to modification by all.}

Task Summary

🎟️ Re-ticketed from: #
📅 Due date: N/A
🎯 Success criteria: ...

...

To Do

Benchmark Router
Figure out config for roof-top router

Select on-mesh service to implement

^{This initial comment is collaborative and open to modification by all.}

Task Summary

🎟️ Re-ticketed from: #
📅 Due date: N/A
🎯 Success criteria: A valuable service is selected for development, deployment and maintenance on the Toronto Community Network

There have been a variety of services proposed for delivering value on the mesh. This task is concerned with identifying a long-list of candidate services and then convening a process for collaboratively submitting service definitions, narrowing down and prioritizing the alternatives and finally agreeing on a service to design, deploy, and operate/maintain on the mesh.

To Do

Communicate the intentions behind deploying a service and some framing of "goodness criteria"
Gather definitions of candidate services
Formulate a way of short-listing the top 5 service definitions
Select a top 5 service definitions
Formulate a way of selecting the preferred service for completion and deployment
Select the preferred service for completion and deployment
Assemble the resources and begin design, development and deployment of the selected service

Related services issues:

Operational
- #44 NTP
- #45 DNS
Community
- #46 SDR
- #95 Lets Encrypt Proxy

Mesh Services - NTP

^{This initial comment is collaborative and open to modification by all.}

Task Summary

🎟️ Re-ticketed from: #
📅 Due date: N/A
🎯 Success criteria: Deploy NTP server

...

To Do

...

L2TP as link

^{This initial comment is collaborative and open to modification by all.}

Task Summary

🎟️ Re-ticketed from: #
📅 Due date: N/A
🎯 Success criteria: Figure out how to build L2TP Tunnels

...

To Do

...

Node Install Process - Installers

^{This initial comment is collaborative and open to modification by all.}

Task Summary

🎟️ Re-ticketed from: #
📅 Due date: N/A
🎯 Success criteria: ...

...

To Do

...

Investigate ERX-SFP Resiliance

^{This initial comment is collaborative and open to modification by all.}

Task Summary

🎟️ Re-ticketed from: #
📅 Due date: N/A
🎯 Success criteria: ...

...

To Do

check if router loose time on reboot back to EPOC
check if router loose time on power cycle or loss of power to EPOC
check if router looses babed on firmware upgrade

First Exit Node

^{This initial comment is collaborative and open to modification by all.}

Task Summary

🎟️ Re-ticketed from: #
📅 Due date: N/A
🎯 Success criteria: Access to a Exit Node

...

To Do

Redeploy existing NJ peer or get new one

Plan out network deployment @ 190/200

^{This initial comment is collaborative and open to modification by all.}

Task Summary

🎟️ Re-ticketed from: #
📅 Due date: N/A
🎯 Success criteria: Have a clear map of first super node

...

To Do

Decide on location of antennas
Decide on layer 2 topology
Lab test it #1
Decide on IP organization #8

200 WOOLNER Deployment

^{This initial comment is collaborative and open to modification by all.}

Task Summary

🎟️ Re-ticketed from: #
📅 Due date: 7/24/2020
🎯 Success criteria: Nodes are up and running and ready to receive connections

Location: https://goo.gl/maps/qvdh4f49L7tQpPKt6 (200 Woolner Ave)

NOTE We will be limiting the amount of people on the roof to about 2 at a time.
If your interested in participating (on the roof or on the ground) please make sure you get in touch with us ([email protected])

COVID NOTICE: If you will be attend please bring a mask or face covering.

We will be deploying along side the CITY FREE WIFI PROJECT on Thursday, July 23 and Friday July 24th.

The project window will be between 9-5 on each day.
Toronto mesh will attend

Thursday 12:01 pm - 5:00 pm (to allow for infra deployment by other teams first)
Friday 9:00 am - 5:00 pm

Goal is to have everything operational by end of Friday.

Weather outlook shows possible thunderstorms on Thursday. For safety reasons we will NOT be on the roof if there is any evidence of severe weather.

What to bring with you

Mask
Weather gear
- Sunblock
- Sun Glasses
- Hat
Laptop (charged)
Phone (charged)
Food/Water/Whatever else you need for the day

To Do

ISOC Funding

^{This initial comment is collaborative and open to modification by all.}

Task Summary

🎟️ Re-ticketed from: #
📅 Due date:

Submit ISOC Proposal - 6/22/2020
🎯 Success criteria: Receive access to ISOC Funding.

...

To Do

Routing Hardware - ROUTER-X

^{This initial comment is collaborative and open to modification by all.}

Task Summary

🎟️ Re-ticketed from: #
📅 Due date: N/A
🎯 Success criteria: Identify limitations and uses of EdgerRouter family (including EdgePoint)

EP‑R6 is a nice 5 port outdoor router with poe that should be compatible with EdgeRouter X.

https://www.ui.com/edgemax/edgepoint/

To Do

EdgeRouter X SFP doubles as a 5 port POE switch.

Get hardware for deployment - Node 1

^{This initial comment is collaborative and open to modification by all.}

Task Summary

🎟️ Re-ticketed from: #
📅 Due date: N/A
🎯 Success criteria: Hardware ready for deployment

...

To Do

Adjust topology for Woolner

^{This initial comment is collaborative and open to modification by all.}

Task Summary

🎟️ Re-ticketed from: #
📅 Due date: Thursday
🎯 Success criteria: Decide on router model at woolner

...
Select topology and hardware used for node
Option 2 and 3 need some one to donate resources
Needs to be ready for deployment by thursday

Option 1 - Basic setup

No additional hardware
L2TP tunnel back to exit node over bell GPON (Not encrypted)
Should be able to pull full 1Gbps with HW acceleration

Option 2 - VPN Server

Requires SFP to RJ45 Adaper
Requires small form factor PC to run VPN
Requires harddrive for PC ?
Primary path will be encrypted to the exit node over bell GPON
L2TP tunnel would still exist as an alternative route (in case pc dies)
1Gbps depends on
- if PC can handle
- if Exit node can handle (probably cant right now)

Option 3 - Redundancy

Requires another Router X SFP
Optional - SFP means of interconnecting
Requires small form factor PC to run VPN
Requires harddrive for PC ?
Primary path will be encrypted to the exit node over bell GPON
L2TP tunnel would still exist as an alternative route (in case pc dies)
1Gbps depends on
- if PC can handle
- if Exit node can handle (probably cant right now)
Antennas distributed between two routers
Both Routers provide path to exit node
If one router dies, only 2 antennas die
can loose any 2 of VPN and 2 tunnels for resiliency
BELL GPON single point of failure
support 2 additional devices (4 if SFP)

Create mesh node at Hack Lab

^{This initial comment is collaborative and open to modification by all.}

Task Summary

🎟️ Re-ticketed from: #
📅 Due date: N/A
🎯 Success criteria: Active note at Hack Lab connected.

...

To Do

Contact and get approval
Get roof access
Get Mount
- Pedro may have some mounts in storage
- From Cisco deployment ~ $170
Get P2P antennas
Deploy

1-Page Get Connected flyer

^{This initial comment is collaborative and open to modification by all.}

Task Summary

🎟️ Re-ticketed from: #
📅 Due date: N/A
🎯 Success criteria: 1 Page flyer available in github repo
...

To Do

Confirm steps to "Getting connected"
Figure out what information we want the flyer to convey in addition to "getting connected"
Design flyer
Print flyer
Distribute flyer

Mesh Services - DNS

^{This initial comment is collaborative and open to modification by all.}

Task Summary

🎟️ Re-ticketed from: #
📅 Due date: N/A
🎯 Success criteria: Deploy DNS server
...

To Do

Provision dns servers
Check if anycast works as expected
Run tcn.tomesh.net TLD
DDNS node info json

Rooftop Woolner Small Tasks

Tasks for next time some one goes up onto the roof of Woolner

Power bar to bring power into the box
- Currently each devices is plugged directly into the wall outside of the box
- All the plugs are used and some one may unplug something to drill or whatever
- Label power cable that it is network infra
Check for hanging power brick that may put stress on the power cable
Shorter orange Ethernet cable from WAN to Cisco Switch
Second network cable cable from a disabled port of ERX to Bell Modem in case cisco switch dies.
get exact bearing and GPS coord of both antennas

E2E VPN

^{This initial comment is collaborative and open to modification by all.}

Task Summary

🎟️ Re-ticketed from: #
📅 Due date: N/A
🎯 Success criteria: Arrive at model for E2E VPN Criteria

...

To Do

Hardware
VPN server deployment

Consistency of names across different spaces

^{This initial comment is collaborative and open to modification by all.}

Task Summary

🎟️ Re-ticketed from: #
📅 Due date: asap
🎯 Success criteria: Agree on a set of terms we will use consistently across different spaces.

I would like us to agree on a set of terms and use them consistently across different spaces. Any deviation should be treated as an error and fixed. Otherwise, it is massively confusing for new people coming onboard to understand our communications, when the same thing is referred to in many ways. (e.g. Is Toronto Mesh same as TOMesh? What is the relation between Toronto Mesh, Toronto Community Network, Free WiFi Project?)

I propose the following, and stick to it religiously. If there is any disagreement or new term we need to define, let's list them here and we agree on their use.

`Toronto Mesh`

Written upper case T and upper case M.

This is how this group is formally referred to in different spaces (e.g. on our website timeline, CoC, all external communications and articles written by others). It is not TOMesh, TO Mesh, or Toronto Meshnet.

`Toronto Community Network`

Written upper case T, upper case C, and upper case N.

The name of this particular initiative. It is the name we agreed on and put into all proposal material shared with collaborators.

`City of Toronto's Free WiFi Project` / `Toronto Free WiFi Project`

The working title of the project that the City is working on with its partners to offer free WiFi to neighbourhoods in need, as emergency response to the covid-19 pandemic.

`tomeshnet`

Written all lower case.

This is our account handle on different services and social media (e.g. Twitter, GitHub).

`tomesh`

Written all lower case.

Sometimes used as a short form to refer to Toronto Mesh in informal situations. This short form should never be used on published documents or official communication.

`tomesh.net`

Written all lower case.

Our website. It is without the www. in front.

`supernode`

A supernode is an actively maintained relaying node that supports high bandwidth point-to-multipoint (PTMP) connectivity. Currently all supernodes are managed by the Network Planning, Design and Operations working group at Toronto Mesh, but other groups may also operate their own supernodes on the Toronto Community Network.

To Do

Agree to adopt (please 👍 on this or comment in issue)
Update this repository name to toronto-community-network (this name is confusing esp. since we have deployment repo)
Change references that are incorrect

Update website to emphasize Toronto Community Network project

^{This initial comment is collaborative and open to modification by all.}

Task Summary

🎟️ Re-ticketed from: #
📅 Due date: N/A
🎯 Success criteria: Publish an update website that features this project with clear ways to participate, and is not confused with previous projects.

The website has led to a lot of confusion between the many projects that tomesh worked on. Let's try to redesign the website to present things clearly, and emphasize the existing project.

To Do

Most of the changes will happen on https://github.com/tomeshnet/tomesh.net

Establish Free Geek Relationship As Host

^{This initial comment is collaborative and open to modification by all.}

Task Summary

🎟️ Re-ticketed from: #
📅 Due date: 6/23/2020
🎯 Success criteria: Create relationship with Free Geek, submit ISOC grant, complete all admin tasks to be able to access funds.

...

To Do

Formal Proposal

^{This initial comment is collaborative and open to modification by all.}

Task Summary

🎟️ Re-ticketed from: #
📅 Due date: N/A
🎯 Success criteria: Send out formal proposal to all contacts.

Create proposal for longer vision of toronto mesh.

To Do

Discuss future of this document
Finish draft
Run it through Hank
Send it to individuals that could get behind it.

Monitoring - UNMS - Prometheus

^{This initial comment is collaborative and open to modification by all.}

Task Summary

🎟️ Re-ticketed from: #
📅 Due date: N/A
🎯 Success criteria: Decide on monitoring software.

...

To Do

Do we want to use UNMS
Do we want to use Prometheus
Do we want to push UNMS data to Prometheus
Build script to export UNMS to Promethus

Establish online store

^{This initial comment is collaborative and open to modification by all.}

Task Summary

🎟️ Re-ticketed from: #
📅 Due date: N/A
🎯 Success criteria: Open functional online store.

...

To Do

Look into free geek capability to support
- Investigate allocation of funds from IPFS grant
- If needed, investigate if Open Collective can help (need to involve Hypha)
Get stock
Start selling

Decide how to keep secrets

^{This initial comment is collaborative and open to modification by all.}

Task Summary

🎟️ Re-ticketed from: #
📅 Due date: N/A
🎯 Success criteria: Define a policy for secret keeping.

Who has access to what credentials, accounts, etc.
Where are they stored.

To Do

Determine Password Management Tool
Install and Configure Password Management Tool
Provide access to Toronto Community Network contributors
Update this issue with the first draft
Commit documentation to docs.tomesh.net

Network Organization

^{This initial comment is collaborative and open to modification by all.}

Task Summary

🎟️ Re-ticketed from: #
📅 Due date: N/A
🎯 Success criteria: Be ready to deploy IPs to production network.

...

To Do

Figure out IP assignment #21
Figure out Node Naming
Where to store IP and Node Information
Where to store service information

Prometheus Server

^{This initial comment is collaborative and open to modification by all.}

Task Summary

🎟️ Re-ticketed from: #
📅 Due date: N/A
🎯 Success criteria: Document how to build a prometheus server

...

To Do

...

Data collection/usage/privacy policy

^{This initial comment is collaborative and open to modification by all.}

Policy for Data Collection/Usage/Privacy

🎟️ Re-ticketed from: #
📅 Due date: N/A
🎯 Success criteria: Establish a policy for data usage.

...

Background

Toronto Mesh is an unincorporated volunteer based collective entity
The primary project is Toronto Community Network

Issues

Short term: As an organization there are many types of data currently generated and used by Toronto Mesh, without any explicit policy for use of these different types of data
Medium term: As more individuals or organizations start using Toronto Mesh installed infrastructure, data policies are required to fulfil any commitments
Long term: Toronto Mesh intends to be a replicable organization, in the style of an open organization or open innovation process, which requires the vast majority of data and content produced by Toronto mesh to be openly available, modifiable and resuable by anyone else.

Types of Data currently collected and used by Toronto Mesh:

Contact information for members (e.g. contact spreadheet)
Contact information for non-member stakeholders (e.g. contact spreadheet)
Formal agreements with entities (e.g. Hypha, Free Geek Toronto, Toronto Public Library)
Formal correspondence between members and anyone else (e.g. email)
Informal Correspondence between members (e.g. Element/Riot)
Tracking of organizaiton and project issues (e.g. Github)
Notes from meetings (e.g. typepad)
Content generated from meetings (Video, Sketches, Milosh Powerpoints and Jamboards)
Public consumption communicaitons (e.g. website, social media)
Locations of Toronto Mesh equipment intallations (e.g. node map)
Usage of of Toronto Mesh equipment (e.g. range, traffic etc.)

Current Practice

In the absence of written (or uniformly followed) policies, the implementation then becomes the defacto policy.
i.e. code is the law. If I have the permission to change a particular type of content (e.g. website) whatever changes I make to the website becomes the public facing communication for Toronto Mesh.

Risks

Simple: If I change content on the website within my permission capabilities, but without coordination with other communication activities, the website content could become out of sync with organizational priorities.

Complicated: If I am a new member and have been added to Toronto Mesh Element chat, can I take any member to member content including jokes and sarcastic comments, and publish it on another public website out of context?

Complex: If we want to be an open organization, whose processes are replicable, should we record video of all meetings? On one hand it males it available to members who could not attend the meeting, but it also limits discussion for those concerned about privacy or quotes taken out of context [add existing video policy discusion here]

Priorities

Establish clear criteria for a membership list and types of members
This will document who has permission to do what.

...

Queertech Hackathon

^{This initial comment is collaborative and open to modification by all.}

Task Summary

🎟️ Re-ticketed from: #
📅 Due date: N/A
🎯 Success criteria: ...

Montreal-based organization Queertech is working with Toronto clinic Sherborne Health to come up with a solution to providing internet access to those that do not have it as during the pandemic many of their traditionally in-person services have been moved online. They'll be looking into this issue and trying to connect Sherborne Health with solutions as part of their PrideHacks 2020 event and have asked that we remain available to answer questions that event participants may have.

To Do

Follow up with Kate once she has followed up with us on next steps for the hackathon / Sherborne Health involvement
Be generally available on Matrix on August 7-8

Add coverage map to tomesh.net

^{This initial comment is collaborative and open to modification by all.}

Task Summary

🎟️ Re-ticketed from: #
📅 Due date: N/A
🎯 Success criteria: PR accepted
...

To Do

Add support to draw coverage ARCs on tomesh.net site
Correct eslint errors
Accept PR tomeshnet/tomesh.net#275
Create new node list (possibly related to #8)

Outreach and initiation of collaborative relationship with BAI Communications

^{This initial comment is collaborative and open to modification by all.}

Task Summary

🎟️ Re-ticketed from: #
📅 Due date: N/A
🎯 Success criteria: Establish an understanding and relationship with BAI and tomesh

...

To Do

Contact BAI
See if they are willing to donate

TunnelDiggers as a L2TP tunnel

^{This initial comment is collaborative and open to modification by all.}

Task Summary

🎟️ Re-ticketed from: #
📅 Due date: N/A
🎯 Success criteria: instructions on how to setup and run tunneldigger

...

To Do

run broker
run client
compile client on all platfors

First Toronto Exit Node

^{This initial comment is collaborative and open to modification by all.}

Task Summary

🎟️ Re-ticketed from: #6
📅 Due date: N/A
🎯 Success criteria: Establish Toronto local exit node.
❌ Blocked By: ~~#10~~ #123

...

To Do

Cisco exit node
- Contact Beanfield #10
- Get circut donated/paid
- Get circuit installed @ cisco?
- Rack and Stack Servers
- Install Debian running Babeld and accept L2TP tunnels

Relationship with Beanfield

^{This initial comment is collaborative and open to modification by all.}

Task Summary

🎟️ Re-ticketed from: #
📅 Due date: N/A
🎯 Success criteria: Establish an understanding and relationship with beanfield and tomesh

...

To Do

Research tomesh AS

^{This initial comment is collaborative and open to modification by all.}

Task Summary

🎟️ Re-ticketed from: #
📅 Due date: N/A
🎯 Success criteria: Get or Reject a tomesh AS

Summary

ARIN

To gain ownership of an IPv4 or IPv6 Public Internet IP Space you must register with a Regional Internet Registry. The North America registry is called ARIN. Once registered we can apply for a IP address size for both IPv4 and IPv6.

AS number

When applying for a IP range we will also be given an AS number. This AS number is used to announce the location of these IP addresses to the internet.

Reasons for requiring an AS

Multiple Exit Nodes support

When using multiple exit nodes, the ability to announce the same IP address for each one will allow for more resilience on the mesh. Just like outbound connections could use any exit node, inbound connections could also be routed through any exit node.

Possibly not as important when using NAT

Public IP routing inside of mesh

With an assigned AS we can router the IPv4 addresses into our mesh. The means that members can be given a publicly routable IPv4 IP address that lives on the mesh and is reachable from the internet.

Additionally publicly routable IPv6 addresses could also be handed out inside the mesh to every user.

TORIX Peering

To peer with TORIX you require your own IP range to announce. Torix is a "short cut" to many of the larger organizations that have presence in Toronto. This shortcut would lower the dependence on our internet egress.

Easier donate ask

IPv4 are a rare commodity and many transit contacts may not wish to donate theirs. By being able to bring our own IPv4 addresses, it may be easier to ask for service since it would not require depleting their ipv4 pools.

Puts on on the "MAP"

By owning an AS and an IP range we could be seen as more then a few hobbits and serious players in the "internet" game.

To Do

Research Pricing with ARIN
Decide on size and ips
Research who can hold it (tomesh, free geek)
- Approach Hypha to be the legal custodian
- Get approval
What is needed to apply

Nameing/Numbering Standards

^{This initial comment is collaborative and open to modification by all.}

Task Summary

🎟️ Re-ticketed from: #
📅 Due date: N/A
🎯 Success criteria: ...

IP Standard

We will be using IPv4 and IPv6 Ip addresses for the mesh
Fun Fact: IPv6 Address is in the fd::/8 range. The bytes of 74 6F 6D 73 86 converted into ASCII spell TOMSH (lowe case for backhaul range)

IPv4 subnets that will be used

/32 - Single Host
/30 - PtP L2TP etc
/24 - Subnets

Backhaul network

Used for super nodes and core controlled network components

IPv4: 100.64.0.0/10

IPv6: FD54:4f4d:5348::/48

Address:   100.64.0.0            01100100.01 000000.00000000.00000000
Netmask:   255.192.0.0 = 10      11111111.11 000000.00000000.00000000
Wildcard:  0.63.255.255          00000000.00 111111.11111111.11111111
=>
Network:   100.64.0.0/10         01100100.01 000000.00000000.00000000 (Class A)
Broadcast: 100.127.255.255       01100100.01 111111.11111111.11111111
HostMin:   100.64.0.1            01100100.01 000000.00000000.00000001
HostMax:   100.127.255.254       01100100.01 111111.11111111.11111110
Hosts/Net: 4194302

IPv4: 10.0.0.0/8

IPv6: FD74:6F6D:73:86::/48

Used for community hubs and non-core devices

Address:   10.0.0.0              00001010 .00000000.00000000.00000000
Netmask:   255.0.0.0 = 8         11111111 .00000000.00000000.00000000
Wildcard:  0.255.255.255         00000000 .11111111.11111111.11111111
=>
Network:   10.0.0.0/8            00001010 .00000000.00000000.00000000 (Class A)
Broadcast: 10.255.255.255        00001010 .11111111.11111111.11111111
HostMin:   10.0.0.1              00001010 .00000000.00000000.00000001
HostMax:   10.255.255.254        00001010 .11111111.11111111.11111110
Hosts/Net: 16777214              (Private Internet)

Supernode Name Standards

The supernode hostname is snXyY and where X is assigned by the Network Planning, Design and Operations working group, and yY is chosen by the node operator to identify network components within the node. For example a1 for antenna 1 and r1 for router 1.

All hostnames will be unique across the mesh.

The supernode devices will also use a domain in the format operator.tcn.tomesh.net. A DNS and reverse DNS entry will be made for each device with such a domain name. For simplicity a super node will also carry an entry with the domain of nodename.tcn.tomesh.net

For example a FQDN (fully qualified domain name) will be sn1a1.core.tcn.tomesh.net for a device operated by the core team at Toronto Community Network. The node will also answer as sn1a1.tcn.tomesh.net

SSID

Public SSID

Public SSID will not extend the BABELD protocol. They are standard access points connections for the public to access the mesh.

Format
tomesh.net

Mesh SSID

Mesh SSID are used to extend the mesh network. They have BABELD running on them. They can be one of several protocols.

Format

tomesh-(protocol)[-(meshid)]

parameters

tomesh- is a constant and never changes

(protocol) is he protocol name the SSID is running. This could be for example airmaxac,80211s,adhoc

(meshid) Optional part of the string when SSIDs need to be isolated. PtP and PtMP antennas will use their hostnames

Example

a tomesh node with hostname of sn1a1 runing airmax-ac protocol would be
tomesh-airmaxac-sn1a1

a tomesh node with running 80211s would be
tomesh-80211s

IP Standard

To Do

Reaserch/Find NEMA Cabinet

^{This initial comment is collaborative and open to modification by all.}

Task Summary

🎟️ Re-ticketed from: #
📅 Due date: N/A
🎯 Success criteria: Purchase of NEMA cabinet

...

To Do

Research cabinet and pricing
Select cabinet
Order cabinet

Default route and Babled route co-exist

^{This initial comment is collaborative and open to modification by all.}

Task Summary

🎟️ Re-ticketed from: #
📅 Due date: N/A
🎯 Success criteria: ...

In a Gateway node where a tunnel interface that relies on the internet, and babeld traffic get routed causing conflict.

Default Gateway on node will point to its local internet
- This is needed to establish a tunnel
Babeld wont install a default route to an exit node
- It can be forced, but that will just collapse the tunnel
Because default route is going out the local gateway, any other traffic routing through this trying to get out to an exit node will use the local gateway beacuse thats what the route is. Most times it will fail since the source ip address is unknown to the default gateway.

Workaround 1 - use static routes

static route only the l2tp tunnel ip to the local gateway. This will allow babeld to install the correct route

ip route delete 0.0.0.0/0
ip route add 123.123.123.123/32 via 1921.68.1.1

Workaround 2 - use separate table for babeld

Make babled put all its routes into a separate route table
This will keep the local route table and babeld's route table separate
Add this to babeld.conf
export-table 10

Route all incoming traffic on specific interfaces to use the babeld route table instead of the os master
(this includes the 0.0.0.0/0 selected by babeld)
put it in rc.local

ip rule add iif ens19 table 10
ip rule add iif tun0 table 10
ip rule add iif l2tpeth61 table 10

I had to add the routes for the local interfaces including openvpn

ip route add 100.64.21.0/24 dev ens19 table 10
ip route add 100.127.253.0/24 dev tun0 table 10

Workaround 3 - VRF to interfaces

Create a mesh VRF and assign it Routing Table 10

ip link add name mesh type vrf table 10
ip link set dev mesh up

Allow TCP and UDP port to be accessable from the VRFs (so you can SSH into the box)

/sbin/sysctl -w net.ipv4.tcp_l3mdev_accept=1
/sbin/sysctl -w net.ipv4.udp_l3mdev_accept=1

Add interfaces to the VRF that should be routing over babeld's routes

ip link set dev ens19 vrf mesh up
ip link set dev tun0 vrf mesh up
ip link set dev l2tpeth61 vrf mesh up

Create a rule that puts all incoming and outgoing packets on the interfaces to use the vrf's routing table (table 10). This is needed to forward packets

ip rule add iif ens19 table 10
ip rule add oif ens19 table 10

ip rule add iif tun0 table 10
ip rule add oif tun0 table 10

ip rule add iif l2tpeth61 table 10
ip rule add oif l2tpeth61 table 10

Add the following in babeld to use table 10 to read and write routes

export-table 10
import-table 10

Usage:

Completely transparent to forwarded packets (packets coming from other devices)
From the local machine all traffic happens on the GLOBAL (non mesh) route table
To use the mesh table locally
- ping 100.64.10.1 -I mesh <- tells it to attach it to interface MESH
- ip vrf exec mesh traceroute 100.64.10.1 <- run traceroute (on any exec) in mesh vrf

Issues:

IPv6 addresses disappear :( and need to be re-added)

todo

Find a way to seperate babeld and local route tables
Check to see if you can default to table 10 instead of "opt in"
Look into VRF and marry interfaces to tunnels

Identification stickers for hardware

^{This initial comment is collaborative and open to modification by all.}

Task Summary

🎟️ Re-ticketed from: #
📅 Due date: 7/22/2020
🎯 Success criteria: Stickers ready to be applied to hardware.

...

To Do

Get phone number #14
Get stickers designed (@Shrinks99)
Get stickers ordered
Get stickers delivered

Decide on router hardware - Supernode

^{This initial comment is collaborative and open to modification by all.}

Task Summary

🎟️ Re-ticketed from: #
📅 Due date: N/A
🎯 Success criteria: Selection on router hardware

Espresso bin ~ $80.00 #12
ClearFog - ~ $200-$350
Turris Omnia 2020 ~ $500
PC
- KANSUNG celeron ~ $200-250
Edge Point ~ $600 @ CDW for 8port ~ $400 @ Amazon 6 port
- No VPN
- Weather proof
- POE Switch built in
- Basically an EdgeRouterX #22 with POE and outdoor case

To Do

Select and test router

Bench Marks

P2P Device directly connected to a computer
Routed Device between two computers routing across subnets
WG P2P Device WG to another Device
WG Routed Device GW to another device and an PC Routed across that link

Devices	P2P	Routed	WG P2P	WG Routed	L2TP P2P	L2TP Routed
EspressoBin	✔️ 931	❌ 335/403	❌ 213/335	--	--
AtomicPi	✔️ 923	✔️ 837	✔️ 895	🟨 665	✔️ 767/863	✔️ 798/705
WRT1900ACV1	✔️ 920	✔️ 879	🟨 350/450	❌ 280/338	--	--
EdgerouteX	356/533	750/510	--	--	--	--
EdgerouteX HW OFFLOAD		913/927	217/180	180/211	--	--
OmniTik POE		900

Contributor onboarding process

^{This initial comment is collaborative and open to modification by all.}

Task Summary

🎟️ Re-ticketed from: #
📅 Due date: asap
🎯 Success criteria: Establish onboarding workflow for new contributors.

If someone says they want to help, we need a standardized way to quickly engage and onboard them into our spaces and workflow. I imagine getting their email and send an onboarding templated email that includes steps to get onto our working groups on GitHub, chat, etc. followed by a peer session to explain how to use the tools and our collaboration practices.

To Do

Create a one-pager to onboard email template (put in this repo), this should include:
- WGs in GitHub Teams
- Project board and tasks
- Element chat
- Mailing list (main mailman list and forwarder)
- Meeting time poll (for each WG)
- Responsibilities and CoC
Send this to existing contributors
Do a walkthru together on workflow
Designate someone in @tomeshnet/project-operations to respond to new onboarding emails moving forward

Supernode 1 Field Testing

^{This initial comment is collaborative and open to modification by all.}

Task Summary

🎟️ Re-ticketed from: #
📅 Due date: 7/24/2020
🎯 Success criteria: Collect data from different points about strenght and speed of node.

To Do

Collect data on link quality with AirMaxAC from the ground where there is LOS
Convert to documentation somewhere

Tools required

AC Battery or Car cigarette liter Inverter (one of each)
Loco or LiteBeam (two of each)

Research POE Switch

^{This initial comment is collaborative and open to modification by all.}

Task Summary

🎟️ Re-ticketed from: #
📅 Due date: N/A
🎯 Success criteria: Decide on POE switch to use

Register tomesh phone number

^{This initial comment is collaborative and open to modification by all.}

Task Summary

🎟️ Re-ticketed from: #7
📅 Due date: N/A
🎯 Success criteria: Setup phone number

...

To Do

Register phone number
Decide where voicemail should go (new email or existing)
Configure voicemail to email
Migrate to ownership of TOMESH

LAB TEST mesh network

^{This initial comment is collaborative and open to modification by all.}

Task Summary

🎟️ Re-ticketed from: #
📅 Due date: N/A
🎯 Success criteria: Create a functional lab network for the mesh

To Do

Document operational and technical information

^{This initial comment is collaborative and open to modification by all.}

Task Summary

🎟️ Re-ticketed from: #
📅 Due date: N/A
🎯 Success criteria: Have relevant documentation added to https://docs.tomesh.net from the list below.

Keep operational and technical documentation in a well-structured book for anyone to easily find current information. Currently they are spread across multiple spaces and hard to discover/navigate.

To Do

These need to be fit into the docs chapters in the next section.

Migrat Content

To be blogged

#34 Supernode 1 field testing

No Content

#17 - Nema Cabinate
#20 POE Switch

Docs chapters

Please edit this comment to add sections. Use of subchapters is encouraged.

Docs are being worked on in the toronto-community-network-docs repo.

tomeshnet / toronto-community-network Goto Github PK

toronto-community-network's Introduction

Toronto Community Network

Get Involved

toronto-community-network's People

Contributors

Stargazers

Watchers

Forkers

toronto-community-network's Issues

Task Summary

To Do

Task Summary

To Do

Task Summary

To Do

Task Summary

To Do

Task Summary

To Do

Task Summary

To Do

Related services issues:

Task Summary

To Do

Task Summary

To Do

Task Summary

To Do

Task Summary

To Do

Task Summary

To Do

Task Summary

To Do

Task Summary

What to bring with you

To Do

Task Summary

To Do

Task Summary

To Do

Task Summary

To Do

Task Summary

Option 1 - Basic setup

Option 2 - VPN Server

Option 3 - Redundancy

Task Summary

To Do

Task Summary

To Do

Task Summary

To Do

Task Summary

To Do

Task Summary

Toronto Mesh

Toronto Community Network

City of Toronto's Free WiFi Project / Toronto Free WiFi Project

tomeshnet

tomesh

tomesh.net

supernode

To Do

Task Summary

To Do

Task Summary

To Do

Task Summary

To Do

Task Summary

To Do

Task Summary

To Do

Task Summary

To Do

Task Summary

To Do

Task Summary

`Toronto Mesh`

`Toronto Community Network`

`City of Toronto's Free WiFi Project` / `Toronto Free WiFi Project`

`tomeshnet`

`tomesh`

`tomesh.net`

`supernode`