Re: [IRPF-Livre, Rnetclient] Impossível enviar declaração

Mar Jun 2 22:53:16 UTC 2026

Em 25/05/2026 20:06, Alexandre Oliva escreveu:
> Não tenho certeza.  Parece-me que precisei fazer alterações ao t.java
> para que aa.java fosse compilado com as modificações, mas depois das
> alterações, não tive mais erros.  Pode ser que nem precisasse delas, ou

Consegui sem alterar t.java.

Além disso, usando SSLKEYLOGFILE (e um complemento que me possibilitou 
usar este em Java) e tcpdump como root antes de rodar o Receitanet 
customizado e rnetclient ambos como usuário normal, consegui os arquivos 
PCAP em anexo e o arquivo de segredos SSL/TLS que pode ser adicionado 
nas preferências do Wireshark para o protocolo TLS, que possibilita ver 
detalhes dos pacotes mesmo que dentro de uma sessão SSL/TLS.

Conforme escrevi hoje na sala usuarios-gnu no XMPP, não sei se é o 
motivo do problema de envio, mas notei que servidor da RFB está enviando 
uma mensagem com `pos_inicio`, e depois disso, o programa de referência 
envia a declaração usando o mesmo ticket de sessão TLS, mas no caso do 
rnetclient, depois de o próprio rnetclient enviar o quinto pacote (ver 
`doc/FORMATO` no repositório do rnetclient), ou seja antes do pacote 
contendo o arquivo da declaração em si, o próprio rnetclient parece 
terminar a sessão TLS e depois há um novo ticket de sessão TLS enviado 
pelo servidor, com uma mensagem `pos_inicio` (presumo que seja aquela 
esperada pelo programa de referência), seguida de outra separada com a 
mensagem de erro, ambas vindas do servidor, mas ainda não sei se o 
fechamento da sessão pelo cliente tem alguma relevância para causar o erro.

Em adendo, depois daquele comentário, fazendo mais testes, descobri que 
se modificar rnetclient para salvar os resultados de gnutls_record_recv 
em uma variável do tipo ssize_t e inspecionar no GDB, o retorno parece 
ser -28 que, segundo o que tenho anotado aqui, deve ser algo como 
GNUTLS_E_AGAIN. Além disso, observei que o texto armazenado pelos usos 
de rnet_recv não é o texto inteiro dado pelo servidor. Todavia, como eu 
não tenho muito conhecimento em Java ou linguagens de baixo nível como C 
(apenas shell, Python, etc), não sei como fazer para que o rnetclient 
entenda os pacotes retornados pelo servidor (ver FIXME deixado por mim 
no patch em anexo).

Tirando o endereço MAC, IP e porta que variam conforme declaração ou 
cliente, o quinto pacote (enviado pelo cliente, antes do envio do DEC 
emm si), parece ser similar para ambos os clientes. O que me dá a 
impressão que o problema está na troca de comunicações entre 
cliente-servidor.

Não sei se cascardo acompanha esta lista, mas para 
https://sr.ht/~cascardo/rnetclient/, com base nas observações acima, fiz 
o patch mencionado.

Como não tenho experiência em C ou outras linguagens que requerem gestão 
manual da memória, sintam-se a vontade para corrigir quaisquer erros de 
minha parte.

Caso não tenha ficado claro, gostaria de sugestões ou patches de como 
fazer rnetclient ler o sexto pacote (enviado pelo servidor) e 
condicionalmente o sétimo, se existir.

