{5} Accepted, Active Tickets by Owner (Full Description) (33 matches)

To connect to a WPA encrypted network using libbsd it is currently necessary to restart the wpa_supplicant for each new connection. A better solution for that should be found.

In FreeBSD, the wpa_supplicant will somehow automatically be started if the ifconfig_<interface> line or rc.conf contains a WPA (see ​rc.conf(5) section network_interfaces).

The rtems-libbsd should have a similar mechanism. One possibility would be to try to make the dhcpcd script hooks usable on RTEMS and start wpa_supplicant from a hook.

Possible Approaches The DHCP client used in the libbsd (dhcpcd) has a script hook support. That support has been removed in the RTEMS port because there is no script interpreter. One possibility would be to try to make the dhcpcd script hooks usable on RTEMS so that they can call C functions instead of the scripts. Such a hook could then start a wpa_supplicant from a hook. Another solution would be to take a detailed look at the FreeBSD implementation and create something similar.

Additional Problems Most likely it will be necessary to start more then one instance of wpa_supplicant (for example if two interfaces are connected). Currently that is not possible. The wpa_supplicant should be reviewed whether it can be started multiple times in parallel.

Necessary Hardware I would recommend some real hardware (like a Beagle Bone Black with a RTL8188 based USB WiFi?? dongle) and a hardware debugger (Segger J-Link, Flyswatter 2, something supported by OpenOCD, ...). Real hardware with WiFi?? is the most likely later use case. Theoretically WPA should be usable on wired interfaces. So it might be possible to develop this in a simulator too. The advantage of this is that there are no hardware costs and a simple debug integration. If you think about that solution, please discuss it with your (planned) mentor before starting.

Related projects #3222 will need some WiFi?? related rc.conf integration too. Maybe the hot-plug detection of that project could be of some use too.

Skills C programming and understanding of system configuration/administration.

This is a 350-hour project of hard difficulty.

Doing this manually over as many certificates we have is causing too many issues.

This needs to be crontabed for every 30 days safely.

This list of tasks is not exhaustive there are many other changes that need to happen during this transition. It's been close to 9 years since this hardware was setup there is going to be a lot that is missing here.

• Switch jails from no longer maintained EZ-Jail to Bastille
• Update all services to latest version from ports.
• Modernise config files many services use older configurations such as Postfix or require older versions.
• Will require rolling downtime of services during OSL business hours.
• Ticket will be updated with changes as work is completed
• Weekly certificate updates to avoid certificate expiration

• Currently we use more than one system for backups formalise all of this under one system using restic.net

This does not mean we aren't backing up. We need a formal procedure and to use one method across all backups required.

While we can use the same tool to do the backups certain tasks require the additional use of external software or commands such as databases.

• Update firewalls to latest FreeBSD 13.1
• Firewalls are dual redundant and share state using pfysnc
• May require several hours of downtime during OSL business hours.

This needs to be done while the OSL has workers in the case of a severe issue. If it's done outside of typical RTEMS activity there will be noone there to help.

Passing along a report from a user that their IT has blocked pages using TLS 1.2. This impacts at least the RSB downloading patches associated with RTEMS tickets.

Here is their curl verbose output in case it helps:

$ curl -vvvv https://devel.rtems.org/raw-attachment/ticket/4783/0001-checks.c-Ensure-argument-is-an-integer-v2.patch
*   Trying 140.211.10.146...
* TCP_NODELAY set
* Connected to devel.rtems.org (140.211.10.146) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS alert, bad record mac (532):
* error:140943FC:SSL routines:ssl3_read_bytes:sslv3 alert bad record mac
* Closing connection 0
curl: (35) error:140943FC:SSL routines:ssl3_read_bytes:sslv3 alert bad record mac

For some reason either the plugin or trac is ignoring the notify settings. Previously the plugin ignored the CC-all setting now it doesn't. This means the verify emails are getting sent out to bugs.

This is a known issue for trac v1.2 see: ​​https://trac-hacks.org/ticket/8796

Make the collapse boxes change colour when hovering to indicate the box can be clicked.

If a run-time loaded library contains global variables, its load fails because of an unsupported relocation type. The following is the dlerror message:

.text: Unsupported relocation type 26 in non-PLT relocations

After examining the library's object file, the relocation type for the symbol was determined to be R_ARM_GOT_BREL.

I will update the ticket with a small program that reproduces the error within a couple of days.

config: tools/rtems-kernel-4.10.2.cfg
package: arm-rtems4.10-kernel-4.10.2-1
download: http://ftp.rtems.org/pub/rtems/4.10.2/rtems-4.10.2.tar.bz2 -> sources/rtems-4.10.2.tar.bz2

