GNOME Control Center: "Network Devices" module

till-kamppeter · April 27, 2021, 7:27pm

Hi,

as many of you probably know my primary project I am working on at OpenPrinting is the change of the printing and scanning architecture to an all-IPP model which especially works with sandboxed packaging, including the all-Snap Ubuntu Core desktop.

Printer and scanner drivers are emulated driverless network devices on the local machine, also CUPS is (as it always was) emulating IPP network printers. All these emulated devices advertise themselves in the local network via DNS-SD to get auto-discovered by clients (like CUPS or applications which print and/or scan) and each device has a web interface with which the user can configure the device.

Most general network devices, as routers, access points, security cameras, IoT, smaor home, … devices work the same way, they advertise themselves via DNS-SD and have a web interface to configure them.

Problem for the user is that he does not have a way to get an overview of such devices. avahi-browse is a command line tool and avahi-discover is GUI but very technical, made for developers and admins to debug DNS-SD problems, less for a user to find available devices and services.

During my thoughts and discussions on the printer setup of the future, for the new architecture I came to the idea of creating a kind of "user-friendly avahi-discover". a module for the GNOME Control Center which lists all network services which advertise themselves via DNS-SD (and so are discovered via Avahi), each distinct service only once (and not repeatedly due to the different network interfaces, IPv4/IPv6, and encrypted/unencrypted) and with buttons for common operations, especially one button which opens the device’s web admin interface in a browser, but also with additional, service-type-dependent buttons for common operations (for example in a Printer Application, aka printer driver, to auto-connect all supported printers), on an access point to turn its Wi-Fi on and off, … The buttons do not need to pop up fancy tools, often it is enough to let them short-cut into certain palces of the device’s web interface.

This way it will get much easier for users to lead with network devices. They do not need to find out which default host name or IP address they have and alsosee which devices are actually reachable (connected, turned on, in the same subnet).

I have posted this project as a project idea for the Google Summer of Code 2021 and a student has submitted a proposal to implement this project. He also already presented it to the GNOME developers as a feature request but they are not very convinced about it.

So I want to ask you about what you think about this project and whether you would like to have this functionality in the GNOME Control Center. I am also very grateful if one or another could step up to help convincing the GNOME developers to include this and also to help mentoring the student.

Note that I by myself am not a GUI developer but architect, designer, and developer of the printing infrstructure, what is happening behind the scenes when you click on “Print”. And one problem we have at OpenPrinting is to actually get the GUIs up-to-date with the newest development of the printing stack.

So any help is appreciated

Till

jamesh · April 28, 2021, 1:56pm

Is this particularly common outside of the printer market? I don’t think I’ve ever any of my routers advertise their web interface like this. I guess this would be down to Windows not having support for this kind of discovery by default.

On my home network, the only systems advertising a _http._tcp service are a few boxes running Kodi (which give a 401 Unauthorized response because I don’t think they’ve been set up for web administration). The rest of the advertised records are for device specific protocols.

If it’s mainly printers that people are likely to find with this kind of UI, might it make sense to put this kind of feature into the printers control panel? If a local print queue represents a remote printer discovered via mDNS and an _http._tcp service is published with the same name, then it would make sense to include a button there to launch the printer’s web UI.

till-kamppeter · April 28, 2021, 3:16pm

I get the following:

$ avahi-browse -t _http._tcp
+ enx8c47be090292 IPv6 dLAN 1200+ WiFi ac                            Web Site             local
+ enx8c47be090292 IPv6 test                                          Web Site             local
+ enx8c47be090292 IPv6 PostScript Printer Application (4187D4)       Web Site             local
+ enx8c47be090292 IPv6 HP OfficeJet Pro 8730 [08C229]                Web Site             local
+ enx8c47be090292 IPv4 test                                          Web Site             local
+ enx8c47be090292 IPv4 PostScript Printer Application (4187D4)       Web Site             local
+ enx8c47be090292 IPv4 dLAN 1200+ WiFi ac                            Web Site             local
+ enx8c47be090292 IPv4 HP OfficeJet Pro 8730 [08C229]                Web Site             local
+ wlp0s20f3 IPv6 dLAN 1200+ WiFi ac                            Web Site             local
+ wlp0s20f3 IPv6 test                                          Web Site             local
+ wlp0s20f3 IPv6 PostScript Printer Application (4187D4)       Web Site             local
+ wlp0s20f3 IPv6 HP OfficeJet Pro 8730 [08C229]                Web Site             local
+     lo IPv4 HP OfficeJet Pro 8730 [08C229] (USB)          Web Site             local
$

Cleaning out duplicates due to IPv4/IPv6 and network interfaces I get

dLAN 1200+ WiFi ac                            Web Site             local
test                                          Web Site             local
PostScript Printer Application (4187D4)       Web Site             local
HP OfficeJet Pro 8730 [08C229]                Web Site             local
HP OfficeJet Pro 8730 [08C229] (USB)          Web Site             local

Most entries (all except “dLAN 1200+ WiFi ac”) are actually printers, only my access point advertises its web interface here, my router does not appear, also not my second access point, meaning that you are right in terms of non-printing devices usually not advertising their web interfaces.

So putting this functionality into the printer tool makes sense.

Here one would add entries on two places, once as you tell, add a button to get to the web admin interface of the printer for each print queue listed on the main panel, but second, in the add-printer wizard also list all DNS-SD-discovered printing devices and add buttons to point to the web interfaces. Sometimes one has to set something in the web interface before creating the CUPS queue.

jamesh · April 29, 2021, 2:49pm

If you’re dealing with printers that have tried to implement Apple’s Bonjour printing guidelines, then you should be able to find them by browsing for for a _printer subtype of _http._tcp. The following should find :

avahi-browse -kt _printer._sub._http._tcp

Or in the case where you want to find the web interface of a particular printer, you’d call Avahi’s ResolveService API with the service name that was advertised via _ipp._tcp, and _http._tcp as the service type.

More details can be seen in section 7.5 of Apple’s docs:

https://developer.apple.com/bonjour/printing-specification/bonjourprinting-1.2.1.pdf

It would be nice if there were more types of devices that advertised themselves this way, but I don’t think we’re in a position to move the needle. Maybe a web browser extension to display a menu of all available local web servers would be a better fit for the non-printer use case?