1. Home
  2. Electronics Design
  3. Flexible topology for RFC 1918 addressing
  4. Page 2

Flexible topology for RFC 1918 addressing

The problem is this sort of environment is "too unusual".

I.e., if you put the DUT on the same switch as your "console" (wherever *you* are trying to interact with the device), then your IP, the IP of the (managed) switch and the IP's of every other device on the switch pollute the address space of the DUT (*it* can't conflict with any of those... but, you don't know what *it* is using -- or wanting to use -- yet!).

It exposes all of those devices to the DUT -- including, potentially, your outbound connection.

It requires you to have a DHCP/BOOTP service running on some device that is connected to that switch (in case the DUT goes looking for a lease).

If the DUT happens, coincidentally, to be using the same IP as the machine from which you are connecting, then some form of address translation is required (assume you can hide all the other hosts to minimize the number of potential conflicts -- that's what my "two device network" does).

You (or some other host on that switch) have to be capable of performing network discovery (which can require several different approaches based on what the DUT supports, protocol wise) if the device has already chosen an IP.

And, I've not even addressed IPv6! :-/

So, it seems the most effective ("safe") approach is to install a proxy that *I* can talk to (or any other node on *my* switch) and have it play the role of the "laptop" in the "two device network" that I mentioned originally. I.e., just take the display and keyboard *off* that "virtual laptop" and move them to wherever I happen to be sitting, currently.

E.g., maybe just let something like nessus hammer away at the DUT "in isolation" and see what *it* has to say...

Reply to
Don Y
Loading thread data ...

Nor

request

translation

own use?).

term.

system

I believe you might be right. When all those **** things use wireless to keep the masses happy it gets radically worse. On the upside it will force the devices to have proper DHCP stacks.

I recommend that you build your own gateway for these things.

*you*

(managed)

address

don't know

your

Per my above expectation. After all, part of its job is to call home.

machine

Your main net being on 10/8 may avoid most of that as these DUTs will tend to be in 192.168/16.

chosen

Private gateway. Sounds like a useful approach.

And perhaps wireshark as well.

?-)

Reply to
josephkk

It would be *so* much easier if everything had a real (built-in) "console" instead of relying on some external device (e.g., "terminal") to provide the user interface. Then, you could configure the device

*before* you had to "talk to it".

There are a wide variety of devices that I am addressing. Many "appliances" don't phone home as part of their default operation. But, typically *do* provide a link on the web interface that they serve up that does that "on demand".

That is *usually* the case. However, I've been bitten at least once by something residing on my local subnet "unexpectedly".

Most of the devices that are wireless capable can have their radios turned off so that's not as big an issue for this particular set of devices I'm addressing.

I've considered painting (at least) one room in the house with aliminized paint to block RF. But, I can't imagine how you could ever *remove* (undo) this. Imagine someone trying to use a cell phone (in an emergency) and having their signal blocked...

Reply to
Don Y

to

"console"

For crying out loud. Asking console free devices to have console ports? No vendor is going to provide a less than trivially easy to use serial port console instead of a web page these days. Just because it is easy for you does not make it reasonable for other users or manufacturers.

?-)

Reply to
josephkk

I'm merely pointing out the consequences of using an in-band control channel that isn't flexibly preconfigured.

An *equally* effective solution is to allow that channel to be accessed using a DEVICE SPECIFIC mechanism. As MAC's *are* unique to each device, an addressing scheme that relied *solely* on MAC address ("press button to reset current configuration") would suffice. Unfortunately, this option isn't universally available.

Reply to
Don Y

Then it's easy enough to provide Telnet ( or ssh where appropriate ) service.

If the device is "lost" - has no known IP - then make sure the MAC address is on a sticker and use RARP.

--
Les Cargill
Reply to
Les Cargill

Or *any* (RARP is obsolescent) protocol that UNIQUELY identifies a particular device (BOOTP, DHCP, etc.). This can only be done with MAC addresses (assuming they play by the rules). Every device should have a means (RESET button) by which they can be forced to accept an *imposed* IP address instead of "picking their own default IP".

This really isn't hard to implement -- if you've taken the trouble to implement a stack (even just UDP!), then these are relatively lightweight additions.

A more interesting issue is *forcing* a device to accept a particular IP address. I.e., the aforementioned protocols expect the device to *request* one... how do you "make it" request one if it doesn't think it *needs* one??

(i.e., in the above scenario, how do you push the RESET button remotely? This was one of the issues I've had to address in my automation system as the "boxes" aren't usually easily PHYSICALLY accessible)

Reply to
Don Y

RARP won't work.

use MAC-telnet.

or similar MAC-based admin interface. Mikrotic allows MAC based access to their routers.

--
umop apisdn
Reply to
Jasen Betts

Er... I've used it. More than once. There's a client for Windows XP. Been a while to be sure.

What I mean by rarp is something that assigns an IP address to a node through it's MAC address - basically a one-shot DHCP. When last I used it, you had to be connected with a cable, connected through a hub or connected through a switch that is a proper learning bridge and floods unknown traffic properly.

Aha! Very nice. Thanks. I was unaware of that one.

--
Les Cargill
Reply to
Les Cargill

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.