Messages

I've moved the topic so that you might get better visibility to people who can help you.

I am about to post slightly modified versions of these packages, which may address your problem.

I have no experience sharing with a Windows computer, so I don't know what the solution might be.  You could try the latest driver (1.00.21), which I am about to post - but it may not be a Samsung driver issue.

I am about to post a new driver version, you could try that (driver2-1.00.21).

As a temporary fix, I will add both names as resolving this dependency to the latest release of this package.  Hopefully it won't cause additional problems for those using the newer library.

Thanks for sharing the solution.  I will add this as a possible solution for network issues.

Have you tried the 3.00.65 driver from the repository?

Otherwise, you don't need the repository if the direct install works for the server.

I agree that this is strange.  However, what exactly is the problem you are having as a result of sane-find-scanner not finding the scanner, if the other tools work?

I am not aware of any issues related to Ubuntu 14.04, so you should not need to take any action.

I think this is the same as the M2825 series, which means the M262x driver series should work.

No diagnostics that I am aware of.  I run into this problem as well (and only with my Samsung printer, not with various others), often with Impress but occasionally elsewhere.  I've had reasonable success by exporting to a PDF and then printing that.  I'm not sure where the problem is or why that sometimes help.  It may be a file size/complexity issue - I have some small amount of image compression set for the PDF export.

And sometimes I just end up printing 1 page at a time.

As far as I know, there are not any environment variables that you can set.  The only thought I have would be to try setting the wireless network to a higher IP range than the wired (e.g., 192.168.2.x) - perhaps the issue is that libsane-smfp always uses the lowest?

Alternatively, try an older driver and see if it behaves better.

