From: Didi on
I tried today to figure out a simple way to give users of our
new netmca ( http://tgi-sci.com/tgi/nmcatb.htm ) to locate its
IP address once it gets one via dhcp when there is no internet
at the moment (when there is the device posts its IP to our domain
and customers can see it using a browser).

Turned out there is nothing like an easy way to do that!

There are some utilities which can be used to ping the entire subnet;
then list the arp cache, locate the known MAC address and
see its IP. But these are far from something one would want to ask
customers to deal with, long lists, necessity to search etc. , heck,
it
will generate more calls to me than if I do it for them every time.

In an attempt to solve it I spent 10 minutes adding RARP reply
to our device Ethernet related stuff - so it would reply to an ARP
inquiry #3 by sending its IP address (it only has one); and then spent
perhaps 3 hours googling, moogling, you name it, searching for some
piece of code to do that at the wintel side. Even rebooted the wintel
laptop to ubuntu to try it out from there (thought arp -r or something
would just work), oh no. No way. Spent perhaps half an hour of
moogling for linux rarp, same thing.

How on Earth is that possible?! I can understand how many things
are retarded as one would expect them to be on a x86 based thing,
but this is too simple even for the x86 world.

Any ideas? I have not faced the issue in real life yet (users tend
to have internet) but this is bound to happen and I am looking for
some solution.

Dimiter

------------------------------------------------------
Dimiter Popoff Transgalactic Instruments

http://www.tgi-sci.com
------------------------------------------------------
http://www.flickr.com/photos/didi_tgi/sets/72157600228621276/


From: Nobody on
On Thu, 25 Mar 2010 14:54:42 -0700, Didi wrote:

> I tried today to figure out a simple way to give users of our
> new netmca ( http://tgi-sci.com/tgi/nmcatb.htm ) to locate its
> IP address once it gets one via dhcp when there is no internet
> at the moment (when there is the device posts its IP to our domain
> and customers can see it using a browser).
>
> Turned out there is nothing like an easy way to do that!
>
> There are some utilities which can be used to ping the entire subnet;
> then list the arp cache, locate the known MAC address and
> see its IP. But these are far from something one would want to ask
> customers to deal with, long lists, necessity to search etc. , heck,
> it
> will generate more calls to me than if I do it for them every time.
>
> In an attempt to solve it I spent 10 minutes adding RARP reply
> to our device Ethernet related stuff - so it would reply to an ARP
> inquiry #3 by sending its IP address (it only has one); and then spent
> perhaps 3 hours googling, moogling, you name it, searching for some
> piece of code to do that at the wintel side. Even rebooted the wintel
> laptop to ubuntu to try it out from there (thought arp -r or something
> would just work), oh no. No way. Spent perhaps half an hour of
> moogling for linux rarp, same thing.

I think that you may misunderstand what RARP is. It's similar to BOOTP or
DHCP, but implemented at the link layer (Ethernet) rather than the network
layer (IP). RARP allows a client to determine its own IP address at boot.
It has largely fallen out of favour due to its lack of functionality
compared to BOOTP or DHCP, and the difficulty of implementation (it
requires "raw" ethernet access, cannot be routed, etc).

Essentially, a client broadcasts a RARP request, the RARP server notices
the request, looks up the source MAC address to obtain an IP address, and
sends a RARP reply back to that MAC address.

"Inverse ARP" (InARP) appears to be the reverse of ARP, but it isn't
widely used (I've only just found out about it now, in spite of having
performed a significant amount of both TCP/IP programming and
administration of TCP/IP networks and servers).

InARP is an extension to the ARP protocol, which is normally implemented
within the kernel's networking stack. You may be able to use e.g. netcat
to issue an InARP request and receive the response, provided that you have
sufficient privilege (raw/packet sockets typically require root or
Administrator privilege) and any firewalls don't get in the way.

> Any ideas? I have not faced the issue in real life yet (users tend
> to have internet) but this is bound to happen and I am looking for
> some solution.

If you want to find a device on the network, one option is a NetBIOS-style
"sonar", sending a UDP packet to a specific port on the broadcast address
and listening for replies. But that will only work if the device is on the
same network segment (routers don't normally pass broadcast packets).

You're probably better off just asking the DHCP (or DNS) server where the
device is. Anything else is likely to run afoul of firewall rules or the
like. Nowadays, anything beyond HTTP, SMTP and Windows' own protocols is
likely to be considered suspicious.

From: David Schwartz on
On Mar 25, 2:54 pm, Didi <d...(a)tgi-sci.com> wrote:

> I tried today to figure out a simple way to give users of our
> new netmca (http://tgi-sci.com/tgi/nmcatb.htm) to locate its
> IP address once it gets one via dhcp when there is no internet
> at the moment (when there is the device posts its IP to our domain
> and customers can see it using a browser).
>
> Turned out there is nothing like an easy way to do that!

There are, actually, a lot of ways.

In the Windows world, NMB provides a naming service that maps local
host names to IP addresses. If the computers are set up with NetBIOS
over TCP/IP and you know the host name, you can get the IP address
easily. On Windows, 'gethostbyname' will use the local browse table.

Apple's Bonjour protocol also does this. You can make your service a
zeroconf advertised service. This technology uses multicast DNS.

You can also use your own multicast or broadcast based location
service. A server running your software listens on a UDP broadcast/
multicast port for service discovery requests. A client can then send
a service request and wait for the server to reply. I don't recommend
doing periodic service availability broadcasts for your custom
protocol unless there's a real need.

Another solution is dynamic DNS. Most operating systems support the
ability to register their dynamically-assigned IP addresses in a dDNS
server. Most platforms provide servers with dDNS capability as well.

And, of course, you can just punt on this. Simply state "You need the
IP address of the server to access it. Either configure it statically
or arrange for it put it someplace you can get it." (This is what
pretty much every server already does.)

There are also all kinds of tricks you can do. For example, you can
run a local proxy and use a fixed IP address and port (say
127.1.2.3:8000 or something like that). The proxy binds to that IP and
port and forward requests to the server's current IP addresses,
determining it using any of the above methods.

Is the client running special client software? Or do you need the IP
address to enter into a browser or something like that?

DS
From: Didi on
On Mar 26, 12:48 am, David Schwartz <dav...(a)webmaster.com> wrote:
> ..
> And, of course, you can just punt on this. Simply state "You need the
> IP address of the server to access it. Either configure it statically
> or arrange for it put it someplace you can get it." (This is what
> pretty much every server already does.)

Well yes but many of the customers have no clue beyond basic
browser usage. They will have network support etc. and call them
but I want to prevent the initial frustration they will face
when they don't know how to connect to the device.

It comes with a fixed fallback IP address which they can
subsequently change (I ship it with 192.168.100.last MAC address
byte - not sure why for any part of it, did not give it a long
thought) - but they have to set a static IP address on the
windows system in most cases to be able to access that. In
fact they do and some have reported success, but others would
not even dare to try it out.

> ...
> There are also all kinds of tricks you can do. For example, you can
> run a local proxy and use a fixed IP address and port (say
> 127.1.2.3:8000 or something like that). The proxy binds to that IP and
> port and forward requests to the server's current IP addresses,
> determining it using any of the above methods.

That's too complex... If they can do that they will likely be able
to figure out the IP address the device has, loop ping/ do arp -a
or look into the router tables and see what IP it gave to this MAC
etc.

> Is the client running special client software? Or do you need the IP
> address to enter into a browser or something like that?

Pretty much the latter, although usually it is not a browser
but an RFB (VNC) client. If only there were a command line in
the MSDOS window like arp -r <MAC address> which would then do
inverse ARP and list the result I guess I would be fine but...

Dimiter

------------------------------------------------------
Dimiter Popoff Transgalactic Instruments

http://www.tgi-sci.com
------------------------------------------------------
http://www.flickr.com/photos/didi_tgi/sets/72157600228621276/

Original message: http://groups.google.com/group/comp.arch.embedded/msg/df514407e21d7002?dmode=source



From: Didi on
On Mar 26, 12:38 am, Nobody <nob...(a)nowhere.com> wrote:
> ...
> I think that you may misunderstand what RARP is.

Well no, I read the related RFCs, and I read about inarp too.
I think rarp also allows doing what I want (not quite sure)
but even if it does not there is no problem misusing it for
the purpose. Then I could include inarp reply as well, it is
almost the same thing.
The packet is the same as ARP only with a different type
field; and only the known/unknown fields are the other
way around, that is, the replying host fills in the IP
field (which has come as 0) rather than its MAC field
(which has come valid - non broadcast and non-0).
That's all, adding the reply took me just a few minutes
(4-5 lines of code... :-) ).

But there is just no simple to use utility which would
trigger that response from my device and list the result...

> You're probably better off just asking the DHCP (or DNS) server where the
> device is. Anything else is likely to run afoul of firewall rules or the
> like. Nowadays, anything beyond HTTP, SMTP and Windows' own protocols is
> likely to be considered suspicious.

Oh no, no firewall issues. Or if there are any I would just not go
into that, I'll say "if you have no internet disengage your firewall
before you proceed" and that's it. This is only about the local
subnet, if
there is internet I am fine, they use a bookmark in their browser
and see the IP of interest (which the device has written there on
boot time over the internet).

Dimiter

------------------------------------------------------
Dimiter Popoff Transgalactic Instruments

http://www.tgi-sci.com
------------------------------------------------------
http://www.flickr.com/photos/didi_tgi/sets/72157600228621276/

Original message: http://groups.google.com/group/comp.arch.embedded/msg/0d9a6b277ddf7039?dmode=source