Rare project developers

[mc36 <>]

hi,
this dynamic subinterface exporting thing was a bigger than initially tought:
https://github.com/mc36/freeRouter/commit/2ed73ee94b91a89a529b4d207d0a6a1eee41c900
and not yet complete because there are two remaining user-configurable knobs
to export the dynamic access and dynamic bridge ranges... these should go too,
but for now, i just concentrated on the very core of this feature....
hopefully those will be smaller changes compared to this...
regards,
cs


On 2/27/22 09:49, mc36 wrote:
> hi,
> the preparation for it (the negotiation) was straightforward afterall:
> https://github.com/mc36/freeRouter/commit/d7168beb35c61128b96e12b5ecb2725b4edc8310
> the dataplane tests are not fully run but all passed about 10% of the tests...
> after that my homenet got the update and everything went smoooth during the
> autoupgrade, fortunately the process first upgrades the dataplanes and the
> jar is the last in the row so introducing additions to the dataplane protocol
> seems easy-peasy keeping this in mind.... :)
> now there will be the harder part, the "export-port tunnelX/hairpinX/etc 
> dynamic"
> and the subinterface auto-export stuff....
> regards,
> cs
>
> On 2/27/22 08:48, mc36 wrote:
> > hi,
> > hi,
> >
> > On 2/27/22 08:30, mc36 wrote:
> > > >        * The user doesn't have to create "export-port" stanzas for
> > > >            sub-interfaces explicitely
> > >
> > > right now, the dynamic range is also user managed...
> > > there will still be special interfaces that need to be exported,
> > > but my idea for them now is to allow the knob "dynamic" where we
> > > accept frontpanel names or mostly subifids... these are pppoe
> > > virtual accesses, tunnels, hairpins, and basically everything
> > > that is not sdn interface... we already scan the available interfaces
> > > for virtual-accesses, i can easily extend that part to subinterfaces too...
> > > the dataplanes already inform freerouter of the dynamic ranges they
> > > support so it seems easy-peasy as said before... that'll be the
> > > next pokemon to catch... :)
> >
> > for this to happen, a bit stricter dataplane behavior will be enforced:
> > the capability, platform, portname and dynrange messages will be processed
> > at the beginning of the session, the dynrange will terminate this phase...
> > all the future messages must be sent interleaved in between these...
> > freerotuer will not send anything during this phase at all...
> > after the dynrage message, these messages wont be interpreted anymore
> > and freerouter will send the same messages that it's already sending...
> >
> > frederic, maybe alox: please prepare the bffwd for this thing...
> > right now i dont get portname messages at all, the rest seems to be
> > already fulfilled, but you maintain the code, please ensure...
> >
> > thanks,
> > cs