I’ve got a very basic WUI feature request that I’m pretty sure would be at least useful at one time or another to all users. I’m also hoping I’m posting this in the correct section; admins feel free to correct as appropriate.
Currently, the DHCP Configuration page in WUI has the “Current Leases” section with connected devices and a list of former devices that “strikethrough” to indicate a “Not Connected” status. This is fine and wonderful but the same simple information is missing for static reservations. As in “Current fixed leases” has MAC, IP, Remark for Hostname, “next-server”, “filename”, “root path”, Check box for Enable/Disable, Edit, and Trash. There is no way from the WUI to tell if a Static/Reserved IP Host is currently connected or not. I’m looking for literally anything, strikethrough or text color on disconnected reservations, a green/red dot column, a star in the Remarks, or literally whatever is fastest and easiest for the Devs to implement. I believe (hope?) this would be a useful feature for many admins as I’m sure lots of us have devices that are more easily checked by the WUI and it also allows connection troubleshooting from the router.
Am I asking for more than I think I am or is this something quick and useful that could easily be added in a future release?
This is more or less the functionality of WhoIsOnline. This function gives the the activity information based on peridiocal look-ups. The period is 5 min, which is shorter than the lease times typically used.
A static lease must not renew the lease, usually it does nevertheless, therefore there is no direct information to the DHCP server.
Do you want to know if a MAC address is already assigned to a fixed IP address?
If you just want to know if the client is online, then follow Bernhard Bitsch advice and use WhoIsOnline.
Thanks Bernard, I do believe this gets me something resembling the tool I was looking for in general. I’m used to being able to check an ARP Table or connected device list regardless to which manufacturer I’m dealing with from business to consumer class. It’s a just so de rigueur that I didn’t expect to go looking for an add-on to my detriment.
RC, I was looking for something resembling an ARP table or Connected Devices list, such as is in most SMB and Consumer equipment (which ipfire does for dynamic leases by default). I’m aware a lot of Enterprise hardware (especially older stuff) doesn’t necessarily mix the two into a single location but it’s quite useful at times and seemed to be something that could be simply implemented, no? (I really don’t know…)
I’m not up to speed enough on coding in the modern era or the underpinnings of ipfire to know what’s simple to indicate and not. Ipfire is so “finished” or well put together that it seemed a logical and hopefully simple item to be on the “todo list”. If I’m wrong, apologies and I’ll continue to use wio as an add on as Bernhard suggested. That said, it’s a powerful tool designed for other purposes which seems like overkill for something so simple that I believe many users would find useful from time to time. Again, I could be very wrong but I figured the squeaky wheel is the one that gets the grease.
I don’t think, wio is overkill.
It is just the right tool for checking connectivity of devices, which is the purpose of your suggestion.
Depending on the DHCP server isn’t sufficient. What about installations not using DHCP at all? You can configure IP settings totally static. Whether this is really comfortable, is not the point. It is possible with IPFire.
My favourite config is to setup IP <–> device(MAC) relations by fixed leases in DHCP server. For a smooth integration of new devices a small ( 2-4 IPs) set is defined for dynamic leases.
Thus it is centrally configurable.
For connectivity analysis use wio. This tool allows to check other ( external ) devices also and does depend on functions used by client applications ( ICMP ). This matches the sight of the environment by IPFire and by end-user applications, making it easier to check possible problems on connected devices.
Hi Adolf,
I saw that after installing wio at Bernhard’s suggestion. It gets the job done for sure. I’m still getting used to ipfire, so I’ll be putting this into practice. Thanks for the tip!
Bernhard, don’t get me wrong. I do think wio looks to be a great tool and I’m looking forward to using it now that I know it’s available. It looks to be quite powerful and easy to use, which is something I’ve learned to appreciate after a decade or two of using Linux. It’s just not “the information I was looking for in the place I expected it to be after experience with many off the shelf routers”. That’s not criticism, simply observation and something that, in an effort to be a “useful user”, I thought the devs might wish to be aware of. Ipfire has reached a level of polish that changes like my request may or may not be something that they wish to do but it’s not out of the question if it’s easy since the product of their work is obviously long past the beta stage of hacking at a jungle of functionality problems.
As for the DHCP server not being sufficient, it is simply a TS step: If the DHCP isn’t communicating with the device, it’s got a problem: next step TS physical connectivity and device config. It isn’t the end all but it’s a useful step I’ve almost always found it in this area rather than an “add on”, so it was a tad awkward to a new user. Again, not criticism or complaint, simply observation. wio works great but it’s not “already installed” from bare bones, so maybe that’s the better solution.
I actually run most of my networks similarly to your suggestion but with a bit of a twist based on my “outside source” relationship with my clients. My clients are usually smaller entities with lots of free range devices that need connectivity (laptops, phones, etc.) and they don’t want to bring me in for a trip charge because some new employee or visiting partner needed access, so it’s reserve a decade or two of addresses for necessary statics then just DHCP everything else. Either way, both our topologies are well served by wio. I’ll be looking forward seeing how else I can use it.
Thanks again for your time and advice! It was definitely useful and appreciated!
And as such, the devs are not gonna want to spend time on something that already exists
I believe your suggestion has merrit and as such I believe it’s worth while to implement but not by ipfire devs, i would rather they keep working on more pressing matters
In cases like this in the past, I usually created my own modifications and then after I worked the addon through the alpha state I would share it with the community, that way you get free beta testers, free community devs (if the idea is useful) and you get to help other people.
As an added benefit you also learn some new skills like perl (the language).
Thats where I would start, if you don’t have enough time or just don’t want to travel that route, you’re going to have to hope the devs agree that it’s worth their time to add a feature that already exists, but I WOULDN’T count on it.
As my suggestions have helped a bit, there only remains the wish to integrate wio to the basic distribution.
If the addon is stable enough, which I suppose is given for an official addon, it is only a more organisational step. sfeddersen is part of the dev community.
After messing around with it for a day or so, I have to agree that wio seems to handle everything I would need, just in a different place than I initially expected. It definitely does the job though.
Thanks for the insight on which language is used for ipfire. Ironically, I have a friend who’s an old hand at perl that’s pretty bored and stuck “at home” taking care of her mother in her final years. This just might be the perfect project for her. I’ll have to check in on it. I know I can provide her with the hardware necessary to test it.
I built something there once. Unpack the archive and copy the dhcp.cgi on the IPFire to /srv/web/ipfire/cgi-bin. @sltaway , is this how you imagined it? dhcp.cgi.tar.gz (11,6 KB)
