S autorom programa Email OAuth 2.0 Proxy pokusavam otkriti pod kojim se okolnostima desava da se odredjeni TCP paketi koje salje email client prema proxy-ju koji je na drugom kompjuteru u lokalnoj mrezi ne isporuce pa me zanimaju prijedlozi koje bi jos metode debuggiranja, osim onih koje sam vec koristio, mogo koristiti.
Proxy sluzi da bi se email clienti koji nemaju mogucnost OAuth2 autentifikacije preko njega spajali na gmail.
Situacija je sljedeca:
Kompjuter A:
- Staticka IP adresa
- Email client
- Wireshark
Kompjuter B:
- Staticka IP adresa
- Proxy
- Wireshark
Citanje poste preko POP protokola radi ispravno a slanje preko SMTP-a radi samo ako se u mail-u ne salje attachment i ako se u mail-u ne salje potpis koji sadrzi sliku a situacija je ista i kad se iskljuce svi firewall-i i antivirusi.
Ako prije slanja mail-a s attachment-om na obadva kompjutera pokrenem Wireshark capture onda na kompjuteru B vidim da u jednom trenutku paketi prestanu stizati a na kompjuteru A vidim da se za paket koji ne stize prije timeouta jos nekoliko puta desi retransmisija pa me zanima kako potvrditi da problem uzrokuje bas proxy program a da problem nije nesta drugo (OS, driveri, router, wifi adapter, email client, ...).
Autor proxy-ja tvrdi da njegov program nakon authentifikacije vise ne radi nikakvo parsiranje nego da TCP pakete samo prosljedjuje i da proxy ne moze utjecati na to da li ce se neki paket isporuciti od email client-a prema kompjuteru B ili nece ali sam u toku testiranja uhvatio nekoliko dogadjaja iz kojih se moze zakljuciti suprotno.
Iako citanje poste preko POP-a radi ispravno, povremeno (jedanput u tjedan dana) se desi da prilikom citanja poste proxy zablokira nakon cega Wireshark na kompjuteru B tako dugo dok se proxy ne zaustavi s Task Manager-om pa se opet restarta vise ne registrira niti jedan TCP paket kojeg salje email client.
Prema tome, proxy utjece na to da li ce se TCP paketi u kompjuteru B registrirati a izgleda da postoje dva slucaja:
1. Kada se desi da se iz nekog razloga TCP paketi ne isporuce za vrijeme komunikacije preko POP protokola (za vrijeme citanja mail-a) onda proxy zablokira i Wireshark vise ne vidi niti jedan TCP paket kojeg posalje email client sve dok se proxy ponovo ne restarta.
2. Kada se desi da se iz nekog razloga TCP paketi ne isporuce za vrijeme komunikacije preko SMTP protokola (za vrijeme slanja mail-a) onda proxy ne zablokira i moze se nastaviti koristiti nakon zaustavljanja slanja mail-a ili timeout-a.
Proxy za vrijeme rada u terminalu ispisuje odredjene poruke koje sprema i u .log file a ako se ukljuci debug mode onda u .log sprema i cijelu komunikaciju ali kad se opisani problem desi onda se ne ispisuje ni ne logira nista.
Zanima me kako debuggirati TCP pakete koji se nikad ne isporuce kad njih Wireshark u kompjuteru B niti ne vidi a Wireshark u kompjuteru A vidi samo retransmisije paketa koji se nije isporucio.
Kada u kompjuteru B pokrenem jos jedne Windows-e u kojima je isti email client koji se spaja na isti proxy koji je u kompjuteru B izvan virtualne masine onda slanje attachment-a radi ispravno.
Kad sam napravio capture slanja mail-a s attachment-om iz virtualne masine (gdje slanje radi ispravno) onda sam vidio da su svi TCP paketi jako kratki i da niti jedan paket nije imao duzinu vecu od 150 byte-ova a kad mail saljem preko email client-a u kompjuteru A onda najduzi TCP paketi imaju duzinu 1514 byte-ova (MTU je 1500).
Mislio sam da je problem u duzini paketa ali ako iz kompjutera A saljem mail bez attachment-a koji ima vise od 1500 byte-ova onda, iako ima paketa duzine 1514 byte-ova, sve radi ispravno.
Primijetio sam da se u paketima koji se salju iz email client-a u virtualnoj masini 0x0d 0x0a nikad ne javlja vise od jedanput (zato su u tom slucaju paketi kraci) a u paketima koji se salju s kompjutera A se 0x0d 0x0a pojavljuje vise puta. Recimo ako se u paketu pojavi:
0xc9 0x aa 0x0d 0x0a 0x0d 0x0a 0xbb
onda ce paketi poslani iz email client-a u virtualnoj masini izgledati ovako:
paket 1: 0xc9 0x0d 0x0a
paket 2: 0x0d 0x0a
paket 3: 0xbb
a kad se isti mail salje s email client-a u kompjuteru A onda se sve posalje u jednom paketu.
Mislio sam da je problem u vise od jednog 0x0d 0x0a u jednom paketu (iako je autor programa reko da nema parsiranja) pa sam probao poslati mail bez attachment-a u kojem sam na nekim mjestima stavio po nekoliko CRLF-ova i mail se je poslao ispravno bez obzira na to da je u jednom TCP paketu bilo vise pojavljivanja 0x0d 0x0a tako da problem nije niti u duzini paketa niti u visestrukom pojavljivaju CRLF.
Trenutno znaci trazim na koji nacin debuggirati pakete koji nikad ne stizu (a to se desava samo u slucaju kad se salje mail koji sadrzi attachment ili je u potpisu slika) da bi pronasao uzrok zato se to desava.
To da mail sadrzi attachment ili je u potpisu slika znaci da postoji i sadrzaj koji je MIME encoded (u email clientu se moze odabrati i BinHex i Uuencode ali je problem isti) ali ne vidim na koji bi nacin takav sadrzaj mogao poremetiti isporuku TCP paketa jer na kraju se opet prenose samo ASCII karakteri :-/
Ako ce nekog zanimati, puno vise detalja sam napisao ovdje. Tu sam stavio i capture paketa koji se nikad ne isporuce i jos dosta toga.