I had thought that it might be more professional if we were able to email
people from @peoplesopen.net addresses instead of just using our personal
addresses. The current peoplesopen.net email setup is that there are
forwarding rules (you can receive mail on a @peoplesopen.net address), but
you can't send it. To be able to send emails, we need an email server.
I've set up mailinabox on a ubuntu server, it's a pretty good combo of
dovecot, a webmail interface, some spam stuff, and an admin panel with
status checks. It will even automatically get letsencrypt certificates.
However, setting up the DNS has proven to be very hard for me to get right.
I've set up DNS for email and websites before, but never on such a complex
setup with so many domains and things that need to keep working.
I've tried a bunch of stuff, but either webmail doesn't work, forwarding
doesn't work, or all emails from the server end up in the spam folder. Marc
has been helping me, since he has control of the DNS, but I don't want to
bother him too much if it's not a priority for him.
I'm wondering if anyone who is experienced with email and/or DNS wants to
hack on this email server with me, maybe Tuesday before or during the
meeting. If nobody is interested, I'll probably drop it for now and we can
keep using personal email addresses.
-Jehan
Sorry for not showing up for a time, I have this awful cold. This must
be at least the 4th this season, what the hell is going on?
Anyway, I'll be back as soon as I can shake it. See you there.
--
Please *no* private Cc: on mailing lists and newsgroups
Personal signed mail: please _encrypt_ and sign
Don't clear-text sign:
http://primate.net/~itz/blog/the-problem-with-gpg-signatures.html
Yes dhcp now. Each node is assigned a /26 at birth by makenode. It uses the
first ip for itself and the next four for extender nodes then hands out the
rest to clients on short leases. If we want ipv6 then we could get the
nodes to self-assign a random small subnet within a specified larger
subnet. We will then want to use dhcpv6 to hand out ips to clients for a
few reasons but a big one is that most operating systems embed their MAC
address in their self-assigned ipv6 address which would turn the mesh into
a huge tracking network just by traceroute'ing continuously to a
predictable set of ips for a know MAC for e.g. someone's phone. Windows is
the only major OS that "does it right" and uses the alternate strategy for
ipv6 self-assignment which was added to the standars later, namely
"randomly generate". Linux folks are being stubborn and want to stick to
the default that is specified in the standars as the default. This is
terrible for privacy. Using dhcpv6 means we can ensure that client MAC
addresses are not embedded in assigned IPs
On Thursday, April 27, 2017, Jehan Tremback <jehan.tremback(a)gmail.com>
wrote:
> Oops, yea not link local, but random. How do client devices get ipv4
> addresses now? Not dhcp, right?
>
> On Thu, Apr 27, 2017 at 8:44 PM, Mitar <mitar(a)tnode.com
> <javascript:_e(%7B%7D,'cvml','mitar(a)tnode.com');>> wrote:
>
>> Hi!
>>
>> Ah, for nodes. Yes, nodes could have automatic IPv6 addresses (and not
>> even link-local, but global).
>>
>> For clients is trickier.
>>
>> But we could do some automatic IPv6 address subnets for nodes. :-)
>>
>>
>> Mitar
>>
>> > Well, I'm not an expert on all the details, but I imagine we'd generate
>> > them randomly during makenode (or whenever). Then routes to addresses
>> would
>> > be propagated by babel in the same way that ipv4 addresses are now. I'm
>> not
>> > sure if the exit server would need an ipv6 address or if it would be
>> good
>> > to switch existing nodes over.
>> >
>> > -Jehan
>> >
>> > On Thu, Apr 27, 2017 at 7:50 PM, Mitar <mitar(a)tnode.com
>> <javascript:_e(%7B%7D,'cvml','mitar(a)tnode.com');>> wrote:
>> >
>> >> Hi!
>> >>
>> >> I was asking for the "IPv6 randomly generated link-local
>> >> addresses" idea. How would that route?
>> >>
>> >>
>> >> Mitar
>> >>
>> >>>> And how would you route that over L3 network?
>> >>>
>> >>> Off the top of my head:
>> >>>
>> >>> - Packet headed somewhere on the internet with an ipv4 address comes
>> >> from a
>> >>> client device to the home node.
>> >>> - Home node pops that packet into an ipv6 packet bearing the ipv6
>> address
>> >>> of the exit server which is then routed over the mesh network
>> >>> - Exit server takes the ipv4 packet out and does NAT on it (switches
>> the
>> >>> source address to public IP) and sends it out to the internet.
>> >>> - Response from internet comes back to exit server, the exit server
>> does
>> >>> NAT again (switches the destination address to private IP)
>> >>> - Exit server puts the packet into an ipv6 packet with the ipv6
>> address
>> >> of
>> >>> the home node and sends it onto the mesh (it needs to have kept track
>> of
>> >>> the ipv6 address)
>> >>> - Home node receives the ipv6 packet, takes the ipv4 packet out and
>> sends
>> >>> it to the client.
>> >>>
>> >>> I'm not an expert, so there might be some issues with this. Here's an
>> RFC
>> >>> which might be similar:
>> >>>
>> >>> https://tools.ietf.org/html/rfc7040
>> >>>
>> >>> On Thu, Apr 27, 2017 at 1:28 PM, Marc Juul <juul(a)labitat.dk
>> <javascript:_e(%7B%7D,'cvml','juul(a)labitat.dk');>> wrote:
>> >>>
>> >>>>
>> >>>>
>> >>>> On Thu, Apr 27, 2017 at 1:22 PM, Mitar <mitar(a)tnode.com
>> <javascript:_e(%7B%7D,'cvml','mitar(a)tnode.com');>> wrote:
>> >>>>
>> >>>>> Hi!
>> >>>>>
>> >>>>>> IMO, we should put everything on ipv6 randomly generated link-local
>> >>>>>> addresses to avoid the whole makenode centralized IP assignment
>> >>>>> business.
>> >>>>>
>> >>>>> And how would you route that over L3 network?
>> >>>>>
>> >>>>> It would work over L2 Batman network. But not over L3.
>> >>>>>
>> >>>>> Have you looked into AHCP:
>> >>>>>
>> >>>>> https://www.irif.fr/~jch/software/ahcp/
>> >>>>
>> >>>>
>> >>>> Ssssh! Why did you have to tell them about AHCP?
>> >>>>
>> >>>> ... *OBLIVIATE!*
>> >>>>
>> >>>> --
>> >>>> marc/juul
>> >>>>
>> >>>
>> >>
>> >> --
>> >> http://mitar.tnode.com/
>> >> https://twitter.com/mitar_m
>> >>
>> >
>>
>> --
>> http://mitar.tnode.com/
>> https://twitter.com/mitar_m
>>
>
>
so if this is the case, will home nodes still be able to give out IPV4
addresses or will the mesh exclude equipment which doesn't support IPV6?
-jake
On Fri, 28 Apr 2017 Jehan wrote:
> So let me get this straight- home nodes advertise their /26, which is how
> the network knows how to get return traffic back to any given client?
>
> Wouldn't giving clients ipv6 addresses result in the problems with many of
> the ipv4 only protocols that were mentioned at the start of the thread?
>
>
> On Fri, Apr 28, 2017 at 2:24 AM, Mitar <mitar(a)tnode.com> wrote:
>
>> Hi!
>>
>>> Windows is the only major OS that "does it right" and uses the
>>> alternate strategy for ipv6 self-assignment which was added to the
>>> standars later, namely "randomly generate".
>>
>> This is called:
>>
>> https://tools.ietf.org/html/rfc3041
>>
>>> Linux folks are being stubborn and want to stick to the default that
>>> is specified in the standars as the default.
>>
>> Seems Ubuntu fixed this in 2011 or 2012:
>>
>> https://bugs.launchpad.net/ubuntu/+source/procps/+bug/176125
>>
>>
>> Mitar
------------------- forwarded message -------------------
My work is tossing about 18 of these Radwin 2000 radios. Does the mesh project
want them? If so I could ask.
[IMAGE]
[IMAGE]
--
Gregg Horton
510-283-8734
gregghorton.com [gregghorton.com]
My work is tossing about 18 of these Radwin 2000 radios. Does the mesh
project want them? If so I could ask.
--
Gregg Horton
510-283-8734
gregghorton.com
Hello Folks,
Just you are on the know.
My friend Mike Wilson (not a Sudoer, but kindly building us the gate at the
server area) has planed to come this Friday to do the wire fencing.
Thanks, and please let me know if you have any questions.
Daniel
Signal: 415.336.9143 <https://whispersystems.org/>
WhatsApp: 415.336.9143 <https://www.whatsapp.com/download/>
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - -
Help open a people-powered common space in Oakland, California!
https://omnicommons.org/donate
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - -
Yeah, for the CleaZe I bet we could do above the study room on roof of the east wing or above Ito's lounge on the west.
----- Reply message -----
From: "Mitar" <mitar(a)tnode.com>
To: "Jehan Tremback" <jehan.tremback(a)gmail.com>, "Marc Juul" <juul(a)labitat.dk>
Cc: "mesh(a)lists.sudoroom.org" <mesh(a)lists.sudoroom.org>
Subject: [Mesh] Source of gigabits
Date: Wed, Apr 26, 2017 7:37 PM
Hi!
Maybe instead of Cloyne try CZ (Casa Zimbabwe). Last time I checked
quite a bit of Berkeley and large Oakland buildings were visible from
there. And we have then internal WiFi links from CZ to Cloyne and other
houses.
There are also some photos from roofs if it helps.
https://drive.google.com/drive/u/0/folders/0Bz0lCyRxvUUTflpZSTBYY2UwVUR0ODV…
Mitar
> I was poking around on Google Earth, and getting to Cloyne seems pretty
> dicey, even from the lowest altitude that google earth can go which was
> probably ~20 feet above the LMI roof. It's in a somewhat low lying and
> heavily vegetated area.
>
> -Jehan
>
> On Wed, Apr 26, 2017 at 5:18 PM, Marc Juul <juul(a)labitat.dk> wrote:
>
>> We may have an opportunity to get affordable gigabits from LMI.
>>
>> They may allows us to put an AirFiber node on their roof. I haven't gotten
>> the quote yet but I'm expecting it to be around $1000 per month +/- 50%.
>>
>> We'd need somewhere with line of sight to the LMI rooftop where we can
>> mount a few rooftop node.
>>
>> Does anyone on this list live near this address or know someone who does?
>>
>> One obvious peer would be one of the Berkeley Student Coops, e.g. Cloyne.
>>
>> Can someone use e.g. Google Earth to check line of sight from the LMI roof
>> to the surrounding student coops?
>>
>> The LMI address is:
>>
>> 1700 Martin Luther King Jr Way
>> Berkeley, CA 94709
>>
>> --
>> marc/juul
>>
>> _______________________________________________
>> mesh mailing list
>> mesh(a)lists.sudoroom.org
>> https://sudoroom.org/lists/listinfo/mesh
>>
>>
>
>
>
> _______________________________________________
> mesh mailing list
> mesh(a)lists.sudoroom.org
> https://sudoroom.org/lists/listinfo/mesh
>
--
http://mitar.tnode.com/https://twitter.com/mitar_m
_______________________________________________
mesh mailing list
mesh(a)lists.sudoroom.org
https://sudoroom.org/lists/listinfo/mesh
