Closed markosjal closed 3 years ago
Just to clarify, making an eSCL client seems easy enough, but when emulating a scanner or making a scan server (as this project does) you need to keep many different flavors of clients happy . If I can keep Mopria and Apple happy that tells me I probably have done pretty well as the rest is reverse engineered as far as I can tell.
You might use the SANE test backend in conjunction with AirSane and observe the traffic when scanning from a real or virtualized macOS machine.
Thanks,
I think I am past that at this point . I used the Mopria Android Client.
Trying now to figure out how to generate a response to the GET CHUNKED request made by Mopria from Apache / PHP.
You may respond with a normal (not chunked) response.
Not able to get the Mopria client to recognize it at all. I have tried many things, headers , etc.
Wireshark traces:
Frame 1093: 209 bytes on wire (1672 bits), 209 bytes captured (1672 bits) on interface \Device\NPF_{9AF84BC1-E1F6-4A31-BC25-33964BBB83EC}, id 0 Ethernet II, Src: Motorola_18:69:75 (84:b8:b8:18:69:75), Dst: IntelCor_f8:a5:5c (a4:34:d9:f8:a5:5c) Internet Protocol Version 4, Src: 192.168.0.150, Dst: 192.168.0.99 Transmission Control Protocol, Src Port: 35138, Dst Port: 8000, Seq: 14994, Ack: 122074, Len: 155 Hypertext Transfer Protocol GET /eSCL/ScanJobs/NextDocument HTTP/1.1\r\n TE: chunked\r\n Host: 192.168.0.99:8000\r\n Connection: Keep-Alive\r\n Accept-Encoding: gzip\r\n User-Agent: okhttp/4.9.1\r\n \r\n [Full request URI: http://192.168.0.99:8000/eSCL/ScanJobs/NextDocument] [HTTP request 98/101] [Prev request in frame: 1091] [Response in frame: 1094] [Next request in frame: 1095]
`Frame 1094: 1319 bytes on wire (10552 bits), 1319 bytes captured (10552 bits) on interface \Device\NPF_{9AF84BC1-E1F6-4A31-BC25-33964BBB83EC}, id 0 Ethernet II, Src: IntelCor_f8:a5:5c (a4:34:d9:f8:a5:5c), Dst: Motorola_18:69:75 (84:b8:b8:18:69:75) Internet Protocol Version 4, Src: 192.168.0.99, Dst: 192.168.0.150 Transmission Control Protocol, Src Port: 8000, Dst Port: 35138, Seq: 122074, Ack: 15149, Len: 1265 Hypertext Transfer Protocol HTTP/1.1 200 OK\r\n Date: Tue, 13 Jul 2021 11:12:43 GMT\r\n Server: Apache/2.4.48 (Win64) OpenSSL/1.1.1k PHP/8.0.8\r\n Content-Length: 1038\r\n Keep-Alive: timeout=5, max=3\r\n Connection: Keep-Alive\r\n Content-Type: text/html;charset=UTF-8\r\n \r\n [HTTP response 98/101] [Time since request: 0.005202000 seconds] [Prev request in frame: 1091] [Prev response in frame: 1092] [Request in frame: 1093] [Next request in frame: 1095] [Next response in frame: 1096] [Request URI: http://192.168.0.99:8000/eSCL/ScanJobs/NextDocument] File Data: 1038 bytes Line-based text data: text/html (16 lines) <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">\n
\n \nName | Last modified | Size | Description | |
---|---|---|---|---|
Parent Directory | - | |||
index.php | 2021-07-13 00:43 | 1.0K | ||
Your response contains HTML instead of JPEG data?
Probably just another one of the MANY things I have tried.
Looks like that particular capture may have had a different problem though! sorry about that , too many captures to track.
Here is passing raw jpg data with php's readfile(), no headers no nothing added just the raw jpg (see attached wireshark capture) . If I could get past this I would have a great solution however on my last eSCL project this is the same place I got hung up before. It worked with some clients but not with Apple nor Mopria.
Note I am not using eSCL Ver2.6 so no UUIDs in the URLs . It complicates the trailing slash issue with random URLs, at least for now I stick with 2.5. GoodScanFailedTransfer.zip
You should set the Content-Type header to image/jpeg if you are sending JPEG data.
As Stated , I have made MANY modifications to this including that being set.
Sure would be nice to see a trace of a working scan because I am weeks into it now and no image back to Mopria Android.
Of course some apps and back-ends are not sending or specifically looking for chunked data . They will work with anything they can understand, including just an un-chunked jpg
Have you tested yours with Mopria Android?
I've tested both with Apple image Capture and Mopria Android. Both are working. You may record communication between Mopria Android and AirSane in order to get a trace of a working scan.
I would need a working Linux scanner for that!
You may use the SANE test backend. Enable it in /etc/sane.d/dll.conf
.
Yea, but that test backend has given me some problems in the past with testing Found an old Canon LIDE 200 that made "not so great" images but otherwise "works". Linux compatible and a quick install of your stuff on a fresh Linux Mint install and I must compliment you on the great documentation. Even the bug was easy to work - around because of the great docs.
Made a successful scan and capture from Mopria Android. But also tested from OSX 10.14 the preview app seems to work but the imaging app seemed to repeat the scan, over and over. That indicates to me that what you use is likely somehow imperfect, but not judging just stating what I see . It is way better than what I have in any case.
I now have something more to go on.
What I am working on would be a solution much like this one ,but for a Windows scanner
Thanks
Good luck then.
not an issue however building a similar solution for Windows TWAIN scanner in php, and wanting to upgrade older scanning application. . having issues with understanding nuances in communication. I have the Mopria spec but it is unclear in many ways.
Do you have packet sniffs of actual successful scans?
Any other advice?