Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 638176

Summary:	Replies to broadcast SNMP and NetBIOS queries are dropped
Product:	Red Hat Enterprise Linux 6	Reporter:	Tim Waugh <twaugh>
Component:	kernel	Assignee:	Jiri Olsa <jolsa>
Status:	CLOSED ERRATA	QA Contact:	Dayong Tian <dtian>
Severity:	medium	Docs Contact:
Priority:	low
Version:	6.0	CC:	dtian, hjia, j.kopkova, jolsa, kzhang, nhorman, tgraf, twaugh, ykopkova
Target Milestone:	rc
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:	kernel-2.6.32-112.el6	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:	538675
Clones:	728138 (view as bug list)		Environment:
Last Closed:	2011-05-23 20:53:26 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	538675
Bug Blocks:	591633, 728138

Description Tim Waugh 2010-09-28 12:52:59 UTC

Summary:

It ought to be possible to ship a default firewall that will allow replies to broadcast SNMP and NetBIOS queries that we have sent.

This needs:

a) kernel support in order to associate the responses with the broadcast queries
b) system-config-firewall changes to use the new kernel support

+++ This bug was initially created as a clone of Bug #538675 +++

Created attachment 370258 [details]
snmp results when specifying a hostname

Description of problem:
My printer isn't listed in the "Discovered Network Printers" list when I try to add it. Also, following the debugging steps outlined in http://localhost:631/help/network.html?QUERY=discover#SNMP shows that the snmp command doesn't actually speak to or find my SNMPv1-enabled printer.


Version-Release number of selected component (if applicable):
cups-1.4.1-13.fc12.x86_64

How reproducible:
Always.

Steps to Reproduce:
1. CUPS_DEBUG_LEVEL=2 /usr/lib/cups/backend/snmp 2>&1 | tee snmp.log
2. cat snmp.log
3.
  
Actual results:
DEBUG: Scanning for devices in "public" via "@LOCAL"...
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: 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: 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.005 Scan complete!

Expected results:
Something like the following. Note the obvious lack of sending bytes to the broadcast IP:
 1  INFO: Using default SNMP Address @LOCAL
 2  INFO: Using default SNMP Community public
 3  DEBUG: Scanning for devices in "public" via "@LOCAL"...
 4  DEBUG: 0.000 Sending 46 bytes to 192.168.2.255...
 5  DEBUG: SEQUENCE 44 bytes
 6  DEBUG:     INTEGER 1 bytes 0
 7  DEBUG:     OCTET STRING 6 bytes "public"
 8  DEBUG:     Get-Request-PDU 31 bytes
 9  DEBUG:         INTEGER 4 bytes 1149539174
10  DEBUG:         INTEGER 1 bytes 0
11  DEBUG:         INTEGER 1 bytes 0
12  DEBUG:         SEQUENCE 17 bytes
13  DEBUG:             SEQUENCE 15 bytes
14  DEBUG:                 OID 11 bytes .1.3.6.1.2.1.25.3.2.1.2.1
15  DEBUG:                 NULL VALUE 0 bytes
16  DEBUG: 0.001 Received 55 bytes from 192.168.2.229...
17  DEBUG: community="public"
18  DEBUG: request-id=1149539174
19  DEBUG: error-status=0
20  DEBUG: SEQUENCE 53 bytes
21  DEBUG:     INTEGER 1 bytes 0
22  DEBUG:     OCTET STRING 6 bytes "public"
23  DEBUG:     Get-Response-PDU 40 bytes
24  DEBUG:         INTEGER 4 bytes 1149539174
25  DEBUG:         INTEGER 1 bytes 0
26  DEBUG:         INTEGER 1 bytes 0
27  DEBUG:         SEQUENCE 26 bytes
28  DEBUG:             SEQUENCE 24 bytes
29  DEBUG:                 OID 11 bytes .1.3.6.1.2.1.25.3.2.1.2.1
30  DEBUG:                 OID 9 bytes .1.3.6.1.2.1.25.3.1.5
31  DEBUG: add_cache(addr=0xbfffe170, addrname="192.168.2.229",
    uri="(null)", id="(null)", make_and_model="(null)")
