attah / harbour-seaprint

🐟🖨 Network printing for Sailfish OS
GNU General Public License v3.0
16 stars 20 forks source link

Discovery issues #11

Closed attah closed 3 years ago

attah commented 4 years ago

Some users are reporting discovery issues. It may be a fault in how the dereferencing of DNS records is done, but it could be just about anything too. If you are experiencing this, please post here.

To get the relevant logs from SeaPrint, start it from terminal, harbour-seaprint, and look for anything starting with IppDiscovery::, especially IppDiscovery::readPendingDatagrams.

If you have Wireshark and are able to look at the traffic between the phone and your printer, use a filter like this: udp.srcport == 5353 || udp.dstport == 5353 to catch mdns traffic.

adelnoureddine commented 4 years ago

Hi attah, here is the log when trying to connect to a Brother DCP-L2520DW printer over WiFi. Tried both automatic discovery and adding by URL. Android Brother's app detects the printer with no issues.

attah commented 4 years ago

Hi @adelnoureddine, Thanks for the log. It seems tat your printer (or rather printer server box?) is only responding with a pointer, and no other records, like addresses. Not sure if the query should be changed for it not to do this, or of i need to ask about the new address. Maybe it puts the information in the Authority part. However, either of these would be a bit weird. A Wireshark log would be helpful.

I assume you also have issues adding it manually? That appears to stem from that the printer reports an empty name. A bit strange, since i thought the point of it being a required attribute would be that it would contain something. I used the presence of a name to check if the printer was detected, but the code also won't accept an empty name. This part wouldn't be too hard to fix, and i probably will, however it seems your printer doesn't support any of the currently usable formats. It does however support PWG and URF/Apple raster, which are also "driver free", but require client side rendering/conversion.

adelnoureddine commented 4 years ago

Thanks @attah for your reply. My printer can't be discovered automatically or manually (as you guessed from the log). The server box you see in the log is my internet set top box, not the printer. However, I tried to connect my printer to it, and connect seaprint to the box (instead of the printer), and it is discovered. Though, as you said, the app tells me "no relevant formats supported".

attah commented 4 years ago

Hmm, interesting. Then the response makes more sense, as a "look here instead". But the printer should have responded too. Sooner or later i will do something about raster formats, but that is quite a big project, so any help with developing that would be much appreciated.

vigejolla commented 4 years ago

I have shared my printers using CUPS. The printers work fine after adding manually, but automatic discovery does not work. Here are the relevant bits from log: [D] IppDiscovery::discover:73 - discovering [D] onConnectedChanged:23 - conn true [D] getFavourites:47 - satunnetti [] [D] onConnectedChanged:26 - [] [D] IppDiscovery::readPendingDatagrams:163 - ptrs QMap(("_ipp._tcp.local", "Lexmark @ lemonade._ipp._tcp.local")) [D] IppDiscovery::readPendingDatagrams:164 - rps QMap() [D] IppDiscovery::readPendingDatagrams:165 - ports QMap(("Canon MG3100 series @ lemonade._ipp._tcp.local", 631)("Lexmark @ lemonade._ipp._tcp.local", 631)) [D] IppDiscovery::readPendingDatagrams:166 - targets QMap(("Canon MG3100 series @ lemonade._ipp._tcp.local", "lemonade.local")("Lexmark @ lemonade._ipp._tcp.local", "lemonade.local")) [D] IppDiscovery::readPendingDatagrams:167 - AAs QMap(("lemonade.local", "192.168.0.5")) [D] IppDiscovery::readPendingDatagrams:168 - AAAAs QMap() [D] IppDiscovery::readPendingDatagrams:163 - ptrs QMap(("_ipp._tcp.local", "Lexmark E120n._ipp._tcp.local")) [D] IppDiscovery::readPendingDatagrams:164 - rps QMap() [D] IppDiscovery::readPendingDatagrams:165 - ports QMap() [D] IppDiscovery::readPendingDatagrams:166 - targets QMap() [D] IppDiscovery::readPendingDatagrams:167 - AAs QMap() [D] IppDiscovery::readPendingDatagrams:168 - AAAAs QMap() [D] IppDiscovery::readPendingDatagrams:163 - ptrs QMap(("_ipp._tcp.local", "Canon MG3100 series._ipp._tcp.local")) [D] IppDiscovery::readPendingDatagrams:164 - rps QMap() [D] IppDiscovery::readPendingDatagrams:165 - ports QMap() [D] IppDiscovery::readPendingDatagrams:166 - targets QMap() [D] IppDiscovery::readPendingDatagrams:167 - AAs QMap() [D] IppDiscovery::readPendingDatagrams:168 - AAAAs QMap() [D] IppDiscovery::update:79 - () ("192.168.0.5:631/") [D] IppPrinter::refresh:55 - "192.168.0.5:631/" 631 [D] onCountChanged:198 - count 1 [D] onCountChanged:198 - count 1 [W] unknown:158 - file:///usr/share/harbour-seaprint/qml/pages/FirstPage.qml:158: TypeError: Cannot read property 'value' of undefined [W] unknown:13 - file:///usr/share/harbour-seaprint/qml/pages/utils.js:13: TypeError: Cannot read property 'value' of undefined [W] unknown:13 - file:///usr/share/harbour-seaprint/qml/pages/utils.js:13: TypeError: Cannot read property 'value' of undefined [D] IppPrinter::getPrinterAttributesFinished:71 - QNetworkReply::NetworkError(NoError) "Unknown error" "" [D] IppPrinter::getPrinterAttributesFinished:77 - 1030 QJsonObject({"attributes-charset":{"tag":71,"value":"utf-8"},"attributes-natural-language":{"tag":72,"value":"en-us"},"status-message":{"tag":65,"value":"The printer or class does not exist."}}) QJsonObject()

