217 odpovědí na toto téma

[PabloM64]

Po instalaci GeoGetu jsem přenesl nastavení původní složky Data.
Poté, když jsem zjistil, že GgDrake nefunguje, provedl jsem, u tohoto pluginu, přeinstalaci.
Nepomohlo to. Plugin jsem tedy odinstaloval a nainstaloval znovu. Nepomohlo.
Přeinstaloval jsem GeoGet - nepomohlo.

[gord]

To je divne. Uz jen pokud preneses cely datovy adresar, melo by byt vse jako na puvodnim pocitaci.

 

Tohle je problem pri volani obsluzne procedury a jelikoz stejny zdrojak chodi na jinych pocitacich bez problemu, tak mi to pripada jako datove zavisle. Chova se to stejne i kdyz nastavis (spravne) rucni pripojeni?

[PabloM64]

Ruční připojení jsem nezkoušel. A nyní to nevyzkouším. Nejdříve až budu odpoledne doma.

[gord]

Dobre. Pak dej vedet uz pres SZ, budem to spolu resit mimo vlakno a sem pak dam az vysledek.

[gord]

Problem nalezen, opraveno. Na cerstve novem PC chybely nejake knihovny, tak jsem to doplnil do dokumentace pluginu.

[Pontiac_CZ]

Zjistil jsem empiricky, že GgDrake nepřenáší keše s kódem, který nezačíná GC****.

 

Připravuju nové keše a napadlo mě (prvně ), proč pro rozdělanou keš nepoužít taky Geoget.

 

Protože nemám zatím založený listing, tak jsem si vytvořil "bod" s vymyšleným ID, např. ABCDEF. Geoget to vezme, tam není problém. Ale GgDrake to nepřenese do aDrake. Nevím, kde je problém, možná je až v aDrake.

 

 

Keš jsem v aDrake nenašel.

 

 

Když jsem ID změnil, aby začínal na GC, už to proběhlo v pořádku a keš šla najít v aDrake.

 

[gord]

Zjevne bylo GPX odeslano. Takze bude spis otazkou toho, zda AD to importuje a zda to hledas spravne, pripadne to AD umi.

[LudekV]

Vždyť to tam je napsané .

ABCDEF není keš, ale waypoint s prefixem AB ke keši GCCDEF. Pokud chceš fiktivní keš, musí začínat GC.

Mimochodem, pokud začne WM, je to waymark, pokud GS, je to GeoSpy (žije to vůbec ještě?)

[Pontiac_CZ]

OK, když musí začínat GC, nemám s tím problém. Testovací keši jsem změnil ID na GC_ABCDEF a již se přenesla. Jen její waypoint ne, tam je nějaká zrada.

 

GgDrake píše:

SendGpxFile: start
      odpověď: Počet importovaných keší: 1
Počet aktualizovaných keší: 0
Počet importovaných waypointů: 0
22:05:45 | GC_ABCDEF - test prenosu [inserted]
22:05:45 | TE_ABCDEF - testovací waypoint
   SendGpxFile: ok

A aDrake také hlásí, že údajně waypoint naimportoval:

 

 

 

Nicméně sekce s waypointy v detailu keše v aDrake je prázdná.

Tento příspěvek byl upraven od Pontiac_CZ: 13 březen 2019 - 14:35

[Pontiac_CZ]

Myslím, že už jsem to zmiňoval - co dělat s problémem navázání spojení při připojení přes wi-fi? Nevím, jestli tím trpím jenom já, ale třeba mi to někdo potvrdí...

 

Na a:Drake spustím GeoGet Sync. To vypadá takto:

 

 

V GeoGetu spustím GgDrake - ten vypadá následovně:

 

 

Jak vidno, mám ho v ručním režimu. Kliknu na tlačítko "Připojit" a pak se 15 sekund dívám na následující informaci:

 

 

a poté se to vrátí do dialogu GgDrake s chybovou hláškou:

 

 

Z prvního screenshotu je zjevné, že aDrake běží. Mimochodem, GgDrake zobrazí i irelevantní informaci "MTP - a:Drake nenalezeno" - přitom ale přísahám, že jsem klikal na "Připojit" se symbolem wi-fi, MTP nepoužívám.

 

Navázání spojení z GgDrake se takto mnohdy podaří až na po-xté, pokud vůbec. Dřív pomáhalo z mobilu pingnout PC, ale posledních pár dní ani to ne.

 

Zkusil jsem i režim "Automaticky" - chvíli to hledalo a pak vyplivlo: ERR: IP adresa nenalezena, k síti není připojeno žádné zařízení s a:Drake

 

[gord]

