Description of problem: Xsane, Simple-scan, Skanlite and gscan2pdf fail detecting network scanner. Before upgrading to F28 everything worked just fine. Version-Release number of selected component (if applicable): How reproducible: Every time I try to scan with either app. Steps to Reproduce: 1.Launch the app. 2.Ask the app to detect networking scanner. 3.The app reports no scanner found or crash altogether. Actual results: No scanner detected. Expected results: Scanner detected in the same way as Fedora 27 and predecessors did. Additional info: The scanner is a Brother MFC-8890DW, used via network. I upgraded my desktop from F27 to F28 beta and found this issue. I verified connections and everything seems OK. I can print with it and access it via the web browser. I verified specific brother drivers and they were installed, as well as sane-backends, sane-backends-drivers-cameras, sane-backends-drivers-scanners, sane-backends-libs and sane-frontends. I ran command "brsaneconfig3 -a name=SCANNER model=MFC-8890DW ip=192.168.1.106" as usual, and then command "brsaneconfig3 -q | grep SCANNER", which showed the scanner was duly detected: "0 SCANNER "MFC-8890DW" I:192.168.1.106". This is not an upgrade issue, since I found similar results in my Lenovo laptop running F28 installed from scratch. Not sure which component to put my finger on, I choose xsane but it might be something else.
I have encountered the same problem with a Brother HL-2280DW connected by network, which worked fine in F27. The Brother utility brsaneconfig4 shows that the device is online, and I can print to the device. However, no scanning programs are able to detect the device. I have reproduced the problem on an Acer C740 and a Lenovo Thinkpad Yoga 260 (both upgraded to F28 Beta XFCE from F27 XFCE).
Hi everyone, thank you for reporting this issues, but: 1) If the issue isn't only in xsane, please do not file a bug on xsane, but on sane-backends, which provides scanning for Linux. 2) Brother printers needs proprietary software from Brother and sane-backends is the same version as on F27, so there can be error in 3rd party software. Can you run 'SANE_DEBUG_DLL=255 SANE_DEBUG_SANEI_TCP=255 scanimage -L &> scanimage.debug' if device is discovered and attach gathered output here.
Hi. I just ran 'SANE_DEBUG_DLL=255 SANE_DEBUG_SANEI_TCP=255 scanimage -L &> scanimage.debug' twice, with no result.
What about checking if scanimage.debug file is created and attaching it? There shouldn't be any output on terminal, all messages go to the file.
Created attachment 1420125 [details] scanimage.debug file obtained after running 'SANE_DEBUG_DLL=255 SANE_DEBUG_SANEI_TCP=255 scanimage -L &> scanimage.debug' Hello, I've run the command as requested; I've attached the debug file. Hope this helps.
[dll] load: searching backend `brother4' in `/usr/lib64/sane' [dll] load: trying to load `/usr/lib64/sane/libsane-brother4.so.1' [dll] load: dlopen()ing `/usr/lib64/sane/libsane-brother4.so.1' [dll] load: dlopen() failed (libnsl.so.1: cannot open shared object file: No such file or directory) There was a change in F28 that libnsl isn't shipped by glibc anymore, but by separate package libnsl. Please try to download and install the newest package from Brother, try to run command from comment#2, check debug log for messages copied above. Then: A) If such lines will not be there anymore and scanner cannot be discovered, reopen this issue. B) If there will be still such lines, please report this issue on Brother support - they need to rebuild their package with Requires: libnsl, if they want to have libnsl.so.1 shared library. (for libnsl.so.2 they need Requires: libnsl2) Closing this as WONTFIX for now.
I checked my scanimage.debug file, which shows the same error as Alvin's. Also verified I have the latest drivers from Brother, which were last updated in April 2015. I'm a little busy right now but will try to contact Brother support this week.
I was lucky enough to find Brother support quickly and reported the issue, with number 180411-000171.
I found a solution. Checking in dnfdragora, I noticed the library installed on my desktop is libnsl2. I also found as not installed libnsl, described as providing "the legacy version of libnsl library, for accessing NIS services. This library is provided for backwards compatibility only; applications should use libnsl2 instead to gain IPv6 support." I installed libnsl and the scanner now works as expected. Don't know if this could be considered a permanent solution or just a temporary fix.
(In reply to Boricua from comment #9) > I installed libnsl and the scanner now works as expected. Don't know if this > could be considered a permanent solution or just a temporary fix. I'm sorry, but IMHO this isn't permanent solution - if you consider other users of Brother scanners, then they have to install libnsl manually (and they need to know that they need to do it) when they install Brother 3rd party drivers to get scanner working... the fact that libnsl needs to be installed for running driver needs to be mentioned in spec file of rpm, which Brother ships. Not mentioning that libnsl can be removed from Fedora, because it is old, and only libnsl2 will be available, then even requiring libnsl will not help and driver will need to be ported to libnsl2... The best course of action for Brother support is to port driver to use libnsl2 and requiring it in spec file. If that's not possible, other solution (kind of temporary, but better for users than manually installing it) is requiring libnsl in spec file.
Agreed. I'm still dealing with getting a respond from Brother support, make them aware of this bug report and ask for a permanent fix. Meanwhile, this temporary fix is critical for me, in order to upgrade all my desktops and laptop to F28.
Hi! Boricua, have you had any answer from Brother support? I had the same problem on all our computers after update to Fedora 28. I confirm that installing libnsl then reinstalling the Brother drivers (somehow just reinstalling was not enough) worked around the problem. Now my network scanner (Brother MFC-J6920DW) work again. But I'd be interested by a long term solution. As Zdenek notes, this is a library with "Legacy" in the summary. I fear that it will disappear some day and that our Brother scanner won't work anymore with Fedora (or at least not easily).
Hi, Jehan. I share your concern, since I have two Brother network scanners. I filed a linux driver update request with Brother on April 11 2018. The next day a representative acknowledged my petition and let me know it was forwarded to their engineer group. Nothing else from them yet. My report is #180411-000171, in case you wish to file one. I guess we will need to add numbers in order to expedite this matter before libnsl is no more. As soon as I get any response from Brother I will post it here.
Guys, I just installed the libnsl package and redownloaded their driver brsane4 which has been actually updated in 2018 (brscan4-0.4.5-1.x86_64.rpm). Both installed fine and no scriplet errors, but yet simple-scan won't see my scanner. In the scanimage debug output, I don't see any "brother" line, it looks like in my case Brother driver is not properly registered. Perhaps another bug in their install scripts?
For googlers - there is another problem in their scriplets. Here is how to fix this: First, I am going to use simple scan utility, it also needs a dependency package which somehow is not correctly listed in Fedora 28, so install these two guys: dnf -y install libnsl simple-scan Then download brscan4 and brscan-skey RPM packages from [Brother site](http://support.brother.com/g/s/id/linux/en/download_scn.html) and install both. For scanning you only need brscan4 actually, but I installed both. Some tutorials also guides you to install package named `brother-udev-rule-type1-1.0.0-1.noarch.rpm` but you won't need it as it was merged into `brscan4` package. Brother RPM packages are known to have lame scripting, their scripts usually don't work in different environments. After installation check that the following file exist: `/etc/udev/rules.d/50-brother-brscan4-libsane-type1.rules` and if not fix the installation script `/opt/brother/scanner/brscan4/udev_config.sh`. Also check that the file `/etc/sane.d/dll.conf` contains `brscan4` line, if not add it or fix their script `/opt/brother/scanner/brscan4/setupSaneScan4`: echo brother4 >> /etc/sane.d/dll.conf This was not working in my Fedora 28 in package `brscan4-0.4.5-1.x86_64.rpm` at all. Then visit printer's built-in web interface and configure it for static IP. You can do the same on your DHCP server if you prefer to. And then - aaarghhh - the hidden trick which caused me the headache: $ brsaneconfig4 -a name=PRACOVNA model=MFC-L2700DW ip=192.168.1.111 And done! Switch over to "Brother *PRACOVNA" scanner and you can scan over IP. I use "simple-scan" which is quick and nice tool that aims for easy scanning into PDF with multiple pages support. Highly recommended. Actually I haven't configured printing because I use Google Cloud Print which is built in the device. Frankly, I tried but it did not work. https://lukas.zapletalovi.com/2016/07/brother-mfc-l27000dw-and-fedora-23.html
Hi Lukas, thank you for sharing your how-to! Would you mind if I use it for creating a small how-to for Brother scanners in sane-backends?
Absolutely, my blog is CC-licensed anyway but check the spelling :) Just to expand on this, it my case (F28 with brscan4-0.4.5-1.x86_64.rpm) the udev rule was properly created but dll.conf was left untouched (the script just creates dll.conf.tmp and exits with non-zero). They probably want to capture all RPM-based distros but it's poor shell scripting on all levels anyway. Second, I gigured out that brscan-skey is just some scan-to-email utility which does not work anyway, I suggest not to recommend installation in your HOWTO. Not sure why I failed configuring printing, I did not bother as I tend to use GCP which always work for me. It's lame but I rarely print.
*** Bug 1600811 has been marked as a duplicate of this bug. ***
For the record, I also reported to Brother (before I found this report actually). And they sent me later the exact solution of installing libnsl (so they obviously knew about this problem). Then I asked them if they had plans to fix their drivers (it should install libnsl as a dependency!) and more if they were planning to update it by using libnsl2 considering the "Legacy" tagging which means it may disappear soon from repositories. They said they would forward to their dev team, which is as far as we can go, I guess. Hopefully it really reached the devs and they already had plans to update (or will now).
Thank you for the update, Jehan!