There is a new sudo mesh build server. Here's the info:
https://sudoroom.org/wiki/Mesh/Build_server
Ask me if you want access to the server.
Currently juul, deekoo, alex and max have access.
--
marc/juul
Hi All,
Found a flyer for this at Scarlett City coffee, and sounded interesting.
As an intro, my name is Trav, I'm a designer/developer in Emeryville. I
do front-end work currently, although have done server-side stuff in the
past.
I'll just be lurking for a bit to find out what goes on here, but I
thought I'd note that for the last several days when you navigate to
peoplesopen.net, you get a certificate error. You may want to either
update your cert, or not auto-redirect to https (which may be better if
you don't really need an encrypted connection for most of the content.)
I noticed a bit later that some of the resources being served up for at
least the home page aren't coming from https urls, so just fixing the
cert won't help those. I'm happy to provide some insight on this, but
don't want to crowd the list with website stuff... is there someone in
particular I should email?
Will try to make it to a meetup at some point, would definitely like to
learn more.
Hope that makes sense, happy to provide more info.
Trav
PS, thanks to Jenny for pointing me to the right list!
Hey everyone,
it would be great if anyone interested in software for networks would
contribute to this discussion.
The mailing list is at:
https://lists.funkfeuer.at/mailman/listinfo/interop-dev
-------- Original Message --------
Subject: [Interop-dev] Network Device JSON Schema
Date: Sat, 25 Oct 2014 19:34:53 -0700
From: Nemesis <nemesis(a)ninux.org>
To: interop-dev(a)lists.funkfeuer.at
Hi everyone,
recently I met some of you guys and girls and I think there's the shared
opinion that we should get back together and collaborate on small tasks,
which should not be so painful as working on big tasks.
One small task that has been in the backlog for some time was this JSON
representation ofa network device.
I sat together with Andi (Freifunk Weimar) today at the Google Mentor
Summit Reunion, we compared a few JSON outputs: openwifi map, openwrt
ubus, netengine and we came up with afirstbasic proposal.
We haven't worked on the JSON schema yet, only on an example, it should
be easy to write the JSON schema after we agree on some examples.
So I would like to encourage all of you to take a look atthis file:
https://github.com/interop-dev/network-device-schema/blob/master/example.js…
Our aim is to include only the very essential bitsand then start
iterating to improve it.
What do you think?
Federico (Ninux) and Andi (Freifunk)
Hello mesh-dev.
I think we may finally have an explanation of the vexing issue of "I can't
connect to the internet over peoplesopen.net."
Marc and I spent some time staring at wireshark dumps and thinking
about why some clients are unable to consistently connect via the
tunnel last night. I think Marc came up with a disappointing but correct
answer: it is basically an mtu issue (mtu is not being discovered
correctly), BUT there is no good fix because we are tunneling at layer 2.
When a packet arrives at a node from a client with too large an mtu,
what SHOULD happen in a normal forwarding situation (per RFC 1191)
is that the node issue a ICMP "Destination Unreachable" packet with a
"Fragmentation required" code. The client then uses this information to
reset its mtu.
This doesn't happen because we aren't really forwarding (forwarding happens
at layer 3). Instead, our interfaces (open0 and bat0) are bridged. So if a
frame
coming from open0 doesn't fit into bat0 it most likely gets silently
dropped.
So bridging open0 with bat0 is a disaster. A quick fix might be to replace
bridging with forwarding (at the IP level). I suspect this is not the right
thing
to do. It might be better to abandon the idea of meshing at layer 2; there
are numerous advantages to this.
In any case; we should discuss options this Tuesday.
Alex
I brought a windows 8 machine to sudo room and tried to use peoplesopen.net.
I could resolve domains and ping just fine but loading web pages didn't
work. Looks very similar to the iOS problem. I'm fairly sure it's the MTU
issue again.
Next time I'm there I'll try to set up TCP MSS clamping and see if it makes
the problem go away.
--
marc/juul
I believe we're setting the mesh_dhcp_range_start option incorrectly. The
wiki (http://wiki.openwrt.org/doc/uci/dhcp) says it should be the offset
from the network address of the interface. So we should be able to set this
to, say, 50 for all nodes.
I can't seem remember how this worked in practice though. None of the
running nodes I have access to had any dhcp.leases for me to check.
Something to test on Thurs.
Alex
Thinking about seeing how our firmware compiles on the new release!
-------- Original Message --------
From: Dave Taht <dave.taht(a)bufferbloat.net>
Sent: October 6, 2014 9:35:17 AM PDT
To: Steven Barth <cyrus(a)openwrt.org>
Cc: openwrt-devel(a)lists.openwrt.org
Subject: Re: [OpenWrt-Devel] Barrier Breaker 14.07 Final
Congrats everyone!
Here's to a faster, bufferbloat-free and ipv6 enabled
Internet!
On Thu, Oct 02, 2014 at 02:59:08PM +0200, Steven Barth wrote:
> The OpenWrt developers are proud to announce the final release
> of OpenWrt Barrier Breaker.
>
> _______ ________ __
> | |.-----.-----.-----.| | | |.----.| |_
> | - || _ | -__| || | | || _|| _|
> |_______|| __|_____|__|__||________||__| |____|
> |__| W I R E L E S S F R E E D O M
> -----------------------------------------------------
> BARRIER BREAKER (14.07)
> -----------------------------------------------------
> * 1/2 oz Galliano Pour all ingredients into
> * 4 oz cold Coffee an irish coffee mug filled
> * 1 1/2 oz Dark Rum with crushed ice. Stir.
> * 2 tsp. Creme de Cacao
> -----------------------------------------------------
>
> http://downloads.openwrt.org/barrier_breaker/14.07/
>
> Important changes since RC3
> * various ath9k related fixes
> * a few board related fixes
> * fixes for packages depdending on curl
> * per feed download folders
>
> Important changes since RC2
> * NAT & firewall throughput improvements
> * Security updates for OpenSSL & PolarSSL
> * Minor fixes in DHCP & DHCPv6 handling
> * Configuration support for GRE tunnels
> * Various other fixes
>
> Important changes since RC1
> * fix a long standing ath9k deadlock bug
> * all feeds are now built
> * image builder now works and RC2 contains all board specific images
> * various board/stability fixes
>
> ** Highlights since Attitude Adjustment **
> Default configuration and images
>
> * Linux kernel updated to version 3.10
> * Procd: new preinit, init, hotplug and event system written in C
> * Native IPv6-support
> - RA & DHCPv6+PD client and server
> - Local prefix allocation & source-restricted routes
> (multihoming)
> * Filesystem improvements
> - Added support for sysupgrade on NAND-flash
> - Added support for filesystem snapshot and rollback
> - Rewritten mounting system in C for rootfs and block devices
> * UCI configuration improvements
> - Support for testing configuration and rollback to working
> last working state
> - Unified change trigger system to restart services on-demand
> - Added a data validation layer
> * Networking improvements
> - Netifd now handles setup and configuration reload of
> wireless interfaces
> - Added reworked event support to allow obsoleting network
> hotplug-scripts
> - Added support for dynamic firewall rules and zones
> - Added support for transparent multicast to unicast
> translation for bridges
> - Various other fixes and improvements
>
> Additional highlights selectable in the package feeds or SDK
> * Extended IPv6-support
> - Added DS-Lite support and improved 6to4, 6in4 and 6rd-support
> - Experimental support for Lightweight 4over6, MAP-E and MAP-T
> - Draft-support for self-managing home networks (HNCP)
> * rpcd: new JSONRPC over HTTP-frontend for remote access to ubus
> * mdns: new lightweight mdns daemon (work in progress)
> * Initial support for the musl C standard library
> * Support for QMI-based 3g/4g modems
> * Support for DNSSEC validation
> * Added architecture for package signing and SHA256 hashing
> * ... and many more cool things
>
> Package feed reorganization
> For quite a while already we are not very satisfied with the quality
> of the packages-feed. To address this, we decided to do a fresh start
> on GitHub. The new feed https://github.com/openwrt/packages should be
> used from now on and package maintainers are asked to move their
> packages there. For the final release we will still build the old
> packages feed but it will be necessary to enable it manually in the
> opkg package list to be usable.
> Additionally we would like to give a big thank you to all of our
> package
> maintainers working on our various feeds.
>
> New build servers
> We would like to express our gratitude to Imagination Technology for
> funding the 2 build servers that we used for the release.
>
> Whats next ?
> We aim at releasing Chaos Calmer (CC) before the end of the year. The
> CC release will use 3.14 or a newer LTS kernel as baseline.
>
>
> Have fun!
> The OpenWrt developer team
> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel(a)lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
_______________________________________________
openwrt-devel mailing list
openwrt-devel(a)lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
