Searching \ for '[EE] Strategy for addressing embedded Ethernet dev' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/index.htm?key=strategy+addressing
Search entire site for: 'Strategy for addressing embedded Ethernet dev'.

Exact match. Not showing close matches.
PICList Thread
'[EE] Strategy for addressing embedded Ethernet dev'
2006\06\26@154731 by Josh Koffman

face picon face
Hi all. So I've been thinking about all sorts of little embedded
Ethernet projects I want to do (someday when I am a better
programmer), and one thing keeps jumping out at me: adressing. Sure,
it's easy to configure a computer to access a network becuase it has a
screen and a keyboard. The devices I want to build are to be tiny and
won't have the space for all sorts of switches and an LCD (or the cost
come to think of it). So how to recognize these devices across the
network?

Here are a few ideas I've had:

1. Hardcode everything. Not such a great option IMO, especially if the
units are travelling between networks.

2. Have some sort of discovery program that runs as a PC application
and allows you to configure the devices. Not a bad idea, but I can't
program for PCs. Guess I'd have to find a partner. Also how to
identify the individual units if they are geographically spread out? I
guess manually writing down the MAC addresses would work but seems
cumbersome. Can't "flash the LEDs" if you can't see the remote
device...

3. Some sort of intelligent controller (ie PDA or custom built
solution) that connected up to each individual device and allowed
configuration. I like this idea, but I can't program for PDA.

This isn't pressing, I don't think I will be working on these projects
any time soon, but man those Xports are tempting. So what would you
do?

Josh
--
A common mistake that people make when trying to design something
completely foolproof is to underestimate the ingenuity of complete
fools.
       -Douglas Adams

2006\06\26@160359 by Shawn Tan

flavicon
face
On Monday 26 June 2006 20:47, Josh Koffman wrote:
> Here are a few ideas I've had:
> 1. Hardcode everything. Not such a great option IMO, especially if the
> 2. Have some sort of discovery program that runs as a PC application
> 3. Some sort of intelligent controller (ie PDA or custom built

> This isn't pressing, I don't think I will be working on these projects
> any time soon, but man those Xports are tempting. So what would you
> do?

i've not actually done these things before.. so, take this with a grain of
salt..

4. Ideally, your device should be preconfigured to some private IP address,
like 10.0.0.1 or whatever.. Then, you can connect it to a network,
temporarily modify your PC to be in the same IP range and connect to the
device..

Then, you can either implement a simple "telnet" server or even run a
small "web server" that displays a configuration page.. For future
connections, you can even implement a small dhcp client..

5. However, from your description, it seems that you might like your devices
to be "auto configured".. then, you may want to implement a small dhcp client
in your device.. but this requires that you have a DHCP server running on the
network.. it could use it's MAC address as a "hostname" identifier to the
server.. You can group your devices under a common MAC identifier..

cheers..

with metta,
shawn tan.

2006\06\26@161723 by William Chops Westfield

face picon face

Are you talking about your basic ethernet address, or the
higher level (IP) addresses and configuration?

Devices generally store an ethernet address in a serial
EEPROM of some sort.  Once you have an ethernet address,
the rest of configuration is a well-examined problem:

> Have some sort of discovery program that runs as a PC
> application and allows you to configure the devices. Not
> a bad idea, but I can't program for PCs. Guess I'd have
> to find a partner. Also how to identify the individual
> units if they are geographically spread out?

Look into the "DHCP" Protocol imlpemntations (Dynamic Host
Configuration Protocol.)  This was aimed at configuring the
details of all those damn PCs clueless idiots kept connecting
to the corporate internet, and is well suited to getting a
pretty complete configuration for an arbitrary device starting
with nothing more than an ethernet address (and perhaps less,
for non-ethernet networks.)  Basically, when a host comes up
not knowing much about who it is, it sends a broadcast IP
packet to the DHCP server requesting information, and the
DHCP server responds with an IP address that can be used
by the device, the default router, the nameserver, ...,
and the name of config file that might contain additional
information of a less generic nature.

DHCP is built on top of the earlier BOOTP protocol.
BOOTP in turn addressed some of the limitations of
"Reverse ARP (RARP), which did nothing beyond assigning
an IP address based on ethernet address.

(now, a FULL implementation of everything in DHCP is going
to exceed the memory of most microcontrollers.  But a FULL
implementation is unlikely to be necessary...)

BillW

2006\06\26@161930 by Josh Koffman

face picon face
On 6/26/06, Shawn Tan <spam_OUTshawn.tanTakeThisOuTspamaeste.net> wrote:
> 4. Ideally, your device should be preconfigured to some private IP address,
> like 10.0.0.1 or whatever.. Then, you can connect it to a network,
> temporarily modify your PC to be in the same IP range and connect to the
> device..
>
> Then, you can either implement a simple "telnet" server or even run a
> small "web server" that displays a configuration page.. For future
> connections, you can even implement a small dhcp client..

I've always found that to be a bit of a pain, but you're right, it is
a valid solution.

> 5. However, from your description, it seems that you might like your devices
> to be "auto configured".. then, you may want to implement a small dhcp client
> in your device.. but this requires that you have a DHCP server running on the
> network.. it could use it's MAC address as a "hostname" identifier to the
> server.. You can group your devices under a common MAC identifier..

My problem with DHCP is that if I randomly hand out IP addresses, how
can I ensure that the device at 192.168.1.32 is going to be the same
each time? The devices I'm thinking about will always need to be
repeatably addressed based on their physical location, which is
something that Ethernet doesn't really care about - you can plug your
cable in anywhere and still get a connection. Perhaps a combo of
assigning an IP address via DHCP then using the MAC address as an
identifier?

Josh
--
A common mistake that people make when trying to design something
completely foolproof is to underestimate the ingenuity of complete
fools.
       -Douglas Adams

2006\06\26@162523 by Timothy Weber

face picon face
Josh Koffman wrote:
> Hi all. So I've been thinking about all sorts of little embedded
> Ethernet projects I want to do (someday when I am a better
> programmer), and one thing keeps jumping out at me: adressing. Sure,
> it's easy to configure a computer to access a network becuase it has a
> screen and a keyboard. The devices I want to build are to be tiny and
> won't have the space for all sorts of switches and an LCD (or the cost
> come to think of it). So how to recognize these devices across the
> network?

