Infrastrutture e Applicazioni Avanzate dell'ICT

Re: Elaborazioni csi


Cronologico Percorso di conversazione 
  • From: Paolo Colucci < >
  • To: Simone Di Domenico < >
  • Cc: Laura Liberati < >,
  • Subject: Re: Elaborazioni csi
  • Date: Sat, 23 Jan 2016 14:43:49 +0100

Ciao ragazzi buon week end !!

Ho scoperto il "mistero" dei pkt vuoti. In pratica quando  log_to_file avverte il segnale di chiusura con CRTL+C fa partire una routine che prima di uccidere il processo chiude anche il buffer di lettura.
Simulando la chiusura con il comando "kill $PID" la routine non parte in quanto viene imposto un arresto forzato e quindi il buffer in lettura rimane aperto e genere quei pkt dummy.

La soluzione sta nel dare il comando "kill -INT $PID" che invia lo stesso segnale del CRTL+C e quindi chiude il buffer !!

Per quanto riguarda il real time, ho analizzato meglio il codice C in log_to_file: https://github.com/dhalperi/linux-80211n-csitool-supplementary/blob/master/netlink/log_to_file.c

/* Receive from socket with infinite timeout */
ret = recv(sock_fd, buf, sizeof(buf), 0);
if (ret == -1)
exit_program_err(-1, "recv");
/* Pull out the message portion and print some stats */
Questo è il dato (la struttura matlab) che arriva dal modulo del Kernel !!---->cmsg = NLMSG_DATA(buf);
f (count % SLOW_MSG_CNT == 0)
printf("received %d bytes: id: %d val: %d seq: %d clen: %d\n", cmsg->len, cmsg->id.idx, cmsg->id.val, cmsg->seq, cmsg->len);
/* Log the data to file */
l = (unsigned short) cmsg->len;
l2 = htons(l);
fwrite(&l2, 1, sizeof(unsigned short), out);
E questo è ciò che viene scritto sul file di out----> ret = fwrite(cmsg->data, 1, l, out);



A me "pare" che il buffer che arriva è già codificato in matlab e dal codice C al massimo si può dire dove salvarlo (o metterlo su un socket ogni tot arrivi !!). Non penso però che si possa convertire da C dalla struttura matlab a JSon o XML !!

Il giorno 23 gennaio 2016 01:25, Simone Di Domenico < " target="_blank"> > ha scritto:

Buonanotte,
per quanto riguarda i pacchetti, dovrebbe essere corretto che il loro numero sia intorno a 5k/6k, visto che le catture erano di 120 secondi per 50 pacchetti al secondo. Gli altri pacchetti vuoti magari saranno quelli da cui il csi non è stato correttamente estratto. Comunque, per capirlo Paolo può fare una prova e vedere su Wireshark se ci siano altri pacchetti oltre al ping.
Per quando riguarda il discorso real time, come dicevo oggi anche a Laura e Valerio, l'ideale sarebbe aprire un socket direttamente in C ed inviare, se possibile, i dati raw, quindi anche prima dell'eventuale scrittura in file matlab, in modo da renderci indipendenti da quest'ultimo. In numero di pacchetti da inviare dovrebbe essere settato come parametro nel file di configurazione.
Cerchiamo di risolvere queste cose per Martedì, visto che l'aula convegni è difficilmente disponibile. Priorità massima sul capire perché vengono catturati anche pacchetti "vuoti".
Fatemi sapere.
A presto,

Simone

On 23 Jan 2016 00:01, Laura Liberati < " target="_blank"> > wrote:

Abbiamo cominciato ad elaborare i dati e volevo far presente a tutti che i file mandati sono di 22k di pacchetti di cui solo i primi 5k e qualcosa sono riempiti i restanti risultano vuoti e davano anche errori nell'elaborazione ... quindi visto che dalle misure ne abbiamo presi circa 5k non ho idea da dove arrivino nel log tutti quei pacchetti vuoti salvati dalla traccia





Archivio con motore MhonArc 2.6.16.

§