Howto find misconfigured Digi Portserver on the lan w/o Xwindows?

In news:139tfhnr5m6n95d@corp.supernews.com,
Frank Winans <fwinans@sbcglobal.net> wrote:

....
> and have them try stuff like changing the linux server to odd
> settings like inventing a class "A" address 192.0.0.1 for the server
> for the test runs, ...

That address belongs to isi.edu. Use only the reserved non-routable
addresses found in http://www.faqs.org/rfcs/rfc1918.html such as 10/8,
192.168/16 and 172.16/12 .

I was admiring the rhel5 wireshark packet-sniffer of rhel5 the other day,
and in fact used it to find the netmask settings of a portserverII box
{seems at power-on it sends out some arp query 'who owns this ip address?'
to see if his ip address is already in use on the LAN}

Erm, wireshark was formerly called ethereal, by the way...

Anyway, I really liked it, but many times I'm ssh'd in to a remote client,
and really, really don't want to hassle with setting up a graphical environment,
so I'm like stuck using text-based tools like nmap.

Is there some way I can warp a linux box to seek out portservers on the LAN,
given I don't know what subnet they've been set up as? This scenario is the
remote customer getting a new linux server, but using old digi portserverII
boxes. If it helps I could have a voiced phone call with an on-site minion,
and have them try stuff like changing the linux server to odd settings like
inventing a class "A" address 192.0.0.1 for the server for the test runs,
but the minions I know would 'freak out' at using Xwindows, though they are
comfortable with doing vi sessions... Oddly enough, they're also reluctant
to plug a serial terminal into the portserver so I can have them issue commands
at a serial terminal to view/reconfigure the portserver.

This doesn't come up often, but when it does the client is like hundreds of miles
away. Oh, and I know the mac address of the portserver -- both from records
and from the little paper sticker that is usually still present from the factory...

I got spoiled working with dlink pocket print servers -- you could just read the
mac address off the sticker, use any old winbox to set up an arp table entry for
that and telnet to the dummied-in ip address from that arp command. Doesn't
work for portservers...

"Frank Winans" wrote
> Is there some way I can warp a linux box to seek out portservers on the LAN,
> given I don't know what subnet they've been set up as? This scenario is the
> remote customer getting a new linux server, but using old digi portserverII
> boxes.

tcpdump -t -i eth0 -n -l arp will show three copies of message like
arp who-has 192.168.12.109 tell 192.168.12.109
when the digi portserverII reaches "AC" status on front-panel LEDs.
My windows 2000 box is hardcoded to 192.168.0.10 and also coughs up
three of arp who-has messages when I reenable that nic interface, so that's a
source of sample data before you have your minion go cycle power on the portserver.
SIGINT {probably Control-C} terminates the tcpdump command, by the way.

The man pages aren't kidding -- it seems like standard output is suppressed if you try
piping the tcpdump into another command without using the tcpdump '-l' arg!

Those args above eth0 as in eth{zero} & -l as in lowercase(-L)

"Gretch" wrote
> Frank Winans wrote:
>
> ...
> > and have them try stuff like changing the linux server to odd
> > settings like inventing a class "A" address 192.0.0.1 for the server
> > for the test runs, ...
>
> That address belongs to isi.edu. Use only the reserved non-routable
> addresses found in http://www.faqs.org/rfcs/rfc1918.html such as 10/8,
> 192.168/16 and 172.16/12 .
>
Two things; a) you're right, 192/8 was a bad plan,
and b) I had envisioned an air gap around their LAN during testing.

When you need promiscuous mode, using a shorty netmask is a rotten substitute.

Is anybody using ipv6 much? I'm already tired of typing a line
net-pf-10 off
into /etc/modprobe.conf every time I do a Redhat rhel5 install so my
ifconfig -a
output will omit the sit0 interface, and fit on one screenfull...

"Frank Winans" schrieb
>
> [...]
> I got spoiled working with dlink pocket print servers -- you could
> just read the mac address off the sticker, use any old winbox to
> set up an arp table entry for that and telnet to the dummied-in ip
> address from that arp command.
>
This also works for linux, BTW. No need for a winbox.

>
> Doesn't work for portservers...
>
Why? And even if yes, it's a problem of the portserver, not
of linux. You're barking up the wrong tree.


Regards
Martin

"Martin Blume" wrote
> "Frank Winans" schrieb
> >
> > [...]
> > I got spoiled working with dlink pocket print servers -- you could
> > just read the mac address off the sticker, use any old winbox to
> > set up an arp table entry for that and telnet to the dummied-in ip
> > address from that arp command.
> >
> This also works for linux, BTW. No need for a winbox.
True, but nice to know you can do it with any nearby winbox
instead of walking across campus to the linux server(s).
>
> >
> > Doesn't work for portservers...
> >
> Why? And even if yes, it's a problem of the portserver, not
> of linux. You're barking up the wrong tree.
>
It would be more precise to say I haven't gotten it to work yet.
I'm pretty sure it was because my computer was in 192.168.0.something
and the portserverII was, as luck would have it, on 192.168.13.somethingelse
with a 255.255.255.0 netmask. Seems portservers don't _do_ promiscous...
I'd enjoy knowing how to sleuth this 'unknown subnet' problem other than
using tcpdump -n -l arp and cycling power on the portserverII, given that
X is often not readily available to us, and serial devices awkward to recable...
>
> Regards
> Martin
>
>