non

Inserisci quello che vuoi cercare
non - nei commenti

HTML2POP3 2.56a - 26 Marzo 2019 - 21:22

Tin.it ha probabilmente cambiato pagina
Da oggi a pranzo non riesce piu' a scaricare la posta, indicando un errore di password. Ho provato anche la versione su html2pop3.baccan.it con lo stesso risultato. tin: SSO GET:http://webmailvtin.alice.it/cp/ps/Main/login/SSOLogin tin: LOGIN GET:http://webmailvtin.alice.it/cp/ps/Main/login/PreLogin?u=MIAEMAIL&d=tin.it&style=light&l=it java.lang.StringIndexOutOfBoundsException: String index out of range: -16 se la pagina chiamata e' https://webmailtin.pc.tim.it/cp/ps/Main/login/SSOLogin si entra in una situazione di errore per sito non sicuro, e poi si viene reindirizzati su https://mail.tim.it/ se invece e' quella sotto si viene reindirizzati a tim.it

HTML2POP3 2.56a - 18 Marzo 2019 - 16:45

tin.it ancora
Libero me la scarica, ma tin.it---non MI FA ACCEDERE-ultima versione di htmlpop3 logico. mio web server Fastweb----2 mega ---siamo alla preistoria----abito in campagna

Quando il reverse engineering è l'unica soluzione - 1 Marzo 2019 - 09:06

Re: Re: Re: Re: Log in CeNComLayer.dll
Buongiorno Matteo, Grazie ancora per la disponibilità! Sembra un problema di definizione dei parametri, non so se dipenda da node-ffi le definizioni le avevo prese da un esempio in c dove il terzo parametro era era un "DWORD dwSysError = 0x00000000;". Modificando il terzo parametro (o non passandolo...) la comunicazione si avvia. Appena ho risolto posto qui la definizione x node magari potrebbe essere utile a qualcun'altro. Grazie Ancora Buona Giornata, Roberto

Quando il reverse engineering è l'unica soluzione - 28 Febbraio 2019 - 14:03

Re: Re: Re: Log in CeNComLayer.dll
Ciao Rob ti lascio la riga (semplificata) che uso per la connessione eth // Setup porta IntByReference lpdwSysError = new IntByReference(); lpdwSysError.setValue(0); WinDef.DWORD CEFOpen = new WinDef.DWORD(0); // Creo il buffer per il ritorno Memory mOut = new Memory(255); mOut.setString(0, "192.168.1.121"); // Apro ethernet CEFOpen = cefdll.CEFOpenEth(mOut, new WinDef.DWORD(9100), lpdwSysError); in questo modo mi funziona. L'errore di sconnessione, a fronte di non traffico, mi fa pensare solo a un problema di interpretazione dei parametri di connessione che, pur giusti, sono utilizzati in modo errato per dimensionamento dei parametri di ingresso in DLL Il dubbio mi viene sul terzo parametro che è un riferimento ad una variabile e non un valore, nella dichiarazione che uso lo esternalizzo in questo modo WinDef.DWORD CEFOpenEth(Pointer strip, WinDef.DWORD dwPort, IntByReference lpdwSysError); Puntatore a stringa, DWORD come valore, Int by riferimento ciao matteo

Quando il reverse engineering è l'unica soluzione - 28 Febbraio 2019 - 09:45