One approach I've used for small wireless devices, where there's a
similar problem:

Include at least one dedicated switch, or multi-button combination, or
something like that - a way to trigger a "Yo" message.

When a device says "Yo," it's sent broadcast.

At the administrative machine (e.g., Windows), run a client program that
listens for "Yo" messages and marks down the IP addresses they came
from.  It then presents them in a list sorted by time received, and lets
you type a display name for each.

When you get one or more new devices you want to add to the network, you
just start up the client app, then go around plugging in devices and
triggering the "Yo" message on each device.  Write down the order you
set them up, if necessary, or just do them in some memorable order.
When you get back, name the devices you just added.

From then on, you can do whatever you like with those display names -
send them back to the remote device, publish them to a well-known
directory, whatever.  You can also send pings out to each device on some
schedule to see if they're all still there.
--
Timothy J. Weber
http://timothyweber.org

2006\06\26@163030 by YAP

picon face
Hi Josh,

On 6/26/06, Josh Koffman <.....joshybearKILLspamspam@spam@gmail.com> wrote:
{Quote hidden}

For VSCP (http://www.vscp.org) we use two different methods when we work
over TCP/IP.

1.) Only UDP datagrams where the frame act as an unreliable event. The deman
on the application is rather high here as frames will be lost from time to
time. OK for many situations.

2.) Each node connect to some central TCP/IP server. This can be done either
by hardcoding the server IP address in the node or using the "High End
Server Request" / "High End Server Response" events which are UDP datagram
broadcast  sent out to port 9598 (the VSCP reserved port) and to which
available servers should respond. This will of course only work on a local
segment as a router normally will not forward UDP datagram broadcasts.

