* [ECOS] Notes on static configuration of an eCos network interface @ 2000-07-17 5:45 Nick Barnes 2000-07-17 6:59 ` Bart Veer ` (2 more replies) 0 siblings, 3 replies; 18+ messages in thread From: Nick Barnes @ 2000-07-17 5:45 UTC (permalink / raw) To: ecos-discuss 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) ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [ECOS] Notes on static configuration of an eCos network interface 2000-07-17 5:45 [ECOS] Notes on static configuration of an eCos network interface Nick Barnes @ 2000-07-17 6:59 ` Bart Veer 2000-07-17 7:07 ` [ECOS] Notes on static configuration of an eCos network inte Gary Thomas 2000-07-18 5:52 ` [ECOS] Notes on static configuration of an eCos network interface Nick Barnes 2000-07-17 8:52 ` Grant Edwards 2000-07-20 7:00 ` Hugo 'NOx' Tyson 2 siblings, 2 replies; 18+ messages in thread From: Bart Veer @ 2000-07-17 6:59 UTC (permalink / raw) To: Nick.Barnes; +Cc: ecos-discuss 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [ECOS] Notes on static configuration of an eCos network inte 2000-07-17 6:59 ` Bart Veer @ 2000-07-17 7:07 ` Gary Thomas 2000-07-18 5:52 ` [ECOS] Notes on static configuration of an eCos network interface Nick Barnes 1 sibling, 0 replies; 18+ messages in thread From: Gary Thomas @ 2000-07-17 7:07 UTC (permalink / raw) To: Bart Veer; +Cc: ecos-discuss, Nick.Barnes 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. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [ECOS] Notes on static configuration of an eCos network interface 2000-07-17 6:59 ` Bart Veer 2000-07-17 7:07 ` [ECOS] Notes on static configuration of an eCos network inte Gary Thomas @ 2000-07-18 5:52 ` Nick Barnes 2000-07-18 8:03 ` Grant Edwards 1 sibling, 1 reply; 18+ messages in thread From: Nick Barnes @ 2000-07-18 5:52 UTC (permalink / raw) To: bartv; +Cc: ecos-discuss 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) ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [ECOS] Notes on static configuration of an eCos network interface 2000-07-18 5:52 ` [ECOS] Notes on static configuration of an eCos network interface Nick Barnes @ 2000-07-18 8:03 ` Grant Edwards 0 siblings, 0 replies; 18+ messages in thread From: Grant Edwards @ 2000-07-18 8:03 UTC (permalink / raw) To: Nick Barnes; +Cc: bartv, ecos-discuss 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [ECOS] Notes on static configuration of an eCos network interface 2000-07-17 5:45 [ECOS] Notes on static configuration of an eCos network interface Nick Barnes 2000-07-17 6:59 ` Bart Veer @ 2000-07-17 8:52 ` Grant Edwards 2000-07-17 9:03 ` [ECOS] Notes on static configuration of an eCos network inte Gary Thomas 2000-07-17 9:45 ` [ECOS] Notes on static configuration of an eCos network interface Hugo 'NOx' Tyson 2000-07-20 7:00 ` Hugo 'NOx' Tyson 2 siblings, 2 replies; 18+ messages in thread From: Grant Edwards @ 2000-07-17 8:52 UTC (permalink / raw) To: Nick Barnes; +Cc: ecos-discuss > 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [ECOS] Notes on static configuration of an eCos network inte 2000-07-17 8:52 ` Grant Edwards @ 2000-07-17 9:03 ` Gary Thomas 2000-07-17 9:28 ` Andrew Lunn 2000-07-17 9:29 ` Grant Edwards 2000-07-17 9:45 ` [ECOS] Notes on static configuration of an eCos network interface Hugo 'NOx' Tyson 1 sibling, 2 replies; 18+ messages in thread From: Gary Thomas @ 2000-07-17 9:03 UTC (permalink / raw) To: Grant Edwards; +Cc: ecos-discuss, Nick Barnes 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. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [ECOS] Notes on static configuration of an eCos network inte 2000-07-17 9:03 ` [ECOS] Notes on static configuration of an eCos network inte Gary Thomas @ 2000-07-17 9:28 ` Andrew Lunn 2000-07-17 9:40 ` Grant Edwards 2000-07-17 9:29 ` Grant Edwards 1 sibling, 1 reply; 18+ messages in thread From: Andrew Lunn @ 2000-07-17 9:28 UTC (permalink / raw) To: Gary Thomas; +Cc: grante, ecos-discuss, Nick.Barnes 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [ECOS] Notes on static configuration of an eCos network inte 2000-07-17 9:28 ` Andrew Lunn @ 2000-07-17 9:40 ` Grant Edwards 2000-07-17 9:47 ` Andrew Lunn 0 siblings, 1 reply; 18+ messages in thread From: Grant Edwards @ 2000-07-17 9:40 UTC (permalink / raw) To: Andrew Lunn; +Cc: Gary Thomas, ecos-discuss, Nick.Barnes > 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [ECOS] Notes on static configuration of an eCos network inte 2000-07-17 9:40 ` Grant Edwards @ 2000-07-17 9:47 ` Andrew Lunn 0 siblings, 0 replies; 18+ messages in thread From: Andrew Lunn @ 2000-07-17 9:47 UTC (permalink / raw) To: Grant Edwards; +Cc: andrew.lunn, gthomas, ecos-discuss, Nick.Barnes > > 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [ECOS] Notes on static configuration of an eCos network inte 2000-07-17 9:03 ` [ECOS] Notes on static configuration of an eCos network inte Gary Thomas 2000-07-17 9:28 ` Andrew Lunn @ 2000-07-17 9:29 ` Grant Edwards 2000-07-17 9:45 ` Gary Thomas 1 sibling, 1 reply; 18+ messages in thread From: Grant Edwards @ 2000-07-17 9:29 UTC (permalink / raw) To: Gary Thomas; +Cc: ecos-discuss, Nick Barnes > > 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [ECOS] Notes on static configuration of an eCos network inte 2000-07-17 9:29 ` Grant Edwards @ 2000-07-17 9:45 ` Gary Thomas 2000-07-17 10:01 ` Grant Edwards 0 siblings, 1 reply; 18+ messages in thread From: Gary Thomas @ 2000-07-17 9:45 UTC (permalink / raw) To: Grant Edwards; +Cc: Nick Barnes, ecos-discuss 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. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [ECOS] Notes on static configuration of an eCos network inte 2000-07-17 9:45 ` Gary Thomas @ 2000-07-17 10:01 ` Grant Edwards 0 siblings, 0 replies; 18+ messages in thread From: Grant Edwards @ 2000-07-17 10:01 UTC (permalink / raw) To: Gary Thomas; +Cc: Nick Barnes, ecos-discuss 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [ECOS] Notes on static configuration of an eCos network interface 2000-07-17 8:52 ` Grant Edwards 2000-07-17 9:03 ` [ECOS] Notes on static configuration of an eCos network inte Gary Thomas @ 2000-07-17 9:45 ` Hugo 'NOx' Tyson 1 sibling, 0 replies; 18+ messages in thread From: Hugo 'NOx' Tyson @ 2000-07-17 9:45 UTC (permalink / raw) To: ecos-discuss 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [ECOS] Notes on static configuration of an eCos network interface 2000-07-17 5:45 [ECOS] Notes on static configuration of an eCos network interface Nick Barnes 2000-07-17 6:59 ` Bart Veer 2000-07-17 8:52 ` Grant Edwards @ 2000-07-20 7:00 ` Hugo 'NOx' Tyson 2000-07-20 9:57 ` Bart Veer 2 siblings, 1 reply; 18+ messages in thread From: Hugo 'NOx' Tyson @ 2000-07-20 7:00 UTC (permalink / raw) To: ecos-discuss 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [ECOS] Notes on static configuration of an eCos network interface 2000-07-20 7:00 ` Hugo 'NOx' Tyson @ 2000-07-20 9:57 ` Bart Veer 2000-07-20 11:00 ` Hugo 'NOx' Tyson 0 siblings, 1 reply; 18+ messages in thread From: Bart Veer @ 2000-07-20 9:57 UTC (permalink / raw) To: ecos-discuss >>>>> "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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [ECOS] Notes on static configuration of an eCos network interface 2000-07-20 9:57 ` Bart Veer @ 2000-07-20 11:00 ` Hugo 'NOx' Tyson 2000-07-20 11:19 ` Bart Veer 0 siblings, 1 reply; 18+ messages in thread From: Hugo 'NOx' Tyson @ 2000-07-20 11:00 UTC (permalink / raw) To: ecos-discuss 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [ECOS] Notes on static configuration of an eCos network interface 2000-07-20 11:00 ` Hugo 'NOx' Tyson @ 2000-07-20 11:19 ` Bart Veer 0 siblings, 0 replies; 18+ messages in thread From: Bart Veer @ 2000-07-20 11:19 UTC (permalink / raw) To: ecos-discuss >>>>> "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 ^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2000-07-20 11:19 UTC | newest] Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2000-07-17 5:45 [ECOS] Notes on static configuration of an eCos network interface Nick Barnes 2000-07-17 6:59 ` Bart Veer 2000-07-17 7:07 ` [ECOS] Notes on static configuration of an eCos network inte Gary Thomas 2000-07-18 5:52 ` [ECOS] Notes on static configuration of an eCos network interface Nick Barnes 2000-07-18 8:03 ` Grant Edwards 2000-07-17 8:52 ` Grant Edwards 2000-07-17 9:03 ` [ECOS] Notes on static configuration of an eCos network inte Gary Thomas 2000-07-17 9:28 ` Andrew Lunn 2000-07-17 9:40 ` Grant Edwards 2000-07-17 9:47 ` Andrew Lunn 2000-07-17 9:29 ` Grant Edwards 2000-07-17 9:45 ` Gary Thomas 2000-07-17 10:01 ` Grant Edwards 2000-07-17 9:45 ` [ECOS] Notes on static configuration of an eCos network interface Hugo 'NOx' Tyson 2000-07-20 7:00 ` Hugo 'NOx' Tyson 2000-07-20 9:57 ` Bart Veer 2000-07-20 11:00 ` Hugo 'NOx' Tyson 2000-07-20 11:19 ` Bart Veer
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).