Nabaztag V1 : Boot

Contrairement au v2, le Nabaztag V1 n'a pas de "Boot_Code" chargé lors son démarrage. Il reçoit du serveur distant des paquets de type "pseudo assembleur" (bytecode) à intervalles réguliers.

Démarrage du Nabaztag v1 :
Demande (GET HTTP/1.0) du ping à intervalle régulier vers un serveur de type Violet (ici p.nabaztag.com)

GET http://188.165.120.132/vl/FR/p3.jsp?sn=0090xxxxxxxx&ex=000000000000&v=20&st=00&tc=00000001 HTTP/1.0
User-Agent: VIOLET
Pragma: no-cache

Le serveur répond en renvoyant une trame (packets), un ensemble de messages, au format attendu par le v1.
Si la première requête reste sans réponse, la seconde peut avoir le format suivant :

GET http://188.165.120.132/vl/FR/p3.jsp?sn=00904BBDAA81&ex=000000000000&v=20&st=00&ts=00000000&sd=0002&tc=00000001 HTTP/1.0
User-Agent: VIOLET
Pragma: no-cache

• Paramètres :

sn : S/N du V1 (adresses MAC)
ex : ?
v : version du firmware (souvent 1.4 ou 2.0)
st : 00 lors du boot, 01 ensuite.
sd : statut du Tag (cf instruction vasm SEND r0, r1)
tc : id du bytecode courant (bc msg_type 05)
tn : id du bytecode précédent
ts : copie de tn ?

Note : Malgré avoir indiqué dans son setup le domaine p.nabaztag.com, on s'aperçoit que le V1 tente un get sur l'ip avec /vl/FR/xxx. Cela pose d'emblée un problème pour les hébergements mutualisés... On note l'absence du tag HOST dans la séquence du GET. Si l'on ne dispose pas d'un serveur dédié, la première chose à faire pour les tests est donc de monter un serveur web en local. NginX fera l'affaire.

Toutes ces informations sont le résultats de (longues) heures d'analyse des trames échangées, sans de réelles documentations à disposition... Elles peuvent donc être sujettes à des corrections au fil du temps...

Voir aussi l'Exemple de serveur pour v1

A noter :

Nabaztag v1 vasm
Nabaztag.magicmonkey.org
ploki.info
ADPCM2 en/decoding
Wikipédia