MavEtJu's Distorted View of the World - Printers

Stupid network printers...
Kyocera KM-4035 network scanner

Back to index

Stupid network printers...

Posted on 2006-11-22 11:30:53, modified on 2006-11-22 11:37:54
Tags: Printers, DHCP

Just when you think that you can quietly do some overdue network redesign, everybody suddenly wants network printers / scanners hooked up. And of course, these things are dumb++

Printers which don't understand DHCP relays and lose their IP address every time their lease expires.
Printers which do understand DHCP, but their installers do not want to use it since they have bad experiences with it.
Printers which don't understand DNS and demand the IP address of the SMTP server.
Printers which don't have MacOS/X printer drivers, but understand LPR so Mac users get un-accounted printing facilities (yay!)

No comments | Share on Facebook | Share on Twitter

Kyocera KM-4035 network scanner

Posted on 2005-03-24 10:41:11, modified on 2006-01-09 16:29:23
Tags: Networking, Printers, DNS

We have the Kyocera KM-4035 network printer/scanner. Beautiful machine, it can copy, print and scan. It accepts print jobs from the network, and it can send scanned pictures as PDF to your mailbox.

Well, most of the time. Sometimes it refuses to send emails. Why?

To scan, you need to press the scan button. And sometimes, it just says "SMTP server could not be found". Very annoying. And what was more annoying was that the problem was not easily reproducable, it was actually very hard to figure it out.

To make a long story short, the problem lies in the DNS request of the scanner:

12:54:30.879447 10.200.5.11.1024 > 10.200.5.1.53:  19311 A? smtp.banco.net.au. (47)
0x0000   4500 004b 0a59 0000 ff11 91ad 0ac8 050b    E..K.Y..........
0x0010   0ac8 0501 0400 0035 0037 28ad 4b6f 0000    .......5.7(.Ko..
0x0020   0001 0000 0000 0000 0473 6d74 7005 6261    .........smtp.ba
0x0030   6e63 6f03 6e65 7402 6175 0000 0100 0100    nco.net.au......
0x0040   0000 0000 0000 0000 0000 00                ...........

At offset 0x001c the DNS header starts: 0x4b6f (=19311) for the identification, 0x0000 for the flags, 0x0001/0x0000/0x0000/0x000 for the number of requests/answers/authority/additional resource records and the question: who knows the A record for smtp.banco.net.au.

The DNS server for that LAN, at 10.200.5.1, is a caching-only forwarding name server. It does know where to ask for others, but itself isn't authoritative for any domains. It will give answer to questions of which the answers are cached, or to questions which have the RD (Recursion Desired) flag set. The RD flag is normally set for DNS request from simple clients (PCs, network equipment etc). If the RD flag is not set, it indicates that the device (most likely a DNS server) asking the question is smart enough to know how to handle answers with referrals.

So the scanner sends a question without the RD flag.

If the name smtp.banco.net.au is known in the cache of the nameserver, it will return it (this is the "sometimes the scanner works"):
```
12:54:30.879929 10.200.5.1.53 > 10.200.5.11.1024:  19311 3/2/2 CNAME smtp.barnet.com.au., CNAME mail2.barnet.com.au., A 202.83.176.13 (169)
```
If the name smtp.banco.net.au is not known in the cache of the nameserver, it will tell return a list of servers where it can get the information:
```
12:51:51.747207 10.200.5.1.53 > 10.200.5.11.1024:  27028 0/13/13 (454)
```

How can it be resolved?

Long term solution: The scanner should set the RD flag in the question. It has shown it is not capable of finding out itself what to do with the referer answer, it should let this be done by the DNS server itself. Tell Kyocera about this problem and let them release new firmware.
Short term solution: We point the scanner to our main DNS servers, which are authoritative for these domains and thus always can answer the question or where smtp.banco.net.au lives.

The model of the printer/scanner is: KM-4035 Network Scanner
The scanner firmware is: KM-4035 Ver2.62.8
The network firmware is: NS-30 Ver1.3.00

Kyocera has been informed.

No comments | Share on Facebook | Share on Twitter