API v4 - connexion non fermée

Bonjour,

Je suis en train d’écrire une librairie python pour contrôler l’IPX800 (v4) et je m’aperçois de comportement bizarre. La connexion HTTP ne semble pas être correctement fermée sur les appels « ToggleR » et « ClearR », alors que tout se passe bien pour le « Get=R » et « SetR ». Je suis seulement sur les relais pour le moment. Est ce que cela vous parle ?

J’ai mis le firmware 4.01.01

Cordialement

2 « J'aime »

Bonjour,

Pour moi cela ne me parle pas tellement, par contre cela intéressera certainement @GCE.

J’utilise la version 4.01.04.b et çela semble marcher correctement ?

>curl --verbose http://192.168.1.32/api/xdevices.json?ToggleR=1
*   Trying 192.168.1.32...
* TCP_NODELAY set
* Connected to 192.168.1.32 (192.168.1.32) port 80 (#0)
> GET /api/xdevices.json?ToggleR=1 HTTP/1.1
> Host: 192.168.1.32
> User-Agent: curl/7.55.1
> Accept: */*
>
< HTTP/1.1 200 OK
< Access-Control-Allow-Origin: *
< Connection: close
< Content-Type: application/json
< Cache-Control: no-cache
<
{
    "product": "IPX800_V4",
    "status": "Success"
}
* Closing connection 0

Avec curl j’ai le même résultat en effet. Par contre je ne comprends pas pourquoi j’ai cet effet avec la librairie python que je fais avec « requests ». Est ce que quelqu’un est intéressé de tester :

Voilà des traces avec tcpdump pour tenter de comprendre la différence. Avec l’appel en python, le serveur IPX ne retourne pas de réponse. Est ce qu’il y a des paramètres HTTP qu’il n’aime pas, ou traite en générant une erreur qui n’est pas retournée ?

1 - Avec un appel curl : curl --trace - "http://192.168.78.30/api/xdevices.json?key=apikey&ClearR=4"

› sudo tcpdump -n -X -s 0 'host 192.168.78.30 and port 80'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on wlp2s0, link-type EN10MB (Ethernet), capture size 262144 bytes
19:40:01.827830 IP 192.168.78.200.48970 > 192.168.78.30.80: Flags [S], seq 537058402, win 64240, options [mss 1460,sackOK,TS val 2366651419 ecr 0,nop,wscale 7], length 0
	0x0000:  4500 003c a1e1 4000 4006 7aa3 c0a8 4ec8  E..<..@.@.z...N.
	0x0010:  c0a8 4e1e bf4a 0050 2002 dc62 0000 0000  ..N..J.P...b....
	0x0020:  a002 faf0 a9ac 0000 0204 05b4 0402 080a  ................
	0x0030:  8d10 3c1b 0000 0000 0103 0307            ..<.........
19:40:01.829953 IP 192.168.78.30.80 > 192.168.78.200.48970: Flags [S.], seq 1864078265, ack 537058403, win 2049, options [mss 536], length 0
	0x0000:  4500 002c 000d 0000 6406 3888 c0a8 4e1e  E..,....d.8...N.
	0x0010:  c0a8 4ec8 0050 bf4a 6f1b 93b9 2002 dc63  ..N..P.Jo......c
	0x0020:  6012 0801 b6a4 0000 0204 0218 0000       `.............
19:40:01.830011 IP 192.168.78.200.48970 > 192.168.78.30.80: Flags [.], ack 1, win 64240, length 0
	0x0000:  4500 0028 a1e2 4000 4006 7ab6 c0a8 4ec8  E..(..@.@.z...N.
	0x0010:  c0a8 4e1e bf4a 0050 2002 dc63 6f1b 93ba  ..N..J.P...co...
	0x0020:  5010 faf0 d7d5 0000                      P.......
19:40:01.830124 IP 192.168.78.200.48970 > 192.168.78.30.80: Flags [P.], seq 1:191, ack 1, win 64240, length 190: HTTP: GET /api/xdevices.json?key=apikey&ClearR=4 HTTP/1.1
	0x0000:  4500 00e6 a1e3 4000 4006 79f7 c0a8 4ec8  E.....@.@.y...N.
	0x0010:  c0a8 4e1e bf4a 0050 2002 dc63 6f1b 93ba  ..N..J.P...co...
	0x0020:  5018 faf0 5906 0000 4745 5420 2f61 7069  P...Y...GET./api
	0x0030:  2f78 6465 7669 6365 732e 6a73 6f6e 3f6b  /xdevices.json?k
	0x0040:  6579 3d61 7069 6b65 7926 436c 6561 7252  ey=apikey&ClearR
	0x0050:  3d34 2048 5454 502f 312e 310d 0a48 6f73  =4.HTTP/1.1..Hos
	0x0060:  743a 2031 3932 2e31 3638 2e37 382e 3330  t:.192.168.78.30
	0x0070:  0d0a 5573 6572 2d41 6765 6e74 3a20 4d6f  ..User-Agent:.Mo
	0x0080:  7a69 6c6c 612f 352e 3020 2858 3131 3b20  zilla/5.0.(X11;.
	0x0090:  5562 756e 7475 3b20 4c69 6e75 7820 7838  Ubuntu;.Linux.x8
	0x00a0:  365f 3634 3b20 7276 3a34 312e 3029 2047  6_64;.rv:41.0).G
	0x00b0:  6563 6b6f 2f32 3031 3030 3130 3120 4669  ecko/20100101.Fi
	0x00c0:  7265 666f 782f 3431 2e30 0d0a 4163 6365  refox/41.0..Acce
	0x00d0:  7074 3a20 2a2f 2a0d 0a52 6566 6572 6572  pt:.*/*..Referer
	0x00e0:  3a20 0d0a 0d0a                           :.....
19:40:01.832393 IP 192.168.78.30.80 > 192.168.78.200.48970: Flags [.], ack 191, win 3906, length 0
	0x0000:  4500 0028 000e 0000 6406 388b c0a8 4e1e  E..(....d.8...N.
	0x0010:  c0a8 4ec8 0050 bf4a 6f1b 93ba 2002 dd21  ..N..P.Jo......!
	0x0020:  5010 0f42 c2c6 0000 0000 0000 0000       P..B..........
19:40:01.835530 IP 192.168.78.30.80 > 192.168.78.200.48970: Flags [.], ack 191, win 1, length 0
	0x0000:  4500 0028 000f 0000 6406 388a c0a8 4e1e  E..(....d.8...N.
	0x0010:  c0a8 4ec8 0050 bf4a 6f1b 93ba 2002 dd21  ..N..P.Jo......!
	0x0020:  5010 0001 d207 0000 0000 0000 0000       P.............
19:40:01.836124 IP 192.168.78.30.80 > 192.168.78.200.48970: Flags [FP.], seq 1:186, ack 191, win 1, length 185: HTTP: HTTP/1.1 200 OK
	0x0000:  4500 00e1 0010 0000 6406 37d0 c0a8 4e1e  E.......d.7...N.
	0x0010:  c0a8 4ec8 0050 bf4a 6f1b 93ba 2002 dd21  ..N..P.Jo......!
	0x0020:  5019 0001 a844 0000 4854 5450 2f31 2e31  P....D..HTTP/1.1
	0x0030:  2032 3030 204f 4b0d 0a41 6363 6573 732d  .200.OK..Access-
	0x0040:  436f 6e74 726f 6c2d 416c 6c6f 772d 4f72  Control-Allow-Or
	0x0050:  6967 696e 3a20 2a0d 0a43 6f6e 6e65 6374  igin:.*..Connect
	0x0060:  696f 6e3a 2063 6c6f 7365 0d0a 436f 6e74  ion:.close..Cont
	0x0070:  656e 742d 5479 7065 3a20 6170 706c 6963  ent-Type:.applic
	0x0080:  6174 696f 6e2f 6a73 6f6e 0d0a 4361 6368  ation/json..Cach
	0x0090:  652d 436f 6e74 726f 6c3a 206e 6f2d 6361  e-Control:.no-ca
	0x00a0:  6368 650d 0a0d 0a7b 0d0a 2020 2020 2270  che....{......"p
	0x00b0:  726f 6475 6374 223a 2022 4950 5838 3030  roduct":."IPX800
	0x00c0:  5f56 3422 2c0d 0a20 2020 2022 7374 6174  _V4",......"stat
	0x00d0:  7573 223a 2022 5375 6363 6573 7322 0d0a  us":."Success"..
	0x00e0:  7d                                       }
19:40:01.836451 IP 192.168.78.200.48970 > 192.168.78.30.80: Flags [F.], seq 191, ack 187, win 64054, length 0
	0x0000:  4500 0028 a1e4 4000 4006 7ab4 c0a8 4ec8  E..(..@.@.z...N.
	0x0010:  c0a8 4e1e bf4a 0050 2002 dd21 6f1b 9474  ..N..J.P...!o..t
	0x0020:  5011 fa36 d716 0000                      P..6....
19:40:01.837781 IP 192.168.78.30.80 > 192.168.78.200.48970: Flags [.], ack 192, win 1, length 0
	0x0000:  4500 0028 0011 0000 6406 3888 c0a8 4e1e  E..(....d.8...N.
	0x0010:  c0a8 4ec8 0050 bf4a 6f1b 9473 2002 dd22  ..N..P.Jo..s..."
	0x0020:  5010 0001 d14d 0000 0000 0000 0000       P....M........
19:40:01.837814 IP 192.168.78.200.48970 > 192.168.78.30.80: Flags [.], ack 187, win 64054, length 0
	0x0000:  4500 0028 a1e5 4000 4006 7ab3 c0a8 4ec8  E..(..@.@.z...N.
	0x0010:  c0a8 4e1e bf4a 0050 2002 dd22 6f1b 9474  ..N..J.P..."o..t
	0x0020:  5010 fa36 d716 0000                      P..6....
19:40:01.841335 IP 192.168.78.30.80 > 192.168.78.200.48970: Flags [R], seq 1864078452, win 2049, length 0
	0x0000:  4500 0028 0012 0000 6406 3887 c0a8 4e1e  E..(....d.8...N.
	0x0010:  c0a8 4ec8 0050 bf4a 6f1b 9474 2002 dd22  ..N..P.Jo..t..."
	0x0020:  5004 0801 c958 0000 0000 0000 0000       P....X........
^C
11 packets captured
11 packets received by filter
0 packets dropped by kernel

Avec le code python de la librairie : r.off()

› sudo tcpdump -n -X -s 0 'host 192.168.78.30 and port 80'                   
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on wlp2s0, link-type EN10MB (Ethernet), capture size 262144 bytes
19:41:10.897771 IP 192.168.78.200.48992 > 192.168.78.30.80: Flags [S], seq 70474061, win 64240, options [mss 1460,sackOK,TS val 2366720489 ecr 0,nop,wscale 7], length 0
        0x0000:  4500 003c 99bb 4000 4006 82c9 c0a8 4ec8  E..<..@.@.....N.
        0x0010:  c0a8 4e1e bf60 0050 0433 594d 0000 0000  ..N..`.P.3YM....
        0x0020:  a002 faf0 3aac 0000 0204 05b4 0402 080a  ....:...........
        0x0030:  8d11 49e9 0000 0000 0103 0307            ..I.........
19:41:10.900653 IP 192.168.78.30.80 > 192.168.78.200.48992: Flags [S.], seq 4216541311, ack 70474062, win 2049, options [mss 536], length 0
        0x0000:  4500 002c 0013 0000 6406 3882 c0a8 4e1e  E..,....d.8...N.
        0x0010:  c0a8 4ec8 0050 bf60 fb53 507f 0433 594e  ..N..P.`.SP..3YN
        0x0020:  6012 0801 0c75 0000 0204 0218 0000       `....u........
19:41:10.900715 IP 192.168.78.200.48992 > 192.168.78.30.80: Flags [.], ack 1, win 64240, length 0
        0x0000:  4500 0028 99bc 4000 4006 82dc c0a8 4ec8  E..(..@.@.....N.
        0x0010:  c0a8 4e1e bf60 0050 0433 594e fb53 5080  ..N..`.P.3YN.SP.
        0x0020:  5010 faf0 2da6 0000                      P...-...
19:41:10.900824 IP 192.168.78.200.48992 > 192.168.78.30.80: Flags [P.], seq 1:159, ack 1, win 64240, length 158: HTTP: GET /api/xdevices.json?ClearR=4&key=apikey HTTP/1.1
        0x0000:  4500 00c6 99bd 4000 4006 823d c0a8 4ec8  E.....@.@..=..N.
        0x0010:  c0a8 4e1e bf60 0050 0433 594e fb53 5080  ..N..`.P.3YN.SP.
        0x0020:  5018 faf0 181f 0000 4745 5420 2f61 7069  P.......GET./api
        0x0030:  2f78 6465 7669 6365 732e 6a73 6f6e 3f43  /xdevices.json?C
        0x0040:  6c65 6172 523d 3426 6b65 793d 6170 696b  learR=4&key=apik
        0x0050:  6579 2048 5454 502f 312e 310d 0a48 6f73  ey.HTTP/1.1..Hos
        0x0060:  743a 2031 3932 2e31 3638 2e37 382e 3330  t:.192.168.78.30
        0x0070:  0d0a 4163 6365 7074 2d45 6e63 6f64 696e  ..Accept-Encodin
        0x0080:  673a 2069 6465 6e74 6974 790d 0a55 7365  g:.identity..Use
        0x0090:  722d 4167 656e 743a 2070 7974 686f 6e2d  r-Agent:.python-
        0x00a0:  7265 7175 6573 7473 2f32 2e32 322e 300d  requests/2.22.0.
        0x00b0:  0a43 6f6e 6e65 6374 696f 6e3a 2063 6c6f  .Connection:.clo
        0x00c0:  7365 0d0a 0d0a                           se....
19:41:10.903493 IP 192.168.78.30.80 > 192.168.78.200.48992: Flags [.], ack 159, win 3938, length 0
        0x0000:  4500 0028 0014 0000 6406 3885 c0a8 4e1e  E..(....d.8...N.
        0x0010:  c0a8 4ec8 0050 bf60 fb53 5080 0433 59ec  ..N..P.`.SP..3Y.
        0x0020:  5010 0f62 1897 0000 0000 0000 0000       P..b..........
19:41:12.903535 IP 192.168.78.200.48992 > 192.168.78.30.80: Flags [F.], seq 159, ack 1, win 64240, length 0
        0x0000:  4500 0028 99be 4000 4006 82da c0a8 4ec8  E..(..@.@.....N.
        0x0010:  c0a8 4e1e bf60 0050 0433 59ec fb53 5080  ..N..`.P.3Y..SP.
        0x0020:  5011 faf0 2d07 0000                      P...-...
19:41:13.115343 IP 192.168.78.200.48992 > 192.168.78.30.80: Flags [F.], seq 159, ack 1, win 64240, length 0
        0x0000:  4500 0028 99bf 4000 4006 82d9 c0a8 4ec8  E..(..@.@.....N.
        0x0010:  c0a8 4e1e bf60 0050 0433 59ec fb53 5080  ..N..`.P.3Y..SP.
        0x0020:  5011 faf0 2d07 0000                      P...-...
19:41:13.531515 IP 192.168.78.200.48992 > 192.168.78.30.80: Flags [F.], seq 159, ack 1, win 64240, length 0
        0x0000:  4500 0028 99c0 4000 4006 82d8 c0a8 4ec8  E..(..@.@.....N.
        0x0010:  c0a8 4e1e bf60 0050 0433 59ec fb53 5080  ..N..`.P.3Y..SP.
        0x0020:  5011 faf0 2d07 0000                      P...-...
19:41:14.359275 IP 192.168.78.200.48992 > 192.168.78.30.80: Flags [F.], seq 159, ack 1, win 64240, length 0
        0x0000:  4500 0028 99c1 4000 4006 82d7 c0a8 4ec8  E..(..@.@.....N.
        0x0010:  c0a8 4e1e bf60 0050 0433 59ec fb53 5080  ..N..`.P.3Y..SP.
        0x0020:  5011 faf0 2d07 0000                      P...-...
19:41:16.023408 IP 192.168.78.200.48992 > 192.168.78.30.80: Flags [F.], seq 159, ack 1, win 64240, length 0
        0x0000:  4500 0028 99c2 4000 4006 82d6 c0a8 4ec8  E..(..@.@.....N.
        0x0010:  c0a8 4e1e bf60 0050 0433 59ec fb53 5080  ..N..`.P.3Y..SP.
        0x0020:  5011 faf0 2d07 0000                      P...-...
19:41:19.383248 IP 192.168.78.200.48992 > 192.168.78.30.80: Flags [F.], seq 159, ack 1, win 64240, length 0
        0x0000:  4500 0028 99c3 4000 4006 82d5 c0a8 4ec8  E..(..@.@.....N.
        0x0010:  c0a8 4e1e bf60 0050 0433 59ec fb53 5080  ..N..`.P.3Y..SP.
        0x0020:  5011 faf0 2d07 0000                      P...-...
19:41:19.385839 IP 192.168.78.30.80 > 192.168.78.200.48992: Flags [R], seq 4216541312, win 2049, length 0
        0x0000:  4500 0028 0006 0000 6406 3893 c0a8 4e1e  E..(....d.8...N.
        0x0010:  c0a8 4ec8 0050 bf60 fb53 5080 0000 0000  ..N..P.`.SP.....
        0x0020:  5004 0801 7e23 0000 0000 0000 0000       P...~#........
^C
12 packets captured
12 packets received by filter
0 packets dropped by kernel

On voit que l’IPX ne répond et après 2 secondes la connexion est coupée via le timeout sur l’appel.

1 « J'aime »

Bonsoir,

@GCE je pense avoir trouvé le bug qui vient de l’IPX800. La différence entre les appels que j’ai pu mettre en avant est celui ci : dans l’appel « ClearR », si le 1er paramètre est « key » pour la clé d’api alors j’obtiens une réponse du serveur. Par contre si le 1er paramètre est ClearR, je n’obtiens pas de réponse.

Cela se démontre facilement en faisant ces 2 appels :

pas de réponse = curl --trace - "http://<IP>/api/xdevices.json?ClearR=4&key=apikey"

versus

réponse OK = curl --trace - "http://<IP>/api/xdevices.json?key=apikey&ClearR=4"

Est ce que vous confirmez ce bug de votre côté ? J’appelle bien cela un bug car l’ordre des paramètres ne doit pas influencer le résultat sauf pour les listes.

1 « J'aime »

Il ne s’agit pas d’un bug…l’apikey doit toujours être envoyé en premier sinon la commande n’est pas traitée.

Pour la lecture de l’état cela fonctionne par exemple d’avoir l’apikey après. Dans tous les cas le protocole HTTP ne défini pas une notion d’ordre des paramètres. Tous les frameworks web ne se basent pas sur l’ordre mais sur un dictionnaire de clé-valeur pour obtenir les paramètres d’une requête.

Quelle est votre contrainte qui vous impose de l’avoir en 1er ?

Je viens de faire d’autres tests, et je peux faire des requêtes avec la commande en 1er et la clé en 2ème et j’obtiens bien une réponse pour : Get=R et SetR. Ce qui contredit votre point à moins qu’il y ait des exceptions.

Pour ClearR et ToggleR, le serveur ne retourne pas de réponse mais semble exécuter quelque chose lors de l’appel suivant (par exemple pour obtenir le statut avec Get=R) car la réponse met quelques secondes à venir. Le relai est toujours passé à 0 à ce moment là. Cela donne l’impression d’un « reset » interne.

Bonjour,

Je vais regarder cela ce matin. Si le protocole ne définit pas l’ordre, dans les spécifications de la v4, c’est ce qui avait été demandé. Il y a peut être des exceptions mais ce n’est pas voulu car il était prévu initialement que l’apikey devait toujours être envoyé en premier une fois le socket ouvert et l’apikey envoyée il n’est pas nécessaire de la renvoyer, les commandes sont traitées normalement tant que le socket reste ouvert.

Cdt

Concernant ce fait que le serveur ne réponde pas si la 1ère clé n’est pas celle de l’API. Il serait souhaitable de retourner une erreur, car ne pas retourner de réponse est plus ennuyeux. Pouvez-vous retourner une erreur HTTP 400 (Bad request - https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/400) montrant que le serveur ne comprend pas la requête.

De même que retourner un code 400 quand la réponse est une erreur serait plus conforme que de retourner une réponse 200.

Bonjour,

Une refonte complete de l’API est en cours d’étude, j’aborderais ce sujet avec mon équipe;

Cdt

3 « J'aime »

Bonsoir,

Est ce que vous confirmez le point précédent ? Vous parliez de tests pour confirmer mes remarques.

J’ai relu votre message et je trouve plutôt étonnant au niveau sécurité de ne pas devoir renvoyer l’apikey car cela peut rendre vulnérable à des attaques simples l’IPX si on le place derrière un reverse proxy.

Bonjour,

J’ai fait une erreur en mélangeant avec le M2M (commande direct sur socket tcp)
En requête API (via HTTP) il faut systématiquement inclure l’apikey.
En M2M il suffit de l’envoyer une seule fois.

Cdt

1 « J'aime »

Bonjour, je suis tombé sur vos travaux sur GitHub et vu que vous aviez ajouté récemment de nouvelles fonctions (lecture des entrées analogiques).
Python a clairement le vent en poupe et je suis ravis que vous vous penchiez sur l’IPX800.
D’autres projets de développement prévus ?

Bonjour @spK

Oui la librairie avance en terme de fonctionnalité (doucement). Je viens de rajouter les parties sur les relais virtuels avec la version 0.4. Si vous avez des besoins particuliers sur la librairie python, n’hésitez pas à m’ouvrir un ticket sur github pour que je travaille sur cette partie prochainement.

Je prévois de faire un programme cli aussi pour manipuler l’IPX800 de manière simple.

1 « J'aime »

Bonjour @marcaurele

Avec l’arrivée imminente de la v5, penses-tu t’y attaquer également ?

A lire la description du produit, ça devrait presque être plus facile à intégrer si c’est réellement du REST. Il me restera le problème de faire cela sans l’unité avec de la documentation uniquement.
Je verrais si j’arrive à négocier quelque chose pour avoir une unité si c’est trop problématique avec uniquement la documentation.