Elektroda.pl
Elektroda.pl
X
Proszę, dodaj wyjątek dla www.elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

Blokowanie się Programu Płatnika 7 w systemie Windows 98

09 Sty 2008 18:27 7888 48
  • Poziom 21  
    Do blokady programu dochodzi w trakcie otwierania listy certyfikatów lub przesyłania dokumentów za pomocą SDWI. Trwa to od kilku do kilkunastu minut.

    W przypadku komputerów łączących się z Internetem za pośrednictwem komutowanego połączenia (Dial-Up Networking), efekt blokowania się występuje tylko w czasie połączenia. Tak więc przeglądanie listy certyfikatów nie blokuje programu do momentu połączenia z Internetem. Oczywiście, w czasie przesyłania dokumentów do ZUS odłączenie od Internetu nie jest sposobem na obejście blokady. Innymi słowy użytkownicy stałego połączenia z Internetem, mają kompletnie przechlapane.

    Płatnik 7.02.001 wydaje się blokować, tylko przy pierszym wejściu na listę certyfikatów. Płatnik 7.01.001 blokował się przy każdym wejściu na tę listę (przynajmniej według moich własnych obserwacji).

    Jedyna pomoc jaką udało mi się uzyskać ze strony ZUSu, to wyjaśnienie, że winne jest Windows 98. Z tego co wywnioskowałem wynika, że Płatnik kontroluje przechowywane w magazynie systemowym certyfikaty dodając brakujące w razie potrzeby. Proces sprawdzania certyfikatów trwa bardzo długo, z niewyjaśnionych przyczyn.
  • Poziom 10  
    Taki wpis znalazłem na jednej ze stron:

    "Program Płatnik wersja 7.01.001 jest przygotowany pod obsługe certyfikatów kwalifikowanych.
    Dłuższy czas dostępu wynika z długiego działania funkcji weryfikującej poprawność certyfikatów na systemie Windows 98.
    Nie istnienie możliwość przyspieszenia jej działania, gdyż odpowiednie modyfikacje w tym zakresie
    są dostępne jedynie na nowszych systemach. Pewną poprawę można uzyskać
    poprzez wyłączenie weryfikacji wstępnej certyfikatów w Ustawieniach
    przekazu elektronicznego.
    Prosze spróbowac wyłaczyc opcje Wyswietlaj odcisk klucza..."


    Przyznam że aktuaizowałem ostatnio płatnika na kliku komp. pracujacych na win98se i nie było tego typu problemów (v7.01.001).
    Może warto było by zainstalować nieoficjalny service pack 2 dla win 98
    http://dobreprogramy.pl/index.php?dz=2&t=35&id=772
  • Poziom 21  
    Podczas instalacji lub aktualizacji nie widać żadnych oznak istnienia problemu. Dopiero wizyta na liście certyfikatów, lub próba wysłania dokumentów ujawnia problem. W przypadku komputerów wykorzystujących Dial-Up występowanie problemu jest jeszcze bardziej ograniczone.

    Problem obserwowałam na sześciu komputerach. Każdy miał zainstalowane Windows 98 SE PL oraz IE 5.5 SP2 lub IE 6 SP1. Wszystkie miały zainstalowany Nieoficjalny Service Pack 2.1a lub 2.1b. Nie miałem okazji obserwować komputera w systemem Windows 98 całkowicie pozbawionego efektu blokady.

    Ostatnie eksperymenty wykazały, że w systemie Windows 2000 weryfikacja certyfikatów jest natychmiastowa, a komputer nie lączy się z Internetem. W windows 98 sytuacja wygląda zupełnie inaczej. Komputer łączy się z portalami cc.unet.pl, www.cc.unet.pl, oraz adresem IP 195.205.248.71:80. Po każdym połączeniu z 195.205.248.71:80 występuje 45 sekundowa przerwa.

    W zależności od ilości certyfikatów zmienia się ilość prób połączenia z 195.205.248.71:80. Nie udało mi się jednak ustalić, które certyfikaty są odpowiedzialne za konkretne próby połączeń.
  • Moderator na urlopie...
    Może wyjściem jest pobranie certyfikatów ręcznie z cc.unet.pl. Zadzwoń na infolinię Płatnika dość konkretni ludzie tam pracują. Przy wersji 6 A-E - przesłali mi na maila jakąś łatkę, też mi się program sypał przy certyfikatach.
  • Poziom 21  
    Dzoniłem już na infolinię płatnika. Powiedzieli mi, że winne jest Windows 98, i nic nie mogę z tym zrobić.

    Ręczne pobranie certyfikatów nic nie zmieni, gdyż problematyczne jest sprawdzanie zainstalowania certyfikatów, a nie sama instalacja. Procedura sprawdzająca jest wykonywana po każdym uruchomieniu Płatnika. Nawet, jeżeli wszystkie stosowne certyfikaty znajdują się w magazynie systemowym, to Płatnik przyblokuje się w trakcie weryfikacji tego faktu.
  • Poziom 30  
    Aktualizacje WindowsUpdate + nieoficjalny patch o którym pisał kolega powinny pomóć. Z innej beczki - pora przesiadać się już na XP. Łatwo powiedzieć, wiem, ale 98 nie jest juz wspieranym systemem i stąd pewnie problem a z tego co widzę niestsety coraz więcej producentów oprogramowania wypina się na 98 :-(
  • Poziom 21  
    Problem występuje nawet z całkowicie zaktualizowanym systemem.

    Ale, znalazłem rozwiązanie. Wczoraj eksperymentowałem z biblioteką Płatnika odpowiedzialną za certyfikaty. W rejestrze systemowym można zablokować tylko część funkcjonalności tej biblioteki.

    Usunięcie wpisów odpowiedzialnych za funkcję sprawdzania certyfikatów, powoduje wyświetlenie komunikatu o braku ważnego certyfikatu OOP. (Komunikat nie ma oczywiście racji, gdyż certyfikat OOP jest ważny.) Po zamknięciu komunikatu wszystko działa tak jak powinno, bez zbędnego czekania na weryfikację certyfikatów w magazynie systemowym.

    Tak więc, instalacja systemu XP jest o wiele bardziej skomplikowanym rozwiązaniem, niż usunięcie jednego klucza w rejestrze systemowym. Nie wspominając już o cenie licencji Windows XP i nowego komputera.
  • Poziom 21  
    Miałem okazję obserwować Płatnika w połączeniu z systemem Windows 95. Funkcja kontroli i dodawania certyfikatów do magazynu systemowego nie działa całkowicie. Podczas próby dodania certyfikatu do magazynu, płatnik żąda włożenia dyskietki do stacji A:. Anulowanie tej operacji powoduje zatrzymanie procedury. Tak więc w systemie Windows 95 może być konieczne ręczne dodanie certyfikatów do magazynu systemowego.

    Wracając do systemu Windows 98. Po usunięciu klucza rejestru:
    HKEY_CLASSES_ROOT\Interface\{7AB5C758-522C-41FD-948F-E99FF615A572}
    Procedura sprawdzania jest przerywana, tak więc nie ma opóźnień i blokowania programu. Niestety jest jednak skutek uboczny. Płatnik nie wyłącza się prawidłowo. W systemie pozostaje aktywny proces "Elogerr". Dopiero jego awaryjne zakończenie pozwoli na prawidłowe zamknięcie systemu. W przeciwnym przypadku system nie wyłączy się tak jak powinien. Jest to klasyczny problem związany z użytkowaniem systemu Windows 98. Nawet jedna nieprawidłowo zamknięta aplikacja, lub zawieszona biblioteka potrafi zablokować procedurę wyłączenia komputera.

    ----------------------------------

    Wygląda na to, że problem jest nieco bardziej skomplikowany. Proces "Elogerr" jest częścią innego pakietu oprogramowania. Na innych komputerach nie występuje. Pomimo tego, kłopoty z wyłączaniem Systemu Windows 98 po użyciu Płatnika (z usuniętym kluczem rejestru odpowiedzialnym za sprawdzanie certyfikatów) wydają się występować także na innych komputerach.
  • Poziom 30  
    Jak już kolega sprawdzi i będzie pewny tego co pisze prosimy o informacje bo jka na razie możnaby sądzić że podane rozwiązanie jest nieskuteczne i spowodowało błąd...
  • Poziom 21  
    Rozwiązanie działa. Ale, mogłem je przetestować na ograniczonej ilości komputerów. Dodatkowym utrudnieniem jest fakt, że nie mogę testować transmisji na zawołanie. Potrzebny jest zestaw danych, a właściwie konieczność wysłania danych do ZUS.

    Modyfikację rejestru polegającą na usunięciu klucza HKEY_CLASSES_ROOT\Interface\{7AB5C758-522C-41FD-948F-E99FF615A572} zastosowałem w biurze rachunkowym. Po wysłaniu kilku zestawów, oraz odebraniu potwierdzeń, mogę stwierdzić, że rozwiązanie działa, i jest skuteczne.

    Obserwowałem jednak przypadki, w których komputer nie dawał się wyłączyć za pomocą standardowej procedury zamknięcia systemu. W tej chwili nie mogę jednoznacznie stwierdzić zależności pomiędzy poprawką w rejestrze a problemami z wyłączeniem komputera. Wbrew wcześniejszym obserwacjom efekt nie jest powtarzalny. Nie zmienia to faktu, że potencjalny problem z wyłączaniem komputera nie ma istotnego wpływu na działanie samego Programu Płatnika.

    Pomysł testowałem na własnych komputerach, ale zdążyłem go wykorzystać tylko u dwóch klientów. Następne dni powinny przynieść więcej okazji do obserwacji.

    Podsumowując:
    - rozwiązanie działa.
    - może istnieć problem z wyłączeniem komputera po użyciu funkcji trasmisjii danych do ZUS w Płatniku.
  • Poziom 1  
    Dzięki za podpowiedź - przyda się.
    Dodam tylko do opisu problemu, że przy połączeniach z bazą MS SQL "blokowanie się stacji Windows 98", ma miejsce tylko w momencie przygotowywania wysyłki.

    Jeśli idzie o propozycje przesiadki na XP, to w tym wypadku poproszę o podpowiedź - a jaką propozycję ma "podpowiadacz" dla zwalniania pracy w środowisku CS Clariona na serwerach Novell.
    Pod Win98 wykonanie zestawienia zajmuje 6 minut, a ze stacji XP to samo zestawienie to już 24 minuty. Co ciekawe stacja z 98 to Duron 1800+ a WinXp Athlon 3200+
  • Poziom 21  
    Najbardziej denerwujący jest fakt, że problem można było bardzo łatwo rozwiązać poprzez dodanie "wyłącznika" kontroli certyfikatów w Płatniku.
    Można było by włączać i wyłączać tę funkcję w zależności od sytuacji. Ale Prokom po prostu wie lepiej. Certyfikaty trzeba koniecznie skontrolować w każdej sesji Płatnika. Jest także całkowicie bez znaczenia jak często Płatnik jest uruchamiany w trakcie dnia.

    Podsumowując, twórcy Płatnika po prostu "olali" użytkowników systemu Windows 98. Ich wymówką jest wina po stronie systemu operacyjnego. Oni po prostu nie mają obowiązku rozważać wygody użytkowników. Ich odpowiedź na skargi to: kupcie sobie Windows XP.

    Zastanawiam się, czy jest to wystarczająca podstawa do wysnucia teorii spisku Prokomu i Microsoftu. Dawno temu Microsoft i Prokom podpisali umowę o wzajemnej współpracy. Teraz Prokom stara się napełnić kieszenie Microsoftu nakłaniając użytkowników starych systemów Microsoftu do płatnej przesiadki na Windows XP.
  • Poziom 1  
    powiem tak jeśli mogę .....
    według mojej wiedzy i praktyki płatnik nie blokuje się na win98 tylko tak długo weryfikuje certyfikaty ;-) trwa to od 1 min nawet do 15 min więc przed pierwszą wysyłką kawka ;-) pasjans ;-) poczta ;-) i co tam kto lubi potem jak już przebrniemy przez weryfikację to wysyłki idą jak trzeba i bez specjalnych problemów
    Pozdrawiam i cierpliwości życzę
  • Poziom 21  
    Zgadzam się. Blokada o której pisałem jest skutkiem weryfikacji certyfikatów.

    Cały dowcip polega na tym, że Windows 98 usiłuje coś weryfikować za pośrednictwem Internetu. Nowsze systemy operacyjne tego nie robią.

    Dla płatnika wysyłającego dokumenty raz na miesiąc nie jest problemem odczekanie kilku minut. W biurach rachunkowych Płatnik jest uruchamiany wielokrotnie w ciągu jednego dnia. Łączny czas poświęcony na oczekiwanie w trakcie weryfikacji certyfikatów jest w takim przypadku bardzo istotny.

    ---------------------------

    A tak przy okazji. Płatnik 7.02.001 ma jeszcze jeden błąd. Numery certyfikatów są teraz podawane w formie szesnastkowej.
  • Poziom 35  
    Znalazłem rozwiązanie problemu, które sprawdza się w 99%. Polega ono na wyłączeniu routowania dla adresów z którymi chce się łączyć PP przy weryfikacji certyfikatów. Niestety udało mi się to zrobić jedynie zakresami przez co przyblokowanych jest tez część innych adresów.
    Powinny byc zablokowane adresy:
    -213.222.192.30
    -cc.unet.pl 212.160.73.62
    -www.ca.unet.pl 195.205.248.71

    A oto plik bat który uruchamiam w autostarcie (192.168.1.254 jest u mnie adresem routera, należy go zmienić na własny):

    @echo off
    route delete 0.0.0.0

    route add 0.0.0.0 mask 128.0.0.0 192.168.1.254
    route add 128.0.0.0 mask 192.0.0.0 192.168.1.254

    route add 192.0.0.0 mask 255.0.0.0 192.168.1.254
    route add 193.0.0.0 mask 255.0.0.0 192.168.1.254
    route add 194.0.0.0 mask 255.0.0.0 192.168.1.254
    route add 196.0.0.0 mask 255.0.0.0 192.168.1.254
    route add 197.0.0.0 mask 255.0.0.0 192.168.1.254
    route add 198.0.0.0 mask 255.0.0.0 192.168.1.254
    route add 199.0.0.0 mask 255.0.0.0 192.168.1.254
    route add 200.0.0.0 mask 255.0.0.0 192.168.1.254
    route add 201.0.0.0 mask 255.0.0.0 192.168.1.254
    route add 202.0.0.0 mask 255.0.0.0 192.168.1.254
    route add 203.0.0.0 mask 255.0.0.0 192.168.1.254
    route add 204.0.0.0 mask 255.0.0.0 192.168.1.254
    route add 205.0.0.0 mask 255.0.0.0 192.168.1.254
    route add 206.0.0.0 mask 255.0.0.0 192.168.1.254
    route add 207.0.0.0 mask 255.0.0.0 192.168.1.254
    route add 208.0.0.0 mask 255.0.0.0 192.168.1.254
    route add 209.0.0.0 mask 255.0.0.0 192.168.1.254
    route add 210.0.0.0 mask 255.0.0.0 192.168.1.254
    route add 211.0.0.0 mask 255.0.0.0 192.168.1.254
    route add 214.0.0.0 mask 255.0.0.0 192.168.1.254
    route add 215.0.0.0 mask 255.0.0.0 192.168.1.254
    route add 216.0.0.0 mask 255.0.0.0 192.168.1.254
    route add 217.0.0.0 mask 255.0.0.0 192.168.1.254
    route add 218.0.0.0 mask 255.0.0.0 192.168.1.254
    route add 219.0.0.0 mask 255.0.0.0 192.168.1.254
    route add 220.0.0.0 mask 255.0.0.0 192.168.1.254
    route add 221.0.0.0 mask 255.0.0.0 192.168.1.254
    route add 222.0.0.0 mask 255.0.0.0 192.168.1.254
    route add 223.0.0.0 mask 255.0.0.0 192.168.1.254

    route add 195.0.0.0 mask 255.128.0.0 192.168.1.254
    route add 195.128.0.0 mask 255.224.0.0 192.168.1.254
    route add 195.160.0.0 mask 255.224.0.0 192.168.1.254
    route add 195.224.0.0 mask 255.224.0.0 192.168.1.254

    route add 212.0.0.0 mask 255.128.0.0 192.168.1.254
    route add 212.128.0.0 mask 255.224.0.0 192.168.1.254
    route add 212.192.0.0 mask 255.224.0.0 192.168.1.254
    route add 212.224.0.0 mask 255.224.0.0 192.168.1.254

    route add 213.0.0.0 mask 255.128.0.0 192.168.1.254
    route add 213.128.0.0 mask 255.224.0.0 192.168.1.254
    route add 213.160.0.0 mask 255.224.0.0 192.168.1.254
    route add 213.224.0.0 mask 255.224.0.0 192.168.1.254
  • Poziom 35  
    Czekam na uwagi odnośnie działania tego rozwiązania.
    Przetestowałem już swoje rozwiązanie na kilku komputerach i nie zauważyłem dodatkowych efektów ubocznych, mogę wiec śmiało polecić.
  • Poziom 21  
    Rozwiązanie wydaje się być odpowiednie dla komputerów współdzielących stałe łącze internetowe. Jego zastosowanie w systemach podłączonych przy pomocy dostępu wdzwanianego nie jest oczywista.
  • Poziom 35  
    W komputerach Z dial-upem "usterka" Programu Płatnika nie jest na szczęście taka odczuwalna, można normalnie wejść do programu, pracować, nie odczuwa się żadnych "przytkań". Dopiero w momencie wysyłki mogą występować "przytkania" programu a je zwykle robi sie znacznie rzadziej niż sama edycja, wydruki itp.
  • Poziom 21  
    Zgadzam się. Wynika z tego, że skrypt należałoby wykonać, już po połączeniu z Internetem. Problem w tym, że adres bramy jest przydzielany przez DHCP. Założenie, że adres bramy jest stały nie wydaje się być w takim przypadku bezpieczne.

    ---- Edit
    Dokonałem drobnej poprawki umożliwiającej łatwiejsze przystosowanie skryptu do indywidualnych adresów bramy. Teraz wystarczy ustawić zmienną GATEWAY na adres bramy w sieci lokalnej.

    Code:
    @echo off
    
    SET GATEWAY=192.168.122.253
    route delete 0.0.0.0

    route add 0.0.0.0 mask 128.0.0.0 %GATEWAY%
    route add 128.0.0.0 mask 192.0.0.0 %GATEWAY%

    route add 192.0.0.0 mask 255.0.0.0 %GATEWAY%
    route add 193.0.0.0 mask 255.0.0.0 %GATEWAY%
    route add 194.0.0.0 mask 255.0.0.0 %GATEWAY%
    route add 196.0.0.0 mask 255.0.0.0 %GATEWAY%
    route add 197.0.0.0 mask 255.0.0.0 %GATEWAY%
    route add 198.0.0.0 mask 255.0.0.0 %GATEWAY%
    route add 199.0.0.0 mask 255.0.0.0 %GATEWAY%
    route add 200.0.0.0 mask 255.0.0.0 %GATEWAY%
    route add 201.0.0.0 mask 255.0.0.0 %GATEWAY%
    route add 202.0.0.0 mask 255.0.0.0 %GATEWAY%
    route add 203.0.0.0 mask 255.0.0.0 %GATEWAY%
    route add 204.0.0.0 mask 255.0.0.0 %GATEWAY%
    route add 205.0.0.0 mask 255.0.0.0 %GATEWAY%
    route add 206.0.0.0 mask 255.0.0.0 %GATEWAY%
    route add 207.0.0.0 mask 255.0.0.0 %GATEWAY%
    route add 208.0.0.0 mask 255.0.0.0 %GATEWAY%
    route add 209.0.0.0 mask 255.0.0.0 %GATEWAY%
    route add 210.0.0.0 mask 255.0.0.0 %GATEWAY%
    route add 211.0.0.0 mask 255.0.0.0 %GATEWAY%
    route add 214.0.0.0 mask 255.0.0.0 %GATEWAY%
    route add 215.0.0.0 mask 255.0.0.0 %GATEWAY%
    route add 216.0.0.0 mask 255.0.0.0 %GATEWAY%
    route add 217.0.0.0 mask 255.0.0.0 %GATEWAY%
    route add 218.0.0.0 mask 255.0.0.0 %GATEWAY%
    route add 219.0.0.0 mask 255.0.0.0 %GATEWAY%
    route add 220.0.0.0 mask 255.0.0.0 %GATEWAY%
    route add 221.0.0.0 mask 255.0.0.0 %GATEWAY%
    route add 222.0.0.0 mask 255.0.0.0 %GATEWAY%
    route add 223.0.0.0 mask 255.0.0.0 %GATEWAY%

    route add 195.0.0.0 mask 255.128.0.0 %GATEWAY%
    route add 195.128.0.0 mask 255.224.0.0 %GATEWAY%
    route add 195.160.0.0 mask 255.224.0.0 %GATEWAY%
    route add 195.224.0.0 mask 255.224.0.0 %GATEWAY%

    route add 212.0.0.0 mask 255.128.0.0 %GATEWAY%
    route add 212.128.0.0 mask 255.224.0.0 %GATEWAY%
    route add 212.192.0.0 mask 255.224.0.0 %GATEWAY%
    route add 212.224.0.0 mask 255.224.0.0 %GATEWAY%

    route add 213.0.0.0 mask 255.128.0.0 %GATEWAY%
    route add 213.128.0.0 mask 255.224.0.0 %GATEWAY%
    route add 213.160.0.0 mask 255.224.0.0 %GATEWAY%
    route add 213.224.0.0 mask 255.224.0.0 %GATEWAY%


    Skrypt nie jest niestety doskonały. W moim konkretnym przypadku zablokowany został dostęp do Elektrody (212.180.179.20). Tak więc trzeba jeszcze dodać bardziej precyzjne reguły przekierowania ruchu.

    Odnowienie adresu IP z poziomu programu WINIPCFG.EXE powoduje unieważnienie zmian wprowadzonych przez skrypt, bez konieczności restartowania komputera.
  • Poziom 21  
    Usprawniłem skrypt do penego stopnia. Portal Elektrody działa z nim prawidłowo. Ciągle jednak w okolicach "wyciętych" adresów znajdują się luki. Tak więc znajdą się wykluczone strony internetowe.

    Code:
    @echo off
    
    SET GATEWAY=192.168.122.253
    route delete 0.0.0.0

    route add 0.0.0.0 mask 128.0.0.0 %GATEWAY%
    route add 128.0.0.0 mask 192.0.0.0 %GATEWAY%
    route add 192.0.0.0 mask 254.0.0.0 %GATEWAY%
    route add 194.0.0.0 mask 255.0.0.0 %GATEWAY%

    route add 195.0.0.0 mask 255.128.0.0 %GATEWAY%
    route add 195.128.0.0 mask 255.192.0.0 %GATEWAY%
    route add 195.192.0.0 mask 255.248.0.0 %GATEWAY%
    route add 195.200.0.0 mask 255.252.0.0 %GATEWAY%
    route add 195.204.0.0 mask 255.255.0.0 %GATEWAY%
    REM -www.ca.unet.pl 195.205.248.71
    route add 195.206.0.0 mask 255.254.0.0 %GATEWAY%
    route add 195.208.0.0 mask 255.240.0.0 %GATEWAY%
    route add 195.224.0.0 mask 255.224.0.0 %GATEWAY%

    route add 196.0.0.0 mask 252.0.0.0 %GATEWAY%
    route add 200.0.0.0 mask 248.0.0.0 %GATEWAY%
    route add 208.0.0.0 mask 250.0.0.0 %GATEWAY%

    route add 212.0.0.0 mask 255.128.0.0 %GATEWAY%
    route add 212.128.0.0 mask 255.224.0.0 %GATEWAY%
    REM -cc.unet.pl 212.160.73.62
    route add 212.161.0.0 mask 255.255.0.0 %GATEWAY%
    route add 212.162.0.0 mask 255.254.0.0 %GATEWAY%
    route add 212.164.0.0 mask 255.252.0.0 %GATEWAY%
    route add 212.168.0.0 mask 255.248.0.0 %GATEWAY%
    route add 212.176.0.0 mask 255.240.0.0 %GATEWAY%
    route add 212.192.0.0 mask 255.192.0.0 %GATEWAY%

    route add 213.0.0.0 mask 255.128.0.0 %GATEWAY%
    route add 213.128.0.0 mask 255.192.0.0 %GATEWAY%
    route add 213.192.0.0 mask 255.240.0.0 %GATEWAY%
    route add 213.208.0.0 mask 255.248.0.0 %GATEWAY%
    route add 213.216.0.0 mask 255.252.0.0 %GATEWAY%
    route add 213.220.0.0 mask 255.254.0.0 %GATEWAY%
    REM -213.222.192.30
    route add 213.223.0.0 mask 255.255.0.0 %GATEWAY%
    route add 213.224.0.0 mask 255.224.0.0 %GATEWAY%

    route add 214.0.0.0 mask 254.0.0.0 %GATEWAY%
    route add 216.0.0.0 mask 248.0.0.0 %GATEWAY%
    REM 224.0.0.0        224.0.0.0
    REM 255.255.255.255  255.255.255.255


    ------------------- Edycja

    Po kilku eksperymentach muszę przyznać, że metoda ta ma spory potencjał. W przeciwieńtwie do modyfikacji rejetru Płatnik nie wyświetla żadnych dodatkowych komunikatów.

    Przetestowałem to rozwiązanie tylko na jednym komputerze. Niestety i w tym przypadku system nie chce się prawidłowo zamykać.
  • Poziom 21  
    Windows odtwarza domyślne tabele rutowania przy każdym odnowieniu adresu IP za pomocą DHCP. Jeżeli, czas dzierżawy adresu IP jest krótki (rzadko spotykana sytuacja), to trudno będzie temu zaradzić. Jeżeli jednak okres ten trwa przynajmniej kilka lub kilkanaście godzin, to można pokusić się o wymuszenie odnowienia adresu IP w trakcie wykonywania skryptu. Spowoduje to przyznanie adresu IP na nowy okres, i zapobiegnie odnowieniu adresu w trakcie normalnego dnia roboczego (zakładając, że komputer jest uruchamiany z rana a skrypt jest uruchamiany w trakcie startu).

    Można to osiągnąć dodając dwie linie na początku skryptu:
    Code:
    IPConfig /release 0
    
    IPConfig /renew 0

    (Zakładając, że właściwa karta sieciowa ma numer 0. Nie zawsze jest to prawdą.)

    ------------------- Dodane

    Przetestowałem nową wesję skryptu na kolejnym komputerze. Eksperymenty potwierdziły problem z wyłączaniem komputera po wizycie na liście certyfikatów w Płatniku. O dziwo, nie ma problemów z restartem systemu.

    Tak więc zamiast wyłączać komputer ręcznie, można zrestartować system, a następnie wyłączyć komputer poprzez polecenie zamknij.
  • Poziom 21  
    Znalazłem sposób na automatyczne pobranie przez skrypt adresu bramy.

    Pierwszą część rozwiązania stanowi krótki skrypt o dowolnej nazwie:

    Code:
    IPConfig /release 0
    
    IPConfig /renew 0|find "brama">ipbramy.bat
    ipbramy


    Wykonanie go utworzy skrypt o nazwie IPBRAMY.BAT o przykladowej zawartości:
    Code:
       Domyślna brama . . . . . . : 192.168.122.253

    a następnie uruchomi go.

    Wykonanie skryptu IPBRAMY.BAT spowoduje uruchomienie skryptu DOMYŚLNA.BAT z dziewiątym parametrem wywołania równym adresowi IP bramy.

    Aby to zadziałało musimy stworzyć skrypt o nazwie DOMYŚLNA.BAT:

    Code:
    @echo off
    
    SET GATEWAY=%9
    route delete 0.0.0.0

    route add 0.0.0.0 mask 128.0.0.0 %GATEWAY%
    route add 128.0.0.0 mask 192.0.0.0 %GATEWAY%
    route add 192.0.0.0 mask 254.0.0.0 %GATEWAY%
    route add 194.0.0.0 mask 255.0.0.0 %GATEWAY%

    route add 195.0.0.0 mask 255.128.0.0 %GATEWAY%
    route add 195.128.0.0 mask 255.192.0.0 %GATEWAY%
    route add 195.192.0.0 mask 255.248.0.0 %GATEWAY%
    route add 195.200.0.0 mask 255.252.0.0 %GATEWAY%
    route add 195.204.0.0 mask 255.255.0.0 %GATEWAY%
    route add 195.205.0.0 mask 255.255.128.0 %GATEWAY%
    route add 195.205.128.0 mask 255.255.192.0 %GATEWAY%
    route add 195.205.192.0 mask 255.255.224.0 %GATEWAY%
    route add 195.205.224.0 mask 255.255.240.0 %GATEWAY%
    route add 195.205.240.0 mask 255.255.248.0 %GATEWAY%
    route add 195.205.248.0 mask 255.255.255.192 %GATEWAY%
    route add 195.205.248.64 mask 255.255.255.252 %GATEWAY%
    route add 195.205.248.68 mask 255.255.255.254 %GATEWAY%
    route add 195.205.248.70 mask 255.255.255.255 %GATEWAY%
    REM -www.ca.unet.pl 195.205.248.71
    route add 195.205.248.72 mask 255.255.255.248 %GATEWAY%
    route add 195.205.248.80 mask 255.255.255.240 %GATEWAY%
    route add 195.205.248.96 mask 255.255.255.224 %GATEWAY%
    route add 195.205.248.128 mask 255.255.255.128 %GATEWAY%
    route add 195.205.249.0 mask 255.255.255.0 %GATEWAY%
    route add 195.205.250.0 mask 255.255.254.0 %GATEWAY%
    route add 195.205.252.0 mask 255.255.252.0 %GATEWAY%
    route add 195.206.0.0 mask 255.254.0.0 %GATEWAY%
    route add 195.208.0.0 mask 255.240.0.0 %GATEWAY%
    route add 195.224.0.0 mask 255.224.0.0 %GATEWAY%

    route add 196.0.0.0 mask 252.0.0.0 %GATEWAY%
    route add 200.0.0.0 mask 248.0.0.0 %GATEWAY%
    route add 208.0.0.0 mask 250.0.0.0 %GATEWAY%

    route add 212.0.0.0 mask 255.128.0.0 %GATEWAY%
    route add 212.128.0.0 mask 255.224.0.0 %GATEWAY%
    route add 212.160.0.0 mask 255.225.192.0 %GATEWAY%
    route add 212.160.64.0 mask 255.225.248.0 %GATEWAY%
    route add 212.160.72.0 mask 255.225.255.0 %GATEWAY%
    route add 212.160.73.0 mask 255.225.255.224 %GATEWAY%
    route add 212.160.73.32 mask 255.225.255.240 %GATEWAY%
    route add 212.160.73.48 mask 255.225.255.248 %GATEWAY%
    route add 212.160.73.56 mask 255.225.255.252 %GATEWAY%
    route add 212.160.73.60 mask 255.225.255.254 %GATEWAY%
    REM -cc.unet.pl 212.160.73.62
    route add 212.160.73.63 mask 255.225.255.255 %GATEWAY%
    route add 212.160.73.64 mask 255.225.255.192 %GATEWAY%
    route add 212.160.73.128 mask 255.225.255.128 %GATEWAY%
    route add 212.160.74.0 mask 255.225.254.0 %GATEWAY%
    route add 212.160.76.0 mask 255.225.252.0 %GATEWAY%
    route add 212.160.80.0 mask 255.225.240.0 %GATEWAY%
    route add 212.160.96.0 mask 255.225.224.0 %GATEWAY%
    route add 212.160.128.0 mask 255.225.128.0 %GATEWAY%
    route add 212.161.0.0 mask 255.255.0.0 %GATEWAY%
    route add 212.162.0.0 mask 255.254.0.0 %GATEWAY%
    route add 212.164.0.0 mask 255.252.0.0 %GATEWAY%
    route add 212.168.0.0 mask 255.248.0.0 %GATEWAY%
    route add 212.176.0.0 mask 255.240.0.0 %GATEWAY%
    route add 212.192.0.0 mask 255.192.0.0 %GATEWAY%

    route add 213.0.0.0 mask 255.128.0.0 %GATEWAY%
    route add 213.128.0.0 mask 255.192.0.0 %GATEWAY%
    route add 213.192.0.0 mask 255.240.0.0 %GATEWAY%
    route add 213.208.0.0 mask 255.248.0.0 %GATEWAY%
    route add 213.216.0.0 mask 255.252.0.0 %GATEWAY%
    route add 213.220.0.0 mask 255.254.0.0 %GATEWAY%
    route add 213.222.0.0 mask 255.254.128.0 %GATEWAY%
    route add 213.222.128.0 mask 255.255.192.0 %GATEWAY%
    route add 213.222.192.0 mask 255.255.255.240 %GATEWAY%
    route add 213.222.192.16 mask 255.255.255.248 %GATEWAY%
    route add 213.222.192.24 mask 255.255.255.252 %GATEWAY%
    route add 213.222.192.28 mask 255.255.255.254 %GATEWAY%
    REM -213.222.192.30
    route add 213.222.192.31 mask 255.255.255.255 %GATEWAY%
    route add 213.222.192.32 mask 255.255.255.224 %GATEWAY%
    route add 213.222.192.64 mask 255.255.255.192 %GATEWAY%
    route add 213.222.192.128 mask 255.255.255.128 %GATEWAY%
    route add 213.222.193.0 mask 255.255.255.0 %GATEWAY%
    route add 213.222.194.0 mask 255.255.254.0 %GATEWAY%
    route add 213.222.196.0 mask 255.255.252.0 %GATEWAY%
    route add 213.222.200.0 mask 255.255.248.0 %GATEWAY%
    route add 213.222.208.0 mask 255.255.240.0 %GATEWAY%
    route add 213.222.224.0 mask 255.255.224.0 %GATEWAY%
    route add 213.223.0.0 mask 255.255.0.0 %GATEWAY%
    route add 213.224.0.0 mask 255.224.0.0 %GATEWAY%

    route add 214.0.0.0 mask 254.0.0.0 %GATEWAY%
    route add 216.0.0.0 mask 248.0.0.0 %GATEWAY%
    REM 224.0.0.0        224.0.0.0
    REM 255.255.255.255  255.255.255.255


    W powyższym skrypcie luki w przekierowaniach zostały już załatane. Tak więc zablokuje on jedynie trzy adresy IP:
    -www.ca.unet.pl 195.205.248.71
    -cc.unet.pl 212.160.73.62
    -213.222.192.30

    Rozwiązanie to jest przeznaczone do używania w sieciach lokalnych, ale po nieznacznej modyfikacj może być przydatne także w dostępie wdzwanianym.

    Testowałem rozwiązanie umieszczając skrót do pierszego skryptu w folderze Programy/Autostart
  • Poziom 35  
    Mój skrypt jak widzę załatany, gratuluje cierpliwości. Niestety jest jeszcze dłuższy od oryginału co spowoduje ze po umieszczeniu w autostarcie będzie się odpalał jeszcze wolniej. Wg mnie należało by sie zastanowić nad jakimś sposobem przyspieszenia jego działania bowiem czarne okienko przez dłuższy czas po uruchomieniu komputera jest denerwujące (zminimalizowany odpala się jeszcze wolniej).
  • Poziom 21  
    Podejmę więc polemikę argumentując, że oczekiwanie na Płatnika sprawdzającego certyfikaty jest jeszcze bardziej denerwujące, niż czekanie na wykonanie skryptu.

    Właściwie to nie jest konieczne umieszczanie skryptu w Autostarcie. W zależności od sposobu wykorzystania komputera dobrym rozwiązaniem może być uruchomienie skryptu wraz z Płatnikiem.

    Wracając do połączeń Dial-Up. Możliwe jest "ręczne" uruchomienie po nawiązaniu połączenia. Chwilowo nie mam pomysłu na automatyzację w tym konkretnym przypadku.
  • Poziom 21  
    Skrypt wydaje się funkcjonować prawidłowo. Ciągle jednak posiada pewne mankamenty. Jednym z nich jest zależność mechanizmu pozyskiwania adresu IP bramy od numeru karty sieciowej. W przypadku systemu, gdzie zainstalowane są karta sieciowa i Dial-up networking, automatyczne wprowadzenie adresu IP do zmiennej %GATEWAY% może nie być możliwe. Spowodowane jest to zjawiskiem braku kontynuacji wykonywania skryptu jeżeli wywołamy inny skrypt bez polecenia CALL.

    Drugin składnikiem problemu jest samo polecenie IPCONFIG. Zawsze wyświetla ono ustawienia wszystkich urządzeń sieciowych. Tak więc urządzenie z numerem 0 zawsze jest pierwsze. W przypadku kiedy Dial-up networking nosi numer 0 a karta sieciowa 1 plik IPBRAMY.BAT będzie zawierał:
    Code:
       Domyślna brama . . . . . . :
    
       Domyślna brama . . . . . . : 192.168.122.253


    Parametr zostanie pobrany tylko z pierwszej linii. Druga jest zawsze ignorowana. Chwilowo nie mam dobrego pomysłu na rozwiązanie tego problemu. Tak więc zmuszony byłem usuwać Dial-up networking z komputerów, w których rozwiązanie to jest stosowane.

    Oczywiście można ustawić adres bramy na sztywno. Ale jest to, w pewnym sensie, krok wstecz w rozwoju całego pomysłu.
  • Poziom 21  
    Zaobserwowałem sporadyczne blokowanie się Płatnika w trakcie wysyłania lub odbierania danych za pomocą SDWI. Efekt występuje na trzech różnych komputerach z wprowadzoną poprawką w rejestrze systemowym, oraz łączących się z Internetem za pomocą Dial-up.

    Prawdopodobnie w momencie wystąpienia błędu podczas trasmisji Płatnik blokuje się zamiast wyświetlić komunikat o odpowiednim błędzie.

    Wszystko wskazuje na to, że problem nie występuje podczas komunikacji za pomocą EWD.
  • Poziom 10  
    A próbowaliście nie instalować certyfikatów w magazynie Windows?

    Miałem taki przypadek u kuzynki w pracy. Zaktualizowałem wersję 6.x na 7.02 na szybko, bez wchodzenia do przekazu elektronicznego, więc nie dostałem pytania "czy zainstalować w magzynie głównym certyfikatów..." czy jakoś tak. Pomyślałem, że jak pierwszy raz wejdzie w przekaz, to sama sobie kliknie "tak" i zainstaluje te certyfikaty.

    Ale jak ostatnio u niej byłem okazało się, że za każdym razem anuluje to pytanie i wchodzi dalej. Nie sprawdzałem tego dokładnie, ale to było miesiąc temu, więc na pewno jakieś dokumenty w tym czasie wysyłała.

    Niestety kiedy ja zobaczyłem to pytanie o instalację certyfikatu na ekranie, to uznałem, że trzeba to naprawić. Kliknąłem "tak" no i zaczęło się... Teraz nie mam czystej instalacji, żeby to sprawdzić.
  • Poziom 21  
    Problem w tym, że pewne certyfikaty w magazynie Windows są potrzebne.

    Nie znam budowy Płatnika wystarczająco dobrze, żeby mieć absolutną pewność, że Płatnik wymaga stosownych certyfikatów w magazynie systemowym do prawidłowego działania wysyłki automatycznej.

    ----------------------------------------

    Faktycznie, brak certyfikatów Unizeto w magazynie systemowym eliminuje efekt "blokady". Kiedy Płatnik usiłuje zainstalować certyfikat można odmówić jego instalacji, i procedura sprawdzania zostaje zakończona. Pozostaje problem stwierdzenia, czy można w tej sytuacji wysyłać dokumenty.

    Magazyn systemowy można ręcznie "wyczyścić" z certyfikatów Unizeto. W Narzędzia - Opcje internetowe - Zawartość - Cetryfikaty można usunąć certyfikaty Unizeto w zakładkach Intermediate Certification Authorities oraz Trusted Root Certification Authorities.

    Dodano po 1 [godziny] 16 [minuty]:

    Dokonałem kolejnego eksperymentu.

    Pozwoliłem Płatnikowi wpisać wszystkie certyfikaty do magazynu systemowego. Następnie usunąłem najstarszy z certyfikatów (w moim przypadku był to certyfikat ważny od 2002 do 2004). Płatnik instaluje certyfikaty zaczynając od najstarszego, więc mogę teraz przerwać procedurę ich instalacji na najstarszym certyfikacie, podczas gdy nowsze są już zainstalowane. W teorii powinno to pozwolić na prawidłowe działanie Płatnika.

    Nie mam jednak możliwości, aby szybko sprawdzić skuteczność tego sposobu.
  • Poziom 10  
    Czy z twoich eksperymentów wynika, że wystarczy usunąć ten stary unizeto, żeby znikło blokowanie?
  • Poziom 21  
    Tak, zgadza się.

    Trzeba tylko nie pozwalać na ponowne zainstalowanie tego certyfikatu po każdym uruchomieniu Płatnika.

    Co ciekawe, i w tym przypadku system nie chce się poprawnie wyłączać jeżeli procedura kontroli certyfikatów została przerwana.