[ECOS] Notes on static configuration of an eCos network interface

[ECOS] Notes on static configuration of an eCos network interface

[Nick Barnes]

Notes on static configuration of an eCos network interface

1. Static interface configuration

A simple single-interface static configuration looks like this:

- IP address;
- subnet mask;
- broadcast address;
- default router IP address.

On occasion, there may be more than one router on the subnet, and in
that case there may be multiple routes (destination/mask/router
triplets).

In any case, these correspond to the following information in a BOOTP
message:

IP address:      ciaddr, or yiaddr if ciaddr was 0
subnet mask:     TAG_SUBNET_MASK
broadcast:       TAG_IP_BROADCAST
router address:  TAG_GATEWAY
multiple routes: TAG_IP_STATIC_ROUTES

The siaddr and giaddr fields of a BOOTP message are irrelevant to
configuring a network interface: they are used for talking to the
BOOTP server (e.g. for TFTPing a kernel).

2. Using the eCos config tool

Currently, the config tool defines the following five fields (for
eth0):

CYGHWR_NET_DRIVER_ETH0_ADDRS_IP
CYGHWR_NET_DRIVER_ETH0_ADDRS_NETMASK
CYGHWR_NET_DRIVER_ETH0_ADDRS_BROADCAST
CYGHWR_NET_DRIVER_ETH0_ADDRS_GATEWAY
CYGHWR_NET_DRIVER_ETH0_ADDRS_SERVER

Note that the "SERVER" field is meaningless on a non-bootp system.
Note that there's no way of setting up multiple static routes.

3. Building a BOOTP record

Then build_bootp_record() in network_support.c builds a bootp record
from this information as follows:

ciaddr = yiaddr = IP            ; good
siaddr = SERVER                 ; irrelevant
giaddr = GATEWAY                ; irrelevant
TAG_SUBNET_MASK : NETMASK       ; good
TAG_IP_BROADCAST : BROADCAST    ; good

Note that the GATEWAY field is plugged into giaddr, which tells the
BOOTP client what BOOTP gateway was used to talk to the BOOTP server
(named by SERVER).  This field is irrelevant for a non-bootp system.
So the "GATEWAY" config information is effectively thrown away.

I added code last week to add this to the bootp record:

TAG_GATEWAY : GATEWAY           ; if you add the code I posted last week

4. Initializing the interface

Then init_net() in bootp_support.c uses this bootp record to set up
the interface as follows:

SIOCSIFADDR, yiaddr                               ; good
SIOCSIFNETMASK, TAG_SUBNET_MASK                   ; good
SIOCSIFBRDADDR, TAG_IP_BROADCAST                  ; good
SIOCADDRT, yiaddr & netmask, netmask, TAG_GATEWAY ; bogus

This last line is bogus because the destination field (yiaddr &
netmask) is just the local subnet.  An interface configured like this
can't send packets outside the local subnet.  Suppose that the local
machine is 192.168.42.42/24, and the gateway is 192.168.42.69.  Then
this last gateway line sets up the following route:

route add 192.168.42.0 192.168.42.69 -netmask 255.255.255.0

That is, packets to the local subnet should be routed via the router.

In fact, to specify a default route, you should have a zero mask, and
can have a zero destination as well:

SIOCADDRT, 0, 0, TAG_GATEWAY                     ; better!

5. Recommendations

5.1. Config tool

Assuming the simple situation, with a default router and without
multiple static routes.  Then the config tool should be set up to
allow the specification of:

- IP address;           (as at present)
- subnet mask;          (as at present)
- broadcast address;    (as at present)
- router IP address.    ("gateway" at present)

and _not_ "server", which is a meaningless idea in the absence of
BOOTP.

5.2. building a BOOTP record:

build_bootp_record() shouldn't bother setting siaddr or giaddr, but
should put this information into the BOOTP record:

ciaddr = yiaddr = IP
TAG_SUBNET_MASK : NETMASK
TAG_IP_BROADCAST : BROADCAST
TAG_GATEWAY : GATEWAY

5.3. initializing the interface:

init_net() should initialize the interface as follows:

SIOCSIFADDR, yiaddr
SIOCSIFNETMASK, TAG_SUBNET_MASK
SIOCSIFBRDADDR, TAG_IP_BROADCAST
SIOCADDRT, 0, 0, TAG_GATEWAY

