3 ms·

The issue with UPNP is not that it's misunderstood. The issue is that somebody implementing it has to pay hundreds of bucks to read the ISO. Nobody cares about

The issue with UPNP is not that it's misunderstood. The issue is that somebody implementing it has to pay hundreds of bucks to read the ISO. Nobody cares about ISOs in the web world, everything that's not an RFC will never receive well penetrated adoption. On the other hand printers are working on your smartphones but not on your Linux desktop. Ever thought why that is? The reason is an outdated resolve concept that needs lots of (possibly going wrong) manual configuration just to get a Multicast DNS-SD resolution feature going. It's such a hardcore fail when considering that the goal for zerconf and DNS-SD was to ease things up, and on Linux it made things worse because of config fatigue.

oshiar53-0 5y ago
I wonder how I can finally make it work on a Linux desktop
forty 5y ago
I'm under the impression that mDNS / DNS-SD worked out of the box on Ubuntu at least, for printers (I'm not sure, maybe installing avahi manually is needed if it's not there by default, but I wouldn't call that "a lot of manual configuration")
- jcrawfordor 5y ago
  Avahi often seems like a mixed bag. Sometimes it Just Works, but other times it doesn't---one of the big pain points of zero-configuration systems has always been opacity and difficult troubleshooting. For example, it's not at all unusual for well-meaning consumer network appliances to monitor and interfere with IGMP ("IGMP snooping"), ostensibly for performance reasons, but then unintentionally break mDNS. It can be very hard to figure out that that's what's happening when your printer just isn't showing up. In general distributed systems tend to be a pain to troubleshoot, but especially so the zero-configuration efforts since they often try excessively hard to be completely invisible.
  - tux3 5y ago
    If I had a network appliance configured to do any sort of nebulous network optimization, I'd start to suspect it any time anything doesn't work Coffee too cold? Teapot protocol should have used QUIC.
