Questo e' il tracciato:

\x00\x00\x00\x00\x4d\x00\xf0\x00 <- intestazione (fissa)
\x4e\x4f\x56\x45\x47\x31 <- mittente da 6 byte ???? NOVEG1
\x00\x00\x00\x00 <- separatore (fisso)
\x41\x4c\x4c\x31\x32\x33 <- destinatario da 6 byte ??? ALL123
\x00\x00\x00\x00 <- separatore (fisso)
\x06 <- dimensione messaggio massimo 256 caratteri
\x00\x00\x00\x00\x00\x00\x00 <- separatore (fisso)
\x63\x69\x61\x6f\x31 <- messaggio (ciao1)
\x0d <- chiusura

che io ho tradotto così :

# COMPOSIZIONE ed INVIO della sequenza di Bites
def Invio_SM(X): # X contiene il testo da inviare / MessaggioCompleto
inte1 = chr(0)+chr(0)+chr(0)+chr(0)+chr(77)+chr(0) # parte iniziale intestazione
intes3 = chr(0) # parte finale intestazione
mittente = PST + "_______" # PST è il nome della Postazione Aggiungo se è meno di 6 caratteri
mittent1 = mittente[0:6:1] # Devono essere inviati MAX 6 caratteri
separatore = chr(0)+chr(0)+chr(0)+chr(0) # 4 caratteri NULL
destinatario = "TUTTI_" # sempre 6 caratteri
num = len(X)
numx = num - 1
#print("Lunghezza: ",str(num))
XT = X[0:numx:1] # tolgo il LF finale che non so da dove arriva
separ7 = chr(0)+chr(0)+chr(0)+chr(0)+chr(0)+chr(0)+chr(0) # 7 caratteri NULL

b_inte1 = inte1.encode()
values = 240
b_inte2 = values.to_bytes(1,'little') # parte intermedia intestazione carattere bastardo
b_inte3 = intes3.encode() # fine intestazione
b_mitte = mittent1.encode()
b_separ = separatore.encode()
b_desti = destinatario.encode()
b_lungh = num.to_bytes(1,'little') # conversione lunghezza testo in carattere HEX corrispondente
b_sepa7 = separ7.encode()
b_messa = XT.encode() # messaggio vero e proprio senza LF finale
values = 13
b_fine = values.to_bytes(1,'little') # carattere di chiusura
request = b_inte1 + b_inte2 +b_inte3 + b_mitte + b_separ + b_desti + b_separ + b_lungh + b_sepa7 + b_messa + b_fine

Da notare che il terminale originale mette sempre una unità in più sulla lunghezza messaggio
Ed il tutto si chiude col CR (0d) subito in coda al messaggio senza LF
A me veniva fuori un LF fra messaggio e CR e lo ho tolto in maniera brutale

Il server è sempre in funzione non capisco come sia possibile togliere l'allegato dal mio precedente messaggio
La cosa non ha importanza perchè serve solo per questo servizio

Ti chiedo una ultima cosa
Commenta il while di ricezione per non bloccare tutto e prova a fare un paio di invii, giusto per verifica

Ci leggiamo
Ciao



--- Ultima modifica di Pietro Bruno Lancerotto in data 2024-02-18 11:07:00 ---

Il tracciato l'avevo individuato, è proprio da li che mi son ricavato i byte "fastidiosi" da far ignorare allo echo-server per le prove.

Intendiamoci, ciò che sto cercando di fare è darTi un "la" per far girare il Tuo codice, non realizzare un terminale per un server di cui neanche conosco le specifiche, quell'aspetto tocca a Te.

Riguardo a ciò che intendevo mostrarTi ho concluso lo stretto indispensabile, nei 4 file che allegherò a questo post troverai uno denominato "server.py", lancialo da terminale, avrai un server a singolo accesso che stamperà a video il messaggio ricevuto (escludendo header e terminatore) e Ti ritrasmetterà lo stesso messaggio. Se invierai il messaggio 'CLOSE_REQUEST' il server si fermerà, naturalmente eventuali tentativi di comunicazione Ti daranno errore.
avrai inoltre un file "utility.py", in tale file ho definito delle classi di supporto a ciò che devi fare; la classe "Chatterbox" (chiaccherone) sostituisce tutte le Tue operazioni coi socket, richiamabile fornendo quali parametri l'host e la porta cui connettersi, fornisce una API con i comandi "connect" per avviare la connessione e "transmit" per inviare un messaggio elaborato dal Tuo programma, ho reso disponibile anche un comando "close" non utilizzato nel caso venisse l'esigenza di chiuderlo manualmente.

