Conference 7.286::postscript_printing

7069.0. "LPS printers /w NT-DHCP server IP problem" by CSCMA::RUSSELL () Mon Feb 03 1997 08:08

Hi,

A customer at Glaxowellcome has found a strange problem with all printservers
and NT-servers that have DHCP.

The customer has mulitple printservers booted from VMS, lps32, lps20-turbos,
lps17s.

The print clients include DECnet, unix and NT.


problem:

During a reboot of any lps printer, if dhcp packet is sent from the NT-DHCP
server while a LPS printer is going through it's primary boot, the LPS printer
will pick up that dhcp packet and will take that IP address from the NT-DHCP
servere instead the IP address that is defined on the VMS boot-host. 

The LPS printer that takes the DHCP IP address will boot successfully, and
will support print clients from DECnet. 

All other Unix and NT print clients cannot access this LPS printer. The NT 
client that is suppose to get it's Ip address from the NT-DHCP server is lost.


analysis:

lpsconfig.printer has ip address subnet, and gateway is set,

LPSlog.printername shows the reboot process, it loads successfully with
the unassigned IP address sent via NT-DHCP server, The lpslog.printer
files shows "ip address ignored" "ip address already assigned"

The customer says that his NT-DHCP manager says that from the DHCP
database the printservers are excluded someone so that they do not 
get an IP address. (I don't understand enough about DHCP to explain
how/or where this is done)

Thank you for any information,
Lynda

***************************************************************************


Several bits follow.  I have PrintServers running on V4.2-18 of the
software, and PrintServers running on V5.1-15.  The problem is occurring
with both versions of the software.

The example I am sending is for a PrintServer we call US0S20, a
PrintServer 17, currently loading the V4.2 version of the software.
The LPSCONFIG.US0S20 file is shown here ("-" lines are used to show 
the limits of the file, they are NOT actually part of file contents):

----------------------------------------------------------------------------
accounting off
logging on
printername US0S20
ps-password (gargleblaster)
manage-password (nolatprinters)
language eng
ipaddress 152.51.20.208
subnetmask 255.255.0.0
gateway 152.51.1.222
----------------------------------------------------------------------------

Below you'll find a subset of LPSLOG.US0S20, showing my last reboot 
attempt on the printer.  Reboot was forced using NCP TRIGGER NODE US0S20:

----------------------------------------------------------------------------
lps$services.exe;2  Jan 31 09:28:35:  Lost connection to server -- restarting
lps$services.exe;2  Jan 31 09:29:08:  Start management session
31-JAN-1997 09:29:08 $CONFIG: ipaddress ignored (already set)
31-JAN-1997 09:29:54 Load complete
31-JAN-1997 09:30:08 Print Engine ready
31-JAN-1997 09:30:11 Job refused pending configuration
31-JAN-1997 09:30:16 exitserver has been executed - permanent state may be changed
31-JAN-1997 09:31:08 Job refused pending configuration
31-JAN-1997 09:31:15 exitserver has been executed - permanent state may be changed
31-JAN-1997 09:31:42 exitserver has been executed - permanent state may be changed
31-JAN-1997 09:32:07 exitserver has been executed - permanent state may be changed
31-JAN-1997 09:32:07 Job refused pending configuration
31-JAN-1997 09:33:07 Session 1 (US8V62_US0S20-connect@US8V62) connect 
31-JAN-1997 09:33:11 Job 1, document 1 (Client Job Id: 106, BJ17938@US8V62) start 
----------------------------------------------------------------------------

Finally, the result of connecting to the printer via LPS$CONSOLE and
issuing the CONFIG command to show the configuration after the printer
reboot:

----------------------------------------------------------------------------
 LPS> config
Accounting:     Off
Logging:        On -> US0V00
Boot host:      aa:00:04:00:01:2c (US0V00)
Configuration host(s):
  Initial:      US0V00
  Latest :      US0V00
IP address:     152.51.146.116
IP subnet mask: 255.255.0.0
Ethernet:       aa:00:04:00:d7:3f
DECnet address: 15.983
Consoles:       AMR22583@US0V00
Option(s):
  Memory         8M base +  0M optional
  Duplexer      Not installed
  Env. Feeder   Not Installed
  Network board Thin wire/thick wire
----------------------------------------------------------------------------

As you can see, clearly it has grabbed a different IP address from the one
which it is SUPPOSED to be obtaining (from LPSCONFIG via the supporting
host)!

My only means for getting this machine configured at its CORRECT IP address
is to continually reboot the printer until I happen to get lucky, and get
the critical part of rebooting (whatever that is) done without a DHCP
packet flying by and the printer stealing that address.

Of course this is causing multiple problems:

	1.  The PrintServer and the NT client are in conflict over
		who owns the IP address.

	2.  Unix nodes cannot print to the PrintServer when it 
		steals an address, since they expect it to be
		at the static address.

	3.  NT print server nodes cannot print to the PrintServer,
		since they also expect it to be at the static IP
		address.


One final note for me today.  The DHCP gurus were gone for the week, but
I talked with an apprentice.  What we are observing here doesn't seem to
fit well with the description you had from your coworker.