On IP networks DHCP can be used to give each node a unique ID in the form of
an IP address. On the DHCP server you can match Ethernet MAC addresses and
IP numbers if you want or just let the node pick an address in a range.

For VSCP we use a 128 bit GUID that identifies each node. The MAC address or
the IP address can be used to construct this GUID or it can be unique for a
company/person (http://www.vscp.org/wiki/doku.php?id=vscp_assigned_guid_s)

If you want to play I can recommend the Modtronix Ethernet boards (
http://www.modtronix.com). They are easy and fun to work with (not
affiliated in any way other then as a satisfied customer).

Cheers
/Ake

2006\06\26@163518 by Josh Koffman

face picon face
On 6/26/06, William Chops Westfield <westfwspamKILLspammac.com> wrote:
> Are you talking about your basic ethernet address, or the
> higher level (IP) addresses and configuration?

You touch on a good point, one that I didn't mention but should have.
In addition to the basic IP address, there would likely be small bits
of configuration data (ie unit number, specific behavious modifiers,
etc) that would need to be sent. That's why I'm leaning towards the
PC/PDA configurator I think.

Josh
--
A common mistake that people make when trying to design something
completely foolproof is to underestimate the ingenuity of complete
fools.
       -Douglas Adams

2006\06\26@164900 by Herbert Graf

flavicon
face
On Mon, 2006-06-26 at 16:19 -0400, Josh Koffman wrote:
> My problem with DHCP is that if I randomly hand out IP addresses, how
> can I ensure that the device at 192.168.1.32 is going to be the same
> each time? The devices I'm thinking about will always need to be
> repeatably addressed based on their physical location, which is
> something that Ethernet doesn't really care about - you can plug your
> cable in anywhere and still get a connection. Perhaps a combo of
> assigning an IP address via DHCP then using the MAC address as an
> identifier?

Most "better" DHCP servers allow a sort of "static" DHCP where you
statically set the IP of each client at the DHCP server. The DHCP
server, on recieving a DHCP request, checks the requests MAC, cross
references it to it's internal list, and hands out the static IP.

The benefit is that while everything is static, everything can be
changed at only one spot, the DHCP server.

TTYL

2006\06\26@170149 by Josh Koffman

face picon face
On 6/26/06, Herbert Graf <.....mailinglist2KILLspamspam.....farcite.net> wrote:
> Most "better" DHCP servers allow a sort of "static" DHCP where you
> statically set the IP of each client at the DHCP server. The DHCP
> server, on recieving a DHCP request, checks the requests MAC, cross
> references it to it's internal list, and hands out the static IP.
>
> The benefit is that while everything is static, everything can be
> changed at only one spot, the DHCP server.

The downside to this is that ideally you'd want to support moving to
different networks. Or at least,  I would want to support that. My
thought is that being able to roam from a DHCP network (your server)
to a DHCP network (someone else's server) to a static IP network
should all be possible. I recognize that you might have to run a PC
based program to get the nodes flipped to the new config, but the
innate capability would still be there.

I suppose this is a hard concept without a concrete example, but while
I do have something in mind, I can't quite explain it all. Anyone who
wishes to drop in at my house (in Toronto) is welcome to come see an
example of a system that sort of works.

:)

Josh
--
A common mistake that people make when trying to design something
completely foolproof is to underestimate the ingenuity of complete
fools.
       -Douglas Adams

2006\06\26@172345 by Carey Fisher

face picon face
Herbert Graf wrote:
> On Mon, 2006-06-26 at 16:19 -0400, Josh Koffman wrote:
>  
>> My problem with DHCP is that if I randomly hand out IP addresses, how
>> can I ensure that the device at 192.168.1.32 is going to be the same
>> each time? The devices I'm thinking about will always need to be
>> repeatably addressed based on their physical location, which is
>> something that Ethernet doesn't really care about - you can plug your
>> cable in anywhere and still get a connection. Perhaps a combo of
>> assigning an IP address via DHCP then using the MAC address as an
>> identifier?
>>    
>
> Most "better" DHCP servers allow a sort of "static" DHCP where you
> statically set the IP of each client at the DHCP server. The DHCP
> server, on recieving a DHCP request, checks the requests MAC, cross
> references it to it's internal list, and hands out the static IP.
>
>
>  
An example is the Dlink DI- 808.  It allows DHCP while providing a
specific IP Address for a device with a specific MAC address.

Carey
--

*Carey Fisher, Chief Technical Officer
New Communications Solutions, LLC
*EraseMEcareyfisherspam_OUTspamTakeThisOuTncsradio.com <careyfisherspamspam_OUTncsradio.com>
Toll Free Phone:888-883-5788
Local Phone:770-814-0683
FAX: 888-883-5788
http://www.ncsradio.com <http://www.ncsradio.com/>

2006\06\26@175248 by David VanHorn

picon face
My printer does this.  It does regular DHCP, then the front end software
finds it, presumably with a broadcast to an oddball port or an "are you my
mommy" scan.

2006\06\26@191846 by Josh Koffman

face picon face
On 6/26/06, David VanHorn <@spam@dvanhornKILLspamspammicrobrix.com> wrote:
> My printer does this.  It does regular DHCP, then the front end software
> finds it, presumably with a broadcast to an oddball port or an "are you my
> mommy" scan.

Anyone know how iTunes finds other instances of iTunes? I'm pretty
sure it works even if the computers are using different IP ranges (ie
one computer has a proper IP, and the other has a 169.x.x.x address).
At least, I seem to remember that...

Josh
--
A common mistake that people make when trying to design something
completely foolproof is to underestimate the ingenuity of complete
fools.
       -Douglas Adams

2006\06\26@193430 by Alex Harford

face picon face
On 6/26/06, Josh Koffman <KILLspamjoshybearKILLspamspamgmail.com> wrote:
>
> Anyone know how iTunes finds other instances of iTunes? I'm pretty
> sure it works even if the computers are using different IP ranges (ie
> one computer has a proper IP, and the other has a 169.x.x.x address).
> At least, I seem to remember that...
>

Zeroconf.

http://en.wikipedia.org/wiki/Zeroconf

Apple calls it Bonjour.  Previously Rendezvous but there was a
trademark conflict IIRC.

Alex

2006\06\26@195806 by Zik Saleeba

face picon face
Not exactly answering your question but if you want an easy ethernet
interface one of these products might help:

www.digi.com/products/embeddedsolutions/digiconnectme.jsp
http://www.saelig.com/miva/merchant.mvc?Screen=PROD&Product_Code=ETH001&Category_Code=ETH

Cheers,
Zik

On 27/06/06, Josh Koffman <RemoveMEjoshybearTakeThisOuTspamgmail.com> wrote:
{Quote hidden}

> -

2006\06\27@033332 by Marcel van Lieshout

flavicon
face
Perhaps IP-gleaning is an option? Microchip uses this in their TCP/IP stack.
See: http://ww1.microchip.com/downloads/en/AppNotes/00833b.pdf

Marcel

Alex Harford wrote:
{Quote hidden}

2006\06\27@044002 by Alan B. Pearce

face picon face
>> Most "better" DHCP servers allow a sort of "static" DHCP where you
>> statically set the IP of each client at the DHCP server. The DHCP
>> server, on recieving a DHCP request, checks the requests MAC, cross
>> references it to it's internal list, and hands out the static IP.
>>
>> The benefit is that while everything is static, everything can be
>> changed at only one spot, the DHCP server.
>
>The downside to this is that ideally you'd want to support moving to
>different networks. Or at least,  I would want to support that. My
>thought is that being able to roam from a DHCP network (your server)
>to a DHCP network (someone else's server) to a static IP network
>should all be possible. I recognize that you might have to run a PC
>based program to get the nodes flipped to the new config, but the
>innate capability would still be there.

This is the way my laptop is configured, and the lab network uses the MAC
address to assign an IP number. Because some lab areas are in different IP
villages they configure things this way so that laptops can be used almost
anywhere, once the DHCP is set up.

I assume Josh's original query starts from a point of producing a reasonable
number of devices, which then need configuring with a minimum of effort. Is
there some reason why one cannot configure the device with a "standard" MAC
address, and DHCP, plug it into a test network, and then from a PC sent it a
heap of info such as its permanent MAC address, a node name, and if required
a permanent IP address, setting it to use that instead of DHCP. Send a
message to write that lot into EEPROM and reboot.

2006\06\28@022814 by Nate Duehr

face
flavicon
face

On Jun 26, 2006, at 3:52 PM, David VanHorn wrote:

> My printer does this.  It does regular DHCP, then the front end  
> software
> finds it, presumably with a broadcast to an oddball port or an "are  
> you my
> mommy" scan.

Probably "mommy" just sends out a broadcast packet that all  
"children" know to respond to in a certain way.  If your LAN were a  
class A (e.g. 10.0.0.0/8) it'd take "mommy" a very long time to find  
her "children".  :-)

You could find out for sure, for free... http://www.wireshark.org  
(the "non-fork" of Ethereal).

Nate

2006\06\28@032330 by Philip Pemberton

face picon face
Nate Duehr wrote:
> Probably "mommy" just sends out a broadcast packet that all  
> "children" know to respond to in a certain way.  If your LAN were a  
> class A (e.g. 10.0.0.0/8) it'd take "mommy" a very long time to find  
> her "children".  :-)

