wireless printer

The last step of the installation of my Brother HL-5370DW wireless printer gave an error message:

Will you specify the Device URI? [Y/n] ->Y

0: http
1: https
2: beh
3: smb
4: ipp
5: socket
6: ipps
7: lpd
8: hp
9: parallel:/dev/lp0
10 (I): Specify IP address.
11 (A): Auto. (usb://dev/usblp0)

select the number of destination Device URI. ->4

lpadmin -p HL5370DW -v ipp -E
lpadmin: Bad device-uri “ipp”.
Which URI option do I need and how can I correct it?

Hi mgl

A very similar issue was discussed recently here in this thread

https://forums.opensuse.org/showthread.php/494648-Suse-13-1-Cups-won-t-connect-to-wireless-printer?p=2619592#post2619592

Assuming you have your printer assigned with a static IP address, it is possible to use something like

socket://<printer IP address>

However, the thread discussed the method(s) required to address the printer by its hostname instead.

Refer post #23 of the same thread onwards. Thanks to advice by user kalten, it was possible to consider using SNMP to generate a manual URI with hostname used (rather than IP address). In post #26, I listed some commands that could be run to query the network-attached printer. For example, the ‘snmp’ backend can be called directly with

/usr/lib/cups/backend/snmp <printer hostname>.local

assuming you know the hostname of your printer, or by its IP address.

Let me know if you get stuck.

Yes, I’d like to avoid static IP. The snmp provided this:

 misi@linux-hirq:~> /usr/lib/cups/backend/snmp 192.168.1.63 INFO: Using default SNMP Community public network lpd://BRW5CAC4C807987/BINARY_P1 "Brother HL-5370DW series" "Brother HL-5370DW series" "MFG:Brother;CMD:PJL,PCL,PCLXL,POSTSCRIPT;MDL:HL-5370DW series;CLS:PRINTER;" "" 

After the ipp has failed, how do I pick the lpd option? Do I have to go through the entire installation again? Also, how about the blanks in the printer’s name, as I remember that Unix doesn’t like them. Thanks!

It might be as simple as editing /etc/cups/printers.conf as root so that ‘Device URI’ looks like this

DeviceURI lpd://BRW5CAC4C807987.local/BINARY_P1

Then restart CUPS, and see if you can print.

BTW, as a test, you should get a response from this query too…

/usr/lib/cups/backend/snmp BRW5CAC4C807987.local

I modified deviceURI and I got this:

misi@linux-hirq:/> /usr/lib/cups/backend/snmp BRW5CAC4C807987.local
INFO: Using default SNMP Community public
ERROR: Unable to scan "BRW5CAC4C807987.local"!

For hostname resolution to work, you need to have avahi installed and active.

Check the daemon status

systemctl status avahi-daemon.service

and /etc/nsswitch.conf should contain an entry similar to this

hosts:          files mdns_minimal [NOTFOUND=return] dns

*The mdns_minimal module handles queries for the .local top level domain.

Other than that, I’m not sure what else to advise

This is what I got for the daemon status:


misi@linux-hirq:~> systemctl status avahi-daemon.service
avahi-daemon.service - Avahi mDNS/DNS-SD Stack
   Loaded: loaded (/usr/lib/systemd/system/avahi-daemon.service; enabled)
   Active: active (running) since Mon 2014-02-10 21:41:16 EST; 7min ago
 Main PID: 574 (avahi-daemon)
   Status: "Server startup complete. Host name is linux-hirq.local. Local service cookie is 23286237."
   CGroup: /system.slice/avahi-daemon.service
           └─574 avahi-daemon: running [linux-hirq.local]

… and here is my nsswitch.conf file:

#
# /etc/nsswitch.conf
#
# An example Name Service Switch config file. This file should be
# sorted with the most-used services at the beginning.
#
# The entry '[NOTFOUND=return]' means that the search for an
# entry should stop if the search in the previous entry turned
# up nothing. Note that if the search failed due to some other reason
# (like no NIS server responding) then the search continues with the
# next entry.
#
# Legal entries are:
#
#       compat                  Use compatibility setup
#       nisplus                 Use NIS+ (NIS version 3)
#       nis                     Use NIS (NIS version 2), also called YP
#       dns                     Use DNS (Domain Name Service)
#       files                   Use the local files
#       [NOTFOUND=return]       Stop searching if not found so far
#
# For more information, please read the nsswitch.conf.5 manual page.
#

# passwd: files nis
# shadow: files nis
# group:  files nis

passwd: compat
group:  compat

hosts:          files mdns_minimal [NOTFOUND=return] dns
networks:       files dns

services:       files
protocols:      files
rpc:            files
ethers:         files
netmasks:       files
netgroup:       files nis
publickey:      files

bootparams:     files
automount:      files nis
aliases:        files

I’m not quite sure what is failing here. With your printer online, report the output from

CUPS_DEBUG_LEVEL=3 /usr/lib/cups/backend/snmp

I just remembered that I has a similar issue with querying a network printer via the office wireless network, but when I switched to wired ethernet, I was able to detect it. I wonder if you’re experiencing the same. If possible, as a test try connecting the PC directly to the router via an ethernet cable, (and maybe the printer too).

Avahi uses mDNS to discover the IP addresses of a given hostname. I have read that some wireless routers apparently need to be configured to allow multicast broadcasts.

Further to this, I note that my Netcomm NB304N router has a wireless setting ‘Enable Wireless Multicast Forwarding (WMF)’ which I have enabled.

Thanks Deano! Mine is a desk-, rather than a laptop, so I would need a very long ethernet cable to the router. I moved the computer when I installed openSuse (to replace XP), but it’s a hassle. So that’s the last resort. Here is the debug:


linux-hirq:/home/misi # CUPS_DEBUG_LEVEL=3 /usr/lib/cups/backend/snmp
DEBUG: Scanning for devices in "public" via "@LOCAL"...
DEBUG: Sending get request to 192.168.1.255...
DEBUG: OUT Hex Dump (43 bytes):
DEBUG: OUT 0000: 30 29 02 01  00 04 06 70  75 62 6c 69  63 a0 1c 02    0).....public...
DEBUG: OUT 0010: 01 01 02 01  00 02 01 00  30 11 30 0f  06 0b 2b 06    ........0.0...+.
DEBUG: OUT 0020: 01 02 01 19  03 02 01 02  01 05 00                    ...........
DEBUG: OUT Message:
DEBUG: OUT SEQUENCE 41 bytes
DEBUG: OUT     INTEGER 1 bytes 0
DEBUG: OUT     OCTET STRING 6 bytes "public"
DEBUG: OUT     Get-Request-PDU 28 bytes
DEBUG: OUT         INTEGER 1 bytes 1
DEBUG: OUT         INTEGER 1 bytes 0
DEBUG: OUT         INTEGER 1 bytes 0
DEBUG: OUT         SEQUENCE 17 bytes
DEBUG: OUT             SEQUENCE 15 bytes
DEBUG: OUT                 OID 11 bytes .1.3.6.1.2.1.25.3.2.1.2.1
DEBUG: OUT                 NULL VALUE 0 bytes
DEBUG: 2.002 Scan complete!

