Za svoj glavni log uporabljam DXKeeper, vendar za delo s postajo uporabljam N1MM Logger+, seveda imam med njima za povezavo nameščen še N1MM-DXKeeper Gateway. Zadeva ponavadi deluje brez velikih težav.
Zato je danes še toliko bolj zmedlo, ker je nenadoma – brez očitnega razloga – nehalo delovati. To se je zgodilo na računalniku, kjer je sevea vse na njemu z operacijskim sistemom Windows 10. Program N1MM je podatke uspešno pošiljal v Gateway, ta jih je posredoval naprej, a v DXKeeperju se ni pojavila nobena nova zveza. In kar je najbolj zanimivo: enaka konfiguracija je na novem računalniku z Windows 11 delovala brezhibno.
Sledil je dolg in temeljit postopek odkrivanja, ki je vključeval pregledovanje registra, primerjavo obeh sistemov, preverjanje požarnih zidov, pravic in celo ročno pošiljanje ukazov prek orodja netcat. A odgovor je bil ves čas pred nosom – skrit v podrobnostih omrežnih povezav.
Simptomi
Gateway je kazal result = sent (uspešno poslano), a zveze ni bilo v bazi.
DXKeeperjev errorlog ni kazal nobene napake, prav tako ni bilo nobenega odziva na ukaz externallog.
Na drugem računalniku z enako konfiguracijo je vse delovalo.Ključna sled
Po dolgem iskanju sem se odločil preveriti, katera vrata (porte) in kateri procesi jih poslušajo. Ukaz v ukazni vrstici je razkril skrito resnico:
CMD UKAZ:
netstat -ano | findstr 52001
CMD UKAZ:
tasklist | findstr 11940
tasklist | findstr 7416
Razlaga
DXKeeper je poslušal na vseh omrežnih vmesnikih (0.0.0.0:52001).
N1MM Logger+ pa je prav tako poslušal na istih vratih, vendar samo na lokalnem naslovu (127.0.0.1:52001).
Gateway je pošiljal ukaz na naslov 127.0.0.1:52001. Ta paket je sprejel N1MM (PID 7416), ne DXKeeper. Ker N1MM ne razume ukaza externallog, ga je tiho zavrgel.Gateway je sicer dobil potrditev, da je bil paket poslan (sent), a ker ga je prevzel napačen program, DXKeeper ni nikoli prejel zahtevka za zapis zveze. Na drugem računalniku ta konflikt ni obstajal, saj N1MM tam ni poslušal na vratih 52001.
Rešitev
Rešitev je bila presenetljivo preprosta:
V N1MM Logger+ sem odprl nastavitve Config → Configure Ports → WSJT / JTDX Setup.
V razdelku JTDX / Others TCP Settings sem za Radio #1 Settings spremenil TCP Port iz privzetega 52001 na prosti port, npr. 52006.
Po ponovnem zagonu N1MM Logger+ je vse steklo kot po maslu.
Zaključek
Uganka je bila rešena. Težava ni bila v nobeni od naštetih običajnih nastavitev – ne v registru, ne v bazi, ne v požarnem zidu – ampak v konfliktu dveh programov, ki sta poslušala ista vrata. Takšna težava se lahko pojavi kadarkoli, ko drug program (npr. JTDX, WSJT-X ali celo N1MM sam) zasede vrata, ki jih pričakuje DXKeeper.
Če se vam zgodi podobna težava, ne pozabite preveriti, kateri procesi poslušajo določena vrata – pogosto je odgovor skrit ravno tam, kjer ga najmanj pričakujete.