Nel connettersi Chatterbox lancia un thread di tipo daemon che provvede ad intercettare i messaggi che raggiungono il socket restituito dalla connessione, tale thread è parallelo e separato dal mainloop di tkinter.

Dato che i thread hanno spazio dei nomi separato (non conoscono le rispettive variabili) ho implementato un minimo di pattner observer, definendo un "postino" (Delivery) di tipo singleton che provvede a smistare dei "messaggi" tra i componenti iscritti della applicazione.

Ho quindi modificato opportunamente il Tuo codice, definendo il Tuo "terminale" quale "Chatterbox" ed adeguando i punti rilevanti, ho inoltre definito due metodi di classe nella tua "PAGINA", uno ("obs") registrato quale observer in due gruppi, l'altro perché provveda ad eliminare dette registrazioni, avvertire Chatterbox dell'imminente chiusura, perché faccia altrettanto e fermi il thread di ascolto, ed in fine chiusa l'applicazione.

I test eseguiti e l'attenzione prestata è stata per il solo pulsante "trasmetti", le conseguenze sugli altri comandi ed opzioni non le ho guardate.

Ti invito caldamente a provare con il server da me creato il codice che Ti propongo prima di ogni cosa, è già impostato, studialo per capire come funziona, guarda le differenze rispetto al Tuo codice e comprendile, solo dopo acquisita tale comprensione provalo con il Tuo SoundModem.

Ora tocca a Te, fai sapere se Ti è utile, ciao

P.S. - il discorso proposto è minimale, ma se qualche user a miglioramenti di approccio da proporre ...

Sono onorato di quello che pensi circa le mie capacità

Ho fatto un paio di aggiunte per far si che i messaggi in transito vengano memorizzati su disco

def obs(self, message: list) -> None:
op = message0
txt = ''
if op != 'ERROR':
txt = message1
else:
txt = 'AVVENUTO ERRORE : ' + message1
pkt_gui_rcs_support.Salvataggio(txt)
old = self.TestoRicevuto.get()
txt = old + '\n'+ txt
self.TestoRicevuto.set(txt)

Di poi il Salvataggio ( e no Savataggio / tirare le ciabatte / savatare in veneto )

La variabile PST vuota all'avvio creava errore a fronte del messaggio di connessione avvenuta, quindi ..

global PST
PST = "GENERICI"

e poi ..

# Apertura File LOG , Scrittura e chiusura
def Salvataggio(X):
global PST
LOGS = open("DATI_"+PST+".log", "a")
LOGS.write(X +"\n")
LOGS.close()

Alla apertura genera il file DATI_GENERICI.log che a me sta bene ci sia; successivamente DATI NomePostazione.log

Purtroppo con il SoundModem invia solamente senza inchiodamenti di sorta

Ho fatto la cattura del traffico che chiaramente per me è arabo
Magari Tu riesci a vederci qualcosa

Allego i file aggiornati e quelli di cattura
Intanto grazie

PS: Tengo aperto il SoundModem ulla porta 8000






--- Ultima modifica di Pietro Bruno Lancerotto in data 2024-02-19 14:59:21 ---

Sono incerto sulla interpretazione di questo commento, qualora le frasi cui sono collegate vengano interpretate quale critica esse non vogliono essere offensive ma il Tuo codice ed il modo di procedere mi evidenziano una forte voglia di "realizzare" quando i concetti di base relativi a python e tkinter e processi concorrenti non sono adeguati, quindi, volevano essere solo un incitamento ad approfondire gli argomenti in questione (decisamente complessi) prima di proseguire.

Pietro Bruno Lancerotto said @ 2024-02-19 14:53:55:

Ho fatto un paio di aggiunte per far si che i messaggi in transito vengano memorizzati su disco

Anche le strategie di gestione dei logs e di approccio alla connessione andrebbero meditate ... se è necessario un identificativo per la connessione, deve essere controllato sia definito, sulla base di uno specifico elenco qualora occorra, prima di stabilire la connessione ...

Non ho sollevato diversi argomenti, per non deviare il discorso dai quesiti posti ma ci sono numerosi fattori critici in ciò che stai facendo, uno per tutti l'esporre i messaggi di ritorno in una label, cosa che renderebbe ingestibile l'interfaccia in caso della ricezione di numerosi messaggi, un tkinter.Text sarebbe più indicato.