If the PrintServer is requesting an address after the VAX ELN image 
starts up AND the DHCP server was assigning it one, then we would expect 
the server to show that address as having been reserved by one of the two
possible MAC addresses for the PrintServer (most likely the AA-00-04-
address, after DECnet is started on the card).

What our DHCP server is claiming is that the IP address that the
PrintServer has was reserved for a DIFFERENT client (i.e., one which
does not have EITHER of the PrintServer's possible MAC addresses).

At the moment, I can only think of one scenario which would support this:

	1.  The PrintServer sends a bootp request for address

	2.  The DHCP server responds

	3.  The PrintServer assumes the address, but does NOT
		conclude the reservation dialog with the DHCP
		server

	4.  The DHCP server "times out," assumes that it did
		not grant the address, returns it to the free
		addresses pool, and assigns it to a PC at a
		later time. 

If there is another scenario which fits the observations at the server, I'd
love to hear about it.

I will arrange for experiments next week to block/fix the response to the 
MAC addressES of the PrintServers on the DHCP server (which is what I think
your coworker was suggesting), since they would prevent the "broken dialog" 
description above.

    Hello,
    
    I'm still waiting on a trace log from the NT DHCP sever, in the
    meantime I have more information from the customer.
    
    The customer claims that the PrintServer has been excluded from the
    DHCP databse. 
    
    AT this itme I cannot explain why the Printer still takes the IP addres
    from the NT DHCP server and not the VMS boot host.
    
    Thank You,
    Lynda
    
With respect to trying to define the desired IP address to assign to
either/both of the PrintServer's MAC addresses, we did try that 
experiment, and it did not appear to solve any problems.  The 
PrintServer did not obtain the correct IP address, but continued 
to obtain other IP address(es) when we cycled it through reboot(s).

When I rebooted the PrintServer and found it at an incorrect IP 
address, I had the NT person who was connected to the DHCP server
check and see who the server thought the address was assigned to.
In all cases, the server believed the reservation was to a 
different node, not to the PrintServer (at either MAC address).

Furthermore, in most cases, the DHCP server believed (based on the
expiration time for the reservation) that the IP address in-question
had actually be reserved by the third-party node some time ago 
(i.e., not concurrently with the PrintServer reboot).

I'm reported information relayed to me over the phone during a test
session, but I don't have any reason to doubt its accuracy.  I plan
to try and talk with the DHCP person again this afternoon and see
if he can setup this "trace log" you mentioned in your e-mail.  Let
me make sure (one more time) that I understand what I'm supposed to
ask him:

	1.  On the DHCP server, there is going to be a "Print
		Manager" window, which has a "Properties" window
		for a given PrintServer printer.

		Q:  Is this true even though the DHCP server
		    node is not configured to assign an IP 
		    address to the PrintServer, and probably 
		    does not have any print queues configured
		    (my understanding is the DHCP server nodes 
		    here are single-function, dedicated to
		    DHCP)?

	2.  In this Properties window, the DHCP manager should
		activate "Settings->Options->Logging" and turn
		on a "Trace File."

	3.  This will somehow get us a trace of any DHCP activities 
		the DHCP server thinks it has carried out on behalf 
		of the PrintServer, if any?

    Could there be another DHCP server on the LAN that you don't know
    about?  There is a utility in the NT resource kit to sniff out DHCP
    servers.
    
    	dave
    

    
    Two facts, which do not SOLVE your problem, but may be useful:
    
    The PrintServer *always* issues a BOOTP request after the primary boot.
    If it gets answered BEFORE the VMS management client can connect, then
    the IP info in the LPSCONFIG file will be ignored. You have already
    observed this behavior, I'm just confirming that your observation is
    correct.
    
    The PrintServer does not "do" DHCP per se. DHCP is a relatively new
    extension to BOOTP, that is backwards-compatible with BOOTP. So, your
    theory that the printer may not be able to complete a DHCP
    "conversation" may be true, since it only understands the base BOOTP 
    parts of the packet and would ignore the extensions. I don't know
    enough details about DHCP to comment any further. 
    
    -cg
    
    
      

    I believe this DHCP service is going to be a big problem with
    Printservers, the CSC is starting to get more calls on this,
    boot problems from NT /w DHCP enabled. I don't know enough about 
    DHCP to solve this boot problem except to add the printer to the
    exclustion list, but this doesn't seem to fix the boot issue.
    I have another customer call with a Alpha Nt running DHCP,
    the LPS32 will not boot at all from this node. 
    
    If anyone can add anything more to this issue I would appreciate it,
    if not I will have to IPMT my 2 customer calls.
    
    Thank You,
    Lynda
    

    We are running DHCP here in this building and we boot PrintServer
    printers off of NT systems.
    
    Does the printer stay in ?56 for some time but ultimately boot up?
    Does the printer stay in ?54 mode?
    
       jeff

    Jeff,
    
    	My understanding of this problem is that the DHCP server and the
    boot host for the LPS printer is on the same NT server. I am setting up
    DHCP on my NT server to try some things out.
    
    Renis