first off - great job packaging / cleaning that driver-hell. This makes things *much* more enjoyable.
But despite this great work, i still have some problems. Due to the (physical) network architecture in my house i have only one cable running from my server/router to my some place in my cellar where my cable modem and printers are located. I use a vlan-capable switch as a "external network card" on my router/server to seperate all the different networks i have here (2 wifis, one cable network, the cable to my modem). So to attach my new samsung clx-6220, i've created two logical interface on the "physical" (haha) vlan2, which is the vlan that has the port of said cable that runs to my cellar. There i added a (non-vlan-capable) switch. One interface (vlan2) is dhcp to receive a IP from my modem, one (vlan2:0) is static on 192.168.3.1/255.255.255.0 and routes/masquerades to my other networks (mostly 192.168.0.1/255.255.255.0 on vlan3, my cable network). This setup allows me to get around the hassle of getting a new network cable in my wall.
Now, on this strange setup i can't broadcast-ping to my printer, however the windows software (via manual ip/hostname entry) seems to be able to find my printer and is also able to scan. Now i'm trying to get this to work on linux. Printing works of course using cups and a socket:// URI and the samsung supplied PPD-file. As far as i understand, the whole scanning process, be it this Configurator or scanimage on the commandline relies on netdiscovery finding the printer via a broadcast ping to 255.255.255.255 (WTF samsung, WTF...) - correct so far? Now ... i currently don't see any way to get this setup working and i'd really like to refrain from adding another cable as thats a good day work. I'm also not overly good with bridges, but short tests have shown that i can't create a bridge (using brctl) that has only "vlan2:0" as a member, not "vlan2" as a whole. Does anyone have a tip/idea/suggestion for this strange setup?
I'd be really really grateful for any replies ;P. Regards from Germany (also, please excuse my bad english ;P)
If you can (temporarily) hook up a computer directly to the same switch as the printer, then you can use this solution (modified from http://ubuntuforums.org/showthread.php?p=10482031&postcount=656):
On some machine that is in the same network segment with the Samsung (usually by attachment to the same switch, even if only temporarily to obtain the file):
/opt/Samsung/mfp/bin/netdiscovery --all --scanner >netdiscovery.output
On the computer(s) that need to scan when not on the same network segment (all done as sudo/root):
Copy netdiscovery.output to /opt/Samsung/mfp/bin/:
cp netdiscovery.output /opt/Samsung/mfp/bin
Rename the netdiscovery file:
mv /opt/Samsung/mfp/bin/netdiscovery /opt/Samsung/mfp/bin/netdiscovery-org
Create a new /opt/Samsung/mfp/bin/netdiscovery with this as the contents (using any text editor):
if [ -f /opt/Samsung/mfp/bin/netdiscovery.output ]
then cat /opt/Samsung/mfp/bin/netdiscovery.output
Then make the script executable:
chmod 755 /opt/Samsung/mfp/bin/netdiscovery
(Disclaimer: I have modified this from the original, which had some bits that no longer apply to these packages, but I have not tested it.)
It would have be to a computer hooked to the switch that the printer is currently on that you do the first step with; moving the printer temporarily would not work.
If you can't obtain the netdiscovery.output file, I don't think there is any way to deal with this. As you indicated, the broadcast ping is not the best solution (and obviously not what the Windows driver uses).
I've used this workaround on my home network, and it works without a hitch. The only change I would suggest is that, instead of using mv to rename the original binary, you move it with
dpkg-divert --local --rename --divert /opt/Samsung/mfp/bin/netdiscovery-org /opt/Samsung/mfp/bin/netdiscovery
That way any upgrades to samsungmfp-network will overwrite the original binary rather than clobbering the script.
Update: I have a relatively minimal installation with just -common, -driver-##, -data, -network, and -scanner installed. This workaround works flawlessly for me with all components at version 4.00.35-2, but on upgrade, scanimage -L from my computer on the other subnet no longer finds the printer (the failure was both with 4.00.39 across the board, and with the driver at 4.00.35-3 while the other components upgraded to 4.00.39-1). Downgrading everything to 4.00.35-2 restored the workaround's viability.
Edited to add: on further investigation, this looks like this is only partially related to the "different subnets" issue. I just tested on another computer which is connecting to the same router as the printer, and under the 4.00.39 driver, it seems to only be able to find the printer with scanimage after manually running the netdiscovery binary, whereas under 4.00.35 I could find the scanner just by running scanimage twice. It may be that in one of the recent driver updates, Samsung changed the semantics of how the printer gets woken from an idle state.
Have you tried using the 4.00.39 packages, but using the 4.00.35 netdiscovery binary (from the 4.00.35 network package)? The solution depends on whether the problem is restricted just to the netdiscovery module or something in the scanner library files.
Starting from the 4.00.39 packages, replacing just /usr/lib/sane/libsane-smfp.so.1.0.1 with the one from the version driver 4.00.35-2 allowed me to get scanning working the way it had been (scanimage works even from the other subnet with the hardcoded netdiscovery workaround).
Odd. And also an indication that Samsung must be modifying that library without incrementing the version numbers, which complicates things at my end. I'll see what I can do when I have some time.
I had connected to the internal network (with 192.168.** address), but I still cannot see the scanner! I see only printer:
# DEBUG: Network printers discovery utility
ip: 192.168.169.119 slp: 0,0,0,0 snmp: 1,1,0 vendor: Samsung dsc: "SCX-3400 Series"
How can I enable scanner back? I worked... And it works under Windows.