Nah, probably a broadcast ping or packet. For 10.0.0.0/8, your bcast address
would be 10.255.255.255, so send a packet there and every device on that
subnet should pick it up. Check the packet over, see if it's valid, and
respond to the sender if it is.

--
Phil.                         | Kitsune: Acorn RiscPC SA202 64M+6G ViewFinder
TakeThisOuTphilpemEraseMEspamspam_OUTdsl.pipex.com         | Cheetah: Athlon64 3200+ A8VDeluxeV2 512M+100G
http://www.philpem.me.uk/     | Tiger: Toshiba SatPro4600 Celeron700 256M+40G

2006\06\28@035609 by Nate Duehr

face
flavicon
face

On Jun 28, 2006, at 1:23 AM, Philip Pemberton wrote:

> Nate Duehr wrote:
>> Probably "mommy" just sends out a broadcast packet that all
>> "children" know to respond to in a certain way.  If your LAN were a
>> class A (e.g. 10.0.0.0/8) it'd take "mommy" a very long time to find
>> her "children".  :-)
>
> Nah, probably a broadcast ping or packet. For 10.0.0.0/8, your  
> bcast address
> would be 10.255.255.255, so send a packet there and every device on  
> that
> subnet should pick it up. Check the packet over, see if it's valid,  
> and
> respond to the sender if it is.

