public inbox for b.a.t.m.a.n@lists.open-mesh.org
 help / color / mirror / Atom feed
From: Gui Iribarren <gui@altermundi.net>
To: The list for a Better Approach To Mobile Ad-hoc Networking
	<b.a.t.m.a.n@lists.open-mesh.org>
Subject: [B.A.T.M.A.N.] Complete netifd integration in openwrt
Date: Sun, 28 Jul 2013 21:03:00 -0300	[thread overview]
Message-ID: <51F5B134.4030203@altermundi.net> (raw)

Hello folks,
i finally took the time to finish the netifd integration in openwrt.
since 2013.0.0, the "slave interfaces" moved from 
batman-adv.bat0.interfaces to network.meshblah.proto=batadv, so that 
netifd could properly manage the setup and teardown, avoiding some race 
conditions i faced at that time (about a year ago)
now i did the same for the "mesh interface", batX, which until now had 
the parameters still set in /etc/config/batman-adv.

### So, what in 2012.4.0 was

# cat /etc/config/batman-adv
config 'mesh' 'bat0'
         option 'interfaces' 'mesh0'
         option 'ap_isolation' '1'
         option 'gw_mode' 'server'

# cat /etc/config/network
config interface 'mesh0'
	option ifname 'eth2'
	option proto 'none'
	option auto '1'

### now fully turns into:

# cat /etc/config/network
config interface 'bat0'
	option proto 'batmesh'
	option ifname 'bat0'
	option ap_isolation '1'
	option gw_mode 'server'

config interface 'mesh0'
	option ifname 'eth2'
	option proto 'batadv'
	option mesh 'bat0'

[about the proto name... since proto=batadv was already taken for slave 
interfaces, i couldn't come up with anything better than "batmesh" :(
I was talking with Nico just now, and he suggested "batadvmesh"
in any case, suggestions are much welcome. Anyway, proto=bat.*mesh is 
for setting the mesh parameters]

and well, to avoid breaking current configs unnecesarily [over 
sysupgrades (or opkg upgrades?)] i included a small uci-defaults 
migration script to take care of that; it transparently migrates all 
current /etc/config/batman-adv settings to netifd-style.

Why the integration? reliability in the setup; no more race conditions 
whatsoever at boot, or runtime: i even tried rmmoding the module, and 
doing "ifup mesh0" brought everything up again cleanly. while netifd had 
some stigmas when it was born, now (in my experience) it has grown to a 
pretty solid nifty daemon.

I made a pull request on
https://github.com/openwrt-routing/packages/pull/4
comments welcome :D

if you prefer [PATCHES] over mail, just ask :)

as always, cheers, and thanks for being so cool people!

Gui

             reply	other threads:[~2013-07-29  0:03 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-29  0:03 Gui Iribarren [this message]
2013-07-29  0:39 ` [B.A.T.M.A.N.] Complete netifd integration in openwrt cmsv
2013-07-29  1:18   ` Gui Iribarren

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=51F5B134.4030203@altermundi.net \
    --to=gui@altermundi.net \
    --cc=b.a.t.m.a.n@lists.open-mesh.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox