Reverse or inverse ARP from windows/linux - no way (!?!?)
Didi
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/
Nobody
> 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.
David Schwartz
> 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
Didi
> ..
> 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
Didi
> ...
> 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
glen herrmannsfeldt
(snip)
> 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.
It seems unlikely that RARP will be useful. RARP is from the
days before BOOTP, from which DHCP was derived. RARP was,
at least, used for diskless Sun systems to find their IP address.
The Sun boot ROM would use RARP to find its IP address, then
tftp to load the rest of the boot code. The first thing the
second level boot code does is RARP to find its address.
Then IP based bootparamd to find the rest of the data it needed
to boot, such as the address of its NFS server, and name of
the root file system.
These days, everyone just used DHCP to get an IP address,
either dynamically or statically assigned.
-- glen
Paul Hovnanian P.E.
>
> 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).
>
>
That will solve the dynamic (DHCP assigned) IP address to a DNS entry
that the world can resolve.
--
Paul Hovnanian mailto:Pa...@Hovnanian.com
------------------------------------------------------------------
Life is like an analogy.
David Schwartz
> 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...
You want to sell a physical device that 'just works'. You want it to
connect to a LAN, get its IP by DHCP, and then you want the user to
have some easy way to access the device's built in web server without
having to install or run any special software.
Is that an accurate description of the scenario?
DS
robert...@yahoo.com
> I tried today to figure out a simple way to give users of our
> 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.
Well, you could just install a copy of NMAP on the user's
computer. :-)
More seriously, the usual technique is to supply a small program that
gets the list of interfaces from the OS, and then does a scan from
there.
On Windows, the GetAdaptersInfo() function will quickly get you a list
of all the attached subnets. Then just do something simple to detect
your device - if you can have it respond to a UDP port query, for
example, just scan all those IP addresses for that port (QOTD/UDP is
great for that - just have the quote be "I'm a Widget9000, serial
#1234"*). A smidge more work would be to do it with broadcasts, which
should work for anyone on a typical Ethernet network, although can
have some quirks on less standard connections.
You *could* do that with TCP, but the lengthy timeouts will make that
rather more painful. With UDP, you can just have a bound/listening
socket, and pump the queries out (you should probably throttle that to
no more than a few hundred per second, just to be a nice guy).
A similar approach is possible on *nix. On either system you could
also get the same information from shelling out to ipconfig or
ifconfig, as appropriate, and then parsing the output.
If your device supports SNMP, you can use that, although your query
program then gets to process ASN.1, which is always a joy.
In any case, you could wrap that in an HTML page or two (all of which
would be stored on the user’s machine). Use Javascript to actually
run your scanner program (prompt the user to respond “OK” to the
security message), and have the result be a list of links to candidate
devices.
*Just don’t use that exact string – there’s at least one device in the
world that already uses that exact string (well, almost – the above
“9000” and “1234” have been changed to protect the excessively literal-
minded). I wrote the spec for a client, they passed it on to their
offshore development team, a year later I’m looking at the code, and I
notice that string embedded in the code – sure enough, that’s what the
device sends… Where’s that rolling-eyes-smiley when you need it?
Didi
Yes. And this works fine if the customer has internet, but I know
I won't be lucky all the time...(so far so good, though :-) ).
glen herrmannsfeldt
> I won't be lucky all the time...(so far so good, though :-) ).
Internet or not, most have DHCP, but not all. Many will want
any such devices statically addressed.
If the device has non-volatile memory (usually flash) then
it can store its IP address. DHCP came when diskless machines
had no non-volatile memory other than factory configured ROMs.
(One with the ethernet MAC address in them, another with the boot code.
If not, then you can require DHCP. Many DHCP servers allow one
to configure static assignments based on ethernet MAC address.
If the DHCP server has a log file, then it is easy to find the
recently assigned address. Otherwise, a ping to the broadcast
address for the subnet will find some, but not all, devices.
(They will get ARP entries if they reply to the ping.)
If the device has an LCD or other display, then you can have a
way to find the IP address through the display, and configure
any stored addresses.
-- glen
Didi
> In comp.protocols.tcp-ip Didi <d...@tgi-sci.com> wrote:
> (snip)
>
> > Yes. And this works fine if the customer has internet, but I know
> > I won't be lucky all the time...(so far so good, though :-) ).
>
> Internet or not, most have DHCP, but not all. Many will want
> any such devices statically addressed.
Well yes, but the default state as I ship it is with dhcp on
(attempted) and if it times out fallback to a (re)programmable
fixed IP address. Once they gain VNC access to the device they
can switch dhcp off etc. from a menu and set a static address,
I have no issues with that case.
> If the device has non-volatile memory (usually flash) then
> it can store its IP address. DHCP came when diskless machines
> had no non-volatile memory other than factory configured ROMs.
I know, but this was quite some time ago :-). Now this device
ships with a HDD inside, has an EEPROM, runs a fullblown DPS
and "only" needs tcp/ip access to have a monitor, keyboard and
mouse.
In fact I also offer it without a HDD - the whole DPS + application
software fits in a 2M ROM (most of it being a ROM "disk"), flash
actually. To repost the link to the device page,
http://tgi-sci.com/tgi/nmcatb.htm .
> If not, then you can require DHCP. Many DHCP servers allow one
> to configure static assignments based on ethernet MAC address.
I recently had such an encounter. Wanted to be able to remotely
access the device behind a router and asked the network people
on that site to forward the port of interest. They said it would
take a static IP to do that; I reconsidered and made the device
initiate the connection to my support VNC client which now I
run in passive (listening) mode. Just made the device attempt
it every 20 seconds or so - the user being able to turn that
on/off.
> If the device has an LCD or other display, then you can have a
> way to find the IP address through the display, and configure
> any stored addresses.
Well if it had such a display it could just display its IP
address :-).
But it has not and technically there is no need for one.
Just a tiny windows utility which will send a RARP inquiry to a
MAC address and list the result would do in an internet-less
environment; a browser is enough already if there is 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/424b95a94a446059?dmode=source
Boudewijn Dijkstra
> 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!
Sending a UDP echo (port 7) to a broadcast address and subsequently
receiving information about all of the connected netmca's, is not easy? A
Java applet could do it.
--
Gemaakt met Opera's revolutionaire e-mailprogramma:
http://www.opera.com/mail/
(remove the obvious prefix to reply by mail)
D Yuniskis
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).
OK, to be clear:
- device uses DHCP to acquire an IP from server (somewhere);
- user uses this IP to access web server within device; BUT
- device has no way of conveying that IP to the user.
Presumably, user's aren't smart enough to configure DHCP
server to assign a *known* address to the device?
BOOTPd is not available on the server (same issue)?
Can your device register a name with a DynDNS service?
Assuming you are dealing with Windows users, can you
broadcast a name that folks could access? E.g.,
DimiterXXXX where XXXX is related to the device's
MAC in some obvious way?
(i.e., folks browse the network and then connect to
the "obvious" host that shows up)
Or, is my initial assumption incorrect? :<
markp
"Boudewijn Dijkstra" <sp4mtr4p....@indes.com> wrote in message
news:op.u96mc...@azrael.indes.com...
> Op Thu, 25 Mar 2010 22:54:42 +0100 schreef Didi <d...@tgi-sci.com>:
>> 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!
>
> Sending a UDP echo (port 7) to a broadcast address and subsequently
> receiving information about all of the connected netmca's, is not easy? A
> Java applet could do it.
>
That is what I was going to suggest. Just regularly send your aquired
address via a UDP broadcast packet (say once a second), the bandwidth that
would use is very low.
There is another way, you can actually send arbitrary data in a DHCP_REQUEST
packet. This could contain info about which device type is attempting to
gain an address, and the server could log which addresses have been assigned
to those types. No need for MAC lookups and the like.
Mark
Didi
<sp4mtr4p.boudew...@indes.com> wrote:
> Op Thu, 25 Mar 2010 22:54:42 +0100 schreef Didi <d...@tgi-sci.com>:
>
> > I tried today to figure out a simple way to give users of our
> > 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!
>
> Sending a UDP echo (port 7) to a broadcast address and subsequently
> receiving information about all of the connected netmca's, is not easy? A
> Java applet could do it.
Well "easy" implies no necessity to program the alien system
(windows).
But I may look into the java option, I may have to do it this way.
But I can see mass programming has gone higher level than practical.
Clearly it is a hard thing to do for utility programmers, otherwise
there would be some ARP variety tools out there.
Dimiter
Didi
> Hi Dimiter,
>
> Didi wrote:
> > I tried today to figure out a simple way to give users of our
> > 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).
>
> OK, to be clear:
> - device uses DHCP to acquire an IP from server (somewhere);
> - user uses this IP to access web server within device; BUT
> - device has no way of conveying that IP to the user.
Yes, although usually a VNC server is accessed rather than
a webserver. But there is a small webserver as well, part
of the functionality is accessible via http.
And yes, if there is no internet the device cannot access its
(configurable) home domain to post its IP address there for
user visibility and it has no other means to do that at the
moment.
> Presumably, user's aren't smart enough to configure DHCP
> server to assign a *known* address to the device?
It is not about them being smart enough, many of them just
won't be bothered, have never dealt with that sort of thing
etc.
> BOOTPd is not available on the server (same issue)?
>
> Can your device register a name with a DynDNS service?
>
> Assuming you are dealing with Windows users, can you
> broadcast a name that folks could access? E.g.,
> DimiterXXXX where XXXX is related to the device's
> MAC in some obvious way?
I could do some of these, sure. Have not implemented
any dyndns so far, just the normal DNS thing I needed for
the stack, but it can't be a lot. May be some way out.
Although if it is not widely deployed I will still be
facing the same issue on many locations.
> (i.e., folks browse the network and then connect to
> the "obvious" host that shows up)
Well that's what I tried today at a customer and it
worked. Without having a name for my netMCA; their
network guy had installed there an "Angry IP scanner"
(or similar name) which pinged the subnet in a loop
and listed 6-7 responders; those with names were obvious
(carried the names of people around the lab) and the
two without the names were also obvious, one was the
gateway and the other was the netmca.
Even if not obvious if there are just a few hosts
they can find out which is which by trial and error :-).
So may be I don't have such a huge issue after all,
I'll see how it works out over time before rushing
into it. That's the strategy for now, at least, before
someone screams over the phone "can't see the netmca"...
glen herrmannsfeldt
> 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.
Yesterday, not long after reading this, I was reading about a
device that offers RARP, ARP, BOOTP, and DHCP as ways of assigning
it an IP address.
Looking at the list, I didn't see how they would do it with ARP, but...
(This was suggested for Windows 98.)
arp -s (desired IP address) (device MAC address)
ping (desired IP address)
The device is designed such that when no IP address is assigned
that it looks for such ICMP packets. They could only arrive from
hosts configured with such static ARP entries. Once an address
is assigned (this way, or any other) the device ignores such.
That avoids the problem of no RARP, BOOTP, or DHCP on W98.
-- glen
David Schwartz
> That is what I was going to suggest. Just regularly send your aquired
> address via a UDP broadcast packet (say once a second), the bandwidth that
> would use is very low.
Please don't do that. Instead, listen on a UDP broadcast port for a
UDP broadcast query. You can reply to that query either broadcast or
unicast (just to the querier).
DS
markp
"David Schwartz" <dav...@webmaster.com> wrote in message
news:ec062dee-e5d8-49f2...@u15g2000prd.googlegroups.com...
> DS
Of course, had a bit of a mind freeze there. That's a much more sensible way
of doing it. You still have the question of how often to update the info
because the DHCP server could potentially re-allocate addresses, but with
your enquiry approach an update could be done on demand when needed.
Mark.
Barry Margolin
"Paul Hovnanian P.E." <Pa...@Hovnanian.com> wrote:
> 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).
> >
> >
> Here's an idea: http://en.wikipedia.org/wiki/Dynamic_DNS
>
> That will solve the dynamic (DHCP assigned) IP address to a DNS entry
> that the world can resolve.
Isn't that what he's referring to in the parentheses? He's trying to
find a way to do it when there's no DNS server to update.
--
Barry Margolin, bar...@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***
RockyG
>
>> That is what I was going to suggest. Just regularly send your aquired
>> address via a UDP broadcast packet (say once a second), the bandwidth
>t
>> would use is very low.
>
>Please don't do that. Instead, listen on a UDP broadcast port for a
>UDP broadcast query. You can reply to that query either broadcast or
>unicast (just to the querier).
>
>DS
>
Essentially you give your device a name such as NETMCA123456 where 123456
are the last 6 digits of the mac address, then listen for a broadcast to
UDP port 137. If the query is for NETMCA123456 then it responds with its IP
address.
This only really works on local subnets.
It is supported natively under windows, so VNC from a windows machine
should work fine.
The way it seems to work is that if windows thinks it is a local address
(not sure how that is determined, maybe no '.'s ) then it broadcasts up to
3 NBNS query packets. The netMAC will respond - job done!
On a simple network you don't need to worry about all the server stuff.
To play around, start up Wireshark monitoring UDP port 137 and try to
connect to another machine on the same subnet using its name. Wireshark
should then capture the NBNS sequence.
---------------------------------------
Posted through http://www.EmbeddedRelated.com
Didi
wrote:
Thanks! This may well be it, I'll investigate.
Didi
> I tried today to figure out a simple way to give users of our
> 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 I got to the bottom of it - why this is impossible under
windows, that is.
I had posted the same question in a local (Bulgarian) forum, and today
a guy replied and posted this pointer:
http://en.wikipedia.org/wiki/Raw_socket
Turns out this is just not doable under windows without defeating the
system somehow... hence no such utility.
He says he needed the same thing and wrote himself a GNU/Linux
utility so apparently it is doable there; but I have not located
such a utility in my half hours search (nor do I need it particularly,
most if not all customers run windows and if someone is running
linux chances are he will figure something out without my
assistance.
Here is the topic in the forum (Bulgarian/Cyrillic, most of you
will see just funny characters :-) ):
http://mcu-bg.com/mcu_site/viewtopic.php?t=7680
markp
> I think I got to the bottom of it - why this is impossible under
> windows, that is.
> I had posted the same question in a local (Bulgarian) forum, and today
> a guy replied and posted this pointer:
> http://en.wikipedia.org/wiki/Raw_socket
Raw sockets is the ability to bypass the encapsulation of the lower level
OS. All you need to do is send a legitimate UDP broadcast 'enquire' packet
and receive uni-cast replies, I can't see why you would want to create your
own raw packets and why you can't just use the OS to encapsulate your data
normally (?)
Mark.
markp
"markp" <map.n...@f2s.com> wrote in message
news:81ac4a...@mid.individual.net...
http://msdn.microsoft.com/en-us/magazine/cc163648.aspx
Mark.
Didi
So how do you send an ARP packet via UDP? (FYI: ARP is lower level
than UDP).
Dimiter
markp
"Didi" <d...@tgi-sci.com> wrote in message
news:c89e214e-efb8-43f5...@i25g2000yqm.googlegroups.com...
> Dimiter
I may have got this wrong, but I thought you wanted to find the address of a
newly connected web-server on a local network and be able to configure a
browser to access it. In which case all that is needed is to do is run a
small utility on the browser PC that sends a UDP broadcast packet, the data
portion of which contains the PC's IP address. The client, which has been
allocated an address by the DHCP server, sees the UDP broadcast packet, and
responds by uni-cast to the given address with *its* adddress in the data
portion. The utility displays that address, which the user can either copy
into the browser or click as a hyperlink. Why do you need ARP??
Mark.
JosephKK
APR lower level than UDP? I don't think so. Same level at best, below UDP
is MAC and PHY only.
Philip Paeps
And where does IP go in your world?
- PhiliP
--
Philip Paeps Please don't email any replies
phi...@paeps.cx I follow the newsgroup.
Didi
Uhm, not so sure. Same level as UDP in that they both have the
Ethernet
protocol type set to "internet", perhaps; but the data inside a UDP
packet
are encapsulated into that level, whereas the ARP data are purely
Ethernet
encapsulated. This should put it one level lower - at least
unofficially?
Dimiter
Didi
> "Didi" <d...@tgi-sci.com> wrote in message
>
> news:c89e214e-efb8-43f5...@i25g2000yqm.googlegroups.com...
> On Mar 29, 4:00 am, "markp" <map.nos...@f2s.com> wrote:
>
>
>
> > > I think I got to the bottom of it - why this is impossible under
> > > windows, that is.
> > > I had posted the same question in a local (Bulgarian) forum, and today
> > > a guy replied and posted this pointer:
> > >http://en.wikipedia.org/wiki/Raw_socket
>
> >> Raw sockets is the ability to bypass the encapsulation of the lower level
> >> OS. All you need to do is send a legitimate UDP broadcast 'enquire'
> >> packet
> >> and receive uni-cast replies, I can't see why you would want to create
> >> your
> >> own raw packets and why you can't just use the OS to encapsulate your
> >> data
> >> normally (?)
>
> >> Mark.
> > So how do you send an ARP packet via UDP? (FYI: ARP is lower level
> >than UDP).
> > Dimiter
>
> I may have got this wrong, but I thought you wanted to find the address of a
> newly connected web-server on a local network and be able to configure a
> browser to access it.
No no, you are correct on that. I was just looking for some readily
available utility, I avoid wintel programming like the plague, just
the thought of their APIs etc. stuff makes me sick.
> In which case all that is needed is to do is run a
> small utility on the browser PC that sends a UDP broadcast packet, the data
> portion of which contains the PC's IP address.
That "angry IP scanner" I found is doing something similar (uses ICMP
echo) and does the job for small networks. For large ones it will be
less practical to manually dig through a huge list, though...
Dimiter
Didi
Or may be I forgot that, $806 was ARP and $800 was internet so may be
they are officially different - Oh no, I may be dealing with their
hex dumps and I may have implemented them but I really would not argue
about the official side of things :-) .
I know my stack handles the ARP packets at the same level as IP
packets,
UDP is one level "higher".
Dimiter
markp
>> I may have got this wrong, but I thought you wanted to find the address
>> of a
>> newly connected web-server on a local network and be able to configure a
>> browser to access it.
> No no, you are correct on that. I was just looking for some readily
>available utility, I avoid wintel programming like the plague, just
>the thought of their APIs etc. stuff makes me sick.
>> In which case all that is needed is to do is run a
>> small utility on the browser PC that sends a UDP broadcast packet, the
>> data
>> portion of which contains the PC's IP address.
>That "angry IP scanner" I found is doing something similar (uses ICMP
>echo) and does the job for small networks. For large ones it will be
>less practical to manually dig through a huge list, though...
>Dimiter
Ahha, you're after some already existing software to map MAC addresses to IP
addresses.
If you open a command box in XP and type 'arp -a' you get a list of MAC
addresses and their associated IP addresses. Is that what you want? you
could easily write a batch file to scan for a given MAC address or dump to a
file to search.
Mark.
glen herrmannsfeldt
(snip, someone wrote)
>> No no, you are correct on that. I was just looking for some readily
>>available utility, I avoid wintel programming like the plague, just
>>the thought of their APIs etc. stuff makes me sick.
> Ahha, you're after some already existing software to map MAC
> addresses to IP addresses.
> If you open a command box in XP and type 'arp -a' you get a list of MAC
> addresses and their associated IP addresses. Is that what you want? you
> could easily write a batch file to scan for a given MAC address or dump to a
> file to search.
Some will respond to a ping to the broadcast address, others not.
It seems that it you want to be found then you should respond.
Then you can ping to the broadcast address, followed by arp -a
to see who replied.
-- glen
glen herrmannsfeldt
> On Mar 29, 7:37?am, "JosephKK"<quiettechb...@yahoo.com> wrote:
(snip)
>> APR lower level than UDP? ?I don't think so. ?Same
>> level at best, below UDP is MAC and PHY only.
> Uhm, not so sure. Same level as UDP in that they both have the
> Ethernet protocol type set to "internet", perhaps; but the
> data inside a UDP packet are encapsulated into that level,
> whereas the ARP data are purely Ethernet encapsulated.
> This should put it one level lower - at least unofficially?
MAC at layer 2 (ethernet switch level), IP at layer 3,
TCP and UDP at layer 4.
Sometimes I think that ICMP should be layer 4 (as in ping),
other times in layer 3. It does go inside an IP packet.
ARP does not have the IP (X'0800') ethernet type, so it
seems that it should also be layer 3.
-- glen
Boudewijn Dijkstra
<g...@ugcs.caltech.edu>:
Some will even respond differently to the subnet broadcast address (e.g.
192.168.0.255) than the global broadcast address (255.255.255.255).
Didi
<sp4mtr4p.boudew...@indes.com> wrote:
> Op Mon, 29 Mar 2010 17:10:34 +0200 schreef glen herrmannsfeldt
> <g...@ugcs.caltech.edu>:
>
> > (snip, someone wrote)
>
> > Some will respond to a ping to the broadcast address, others not.
>
> Some will even respond differently to the subnet broadcast address (e.g.
> 192.168.0.255) than the global broadcast address (255.255.255.255).
>
Hmm, do you still think it is "simple" (just kidding :-)).
The necessity to poll, ping the entire subnet etc. nonsense summarizes
what todays PC programming has become.
Instead of simply sending a single packet to a known destination and
use the single packet reply, why not send a few hundred or, better, a
few
thousand of them (the latter is the case when we would really need it
to
work, of course :-) ), then sift through the replies...
Andrew Smallshaw
> I tried today to figure out a simple way to give users of our
> 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).
CDP comes to mind as one option with allows any connected device
to advertise its identity and IP address on the local subnet. I'm
aware that it has at least in theory been superceded by LLDP but
I have no experience of that, and CDP is very simple whereas LLDP
_may_ be more complex. It's primarily a Cisco protocol but it is
documented and clients and viewers are available for Unix and
Windows machines.
--
Andrew Smallshaw
and...@sdf.lonestar.org
markp
On Mar 29, 6:32 pm, "Boudewijn Dijkstra"
<sp4mtr4p.boudew...@indes.com> wrote:
> Op Mon, 29 Mar 2010 17:10:34 +0200 schreef glen herrmannsfeldt
> <g...@ugcs.caltech.edu>:
>>
>> In comp.protocols.tcp-ip markp <map.nos...@f2s.com> wrote:
>> (snip, someone wrote)
>>
>> Some will respond to a ping to the broadcast address, others not.
>>
>> Some will even respond differently to the subnet broadcast address (e.g.
>> 192.168.0.255) than the global broadcast address (255.255.255.255).
>>
> Hmm, do you still think it is "simple" (just kidding :-)).
:-)
OK, the ARP way sounds like you've got to send a ping first to establish the
route. However, since the only things you are worried about are your
web-servers you can guarantee they respond to that as you would have
programmed them too. As an aside, wouldn't the DHCP server when allocating
addresses in the first place do that automatically?
The original idea of sending a UDP broadcast enquiry packet and getting
replies is quite simple though. Only your servers would reply, and you could
even send the desired server's MAC address in the enquiry packet so only one
device that matches it would respond.
Mark.
Didi
> "Didi" <d...@tgi-sci.com> wrote in message
>
> news:851c373c-9078-4880...@g19g2000yqe.googlegroups.com...
> On Mar 29, 6:32 pm, "Boudewijn Dijkstra"
>
> <sp4mtr4p.boudew...@indes.com> wrote:
> > Op Mon, 29 Mar 2010 17:10:34 +0200 schreef glen herrmannsfeldt
> > <g...@ugcs.caltech.edu>:
>
> >> In comp.protocols.tcp-ip markp <map.nos...@f2s.com> wrote:
> >> (snip, someone wrote)
>
> >> Some will respond to a ping to the broadcast address, others not.
>
> >> Some will even respond differently to the subnet broadcast address (e.g.
> >> 192.168.0.255) than the global broadcast address (255.255.255.255).
>
> > Hmm, do you still think it is "simple" (just kidding :-)).
>
> :-)
>
> OK, the ARP way sounds like you've got to send a ping first to establish the
> route.
Nope. Just a single ARP packet type 3 (if RARP misused, not sure
which it has to be for inarp - but same thing) to the known MAC
destination, which will reply in a single packet to the originating
MAC address. No loop, no broadcast involved.
> However, since the only things you are worried about are your
> web-servers you can guarantee they respond to that as you would have
> programmed them too. As an aside, wouldn't the DHCP server when allocating
> addresses in the first place do that automatically?
If you mean would not everyone on the subnet be aware of everyone
elses
IP & mAC address data by snooping the dhcp, then no. Only the dhcp
request is broadcast, the rest goes peer to peer (and may well be
invisible
to much of the subnet even in promiscuous mode).
> The original idea of sending a UDP broadcast enquiry packet and getting
> replies is quite simple though. Only your servers would reply, and you could
> even send the desired server's MAC address in the enquiry packet so only one
> device that matches it would respond.
Yes, of course it is simple. I just want to use the wintel PC's as
TV-sets (i.e. I am not delivering any software for them, my software
runs under DPS on the device). In fact this works so far, I am just
preparing for the day I have this issue at a customers site.
Dimiter
(the thread got lengthy, here is a third link to the device we
are talking about: http://tgi-sci.com/tgi/nmctb.htm )
robert...@yahoo.com
wrote:
> In comp.protocols.tcp-ip Didi <d...@tgi-sci.com> wrote:> On Mar 29, 7:37?am, "JosephKK"<quiettechb...@yahoo.com> wrote:
>
> (snip)
>
> >> APR lower level than UDP? ?I don't think so. ?Same
> >> level at best, below UDP is MAC and PHY only.
> > Uhm, not so sure. Same level as UDP in that they both have the
> > Ethernet protocol type set to "internet", perhaps; but the
> > data inside a UDP packet are encapsulated into that level,
> > whereas the ARP data are purely Ethernet encapsulated.
> > This should put it one level lower - at least unofficially?
>
> MAC at layer 2 (ethernet switch level), IP at layer 3,
> TCP and UDP at layer 4.
>
> Sometimes I think that ICMP should be layer 4 (as in ping),
> other times in layer 3. It does go inside an IP packet.
An ARP packet looks absolutely nothing like an IP packet.
> ARP does not have the IP (X'0800') ethernet type, so it
> seems that it should also be layer 3.
ARP, in most senses, is not technically part of the TCP/IP stack at
all, except that it's needed by some types of links. No more than
Ethernet is really a part of TCP/IP (although it is used by many
implementations). While ARP is defined in an RFC, there's plenty of
stuff in the RFCs that not really part of TCP/IP proper.
In any event, ARP, as defined in RFC826, supports non-Ethernet format
MAC addresses, and non-IP format network addresses. In fact, the
format of the hardware and network addresses, and their lengths, are
specified in the ARP packet for each query and response.
And to the OP: does the OS on this box have any support for the
Windows networking protocols (Samba, if this is *nix)? If you enable
that, and ID the node as a workgroup node with some easily
recognizable name, then the users should be able to find it in
Explorer (somewhere under "My Network Places"). If you published a
share on your node you could put a single html page with a link (or
perhaps a redirect, or just a display – “I’m at IP 1.2.3.4”) to the
correct IP address (that redirect page would be recreated each time
your device was assigned a new IP address).
Didi
<robertwess...@yahoo.com> wrote:
> ....
> And to the OP: does the OS on this box have any support for the
> Windows networking protocols (Samba, if this is *nix)? If you enable
> that, and ID the node as a workgroup node with some easily
> recognizable name, then the users should be able to find it in
> Explorer (somewhere under "My Network Places").
No, DPS is not unix. But thanks for the hint, I'll look into that
"Samba" thing. If not too complex I certainly could add some (probably
partial) support so the name becomes visible in "my network places"
or sort of, this would be perfect as a result.
Dimiter
Hans-Bernhard Bröker
> 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
I believe that, strictly speaking, that can't happen. If you have no
internet at the moment, you don't have DHCP either. Remember that DHCP
itself is a UDP service. UDP in turn works on top of IP, and that, for
better or for worse, is "internet".
> Turned out there is nothing like an easy way to do that!
Well, the problem is nowhere near as easy as it appears at first sight.
It's called a "network" because it's _work_ to set up a properly
functioning net.
> How on Earth is that possible?!
You'll want to look up "zero config networking". That's what the big
guys came up with to address this very same issue. You'll see Apple
mentioned rather a lot, for their "Rendezvouz"/"Bonjour" project.
And let me point out I'm completely flabbergasted that nobody mentioned
this before me --- not over here in c.a.embedded, anyway. I mean, come
on guys: not a single owner of an Apple Airport base station speaking
up, wondering what all these people keep talking about for days, when a
"normal" WLAN box just does the job???
Didi
wrote:
> Didi wrote:
> > I tried today to figure out a simple way to give users of our
> > IP address once it gets one via dhcp when there is no internet
> > at the moment
>
> I believe that, strictly speaking, that can't happen. If you have no
> internet at the moment, you don't have DHCP either. Remember that DHCP
> itself is a UDP service. UDP in turn works on top of IP, and that, for
> better or for worse, is "internet".
Oh no. Here we go again. I got quite a few really insightful replies
and
now this.
There are DHCP servers in the absence of internet. For example, a
popular
type of cable models do assign IP addresses of the 192.168.... kind
when it has no link over the TV cable. Routers do that whether they
are linked to the internet or not. On which planet do you live.
>
> > Turned out there is nothing like an easy way to do that!
>
> Well, the problem is nowhere near as easy as it appears at first sight.
> It's called a "network" because it's _work_ to set up a properly
> functioning net.
Thank for the opinion. But you are posting to groups where some
minimal
understanding of how things work is implied, these are not general
talk
forums. Have a look at the thread in its entity and you will see what
I mean. No offense meant, just being practical and trying to save time
to myself and the rest of the people who really had something to say.
>
> > How on Earth is that possible?!
>
> You'll want to look up "zero config networking". That's what the big
> guys came up with to address this very same issue. You'll see Apple
> mentioned rather a lot, for their "Rendezvouz"/"Bonjour" project.
No. I was quite particular explaining what I wanted, the fact that you
did not understand it should have indicated to you that you are
about to post to a thread you do not understand.
>
> And let me point out I'm completely flabbergasted that nobody mentioned
> this before me --- not over here in c.a.embedded, anyway. I mean, come
> on guys: not a single owner of an Apple Airport base station speaking
> up, wondering what all these people keep talking about for days, when a
> "normal" WLAN box just does the job???
Same answer. The fact that you did not understand what we were talking
about should have been sufficient for you to grasp that the topic is
outside of your competence and that you have nothing to contribute.
These are technical newsgroups.
Dimiter
JosephKK
First off the TCP/IP stack is 4 levels, and the ISO model is 7 layers.
Thus there is intrinsic mismatch. Much of the TCP/IP model tools span
two or more layers in the ISO model. The real deal for TCP/IP protocol
definitions comes from the IETF RFC library.
Please note that this RFC information is freely available for any use.
Wikipedia tries to allocate levels but fails sometimes:
http://en.wikipedia.org/wiki/OSI_model
http://en.wikipedia.org/wiki/TCP/IP_model
And another opinion:
http://mike.passwall.com/networking/netmodels/isoosi7layermodel.html
Personally i place IP and UDP at the ISO link layer and ISO the transport
layer. After all they are sending the message. (R)ARP is about different
network functions and talks to the same layer (going towards Phy) as TCP
and IP; however it functions in link, transport, and network ISO layers.
So where do you want to place it?
JosephKK
>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
>
>I believe that, strictly speaking, that can't happen. If you have no
>internet at the moment, you don't have DHCP either. Remember that DHCP
>itself is a UDP service. UDP in turn works on top of IP, and that, for
>better or for worse, is "internet".
No. UDP does not use IP all. It operates in parallel with IP, and provides
a different service. Al least that is what the RFCs say.
robert...@yahoo.com
> On Tue, 30 Mar 2010 00:44:16 +0200, Hans-Bernhard Bröker <HBBroe...@t-online.de> wrote:
> >Didi wrote:
>
> >> I tried today to figure out a simple way to give users of our
> >> IP address once it gets one via dhcp when there is no internet
> >> at the moment
>
> >I believe that, strictly speaking, that can't happen. If you have no
> >internet at the moment, you don't have DHCP either. Remember that DHCP
> >itself is a UDP service. UDP in turn works on top of IP, and that, for
> >better or for worse, is "internet".
>
> No. UDP does not use IP all. It operates in parallel with IP, and provides
> a different service. Al least that is what the RFCs say.
UDP (and TCP) both use IP as their lower layer. UDP operate in
parallel with *TCP* and provides a different service. They *both* run
over IP.
It is most emphatically *not* what the RFCs say. In fact, the opening
paragraph of RFC786 (which defines UDP) is:
"This User Datagram Protocol (UDP) is defined to make
available a
datagram mode of packet-switched computer communication in
the
environment of an interconnected set of computer networks.
This
protocol assumes that the Internet Protocol (IP) [1] is used as
the
underlying protocol."
And the prior poster is correct - it's IP that basically defines the
Internet - the whole Internet exists to move IP packets around, and
protocols like ICMP, UDP and TCP are built on top of IP. A number of
other less common protocols also are built directly on top of IP
(rather than on top of UDP or TCP). For example, the communication
between routers running OSPF happens over IP, but uses protocol #89,
which is distinct from TCP (6), UDP (17) and ICMP (1).
As for DHCP, it does, in fact, use a UDP packet, although in many
implementations that's more a formality and the IP header is largely
faked during initial system startup. Having it an actual UDP packet
makes it rather easier for the (DHCP) servers and the rest of the
network, though.
Dave Platt
JosephKK <quiett...@yahoo.com> wrote:
>No. UDP does not use IP all. It operates in parallel with IP, and provides
>a different service. Al least that is what the RFCs say.
You are mistaken on this point.
UDP is built on top of IP.
TCP is built on top of IP.
ICMP is built on top of IP.
These three protocols are peers, at the same level in the network stack.
--
Dave Platt <dpl...@radagast.org> AE6EO
Friends of Jade Warrior home page: http://www.radagast.org/jade-warrior
I do _not_ wish to receive unsolicited commercial email, and I will
boycott any company which has the gall to send me such ads!
Didi
> On Tue, 30 Mar 2010 00:44:16 +0200, Hans-Bernhard Bröker <HBBroe...@t-online.de> wrote:
> >Didi wrote:
>
> >> I tried today to figure out a simple way to give users of our
> >> IP address once it gets one via dhcp when there is no internet
> >> at the moment
>
> >I believe that, strictly speaking, that can't happen. If you have no
> >internet at the moment, you don't have DHCP either. Remember that DHCP
> >itself is a UDP service. UDP in turn works on top of IP, and that, for
> >better or for worse, is "internet".
>
> No. UDP does not use IP all. It operates in parallel with IP, and provides
> a different service. Al least that is what the RFCs say.
You are aware that UDP is IP encapsulated, just like tcp? If tcp is
one
level above IP then UDP also is.
But like I said, I am not particularly interested in that sort of
"official" side of things.
dhcp is indeed running over UDP, but during the gray period of
network setup; then at least the request is broadcast etc., some
level cheating is applied during the process.
glen herrmannsfeldt
> There are DHCP servers in the absence of internet. For example, a
> popular type of cable models do assign IP addresses of the
> 192.168.... kind when it has no link over the TV cable.
> Routers do that whether they are linked to the internet or not.
> On which planet do you live.
There is internet, and there is the Internet. You can have a
network, even an internet (network of networks) not connected
to the Internet (the rest of the world).
Any of them may or may not have a DHCP server on them.
-- glen
Anne & Lynn Wheeler
"JosephKK"<quiett...@yahoo.com> writes:
> First off the TCP/IP stack is 4 levels, and the ISO model is 7 layers.
> Thus there is intrinsic mismatch. Much of the TCP/IP model tools span
> two or more layers in the ISO model. The real deal for TCP/IP protocol
> definitions comes from the IETF RFC library.
>
> http://www.ietf.org/rfc.html
>
> Please note that this RFC information is freely available for any use.
note quite true anymore ... the copyright notice use to say that author
gives unlimited rights including any derivative works as long as the
IETF copyright notice was included. A couple years ago, that was changed
... and now it ways that RFC authors may retain rights (so RFCs
published since the change are subject to the new copyright rules).
look at RFCs related to IETF Trust ... for instance 5377
5377 I Advice to the Trustees of the IETF Trust on Rights to Be Granted
in IETF Documents, Halpern J., 2008/11/10 (8pp) (.txt=17843) (See Also
5378) (Refs 3935, 4071, 4371) (Ref'ed By 5744, 5745)
current documents carry the following
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (http://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document
... i got hit with it and had to hire a copyright lawyer out of my own
pocket (situation where an attempt was made to try and apply the new
rules to RFCs published under the old rules) ... and suggested that they
needed to make it much more clear to the authors about copyright
changes.
--
42yrs virtualization experience (since Jan68), online at home since Mar1970
Rick Jones
> First off the TCP/IP stack is 4 levels, and the ISO model is 7
> layers. Thus there is intrinsic mismatch. Much of the TCP/IP model
> tools span two or more layers in the ISO model. The real deal for
> TCP/IP protocol definitions comes from the IETF RFC library.
The ISO and the IETF are both wrong. There are nine layers :)
https://www.isc.org/files/9layer.thumb.png
rick jones
--
firebug n, the idiot who tosses a lit cigarette out his car window
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...
glen herrmannsfeldt
(snip)
> The ISO and the IETF are both wrong. There are nine layers :)
> https://www.isc.org/files/9layer.thumb.png
The story I still remember is that between Europe and US
one wanted six and one eight (I don't remember which) so they
compromised on seven. Also, for ATM, one wanted 32 byte
payload, one 64, so they compromised on 48. (I would have
thought it would be geometric mean, though.)
-- glen
Hans-Bernhard Bröker
>>> 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
>> I believe that, strictly speaking, that can't happen. If you have no
>> internet at the moment, you don't have DHCP either. Remember that DHCP
>> itself is a UDP service. UDP in turn works on top of IP, and that, for
>> better or for worse, is "internet".
> There are DHCP servers in the absence of internet.
That's only true for a meaning of the term "internet" that IMHO rather
strictly contradicts with your self-proclaimed expertise in internet
technologies. What exactly did the 'I' in IP mean again?
> On which planet do you live.
One on which your personal opinion is not the normative reference for
the meaning of a technical term like "internet".
> Thank for the opinion. But you are posting to groups where some
> minimal understanding of how things work is implied,
... says the person who obviously doesn't understand USENET well enough
to recognize that his cross-post is obviously off-topic in one of the
three groups he wrote to and on the fence of topicality for a second,
who didn't bother setting a Followup-To on top of that, and replies to
technical suggestions with ad-hominem attacks undiluted by technical
arguments. Cute.
> Have a look at the thread in its entity and you will see what
> I mean.
Interesting how you believe you know what I looked at and what I didn't.
> No offense meant,
Who do you believe you're kidding?
> just being practical and trying to save time to myself and the rest
> of the people who really had something to say.
Yeah, right. Writing the above really saved your time, as compared to,
say, not bothering to write it at all. Sure.
But if you're so sure I don't understand the issue, how about you start
arguing against my statements instead of against my person?
David Schwartz
wrote:
> I believe that, strictly speaking, that can't happen. If you have no
> internet at the moment, you don't have DHCP either. Remember that DHCP
> itself is a UDP service. UDP in turn works on top of IP, and that, for
> better or for worse, is "internet".
Many networks that have nothing whatsoever to do with the Internet
have adopted its protocol. You can't have the Internet without IP, but
you can certainly have IP with the Internet.
DS
markp
"David Schwartz" <dav...@webmaster.com> wrote in message
news:8a306499-3f14-43cd...@u22g2000yqf.googlegroups.com...
For this thread to make any sense you should be able to define exactly what
an 'Internet' is. Off you go...
Mark.
Paul Hovnanian P.E.
> In article <4BAC2BE3...@Hovnanian.com>,
> "Paul Hovnanian P.E." <Pa...@Hovnanian.com> wrote:
>
>> 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).
>> >
>> >
>> Here's an idea: http://en.wikipedia.org/wiki/Dynamic_DNS
>>
>> That will solve the dynamic (DHCP assigned) IP address to a DNS entry
>> that the world can resolve.
>
> Isn't that what he's referring to in the parentheses? He's trying to
> find a way to do it when there's no DNS server to update.
>
I skipped over that part. When he mentioned his 'customers', I was thinking
of people outside of his LAN (on the Internet), which would assume the
operation of the entire name service infrastructure.
On LANs, the easiest protocol to implement (for discovery of peers) would be
NMBD. That's a part of the Samba s/w suite (http://www.samba.org/). That's
not a solution for WAN access, but it works within small networks.
--
Paul Hovnanian pa...@hovnanian.com
----------------------------------------------------------------------
Have gnu, will travel.
JosephKK
Thanks for the update, i hadn't realized that the publishers sickness had
gotten to IETF. Damn publishers, insisting on hanging on to a
technologically obsolete business model from the dark ages.
JosephKK
>In comp.protocols.tcp-ip JosephKK <quiett...@yahoo.com> wrote:
>> First off the TCP/IP stack is 4 levels, and the ISO model is 7
>> layers. Thus there is intrinsic mismatch. Much of the TCP/IP model
>> tools span two or more layers in the ISO model. The real deal for
>> TCP/IP protocol definitions comes from the IETF RFC library.
>
>The ISO and the IETF are both wrong. There are nine layers :)
>
>https://www.isc.org/files/9layer.thumb.png
>
>rick jones
Not at all, both of those are applied liberally to all levels of
any stack currently; they actually enclose the whole stack.
Worse they are trying to get in between the existing layers/levels.
JosephKK
>Didi wrote:
>> On Mar 30, 1:44 am, Hans-Bernhard Bröker <HBBroe...@t-online.de>
>> wrote:
>>> 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
>
>>> I believe that, strictly speaking, that can't happen. If you have no
>>> internet at the moment, you don't have DHCP either. Remember that DHCP
>>> itself is a UDP service.
>>>UDP in turn works on top of IP, and that, for
>>> better or for worse, is "internet".
This erroneous statement alone shows that you are ill prepared to participate
in this discussion. If you think UDP "sits" on top of IP you are very mistaken.
It is a parallel (at the same level) link/transport protocol.
Moreover, you desired email reply shows arrogant disregard for USENET norms.
>
> > There are DHCP servers in the absence of internet.
>
>That's only true for a meaning of the term "internet" that IMHO rather
>strictly contradicts with your self-proclaimed expertise in internet
>technologies. What exactly did the 'I' in IP mean again?
>
<Snip>
JosephKK
Damn, it seems i got things upside down again.
Boudewijn Dijkstra
<quiett...@yahoo.com>:
> On Wed, 31 Mar 2010 00:31:23 +0200, Hans-Bernhard Bröker
> <HBBr...@t-online.de> wrote:
>> Didi wrote:
>>> On Mar 30, 1:44 am, Hans-Bernhard Bröker <HBBroe...@t-online.de>
>>> wrote:
>>>> 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
>>
>>>> I believe that, strictly speaking, that can't happen. If you have no
>>>> internet at the moment, you don't have DHCP either. Remember that
>>>> DHCP itself is a UDP service.
>
>>>> UDP in turn works on top of IP, and that, for
>>>> better or for worse, is "internet".
>
> This erroneous statement alone shows that you are ill prepared to
> participate
> in this discussion. If you think UDP "sits" on top of IP you are very
> mistaken.
> It is a parallel (at the same level) link/transport protocol.
If you think that the link layer, internet layer and transport layer are
all the same layer, then yes. But alas for you, OSI and TCP/IP do not
agree with you.
> Moreover, you desired email reply shows arrogant disregard for USENET
> norms.
Well, at least he didn't top-post.
--
Gemaakt met Opera's revolutionaire e-mailprogramma:
http://www.opera.com/mail/
(remove the obvious prefix to reply by mail)
Cesar Rabak
> On Wed, 31 Mar 2010 00:31:23 +0200, Hans-Bernhard Bröker<HBBr...@t-online.de> wrote:
>
>> Didi wrote:
>>> On Mar 30, 1:44 am, Hans-Bernhard Bröker<HBBroe...@t-online.de>
>>> wrote:
>>>> 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
>>
>>>> I believe that, strictly speaking, that can't happen. If you have no
>>>> internet at the moment, you don't have DHCP either. Remember that DHCP
>>>> itself is a UDP service.
>
>>>> UDP in turn works on top of IP, and that, for
>>>> better or for worse, is "internet".
>
> This erroneous statement alone shows that you are ill prepared to participate
> in this discussion. If you think UDP "sits" on top of IP you are very mistaken.
> It is a parallel (at the same level) link/transport protocol.
If you think you have a lesson to teach please:
Can you show the erroneous part of the statement explaining us how an
UDP datagram could be *sent* to a network without the IP layer?
Remember *you* wrote they're 'parallel' so they can be used in exchange
of each other, right?
>
> Moreover, you desired email reply shows arrogant disregard for USENET norms.
Your not very informed reply shows an arrogrant ignorance for the
Internet RFC or equivalent ISO models.
--
Cesar Rabak
GNU/Linux User 52247.
Get counted: http://counter.li.org/
markp
"Cesar Rabak" <csr...@bol.com.br> wrote in message
news:hp2enu$7tr$1...@news.eternal-september.org...
Add to that the datagram part can have a length of 64Kbytes, to send that
over the internet will require splitting into max MTU packet sizes and then
re-assembled. Of course UDP sits above IP!!
Mark.
Albert Manfredi
> Uhm, not so sure. Same level as UDP in that they both have the
> Ethernet
> protocol type set to "internet", perhaps; but the data inside a UDP
> packet
> are encapsulated into that level, whereas the ARP data are purely
> Ethernet
> encapsulated. This should put it one level lower - at least
> unofficially?
I totally agree with you that ARP and UDP are in different protocol
layers, but your response here is confusing.
ARP uses a Type of 0x806, whereas IPv4 uses 0x0800. See:
http://www.iana.org/assignments/ethernet-numbers
So, ARP frames are only encapsulated by the Ethernet frame, nothing
more. Whereas UDP datagrams are encapsulated inside an IP datagram,
which in turn is inside the Ethernet frame.
Bert
glen herrmannsfeldt
(snip)
> I totally agree with you that ARP and UDP are in different protocol
> layers, but your response here is confusing.
> ARP uses a Type of 0x806, whereas IPv4 uses 0x0800. See:
> http://www.iana.org/assignments/ethernet-numbers
> So, ARP frames are only encapsulated by the Ethernet frame, nothing
> more. Whereas UDP datagrams are encapsulated inside an IP datagram,
> which in turn is inside the Ethernet frame.
Counting that way, why not any of the higher layers?
Back to ICMP for a moment. As ICMP is also carried in
an IP frame, it seems that it should be the same layer as TCP
and UDP. In terms of ping, that makes sense. In terms of
route redirect or source quench, it doesn't. In the latter
case, the ICMP are to help the IP layer and not much about
anything higher.
ARP is there to help IP send frames on networks where
layer 2 needs such help.
-- glen
Albert Manfredi
> > I totally agree with you that ARP and UDP are in different protocol
> > layers, but your response here is confusing.
> > ARP uses a Type of 0x806, whereas IPv4 uses 0x0800. See:
> >http://www.iana.org/assignments/ethernet-numbers
> > So, ARP frames are only encapsulated by the Ethernet frame, nothing
> > more. Whereas UDP datagrams are encapsulated inside an IP datagram,
> > which in turn is inside the Ethernet frame.
>
> Counting that way, why not any of the higher layers?
>
> Back to ICMP for a moment. As ICMP is also carried in
> an IP frame, it seems that it should be the same layer as TCP
> and UDP. In terms of ping, that makes sense. In terms of
> route redirect or source quench, it doesn't. In the latter
> case, the ICMP are to help the IP layer and not much about
> anything higher.
ICMP is at the same layer as UDP, TCP, or IGMP, for that matter. But
neither ICMP nor IGMP are meant to provide the general purpose
"transport layer" services that TCP and UDP provide. I'd classify ICMP
and IGMP as special purpose protocols to control or monitor layer 3
devices.
> ARP is there to help IP send frames on networks where
> layer 2 needs such help.
True. ARP is network-agnostic. It happens to have been used in IP nets
most often, but that does not mean that it can ONLY be used to resolve
IP addresses to physical addresses. It could in principle have been
used for DECnet or any of those other forgotten protocols.
Bert
glen herrmannsfeldt
> most often, but that does not mean that it can ONLY be used to resolve
> IP addresses to physical addresses. It could in principle have been
> used for DECnet or any of those other forgotten protocols.
Make that should have been used for DECnet. As I remember,
DECnet changes the MAC address based on the DECnet address, such
that no ARP is needed. You can only do that for one protocol
per interface, though.
There was not so long ago on another newsgroup someone who
had a system that uses DHCP to assign the IP address, then
brings up DECnet. Somehow the change of MAC address confused
other parts of the system.
Then Appletalk has AARP instead of using ARP.
I don't know IPX very well, so I don't know what it does.
-- glen
JosephKK
>On Wed, 31 Mar 2010 00:31:23 +0200, Hans-Bernhard Bröker <HBBr...@t-online.de> wrote:
>
>>Didi wrote:
>>> On Mar 30, 1:44 am, Hans-Bernhard Bröker <HBBroe...@t-online.de>
>>> wrote:
>>>> 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
>>
>>>> I believe that, strictly speaking, that can't happen. If you have no
>>>> internet at the moment, you don't have DHCP either. Remember that DHCP
>>>> itself is a UDP service.
>
>>>>UDP in turn works on top of IP, and that, for
>>>> better or for worse, is "internet".
>
>This erroneous statement alone shows that you are ill prepared to participate
>in this discussion. If you think UDP "sits" on top of IP you are very mistaken.
>It is a parallel (at the same level) link/transport protocol.
Arrghkk, gllujk, orwrrpp. (translation ankle tastes soo good)
>
>Moreover, you desired email reply shows arrogant disregard for USENET norms.
This still stands.
Hans-Bernhard Bröker
JosephKK wrote:
> Moreover, you desired email reply shows arrogant disregard for USENET norms.
Well, so did the OP (by failing to set any Followup-To at all, and
X-posting to at least one totally off-topic newsgroup). And in his
utterance that I replied to, _he_ dropped to a level of discussion that
was off-topic for all three newsgroup, and unfit for anything but
private discussion.
I'm quite sure it's well within USENET norms to redirect discussion of
off-topic ad-hominem attacks to more appropriate ways of discussion.
_Ignoring_ such redirects, like you did, is not.
Przemek Klosowski
> Just made the device attempt it every 20 seconds or so - the user being
able
> to turn that on/off.
Just make the device send a packet to the broadcast address, or to
FF:FF:FF:FF:FF:FF every 20 seconds, containing its ID (well, it'll
contain the MAC as the source address already, but you could also add
more info e.g. the time since turned on or other information that may
be helpful to distinguish between multiple devices). Every host on their
local subnet will receive such packets, so it'll be a simple matter of
programming to get the info you need.
JosephKK
No. You asking for email reply is abnormal. Rechecking the thread a bit
i did not see any serious ad hominem either. Perhaps you are reading
different posts than i am, perhaps not.
gopher
> 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
> and customers can see it using a browser).
>
>
> 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/
Okay, perhaps we can steer this back to the original question?...
Is there a (easy) way to generate an Inverse ARP from a WIndows and/or
Linux workstation? (or any other device, like a cisco switch or
router)
My notes to add to the mess:
- We have identified an "interesting mac" address on the network (most
likely noticed on a switches mac table) but we don't know it's IP
address.
- we're assuming it has an IP address. (not netware or appletalk
or...)
- We are not asking about Reverse ARP, that's different than Inverse
ARP. Reveres ARP issued by me is me asking for my own IP address. RARP
was a predecessor to bootp/dhcp.
- Inverse arp is sent to a mac address and asks that mac what his/her
IP address is.
- Not everyone responds to a Broadcast ping to 255.255.255.255, so
those results are not guaranteed to get the "interesting" mac to
respond and add an entry to your arp table
- Not everyone responds to a subnet Broadcast ping to 172.16.3.255
(assuming the subnet is 172.16.3.0/24), so those results are not
guaranteed to get the "interesting" mac to respond.
- Not everyone responds to a ping to 172.16.3.0 (assuming the subnet
is 172.16.3.0/24), so those results are not guaranteed to get the
"interesting" mac to respond.
- the interesting mac may not be using DHCP, it may be statically
assigned an IP address and mask.
- the interesting mac may be programmed for a different subnet than
what we think the switch port should be on (say our subnet is
172.16.3.0/24 and the "interesting mac" is quietly sitting there
programmed for 10.20.30.153/24)
- because of the above, even a ip address scan of the subnet you think
it's on (172.16.3.0/24) isn't going to get a response from the
interesting mac.
So, it would be really cool if you could generate an Inverse-arp to
the "interesting mac" to say "hey! what's your IP address?".
Of course if someone has such a command, the next question will be
what percentage of devices will actually respond to it?
port mirroring to a sniffer (Wireshark) is another way to see it's IP
address, if it's sending anything.
anyway, that's where this posting started (I think). Can anyone answer
that initial question about generating an Inverse-arp?
Cheers - Glen#2
gopher
keep in mind, if your "interesting mac" address host is using dhcp to
get it's IP address, and your DHCP server which it uses is on the
other side of your broken Internet circuit, using inverse-arp would be
a very temporary solution. DHCP based IP addresses are given out with
a lease time that expires. The host should clear it's IP address if
the lease time expires. Lease times can be from minutes to days. I've
often seen 24hrs, but I've seen as low as 1 hour. The DHCP client host
will try to renew at the leases half-life (and probably again after
that until the lease expires, I'll have to look that up one day. I'd
guess it would try half way between the failed renewal and the
expirey, and keep doing that til the expirey, but it's just a guess)
Glen#2
Didi
I have made it to issue a new DHCP request some time before it
expires,
just had a look at it - 3 minutes before expiration. Works so far, but
I don't have many systems deployed yet. Anyway, I have put this(and
other similar high-level behaviour) in a DPS script for a reason, so
it can easily be changed it if needed :-) .
BTW I think I posted the reason why there is no rarp/inarp utility
under windows (their API won't allow it, a guy responded elsewhere).
The same guy said he had written one himself for linux, so it
seems to be possible there - but I did not locate anything readily
available in a half an hours search.
Dimiter
David Schwartz
> For this thread to make any sense you should be able to define exactly what
> an 'Internet' is. Off you go...
I certainly can define exactly what the "Internet" is, but I don't see
how it's relevant.
DS
k...@att.bizzzzzzzzzzzz
There is only one Internet, so "an Internet" is grammatically incorrect. It
should be "the Internet". There is no argument about the definition of
"Internet", as there is only one (note that the capitalized "Internet" denotes
a proper noun).
If you're not talking about *the* Internet, rather a network of computers
outside *the* Internet, you should say "an internet". There you might have an
legitimate argument over the precise definition of "internet".
clemens fischer
On Thu-2010/03/25-22:54 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).
You mention a fallback IP constructed from a standard prefix
192.168.100.<mac>, with <mac> being the last octet of the NIC's MAC.
How about putting a slip of paper into the box stating this fallback IP?
Works with and without non-site internet.
clemens
Didi
n...@spotteswoode.dnsalias.org> wrote:
> (sorry for being so late)
>
> On Thu-2010/03/25-22:54 Didi wrote:
> > I tried today to figure out a simple way to give users of our new
> > 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).
>
> You mention a fallback IP constructed from a standard prefix
> 192.168.100.<mac>, with <mac> being the last octet of the NIC's MAC.
>
> How about putting a slip of paper into the box stating this fallback IP?
> Works with and without non-site internet.
>
> clemens
Well this is sort of the same thing. The lowest byte just has to
be made up somehow, as others use 192.168.100.xx as well. Some
luck will be needed anyway to not have that IP reserved. BTW
the users get this not on a piece of paper but in a file
on the accompanying CD :-) .
But this IP will not work at all in may cases when there is
internet on the site. The subnet is likely to be quite different
to the assumed one for fallback, so hosts trying to reach this
IP will route to the gateway rather than locally (using ARP).
It is just an ultimate fallback scenario so one can somehow get
in touch with the device if it won't get automagiacally accepted
on the local net via dhcp. Say, when people want to set a static
address to it and need to access the thing to do it.
Dimiter
P.S. This is a revived old usenet thread, here is yet again
the URL of the discussed device:
http://tgi-sci.com/tgi/nmcatb.htm
RockyG
Out of curiosity, did you try NBNS and if so what was the factor that
prevented use of it? I noticed you continued trying other solutions..
---------------------------------------
Posted through http://www.EmbeddedRelated.com
Didi
wrote:
Have not tried it. It is nothing pressing which is the reason
why - it appears that if the wintel PC will broadcast its request
which the netMCA will reply to things should work. Then I am
not a wintel person, I don't even know how to make the PC do
that (not that I could not find out, it is probably obvious,
but I have not done it :-) ).
Not directly related, but in a similar line of thoughts:
I was surprised to see recently that my ISP does register the
name from the dhcp request in their ddns database (had to call
and register MAC address until recently). Way to go, if routers
begin doing it within a few years time the issue will mostly
disappear.
Dimiter