Red Hat Bugzilla – Bug 638176
Replies to broadcast SNMP and NetBIOS queries are dropped
Last modified: 2011-08-04 03:48:45 EDT
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@redhat.com 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@gmail.com 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@redhat.com 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@gmail.com 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@redhat.com 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@gmail.com 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@redhat.com 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@gmail.com 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@redhat.com 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@redhat.com 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@redhat.com 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@redhat.com on 2009-12-07 07:11:33 EST --- Thread continues here: http://www.spinics.net/lists/netfilter-devel/msg10916.html --- Additional comment from twaugh@redhat.com 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@redhat.com 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
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
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.
sent one RFC/PATCH upstream http://article.gmane.org/gmane.comp.security.firewalls.netfilter.devel/37297
Thanks!
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.
Patch(es) available on kernel-2.6.32-112.el6
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