Drukuj

Zaloguj się lub zarejestruj.
1 Godzina 1 Dzień 1 Tydzień 1 Miesiąc Zawsze
Zaloguj się podając nazwę użytkownika, hasło i długość sesji

[SP9UOB]

Hej,

Chodzi mi po głowie pewien szalony pomysł, na razie rozważam teoretyczne możliwości ;-)
idealnie było by gdyby moje dane przechodziły przez sieć RF jak i APRS-IS w czystej postaci 8-mio bitowej.
Mam jednak pewne obawy (w APRS IS chyba CRLF jest używane do oznaczenia końca ramki) - co troszkę mi skomplikuje zadanie (dodatkowe kodowanie).

Więc jak to jest - czy w polu danych APRS bezpiecznie jest przesyłać 8-bitowe dane? W specyfikacji nie doszukałem się jednoznacznej odpowiedzi.

[SP6VWX]

Tomek,


Jeżeli pytasz czy dowolne 8 bitów jest dozwolone w polu informacji/danych, to chyba zależy to jedynie od oprogramowania którę ramkę obrabia. Jeżeli pola adresowe, ścieżka, suma kontrolna, itp. są OK to chyba ramka powinna być powtórzona przez digi i IGate'a. Co najwyżej zgłupieją Kenwóody w całej okolicy

P.S.
Edytowałem, bo jak zwykle nie doczytałem pytania

[SP9UOB]

to że ramka HDLC jest 8-bit safe to wiem, jednak mam wątpliwości co do tego jak jest traktowana później np w APRS-IS.

Muszę napisać kawałek softu i to sprawdzić :-)

[SP6VWX]

No własnie nie doczytałem. Sądząc po tym, że serwisy typu aprs.fi ramki obrabiają, jest szansa, że nieprawidłowe ramki są eliminowane. Trzeba by podglądać cały ruch na serwerze, na "żywca" np. logując się do niego telnetem podczas wysyłania tych "fake" ramek.

[SP3LYR]

Obróbka, czy eliminowanie błędnych ramek dotyczy ich struktury, a więc poprawności co do protokołu. Natomiast nie co do zawartości danych w polu informacji. Wyjątkiem tu mogą być filtry dla sytuacji mało realnych, jak np. prędkość większa niż 500km/h.
Natomiast to, co zamieścimy w komentarzu nie jest filtrowane.

Nota bene, trzy lata temu została dodana propozycja, aby specyfikacja APRS pozwalała na posługiwanie się alfabetami narodowymi, jak np. nasze ąćęłóśżź. Początkowo w specyfikacji APRS były przewidziane tylko znaki 7 bit ASCII, ale wprowadzenie UTF-8 pozwoli na kompatybilność ze starym standardem i jednocześnie posługiwanie się alfabetami narodowymi. Więcej http://aprs.org/aprs12/utf-8.txt
Program APRSIS32 pozwala już na takie operacje, tzn. pisanie msg z ąę..., wstawianie ich do komentarza i do statusów. Ale oczywiście obydwu korespondentów musi mieć kompatybilne oprogramowanie.

[SP9UOB]

Kurde, jest gorzej niż myślałem, każdy interpretuje jak chce:

tak wygenerowałem dane do pakietu:


        for (i=0;i<128;i++) {
                *tmpwsk++=i;
        };

        pktlen+=128;



to strumień z radomskiego serwera aprs:

SP9UOB-2>TEST,WIDE1-1,qAR,SQ9KS-2:

SP9UOB-2>TEST,WIDE1-1,qAR,SR9NON:                                 !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~
SP9UOB-2>TEST,WIDE1-1,qAR,SQ9LBC:[ binary data ]
SP9UOB-2>TEST,SR6NWS*,qAS,SQ6XL:



i tak:
SQ9KS-2 wywalił treść
SR9NON niedrukowalne zamienił spacjami
a SQ9LBC wpisał [binary data]

MASAKRA ;-)

[SP3LYR]

Czyli problem pojawia się na IGatach, a konkretnie każde oprogramowanie inaczej się obchodzi z informacją. A to, co z tym zrobią serwery to jest kolejny znak zapytania. Zapewne poszczególne kopie tej samej ramki wpuszczone w odmiennej formie przez IGaty będą klasyfikowane jako różne ramki.

[SP9UOB]

Widzę, żeby mój wynalazek był kompatybilny muszę ograniczyć się do zakresu 0x1f-0x7f co oznacza kolejne kodowanie i przyrost ilości danych :-(

[SP3VSS]

a może wysyłaj wiadomości ?

[SP9UOB]

a może wysyłaj wiadomości ?

Wiadomości to "warstwa aplikacji" przyrównując APRS do modelu ISO/OSI.
Więc jeśli warstwa transportowa nie przenosi czysto - to warstwa wyżej również nie da rady :-(

Ale mam już przetestowane base91. Może niedługo się czymś pochwale :-)