karmahunter1234 5y ago
> The issue with UPNP is not that it's misunderstood. The issue is that somebody implementing it has to pay hundreds of bucks to read the ISO. I think you can get the specs here: https://openconnectivity.org/developer/specifications/upnp-resources/upnp/ https://openconnectivity.org/developer/specifications/upnp-r... > On the other hand printers are working on your smartphones but not on your Linux desktop. I don't think this has anything to do with upnp? Most printers nowadays also support IPP (thanks to apple's cups push?), so ..
franga2000 5y ago
> On the other hand printers are working on your smartphones but not on your Linux desktop. Ever thought why that is? That's not the case though. The only issues I've had were: 1. missing drivers (a universal issue), 2. changed IP after initial config (because the configurator save the IP and not hostname - I've seen this happen on Windows too, 3. incomplete drivers (because the printer doesn't fully adhere to the standards and vendor drivers aren't complete/available) So what do printers have to do with any of this?
- cookiengineer 5y ago
  > So what do printers have to do with any of this? The original post was about zeroconf, and therefore the later multicast DNS-SD based discovery protocol [1]. Namely aireplay, airport, airprint, airscan based protocols that multicast their functionality and protocols via DNS to the 224.0.0.251 or [ff02::fb] addresses on port 5353. Printers these days do have primarily support for airprint + airscan so they work out of the box on MacOS with all the GUIs that the OS has to offer. Not so much for WSD or other protocols that Linux/Windows still need. CUPS or postscript support usually isn't complete for anything else than TIFF, because nobody seems to give a damn about implementing a PDF rasterizer on-device, let alone gutenprint or postscript/ghostscript support for their scanner devices. Reading through the sibling comments you have to recognize that my interpretation of "what is working" is a different one than a developer's perspective. If someone without programming/linux configuration knowledge cannot print or scan via WiFi, your tool is pretty much useless and didn't replace the 100 fragmented alternatives that existed before it already. My complaints were mostly about avahi's integrated discovery tools like avahi-browse and avahi-discover which are only tools to discover printers, but are themselves useless for printing or scanning on their own (and they're not transport-level libraries for DNS-SD IANA registered protocols either). Literally the only scanning tool that works in the Linux world is "simple-scan" [2], which requires preinstalled "sane-airscan" and an integrated avahi-daemon in the resolv.conf/nsswitch.conf. Don't ask about parallel IPv4 + IPv6 support, because that's totally unsupported and will crash in multiple NAT scenarios the daemon in an endless loop, and is the reason why every Linux wiki will recommend to add "mdns4_minimal" to the /etc/nsswitch.conf file instead of "mdns_minimal". [3] Coming back to my point: I mean, every developer can send a postscript file via bash to an IPP port, but I wouldn't call it a working UX or UI. When comparing the aforementioned shitshow with how everything is nicely working on MacOS, Linux is basically a bad joke when it comes to mDNS support. I mean, the technology is almost 15 years old now, and we still can't have nice printer support on Linux. Using Apple's CUPS as an excuse to say we support printers is a 20 years old excuse. And a deprecated one, btw, because PPD support has been deprecated for years now ... so good luck getting a new printer that works with that. Nonetheless fixing my printer on Linux and debugging what all this stuff is for days inspired me to build a Web Browser that uses mDNS for local peer discovery, so at least something good came out of it. [1] http://www.dns-sd.org/ http://www.dns-sd.org/ [2] https://gitlab.gnome.org/GNOME/simple-scan https://gitlab.gnome.org/GNOME/simple-scan [3] e.g. https://wiki.archlinux.org/title/avahi https://wiki.archlinux.org/title/avahi
vetinari 5y ago
> It's such a hardcore fail when considering that the goal for zerconf and DNS-SD was to ease things up, and on Linux it made things worse because of config fatigue What distribution are you using? On those desktop oriented ones, it works out of the box.
- michaelt 5y ago
  Zeroconf on Linux works so well I get to see my printer three times - advertised in Windows format and Mac format; and by IP and mDNS hostname.
  - vetinari 5y ago
    You probably have several discovery protocols enabled on the printer, and your computer dutifully shows each one. I see two scanners for the same reason - one via WSD, one through AirScan.
- tomxor 5y ago
  Yeah i'm not getting the parent either, on Debian you just install the avahi package and it's done. Maybe other distros are more complicated.
jcrawfordor 5y ago
I addressed this in another comment, but as a short thought on the ISO issue - DLNA itself was never adopted by ISO, but UPnP A/V on which it's based was. ISO really wasn't an issue here, though, as the actual DLNA specifications (and the UPnP specifications they incorporated) were maintained and distributed by the DLNA incorporation itself. This is very common for these types of standards (general standards bodies tend to not even be interested in them until there is a decent degree of industry momentum, which you have to get by putting together an implementers group), and I mentioned USB as another prominent example, it's standardized by USB-IF, not IEC, even though each major revision is submitted to IEC after USB-IF adopts it as basically a rubber-stamp exercise. All of that said, DLNA Inc. provided the specs only to members. I do not know what membership cost, but I suspect it was well more than ISO charges for standards copies. I have no doubt this was a hindrance to DLNA acceptance in software, as it would have blocked out a lot of small and open-source efforts. For hardware vendors, having to pay hefty membership dues to an implementer's group to get access to standards is par for the course and how about half of the hardware interconnect standards work, and I don't think it caused much hesitation there. This might help explain why, for a period of 5+ years, embedded DLNA clients were pretty standard in HD-DVD and Blu-Ray players but there were surprisingly few software options. It's no doubt also a factor that the major promoters of both HD-DVD and Blu-Ray themselves were also members of DLNA and may have incentivized their licensees to implement it.

oshiar53-0 5y ago

I wonder how I can finally make it work on a Linux desktop

forty 5y ago

I'm under the impression that mDNS / DNS-SD worked out of the box on Ubuntu at least, for printers (I'm not sure, maybe installing avahi manually is needed if it's not there by default, but I wouldn't call that "a lot of manual configuration")

jcrawfordor 5y ago
Avahi often seems like a mixed bag. Sometimes it Just Works, but other times it doesn't---one of the big pain points of zero-configuration systems has always been opacity and difficult troubleshooting. For example, it's not at all unusual for well-meaning consumer network appliances to monitor and interfere with IGMP ("IGMP snooping"), ostensibly for performance reasons, but then unintentionally break mDNS. It can be very hard to figure out that that's what's happening when your printer just isn't showing up. In general distributed systems tend to be a pain to troubleshoot, but especially so the zero-configuration efforts since they often try excessively hard to be completely invisible.
- tux3 5y ago
  If I had a network appliance configured to do any sort of nebulous network optimization, I'd start to suspect it any time anything doesn't work Coffee too cold? Teapot protocol should have used QUIC.

karmahunter1234 5y ago

> The issue with UPNP is not that it's misunderstood. The issue is that somebody implementing it has to pay hundreds of bucks to read the ISO. I think you can get the specs here: https://openconnectivity.org/developer/specifications/upnp-resources/upnp/ https://openconnectivity.org/developer/specifications/upnp-r... > On the other hand printers are working on your smartphones but not on your Linux desktop. I don't think this has anything to do with upnp? Most printers nowadays also support IPP (thanks to apple's cups push?), so ..

franga2000 5y ago

> On the other hand printers are working on your smartphones but not on your Linux desktop. Ever thought why that is? That's not the case though. The only issues I've had were: 1. missing drivers (a universal issue), 2. changed IP after initial config (because the configurator save the IP and not hostname - I've seen this happen on Windows too, 3. incomplete drivers (because the printer doesn't fully adhere to the standards and vendor drivers aren't complete/available) So what do printers have to do with any of this?

cookiengineer 5y ago
> So what do printers have to do with any of this? The original post was about zeroconf, and therefore the later multicast DNS-SD based discovery protocol [1]. Namely aireplay, airport, airprint, airscan based protocols that multicast their functionality and protocols via DNS to the 224.0.0.251 or [ff02::fb] addresses on port 5353. Printers these days do have primarily support for airprint + airscan so they work out of the box on MacOS with all the GUIs that the OS has to offer. Not so much for WSD or other protocols that Linux/Windows still need. CUPS or postscript support usually isn't complete for anything else than TIFF, because nobody seems to give a damn about implementing a PDF rasterizer on-device, let alone gutenprint or postscript/ghostscript support for their scanner devices. Reading through the sibling comments you have to recognize that my interpretation of "what is working" is a different one than a developer's perspective. If someone without programming/linux configuration knowledge cannot print or scan via WiFi, your tool is pretty much useless and didn't replace the 100 fragmented alternatives that existed before it already. My complaints were mostly about avahi's integrated discovery tools like avahi-browse and avahi-discover which are only tools to discover printers, but are themselves useless for printing or scanning on their own (and they're not transport-level libraries for DNS-SD IANA registered protocols either). Literally the only scanning tool that works in the Linux world is "simple-scan" [2], which requires preinstalled "sane-airscan" and an integrated avahi-daemon in the resolv.conf/nsswitch.conf. Don't ask about parallel IPv4 + IPv6 support, because that's totally unsupported and will crash in multiple NAT scenarios the daemon in an endless loop, and is the reason why every Linux wiki will recommend to add "mdns4_minimal" to the /etc/nsswitch.conf file instead of "mdns_minimal". [3] Coming back to my point: I mean, every developer can send a postscript file via bash to an IPP port, but I wouldn't call it a working UX or UI. When comparing the aforementioned shitshow with how everything is nicely working on MacOS, Linux is basically a bad joke when it comes to mDNS support. I mean, the technology is almost 15 years old now, and we still can't have nice printer support on Linux. Using Apple's CUPS as an excuse to say we support printers is a 20 years old excuse. And a deprecated one, btw, because PPD support has been deprecated for years now ... so good luck getting a new printer that works with that. Nonetheless fixing my printer on Linux and debugging what all this stuff is for days inspired me to build a Web Browser that uses mDNS for local peer discovery, so at least something good came out of it. [1] http://www.dns-sd.org/ http://www.dns-sd.org/ [2] https://gitlab.gnome.org/GNOME/simple-scan https://gitlab.gnome.org/GNOME/simple-scan [3] e.g. https://wiki.archlinux.org/title/avahi https://wiki.archlinux.org/title/avahi

vetinari 5y ago

> It's such a hardcore fail when considering that the goal for zerconf and DNS-SD was to ease things up, and on Linux it made things worse because of config fatigue What distribution are you using? On those desktop oriented ones, it works out of the box.

michaelt 5y ago
Zeroconf on Linux works so well I get to see my printer three times - advertised in Windows format and Mac format; and by IP and mDNS hostname.
- vetinari 5y ago
  You probably have several discovery protocols enabled on the printer, and your computer dutifully shows each one. I see two scanners for the same reason - one via WSD, one through AirScan.
tomxor 5y ago
Yeah i'm not getting the parent either, on Debian you just install the avahi package and it's done. Maybe other distros are more complicated.

jcrawfordor 5y ago

I addressed this in another comment, but as a short thought on the ISO issue - DLNA itself was never adopted by ISO, but UPnP A/V on which it's based was. ISO really wasn't an issue here, though, as the actual DLNA specifications (and the UPnP specifications they incorporated) were maintained and distributed by the DLNA incorporation itself. This is very common for these types of standards (general standards bodies tend to not even be interested in them until there is a decent degree of industry momentum, which you have to get by putting together an implementers group), and I mentioned USB as another prominent example, it's standardized by USB-IF, not IEC, even though each major revision is submitted to IEC after USB-IF adopts it as basically a rubber-stamp exercise. All of that said, DLNA Inc. provided the specs only to members. I do not know what membership cost, but I suspect it was well more than ISO charges for standards copies. I have no doubt this was a hindrance to DLNA acceptance in software, as it would have blocked out a lot of small and open-source efforts. For hardware vendors, having to pay hefty membership dues to an implementer's group to get access to standards is par for the course and how about half of the hardware interconnect standards work, and I don't think it caused much hesitation there. This might help explain why, for a period of 5+ years, embedded DLNA clients were pretty standard in HD-DVD and Blu-Ray players but there were surprisingly few software options. It's no doubt also a factor that the major promoters of both HD-DVD and Blu-Ray themselves were also members of DLNA and may have incentivized their licensees to implement it.