attah commented 4 years ago

Thanks for the log. I see one thing i already know how to fix. But where to get the uri suffixes/paths is a mystery. Your Canon appears to have announced itself too, but just as the first log, no address entry in the response (nor suffix). If you can swing it, a Wireshark log would be very helpful, but i will be able to make one myself (for the CUPS-shared printers) once i convince my CUPS to advertise the printer. It will be another few days before i'm back at a proper computer though.

vigejolla commented 4 years ago

Thanks for the log. I see one thing i already know how to fix. But where to get the uri suffixes/paths is a mystery. Your Canon appears to have announced itself too, but just as the first log, no address entry in the response (nor suffix). If you can swing it, a Wireshark log would be very helpful, but i will be able to make one myself (for the CUPS-shared printers) once i convince my CUPS to advertise the printer. It will be another few days before i'm back at a proper computer though.

Here's a tcpdump log (sorry, too lazy to install wireshark right now):

https://pastebin.com/KuY2eVLU

vigejolla commented 4 years ago

But where to get the uri suffixes/paths is a mystery.

I believe the "rp" key in the TXT records hold the needed information. I also believe that you have to send a separate query for that, using the PTR that was returned for the first query.

attah commented 4 years ago

Yes, that's where i get it already. But the way i read the spec, i thought mdns answers should be "complete", so i didn't add sending further queries. But i guess that makes sense, at least it is consistent with what little knowledge i have about regular dns.

attah commented 4 years ago

fb46694ab8bb87d55aa13abf840e4029eab70586 should take care of at least the CUPS discovery issue, probably the first half of the Brother printer issue too. Do test if you are able and have the time. I won't make a store release just yet, as there are more things i need to fix.

attah commented 4 years ago

51ff40b691d206a72fed3d09cb1c1b05b5f08e7b should take care of the other part of the Brother printer being nameless.

adelnoureddine commented 4 years ago