download: http://ftp.rtems.org/pub/rtems/4.10.2/rtems-4.10.2.tar.bz2: error: HTTP Error 404: Not Found
error: downloading http://ftp.rtems.org/pub/rtems/4.10.2/rtems-4.10.2.tar.bz2: all paths have failed, giving up
Build FAILED
  See error report: rsb-report-arm-rtems4.10-kernel-4.10.2-1.txt
error: downloading http://ftp.rtems.org/pub/rtems/4.10.2/rtems-4.10.2.tar.bz2: all paths have failed, giving up
Build Set: Time 0:09:29.097373
error: downloading http://ftp.rtems.org/pub/rtems/4.10.2/rtems-4.10.2.tar.bz2: all paths have failed, giving up
Build Set: Time 0:09:34.367852
Build FAILED

The reports from the RSB do not report the --rsb-file option correctly.

sparc64 hardware shares an interrupt level (14) between tick comparison and software-raised interrupts. current bsps do not handle the situation of both interrupt sources simultaneously, so software interrupts cannot be used when the timer also is used. What happens is the interrupt level (PIL) does not get set/reset properly and interrupts are missed.

The attached patch is a work-around that hacks the clock isr, but I need to look more closely at the generic ISR handling code to see if the bug is due to interactions between PIL assignment, interrupt enable/disable, and scheduling.

Patch submitted, but still needs review/corrections [1]

[1] ​https://lists.rtems.org/pipermail/devel/2020-March/058307.html

This ticket is to monitor progress and RTEMS repos that need to be Clang/LLVM aware. RISC-V is the target backend I work with for RTEMS, and can be used a reference for other architectures.

The new Termios device API is documented here:

​https://docs.rtems.org/branches/master/bsp-howto/console.html

Legacy drivers can be found via the rtems_termios_open() function.

This ticket summarises activities carried out by a 24 month project sponsored by the European Space Agency (ESA). The project start was February 2019.

The main goal of the project is to enable European space missions to use RTEMS as a software product in criticality category C (this is basically category B without independent software verification and validation, ISVV). Criticality category C means according to ​ECSS-Q-ST-80C:

"Software that if not executed, or if not correctly executed, or whose anomalous behaviour can cause or contribute to a system failure resulting in: Major consequences"

In ​ECSS-Q-ST-40C major consequences are characterized in Table 6-1 as a major mission degradation without effects to the outside world of the system. A future activity may perform ISVV to enable a use in category B settings.

The qualification will be done according to ECSS standards (ECSS-E-ST-40C and ECSS-Q-ST-80C). The standards are available at

​http://ecss.nl/

free of charge after registration.

The project consists of four major tasks.

1. Qualification toolchain
   
   This task aims to produce a tool chain so that qualification related work can be carried out efficiently. For example: document generation, test suite runs (including code coverage), test reporting, test result archiving, code metrics, static code analysis, traceability (e.g. requirements to tests), etc.

2. RTEMS SMP qualification data package
   
   This task covers the main RTEMS components (source code, tests, documentation; new: requirements document, ECSS standard tailoring) so that a data package for space mission consumers can be generated.
   
   
   • #3702: Space profile for RTEMS SMP
   • #3703: Technical Specification (TS) for space profile
     • #3715: Add Requirements Engineering chapter to RTEMS Software Engineering Handbook
     • #3726: Select a requirements engineering tool
   • #3705: Software Design Document (SDD) for space profile
     • #3704: Review and update Doxygen recommendations
     • #3706: Create a hierarchy of RTEMS software components using Doxygen groups
     • #3707: Assign each code file to a Doxygen group
     • #3708: Remove Doxygen comments from confdefs.h
   • #3716: Unit, integration and validation tests for space profile
     • #3717: Add test guidelines chapter to RTEMS Software Engineering Handbook
     • #3718: Add support for test plans
     • #3199: New test framework

3. RTEMS SMP formal verification
   
   This is a research project. The aim is to apply formal methods for the verification of a subset of the RTEMS SMP algorithms.

4. RTEMS SMP application porting
   
   The goal of this task is to port an existing uniprocessor space software from RTEMS 4.8 (RTEMS Improvement by Edisoft) to RTEMS SMP. The algorithms used by the software needs to be parallelized.

The project partners are:

• ​Edisoft (prime) and ​CISTER from Portugal

• ​Lero with Lero researchers from Trinity College Dublin and University of Limerick from Ireland

• ​Jena-Optronik GmbH and ​embedded brains GmbH from Germany

The results of this activity should be open source and available to the RTEMS community.