| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 7090.1 | Look at the gateway | NECSC::HARVEY | Printserver Support- America's Zone | Fri Feb 21 1997 11:34 | 8 |
| Michael,
Can you ping the printer? Is there a a unix machine that the lpsrc
utility can be run on that is in the local printers subnet? Then using
the remote console get the printers config data. I suspect that the
printer doesn't have the correct gateway address.
Renis
|
| 7090.2 | More Details | MEOC02::BARNHOORN | here on Cactus Island | Sun Feb 23 1997 18:38 | 105 |
|
Renis,
I'm working with Michael, on loading the LPS17 over WAN using IP.
To restate the configuration, we are testing (and will go in production) is a
central system(s) located at head office and PCs (Windows 3.1) located at the
remote site with the LPS17.
_____ ______
|DUnix| | W NT |
------- --------
| |
---------------------- (LAN1)
|
(Router1)
\
-----------------
\
(Router 2)
|
-------------- (LAN2)
| |
PCs LPS17
To answer your questions, in .1
>> Can you ping the printer?
After the LPS17 loads the initial lps17.sys file, via bootp, router2 and the
pcs can ping the LPS17.
router1, the NT box and the Unix system CANNOT ping the LPS17.
(They can ping the PCs on the LPS17's subnet (LAN2))
>> Is there an unix machine that the lpsrc utility can be run on that is in
the local printers subnet?
No refer to diagram.
>> Then using the remote console get the printers config data.
no remote system.
>> I suspect that the printer doesn't have the correct gateway address.
Watching the bootp request and reply with an Ethernet sniffer on the LPS17's
network (LAN2) we see the LPS17s, IP address, subnet address and GATEWAY
address sent to the LPS17.
After the bootp file (lps17.sys) is sent, the DUnix box tries to make a TCP
connection to the LPS17 to send the rest of the configuration details, but the
LPS17 never responds.
From the Release Notes ************************************************
Problems Addressed in this Release
Specific changes include the following:
o A PrintServer printer running Version 5.0 cannot be
booted with bootp over a gateway. This means that the
primary boot host, secondary boot host, and PrintServer
printer must all be in the same subnet. This has been
fixed in Version V5.1.
*************************************************************************
HAS ANYONE ELSE TRIED THIS AND SUCCESSFULY GOT THIS TO WORK??
DOES THIS REALLY WORK (REMOTE BOOTING) WITH V5.1?
NOTE:
When the LPS17 is located on Local LAN (LAN1), it loads and prints correctly.
The IP address, subnet address and Gateway address are correctly defined.
The lpssetup utility (and edit bootptab) is re-executed when we relocate the
LPS17 onto LAN2.
regards
Mark.
Versions Used:
VAXELN V4.5 LPS17
LPS17 V2.1 1.0 1.0
LPS17-AB (32 Meg Memory PrinterServer 17/600)
Printserver Server Software for Digital Unix, V5.1
|
| 7090.3 | Check out the subnet mask | NECSC::HARVEY | Printserver Support- America's Zone | Mon Feb 24 1997 11:42 | 19 |
| Mark,
I have personally setup remote booting of LPS17s. One case was a
customer has their major data center in San Francisco, CA and were
booting remote LPS17s in various remote offices, for instance New York.
The path to New York from San Francisco was through at least 3 routers.
They had contracted their leased 56k line to a network provider. So the
config was as follows:
UNIX machine -> router1 -> router2 -->Network Cloud --> router3 ->LPS17
I had to play games with the subnet mask to be able to ping the remote
printer. In one case I made the subnetmask 0.0.0.0 and another it was
255.255.255.255. I would investigate the subnetmask if the gateway
address is correct.
Renis
|
| 7090.4 | | REGENT::WOLF | | Mon Feb 24 1997 16:48 | 38 |
| Generally speaking if the printer boots ok but the mnagement client
can not attach to the printer sucessfully (using tcp) then one
of three things are incorrect
1) The ip address of the printer
2) The subnet mask of the printer
3) The gateway address of the printer
One thing to do is get a UNIX box on the local LAN, run the remote
console to the printer, and see what the PRINTER thinks its
ip address, subnet mask and gateway are. No matter what you think
thay are, if the printer is not getting them then until that is fixed,
nothing else will work.
Another thing that is not well known. When booting using bootp there
are acually two bootp requests made by the printer as follows:
1) Printer's boot ROM makes a bootp broadcast request whose
reply should contain a file name which the printer requests using tftp
over udp
When the primary file is loaded in to the printer and you get the
VAXELN message in the front panel, the printer makes a second bootp
request. When the VAXELN messatge is displayed, the printer loses
its ip address, as contrl is passed form boot ROM code to the VAXELN
O.S. The second bootp request establishes ip address, subnet and
gateway information for the Printer, once it is running under VAXeln
control. If this second bootp request fails, the printer will be
incommunicato. Or if, for what ever reason, you do not get a
gateway address, the printer will only be "seen" on the local
lan.
Do you have DHCP running? Could the DHCP server be answering the
second bootp request? This might screw things up. We are seeing
collisions between DHCP and bootp when DHCP and DECPSMON are running
on the same WNT server.
The bottom line is that this does work, but your network must be
well managed.
jeff
|
| 7090.5 | no duplicate address | MEOC02::DWYERMICHAEL | | Tue Feb 25 1997 04:39 | 38 |
| Hi again,
Further info
Sniffer is being used.
The LPS17 is sitting on its own LAN - no other devices.
The second bootp req and reply are seen on the LPS LAN after VAXELN
comes up. The second bootp reply has the SAME information as the first
bootp-reply before the tftp sequence loaded VAXELN, ie the correct gateway
ie both Gateway IP address and gateway fields (don't know why it should
appear twice), server assigned IP, bootfile name "3", hostname and
address, subnet 255.255.255.0, client mac, vendor ID etc. OK
IP src - server, IP dst - address of the LPS17.
UDP fields 67/ 68 .
TCP connect requests keep comin' onto the LPS LAN but the LPS keeps
ignorin' 'em.
Seems to me that VAXELN is ignoring the parameters that the second
bootp reply is throwing at it.
DHCP - OFF
I see two other devices continually requesting bootp loads but are
ignored all the time. I don't see how they could affect the LPS17.
Tried with IP helper on in both ciscos and then only on in the remote - no
change
Any ideas ?
Regards
Michael
|
| 7090.6 | | REGENT::WOLF | | Tue Feb 25 1997 16:54 | 5 |
| Do you have any IP knowledgable nodes that you could place in the same
LAN as the PrintServer and attach to the PrintServer using PRISM?
I'd love to know what addresses the printer thinks it has.
jeff
|