Re: Re: Log in CeNComLayer.dll
Buongiorno Matteo, Grazie per la risposta di seguito rispetto ai punti elencati: 1) si, in effetti ho anche loggato con wireshark il traffico ed emulato in modo rudimentale i comandi con node e la libreria sua net per il collegamento tcp 2.1) node a 64bit, le librerie .dll a 32bit giustamente non vengono caricate da node-ffi 2.2) qualche dubbio ce l'ho ma dato che la connessione tcp viene avviata verso i corretti indirizzi e porte l'unico ulteriore parametro che potrebbe essere allocato in modo errato è il codice di errore. In pratica con node-ffi ho: var ffi = require('ffi') , ref = require('ref'); var cfd = ffi.Library('CeFdll.dll', { //DWORD CEFOpenEth (LPTSTR strIp, DWORD dwPort, LPDWORD lpdwSysError) "CEFOpenEth" : [ref.types.long, ['string', ref.types.long, ref.types.long]], }); var errBuf = 0x00000000; errBuf.type = ref.types.long var ret = cfd.CEFOpenEth( '192.168.1.121', 9100, errBuf); Qui l'esecuzione si interrompe senza restituire errori, solo node inspect restituisce ECONNRESET che però non dice nulla. Il log CeFdll.log contiene. [ Wed Feb 27 16:17:38 2019 ] CeComOutputDebugString Open ethernet core - Start [ Wed Feb 27 16:17:38 2019 ] CeComOutputDebugString Verify Printer Status Loggando il traffico con wireshark ho notato che dove dovrebbe esserci la chiamata corrispondente a "CEFOpenEth" ovvero gli hex "0x02, 0x30, 0x30, 0x30, 0x31, 0x31, 0x30, 0x39, 0x34, 0x37, 0x03" non c'è nulla e quindi la stampante interrompe la comunicazione. Sono abbastanza sicuro che il secondo log CeNComLayer.log potrebbe aiutare 2.3) Si il traffico arriva correttamente 2.4) Le connessioni in ingresso dovrebbero funzionare correttamente (vedi immagine traffico tcp) In effetti come dicevo ho provato a interfacciare direttamente la comunicazione con un semplice client tcp e copiando i comandi di controllo stampante ed in questo modo funziona correttamente, non sarebbe la soluzione migliore per via di possibili mancanze (questi comandi non sono descritti). Grazie ancora, Roberto

Quando il reverse engineering è l'unica soluzione - 28 Febbraio 2019 - 07:49

Re: Log in CeNComLayer.dll
Ciao Rob io farei questi controlli 1) Il demo della dll CeFDllDemo.exe funziona? 2) Se si ci sono alcune cose da controllare: 2.1) dll a 32 o 64 bit conpatibilmente con l'interfaccia usata 2.2) verifica dimensione dei parametri passati (strutture errate potrebbero causare un tentativo di connessione a indirizzo sbagliato e sconnessione immediata 2.3) Correttezza indirizzo di connessione stampante: il telnet su ip/porta funziona? Ricordo che avevo chiesto varie patch al kernel della stampante per sconnessioni e freeze dell'interfaccia tcp/ip 2.4) Usa un echo server per testare la connessione in ingresso in una finta stampante a valle di queste verifiche la situazione dovrebbe essere più chiara A livello protocollare la stampante gestisce una sequenza di byte abbastanza semplice, data da header di 4 byte 0x02 0x30 0x30 0x30 sequenza da inviare checksum da 2 byte se non ricord male terminatore 0x03 Spero che queste info, al netto del fatto che non ho accesso al codice, possano aiutarti ciao matteo

Quando il reverse engineering è l'unica soluzione - 27 Febbraio 2019 - 18:22

Log in CeNComLayer.dll
Buongiorno Sig. Baccan, Intanto Grazie per l'articolo che oltre ad essere interessante a livello didattico si pone anche utile a livello pratico per il chi sta approcciando la CeFdll.dll con un linguaggio non previsto... Nel mio caso sto cercando di ineragire via NodeJS + Node-ffi, rispetto al caso descritto nell'articolo la comunicazione si avvia ma si interrompe anche immediatamente e non viene restituito nessun errore (se non un generico ECONNRESET nell'inspect di node confermato dal controllo del traffico TCP che ho fatto con wireshark). Ho provato a dare un'occhiata in CeNComLayer.dll e sono sicuro che anche qui ci sia un un log da attivare (di default c:\CeNComLayer.log) ma non riesco a trovare un'analogo je da modificare. non mi dispiacerebbe creare un'interfaccia node da mettere su github magari con un'interscambio dati in xml. Mi rendo conto che l'articolo è di qualche tempo fa e che forse sono un pò off-topic! La ringrazio anticipatamente per un'eventuale risposta Cordiali Saluti, Roberto

HTML2POP3 2.56a - 24 Ottobre 2018 - 19:03

Re: Re: casella tin.it
Ciao Peppe no... non è questo il problema.... quando parte riesce a vuotare la casella ....

HTML2POP3 2.56a - 24 Ottobre 2018 - 11:12

Re: casella tin.it
Ciao riccardo donnini, come ho scritto a me è successo che il messaggio in questione non venisse scaricato perchè veniva bloccato dall'antivirus. Mi è bastato individuare il messaggio ed eliminarlo direttamente dall'interfaccia web, in questo modo html2pop3 non ha avuto più problemi. Ti consiglio di individuare qual'è il messaggio 4 e provare ad eliminarlo via web.

HTML2POP3 2.56a - 24 Ottobre 2018 - 10:58

casella tin.it
da qualche giorno non riesco a scaricare la posta da TIN.IT ogni tanto e qundo sono collegato da WEB sulla pagina TIN per CONNESIONI LIGHT risco a scaricare qualche messaggio dopo di che mi viene questo errore: Invio del comando RETR non riuscito. Errore mentre si cercava di recuperare un messaggio. Il server di posta 127.0.0.1 ha risposto: error retrieving message 4 qualcuno può aiutarmi? grazie