Broadcast Addresses and 'Frankencopiers'

First, what is a 'Frankencopier'?


Basically it's a device that doesn't actually exist at a site, but shows up in the list of devices, and on further examination consists of bits and pieces of information from the other devices on the network.  So it may have the name of one machine, the life count of a different machine, and the serial number of a third machine. Hence 'Frankencopier', just like the monster was assembled from parts from different corpses, this device has been built from parts of different devices.

How does a 'Frankencopier' happen?


Every device on a network will have an unique address to distinguish it from the other devices on the network. Additionally contiguous groups (for the most part) of addresses can be established as subnets.  Functionally, for our purposes, a subnet is a group of addresses that can easily exchange traffic with one another, without requiring a router or gateway. In addition to the individual addresses available for devices, every subnet has two additional addresses: the network address, and the broadcast address, neither of which do we want ICE scanning.

The broadcast address is the one however that can cause a 'Frankencopier' to show up on your site. 

Basically when traffic is sent to the broadcast address, every device on the subnet is being passed that traffic. In the case of ICE, this means it sends an SNMP request to every device on the subnet. So every SNMP capable device could conceivably reply to a request sent on the broadcast address, including the MFPs and copiers. As this flood of replies comes back to ICE, it tries to define the printer it has found.  So it may grab make and model from the replies from one device, toner and counts from another, and serial and location from a third, and so on. 

ICE has been designed to skip network and broadcast addresses, so in general, if scan ranges are configured correctly, ICE will automatically avoid the network and broadcast addresses. The problem arises when the scan range configuration of ICE (specifically the subnet mask) doesn't match the subnet mask in use in the customers environment. 

A subnet mask, again functionally for our discussion, simply serves to identify what those network and broadcast addresses are. This is a gross oversimplification of what a subnet mask actually represents, but again, functionally in terms of 'Frankendevices' it serves the need.

How do I get rid of a 'Frankencopier' and prevent it from coming back?


Well getting rid of them is simply a matter of deleting the device from FM. But, until we address the problem with the scan range, the device will simply repopulate on the next scan (probably with a different mix of readings from other machines.)

The best way to fix it, is to change the subnet mask for the scan range to correspond to the subnet mask that the customer is actually using on that subnet. If ICE uses the same subnet mask that the customer uses, ICE will correctly determine the network and broadcast addresses and stay off of them.

A quick an dirty work around would be to simply modify the scan range to skip the broadcast address where the 'Frankencopier' showed up. This will prevent the 'Frankencopier' from showing up, but it won't address that ICE may be scanning a network address. You would do this as a stop gap measure, until you could get the proper subnet mask from the customer, at which point you would fix it properly by changing the subnet mask on the scan range. Scanning network addresses may not generate an obvious symptom in FM like a 'Frankencopier' but we still don't want ICE scanning it, so the quick and dirty fix should only ever be a stop-gap until the proper subnet mask can be obtained and set up on the appropriate scan range.
How did we do with this article?