J'ai récupéré un NVR (Network Video Recorder) Nuuo, avec 4 emplacements pour des disques SATA, et un firmware pour enregistrer le flux de 4 ou 8 caméras IP. À première vue, le hardware est assez performant, largement assez pour un NAS fonctionnant avec Linux.
Hardware
Le boitier a une carte Promise NS4600, un bloc d'alimentation et permet de mettre 4 disques SATA.
Les NAS Promise NS4600 et Patriot Javelin utilisent exactement la même carte et le même boitier. Seul le firmware change.
Debug Série
La carte-mère a un port série (3.3V, 115200bits/s) accessible sur la face de la carte-mère. Mais comme c'est un connecteur JST au pas de 2mm, il y a le choix entre souder directement des fils, ou bien déformer le connecteur pour y faire rentrer des pins Dupont femelle (pas de 2.54mm).
Le pin 1 est marqué avec un pad carré, et le connecteur a le pinout suivant :
RX
GND
TX
Vdd
En branchant un convertisseur série-USB (FTDI232 ou n'importe quoi d'autre qui sort et accepte du 3.3V), et en le configurant correctement (115200, 8N1), on devrait avoir quelques caractères au boot de la machine.
Si rien n'apparait, on peut vérifier que lex pins RX et TX ne sont pas croisés (erreur fréquente), un voltmètre en AC permet de voir des pulses à l'envoi paquet de texte (et du coup d'identifier les pins RX et TX).
Software U-boot
U-boot a été réglé pour booter le plus vite possible, du coup on ne pourra pas facilement bricoler. Par contre le timeout est réglable.
Il suffit d'appuyer sur ctrl+c le plus vite possible au boot de la machine, avant qu'elle ne charge le noyau.
Une fois avec le prompt de U-Boot, on peut bricoler : setenv bootdelay 10
saveenv
Après un reboot, on a un peu plus de temps pour réagir.
De la même façon, on peut avoir un shell sans connaître le mot-de-passe root : setenv ramargs setenv bootargs root=/dev/ram rw init=/bin/sh
Ici, on a rajouté init=/bin/sh à la fin de la variable ramargs, chargée au démarrage, mais la sauvegarder n'a pas d'intérêt.
Taper printenv permet de voir l'essentiel, jusqu'à la structure de la mémoire flash.
Firmware Nuuo
Pour éviter de tout casser, on va commencer par sauvegarder le firmware original.
Avec init=/bin/sh, on a facilement un shell, et on peut tenter de dumper la flash sur une clé usb.
Après l'avoir branché, il ne faut pas oublier insmod /lib/modules/usb-storage.ko, vu qu'on n'a pas chargé d'init, aucun services comme u-dev ne sont fonctionnels.
La commande tar permet d'archiver les fichiers pour une inspection par la suite (les volumes RAID et les disques ne sont pas automatiquement montés). Il faut aussi exclure /dev, /proc et le point de montage de la clé usb, pour ne pas copier de choses volumineuses et inutiles.
Le début du bootlog contient des informations plus détaillées que u-boot sur les partitions de la flash :
10 cmdlinepart partitions found on MTD device nand0
Using command line partition definition
Creating 10 MTD partitions on "nand0":
0x00000000-0x00100000 : "u-boot"
0x00100000-0x00180000 : "dtb"
0x00180000-0x00480000 : "safe-k"
0x00480000-0x00c80000 : "safe-r"
0x00c80000-0x00f80000 : "kernel"
0x00f80000-0x01780000 : "rootfs"
0x01780000-0x02780000 : "usr"
0x02780000-0x02980000 : "data"
0x02980000-0x02a80000 : "oem"
0x02a80000-0x08000000 : "app"
Comme il y a 12 devices mtd dans /dev/, on va tout dumper pour ne rien oublier :
for i in 0 1 2 3 4 5 6 7 8 9 10 11 12; do dd if=/dev/mtd$i of=/mnt/nuuo/mtd/mtd$i; done
2048+0 records in
2048+0 records out
1024+0 records in
1024+0 records out
6144+0 records in
6144+0 records out
16384+0 records in
16384+0 records out
6144+0 records in
6144+0 records out
16384+0 records in
16384+0 records out
32768+0 records in
32768+0 records out
4096+0 records in
4096+0 records out
2048+0 records in
2048+0 records out
175104+0 records in
175104+0 records out
dd: /dev/mtd10: No such device
dd: /dev/mtd11: No such device
dd: /dev/mtd12: No such device
(c'est malin, la commande range n'a pas été installée).
Si on veut modifier quelque chose, ça sera probablement les zones "rootfs" et "usr", et peut-être "data", "app" et "kernel".
La commande binwalk est assez intéressante pour donner les offsets et la taille du code contenu dans les zones de flash, par contre l'extraction ne fonctionne pas toujours bien.
La commande vbindiff permet de vérifier que les adresses sont correctes. Dans notre cas, la partition "oem" est vide, et la partition "data" commence à l'offset 0xC0000 et finit à 0xC07FF (soit 2kiB).
On peut ensuite utiliser la commande dd pour extraire les fichiers (skip pour indiquer l'offset, count pour indiquer la taille, et bs=1 pour travailler avec des blocs de 1 octet).
Nouveau firmware
Le firmware Nuuo est assez inutilisable pour faire autre chose que de l'enregistrement de videosurveillance, et un message d'erreur rend impossible l'upgrade d'un firmware en utilisant l'interface web.
Du coup, je vais suivre ce tutoriel pour installer Debian sur ce NAS : https://github.com/alexeicolin/javelin
Si ça ne fonctionne pas, un firmware Promise ou Patriot fera sûrement l'affaire.
Notes
Le ventilateur est contrôlé par software. Ce n'est pas critique sans disque dur et avec le boitier ouvert, mais ça peut vite devenir un problème.
Le serveur précédent commence à avoir des performances limitées (il date quand même de 2000), et j'ai pu récupérer un HP Compaq DC5800 de 2009 en bon état.
Hardware
La machine a un processeur Intel Pentium E5200 (2-Core, 2.5GHz, LGA775) et deux barrettes de 1Gio de DDR2 (avec deux slots libres), mais le disque dur et le lecteur optique/disquette manquent ou sont hors-service.
On commence par tout vérifier, nettoyer, puis remettre en état tout ce qui en a besoin :
Memtest avec la mémoire,
Flash du dernier BIOS à jour,
Nettoyage des ventilateurs/radiateurs,
Remplacement de la pâte thermique du processeur,
Face avant
Le lecteur de disquette est manquant et le lecteur optique ne fonctionne pas, du coup je les ai enlevés. Sauf que le refroidissement de la machine est fait de telle sorte que l'air doit être aspiré par le côté avant droit, et soufflé par le côté arrière gauche. Quand le boitier est ouvert ou que la face avant manque, le disque dur est mal refroidi, mais il est possible de découper une plaque de plexiglass pour remplacer les caches d'origine.
Disque dur
Le disque dur était manquant quand j'ai récupéré la machine, mais les vis, clips et bushings manquaient aussi, ce qu'il a fallu adapter.
J'ai pris des vis 6-32 "long sleeve" d'un rack à disques de serveur IBM et des bushings de lecteur CD. L'ensemble rentre dans l'emplacement d'origine et se clipse fermement (pas de vibration).
Software
Mot-de-passe BIOS
Les machines d'entreprises ont souvent des BIOS différents de ceux des PCs habituels. Ici, le mot-de-passe protégeant BIOS est stocké dans une mémoire EEPROM au lieu d'être dans une SRAM. Dans ce cas, enlever la pile quelques secondes n'affecte que l'horloge RTC.
Débrancher le secteur,
Ouvrir le capot,
Attendre que les LEDs de la carte-mère soient éteintes,
Enlever le cavalier vert PSWD (à côté des ports SATA),
Brancher le secteur et démarrer la machine,
Débrancher le secteur et attendre que les LEDs soient éteintes,
Remettre le cavalier PSWD,
Refermer le capot et rebrancher le secteur.
Boot-Menu
Certaines options du BIOS concernant la "sécurité" sont grisées et indisponibles. Ainsi, on ne peut booter que sur le disque SATA HDD0, alors qu'un lecteur optique, USB ou la ROM PXE (réseau) sont disponibles.
Pour cela, il est nécessaire de "protéger" l'accès au BIOS par un mot-de-passe. Le "boot menu" est aussi affecté, et permet de booter sans problème sur un serveur PXE quand un mot-de-passe est entré.
Debian Linux
Je me suis contenté d'échanger le disque dur de l'ancien serveur au nouveau, quasiment sans toucher l'installation de Debian Jessie (8.4) i386.
L'unique bricolage concerne udev et sa façon de détecter les cartes réseau par leur adresses MAC. Si l'on ne change rien, le réseau ne fonctionnera pas et sera à reconfigurer (peu pratique pour un serveur sans écran ni clavier).
Il faut commencer par trouver l'adresse MAC de la carte réseau avec l'ancien serveur en fonctionnement : # ifconfig |grep HWaddr
eth0 Link encap:Ethernet HWaddr 00:d0:b7:xx:xx:xx
eth1 Link encap:Ethernet HWaddr 00:1e:2a:xx:xx:xx
Ici, c'est l'adresse de eth0 qui nous intéresse, mais la configuration de udev est séparée en plusieurs fichiers de configuration que l'on va chercher : # grep -rni '00:d0:b7:xx:xx:xx' /etc/ /etc/udev/rules.d/70-persistent-net.rules:8:SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:d0:b7:xx:xx:xx", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
La recherche peut renvoyer plusieurs fichiers (DHCP, ARP, scripts d'init bricolés), mais c'est ceux qui concernent udev qui nous intéressent et que l'on va éditer :
# PCI device 0x8086:0x1229 (e100)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:d0:b7:xx:xx:xx", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
Dans tous les cas, il faudra supprimer l'association entre chaque carte et son adresse MAC, les cartes réseau suivantes seront ajoutées à la suite (la première carte réseau sera eth2 si l'on ne touche à rien).
Pour être sûr que le réseau fonctionne du premier coup, on va remplacer l'adresse MAC de l'interface eth0 par celle de la nouvelle carte réseau (affichée à l'écran pendant une tentative de boot par PXE).
Performances
Test
HP Compaq dc5800 (new)
IBM PC-300GL 6288 (old)
nbench Mem
18.583
2.649
nbench Int
17.233
2.793
nbench Float
32.444
4.942
Transfert NFS
11.20 Mio/s
11.18 Mio/s
Transfert SaMBa
11.21 Mio/s
11.00 Mio/s
Transfert SSH
11.2 Mio/s
4.05 Mio/s
Génération PHP/Blogotext
7.6 ms
61.9 ms
Compression gzip
15.43 Mio/s
1.31 Mio/s
Décompression gzip
112.48 Mio/s
10,65 Mio/s
Compression bzip2
3.28 Mio/s
0.32 Mio/s
Déompression bzip2
7.18 Mio/s
1.19 Mio/s
Débit disque dur
185.81 Mo/s
40.33 Mo/s
Débit ethernet
94.4 Mbit/s
94.6 Mbit/s
La plupart des débits sont limités à 100Mbit/s par le switch. Mais il faut aussi voir que les tests ont été faits avec des gros fichiers (247Mio).
La différence la plus visible vient du processeur et du contrôleur SATA, la lenteur de l'ancien serveur posait surtout des problèmes en multitâches ou en transférant de nombreux petits fichiers (sauvegardes).
Depuis un moment, j'ai réussi a me débarasser de mes disquettes de boot en démarrant par le réseau avec PXE (voir les articles concernant PXE).
Il est même possible de se passer entièrement de disque dur avec Linux et NFS, mais ce n'est possible qu'avec quelques systèmes basés sur UNIX.
Pour utiliser DOS avec un système plus gros qu'une disquette, ou même Windows sans disque-dur, c'est une autre histoire puisqu'ils ne sont installables que sur un disque-dur visible par le bios.
Serveur/Target
On va installer le service iscsitarget et le module noyau iscsitarget-dkms
On ajoute les images (ou disques physiques/RAID) à partager dans le fichier /etc/iet/ietd.conf en respecant les noms "iSCSI Qualified Name" : Target iqn.2007-01.org.exacnet:foobar.1
IncomingUser
OutgoingUser
Lun 0 Path=/media/stuff/iscsi/foobar,Type=fileio
Alias foobar
Ici, le disque iqn.2007-01.org.exacnet:foobar.1 est relié au fichier /media/iscsi/foobar, qui est une image de disque (crée avec la commande dd).
Une fois le fichier mis à jour, il faut redémarrer le daemon iscsitarget : # /etc/init.d/iscsitarget restart
[ ok ] Restarting iscsitarget (via systemctl): iscsitarget.service.
On peut aussi afficher la liste des disques partagés : # cat /proc/net/iet/session
tid:1 name:iqn.2001-01.org.exacnet:foobar.1
sid:17796167515963456 initiator:iqn.2001-01.org.exacnet:foobar
cid:0 ip:192.168.3.100 state:active hd:none dd:none
La commande ietadm permet d'administrer le service iSCSI de façon non-persistante, et il est aussi possible de sécuriser iSCSI (simple authentification, les données passent toujours en clair).
Client/Initiator (Linux)
Le package open-iscsi fournit les commandes nécessaires pour utiliser un client iSCSI.
On commence par "découvrir" les machines du réseau qui utilisent le protocole iSCSI : # iscsiadm --mode discovery
localhost:3260 via sendtargets
192.168.3.3:3260 via sendtargets
On va vérifier les disques accessibles sur la machine 192.168.3.3 : # iscsiadm --mode discovery -t sendtargets -p 192.168.3.3
192.168.3.3:3260,1 iqn.2001-01.org.exacnet:foo
192.168.3.3:3260,1 iqn.2001-01.org.exacnet:bar
192.168.3.3:3260,1 iqn.2001-01.org.exacnet:foobar.1
La commande iscsiadm -m node permet aussi de lister tous les disques accessibles, peu importe sur quelle machine.
On peut ensuite choisir un disque et l'attacher à la machine : # iscsiadm -m node --targetname "iqn.2001-01.org.exacnet:foobar.1" --login
Logging in to [iface: default, target: iqn.2001-01.org.exacnet:foobar.1, portal: 192.168.3.3,3260] (multiple)
Login to [iface: default, target: iqn.2001-01.org.exacnet:foobar.1, portal: 192.168.3.4,3260] successful.
L'attachement est effectué avec succès, mais il faut connaître le nom de périphérique qu'a attribué le système au disque : # dmesg |tail -n 20
scsi20 : iSCSI Initiator over TCP/IP
scsi 20:0:0:0: Direct-Access IET VIRTUAL-DISK 0 PQ: 0 ANSI: 4
sd 20:0:0:0: Attached scsi generic sg2 type 0
sd 20:0:0:0: [sdb] 409600 512-byte logical blocks: (209 MB/200 MiB)
sd 20:0:0:0: [sdb] Write Protect is off
sd 20:0:0:0: [sdb] Mode Sense: 77 00 00 08
sd 20:0:0:0: [sdb] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
sdb: sdb1
sd 20:0:0:0: [sdb] Attached SCSI disk
On peut ensuite monter le disque et l'utiliser comme s'il s'agissait d'un disque local : # mount /dev/sdb1 /mnt/
Une fois l'utilisation terminée, on peut détacher le disque : # iscsiadm -m node --targetname "iqn.2001-01.org.exacnet:foobar.1" --logout
Logging out of session [sid: 3, target: iqn.2001-01.org.exacnet:foobar.1, portal: 192.168.3.3,3260]
Logout of [sid: 3, target: iqn.2001-01.org.exacnet:foobar.1, portal: 192.168.3.3,3260] successful.
Il est possible de faire plusieurs choses un peu bizarres comme du RAID, ou de monter le même disque (même iqn) à travers plusieurs adresses IP. C'est utile pour des systèmes tolérants aux pannes, mais inutile et compliqué pour un simple "bricolage".
Client/Initiator (PXE)
Pour un seul disque, il n'y a que 3 opérations à faire :
Régler le nom du disque set initiator-iqn iqn.2001-01.org.exacnet:foobar.1
"Accrocher" le disque iSCSI sanhook iscsi:192.168.3.3::::iqn.2001-01.org.exacnet:foobar.1
booter : sanboot
En fait, les paramètres par défaut d'iPXE suffisent pour un seul disque. Si on veut en mettre plusieurs, il faut spécifier l'identifiant de chaque disque.
Dans ce cas, les disques foo et bar seront attachés, et le sytème bootera sur le disque foo, et ça ne fonctionne pas sans donner l'IQN du premier disque.
Utilisation et Performances
On peut installer un système d'exploitation sur un disque iSCSI ou son image comme s'ils étaient des disques physiques.
DOS s'installe sans problème avec QEMU ou une machine physique ayant booté par PXE.
Avec mon serveur un peu ancien et peu performant (Intel Celeron 600MHz), le débit est entre 6.5 et 8Mio/s et les temps d'accès entre 2 et 10ms selon la charge du serveur (en ethernet 100Mbit/s).
Pour l'instant, je n'ai pas réussi à faire fonctionner Windows (j'ai testé les versions 3.1 et 98 sans succès) en bootant depuis un disque iSCSI, mais DOS et Linux fonctionnent sans problème.
Mon routeur (WRT54G) et point d'accès wifi avait quelques problèmes de fiabilité (freezes, coupures de réseau...), j'ai essayé de voir si on pouvait trouver un remplaçant vallable.
Le Nexx WT3020 est une Chinoiserie avec deux interfaces ethernet, une interface wifi, un port usb host et un SoC compatible avec OpenWRT.
Software
Le firmware d'origine à l'air utilisable avec un noyau Linux contrôlable par telnet et une interface web en Anglais (ou en Chinois).
Adresse IP : 192.168.8.1
Login (http) : admin
Mot de passe (http) : admin
Login (telnet) : nexxadmin
Mot de passe (telnet) : y1n2inc.com0755
On peut changer le firmware directement depuis l'interface web ou bien par telnet.
OpenWRT
Il faut d'abord connaître la quantité de mémoire flash embarquée. Comme la puce est difficile à lire, il semble que les modèles dont l'adresse MAC commence par 20:28:18 ont 8Mio de flash.
On peut ensuite télécharger l'image d'OpenWRT adaptée au routeur et utiliser l'interface web d'origine pour flasher le firmware.
Au reboot, l'adresse IP change et devient 192.168.1.1, et une fois un mot de passe choisi, on peut utiliser ssh.
Hardware
En ouvrant le boitier (quasiment impossible sans casser de clip), on voir un SoC Mediatek MT7620N, une mémoire flash SPI (8Mio), deux transformateurs d'impulsion (ethernet), de la SDRAM (64Mio), et quelques régulateurs de tension.
On voit directement que la capacité d'entrée est trop faible (400 à 900mV de ripple mesurés, en fonction de la charge). Par contre le ripple est faible après le régulateur LDO qui alimente le SoC.
J'ai préféré rajouter une capacité chimique de 220µF (16V, ESR <1Ω), ce qui limite le ripple à <20mV.
Les pads qui sont accessibles entre les deux ports ethernet et le SoC servent pour une liaison série, utile pour avoir un accès direct à u-boot en cas de problème.
Par contre il n'y a pas de JTAG, du coup en cas de brickage, il faudra dessouder la mémoire flash (SPI) pour la re-flasher.
Performances
J'ai essayé de mesurer la vitesse de transfert en copiant des fichiers par NFS et en utilisant le benchmark réseau iperf :
Routeur -> PC : 24.9Mbit/s
PC -> Routeur : 22.6Mbit/s
En vérifiant, le routeur fonctionne en mode 802.11g, et est théoriquement limité à 54Mbit/s (~30 en pratique). Il y a peut-être une configuration spécifique pour OpenWRT (le hardware est censé supporter la norme 802.11n à 300Mbit/s et le MIMO).
802.11n(update 06.2016)
Avec un peu de recherches, on voit que le mode 802.11n, qui suppose une bande passante de 300Mbit/s ne peut être actif que si le mode WMM (Wi-Fi Multimedia) est activé et si les données sont encryptées en WPA (j'utilisais le mode WEP depuis mon premier routeur).
Avec quelques tests :
Routeur -> PC : 70.8Mbit/s
PC -> Routeur : 21.6Mbit/s
On a aucune différence en upload, mais le débit en download devient intéressant.
Hardware
La carte est assez simple avec un routage très compact, avec deux buffers TTL 74ALS245 pour le port parallèle, un ASIC custom noté DL3520S (D-Link).
L'ASIC addresse directement sa mémoire cache (32k x 8bit, 70ns), une eeprom SPI de 128bits (93C46) pour sauvegarder l'adresse MAC et les réglages permanents.
Le bus entre l'ASIC et le contrôleur MAU et RJ45 (AT&T T7213) est isolé par un transformateur d'impulsions.
Le contrôleur MAU -> Coaxial (Myson MTD493V) est relié directement au bus MAU du chip AT&T, mais le port RJ45 est relié au chip AT&T par un autre transformateur d'impulsions.
L'alim est commandée par un chip "universel" LT1172 avec un transformateur, qui permet de fournir du +9V et du +5V à partir d'une unique alimentation (12V externe, le port parallèle ne fournit pas de courant).
Compilation du driver pour Linux
Le driver de620 est bien caché et n'est pas compilé par défaut, mais on peut facilement le rajouter.
Avec Debian Squeeze, on va installer les sources et les kernel-headers qui correspondent à notre noyau apt-get install linux-source-$(uname -r |awk -F "-" '{print $1}') linux-headers-$(uname -r)
Une fois tout copié, on va extraire les sources dans le dossier /usr/src/, et préparer le noyau à être installé.
GCC, make et libncurses-dev (dans la même version que celle qui a servi à compiler le noyau) sont nécessaires.
On va commencer dans le dossier contenant les sources du noyau en préparant le noyau : $ cd /usr/src/linux-image-$(uname -r |awk -F "-" '{print $1}')
$ cp ../linux-headers-$(uname -r)/Module.symvers .
$ cp /boot/config-$(uname -r) .config
$ make prepare
$ make scripts
$ make menuconfig
Dans l'interface menuconfig, il va falloir vérifier que le port parallèle est bien activé CONFIG_PARPORT=m et activer les cartes réseaux (Device Drivers ---> Network device support ---> Ethernet (10 or 100Mbit) ---> Pocket and portable adapters, D-link DE600 & D-link DE620 pocket adapter support)
Si la machine est lente, il est conseillé de retirer le maximum de modules (uniquement réseau, la compilation des autres sera évitée).
On peut vérifier que les modules vont bien être compilés : $ grep CONFIG_DE6.0 .config
CONFIG_DE600=m
CONFIG_DE620=m
Il ne reste plus qu'à compiler : $ cd drivers/net/
$ make -C ../../ M=($pwd) modules
Seulement les drivers relatifs au réseau seront recompilés (quasi uniquement DE600 et DE620).
Une fois la compilation et l'édition de liens terminées, on va pouvoir copier les modules # cp de6?0.ko /lib/modules/$(uname -r)/kernel/drivers/net/
# depmod -a
Depmod permet de mettre à jour la liste des modules chargeables par modprobe.
Utilisation
Avec le driver installé, il ne reste qu'a le charger, configurer la carte réseau, puis l'utiliser. # modprobe de620
D-Link DE-620 pocket adapter, Ethernet Address: 00:80:c8:xx:xx:xx (32k RAM, UTP)
Dans mon cas, l'interface est reconnue comme eth1, et on peut la régler avec une adresse IP statique avec ifconfig ou bien en dynamique (dhclient est installé par défaut avec Debian).
On peut rapidement tester avec les commandes ping, route, nslookup et arp que tout fonctionne correctement.
Performances
Pour tester sans être dérangé par d'autres facteurs, je branche un PC de test directement sur la carte PE-EPP avec un câble RJ45. Il n'y a que deux machines sur le réseau. iperf est un outil prévu pour mesurer la bande passante de réseaux, parfaitement adapté à ce cas. J'ai testé en alternant les modes client et serveur, pour mesurer le débit montant et descendant.
[ 3] local 192.168.10.1 port 50051 connected with 192.168.10.2 port 5001
[ 3] 0.0-10.0 sec 2.19 MBytes 1.83 Mbits/sec
[ 5] local 192.168.10.1 port 5001 connected with 192.168.10.2 port 49470
[ 5] 0.0-15.6 sec 2.00 MBytes 1.07 Mbits/sec
[ 4] local 192.168.10.2 port 49468 connected with 192.168.10.1 port 5001
[ 4] 0.0-10.0 sec 1.88 MBytes 1.57 Mbits/sec
[ 5] local 192.168.10.2 port 5001 connected with 192.168.10.1 port 50051
[ 5] 0.0-10.8 sec 2.19 MBytes 1.70 Mbits/sec
Avec plusieurs tests, on a bien 1~1.5Mbit/s en réception et 1.5~1.8Mbit/s en émission, avec une charge CPU élevée.
Ce débit peut paraître lent devant les 10Mbit/s de l'ethernet, mais il ne faut pas oublier que le port parallèle ne dépasse pas 200kio/s en mode SPP, ce qui est cohérent. Il est possible que mon port parallèle et son driver ne fonctionnent pas en mode EPP (2Mio/s maximum et accès DMA).
Note
Plusieurs fois pendant les benchmarks, la carte a arrêté de fonctionner et le noyau a affiché eth1: transmit timed out, network cable problem?. La carte refonctionne après un rechargement de driver (ifconfig eth1 down; rmmod de620; modprobe de620; ifconfig eth1 192.168.10.1).
DOS
Un driver est fourni pour DOS, Windows 3.1 et OS/2, mais DOS n'est pas vraiment pratique.
J'avais récupéré plusieurs boitiers avec une prise DB-15 "slider" (AUI, Attachment Unit Interface) d'un côté, et un connecteur RJ-45 ou BNC de l'autre côté.
Ces boitiers, ou d'autres un peu plus gros sont connus pour leurs Connexion Vampire, qui pincent/coupent/traversent un câble Coaxial pour s'y connecter. Les miens sont moins monstrueux, et se contentent de connecteurs.
Principe de fonctionnement
À la base, la partie "logique" (MAC) et la partie "driver" (MAU, Medium Attachment Unit) étaient isolées galvaniquement, mais aussi montées sur deux cartes séparées. Comme ça on pouvait brancher une carte ethernet sur n'importe quel type de réseau physique (Fibre optique, Câble coaxial, simple ou multiples paires torsadées...), et aussi commander un câble sur de longues distances.
On trouve aussi des switches réseaux avec une interface AUI, pour relier les switches de plusieurs bâtiments ensembles (souvent avec plusieurs centaines de mètres de câble).
L'avantage le plus évident est la haute disponibilité et la robustesse : il n'y a pratiquement pas besoin de redémarrer la machine pour changer son MAU.
Hardware
Comme cette interface est obsolète depuis le Fast-Ethernet (Media Independant Interface à 10/100Mbit/s), et utile dans de rares cas, il ne faut s'y attendre à trouver cette interface que sur du matériel haut de gamme des années 90.
J'ai essayé une carte 3Com 3c509b-combo, qui a un connecteur DB-15 "slider" pour une interface 10base5.
Cette carte se configure entièrement par software, il n'y a aucun cavalier à bouger, même pour choisir l'interface réseau.
Linux
En chargeant le module 3c509 avec les paramètres d'irq # modprobe 3c509 irq=5
eth1: 3c5x9 found at 0x300, 10baseT, address 00:a0:34:xx:xx:xx, IRQ 5., la carte est détectée avec les paramètres qui sont donnés dans sa ROM.
Par contre, ethertool ne semble pas arriver à écrire dans la ROM de la carte...
On va passer par l'utilitaire 3c5x9cfg (DOS) pour écrire dans la ROM et tester la carte.
En redémarrant, # modprobe 3c509 irq=5
eth1: 3c5x9 found at 0x300, AUI port, address 00:a0:34:xx:xx:xx, IRQ 5.
Et il devient possible d'obtenir une adresse IP et d'utiliser le réseau normalement.
Windows
Le driver fourni avec Windows 98 ne permet pas de configurer la carte, ni de la diagnostiquer. On va utiliser un vieux driver pour Windows 95 (qui permet de faire comme 3c5x9cfg depuis Windows)
Notes
Le switch SQE doit être désactivé sur le MAU
Inutile d'espérer une réponse du Network Connectivity Test de 3Com
J'ai déjà essayé de démarrer des machines depuis le réseau, ça évite de s'embêter avec des disquettes peu fiables. Par contre je n'avais essayé que des cartes réseaux répandues sur un bus PCI et datant des années 2000. Pourquoi ne pas essayer une carte ISA datant des années 1990 ?
Choix de la carte réseau
J'ai une carte D-Link DE-220 et une 3Com 3c509 fonctionnelles qui trainent dans un carton plein de cartes ISA.
Après avoir lu leur documentation et fait quelques tests, les deux cartes se configurent sans jumpers, mais avec un programme DOS qui stocke leurs réglages (IO, IRQ, mode ISA PNP, activation de la ROM de boot) dans une eeprom.
La carte 3Com ne fonctionne qu'en mode "ISA PNP" (Plug'n'Play, mais plutôt Plug'n'Pray en pratique) sur ma machine, et ne propose pas de booter en mode ISA PNP.
La carte D-Link fonctionne en mode ISA (IRQ et IO imposés par la carte plutôt que par l'OS), accepte des ROMs de 8 ou 16Kio et des images de ROMs sont trouvables.
Premiers tests
La machine boot, affiche un peu de texte, mais boucle indéfiniment en cherchant serveur RPL. Pas de PXE sur cette carte (le protocole PXE date de 1998 et ne rentre pas dans 16Kio).
Serveur RPL
Comme je ne suis pas le premier à vouloir utiliser RPL, un serveur libre existe (et est inclus dans quelques distributions de Linux).
Sa configuration est intuitive (adresse MAC, masques, chemin du fichier à charger). Il reste les adresses de chargement et d'execution qui ne sont pas intuitives et dépendent des images.
Dans mon cas, j'ai choisi l'image ne2k_isa.pxe d'iPXE, et testé les adresses de chargement et d'execution 0x1000 et 0x1006.
Comme la documentation de RPLD n'est pas très claire, les réglages d'adresses ont dû être faits à tâtons.
Boot de la machine
Le bios initialise la machine, charge la ROM contenue sur la carte réseau (INT19), et execute le programme RPL contenu dans la ROM.
Le programme RPL charge l'image PXE que lui donne le serveur RPL, et l'execute l'image.
Ensuite, iPXE détecte la carte réseau, demande une adresse IP avec DHCP, puis charge un OS via HTTP.
Tests
Je n'ai pas réussi à faire fonctionner PXE avec ma machine 486 (la machine redémarre ou se fige au chargement d'iPXE). Par contre, ça fonctionne sans problèmes avec un Pentium 2 ou avec Qemu émulant une machine 486.
Un Schrödingbug fait que la ROM de la carte réseau n'est pas lue dans certains cas, toujours en démarrant la machine "à froid", aucun problème en cas de reboot. En pratique, c'est lorsque le BIOS effectue trop vite son POST, la carte réseau n'a pas eu le temps d'initialiser la ROM.
Cet article montrait comme mettre en place et utiliser gPXE : http://monorailc.at/cms/?d=2014/11/02/19/23/12-boot-pxe
Seulement, gPXE est un peu ancien et a été remplacé par iPXE, qui apporte des fonctionnalités en plus.
Mise a jour
On remplace le fichier undionly.kpxe situé sur le serveur par celui d'iPXE, et on modifie quelques lignes de la configuration du serveur DHCP.
Jusque là, ça fonctionne de la même façon que gPXE.
Menus
L'intérêt est de pouvoir afficher un menu nativement (sans PXELinux), qui permet de booter plusieurs OS différents.
Pour cela, on va modifier le fichier boot.gpxe présent sur le serveur, et ajouter les images que l'on veut booter.
Le menu est au debut du fichier et commence par le mot clé menu, suivi d'un choix par ligne commençant par item, un label, puis le nom affiché à l'écran.
menu
item shell iPXE shell
item dsarge Debian Sarge NFS
item dsqueeze Debian Sqeeze NFS
item dos DOS
item memtest Memtest86+
choose --default dsqueeze --timeout 5000 target && goto ${target}
La dernière ligne donne le choix par défaut et l'action a faire une fois une option choisie.
Linux
Avec Linux, on peut charger directement un noyau et une initrd. :dsqueeze
kernel http://192.168.3.3/pxe/vmlinuz-squeeze ip=:::::eth0:dhcp root=/dev/nfs nfsroot=192.168.3.3:/media/stuff/chroot/nfsroot/ panic=10 ro ipv6.disable=1
initrd http://192.168.3.3/pxe/initrd.img-squeeze
boot
La première ligne correspond au choix du menu, les deux suivantes chargent le noyau et son initrd, en leur passant des parametres, et la dernière ligne donne l'ordre de booter sur ce qui vient d'être chargé.
DOS
Le plus simple est d'utiliser une image de disquette ou de CD suffisament petite pour rentrer entièrement dans la mémoire de la machine.
Exemple
J'ai filmé un PC sans disque bootant Debian par iPXE, sans autre périphérique bootable que sa carte réseau (avec un firmware gPXE chargé dans le BIOS).
Il est possible de booter une machine sans disque dur, ni lecteur cd (ni même de clé usb).
Beaucoup de cartes réseaux (j'utilise des 3com 3C905CX) ont une EEPROM qui contient un chargeur de boot réseau.
Il y a donc plusieurs parties:
Serveur DHCP
Serveur TFTP
Image(s) PXE
Boot du noyau
Il faut d'abord configurer le serveur DHCP, pour qu'il donne les paramètres de boot à la machine qui va le lui demander. Pour l'instant, je n'ai pas réussi à configurer dnsmasq pour avoir un serveur tftp sur une autre machine que le serveur dhcp, alors j'ai adapté...
Comme le bootloader embarqué dans la carte va charger un autre bootloader (undionly.kpxe), qui lui, va charger le noyau, on va interroger le serveur DHCP deux fois. Ces deux accès sont distingués par le flag "userclass"
dnsmasq est tellement bien fait qu'il a aussi un serveur tftp embarqué. Il suffit de rajouter les lignes suivantes dans le fichier /etc/dnsmasq.conf
enable-tftp
tftp-root=/tmp
Comme le routeur a peu de flash, j'ai mis la raçine du serveur tftp dans /tmp (tmpfs) pour éviter les problèmes. Mais il faut rajouter un script qui télécharge l'image au boot de la machine. undionly.kpxe est une image de gPXE qui permet de booter sur n'importe quel protocole (même http).
Pas mal d'hébergeurs de pub n'hébergent que de la pub sur le même hostname. Du coup, on ne perd pas grand chose à filtrer leurs domaines.
En même temps, quasiment tous les routeurs ont un cache DNS, mes routeurs (OpenWRT) utilisent dnsmasq.
Dans la config de dnsmasq, /etc/dnsmasq.conf, on fait des redirections arbitraires avec l\'instruction suivante : address=/hostname/adresse
À grande échelle, on arrive à une petite commande : for i in $(cat list); do echo "address=/$i/127.0.0.1" >> /etc/dnsmasq.conf ; done
Il ne suffit plus que de redémarrer le service dnsmasq, et ça fonctionne.
Pour trouver la liste, on peut récupérer les listes d'adblock et les trier (les bouts d'url et toutes les regexp n'intéressent pas dnsmasq). On a aussi des listes toutes faites comme ici.
Pour upgrader la liste, on peut rajouter ce qui manque : for i in $(cat nouvelle_liste); do if !(grep -q dnsmasq.conf) ; then echo >> dnsmasq.conf ; fi; done
2017-05-06 - No comments
Tags de l'article : 
