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.
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?
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... ...
OK, I see. Could you show me the output of '/sbin/ifconfig' please?
$ 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)
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
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
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
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.
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.
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!
Discussion of an SNMP conntrack module: http://www.spinics.net/lists/netfilter/msg47069.html
Thread continues here: http://www.spinics.net/lists/netfilter-devel/msg10916.html
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.
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
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
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
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.
Yes, it's still a problem.
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
Is this still a problem with 3.9 based F19 kernels?
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.