Fantastic @attah, I compiled your code and now my printer is detected automatically (though no format is supported as above. Thanks for your work, this is great.

piggz commented 4 years ago

Just discovered this app after suggesting printer support in the sailfish meeting ... anyway, it doesnt display the printer. Here is the console output where it clearly sees my printer:

[D] IppDiscovery::sendQuery:97 - discovering 12 ("_ipp", "_tcp", "local") [D] IppDiscovery::readPendingDatagrams:230 - new ipp ptrs ("Canon MG5700 series._ipp._tcp.local") [D] IppDiscovery::readPendingDatagrams:231 - ipp ptrs ("Canon MG5700 series._ipp._tcp.local") [D] IppDiscovery::readPendingDatagrams:232 - rps QMap(("Canon MG5700 series._ipp._tcp.local", "ipp/print")) [D] IppDiscovery::readPendingDatagrams:233 - ports QMap(("Canon MG5700 series._ipp._tcp.local", 631)) [D] IppDiscovery::readPendingDatagrams:234 - targets QMap(("Canon MG5700 series._ipp._tcp.local", "7780F8000000.local")) [D] IppDiscovery::readPendingDatagrams:235 - AAs QMap() [D] IppDiscovery::readPendingDatagrams:236 - AAAAs QMap() [D] IppDiscovery::update:140 - () () [D] onCountChanged:251 - count 0

What else can i do?

attah commented 4 years ago

I see the issue... i take presence of rp+port+target to mean it has successfully found a printer with enough info about it. But with no resolved ip (AA), it will not show up. Other printers have either given all data at once, or no more than a ptr. I'll fix it this weekend, or maybe even tonight.

Given the amount of attention this got at the sailfish meeting, i should perhaps reach out to you guys about helping me get the final parts of raster conversion integrated. I have rolled my own pwg-raster and apple/urf-raster codec, but am having trouble getting it to play nice with Qt... or Qt with it, depending on how you see things.

piggz commented 4 years ago

My fault, i was suggesting printing support would be neat, especially for driverless printers, and it turns out youve done something already!

abranson commented 4 years ago

I got somewhere with this - in my case, I had a hostname in the target string list, but no AA records. If I added that separately to the 'found' list then my printer turned up (though only if I remove the '.local' domain because I have a different LAN domain set up that the printer doesn't seem to include). I have other problems though - printing doesn't seem to work and I have to remove the database between launchers. I'll look into those a bit more and file what I find.

attah commented 4 years ago

@abranson The thing is that the app should ask again, over mDNS, to get some AA records. And as per my last message, the conditions for it to do so are incorrect... .local implies mDNS-only, and may or may not have some similar entry in regular DNS. I don't think this interaction could or should yield any regular DNS hostnames. (But if you have a log to the contrary, i'd be very happy to see it so i can make that work)

For your other problem; i'll be on IRC later today, and during the weekend. Also feel free to register an issue if you like.

attah commented 4 years ago

Seems fixed in 218f74d41ee0edb18e08d72f8ba27ab76fc8bda8

vigejolla commented 4 years ago

These new versions no longer work with my printer. From quick debugging it seems that the printer attributes returned by the printer are empty. Looking at the IPP spec it seems that the interesting attributes should be listed in "requested-attributes" attribute, and seaprint does not, so my printer returns an empty list of attributes, which seaprint seems to interpret as the printer not cabable of printing anything.

attah commented 4 years ago

Hmm, i don't think i changed that though, because i found this pretty early on:

RFC 2911 3.2.5.1 Get-Printer-Attributes Request

"requested-attributes" (1setOf keyword): [...] If the client omits this attribute, the Printer MUST respond as if this attribute had been supplied with a value of 'all'.

So the symptom you are observing is seemingly successful mdns discovery, but it being hidden from the listing none the less?

vigejolla commented 4 years ago

Weird, I'm sure it used to work at some point. Yes, it looks like mdns discovery is successful, but the printer just doesn't have any attributes. I'd like to debug more, but I'm not sure when I have time :(

vigejolla commented 4 years ago

Little more debugging: The printer actually responds with status 0x400, or "client-error-bad-request".

attah commented 4 years ago

Hmm, really strange. Changes in the area look to be 4-5-6 months old at a 2-minute glance. What version did you come from, that worked for you? Any logs and dumps you can provide would be very much appreciated.

I'll compare a super old version and the latest by means of Wireshark at some point.

Did you update printer firmware by any chance? I was thinking maybe the SSL handshake is, well, shaky.

vigejolla commented 4 years ago

I found the bug, you can expect PR shortly :)

lispykid commented 3 years ago

Hi, I am having trouble adding my Brother HL-1250 to Seaprint. It is behind a fritz.box and AVM documentation says to use port 9100. If I add fritz.box:9100/ipp/print it prints a testpage with some information, so I guess the port is correct.. A discovery fails right away. Printing via CUPS from a linux laptop works. But Seaprint won't let me add my manual entries in the URL page. Where to start? The logfile is mostly empty, save for the "discovering _ipp" bit.

attah commented 3 years ago

Hi @lispykid Well, the problem is that port 9100 isn't for IPP, it is only for raw PDL and/or PCL, or completely proprietary formats. (Some select few printers support Postscript and PDF over port 9100, but that's just the super-fancy, but still old, ones) SeaPrint only supports IPP printers, for many reasons. The output you are seeing is the printer simply printing an IPP request. If you still want to use a legacy printer like that one, share it through CUPS, and use that shared instance with SeaPrint.