Continuando :

Pietro Bruno Lancerotto said @ 2024-02-19 14:53:55:

...
Purtroppo con il SoundModem invia solamente senza inchiodamenti di sorta
Ho fatto la cattura del traffico che chiaramente per me è arabo
Magari Tu riesci a vederci qualcosa
...
PS: Tengo aperto il SoundModem ulla porta 8000

Per caso, hai impostato anche il server di test che Ti ho inviato sulla porta 8000 invece che la 7679?
Lo chiedo perché ripulendo dai segnali di broadcast UDP vedo che le connessioni di entrambi i files indicano una connessione alla porta 8000 e sono praticamente identici:

Python 3.10.12 (main, Nov 20 2023, 15:14:05) [GCC 11.4.0] on linux
Type "help", "copyright", "credits" or "license()" for more information.
file_1 = 'CAP_Server_nuzzo.txt'
file_2 = 'CAP_SoundM_nuzzo.txt'
with open(file_1) as f:
    text = [x for x in f.read().splitlines() if 'localhost.8000' in x]

    
for r in text: print(r)

14:25:39.404119 IP localhost.55450 > localhost.8000: Flags [S], seq 3824417733, win 65535,
                   options [mss 65495,nop,wscale 8,nop,nop,sackOK], length 0
14:25:39.404119 IP localhost.8000 > localhost.55450: Flags [S.], seq 2514615797, ack 3824417734,
                   win 65535, options [mss 65495,nop,wscale 8,nop,nop,sackOK], length 0
14:25:39.404119 IP localhost.55450 > localhost.8000: Flags [.], ack 1, win 10233, length 0
14:26:09.199646 IP localhost.55450 > localhost.8000: Flags [P.], seq 1:113, ack 1, win 10233, length 112
14:26:09.199646 IP localhost.8000 > localhost.55450: Flags [.], ack 113, win 10233, length 0
14:26:09.199646 IP localhost.8000 > localhost.55450: Flags [P.], seq 1:76, ack 113, win 10233, length 75
14:26:09.199646 IP localhost.55450 > localhost.8000: Flags [.], ack 76, win 10233, length 0
14:26:15.869509 IP localhost.55450 > localhost.8000: Flags [R.], seq 113, ack 76, win 0, length 0
with open(file_2) as f:
    text = [x for x in f.read().splitlines() if 'localhost.8000' in x]

    
for r in text: print(r)

14:33:49.515111 IP localhost.8000 > localhost.55460: Flags [S.], seq 804332251, ack 3745156101,
                   win 65535, options [mss 65495,nop,wscale 8,nop,nop,sackOK], length 0
14:33:49.515111 IP localhost.55460 > localhost.8000: Flags S, seq 3745156100, win 65535, 
                   options [mss 65495,nop,wscale 8,nop,nop,sackOK], length 0
14:33:49.515111 IP localhost.55460 > localhost.8000: Flags [.], ack 1, win 10233, length 0
14:34:10.812965 IP localhost.8000 > localhost.55460: Flags [.], ack 113, win 10233, length 0
14:34:10.812965 IP localhost.55460 > localhost.8000: Flags [P.], seq 1:113, ack 1, win 10233, length 112
14:34:23.603896 IP localhost.8000 > localhost.55460: Flags [.], ack 225, win 10233, length 0
14:34:23.604899 IP localhost.55460 > localhost.8000: Flags [P.], seq 113:225, ack 1, win 10233, length 112
14:34:29.091459 IP localhost.55460 > localhost.8000: Flags [R.], seq 225, ack 1, win 0, length 0

Indicano una connessione invio di un pacchetto dati client-> server ed un pacchetto server->client, quindi un reset della connessione (flag [R.]) ... sembrano sessioni con lo stesso host!

Le domande sono : cosa che è hai fatto realmente', cosa vuoi dire con "SoundModem invia solamente senza inchiodamenti"?




EDIT : Mi correggo NON sono uguali, mi ero imbrogliato leggendo, nel secondo vi sono invii di pacchetti dati verso localhost.8000 ma nessuna trasmissione dati da parte di quest'ultimo.


--- Ultima modifica di nuzzopippo in data 2024-02-19 18:16:23 ---

--- Ultima modifica di nuzzopippo in data 2024-02-19 18:29:16 ---

