• Suivre les pratiques de sécurité et le style de code d'OpenBSD
  • Utiliser de manière cohérente style(9) pour tout le code du noyau.
  • Éviter l'analyse complexe dans le noyau, ce qui peut amener à ne pas mettre en œuvre certaines caractéristiques du protocole.
  • Utiliser de manière cohérente style(9), pledge(2) et unveil(2) au sein du code en espace utilisateur.
  • Utiliser la séparation des privilèges lors de l'analyse des données depuis le réseau, un modem ou un disque.
• Garder l'ensemble du code de base aussi libre que possible (au moins aussi libre qu'en amont d'OpenBSD)

• Fournir une pile réseau complète pour l'amateur radio sous OpenBSD
• Une prise en charge KISS TNC :
  • une nouvelle ligne de discipline kiss(4)
  • être capable d'utiliser tout tty(4) incluant pty(4)
  • attaché via ldattach(8) (qui peut être fait durant netstart(8))
• Un support de la couche de liaison ax25(4)
  • TCP/IP encapsulé dans AX.25, en donnant simplement à l'interface une adresse IP.
    • Compatible avec les hôtes sous Linux
  • la prise en charge des sockets AF_AX25, seulement la couche de protocole de niveau 2 (non routée), incluant :
    • les frames SOCK_DGRAM — AX.25
• La dissection d'AX25 par tcpdump(8)
• Une nouvelle interface réseau kiss(4) pour AX.25 sur KISS
• Une nouvelle interface réseau axtap(4) pour les tunnels (e.g. APRS-IS et peut-être les modems sonores)
• Une nouvelle pseudo-interface réseau axeth(4) pour l'encapsulation AX.25 dans Ethernet
• Une nouvelle pseudo-interface réseau axip(4) pour l'encapsulation AX.25 dans IPv4/IPv6
• aprsd(8) - une nouvelle séparation de privilège pour le suivi/digitalisation APRS
  • en utilisant la localisation de données disponible via le framework des senseurs, e.g. depuis nmea(4)
  • en utilisant les données disponibles via certains mécanismes depuis une station météo
• aprsisd(8) - un client du service APRS-IS
  • utilisant (peut être de manière exclusive) une connexion TLS vers le serveur APRS-IS
• rkissd(8) - un service de connexion à distance KISS
• softmodem(8) - un modem logiciel supportant les modes PACTOR et AFSK des Bell 103 et Bell 202
• Considérer les besoins des opérateurs de loisirs et d'urgence

Ces objectifs peuvent être corollaires aux autres activités, mais ne sont pas des objectifs explicites à ce projet :

• Un pilote d'interface réseau générique pour les différents protocoles de ligne en série (e.g. à la fois KISS et SLIP)

• Digitalisation dans le noyau
  • les entêtes AX.25 sont de longueurs variables, ce qui est un peu désordonné. Nous voulons les analyser autant que possible dans le noyau
• SOCK_SEQPACKET pour AF_AX25
  • Il s'agit d'un bloc de code compliqué. Il y a des états de machines, des minuteries et toutes sortes de choses. Si vous le souhaitez, vous pouvez le faire dans l'espace utilisateur en utilisant le support SOCK_RAW.
• Les tunnels IPIP (protocole 4 ou 94)
  • Il est peut-être possible d'être convaincu que cela en vaut la peine, mais l'idée d'un Internet mondial amateur qui rejoint l'Internet public par endroits n'est pas si séduisante. Outre les maux de tête liés à la licence d'exploitation et aux abus potentiels, on ne sait pas très bien quels sont les services fonctionnant sur 44net qui sont vraiment utiles pour l'opérateur moyen. Il est déjà possible d'établir des tunnels entre sites en utilisant d'autres technologies.

Cette page est la traduction officieuse de la page “HamBSD Goals” .
En cas de doute, merci de vous y référer !

Si vous voulez participer à l'effort de traduction, merci de lire ce topic.