Isn't that what I just said?  " 'mommy' just sends out a broadcast  
packet"...

Hello Phil??  More coffee man!

:-)

Nate

2006\06\28@092525 by Martin Klingensmith

flavicon
face
Nate Duehr wrote:

{Quote hidden}

You said send out to all 10.0.0.0/8 which is about 16,581,375 IP
addresses (a few more/less perhaps)
A broadcast ping is physically addressed to the single IP address
10.255.255.255. Anyone on 10/8 should receive it.
--
Martin K

2006\06\28@101555 by Philip Pemberton

face picon face
Martin Klingensmith wrote:
> Nate Duehr wrote:
>> Isn't that what I just said?  " 'mommy' just sends out a broadcast  
>> packet"...
>>
>> Hello Phil??  More coffee man!
>>
>> :-)
>>
>> Nate
>>  
>>
> You said send out to all 10.0.0.0/8 which is about 16,581,375 IP
> addresses (a few more/less perhaps)
> A broadcast ping is physically addressed to the single IP address
> 10.255.255.255. Anyone on 10/8 should receive it.

Is what I say!

Actually, it would be 16,777,214 if you had a /8 subnet mask. One network, no
subnets, one network address, one broadcast address. 2^24 - 2.

--
Phil.                         | Kitsune: Acorn RiscPC SA202 64M+6G ViewFinder
RemoveMEphilpemspamTakeThisOuTdsl.pipex.com         | Cheetah: Athlon64 3200+ A8VDeluxeV2 512M+100G
http://www.philpem.me.uk/     | Tiger: Toshiba SatPro4600 Celeron700 256M+40G