5.4. multiple static routes

The config tool, build_bootp_record() and init_net() should be
extended to allow the specification of multiple static routes, through
TAG_IP_STATIC_ROUTES.

5.5. DNS

A DNS resolver should be added and supported through
TAG_DOMAIN_SERVER.

Nick B

--
FreeBSD 2.2.8-RELEASE: up 15 days, 18:35
last reboot Sat Jul 1 19:26 (lightning strike)

Re: [ECOS] Notes on static configuration of an eCos network interface

[Bart Veer]

I am not qualified to answer most of these points, but:

>>>>> "Nick" == Nick Barnes <Nick.Barnes@pobox.com> writes:
    Nick> Notes on static configuration of an eCos network interface

    <snip>
    Nick> 5.4. multiple static routes

    Nick> The config tool, build_bootp_record() and init_net() should
    Nick> be extended to allow the specification of multiple static
    Nick> routes, through TAG_IP_STATIC_ROUTES.

The current implementation of CDL does not allow for multiple
instantiations of something, e.g. you cannot have a configuration
option that says I want n routes, and then configuration options
are created on the fly to support the new routes (or existing
configuration options are removed).

Instead you could have an upper bound on the number of such routes and
have the appropriate number of config options. Or you could put
multiple routes into one configuration value, although extracting all
the information at compile-time can then prove tricky. Alternatively
the configury would support only the most common situation of a single
route, with an opt-out to defer the whole thing to application code.
I am not sure which of these approaches would be most appropriate in
this case.

Bart

Re: [ECOS] Notes on static configuration of an eCos network inte

[Gary Thomas]

On 17-Jul-2000 Bart Veer wrote:
> I am not qualified to answer most of these points, but:
> 
>>>>>> "Nick" == Nick Barnes <Nick.Barnes@pobox.com> writes:
>     Nick> Notes on static configuration of an eCos network interface
> 
>     <snip>
>     Nick> 5.4. multiple static routes
> 
>     Nick> The config tool, build_bootp_record() and init_net() should
>     Nick> be extended to allow the specification of multiple static
>     Nick> routes, through TAG_IP_STATIC_ROUTES.
> 
> The current implementation of CDL does not allow for multiple
> instantiations of something, e.g. you cannot have a configuration
> option that says I want n routes, and then configuration options
> are created on the fly to support the new routes (or existing
> configuration options are removed).
> 
> Instead you could have an upper bound on the number of such routes and
> have the appropriate number of config options. Or you could put
> multiple routes into one configuration value, although extracting all
> the information at compile-time can then prove tricky. Alternatively
> the configury would support only the most common situation of a single
> route, with an opt-out to defer the whole thing to application code.
> I am not sure which of these approaches would be most appropriate in
> this case.
> 

Since these are just strings (IP dot notation) in the CDL, we could probably
make the code that processes them more flexible and handle the case of 
multiple addresses separated by spaces.

Re: [ECOS] Notes on static configuration of an eCos network interface

[Grant Edwards]

> Notes on static configuration of an eCos network interface

> The siaddr and giaddr fields of a BOOTP message are irrelevant to
> configuring a network interface: they are used for talking to the
> BOOTP server (e.g. for TFTPing a kernel).

Aaargh.  That's why my routing table isn't getting initialized.

> init_net() should initialize the interface as follows:
> 
> SIOCSIFADDR, yiaddr
> SIOCSIFNETMASK, TAG_SUBNET_MASK
> SIOCSIFBRDADDR, TAG_IP_BROADCAST
> SIOCADDRT, 0, 0, TAG_GATEWAY