Volevo dire che sono un emerito analfabeta

Magari mi destreggio con qualche funzione ma purtroppo molte cose di Python mi sono ostiche

Senza una conoscenza di base su come ragiona la faccenda e abbastanza difficile

Una su tutte... non riesco ad inquadrare le classi

nuzzopippo said @ 2024-02-19 18:11:30:

Anche le strategie di gestione dei logs e di approccio alla connessione andrebbero meditate ... se è necessario un identificativo per la connessione, deve essere controllato sia definito, sulla base di uno specifico elenco qualora occorra, prima di stabilire la connessione ...

Hai perfettamente ragione, ma non l'ho al momento considerata una priorità; sono fiducioso nei confronti degli operatori

nuzzopippo said @ 2024-02-19 18:11:30:

Non ho sollevato diversi argomenti, per non deviare il discorso dai quesiti posti ma ci sono numerosi fattori critici in ciò che stai facendo, uno per tutti l'esporre i messaggi di ritorno in una label,

Infatti proprio or ra ho inserito un controllo sulla lunghezza subito dopo il get


In definitiva è sufficente vedere gli ultimi messaggi perchè quello che conta è il log

nuzzopippo said @ 2024-02-19 18:11:30:

Per caso, hai impostato anche il server di test che Ti ho inviato sulla porta 8000 invece che la 7679?

Si l'ho messa su 8000 perchè il SM è impostato su quella

Ma se crea problemi cambio la porta di SM

nuzzopippo said @ 2024-02-19 18:11:30:

Le domande sono : cosa che è hai fatto realmente', cosa vuoi dire con "SoundModem invia solamente senza inchiodamenti"?
EDIT : Mi correggo NON sono uguali, mi ero imbrogliato leggendo, nel secondo vi sono invii di pacchetti dati verso localhost.8000 ma nessuna trasmissione dati da parte di quest'ultimo.

Volevo dire che se mi collego al SM , il sistema funziona solo in invio

Posso fare N invii che saranno perfettamente ricevuti da questo senza dare risposta




Il problema è capire cosa c'è di diverso fra gli invii verso SM e verso il tuo Server

Poi faccio una prova attivando il terminale e rimanendo in ascolto su SM con Radio accesa


Ascoltando l'APRS arrivano pacchetti a manetta

Giusto per vedere se solo l'eco che non viene rispedita o se non invia nulla




Cia e sempre grazie

Purtroppo, Ti sei imbarcato in una impresa complicata, che richiede tutta una serie di conoscenze a monte, e non riferisco al solo python.




Ho cercato un po' in rete, mi son reso conto di non avere idee riguardo il mondo AX25, sul quale essenzialmente si basa ciò che vuoi realizzare ... per altro mi son venuti dubbi riguardo al SoundModem, in particolare circa una sua "risposta".

Per altro, ho spesso incontrato menzione di altri "strumenti", tipo "direwolf" ed "easyterm" (un terminale), in particolare su questa interessante pagina, non saprei dire se possano esserTi utili (e magari li conosci già) comunque li segnalo.

Pietro Bruno Lancerotto said @ 2024-02-19 19:17:05:

Volevo dire che se mi collego al SM , il sistema funziona solo in invio
Posso fare N invii che saranno perfettamente ricevuti da questo senza dare risposta

Beh, almeno una parte funziona ,,,

Pietro Bruno Lancerotto said @ 2024-02-19 19:17:05:

Il problema è capire cosa c'è di diverso fra gli invii verso SM e verso il tuo Server

Il mio è un echo-server, progettato apposta perché risponda, non è detto che ciò che è impostato per SoundModem lo sia.

Per altro, vi è l'incognita del protocollo, non sapendo a priori come avviene il dialogo ... certo, nei primi pacchetti ricavati con wireshark che hai inviato la risposta di SoundModem al terminale specifico c'è, il sospetto che manchi qualcosa nella comunicazione con il terminale in costruzione sorge ... purtroppo, non mi è venuta alcuna idea su come individuare quel "qualcosa"

Pietro Bruno Lancerotto said @ 2024-02-19 19:17:05:

Poi faccio una prova attivando il terminale e rimanendo in ascolto su SM con Radio accesa
Ascoltando l'APRS arrivano pacchetti a manetta

Dove, sul Tuo terminale o su SoundModem?

Pietro Bruno Lancerotto said @ 2024-02-19 19:17:05:

Giusto per vedere se solo l'eco che non viene rispedita o se non invia nulla