32  DEBUG: 0.002 Sending 46 bytes to 192.168.2.229...
33  DEBUG: SEQUENCE 44 bytes
34  DEBUG:     INTEGER 1 bytes 0
35  DEBUG:     OCTET STRING 6 bytes "public"
36  DEBUG:     Get-Request-PDU 31 bytes
37  DEBUG:         INTEGER 4 bytes 1149539175
38  DEBUG:         INTEGER 1 bytes 0
39  DEBUG:         INTEGER 1 bytes 0
40  DEBUG:         SEQUENCE 17 bytes
41  DEBUG:             SEQUENCE 15 bytes
42  DEBUG:                 OID 11 bytes .1.3.6.1.2.1.25.3.2.1.3.1
43  DEBUG:                 NULL VALUE 0 bytes
44  DEBUG: 0.003 Received 69 bytes from 192.168.2.229...
45  DEBUG: community="public"
46  DEBUG: request-id=1149539175
47  DEBUG: error-status=0
48  DEBUG: SEQUENCE 67 bytes
49  DEBUG:     INTEGER 1 bytes 0
50  DEBUG:     OCTET STRING 6 bytes "public"
51  DEBUG:     Get-Response-PDU 54 bytes
52  DEBUG:         INTEGER 4 bytes 1149539175
53  DEBUG:         INTEGER 1 bytes 0
54  DEBUG:         INTEGER 1 bytes 0
55  DEBUG:         SEQUENCE 40 bytes
56  DEBUG:             SEQUENCE 38 bytes
57  DEBUG:                 OID 11 bytes .1.3.6.1.2.1.25.3.2.1.3.1
58  DEBUG:                 OCTET STRING 23 bytes "HP LaserJet 4000
    Series"
59  DEBUG: 1.001 Probing 192.168.2.229...
60  DEBUG: 1.001 Trying socket://192.168.2.229:9100...
61  DEBUG: 192.168.2.229 supports AppSocket!
62  DEBUG: 1.002 Scan complete!
63  network socket://192.168.2.229 "HP LaserJet 4000 Series"
    "HP LaserJet 4000 Series 192.168.2.229" ""


Additional info:
If I add the hostname of my printer at the end of the snmp command like so:
CUPS_DEBUG_LEVEL=2 /usr/lib/cups/backend/snmp 2>&1 | tee snmp.log
Then it, of course, finds the printer and gets a lot of info from int via SNMP (see snmp-printer attachment). However, according to the help/manual and my expectations I shouldn't have to tell cups what my printer's hostname is. It should just find it by doing a network broadcast.

--- Additional comment from twaugh on 2009-12-02 09:35:08 EST ---

It looks like your printer thinks its IP address is 10.1.1.7.

Are you expecting it to be 192.168.2.229?

How is its network interface configured?

--- Additional comment from ploujj on 2009-12-02 10:07:07 EST ---