Right now, I'm building a fake bootp record and passing it to
init_net().  This seems to be way more work than it's worth
(especially since it's not right), so I'm going to throw out
all of the fake bootp stuff and just duplicate the code in
net_init(), passing the right IP addresses in the ioctl() calls.

It will end up being a lot smaller and simpler that way. Is
there any reason I shouldn't do that?

-- 
Grant Edwards
grante@visi.com

Re: [ECOS] Notes on static configuration of an eCos network inte

[Gary Thomas]

On 17-Jul-2000 Grant Edwards wrote:
> 
>> Notes on static configuration of an eCos network interface
> 
>> The siaddr and giaddr fields of a BOOTP message are irrelevant to
>> configuring a network interface: they are used for talking to the
>> BOOTP server (e.g. for TFTPing a kernel).
> 
> Aaargh.  That's why my routing table isn't getting initialized.
> 
>> init_net() should initialize the interface as follows:
>> 
>> SIOCSIFADDR, yiaddr
>> SIOCSIFNETMASK, TAG_SUBNET_MASK
>> SIOCSIFBRDADDR, TAG_IP_BROADCAST
>> SIOCADDRT, 0, 0, TAG_GATEWAY
> 
> Right now, I'm building a fake bootp record and passing it to
> init_net().  This seems to be way more work than it's worth
> (especially since it's not right), so I'm going to throw out
> all of the fake bootp stuff and just duplicate the code in
> net_init(), passing the right IP addresses in the ioctl() calls.
> 
> It will end up being a lot smaller and simpler that way. Is
> there any reason I shouldn't do that?

The reason that init_net() is based on BOOTP now is for flexibility.
By having the numbers hard coded [somehow] in the routine, you loose
all of that.

I always vote for flexible; I've been bitten by "fixed" implementations
too many times in the past.

As for your pain:
 * why do you think the current way of creating BOOTP data is more
   work than coding the values directly?
 * how is what you are using different than the code in "init_all_network..."
   when non-BOOTP mode is selected?
 * if things aren't working, ask for help.  Nick [Barnes] seems to be
   getting quite a lot [of feedback at least] by doing so.

Re: [ECOS] Notes on static configuration of an eCos network inte

[Andrew Lunn]

Time to chip my two pence worth in.

1) I think having the ability to statically defined IP addresses
inside the binary is a bad idea. Its so easy to get the same binary
running on two boards at once. The two boards then have the same IP
addresses active on the network. At best one will fail with an panic,
at worst all sorts of flaky things happen. Id remove this feature all
together. If people want to build static addresses in they can bring
the interfaces up themselfs with the addresses.

2) Until recently, build_bootp_record has not been available becasue
it was declared static and only compiled if you did want to use bootp
to get IP addresses. I pointed this out and i beleave this will be fix
in the next release. This made it messy to use so i just cut&pasted it
into my own code and then modified it to my own needs. I think this is
one area you need to do some more testing. From your tests it looks
like you never test bringing up interfaces with application supplied
addresses. 

>  * how is what you are using different than the code in "init_all_network..."
>    when non-BOOTP mode is selected?

First re-read the message i posted about this last week.

init_all_network interfaces assums you want to do one off...

1) Use bootp
2) Use static ip addresses which are configured by the config tool.

It has problems when you want to use the logical third option

3) The application supplies its own addresses.

and is impossible if you want to

4) application supplies some addresses and bootp is used for others.

In my case i get them from flash, so they are board specific, not
binary specific. As i said in my last message, it not so easy to get
it right, especially when init_all_network... keeps changing with
every release. Thats why i asked for a review off all this when DHCP
is added. init_all_network... should be
init_all_unintializes_network...

        Andrew
 

Re: [ECOS] Notes on static configuration of an eCos network inte

[Grant Edwards]

