Reasonable change to generated eth0.sh??

[ToasterKing]

With Tiny Core 3.5.1 it looks like the net config GUI not only creates the /opt/eth0.sh file, it adds an entry to the end of bootlocal.sh to run eth0.sh.  It also adds entries to .filetool.lst and bootlocal.sh to make sure eth0.sh gets backed up and executed on startup.

The first line of the generated eth0.sh is
    pkill udhcpc
to stop any dhcp requests that are going on.

Would there be any downside to changing the GUI so that the line that gets generated is
    pkill -f 'udhcpc.*eth0 '
(The space after the interface is potentially important, e.g. interface eth1 and eth10)

This would kill dhcp clients only for the given interface but leave clients on other interfaces alone to acquire addresses via dhcp if they can.

The biggest disadvantage I can see is that later dhcp responses wipe out the statically configured gateway and DNS nameserver entries, but that's currently an issue when dhcp is running on multiple interfaces anyway.

[tinypoodle]

For statically configuring DNS with udhcpc see here:
http://forum.tinycorelinux.net/index.php?topic=8019.0

[ToasterKing]

Thanks tinypoodle, I'd seen your suggestion before which handles a purely static configuration situation as long as the static configuration is done via the dhcp.sh script.

Unfortunately the way the default dhcp.sh script is written to handle receiving a DHCP response causes it to overwrite resolv.conf with every response that comes in (which obviously you know but others might not).

If someone wanted to use DHCP to set the nameserver list but not have it blanked or overwritten when a second or subsequent interface got a DHCP response they'd need something more complex.  Especially since the order that interfaces get their response can be non-deterministic and non-repeatable.

That's actually what I meant when I said it's currently an issue.  The proposed change doesn't add a new problem or completely fix the existing problem.  If you're setting DNS values and didn't already know about the problem, it probably makes the existing problem more obvious since it leaves udhcpc running on other interfaces.

I don't need DNS right now myself, but when I do I'll float whatever changes I end up making to fix this back by everyone for consideration.  I just thought the syntax to kill udhcpc on only one interface might be a useful tweak even without a final fix.

I've had a couple technicians confuse themselves pretty badly by using the GUI to statically set an IP on one interface thereby breaking all the others that used to dhcp.  Training issue, I know, but this tweak would fix the problem for me.

[tinypoodle]

Thanks tinypoodle, I'd seen your suggestion before which handles a purely static configuration situation as long as the static configuration is done via the dhcp.sh script.

Not quite so, or at least not only.
This would apply to every instance of udhcpc changing default values to users desire, be it in customized scripts or running udhcpc manually