The 192.168.2.229 IP does not exist on my network. I just took it from the CUPS example (see http://localhost:631/help/network.html?QUERY=discover#SNMP). Sorry for the confusion.

The printer correctly thinks that it's IP address is 10.1.1.7. My network interface is configured to use 10.1.1.8/24.

To make the example more correct, I expect the output to include something like:

...
4  DEBUG: 0.000 Sending 46 bytes to 10.1.1.255...
...
16  DEBUG: 0.001 Received 55 bytes from 10.1.1.7...
...

--- Additional comment from twaugh on 2009-12-02 10:20:39 EST ---

OK, I see.  Could you show me the output of '/sbin/ifconfig' please?

--- Additional comment from ploujj on 2009-12-02 11:23:26 EST ---

$ ifconfig 
eth0      Link encap:Ethernet  HWaddr 00:24:7E:6B:42:D6  
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
          Memory:fc000000-fc020000 

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:477 errors:0 dropped:0 overruns:0 frame:0
          TX packets:477 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:102948 (100.5 KiB)  TX bytes:102948 (100.5 KiB)

virbr0    Link encap:Ethernet  HWaddr C6:8A:04:B6:D2:8A  
          inet addr:192.168.122.1  Bcast:192.168.122.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:24 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:0 (0.0 b)  TX bytes:4566 (4.4 KiB)

wlan0     Link encap:Ethernet  HWaddr 00:21:6A:52:27:5A  
          inet addr:10.1.1.8  Bcast:10.1.1.255  Mask:255.255.255.0
          inet6 addr: fe80::221:6aff:fe52:275a/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:30631 errors:0 dropped:0 overruns:0 frame:0
          TX packets:24970 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:8355314 (7.9 MiB)  TX bytes:4546117 (4.3 MiB)

wmaster0  Link encap:UNSPEC  HWaddr 00-21-6A-52-27-5A-80-3E-00-00-00-00-00-00-00-00  
          UP RUNNING  MTU:0  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

--- Additional comment from twaugh on 2009-12-02 12:22:23 EST ---

It looks like the actual debugging output varies from the described output in that the target IP addresses are not shown.  I think it probably is actually sending a broadcast to that network though.

Could you please run this command while running the snmp backend?:

tcpdump -niwlan0 udp port snmp

--- Additional comment from ploujj on 2009-12-02 13:29:46 EST ---

This is what I got

# tcpdump -niwlan0 udp port snmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on wlan0, link-type EN10MB (Ethernet), capture size 65535 bytes
13:29:02.495718 IP 10.1.1.8.33353 > 10.1.1.255.snmp:  GetRequest(28)  .1.3.6.1.2.1.25.3.2.1.2.1
13:29:02.517592 IP 10.1.1.7.snmp > 10.1.1.8.33353:  GetResponse(37)  .1.3.6.1.2.1.25.3.2.1.2.1=.1.3.6.1.2.1.25.3.1.5

--- Additional comment from twaugh on 2009-12-02 18:01:59 EST ---

I wonder if the firewall is blocking the packet.

Could you try running the snmp backend with the firewall temporarily disabled?

/sbin/service iptables stop
/usr/lib/cups/backend/snmp
/sbin/service iptables start

--- Additional comment from ploujj on 2009-12-02 21:18:08 EST ---

Yeah, looks like it works with iptables stopped:

...
DEBUG: 0.023 Received data from 10.1.1.7...
...
network  "Lexmark  Lexmark E250dn" "Lexmark E250dn 6216N4G LE.PM.P121 -- Part Number --" "MANUFACTURER:Lexmark International;COMMAND SET:PCL 6 Emulation, PostScript Level 3 Emulation, NPAP, PJL;MODEL:Lexmark E250dn;CLS:PRINTER;DES:Lexmark E250dn;CID:Lexmark_Internationa510B, Lexmark_Internationa8DCF, Lexmark_Internationa5C93;COMMENT:ECP1.0, LV_043D, LP_00F2, LF_0046;" "home"
DEBUG: 4.115 Scan complete!
...

and the printer now shows up in the results of cups' automatic scan.

--- Additional comment from twaugh on 2009-12-03 08:30:14 EST ---

I see.  The problem is that the default firewall rules do not allow responses to SNMP broadcast queries.  Not only that but there is no easy modification to the firewall rules to allow such responses.

It looks like this is the SNMP version of an old NetBIOS issue: bug #113918.  That was fixed using a kernel conntrack module, so perhaps the same approach is needed here.

--- Additional comment from twaugh on 2009-12-03 12:41:16 EST ---

It looks like you are also seeing bug #542857 -- the line beginning "network" is incorrect and missing the 'device URI' field.  Could I get you to try out a test cups package to see if that bug is fixed?  See bug #542857 comment #14.  It would be great if you could upgrade to those packages, disable the firewall, run the snmp backend, start the firewall again, and post (to bug #542857) what output you got from the snmp backend.  Thanks!

--- Additional comment from twaugh on 2009-12-04 05:41:54 EST ---

Discussion of an SNMP conntrack module:

http://www.spinics.net/lists/netfilter/msg47069.html

--- Additional comment from twaugh on 2009-12-07 07:11:33 EST ---

Thread continues here:

http://www.spinics.net/lists/netfilter-devel/msg10916.html

--- Additional comment from twaugh on 2010-04-15 14:59:42 EDT ---

So in Fedora 13 the approach I've taken is to get system-config-printer to adjust the firewall to allow all SNMP replies.

We still need to fix this properly: it ought to be possible to ship a default firewall that will allow replies to broadcast queries that we have sent.

Changing component to kernel.

--- Additional comment from twaugh on 2010-08-25 06:41:55 EDT ---

Actually it looks like this solution in system-config-printer does not work.  It allows incoming packets to destination port 161, but that isn't how it works as we can see in comment #6.

I see that the same underlying problem also affects SMB broadcast queries:

11:33:42.458120 IP 192.168.2.11.44542 > 192.168.2.255.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
11:33:42.641206 IP 192.168.2.1.netbios-ns > 192.168.2.11.44542: NBT UDP PACKET(137): QUERY; POSITIVE; RESPONSE; UNICAST

This needs:

a) kernel support in order to associate the responses with the broadcast queries
b) system-config-firewall changes to use the new kernel support

Comment 2 Neil Horman 2010-11-10 18:21:28 UTC

Triage assignment.  If you feel this bug doesn't belong to you, or that it cannot be handled in a timely fashion, please contact me for re-assignment

Comment 3 RHEL Program Management 2011-01-07 04:28:39 UTC

This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated
in the current release, Red Hat is unfortunately unable to
address this request at this time. Red Hat invites you to
ask your support representative to propose this request, if
appropriate and relevant, in the next release of Red Hat
Enterprise Linux. If you would like it considered as an
exception in the current release, please ask your support
representative.

Comment 4 Jiri Olsa 2011-01-14 20:27:39 UTC

sent one RFC/PATCH upstream
http://article.gmane.org/gmane.comp.security.firewalls.netfilter.devel/37297

Comment 5 Tim Waugh 2011-01-17 11:46:55 UTC

Thanks!

Comment 7 RHEL Program Management 2011-01-26 19:30:47 UTC

This request was evaluated by Red Hat Product Management for inclusion
in a Red Hat Enterprise Linux maintenance release. Product Management has 
requested further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed 
products. This request is not yet committed for inclusion in an Update release.

Comment 8 Aristeu Rozanski 2011-02-03 16:46:21 UTC

Patch(es) available on kernel-2.6.32-112.el6

Comment 17 errata-xmlrpc 2011-05-23 20:53:26 UTC

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHSA-2011-0542.html