> > Right now, I'm building a fake bootp record and passing it to
> > init_net().  This seems to be way more work than it's worth
> > (especially since it's not right), so I'm going to throw out
> > all of the fake bootp stuff and just duplicate the code in
> > net_init(), passing the right IP addresses in the ioctl() calls.
> > 
> > It will end up being a lot smaller and simpler that way. Is
> > there any reason I shouldn't do that?
> 
> The reason that init_net() is based on BOOTP now is for flexibility.
> By having the numbers hard coded [somehow] in the routine, you loose
> all of that.

The numbers aren't hard-coded.  I have a structure that
contains the ip address, subnet mask, and default gateway. This
data was constructed by my boot loader code.

> I always vote for flexible; I've been bitten by "fixed"
> implementations too many times in the past.
> 
> As for your pain:
>  * why do you think the current way of creating BOOTP data is more
>    work than coding the values directly?

Perhaps I've misjudged, but at first glance it looked like
constructing a fake bootp frame and then parsing it is more
work than making the ioctl calls directly -- and then I don't
need to keep the routines to first assemble then dissassemble a
bootp frame (not that they're very big, but a few K here and
there add up).

>  * how is what you are using different than the code in "init_all_network..."
>    when non-BOOTP mode is selected?

It isn't. The code I'm using is mostly copied from
init_all_network and build_bootp_record. It looks like
build_bootp_record and init_all_network_interfaces don't
configure the default route based on the gateway address passed
to build_bootp_record().

>  * if things aren't working, ask for help.  Nick [Barnes] seems to be
>    getting quite a lot [of feedback at least] by doing so.

I realized that the routing wasn't working this morning.  By
the time I realized something was wrong, Nick had already
pointed out what it was (he must have borrowed Guido van
Rossum's time machine).

-- 
Grant Edwards
grante@visi.com

Re: [ECOS] Notes on static configuration of an eCos network inte

[Grant Edwards]

> Time to chip my two pence worth in.
> 
> 1) I think having the ability to statically defined IP
> addresses inside the binary is a bad idea.

I guess I wasn't clear.  My IP addresses aren't hard-wired in
the source code.  They're retrieved from flash.  The change I'm
thinking of making is instead of taking those addresses and
building a bootp frame to pass to init_net(), I'll just make
the ioctl() calls.  That eliminates the need for the routines
to build/parse bootp records, and the network initialization
happens where it's obvious what's going on.

> In my case i get them from flash, so they are board specific, not
> binary specific. 

Same here.

> As i said in my last message, it not so easy to get
> it right, especially when init_all_network... keeps changing with
> every release. Thats why i asked for a review off all this when DHCP
> is added. init_all_network... should be
> init_all_unintializes_network...

-- 
Grant Edwards
grante@visi.com

Re: [ECOS] Notes on static configuration of an eCos network interface

[Hugo 'NOx' Tyson]

Grant Edwards <grante@visi.com> writes:
> > Notes on static configuration of an eCos network interface
> 
> > The siaddr and giaddr fields of a BOOTP message are irrelevant to
> > configuring a network interface: they are used for talking to the
> > BOOTP server (e.g. for TFTPing a kernel).
> 
> Aaargh.  That's why my routing table isn't getting initialized.
> 
> > init_net() should initialize the interface as follows:
> > 
> > SIOCSIFADDR, yiaddr
> > SIOCSIFNETMASK, TAG_SUBNET_MASK
> > SIOCSIFBRDADDR, TAG_IP_BROADCAST
> > SIOCADDRT, 0, 0, TAG_GATEWAY
> 
> Right now, I'm building a fake bootp record and passing it to
> init_net().  This seems to be way more work than it's worth
> (especially since it's not right), so I'm going to throw out
> all of the fake bootp stuff and just duplicate the code in
> net_init(), passing the right IP addresses in the ioctl() calls.
> 
> It will end up being a lot smaller and simpler that way. Is
> there any reason I shouldn't do that?

None whatsoever!  Using the ioctl() calls will always be right.  And that
way you know what you'll be getting, and how it'll be set up, rather than
depending on what we happen to have put in as helpful examples and for the
convenience of our test programs.

	- Huge

Re: [ECOS] Notes on static configuration of an eCos network inte

[Gary Thomas]

On 17-Jul-2000 Grant Edwards wrote:
>> > Right now, I'm building a fake bootp record and passing it to
>> > init_net().  This seems to be way more work than it's worth
>> > (especially since it's not right), so I'm going to throw out
>> > all of the fake bootp stuff and just duplicate the code in
>> > net_init(), passing the right IP addresses in the ioctl() calls.
>> > 
>> > It will end up being a lot smaller and simpler that way. Is
>> > there any reason I shouldn't do that?
>> 
>> The reason that init_net() is based on BOOTP now is for flexibility.
>> By having the numbers hard coded [somehow] in the routine, you loose
>> all of that.
> 
> The numbers aren't hard-coded.  I have a structure that
> contains the ip address, subnet mask, and default gateway. This
> data was constructed by my boot loader code.
> 

The idea was [the hope was] that the required data would be exactly what
BOOTP provides if used.  Having you mimic BOOTP was supposed to make
this easier.

I haven't looked at how the DHCP support has changed this, so maybe it
will improve.  If not, we're certainly open to listening to what you need.

Re: [ECOS] Notes on static configuration of an eCos network inte

[Andrew Lunn]

> > 1) I think having the ability to statically defined IP
> > addresses inside the binary is a bad idea.
> 
> I guess I wasn't clear.

I was not meaning you in particular. I don't like eCos having the
feature at all. It seems like a good way to shoot yourself in the
foot. 

        Andrew

Re: [ECOS] Notes on static configuration of an eCos network inte

[Grant Edwards]

On Mon, Jul 17, 2000 at 10:45:44AM -0600, Gary Thomas wrote:

> > The numbers aren't hard-coded.  I have a structure that
> > contains the ip address, subnet mask, and default gateway. This
> > data was constructed by my boot loader code.
> 
> The idea was [the hope was] that the required data would be
> exactly what BOOTP provides if used.  Having you mimic BOOTP
> was supposed to make this easier.

It would -- except that the boot loader code that builds the
structure containing the IP info already existed, and rather
than modify that code (it's built under DOS with ARM tools -- I
mess with it as little as possible), I just passed the IP
addresses it provides to my copy of build_bootp_record which
puts the gateway address in the bp_giaddr.s_addr feild instead
of adding it to the body with TAG_GATEWAY as it should.

The right thing to do would be:

 1) Port the boot-loader over to the gnu toolset.  Right now
    it's a royal PITA to work with.

 2) Change the boot loader so that it exports a bootp record
    instead of our home-made structure -- if there's no IP info
    in flash it will use DHCP to get an address, but then it
    tears apart the bootp response and puts the info into the
    aforementioned structure.