Il dump della comunicazione tra il Tuo terminale e SoundModem evidenzia che non viene trasmesso nulla, da parte di quest'ultimo, prima del reset della connessione, bisognerebbe sincerarsi cosa differenzia la comunicazione (nei termini di protocollo e di invio dati) con il Tuo terminale e quell'altro di dotazione ... mi sembra di ricordare che nei precedenti post hai scritto di aver tolto qualcosa (un ritorno a capo mi pare) che Ti dava problemi, era sul pacchetto di invio?

Analizzando il pacchetto inviato trovavo che il mio messaggio si portava in coda un LF e poi il CR

Ho troncato il messaggio in modo che il messaggio sia seguito dal CR come in TERM

Tutto questo mondo ruota attorno a AGWPE

Proverò un altro terminale che ho nel PC collegato al RTX per vedere quello cosa trasmette

Per l'uso che ne abbiamo fatto noi era però più "intrigoso"; EasyTERM è più pratico

Il tutto è qui http://uz7.ho.ua/packetradio.htm




Catturo e poi Ti so dire




Ci leggiamo

Allego 3 catture fatte con 3 terminali diversi

Noto che i pacchetti che invia SM verso il terminale finiscono con CR CR NULL

Ho provato ad aggiungere giusto per verifica

Il tutto deve finire con un unico CR perchè si possa proseguire altrimenti SM non riceve più

AGWTerm è il padre di tutti


Ciao




PS: mi sono "studiato" ScrolledText(..)

ma per gestire il muose si tira dietro 'na montagna de roba

non è certamente la priorità per cui ...avanti con la Label







--- Ultima modifica di Pietro Bruno Lancerotto in data 2024-02-20 19:39:26 ---

Fatto il dump vedo che tutti e tre i terminali ricevono risposta dalla porta 8000

Python 3.10.12 (main, Nov 20 2023, 15:14:05) [GCC 11.4.0] on linux
Type "help", "copyright", "credits" or "license()" for more information.
file_1 = 'AGWTerm.txt'
file_2 = 'EasyTerm.txt'
file_3 = 'QtTermTCP.txt'
with open(file_1) as f:
    text = [x for x in f.read().splitlines() if 'localhost.8000' in x]

    
for r in text: print(r)

