16 Apr
2015
16 Apr
'15
7:43 p.m.
Hey folks,
I'm running a little late, but it does look like I successfully compiled an
ar71xx binary of notdchpclient and notdhcpserver. I've attached the ipks to
this email in case anyone is super anxious to get running with them,
otherwise I'll be at sudo a little after 8.
See ya!
Max
16 Apr
16 Apr
7:55 p.m.
Scratch that - those aren't compiled correctly. These should be though.
Damn openwrt buildroot is a pita. Why wouldn't make
package/packagename/clean && make package/packagename/compile re-download
the git tarball!!
On Thu, Apr 16, 2015 at 7:43 PM, max b <maxb.personal(a)gmail.com> wrote:
Hey folks,
I'm running a little late, but it does look like I successfully compiled
an ar71xx binary of notdchpclient and notdhcpserver. I've attached the ipks
to this email in case anyone is super anxious to get running with them,
otherwise I'll be at sudo a little after 8.
See ya!
Max
7:55 p.m.
and with attachments.....
On Thu, Apr 16, 2015 at 7:55 PM, max b <maxb.personal(a)gmail.com> wrote:
Scratch that - those aren't compiled correctly.
These should be though.
Damn openwrt buildroot is a pita. Why wouldn't make
package/packagename/clean && make package/packagename/compile re-download
the git tarball!!
On Thu, Apr 16, 2015 at 7:43 PM, max b <maxb.personal(a)gmail.com> wrote:
Hey folks,
I'm running a little late, but it does look like I successfully compiled
an ar71xx binary of notdchpclient and notdhcpserver. I've attached the ipks
to this email in case anyone is super anxious to get running with them,
otherwise I'll be at sudo a little after 8.
See ya!
Max
19 Apr
19 Apr
2:16 a.m.
On Thu, Apr 16, 2015 at 7:55 PM, max b <maxb.personal(a)gmail.com> wrote:
and with attachments.....
On Thu, Apr 16, 2015 at 7:55 PM, max b <maxb.personal(a)gmail.com> wrote:
> Scratch that - those aren't compiled correctly. These should be though.
> Damn openwrt buildroot is a pita. Why wouldn't make
> package/packagename/clean && make package/packagename/compile re-download
> the git tarball!!
>
> On Thu, Apr 16, 2015 at 7:43 PM, max b <maxb.personal(a)gmail.com> wrote:
>
>> Hey folks,
>>
>> I'm running a little late, but it does look like I successfully compiled
>> an ar71xx binary of notdchpclient and notdhcpserver. I've attached the ipks
>> to this email in case anyone is super anxious to get running with them,
>> otherwise I'll be at sudo a little after 8.
>>
>
Yay! \o/
For some reason these messages ended up in my spam box :/
I spent the evening debugging and improving notdhcp and it really needs to
be compiled again. Hopefully that's easy now?
I wrote down some thoughts on our future plans to auto-switch ethernet
ports from public/private to dedicated extender-node ports. Here they are:
https://github.com/sudomesh/sudowrt-firmware/issues/26
I was thinking about setting a tentative development schedule for roll-out:
Suggested milestones for v0.2:
* Switch to babel [done]
* Upgrade to barrier breaker [done]
* Multi-radio support [done]
* Add-on radios via extender-nodes [nearly there]
* New ubus-based web interface (but no extender-node management) [~three
nights work?]
* Working (but not necessarily ideal) node monitoring system [done?]
* No fake captive portal [postponed]
Suggested timeline:
* May 1st: sudowrt feature-complete for 0.2 and ready to test. First
home+extender node up near curtis st. garden.
* May 7th: First garden node prototype operational at Curtis st.
community garden.
* June 1st:
** sudowrt v0.2 release candidate 1.
** Development of v0.3 begins.
* July 1st: sudowrt v0.2 stable release
* August 1st: v0.3 feature-complete
Potential milestones for v0.3:
* Improved web interface
** Usage statistics
** Extender-node management
* Automatic extender-node connection on all ethernet ports
* Fake captive portal working
* Service browser working well
* Node alignment-helper web interface
* Support for monthly bandwidth sharing cap
Potential milestones for v1.0:
* Per-node internet-routable IPv6 subnet
* Multicast node-monitoring
* Gigabit connection piped into mesh
* Decentralized exit node / VPuN server discovery
* Service browser working well
* Switch to "foo over udp" tunnel
* Auto-launch of local services (wikipedia/openstreetmaps) when USB stick
plugged in
* Logistics management for sale of pre-flashed nodes
* Launch crowdfunding campaign
Potential milestones for v2.0:
* Secure trust-based babel routing
* Automatic node transmit power adjustment
Our efforts to document should keep up with releases, so it may make sense
to take a couple of weeks of focused documentation effort after each
release.
What do you humans think?
--
marc/juul
2:14 p.m.
Ambitious! I'm happy to help with documentation.
On Apr 19, 2015 02:16, "Marc Juul" <juul(a)labitat.dk> wrote:
On Thu, Apr 16, 2015 at 7:55 PM, max b <maxb.personal(a)gmail.com> wrote:
and with attachments.....
On Thu, Apr 16, 2015 at 7:55 PM, max b <maxb.personal(a)gmail.com> wrote:
> Scratch that - those aren't compiled correctly. These should be though.
> Damn openwrt buildroot is a pita. Why wouldn't make
> package/packagename/clean && make package/packagename/compile re-download
> the git tarball!!
>
> On Thu, Apr 16, 2015 at 7:43 PM, max b <maxb.personal(a)gmail.com> wrote:
>
>> Hey folks,
>>
>> I'm running a little late, but it does look like I successfully
>> compiled an ar71xx binary of notdchpclient and notdhcpserver. I've attached
>> the ipks to this email in case anyone is super anxious to get running with
>> them, otherwise I'll be at sudo a little after 8.
>>
>
Yay! \o/
For some reason these messages ended up in my spam box :/
I spent the evening debugging and improving notdhcp and it really needs to
be compiled again. Hopefully that's easy now?
I wrote down some thoughts on our future plans to auto-switch ethernet
ports from public/private to dedicated extender-node ports. Here they are:
https://github.com/sudomesh/sudowrt-firmware/issues/26
I was thinking about setting a tentative development schedule for roll-out:
Suggested milestones for v0.2:
* Switch to babel [done]
* Upgrade to barrier breaker [done]
* Multi-radio support [done]
* Add-on radios via extender-nodes [nearly there]
* New ubus-based web interface (but no extender-node management) [~three
nights work?]
* Working (but not necessarily ideal) node monitoring system [done?]
* No fake captive portal [postponed]
Suggested timeline:
* May 1st: sudowrt feature-complete for 0.2 and ready to test. First
home+extender node up near curtis st. garden.
* May 7th: First garden node prototype operational at Curtis st.
community garden.
* June 1st:
** sudowrt v0.2 release candidate 1.
** Development of v0.3 begins.
* July 1st: sudowrt v0.2 stable release
* August 1st: v0.3 feature-complete
Potential milestones for v0.3:
* Improved web interface
** Usage statistics
** Extender-node management
* Automatic extender-node connection on all ethernet ports
* Fake captive portal working
* Service browser working well
* Node alignment-helper web interface
* Support for monthly bandwidth sharing cap
Potential milestones for v1.0:
* Per-node internet-routable IPv6 subnet
* Multicast node-monitoring
* Gigabit connection piped into mesh
* Decentralized exit node / VPuN server discovery
* Service browser working well
* Switch to "foo over udp" tunnel
* Auto-launch of local services (wikipedia/openstreetmaps) when USB stick
plugged in
* Logistics management for sale of pre-flashed nodes
* Launch crowdfunding campaign
Potential milestones for v2.0:
* Secure trust-based babel routing
* Automatic node transmit power adjustment
Our efforts to document should keep up with releases, so it may make sense
to take a couple of weeks of focused documentation effort after each
release.
What do you humans think?
--
marc/juul
_______________________________________________
mesh-dev mailing list
mesh-dev(a)lists.sudoroom.org
https://lists.sudoroom.org/listinfo/mesh-dev
20 Apr
20 Apr
6:05 p.m.
I spent the evening debugging and improving notdhcp and it really needs to
be compiled again. Hopefully that's easy now?
Yeah shouldn't be very hard. I can do it before the hacknight tomorrow.
I like your timelines! May 1st may prove to be a little soon to have an
actual working release, but I'm happy to see if we can make it work! I'll
try to keep any comments I have on the github issue.
See ya tomorrow!
Max
On Sun, Apr 19, 2015 at 2:16 AM, Marc Juul <juul(a)labitat.dk> wrote:
>
>
> On Thu, Apr 16, 2015 at 7:55 PM, max b <maxb.personal(a)gmail.com> wrote:
>
>> and with attachments.....
>>
>> On Thu, Apr 16, 2015 at 7:55 PM, max b <maxb.personal(a)gmail.com> wrote:
>>
>>> Scratch that - those aren't compiled correctly. These should be though.
>>> Damn openwrt buildroot is a pita. Why wouldn't make
>>> package/packagename/clean && make package/packagename/compile
re-download
>>> the git tarball!!
>>>
>>> On Thu, Apr 16, 2015 at 7:43 PM, max b <maxb.personal(a)gmail.com>
wrote:
>>>
>>>> Hey folks,
>>>>
>>>> I'm running a little late, but it does look like I successfully
>>>> compiled an ar71xx binary of notdchpclient and notdhcpserver. I've
attached
>>>> the ipks to this email in case anyone is super anxious to get running
with
>>>> them, otherwise I'll be at sudo a little after 8.
>>>>
>>>
> Yay! \o/
>
> For some reason these messages ended up in my spam box :/
I spent the evening debugging and improving notdhcp and it really needs to
be compiled again. Hopefully that's easy now?
>
> I wrote down some thoughts on our future plans to auto-switch ethernet
> ports from public/private to dedicated extender-node ports. Here they are:
>
> https://github.com/sudomesh/sudowrt-firmware/issues/26
>
> I was thinking about setting a tentative development schedule for roll-out:
>
> Suggested milestones for v0.2:
>
> * Switch to babel [done]
> * Upgrade to barrier breaker [done]
> * Multi-radio support [done]
> * Add-on radios via extender-nodes [nearly there]
> * New ubus-based web interface (but no extender-node management) [~three
> nights work?]
> * Working (but not necessarily ideal) node monitoring system [done?]
> * No fake captive portal [postponed]
>
> Suggested timeline:
>
> * May 1st: sudowrt feature-complete for 0.2 and ready to test. First
> home+extender node up near curtis st. garden.
> * May 7th: First garden node prototype operational at Curtis st.
> community garden.
> * June 1st:
> ** sudowrt v0.2 release candidate 1.
> ** Development of v0.3 begins.
> * July 1st: sudowrt v0.2 stable release
> * August 1st: v0.3 feature-complete
>
> Potential milestones for v0.3:
>
> * Improved web interface
> ** Usage statistics
> ** Extender-node management
> * Automatic extender-node connection on all ethernet ports
> * Fake captive portal working
> * Service browser working well
> * Node alignment-helper web interface
> * Support for monthly bandwidth sharing cap
>
> Potential milestones for v1.0:
>
> * Per-node internet-routable IPv6 subnet
> * Multicast node-monitoring
> * Gigabit connection piped into mesh
> * Decentralized exit node / VPuN server discovery
> * Service browser working well
> * Switch to "foo over udp" tunnel
> * Auto-launch of local services (wikipedia/openstreetmaps) when USB stick
> plugged in
> * Logistics management for sale of pre-flashed nodes
> * Launch crowdfunding campaign
>
> Potential milestones for v2.0:
> * Secure trust-based babel routing
> * Automatic node transmit power adjustment
>
> Our efforts to document should keep up with releases, so it may make sense
> to take a couple of weeks of focused documentation effort after each
> release.
>
> What do you humans think?
>
> --
> marc/juul
>
>
21 Apr
21 Apr
12:12 p.m.
Ok attached are the most recently compiled ipks. I'm fairly confident that
they match juul's most recent commits.
Also - I was looking into it, and I think that as long as we're targeting
supported openwrt chipsets, we can probably wire up a continuous
integration server to build our packages automatically.
This unfortunately won't work for the time being with our whole firmware.
Re-building the entire buildroot takes too long (at least for the free and
easily configurable options that I encountered). Other options include:
- A VPS which has a git hook or other command which rebuilds the entire
buildroot whenever the code changes.
- We build a sudowrt SDK or imagebuilder or whatever that is. That would
substantially reduce the amount of time that firmware builds would take,
but would also require us to rebuild the sdk/imagebuilder every time that
we want to patch kernel, etc.
- We more or less keep the system we have, except that we add some scripts
which rebuild parts of the firmware. I know that juul spent a long time
looking over the image builder and I've spent enough time looking over it
to know that it's not particularly easy, but it would be pretty awesome to
at least have a script which will go through all the steps to update a
package feed, clean all of the relevant lingering files, and (re)build a
package.
Just some thoughts.
On Mon, Apr 20, 2015 at 6:05 PM, max b <maxb.personal(a)gmail.com> wrote:
I spent the evening debugging and improving notdhcp
and it really needs to
be compiled again. Hopefully that's easy now?
Yeah shouldn't be very hard. I can do it before the hacknight tomorrow.
I like your timelines! May 1st may prove to be a little soon to have an
actual working release, but I'm happy to see if we can make it work! I'll
try to keep any comments I have on the github issue.
See ya tomorrow!
Max
On Sun, Apr 19, 2015 at 2:16 AM, Marc Juul <juul(a)labitat.dk> wrote:
On Thu, Apr 16, 2015 at 7:55 PM, max b <maxb.personal(a)gmail.com> wrote:
and with attachments.....
On Thu, Apr 16, 2015 at 7:55 PM, max b <maxb.personal(a)gmail.com> wrote:
> Scratch that - those aren't compiled correctly. These should be though.
> Damn openwrt buildroot is a pita. Why wouldn't make
> package/packagename/clean && make package/packagename/compile re-download
> the git tarball!!
>
> On Thu, Apr 16, 2015 at 7:43 PM, max b <maxb.personal(a)gmail.com> wrote:
>
>> Hey folks,
>>
>> I'm running a little late, but it does look like I successfully
>> compiled an ar71xx binary of notdchpclient and notdhcpserver. I've attached
>> the ipks to this email in case anyone is super anxious to get running with
>> them, otherwise I'll be at sudo a little after 8.
>>
>
Yay! \o/
For some reason these messages ended up in my spam box :/
I spent the evening debugging and improving notdhcp and it really needs
to be compiled again. Hopefully that's easy now?
I wrote down some thoughts on our future plans to auto-switch ethernet
ports from public/private to dedicated extender-node ports. Here they are:
https://github.com/sudomesh/sudowrt-firmware/issues/26
I was thinking about setting a tentative development schedule for
roll-out:
Suggested milestones for v0.2:
* Switch to babel [done]
* Upgrade to barrier breaker [done]
* Multi-radio support [done]
* Add-on radios via extender-nodes [nearly there]
* New ubus-based web interface (but no extender-node management) [~three
nights work?]
* Working (but not necessarily ideal) node monitoring system [done?]
* No fake captive portal [postponed]
Suggested timeline:
* May 1st: sudowrt feature-complete for 0.2 and ready to test. First
home+extender node up near curtis st. garden.
* May 7th: First garden node prototype operational at Curtis st.
community garden.
* June 1st:
** sudowrt v0.2 release candidate 1.
** Development of v0.3 begins.
* July 1st: sudowrt v0.2 stable release
* August 1st: v0.3 feature-complete
Potential milestones for v0.3:
* Improved web interface
** Usage statistics
** Extender-node management
* Automatic extender-node connection on all ethernet ports
* Fake captive portal working
* Service browser working well
* Node alignment-helper web interface
* Support for monthly bandwidth sharing cap
Potential milestones for v1.0:
* Per-node internet-routable IPv6 subnet
* Multicast node-monitoring
* Gigabit connection piped into mesh
* Decentralized exit node / VPuN server discovery
* Service browser working well
* Switch to "foo over udp" tunnel
* Auto-launch of local services (wikipedia/openstreetmaps) when USB stick
plugged in
* Logistics management for sale of pre-flashed nodes
* Launch crowdfunding campaign
Potential milestones for v2.0:
* Secure trust-based babel routing
* Automatic node transmit power adjustment
Our efforts to document should keep up with releases, so it may make
sense to take a couple of weeks of focused documentation effort after each
release.
What do you humans think?
--
marc/juul
3537
days inactive
3541
days old
6 comments
3 participants
participants (3)
-
Marc Juul -
max b -
Mo Balaa