2006\06\28@124509 by Nate Duehr

face
flavicon
face

On Jun 28, 2006, at 7:25 AM, Martin Klingensmith wrote:

{Quote hidden}

Sigh, read it again.

Dave said he thought the PC was "finding" the printer, and he guessed  
it was via some sort of scanning mechanism.

I replied by saying that no, it's probably using a broadcast and *IF*  
the PC was scanning the whole range it would take too long.

Now two people are saying, "No it's using a broadcast."

Someone's not reading here... or you're replying to the wrong person.

Nate

2006\06\28@141829 by Herbert Graf

flavicon
face
On Wed, 2006-06-28 at 00:28 -0600, Nate Duehr wrote:
> On Jun 26, 2006, at 3:52 PM, David VanHorn wrote:
>
> > My printer does this.  It does regular DHCP, then the front end  
> > software
> > finds it, presumably with a broadcast to an oddball port or an "are  
> > you my
> > mommy" scan.
>
> Probably "mommy" just sends out a broadcast packet that all  
> "children" know to respond to in a certain way.  If your LAN were a  
> class A (e.g. 10.0.0.0/8) it'd take "mommy" a very long time to find  
> her "children".  :-)

I don't see why. The size of the network doesn't really matter. If you
send out a broadcast packet that the "children" are designed to respond
to the size of the network doesn't matter. The number of children will
impact the response time of the "mommy" though.

In my housemon project
(http://repatch.dyndns.org:8383/pic_stuff/housemon)
all the "children" send out their packets as broadcast packets. This way
they don't care how many "mommies" are present! :) They don't even worry
about having a mommy (poor things...)

Now, if you're talking about an IP scan (something like connect to a
certain port, write something, see if you get the correct response back)
that can take a VERY long time (depending on your timeout).

TTYL

2006\06\28@163546 by Martin Klingensmith

flavicon
face
Yeah, sorry. I should keep my attempts at helping to the easier to read
threads.
--
Martin K

Nate Duehr wrote:

{Quote hidden}

2006\06\29@100439 by Bill & Pookie

picon face
Each device has a unique address.  The master uses a "nick name" of the low
order N bits to pool for unregistered devices.  Using the nick name keeps
too many from responding the poll at same time.  Then the master polls the
device using full name to register it.  And also polls registered devices to
keep them registered.
So it could poll all the registered devices with nick of 1, then poll for
unregistered devices with nick of 1.  Then same with nick of 2...
Would be nice to use a special nick to have all unregistered devices reply.
Quick way to  see if need to do go down list.   And if only one reply, then
poll to register that one.

Said rnuff, got myself confused.

Bill

2006\06\30@131536 by Howard Winter

face
flavicon
picon face
Josh,

Bear in mind that there's the MAC address, 6 bytes long, usually represented in hex as: xx-xx-xx-xx-xx-xx and
this needs to be unique.  Manufacturers assign these from blocks that they are granted (sold!) by the relevant
authorities.  

IP addresses (currently 4 bytes, usually represented in "decimal dot" notation: xxx.xxx.xxx.xxx) are assigned
at run time, either statically by the firmware of the device, aided and abetted by a user, or dynamically by
DHCP...

On Mon, 26 Jun 2006 16:19:29 -0400, Josh Koffman wrote:
>...
> My problem with DHCP is that if I randomly hand out IP addresses, how
> can I ensure that the device at 192.168.1.32 is going to be the same
> each time?

You can't!  It's a bad fit for a device that will be addressed solely by its IP address, rather than a URL.

> The devices I'm thinking about will always need to be
> repeatably addressed based on their physical location, which is
> something that Ethernet doesn't really care about - you can plug your
> cable in anywhere and still get a connection. Perhaps a combo of
> assigning an IP address via DHCP then using the MAC address as an
> identifier?