18:17:44.609242 IP localhost.52068 > localhost.8000: Flags [S], seq 416943911, win 65535, options [mss 65495,nop,wscale 8,nop,nop,sackOK], length 0
18:17:44.609242 IP localhost.8000 > localhost.52068: Flags [S.], seq 664282257, ack 416943912, win 65535, options [mss 65495,nop,wscale 8,nop,nop,sackOK], length 0
18:17:44.609242 IP localhost.52068 > localhost.8000: Flags [.], ack 1, win 10233, length 0
18:17:44.611241 IP localhost.52068 > localhost.8000: Flags [P.], seq 1:37, ack 1, win 10233, length 36
18:17:44.611241 IP localhost.8000 > localhost.52068: Flags [.], ack 37, win 10233, length 0
18:17:44.611241 IP localhost.8000 > localhost.52068: Flags [P.], seq 1:87, ack 37, win 10233, length 86
18:17:44.611241 IP localhost.52068 > localhost.8000: Flags [.], ack 87, win 10233, length 0
18:17:45.274261 IP localhost.52068 > localhost.8000: Flags [P.], seq 37:73, ack 87, win 10233, length 36
18:17:45.275258 IP localhost.8000 > localhost.52068: Flags [.], ack 73, win 10233, length 0
18:17:45.275258 IP localhost.52068 > localhost.8000: Flags [P.], seq 73:109, ack 87, win 10233, length 36
18:17:45.275258 IP localhost.8000 > localhost.52068: Flags [.], ack 109, win 10233, length 0
18:17:45.275258 IP localhost.8000 > localhost.52068: Flags [P.], seq 87:124, ack 109, win 10233, length 37
18:17:45.275258 IP localhost.52068 > localhost.8000: Flags [.], ack 124, win 10233, length 0
18:17:51.798749 IP localhost.8000 > localhost.52068: Flags [P.], seq 124:312, ack 109, win 10233, length 188
18:17:51.798749 IP localhost.52068 > localhost.8000: Flags [.], ack 312, win 10232, length 0
18:18:02.847759 IP localhost.8000 > localhost.52068: Flags [P.], seq 312:486, ack 109, win 10233, length 174
18:18:02.847759 IP localhost.52068 > localhost.8000: Flags [.], ack 486, win 10231, length 0
18:18:03.827759 IP localhost.8000 > localhost.52068: Flags [P.], seq 486:666, ack 109, win 10233, length 180
18:18:03.827759 IP localhost.52068 > localhost.8000: Flags [.], ack 666, win 10230, length 0
18:18:05.126066 IP localhost.52068 > localhost.8000: Flags [P.], seq 109:164, ack 666, win 10230, length 55
18:18:05.126066 IP localhost.8000 > localhost.52068: Flags [.], ack 164, win 10233, length 0
18:18:05.244388 IP localhost.8000 > localhost.52068: Flags [P.], seq 666:776, ack 164, win 10233, length 110
18:18:05.244388 IP localhost.52068 > localhost.8000: Flags [.], ack 776, win 10230, length 0
18:18:11.628663 IP localhost.8000 > localhost.52068: Flags [P.], seq 776:935, ack 164, win 10233, length 159
18:18:11.628663 IP localhost.52068 > localhost.8000: Flags [.], ack 935, win 10229, length 0
18:18:12.508850 IP localhost.8000 > localhost.52068: Flags [P.], seq 935:1100, ack 164, win 10233, length 165
18:18:12.508850 IP localhost.52068 > localhost.8000: Flags [.], ack 1100, win 10229, length 0
18:18:17.757787 IP localhost.8000 > localhost.52068: Flags [P.], seq 1100:1287, ack 164, win 10233, length 187
18:18:17.757787 IP localhost.52068 > localhost.8000: Flags [.], ack 1287, win 10228, length 0
18:18:20.677614 IP localhost.8000 > localhost.52068: Flags [P.], seq 1287:1428, ack 164, win 10233, length 141
18:18:20.677614 IP localhost.52068 > localhost.8000: Flags [.], ack 1428, win 10228, length 0
18:18:25.075585 IP localhost.52068 > localhost.8000: Flags [P.], seq 164:210, ack 1428, win 10228, length 46
18:18:25.075585 IP localhost.8000 > localhost.52068: Flags [.], ack 210, win 10232, length 0
18:18:25.123234 IP localhost.8000 > localhost.52068: Flags [P.], seq 1428:1529, ack 210, win 10232, length 101
18:18:25.123234 IP localhost.52068 > localhost.8000: Flags [.], ack 1529, win 10227, length 0
>>> with open(file_2) as f:
...     text = [x for x in f.read().splitlines() if 'localhost.8000' in x]
... 
...     
>>> for r in text: print(r)
... 
17:49:29.599048 IP localhost.8000 > localhost.51813: Flags [P.], seq 1794115577:1794115723, ack 59268856, win 10233, length 146
17:49:29.599048 IP localhost.51813 > localhost.8000: Flags [.], ack 146, win 10229, length 0
17:49:30.896758 IP localhost.8000 > localhost.51813: Flags [P.], seq 146:301, ack 1, win 10233, length 155
17:49:30.896758 IP localhost.51813 > localhost.8000: Flags [.], ack 301, win 10228, length 0
17:49:31.966997 IP localhost.8000 > localhost.51813: Flags [P.], seq 301:462, ack 1, win 10233, length 161
17:49:31.966997 IP localhost.51813 > localhost.8000: Flags [.], ack 462, win 10228, length 0
17:49:35.547816 IP localhost.8000 > localhost.51813: Flags [P.], seq 462:644, ack 1, win 10233, length 182
17:49:35.547816 IP localhost.51813 > localhost.8000: Flags [.], ack 644, win 10227, length 0
17:49:39.997085 IP localhost.8000 > localhost.51813: Flags [P.], seq 644:820, ack 1, win 10233, length 176
17:49:39.997085 IP localhost.51813 > localhost.8000: Flags [.], ack 820, win 10226, length 0
17:49:56.612474 IP localhost.51813 > localhost.8000: Flags [P.], seq 1:42, ack 820, win 10226, length 41
17:49:56.612474 IP localhost.8000 > localhost.51813: Flags [.], ack 42, win 10233, length 0
17:49:56.657948 IP localhost.8000 > localhost.51813: Flags [P.], seq 820:915, ack 42, win 10233, length 95
17:49:56.657948 IP localhost.51813 > localhost.8000: Flags [.], ack 915, win 10226, length 0
17:50:00.616768 IP localhost.8000 > localhost.51813: Flags [P.], seq 915:1060, ack 42, win 10233, length 145
17:50:00.616768 IP localhost.51813 > localhost.8000: Flags [.], ack 1060, win 10226, length 0
17:50:07.535732 IP localhost.51813 > localhost.8000: Flags [P.], seq 42:101, ack 1060, win 10226, length 59
17:50:07.535732 IP localhost.8000 > localhost.51813: Flags [.], ack 101, win 10232, length 0
17:50:07.843526 IP localhost.8000 > localhost.51813: Flags [P.], seq 1060:1174, ack 101, win 10232, length 114
17:50:07.843526 IP localhost.51813 > localhost.8000: Flags [.], ack 1174, win 10225, length 0
17:50:25.926558 IP localhost.8000 > localhost.51813: Flags [P.], seq 1174:1319, ack 101, win 10232, length 145
17:50:25.926558 IP localhost.51813 > localhost.8000: Flags [.], ack 1319, win 10225, length 0
>>> with open(file_3) as f:
...     text = [x for x in f.read().splitlines() if 'localhost.8000' in x]
... 
...     
>>> for r in text: print(r)
... 
17:36:46.313599 IP localhost.8000 > localhost.51755: Flags [P.], seq 1577673553:1577673719, ack 4221444206, win 10233, length 166
17:36:46.313599 IP localhost.51755 > localhost.8000: Flags [.], ack 166, win 10229, length 0
17:37:19.128719 IP localhost.8000 > localhost.51755: Flags [P.], seq 166:311, ack 1, win 10233, length 145
17:37:19.128719 IP localhost.51755 > localhost.8000: Flags [.], ack 311, win 10228, length 0

