Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Non-existent conf-cancel #5
Hi, the ifmon manpage refers to spawning /etc/net/conf-cancel, however, I cannot find it in the source code.
There is conf-release, so I presume that is what is intended.
If I plug in a ethernet cable, conf-request is called. Fine, but unplugging the cable does nothing. Neither conf-cancel nor conf-release are called.
I changed this line in /etc/net/mode-lan0, thinking that is needed to recognize cable being unplugged:
But no, makes no difference.
Have I missed understanding something?
Oh, yeah, it's definitely conf-release. I think I need to update the docs on this.
conf-release only gets called if conf-request has exited successfully. This is to allow continuous-mode dhcp clients, like
dhcp-once is probably not what you want for a wired connection. It works just like auto-dhcp for the first carrier-up and the first subsequent carrier-down event. The second carrier-up and any carrier events after that will be ignored. This is meant for WPA (Wi-Fi) links.
Sorry, my bad, it should be
It seems to work well for me, conf-cancel gets called when the cable is pulled.
If you have
OK, fixed that, now all working.
Note, I applied a patch, changed /var/interfaces to /var/local/interfaces, as in easyOS /var is a tmpfs, with only certain sub-directories persistent (such as /var/local). But you don't have to do that, it is easy enough to apply the patch before compiling.
Also /run is a tmpfs, so I have to create /run/ctrl prior to running ifmon.
I have posted a progress report to my blog, kindly let me know if anything is wrong in it:
Regarding /sbin/service, that was for minibase-br, and most likely it won't stay like that. The exact path is not important, all tools should work fine regardless of where they are installed.
For a system with a more conventional fs tree layout, dumping everything into /sbin probably makes more sense than keeping /sbin/service.
I'm not sure I get the idea behind /etc/net/identify, but it wasn't supposed to look like that. In pretty much all cases it should be just
That profile script should probably be called "mode-lan", without the 0 part. It's not a second name for interface, it's more like the role of the device in the system. At least that's what it was meant to be.
Let's say there's a box with four Ethernet interfaces: one uplink to the ISP, two going to local boxes A and B, and one unused. The expected output of
with appropriate setup scripts.
I think I need to work a bit more on the documentation.
Yes, that's exactly how it's supposed to be done.
Ha ha, yes, I wondered if I was being a bit too "creative" with /etc/net/identify. I will think about that some more, and likely modify that blog post soon.
Notice though, although eth0 is assigned to lan0, etc., /etc/net/mode-lan is only copied to /etc/net/mode-lan0 if the latter doesn't exist. It is just creating a default behaviour, in case the user hasn't manually created such a script.
Also, I take your point about "eth0: A", but I didn't see, for myself anyway, any problem with always assigning "eth0: lan0", regardless of what I intended to use lan0 for.
I don't know if you would consider it worthwhile to have something like "ifctl lan1 rename B". Even an option to remove the assignment.
Thanks for the feedback.