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

This is a discussion on Howto find misconfigured Digi Portserver on the lan w/o Xwindows? - Networking ; 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?' ...

+ Reply to Thread
Results 1 to 6 of 6

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

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

    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...



  2. Re: Howto find misconfigured Digi Portserver on the lan w/o Xwindows?

    In news:139tfhnr5m6n95d@corp.supernews.com,
    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 .


  3. Re: Howto find misconfigured Digi Portserver on the lan w/o Xwindows?

    "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)





  4. Re: Howto find misconfigured Digi Portserver on the lan w/o Xwindows?

    "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...




  5. Re: Howto find misconfigured Digi Portserver on the lan w/o Xwindows?

    "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



  6. Re: Howto find misconfigured Digi Portserver on the lan w/o Xwindows?

    "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
    >
    >




+ Reply to Thread