I noticed a couple of issues in rc.inet1 while testing vlans.


(issue 1, ip link set shouldn't mention 'type vlan')

rc.inet1.conf allows IFOPTS to set a vlan name

rc.inet1 loops over these options and sets each of them using "/sbin/ip link set dev ${1} type vlan $IFOPT"

this triggers an error "vlan: unknown command "name""

this is reproduced on the commandline by issuing something like "ip link set dev eth0.6 type vlan name xs4all"

the problem is the 'type vlan' part, when omitted, it works as expected

although this is a trivial patch, it looks like there's a bit more needed even -> I then noticed a few other problems



(issue 2, vlan naming clashes with logic checking for ipv4/ipv6 config)

when a vlan is named using IFOPTS, then this name gets used in /proc too
this then becomes problematic when rc.inet1 uses the original nic name to check, like looking at something like

/proc/sys/net/ipv6/conf/eth1.11/autoconf

instead of the 'renamed' location like

/proc/sys/net/ipv6/conf/<vlan name>/autoconf



(issue 3, nic/vlan cleanup logic seems 'off')

upon a restart the script first tries to 'clean up' everything in order to start fresh

I agree with the basis approach of 'first clean everything up so we can start over', but noticed that what gets cleaned up, depends on the current rc.inet1.conf file instead of on the current system state (i.e. available nics/vlans/etc)

this means that processing/checking larger rc.inet1.conf changes by using rc.inet1 (*_)restart can become quite confusing, since for example changes will be not be processed due to old nics still being 'in use'



I'll need to fix this myself at some point, since I like the convenience of using vlan custom naming, but it's not on the top of my priority list atm, so at least I wanted to mention it here, given the sw15/swcur progress

While IFOPT allows you to set any option accepted by the ip command, the entire rc.inet1 does not support changing the name of the interface from what is expected by the script.

VLAN interfaces are assumed to be named <interface>.<vlan ID> - there is no support for using an arbitrary name and using that in place of the expected format as per rc.inet1.conf.

Again, this comes down to trying to use a specific interface name, rather than accepting the default/assumed interface names, which has always been the way rc.inet1 works.

This has always been the way rc.inet1 works.

rc.inet1 does not store state information of the current interface configuration in order to know what needs to be deconfigured upon a restart - it only knows about the interfaces as configured in rc.inet1.conf at that point in time.

I admit, this does have it's annoyances when it comes to changing configurations and then restarting the interface; but adding state storage to rc.inet1 just seems overkill for the very very minor problems that the admin may have to correct if they change their interface configurations regularly.

rc.inet1 isn't designed to cater for every config or change - it's there to help set up the interfaces, not manage every aspect of them (which would probably require a much much more complicated system like in Ubuntu et al).

@tadgy,

Tnx for the elaborate reply (and for your work, I recognize your handle from the network-scripts README's ).

I understand and agree with the 'design choices' and you're right -> it's fairly easy to 'work around' once aware of what's going on, so time is probably better spent on some other areas.