Yeah, that’s effectively a null result (same as I get with no devices on the network). I think you should try wired connectivity as a test, and also check your router settings (via web its interface) for the kind of settings that might relate to forwarding multicast packets. I’ll be interested in your results. :slight_smile:

I stood on my head, but I connected to the router via ethernet and checked that UPnP is enabled. The result was the same:


inux-hirq:/home/misi # /usr/lib/cups/backend/snmp BRW5CAC4C807987.local
ERROR: Unable to scan "BRW5CAC4C807987.local"!

I called the manufacturer, ASUS, who said that it might be a Linux driver problem, as the printer does work with my windows 7 laptop.

It makes me wonder if the printer hostname is set properly. You could try using snmget or snmpwalk (referenced in post #25 and #26 of the thread I linke to previously) instead to get the ‘sysName.0’ name. You may need to install the ‘snmp-net’ package first.

[QUOTEI called the manufacturer, ASUS, who said that it might be a Linux driver problem, as the printer does work with my windows 7 laptop.[/QUOTE]
Typical rubbish response fomr a vendor who knows nothing about Linux. (You have already demonstrated that connectivity works using IP address.) This is a network/protocol-related issue, but definitely nothing to do with the driver. (Anyway, connecting directly via USB would have proved that.)

Typical rubbish response fomr a vendor who knows nothing about Linux. (You have already demonstrated that connectivity works using IP address.) This is a network/protocol-related issue, but definitely nothing to do with the driver. (Anyway, connecting directly via USB would have proved that.)[/QUOTE]

Unfortunately, no luck:


linux-hirq:/home/misi # /usr/lib/cups/backend/snmp 192.168.1.63
network lpd://BRW5CAC4C807987/BINARY_P1 "Brother HL-5370DW series" "Brother HL-5370DW series" "MFG:Brother;CMD:PJL,PCL,PCLXL;MDL:HL-5370DW series;CLS:PRINTER;" ""

The hostname is also the same on the router’s setting page. However, I connected the printer via UBS and it doesn’t print. What should I check? Thanks!

The hostname is also the same on the router’s setting page. However, I connected the printer via UBS and it doesn’t print. What should I check? Thanks!

Just to be clear, in order that USB printing works you need to be a member of the ‘lp’ group, and you’d need to configure via YaST or the CUPS web interface first.

I must be missing something, as after configuring with YaST, I still get this:

  HL5370DW-10             root             17408   Sat Feb 15 11:30:50 2014 printer HL5370DW now printing HL5370DW-10.  enabled since Sat Feb 15 11:30:50 2014 	Unable to locate printer "BRW5CAC4C807987.local".

Print jobs are sitting in the queue, but not printing:


misi@linux-hirq:~> lpstat
HL5370DW-9              misi              1024   Sat 15 Feb 2014 11:25:01 AM EST

Please post your /etc/cups/printers.conf here. That will show any/all current printer configurations.


cat printers.conf
# Printer configuration file for CUPS v1.5.4
# Written by cupsd on 2014-02-15 11:26
# DO NOT EDIT THIS FILE WHEN CUPSD IS RUNNING
<Printer HL5370DW>
UUID urn:uuid:281fbbe2-cc70-31b9-578a-b9db187dca58
Info HL5370DW
MakeModel Brother HL5370DW for CUPS
DeviceURI lpd://BRW5CAC4C807987.local/BINARY_P1
State Idle
StateTime 1392481545
Type 8392724
Accepting Yes
Shared Yes
JobSheets none none
QuotaPeriod 0
PageLimit 0
KLimit 0
OpPolicy default
ErrorPolicy stop-printer
</Printer>
I also canceled the test page in the queue.