Michas 2 veci dohromady. Pokud das "Pripojit", zkousi se oba typy pripojeni, protoze pro nektere funkce je lepsi to a pro jine ono. Protoze nemas telefon pripojeny USB kabelem, hlasi, ze pres MTP a:Drake nenasel.

 

Pripojeni pres WiFi se sklada ze 2 kroku:

1. vyhledani telefonu, ke kteremu se pripojit, tento krok ziska IP adresu telefonu
2. pres IP adresu se do AD posle prikaz a ceka se na jeho odpoved

Rucni pripojeni preskakuje 1. krok a pouzije se rucne nastavena IP adresa. Pak se na tuto adresu posila prikaz a pokud do timeoutu neprijde odpoved, plugin ohlasi chybu.

 

Tohle vypada, ze pripojeni nefunguje tak jak je ocekavano. Pingnes si z PC na tu IP adresu?

[Pontiac_CZ]

Zkouším ten ping, ale vrací to "cílový hostitel není dostupný". Ale samozřejmě nevím, jestli Android 8 standardně echo vrací.

[LudekV]

Jsi si jistý, že telefon i PC jsou ve stejné síti? Jakou IP adresu má PC? Co se stane, když adresu telefonu i s portem 8080 zadáš do web browseru?

[Pontiac_CZ]

Mám tu jediný router s jediným subnetem 10.9.8.x. Moje PC má konkrétně 10.9.8.7.

 

Když do Firefoxu dám do adresního řádku "10.9.8.13:8080", tak chvíli zkouší a po chvíli time-outuje.

 

Ale zvláštní věc: pustil jsem v CMD pingání na mobil a samozřejmě to psalo "není dostupný". Pak jsem z mobilu z jedné síťové utilitky zkusil port scan na mém PC, nějaké otevřené porty to našlo a vzápětí se ping začal vracet. Už se ozývá i prohlížeč (unknown operation) a už jde i konexe v GgDrake.

 

Straší mi tu?  

[LudekV]

Takže to vypadá, že ti cosi blokuje síťovou komunikaci. Ale to je bohužel mimo moje znalosti.

[Kreten8]

No já bez problémů provozuji tablet na wifi síti, která je jiná od sítě PC, na kterém mám pevně nastavenou IP adresu tabletu, se kterým má GeoGet komunikovat. Takže zde bych viděl problém v arp tabulce některého zařízení po cestě. Máš switch? router? oboje? Jaká je tedy cesta od PC k mobilu?

[pjiy]

Tak tak, problém je opravdu asi v arp tabulkách na switchích (to je hrozný slovo), ale  je to na obsáhlejší troubleshooting, na který tady asi není prostor, je potřeba znát strukturu sítě, adresní plány, co se na ní děje, atd. Obecně je lépe používat rezervované IP adresy na MAC oproti automatickému multicastu (rezervace umí snad DHCP server na každém routeru), pak je celkem jedno, jestli je vše na 1 subnetu. Dál zkontrolovat napadení routeru nějakým malwarem (není úplně neobvyklé), udělat reset routeru a novou konfigurací (obvyklé je přeplnění nějakých tabulek), dělat pingy z obou stran spojení (každý TCPIP stack musí umět odpovědi na ping, není-li to firewallem blokované) a mnoho dalšího.

Taky všelijaké obskurní firewally dokáží provádět hrozné věci.

Taky používám WiFi připojení (FTP, WEB, GGdrake, ….) pro všechny přenosy mezi PC a různými androidy doma, bez toho bych se vůbec neobešel.

No moc jsem teda nepomohl.

[Pontiac_CZ]

Jo, zjevně to bude něco zvláštního u mě.

Cesta: PC -> UTP -> switch Netgear -> UTP -> router ASUS -> wi-fi 5 GHz -> mobil

 

Směruješ to zřejmě dobře k ARP... Když si ve Windows v CMD zobrazím pomocí arp -a ARP tabulku, tak tam mobil není. Ani ping na něj to nenapraví. Až když na mobilu v síťové utilitce, o kterém jsem mluvil výše, nechám prozkoumat otevřené porty na PC, tak arp -a už vrací i položku s adresou mobilu. A jde taky pingnout.

 

Ale pozor: po minutě už ping zase nešel a v ARP tabulce už záznam s adresou mobilu zase nebyl. Je možné, že by expiroval tak brzo?

[pjiy]

Je to takto:

 

Older versions of Windows used to have a timeout of 2 minutes for ARP entries. This has changed in Vista and Server 2008 onwards to comply with RFC4861. The new implementation has lowered this time to a random value between 15 seconds and 45 seconds

[pjiy]

Můžeš ten arp záznam ve windows nastavit natvrdo, ale podmínkou je ta statická IP adresa.  Ale trvalé řešení to není.

Např.

arp -s 157.55.85.212   00-aa-00-62-c6-09