------------ próxima parte ------------
A non-text attachment was scrubbed...
Name: Receitanet.pcap
Type: application/vnd.tcpdump.pcap
Size: 8415 bytes
Desc: no disponible
URL: <http://www.fsfla.org/pipermail/softwares-impostos/attachments/20260602/c57485f7/attachment-0003.pcap>
------------ próxima parte ------------
SERVER_HANDSHAKE_TRAFFIC_SECRET 2498ac496a2dcceb4294c75784d9a9570430a1da699eb7532327c71e395d1a1d b4db380852a5e1df3e153f172f17c1ddb5f8e3c7edd0bbc8bf315115f85be4259b2dc3c8b136bb6534273a9d066ec63c
CLIENT_HANDSHAKE_TRAFFIC_SECRET 2498ac496a2dcceb4294c75784d9a9570430a1da699eb7532327c71e395d1a1d 5bcd8c67c4d90dd8a4c3375f540bfc86097ecbfd46f8638410dc624e1f752fcfcacd4fdef8f61be58f47ab031433efbb
SERVER_TRAFFIC_SECRET_0 2498ac496a2dcceb4294c75784d9a9570430a1da699eb7532327c71e395d1a1d f8635f49175d9620e2990a5fbc73bf54cb501fff025ec2a7dccc7277e02b0d2d96b2f13bf3a861fb20d8d5e6d4880936
CLIENT_TRAFFIC_SECRET_0 2498ac496a2dcceb4294c75784d9a9570430a1da699eb7532327c71e395d1a1d a865404cd2f10dd1b3fa9004caea598827d2612e7f20c0c2d18a055bde917473a47151e624e345d02349fe83f7e97429
CLIENT_HANDSHAKE_TRAFFIC_SECRET 957696fdbe6eb4b3438895e20d92dc98edb122bf66c23e4c7d3f60690ac5498e 19a34f91f009e93464dac9f95bcaa4cd377c9778aeb6a526fa8250ed6462d1fcfeb186d4a9fe35d7a4501d2742b9845e
SERVER_HANDSHAKE_TRAFFIC_SECRET 957696fdbe6eb4b3438895e20d92dc98edb122bf66c23e4c7d3f60690ac5498e f9596e840a02bb41e54339e6cd79d9c8717ce8c710b20da02dbd20ebdc9eac3aef57614ac6b2fa47b5863e3e5f07a0a5
EXPORTER_SECRET 957696fdbe6eb4b3438895e20d92dc98edb122bf66c23e4c7d3f60690ac5498e e00d288460967503aab7da8089e0ded92cb1e000f6e21ae5064b99b4133f17262ca276bbe63444f0d0d321f42100450b
CLIENT_TRAFFIC_SECRET_0 957696fdbe6eb4b3438895e20d92dc98edb122bf66c23e4c7d3f60690ac5498e 56d8a376bc04916e5421f717314a1d908cb4c61220d034fb4d43b3b42068da6d26a0d11c613032f3cb1c2e45f2e3aabd
SERVER_TRAFFIC_SECRET_0 957696fdbe6eb4b3438895e20d92dc98edb122bf66c23e4c7d3f60690ac5498e 3b736205f048050e1ef64cacffcd0a843c6aeafc3f0ec3b21bd57f21514606bc2ea1c5f1ac63ccd3d508ea19a2cc43a6
CLIENT_HANDSHAKE_TRAFFIC_SECRET 6e924adc5e0ad9a2ec787bd94dbdce1e376c1572221c8d7eb3c14163632e0391 8a008cd588486410ff23f2eccb648e0ef5fae64e814724e58a537fc108a7e0e4088ea374f5b0f005e83318c00962d902
SERVER_HANDSHAKE_TRAFFIC_SECRET 6e924adc5e0ad9a2ec787bd94dbdce1e376c1572221c8d7eb3c14163632e0391 9471d24c29f97b9b0a9c4d94df877502a1cc8561284c797bf0002a3ee16ab2ef35e3be451203af25411f019c049175f1
EXPORTER_SECRET 6e924adc5e0ad9a2ec787bd94dbdce1e376c1572221c8d7eb3c14163632e0391 260f777a820a8f5b52689369ba5f3eacabc92fd2488b322fe93c7fcfd661c2accda4575d3e759967e0d4175f95fac9da
CLIENT_TRAFFIC_SECRET_0 6e924adc5e0ad9a2ec787bd94dbdce1e376c1572221c8d7eb3c14163632e0391 de991e50c7e267491bce158a96a3d82cf2f7d175137f1cd4e8aa14e75b5538f458ddbbe2a69189146f631ae28810ac73
SERVER_TRAFFIC_SECRET_0 6e924adc5e0ad9a2ec787bd94dbdce1e376c1572221c8d7eb3c14163632e0391 154dd5b35c0d25c4fe30c34c2076c2da8ffaef11a5bfba6f6553ff695f9a3fecde34b4fc8178d692ca74567c238fe61c
------------ próxima parte ------------
A non-text attachment was scrubbed...
Name: rnetclient mesma declaração.pcap
Type: application/vnd.tcpdump.pcap
Size: 6514 bytes
Desc: no disponible
URL: <http://www.fsfla.org/pipermail/softwares-impostos/attachments/20260602/c57485f7/attachment-0004.pcap>
------------ próxima parte ------------
A non-text attachment was scrubbed...
Name: rnetclient nova declaração.pcap
Type: application/vnd.tcpdump.pcap
Size: 6241 bytes
Desc: no disponible
URL: <http://www.fsfla.org/pipermail/softwares-impostos/attachments/20260602/c57485f7/attachment-0005.pcap>
------------ próxima parte ------------
A non-text attachment was scrubbed...
Name: 0001-Add-2026-with-warning-get-DEC-s-MAC-JVM-connection-s.patch
Type: text/x-patch
Size: 18685 bytes
Desc: no disponible
URL: <http://www.fsfla.org/pipermail/softwares-impostos/attachments/20260602/c57485f7/attachment-0001.bin>
------------ próxima parte ------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 236 bytes
Desc: OpenPGP digital signature
URL: <http://www.fsfla.org/pipermail/softwares-impostos/attachments/20260602/c57485f7/attachment-0001.sig>