Ho notato, per altro, nei dati di AGWTerm un contemporanea notevole scambio dati tra le porte 51825-51826 di localhost ... ha qualche pertinenza?




Comunque, è evidente che nei terminali "professionali" all'invio dati SM risponde al realizzando terminale tkinter invece no ... certo manca "qualcosa" che personalmente non ho presente

Pietro Bruno Lancerotto said @ 2024-02-20 19:32:08:

Il tutto deve finire con un unico CR perchè si possa proseguire altrimenti SM non riceve più

Ed il CR lo hai inserito nel redigere il messaggio, per altro da quanto Hai indicato SM riceve il messaggio normalmente ma non da alcuna risposta, cercando in giro non ho trovato motivo del differente comportamento, forse non ho saputo cercare.

Temo che qua servirebbe un intervento di utenti più esperti di me, a parte l'incognita "protocollo AX.25" non vedo perché il seppur minimale codice adottato non riceva risposta.




C'è da dire che i socket hanno uniradidio di possibilità di configurazione, c'è da perdersi in merito alle varie opzioni, potrebbe anche essere in quell'ambito il problema

Pietro Bruno Lancerotto said @ 2024-02-20 19:32:08:

PS: mi sono "studiato" ScrolledText(..)
ma per gestire il muose si tira dietro 'na montagna de roba

Non so cosa sia ScrolledText ma per associare una tkinter.Text ad una scrollbar ad una scrollbar bastano 1 istruzione (oltre, naturalmente, le 2-3 per definire la scrollbar) ... sarei tentato di farTi un esempio di come vedrei io la Tua finestra (con le classi, ovvio) ... comunque, temo proprio avrebbe lo stesso problema di mancata risposta da parte di SM.




Ciao

Ho contattato l'autore che così risponde ( traduzione google):

Ciao, Pietro.

Puoi parlare con Soundmodem utilizzando l'API AGWPE:

https://www.on7lds.net/42/sites/default/files/AGWPEAPI.HTM

Vedo che stai tentando di inviare il frame dell'interfaccia utente (digita "M").

Se sei per ottenere qualcosa da Soundmodem devi attivarlo
questa funzione invia il frame 'k' per i dati "grezzi" o digita 'm'
per ottenere i fotogrammi del monitor 'I','S','U','T'.


Io provo a guardare ma non so se ci capiro qualcosa




Risposta originale

I see you are trying to send the UI frame (type 'M'). If you are

going to get anything from Soundmodem you must activate

this function sending the 'k'-frame for a "raw" data or type 'm'

for getting the 'I','S','U','T' monitor frames.



--- Ultima modifica di Pietro Bruno Lancerotto in data 2024-02-23 10:18:48 ---