Bug 538675 - Replies to broadcast SNMP and NetBIOS queries are dropped
Summary: Replies to broadcast SNMP and NetBIOS queries are dropped
Keywords:
Status: CLOSED INSUFFICIENT_DATA
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 19
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: 638176 728138
TreeView+ depends on / blocked
 
Reported: 2009-11-19 03:10 UTC by Michael Ploujnikov
Modified: 2013-04-23 17:24 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 638176 (view as bug list)
Environment:
Last Closed: 2013-04-23 17:24:32 UTC
Type: ---


Attachments (Terms of Use)
snmp results when specifying a hostname (17.68 KB, text/plain)
2009-11-19 03:10 UTC, Michael Ploujnikov
no flags Details

Description Michael Ploujnikov 2009-11-19 03:10:07 UTC
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.

Comment 1 Tim Waugh 2009-12-02 14:35:08 UTC
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?

Comment 2 Michael Ploujnikov 2009-12-02 15:07:07 UTC
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...
...

Comment 3 Tim Waugh 2009-12-02 15:20:39 UTC
OK, I see.  Could you show me the output of '/sbin/ifconfig' please?

Comment 4 Michael Ploujnikov 2009-12-02 16:23:26 UTC
$ 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)

Comment 5 Tim Waugh 2009-12-02 17:22:23 UTC
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

Comment 6 Michael Ploujnikov 2009-12-02 18:29:46 UTC
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

Comment 7 Tim Waugh 2009-12-02 23:01:59 UTC
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

Comment 8 Michael Ploujnikov 2009-12-03 02:18:08 UTC
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.

Comment 9 Tim Waugh 2009-12-03 13:30:14 UTC
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.

Comment 10 Tim Waugh 2009-12-03 17:41:16 UTC
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!

Comment 11 Tim Waugh 2009-12-04 10:41:54 UTC
Discussion of an SNMP conntrack module:

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

Comment 12 Tim Waugh 2009-12-07 12:11:33 UTC
Thread continues here:

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

Comment 13 Tim Waugh 2010-04-15 18:59:42 UTC
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.

Comment 14 Tim Waugh 2010-08-25 10:41:55 UTC
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 15 Bug Zapper 2010-11-04 06:06:59 UTC
This message is a reminder that Fedora 12 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 12.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '12'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 12's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 12 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 16 Bug Zapper 2011-06-02 17:24:10 UTC
This message is a reminder that Fedora 13 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 13.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '13'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 13's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 13 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 17 Josh Boyer 2012-06-04 14:48:38 UTC
Tim, is this still a problem in F16 or F17?  If so, this bug should probably be moved to rawhide so it doesn't get stuck in an EOL release closure.

Comment 18 Tim Waugh 2012-06-08 15:38:26 UTC
Yes, it's still a problem.

Comment 19 Fedora End Of Life 2013-04-03 20:07:31 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle.
Changing version to '19'.

(As we did not run this process for some time, it could affect also pre-Fedora 19 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.)

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19

Comment 20 Justin M. Forbes 2013-04-05 15:41:59 UTC
Is this still a problem with 3.9 based F19 kernels?

Comment 21 Justin M. Forbes 2013-04-23 17:24:32 UTC
This bug is being closed with INSUFFICIENT_DATA as there has not been a
response in 2 weeks.  If you are still experiencing this issue,
please reopen and attach the relevant data from the latest kernel you are
running and any data that might have been requested previously.


Note You need to log in before you can comment on or make changes to this bug.