Then I wouldn't need my hacked version of build_bootp_record.

> I haven't looked at how the DHCP support has changed this, so
> maybe it will improve.  If not, we're certainly open to
> listening to what you need.

What I really need is some spare time...

;)

-- 
Grant Edwards
grante@visi.com

Re: [ECOS] Notes on static configuration of an eCos network interface

[Nick Barnes]

At 2000-07-17 13:59:42+0000, Bart Veer writes:
> I am not qualified to answer most of these points, but:
> 
> >>>>> "Nick" == Nick Barnes <Nick.Barnes@pobox.com> writes:
>     Nick> Notes on static configuration of an eCos network interface
> 
>     <snip>
>     Nick> 5.4. multiple static routes
> 
>     Nick> The config tool, build_bootp_record() and init_net() should
>     Nick> be extended to allow the specification of multiple static
>     Nick> routes, through TAG_IP_STATIC_ROUTES.
> 
> The current implementation of CDL does not allow for multiple
> instantiations of something, e.g. you cannot have a configuration
> option that says I want n routes, and then configuration options
> are created on the fly to support the new routes (or existing
> configuration options are removed).
> 
> Instead you could have an upper bound on the number of such routes and
> have the appropriate number of config options. Or you could put
> multiple routes into one configuration value, although extracting all
> the information at compile-time can then prove tricky. Alternatively
> the configury would support only the most common situation of a single
> route, with an opt-out to defer the whole thing to application code.
> I am not sure which of these approaches would be most appropriate in
> this case.

Either way.  This isn't very important to me.

Another option would be to have a single string option for additional
static routes, which is then parsed in network_support.c.

It's an interesting problem.  As other writers have pointed out,
there's a case for taking this out of the kernel configuration
altogether.  For my project I'm now intending to use the ioctl()s
directly, and never call init_all_network_interfaces().

Nick B


--
FreeBSD 2.2.8-RELEASE: up 16 days, 18:42
last reboot Sat Jul 1 19:26 (lightning strike)

Re: [ECOS] Notes on static configuration of an eCos network interface

[Grant Edwards]

On Tue, Jul 18, 2000 at 01:52:06PM +0100, Nick Barnes wrote:

> > Instead you could have an upper bound on the number of such routes and
> > have the appropriate number of config options. Or you could put
> > multiple routes into one configuration value, although extracting all
> > the information at compile-time can then prove tricky. Alternatively
> > the configury would support only the most common situation of a single
> > route, with an opt-out to defer the whole thing to application code.
> > I am not sure which of these approaches would be most appropriate in
> > this case.
> 
> Either way.  This isn't very important to me.
> 
> Another option would be to have a single string option for additional
> static routes, which is then parsed in network_support.c.
> 
> It's an interesting problem.  As other writers have pointed out,
> there's a case for taking this out of the kernel configuration
> altogether.  

It's handy having a default configuration when writing test
programs, but my real applications will all configure the
network "manually", since I don't know until run-time whether
to use bootp/DHCP or not.

