Name of the primary network interface, how to find in bsp header files?

[Chris Johns]

On 10/8/20 4:20 am, Heinz Junkes wrote:
> Hello, Chris,
> 
> with libbsd I also realized this with the concept you suggested (still beta development):
> 
> ...
>     sc = rtems_bsd_initialize();
>     assert(sc == RTEMS_SUCCESSFUL);
> 
>     /* Let the callout timer allocate its resources */
>     sc = rtems_task_wake_after(2);
>     assert(sc == RTEMS_SUCCESSFUL);
> 
>     rtems_bsd_ifconfig_lo0();
> 
> //  lookup available network interfaces
>     char ifnamebuf[IF_NAMESIZE];
>     char *ifname;
> // get primary network interface
>     ifname = if_indextoname(1, &ifnamebuf[0]);
>     assert(ifname != NULL);
>     printf("\n***** Primary Network interface : %s *****\n", ifname);
> 
>     default_network_dhcpcd();
> 
>     // implement DHCP hook  ... and wait for acknowledge
>     dhcpDone = epicsEventMustCreate(epicsEventEmpty);
>     rtems_dhcpcd_add_hook(&dhcpcd_hook);

Is it a requirement for EPICS systems to be DHCP?

>     // wait for dhcp done ... should be if SYNCDHCP is used
>     epicsEventWaitStatus stat;
>     int counter = 10;
>     do {
>         printf("\n ---- Wait for DHCP done ...\n");
>         stat = epicsEventWaitWithTimeout(dhcpDone, 5.0);
>     } while ((stat == epicsEventWaitTimeout) && (--counter > 0));
>     if (stat == epicsEventOK)
>         epicsEventDestroy(dhcpDone);
>     else
>         printf("\n ---- dhcpDone Event Unknown state %d\n", stat);
> …
> 
> static void
> default_network_dhcpcd(void)
> {
>         static const char default_cfg[] = "clientid FHI test client\n";
>         rtems_status_code sc;
>         int fd;
>         int rv;
>         ssize_t n;
> fd = open("/etc/dhcpcd.conf", O_CREAT | O_WRONLY,
>     S_IRWXU | S_IRWXG | S_IRWXO);
> assert(fd >= 0);
> 
> n = write(fd, default_cfg, sizeof(default_cfg) - 1);
> assert(n == (ssize_t) sizeof(default_cfg) - 1);
> 
> 
> static const char fhi_cfg[] = "nodhcp6\nipv4only\noption ntp_servers\noption rtems_cmdline\n";

What is `option rtems_cmdline? Is this a special EPICS option?

There is no `allowinterfaces` so it seems this is for a single interface machine.

While this may work for the qemu testrig we will need something more for the RSB
configuration.

> 
> n = write(fd, fhi_cfg, sizeof(fhi_cfg) - 1);
> assert(n == (ssize_t) sizeof(fhi_cfg) - 1);
> 
> rv = close(fd);
> assert(rv == 0);
> 
> sc = rtems_dhcpcd_start(NULL);
> assert(sc == RTEMS_SUCCESSFUL);
> }
> 
> static void
> dhcpcd_hook_handler(rtems_dhcpcd_hook *hook, char *const *env)
> {
> int bound = 0;
> char iName[16];
> char *name;
> char *value;
> 
>         (void)hook;
> 
>         while (*env != NULL) {
>                 name = strtok(*env,"=");
>                 value = strtok(NULL,"=");
>         printf("all out ---> %s = %s\n", name, value);
>                 if (!strncmp(name, "interface", 9) && !strcmp(value,  NET_CFG_INTERFACE_0))
>                          strncpy(iName, value, 16);
>                 if (!strncmp(name, "reason", 6) && !strncmp(value, "BOUND", 5)){
>                   printf ("Interface %s bounded\n", iName);
>                   bound = 1;
>                 }
>                 if (bound) {
>                   // as there is no ntp-support in rtems-libbsd, we call our own client
>                   if(!strncmp(name, "new_ntp_servers", 15))
>                     strcpy(rtemsInit_NTP_server_ip,value);
>                   if(!strncmp(name, "new_host_name", 13))
>                     sethostname (value, strlen (value));
>                   if(!strncmp(name, "new_tftp_server_name", 20)){
>                     printf(" new_tftp_server_name : %s\n", value);
>                     strncpy(rtems_bsdnet_bootp_server_name,value, sizeof(bootp_server_name_init));
>                   }
> 
>                   printf("---> %s = %s\n", name, value);
>                 }
>                 ++env;
>         }
> if (bound)
>   epicsEventSignal(dhcpDone);
> }
> 
> static rtems_dhcpcd_hook dhcpcd_hook = {
>         .name = "ioc boot",
>         .handler = dhcpcd_hook_handler
> };
> 
> But the biggest problem here is that on the test-CI-system (travis, appveyor, etc.) a dhcp-server, 
> ntp-server, nfs-server and complex routing structures for e.g. qemu must be provided. 

Yes I am sure it is complicated. Is your work just focused on this test set up?

> There it is easier to use environment variables.

In the hook I suspect it is the simplest.

Chris

> 
> Many greetings
> Heinz 
> 
> 
>> On 9. Aug 2020, at 02:44, Chris Johns <chrisj at rtems.org> wrote:
>>
>>> nging configuration. And likely only one NIC.
>>
>> Agreed and it works for a testsuite to some extent. Network tests are hard
>> because you need a very controlled network set up to make then work.
>>
>>> It was used in the network demos for the legacy stack so if we want to
>>> eliminate it completely, it would be good to find a recommended way to
>>> look up the interface name and put it into the legacy configuration
>>> tables.
>>>
>>> https://git.rtems.org/network-demos/tree  
>>>
>>> Yes... I know we all want to see it removed and everyone move to
>>> libbsd. But I don't think that is realistic to expect. The more realistic
>>> solution is to move it to its own build tree and freeze it. It is there
>>> and we encourage people to use libbsd. But it does offer a solution
>>> for older target boards. The old stack is also all that is supported by
>>> many EPICS boards. Outside of EPICS users, even the SPARC BSPs 
>>> haven't been converted yet.
>>
>> Yes we should move it out of the main tree and have it becomes an available
>> optional package. It can be maintained by those with an active interest in it.
>>
>> It has some bugs ... we found one last year with the arp cache and Windows. The
>> solution was a hack to set the arp aging timer to a very large number.
>>
>>> Anyway... I'd love to see RTEMS_BSP_NETWORK_DRIVER_NAME
>>> killed completely but we need to address filling in the legacy network
>>> stack table before the stack is initialized enough to even know the 
>>> interface names.
>>
>> Yes, but Heinz is working on libbsd support for EPICS or have I missed something?
>>
>>> Perhaps this turns into an application provided method for the legacy
>>> stack? Just a thought.
>>
>> Yes that works.
>>
>> Chris
>