Various manufacturers of embedded devices use different strategies - most of the Routers, WAPs, Network
Storage units start out with a fixed address and you then have to change it as part of the installation
process - a pain since the address they have chosen may not be on your subnet and you have to reconfigure the
PC to access it and change it to something more useful.  Or worse, they may have chosen an address you're
already using!

Some manufacturers have a piece of PC software that looks for their devices by sending out some sort of
broadcast saying "anyone there?" - the device(s) respond and you can then set their IPs.

However I came across a method I'd not seen before, yesterday.  It's an Axis video server, and its MAC address
is also its serial number, on a label with a bar-code underneath.  Having powered-up the device and connected
to the network, you start up a command-line session on a PC and then enter:

ARP -s <Desired IP address> <MAC address>
PING -l 408 -t <Desired IP address>

This sets up a table entry so that the device is found from that PC as if it was on the IP address you've
entered, and you can then PING it.  I presume the PING allows the device to detect the IP address it's being
given, and perhaps the 408-byte length is a trigger for it to assume that address - anyway, that's what
happens!  Thereafter you can start a browser and set up all the other parameters, using the IP address to
access it - clever!  :-)

Cheers,


Howard Winter
St.Albans, England


2006\06\30@155017 by Gerhard Fiedler

picon face
Howard Winter wrote:

> However I came across a method I'd not seen before, yesterday.  It's an
> Axis video server, and its MAC address is also its serial number, on a
> label with a bar-code underneath.  Having powered-up the device and
> connected to the network, you start up a command-line session on a PC
> and then enter:
>
> ARP -s <Desired IP address> <MAC address> PING -l 408 -t <Desired IP
> address>
>
> This sets up a table entry so that the device is found from that PC as
> if it was on the IP address you've entered, and you can then PING it.  I
> presume the PING allows the device to detect the IP address it's being
> given, and perhaps the 408-byte length is a trigger for it to assume
> that address - anyway, that's what happens!  Thereafter you can start a
> browser and set up all the other parameters, using the IP address to
> access it - clever!  :-)

The help for arp says that the -s entry is "permanent". This may mean that
it survives a reboot... Do you have the entry still in your list after
reboot ("arp -a")? If so, can you still talk to your device after you
remove the static entry?

Gerhard


'[EE] Strategy for addressing embedded Ethernet dev'
2006\07\04@184752 by Nate Duehr
face
flavicon
face
Gerhard Fiedler wrote:

> The help for arp says that the -s entry is "permanent". This may mean that
> it survives a reboot... Do you have the entry still in your list after
> reboot ("arp -a")? If so, can you still talk to your device after you
> remove the static entry?

Who's version of arp?  Not all do this.

Nate

2006\07\04@200951 by Gerhard Fiedler

picon face
Nate Duehr wrote:

> Gerhard Fiedler wrote:
>
>> The help for arp says that the -s entry is "permanent". This may mean that
>> it survives a reboot... Do you have the entry still in your list after
>> reboot ("arp -a")? If so, can you still talk to your device after you
>> remove the static entry?
>
> Who's version of arp?  Not all do this.

Good point :) Mine is WinXP, Howard's probably OS/2. But anyway... my
questions remain.

Gerhard

2006\07\15@065320 by Howard Winter

face
flavicon
picon face
Gerhard,

Sorry for the late reply...

On Fri, 30 Jun 2006 16:49:47 -0300, Gerhard Fiedler wrote:

> The help for arp says that the -s entry is "permanent". This may mean that
> it survives a reboot... Do you have the entry still in your list after
> reboot ("arp -a")? If so, can you still talk to your device after you
> remove the static entry?

I can't remember which machine (of two possibles) I used for the ARP / PING procedure - one runs under Win2k,
the other OS/2, and neither of them have that entry now, so at least one of those versions of ARP doesn't keep
it across a reboot!

And as soon as I'd followed the procedure, other machines on the network could see the device, so I believe
the PING causes the device to start using the included IP address (the ARP obviously doesn't affect the device
itself).

Cheers,


Howard Winter
St.Albans, England


More... (looser matching)
- Last day of these posts
- In 2006 , 2007 only
- Today
- New search...