> For my project I'm now intending to use the ioctl()s
> directly, and never call init_all_network_interfaces().

Yesterday I changed over to calling the ioctl()s directly.  So
far it seems to be working. The eCos system is trying to use
the router I configure, but I don't have one on the network
right now, so I've got to set up one of my Linux machines as a
router to make sure.

FWIW, here's the init code I'm using:


void StackInit( void )
{
  int s,rc;
  struct sockaddr_in *addrp;
  struct ifreq ifr;
  int one = 1;
  struct ecos_rtentry route;
#ifdef MTM_NET_DEBUG
  extern int net_debug;
  net_debug = 1;
#endif
  
  if ( DhcpData.MyIpAddr == 0 )   // not gonna do ip
    return;  

  s = socket(AF_INET, SOCK_DGRAM, 0);
  
  if (s < 0)
    {
      diag_printf("socket: %d\n",s);
      return;
    }

  if ((rc=setsockopt(s, SOL_SOCKET, SO_BROADCAST, &one, sizeof(one))))
    {
      diag_printf("setsockopt: %d\n",rc);
      close(s);
      return;
    }
  
  strcpy(ifr.ifr_name, "eth0");
  
  addrp = (struct sockaddr_in *) &ifr.ifr_addr;

  memset(addrp, 0, sizeof(*addrp));
  addrp->sin_family = AF_INET;
  addrp->sin_len = sizeof(*addrp);
  addrp->sin_port = 0;
  
  addrp->sin_addr.s_addr = DhcpData.MyIpAddr;
  if ((rc=ioctl(s, SIOCSIFADDR, &ifr)))
    {
      diag_printf("SIOCSIFADDR: %d\n",rc);
      close(s);
      return;
    }
  
  addrp->sin_addr.s_addr = DhcpData.SubnetMask;
  if ((rc=ioctl(s, SIOCSIFNETMASK, &ifr))) 
    {
      diag_printf("SIOCSIFNETMASK: %d\n",rc);
      close(s);
      return;
    }

  addrp->sin_addr.s_addr =  ~DhcpData.SubnetMask | DhcpData.Subnet;
  if ((rc=ioctl(s, SIOCSIFBRDADDR, &ifr)))
    {
      diag_printf("SIOCSIFBRDADDR: %d\n",rc);
      close(s);
      return;
    }

  // Set up routing
  
  diag_printf("   IP = %08x\n", DhcpData.MyIpAddr);
  diag_printf(" Mask = %08x\n", DhcpData.SubnetMask);
  diag_printf(" Gate = %08x\n", DhcpData.Gateways[0]);
  
  memset(&route, 0, sizeof(route));
  
  addrp->sin_addr.s_addr = 0;
  memcpy(&route.rt_dst, addrp, sizeof(*addrp));
  memcpy(&route.rt_genmask, addrp, sizeof(*addrp));
  
  addrp->sin_addr.s_addr = DhcpData.Gateways[0];
  memcpy(&route.rt_gateway, addrp, sizeof(*addrp));
  
  route.rt_dev = ifr.ifr_name;
  route.rt_flags = RTF_UP|RTF_GATEWAY;
  route.rt_metric = 0;
  
  if ((rc=ioctl(s, SIOCADDRT, &route)))
    diag_printf("Route Failed: %d\n",rc);
  else
    {
      diag_printf("Net init complete.\n");
      StackOk = 1;
    }
  close(s);
}


-- 
Grant Edwards
grante@visi.com

Re: [ECOS] Notes on static configuration of an eCos network interface

[Hugo 'NOx' Tyson]

Hi Nick; I've finally made time to have a read at that.  I'll probably put
in some of your requests/recommendations, thanks, all good stuff.

One specific comment springs to mind: 
> 5.1. Config tool
> 
> Assuming the simple situation, with a default router and without
> multiple static routes.  Then the config tool should be set up to
> allow the specification of:
> ....
> and _not_ "server", which is a meaningless idea in the absence of BOOTP.

Indeed it is meaningless BUT several of our test programs use the server
address as "someone to talk to" so it's worth IMHO having it settable in
static configurations.  Eg. ftp test, tftp test, ping tests and the like
expect the "server" to be a nice freindly chap.

So I'm definitely leaving it in, but with more comment to that effect...

	- Huge

Re: [ECOS] Notes on static configuration of an eCos network interface

[Bart Veer]

