LinuxQuestions.org - Rewrite of my DDI thing to support simple configuration for each device

- Slackware - ARM (https://www.linuxquestions.org/questions/slackware-arm-108/)

- - Rewrite of my DDI thing to support simple configuration for each device (https://www.linuxquestions.org/questions/slackware-arm-108/rewrite-of-my-ddi-thing-to-support-simple-configuration-for-each-device-4175593706/)

Rewrite of my DDI thing to support simple configuration for each device

I felt the need to be able to make it easier to add a new network device into my Detect Driven Initialization (DDI) while still keeping the flexibility to write a custom script for any device.

I came up with a solution that has just 10 configuration directive to deal with the most common scenarios without having to write custom scripts: LANs, VLANs, Bridges, WiFi, PPPoE.
Each one can have static or DHCP assigned address and normal LAN also supports aliases

Here's the template cfg file which should be self explanatory.

Code:

#device type: one of ETHER BRIDGE VLAN WIFI 

#TYPE=ETHER|BRIDGE|VLAN|WIFI



#for bridges and vlans the list of slave devices used

#space separated list of slave devices for bridges or other devices that are built similarly

#SLAVE_DEVS="NIC0 NIC1 ... NICn"

#EG for bridging eth0 and wlan0

#SLAVE_DEVS="eth0 wlan0"

#EG for creating vlans 5 7 and 20 on eth1

#SLAVE_DEVS="eth1.5 eth1.7 eth1.20"



#similarly the slave devices need to know which is the master device

#MASTER_DEV=NIC

#EG

#MASTER_DEV=br0 #for bridge

#MASTER_DEV=eth1 #for any of the vlan devices on eth1



#for wifi choose whether to start it in managed mode or master mode

#master mode requires also configuring hostapd

#managed requires setting up wpa_supplicant.conf 

#adhoc mode not supported

#WIFI_MODE=MASTER|MANAGED

#EG for managed mode

#WIFI_MODE=MANAGED



#show the device should acquire address

#IP/MASK for static address

#DHCP for acquiring ip dynamically

#PPPOE for negotiation connection via pppoe (statid address woulkd go in the peer config)

#IP=IP/MASK|DHCP|PPPOE



#force numbering for the ppp interface, this can tecnically be in the peer config 

#but it's handy to have it here

#UNIT=<integer>

#EG for creating ppp0 interface

#UNIT=0



#optional peer for PPPOE

#if you don't set it the peer will need to have the same name as the interface that is set to IP=PPPOE

#PEER=PEER_NAME

#EG

#PEER=comcastxfinity



#optionally if you want any interface to have alias IP configure the ALIAS[n] array with IP/MASH|DHCP

#ALAIS[n]=IP/MASK|DHCP

#EG set eth0:1 with 10.20.30.40/24

#ALIAS[1]=10.20.30.40/24



#optional extra script to command to be executed after taking up NIC 

#EG 

#UP_EXEC="dnsmasq -C /etc/dnsmasq/${INAME}.conf"



#optional extra script or command to be executed before taking down NIC

#EG

#DOWN_EXEC="kill -9 $(ps -eo pid,cmd |grep dnsmasq | grep  -w "${INAME}\.conf" |awk '{print $1}')"

With this reworking also comes better handling of dependencies allowing for bridges (otherwise undetected by udev at boot time) to come up correctly triggered by the slave devices.

Is anybody interested ?

Ooops: I forgot about the default GW ... I'll fix that asap

GW added to the config and fixed master mode wifi NICs not executing DOWN_EXEC (which left dhcp server active).

I'll make a video showing the benefits of this because I think the description did not come trough.

Yesterday I attempted making a video but I'm not yet satisfied with it so I'll write a little moire about it:

Firstly why not just unplug the damn usb dongle ?
Although it's mostly harmless to unplug live usb dongles I've had an rtl8150 module crash when unplugging and/or removing module while interface is up but most importantly mere unplugging would leave ane daemons running on the unplugged device in a mess (like for instance DHCP server, hostapd) and subsequently re-plugging in might not achieve the desired effect.

But the button and LEDs aren't really part of DDI.
Yes and no: technically DDI alone is only good for initializing devices upon detection, you still need to tell it which device to prepare for removal and that's where the buttons come into play, basically my gpio tools inter-operate with DDI and vice versa (plugging in a device would activate DDI trough udev and have it tell the gpio tool to turn on the associated led, the associated button would tell DDI to toggle the status od the device present in the associated usb port).

Why not just use the stock rc.d scripts to configure your network devices.
I really wanted some things to happen automatically when the devices are detected by udev. Right from the start the idea was to have things like guest wifi AP activated when a specific wifi dongle was plugged in. Ok some dongles would allow you to have multiple VAPT running simultaneously but I've never had one of those to play with and besides that there were other things I wanted to happen automatically as the dongle gets inserted, like backup internet link via 3G/4G internet stick, usb lan dongles to acquire IP via DHCP automatically and more. Way back when all this started I was using udev to call the slightly modified rc.d scripts but every now and then things would brake because of modifications introduced in the rc.d scripts so I started organizing the idea into something that would require less work in maintenance and leave the stock rc.d scripts untouched for the rest of the system initialization (just make rc.inet? not executable so that DDI can do it's thing undisturbed).