Are you using system-config-printer or some other interface?  (If you aren't sure, try running system-config-printer from the terminal.)  If it is system-config-printer, then you may need to skip any auto-detect routines (try it with the printer off) and manually select Samsung and then the driver.

If it isn't system-config-printer, try installing and using that.

Thanks.  Now that I'm looking at this, I think actually the whole inner "if" is unnecessary.  I will put out a patched version in a few days.

Thanks for sharing.  I added this as a possible solution.

I don't know what is causing this problem.  My best guess is something in the current version of libsane (sane-backends) that is shipping with 13.10 and 14.04.  There are two other similar threads going in these forums right now about this, but I can't see much in common except a version of libsane that has a couple of extra patches not applied in previous releases or in the Debian series of packages.  My best suggestion now is to file a bug report with Ubuntu against the package, although honestly I wouldn't expect much of a response.

Sorry I can't be more help.

I don't know what is causing this problem.  My best guess is something in the current versions of libsane (sane in Arch) that are shipping with the latest Ubuntu and Arch releases.  There are two other similar threads going in these forums right now about this, but I can't see much in common except a version of libsane that has a couple of extra patches not applied in previous releases or in the Debian series of packages (in Arch, actually a whole new release compared to Debian).  My best suggestion now is to file a bug report with Arch against the package, although honestly I wouldn't expect much of a response.

Sorry I can't be more help.

I don't know what is causing this problem.  My best guess is something in the current version of libsane (sane-backends) that is shipping with 13.10 and 14.04.  There are two other similar threads going in these forums right now about this, but I can't see much in common except a version of libsane that has a couple of extra patches not applied in previous releases or in the Debian series of packages.  My best suggestion now is to file a bug report with Ubuntu against the package, although honestly I wouldn't expect much of a response.

Sorry I can't be more help.

What is the output of "/opt/Samsung/mfp/bin/netdiscovery --all --scanner"?

Are you running Ubuntu 13.10 (Saucy)?  It appears that several other people are having similar problems, and the only common feature I can see so far is the Ubuntu version.

I try this with normal user and root
I also tried old drivers, but with these drivers my scanner is not found.
Any ideas?

It appears that some network signals for the scanner are going through but not others.  Are you running a firewall that could be interfering with something?  Alternatively, is there anything unusual about your network configuration?

TotallyKing or Angelnu, any comments regarding this topic?
http://www.bchemnet.com/suldr/forum/index.php?topic=181.0

The file paths are incorrect.  I suspect that your repository configuration has been corrupted.  Try removing the repository, and then adding it again as a new one.

Are you able to print any actual documents?  It's possible that the Self Test page has a set of instructions that the printer doesn't like, but that aren't relevant for documents.

If it is via some network auto detection, that implies (I suspect) configuration of other services to that end, such avahi or equivalent.
If I'm on the right track, can you clarify which mechanisms suld uses to find the scanner address?

It uses its own utility, either /opt/Samsung/mfp/bin/netdiscovery or /usr/lib/cups/backend/smfpnetdiscovery depending on the version of the driver.  Basically it seems to run a UDP scan of some sort (I've never looked into it much detail).  For it to work, the only thing you need to do is ensure is that your firewall allows UDP replies from the printer IP address (which is standard behavior).

That said, because it is a custom utility, there certainly have been times it hasn't worked correctly.  I don't know how it gets triggered, but the idea is that you shouldn't need to manually modify any files.

Thus far I had used the expression "specify a backend" to mean that I've added the "tcp..." line to a specific file under /etc/sane.d. So I've specified the xmfp_mfp backend only in the sense that it is at the end of /etc/sane.d/xmfp_mfp.conf my "tcp..." line. Where should I put it instead not to specify a backend, and trying that way to have the suld backend picked up?

In theory, the suld driver should be able to work with the scanner without modifying anything.  So simply remove anything you have added to the .conf file.

Of course, the result may also be that the scanner isn't detected by SANE at all.

Are there other backends that I could/should use? I went for the xerox-mfp because that's what I've seen mentioned on the suld website and in other replies on this forum. In fact, I wasn't entirely sure about whether which one I should use between xerox-mfp and xerox-mfp_smfp... If there are alternatives I should try, I'm all ears! :)

xerox-mfp_smfp is not a real backend, it still refers to xerox-mfp.  The only other thing to try is to not specify a backend at all and see if it picks up the suld backend (which can't be forced, because it isn't a SANE component).

I'll give newer sane versions a try. Still, it seems to me that there is arguably a bug *also* in the scanner firmware. It is definitely inappropriate for it to reboot, no matter what the client is telling it over the network.

Agreed.  If you can't get it work without xerox-mfp or with a newer SANE, it's probably also worth contacting Samsung (or perhaps even if you do get it work).

First of all xsane (but in general everything sane-related, it seems) takes a lot to scan for devices, about 35 seconds before showing the device dialog. It's not clear to me if that is normal or not. Any takers? If it is "normal", is there a way to avoid the device scanning and reuse the results from the last run? I'd be particularly cool if that could be done even when xsane is invoked by other applications, and most notably gimp.

This seems to depend on what hardware you have present.  For example, the device scan time on my computer went up substantially after I added a TV tuner card.  I have no idea why, presumably sane is testing hardware that it thinks might be responsive.  I know you can set the environment variable SANE_DEFAULT_DEVICE to designate a particular default device, but I don't think that actually prevents sane from searching for devices every time xsane starts.

It looks like a bug in the scanner firmware, but it's probably one which is caused by xsane and/or the suld driver (because otherwise there will be way more people than me complaining about this over the net... :)).

Any idea about how to fix / work around this?

Since it seems to be using the xerox-mfp backend, I would guess that's where the problem lies, not the Samsung driver.  There is a newer version of sane available (1.24 and 1.25 in development) than is currently in the Debian repositories, you could try installing that and see if it resolves the problem.  Otherwise I would suggest filing a bug report with the SANE project, and/or searching their reports for something similar that may provide a clue to a work-around.

From your description, I doubt that this is due to the Samsung drivers.  If there has been an update to sane recently, that might be it.  Or it could be hardware?

Sorry I can't give any specific help.

Printing is working under Linux. Later I'll see how well it is working. Do you mean that I could try the qt based configurator programs to get wireless working under Linux?

No, the Configurator won't work with that driver.  I was thinking of the "Printer Setting Utility" available for some models.  For example:
http://www.samsung.com/us/support/owners/product/ML-2165W/XAC

I don't know how general the utility is or if it is localized, but some printers seem to require it to configure the wireless.