>>>>> "Huge" == Hugo 'NOx' Tyson <hmt@cygnus.co.ukx> writes:

    Huge> One specific comment springs to mind: 
    >> 5.1. Config tool
    >> 
    >> Assuming the simple situation, with a default router and without
    >> multiple static routes.  Then the config tool should be set up to
    >> allow the specification of:
    >> ....
    >> and _not_ "server", which is a meaningless idea in the absence of BOOTP.

    Huge> Indeed it is meaningless BUT several of our test programs
    Huge> use the server address as "someone to talk to" so it's worth
    Huge> IMHO having it settable in static configurations. Eg. ftp
    Huge> test, tftp test, ping tests and the like expect the "server"
    Huge> to be a nice freindly chap.

That is horrible (IMHO). Setting up such addresses should be handled
by the test harness, e.g. by updating a suitable variable via gdb, and
not by configuration options. Not possible right now, but it will have
to be addressed as the test harness progresses.

    Huge> So I'm definitely leaving it in, but with more comment to
    Huge> that effect...

For now, OK.

Bart

Re: [ECOS] Notes on static configuration of an eCos network interface

[Hugo 'NOx' Tyson]

Bart Veer <bartv@redhat.com> writes:
> >>>>> "Huge" == Hugo 'NOx' Tyson <hmt@cygnus.co.ukx> writes:
>     >> and _not_ "server", which is a meaningless idea in the absence of
>     >> BOOTP. 
> 
>     Huge> Indeed it is meaningless BUT several of our test programs
>     Huge> use the server address as "someone to talk to" so it's worth
>     Huge> IMHO having it settable in static configurations. Eg. ftp
>     Huge> test, tftp test, ping tests and the like expect the "server"
>     Huge> to be a nice freindly chap.
> 
> That is horrible (IMHO). Setting up such addresses should be handled
> by the test harness, e.g. by updating a suitable variable via gdb, and
> not by configuration options. Not possible right now, but it will have
> to be addressed as the test harness progresses.

I was under the impression that we aimed to let customers test their own
configurations, by providing test programs which will work correctly in
such a configuration.  What you suggest may be cleaner, but it directly
defeats the goal of being able to automatically run at least *some* of the
network tests.

However, network testing is rather a special case...

	- Huge

Re: [ECOS] Notes on static configuration of an eCos network interface

[Bart Veer]

>>>>> "Huge" == Hugo 'NOx' Tyson <hmt@cygnus.co.ukx> writes:

    Huge> Bart Veer <bartv@redhat.com> writes:
    >> >>>>> "Huge" == Hugo 'NOx' Tyson <hmt@cygnus.co.ukx> writes:
    >> >> and _not_ "server", which is a meaningless idea in the absence of
    >> >> BOOTP. 
    >> 
    Huge> Indeed it is meaningless BUT several of our test programs
    Huge> use the server address as "someone to talk to" so it's worth
    Huge> IMHO having it settable in static configurations. Eg. ftp
    Huge> test, tftp test, ping tests and the like expect the "server"
    Huge> to be a nice freindly chap.
    >> 
    >> That is horrible (IMHO). Setting up such addresses should be handled
    >> by the test harness, e.g. by updating a suitable variable via gdb, and
    >> not by configuration options. Not possible right now, but it will have
    >> to be addressed as the test harness progresses.

    Huge> I was under the impression that we aimed to let customers
    Huge> test their own configurations, by providing test programs
    Huge> which will work correctly in such a configuration. What you
    Huge> suggest may be cleaner, but it directly defeats the goal of
    Huge> being able to automatically run at least *some* of the
    Huge> network tests.

Configuring the host-side environment (which host serial port gets
used to talk to the target board, what local machines can be used for
network operations, how to access the webcam so that the test harness
can check that LEDs flash when they are supposed to, ...) should be
separate from configuring the target-side. At the point that a test
case is run there should be a suitable transfer of information. A
change in the host-side setup should not require any target-side
configury or rebuilding.

For example, if a technical support customer were to send in a
configuration savefile that is causing problems then we should be able
to rebuild directly from that savefile, with no need to edit the
target-side configuration to match our host-side setup.

This is not possible right now because we do not do a very good job of
host-side setup configury yet. Until then ad hoc approaches such as
server address config options may have to be used, but long term there
are better solutions.

Bart