hpnp and ipfilter issue?
Carl Sopchak
I have a client that's using hpnp to print to a JetDirect box. I
recently installed ipfilter, since they got a DSL connection, as
"extra protection". (There's more to it than that, but it's not
important here...) When I first installed ipfilter, I had an issue
with hpnp printing. I fixed that problem, but, stupidly, didn't write
down exactly what I did. I *thought* I changed the spec file that I
created for ipfilter's use on reboot to allow what's necessary
through.
Yesterday, after over a month of trouble-free operation, the client
had a power outage. When the SCO OSR 5.0.5 box came back up, hpnp
wouldn't print. I'm not sure if some hardware got fried, or if I
missed updating the ipfilter config.
The ipfilter config is as follows:
pass in quick on net0 proto tcp/udp from 192.168.0.0/24 to
192.168.0.0/24
pass in quick on net0 proto icmp from 192.168.0.0/24 to 192.168.0.0/24
block in on net0 all
I thought it was the second line (icmp) that did it for me when I
originally set it up. Maybe not...
The host and printer are configured for 192.168.0.1 and 192.168.0.3,
respectively, with netmask 255.255.255.0.
Trying to ping the printer's ip gives 'Host is down'. We power cycled
the JetDirect box, but that didn't help. The activity light on the
JetDirect flashes when the ping is running. (I'm not sure if that
means much...)
I tried using arp -s to map the IP to the MAC, but ping then just
seemed to hang (no output). arp -an shows 192.168.0.3 at
"(incomplete)"... Also, I can't ping 192.168.0.3 from any of the
machines on the LAN.
My gut is telling me it's ipfilter, but after three hours of searching
for what needs to be changed, I can't for the life of me figure out
what's missing. Anyone have any ideas?
Thanks for the help,
Carl
Scot Harkins
news:c12f3009.03011...@posting.google.com...
> OK, I feel dumb now...
We all get that. Welcome to humanity.
> ...
>
> Trying to ping the printer's ip gives 'Host is down'. We power cycled
> the JetDirect box, but that didn't help. The activity light on the
> JetDirect flashes when the ping is running. (I'm not sure if that
> means much...)
>
> I tried using arp -s to map the IP to the MAC, but ping then just
> seemed to hang (no output). arp -an shows 192.168.0.3 at
> "(incomplete)"... Also, I can't ping 192.168.0.3 from any of the
> machines on the LAN.
There's your key. No other system on the LAN can ping it. ipfilter doesn't
affect other systems on the LAN, meaning it cannot stop one device from
pinging another device on the same LAN. It cannot stop another system from
pinging the JD box on the same LAN segment.
Have you checked the settings on the JD box? Might the power problem have
damaged or reset the JD to factory? Print out a config from the JD. Press
the test button on the JD box and the config sheet will print. If it
doesn't print then you may well have a problem with the JD, meaning you'll
have to follow up on it first to make sure it's okay.
The activity light flashes on the JD because of LAN traffic. It's
non-specific; any LAN traffic will cause it to flicker with the traffic.
It's hopeful that you have a link, assuming you have a link light on both
the JD and the port on the hub into which it is plugged.
If the config sheet prints out with some oddball IP address then it's
probably been reset to factory. It's problematic that adding an arp entry
causes ping to hang; almost sounds like the JD has a near-miss config and
perhaps it's trying to send the reply packets to the gateway (if it knows
about a gateway) rather than the system sending the ping on the LAN.
After you added the MAC in arp (arp -s [ip addr] [MAC addr] temp) 'arp -a'
should show the MAC with the IP. If not then you missed on the arp command.
Once you get it set then it will not matter what IP address the JD has,
unless it's got a gateway and the metric works out as though you're on the
other side of the gateway.
sh
--
Scot Harkins (KA5KDU)
Greenbank, WA
360-678-5880
sc...@bigfoot.com
http://www.bigfoot.com/~scoth
Tony Lawrence
> OK, I feel dumb now...
Welcome :-)
>
> I have a client that's using hpnp to print to a JetDirect box. I
> recently installed ipfilter, since they got a DSL connection, as
> "extra protection". (There's more to it than that, but it's not
> important here...) When I first installed ipfilter, I had an issue
> with hpnp printing. I fixed that problem, but, stupidly, didn't write
> down exactly what I did. I *thought* I changed the spec file that I
> created for ipfilter's use on reboot to allow what's necessary
> through.
I think Scott Harkins covered the important points here (check the
actual JD config) but I do want to add that HPNP printing isn't worth
the trouble: use netcat (
http://aplawrence.com/SCOFAQ/scotec7.html#getnetcat )
--
Tony Lawrence
Free SCO and Linux Skills Tests: http://aplawrence.com/skillstest.html
Tom Parsons
| OK, I feel dumb now...
|
| I have a client that's using hpnp to print to a JetDirect box. I
| recently installed ipfilter, since they got a DSL connection, as
| "extra protection". (There's more to it than that, but it's not
| important here...) When I first installed ipfilter, I had an issue
| with hpnp printing. I fixed that problem, but, stupidly, didn't write
| down exactly what I did. I *thought* I changed the spec file that I
| created for ipfilter's use on reboot to allow what's necessary
| through.
If it was working before the reboot, it will be working after the reboot
unless:
you didn't restart ipf with the latest ruleset
your ipf startup script calls a different ruleset
Included in the the ipf family is ipmon. It is your friend. Start it
running, change your ipf rules to log various rules and diagnose it
yourself. This ipmon script startup ignores ipnat and state entries.
/etc/ipmon -o I /usr/adm/ipf.log &
--
==========================================================================
Tom Parsons t...@tegan.com
==========================================================================
Jeff Liebermann
Sopchak) wrote:
>I have a client that's using hpnp to print to a JetDirect box.
Which model? Different models have different bugs.
>When I first installed ipfilter, I had an issue
>with hpnp printing. I fixed that problem, but, stupidly, didn't write
>down exactly what I did.
The JetDirect box is a print "server". It wants to talk to your OSR5
server. Port 9100, 9101, 9102 are the common IP ports for HPNP.
Also, OSR5 needs status information from the print server using SNMP
on port 160. There's a list port numbers that need to be open at the
bottom of:
http://www.cruzio.com/~jeffl/sco/lp/printservers.htm
However, almost all these ports involve connections that are outgoing
from the OSR5 server. IPFilter allows all out going ports, so that
should not be a problem here. It's not IPFilter.
>I *thought* I changed the spec file that I
>created for ipfilter's use on reboot to allow what's necessary
>through.
Assumption, the mother of all screwups.
Check thy assumptions.
>Yesterday, after over a month of trouble-free operation, the client
>had a power outage. When the SCO OSR 5.0.5 box came back up, hpnp
>wouldn't print.
The default configuration of the unspecified HP JetDirect box is to
get its IP address via DHCP. Some of the early models also use bootp
if that's unavailable. Punch the test button on your unspecified
print server and see if the test print shows that it has an IP
address. If not, telnet or use a web browser to set the IP address to
whatever is specified in /etc/hosts for the printer. You should NOT
be using DHCP or bootp to assign IP addresses of fixed devices
(printers, routers, gateways, etc). If the IP address changes every
time you have a power failure, you'll have a repetition of this
exercise.
>Trying to ping the printer's ip gives 'Host is down'. We power cycled
>the JetDirect box, but that didn't help. The activity light on the
>JetDirect flashes when the ping is running. (I'm not sure if that
>means much...)
Punch the test button. I'm guessing it's a 170x or 300x. You should
get a test page. No IP address, no talk.
>I tried using arp -s to map the IP to the MAC, but ping then just
>seemed to hang (no output). arp -an shows 192.168.0.3 at
>"(incomplete)"... Also, I can't ping 192.168.0.3 from any of the
>machines on the LAN.
If other machines can't ping the unspecified jetdirect box, then it's
either at a different address, fried, misconfigured, or disconnected.
I spent an hour fighting something similar. When I finally power
cycled the switch (or hub) that was in between the servers and the
JetDirect box, everything magically recovered. Like I said, check thy
assumptions.
--
Jeff Liebermann 150 Felker St #D Santa Cruz CA 95060
(831)421-6491 pgr (831)336-2558 home
http://www.LearnByDestroying.com WB6SSY
je...@comix.santa-cruz.ca.us je...@cruzio.com
Carl Sopchak
Printing the test page (which I was unaware of) told me all I needed
to know. The JD (model 170X, BTW) was using DHCP to configure the IP,
and was going to a "new" DHCP server on the LAN. (Actually, it was an
old server, but a new connection between two logical LANs in the
building.) Once I got the IP address of the JD box, I telnet'ed to
it, turned off DHCP, set the IP, netmask, and gateway, and off we
went!
Just for the record...
It is my belief (and I'm not going to go through the steps to prove
it, since the client is an hour's drive away, and they won't pay me
for the time) that the JD box had been using BOOTP to configure
itself. Perhaps the power outage switched a configuration setting
here, I don't know. (It's been over 2 years since it was originally
set up.) My original post, in mentioning ipfilter, was really
questioning if ipfilter might be blocking BOOTP. Then again, maybe I
did some manual configuration when I set the JD up originally. (I'm
getting MUCH better at keeping track of such things these days <g>!)
I didn't think the JD activity light was JD-specific activity, but
thought I'd ask...
Since the hpnp has been working for years, I don't think I'll play
with netcat in this case. I will keep it in mind in the future,
though...
Thanks again to all for the help.
Carl
carl.s...@cegis123.com (Carl Sopchak) wrote in message news:<c12f3009.03011...@posting.google.com>...
> OK, I feel dumb now...
>
Not so much, any more <g>...
Jeff Liebermann
Sopchak) wrote:
>It is my belief (and I'm not going to go through the steps to prove
>it, since the client is an hour's drive away, and they won't pay me
>for the time) that the JD box had been using BOOTP to configure
>itself.
No remote access? Yech. If this is a Windoze network, look into
using NetMeeting for remote control. It's free.
>Perhaps the power outage switched a configuration setting
>here, I don't know. (It's been over 2 years since it was originally
>set up.)
Look at the file:
/etc/bootptab
If the MAC address for the printe server is in there, then it was
setup with bootp. If it's empty, it wasn't bootp.
Carl Sopchak
> On 13 Jan 2003 08:03:40 -0800, carl.s...@cegis123.com (Carl
> Sopchak) wrote:
>
> >It is my belief (and I'm not going to go through the steps to prove
> >it, since the client is an hour's drive away, and they won't pay me
> >for the time) that the JD box had been using BOOTP to configure
> >itself.
>
> No remote access? Yech. If this is a Windoze network, look into
> using NetMeeting for remote control. It's free.
I've got remote access (via Tarantella - nice product, but not free...)
>
> >Perhaps the power outage switched a configuration setting
> >here, I don't know. (It's been over 2 years since it was originally
> >set up.)
>
> Look at the file:
> /etc/bootptab
> If the MAC address for the printe server is in there, then it was
> setup with bootp. If it's empty, it wasn't bootp.
It's the info in /etc/bootptab that makes me believe that it was using BOOTP...
Anyway, it's working now that I set it to use a static IP.
Thanks again for the help...
Carl