Dokument ten był początkowo załącznikiem do HAM-HOWTO ale urósł za bardzo, aby można go było w ten sposób nadal pisać. Dokument ten opisuje w jaki sposób zainstalować i skonfigurować rodzimą obsługę protokołów AX25, NetRom oraz Rose na Linuxie. Podano tutaj kilka typowych konfiguracji, które mogą posłużyć jako model do dalszej pracy.
Wersje protokołów radia amatorskiego pod Linuxem są bardzo elastyczne. Dla ludzi, którzy nie są zbytnio zapoznani z systemem operacyjnym Linux proces konfiguracji wydawać się może uciążliwy i skomplikowany. Zajmie ci to trochę czasu zanim zrozumiesz w jaki sposób wszystko ze sobą pasuje. Konfiguracja jest bardzo trudna jeśli wpierw nie zapoznasz się z Linuxem ogólnie. Nie oczekuj, że uda ci się przejść z jakiegoś środowiska do Linuxa bez zapoznania się uprzednio z samym Linuxem.
dołączyłem informacje o łatce dla modułów. Dodałem parę ogólnych informacji o strukturze jądra.
Poprawiłem konfiguracje ax25d - podziękowania dla John Tanner, VK2ZXQ. Poprzestawiałem mnóstwo rzeczy, powinno teraz być bardziej logicznie.
Poprawić sekcję o SCC, obecna jest chyba zła. Rozwinąć sekcję programowania. Dodać odnośniki do dokumentacji źródeł AX25 i NetRom.
Jest wiele związanych z tym tematem dokumentów. Jest sporo dokumentów traktujących o sprawach sieciowych pod Linuxem w sposób bardziej ogólny, które bardzo polecam ponieważ pomogą ci one w twoich wysiłkach i dadzą ci głebszy wgląd w inne możliwe konfiguracje.
Oto one:
Najlepszym miejscem do znalezienia ostatniej wersji tego dokumentu jest Archiwum Linux Documentation Project. Linux Documentation Project prowadzi Web Server i dokument niniejszy pojawia się tam jako The AX25-HOWTO. Możesz też skontaktować się ze mną ale zwykle przekazuję ostatnie wersje tego dokumentu koordynatorowi projektu LDP, więc jeśli go tam nie ma to są duże szanse, że jeszcze go nie skończyłem.
Protokół AX.25 oferuje dwa tryby operacji: connected i connectionless. Używany jest albo do połączeń typu stacja-do-stacji albo jako medium dla innych protokołow takich jak TCP/IP lub NetRom.
Podobny jest w swej strukturze do X.25 level 2 z pewnymi modyfikacjami, które czynią go bardziej użytecznym do pracy w środowisku radia amatorskiego.
Protokół NetRom jest próbą pełnego protokołu sieciowego i w swej najniższej warstwie używa AX.25 jako protokołu typu datalink. Dostarcza on sieciowej warstwy, która jest adaptowaną formą AX.25. Protokół NetRom cechuje się dynamicznym routingiem, posiada też funkcję pseudonimów dla węzłów.
Protokół Rose został wynaleziony i po raz pierwszy zastosowany przez Tom'a Moulton, W2VY, i jest wariacją protokołu X.25 w warstwie packet. Pomyślany jest tak, że AX.25 jest jego warstwą typu datalink. Sam również dostarcza warstwę sieciową. Adresy Rose przyjmują formę 10 cyfrowych numerków. Pierwsze cztery cyfry stanowią Data Network Identification Code (DNIC) i wzięte zostały z załącznika B z zaleceń CCITT X.121. Więcej informacji na temat protokołu Rose można uzyskać z Serwera RATS.
Początkowo, wczesne oprogramowanie AX.25 współpracujące z jądrem Linuxa wypracował Alan Cox. Następnie Jonathon Naylor przejął rozwijający się projekt dodając obługę NetRomu i Rose; obecnie on właśnie zajmuje się opracowywaniem źródeł AX.25 współpracujego z jądrem Linuxa. DAMA zostało napisane przez Joerg Reuter. Obsługę karty dźwiękowej jako modemu oraz modem Baycom dodał Thomas Sailor. Programy narzędziowe AX.25 są obecnie prowadzone przeze mnie.
Linux obsługuje TNC w trybie KISS (Terminal Node Controllers), kartę Ottawa PI, kartę Gracillis PacketTwin oraz inne oparte na scalaku SCC Z8530, modem Baycom zarówno seryjny jak i równoległy. Nowy, od Tomasza, sterownik DźwiękoModemu obsługuje karty dźwiękowe SoundBlaser oraz te zbudowane w oparciu o Crystal chipset.
Programy użytkownika zawierają prosty PMS (Personal Message System), program latarnie, liniowy program 'call' do połaczeń, 'listen' przykładowy program do uchwycenia surowych ramek AX.25 na poziomie interfejsu, oraz programy do konfiguracji NetRomu. Załączono również program, ktory jest jakby serwerem AX.25 przechwytującym i rozprowadzającym wchodzące połączenia; jest też demonik dla NetRomu, który wykonuje całą czarną robotę dla obsługi protokołu NetRom.
AX.25 pod Linuxem jest zupełnie nową implementacją. Choć na pozór wygląda podobnie do NOS, BPQ lub innych implementacji AX.25 to jednak nie przypomina żadnej z nich ani nie jest identyczną z żadną z nich. AX.25 pod Linuxem można skonfigurować tak, że będzie zachowywać się niemalże tak jak inne implementacje AX.25 ale proces konfiguracyjny jest bardzo odmienny.
Aby dopomóc ci w sposobie myślenia przy konfigurowaniu, sekcja ta stara się wyjaśnić niektóre strukturalne cechy AX.25 oraz umieszcza je w ogólnej strukturze Linuxa.
Uproszczony schemat warstw protokołów sieciowych.
-----------------------------------------------
| AF_AX25 | AF_NETROM | AF_INET | AF_ROSE |
|=========|===========|=============|=========|
| | | | |
| | | TCP/IP | |
| | ---------- | |
| | NetRom | | Rose |
| -------------------------------------
| AX.25 |
-----------------------------------------------
Schemat ten ilustruje poprostu, że NetRom, TCP/IP i Rose wszystkie razem rezydują na protokole AX.25 ale że każdy z nich traktowany jest osobno u poziomu programowania na interfejsie. Nazwy 'AF' to nazwy nadawane dla Address Family każdego z tych protokołów podczas pisania dla nich programów. Ważne tutaj jest to, że konfiguracja urządzenia AX.25 kluczowo wpływa na to jak będą konfigurowane NetRom, Rose oraz TCP/IP.
Schemat modułów w implementacji sieciowej Linuxa
----------------------------------------------------------------------------
User | Programs | call node || Daemons | ax25d mheardd
| | pms mheard || | inetd netromd
----------------------------------------------------------------------------
| Sockets | open(), close(), listen(), read(), write(), connect()
| |------------------------------------------------------
| | AF_AX25 | AF_NETROM | AF_ROSE | AF_INET
|------------------------------------------------------------------
Kernel | Protocols | AX.25 | NetRom | Rose | IP/TCP/UDP
|------------------------------------------------------------------
| Devices | ax0,ax1 | nr0,nr1 | rose0,rose1 | eth0,ppp0
|------------------------------------------------------------------
| Drivers | Kiss PI2 PacketTwin SCC BPQ | slip ppp
| | Soundmodem Baycom | ethernet
----------------------------------------------------------------------------
Hardware | PI2 Card, PacketTwin Card, SCC card, Serial port, Ethernet Card
----------------------------------------------------------------------------
Ten schemat jest troszeczkę bardziej ogólny od pierwszego. Stara się on ukazać zależność pomiędzy programami narzędziowymi, jądrem oraz sprzętem. Pokazuje też zależność pomiędzy interfejsem programowania gniazd dla aplikacji, właściwymi modułami protokołów, interfejsami sieciowymi jądra, oraz sterownikami urządzeń. Każdy element schematu polega na tym elemencie, który jest poniżej niego samego i konfigurację trzeba rozpoczynać od samego dołu w górę. Więc dla przykładu, jeśli chesz odpalać program call to musisz również skonfigurować sprzęt, następnie upewnić się, że jądro posiada odpowiedni sterownik urządzenia, dalej musisz stworzyć właściwy interfejs sieciowy oraz, że jądro zawiera właściwy protokół, który oferuje odpowiedni dla programu call interfejs programowania. W takiej hierarchii starałem się też rozłozyć ten dokument.
Oprogramowanie AX.25 składa się z trzech części: źrodeł jądra, narzędzi do konfiguracji sieci oraz programów narzędziowych.
Wersje jądra Linuxa 2.0.xx zawierają w sobie pierwotnie sterowniki dla AX.25, NetRom, dla kart Z8530 SCC, PacketTwin i Gracillis. Zostały one znacząco udoskonalone w jądrach 2.1.xx. Niestety, pozostała część jądra 2.1.* czyni je bardzą chwiejnymi i nie nadają sie w takim stanie do załączenia w stabilnych wersjach jąder. Aby zaradzić temu problemowi, Jonathon Naylor przygotował zespół łatek, które oblugę protokołów radia amatorskiego w jądrach 2.0.xx wynoszą do poziomu standardu jąder 2.1.*. Jest to bardzą łatwe w zaaplikowaniu i wprowadza wachlarz usług, które są nieobecne w standardowych jądrach, np. obługę Rose.
Źródła jądra należy szukać w jego zwyczajnym miejscu:
ftp://ftp.funet.fi//pub/Linux/PEOPLE/Linus/v2.0/linux-2.0.29.tar.gz
Obecna kopia zespołu łatek według Jonathon'a znajduje się na:
ftp://ftp.cs.nott.ac.uk/jsn/ax25-module-12.tar.gz
Ostatnia wersja alpha standardowych narzędzi sieciowych Linuxa obsługuje AX.25 i NetRom i można ją znależć tutaj:
ftp://ftp.inka.de/pub/comp/Linux/networking/net-tools/net-tools-1.32-alpha.tar.gz
lub
ftp://ftp.linux.org.uk/pub/linux/Networking/base/net-tools-1.32-alpha.tar.gz
Ostani pakiet ipfwadm można znaleźć tu:
ftp://ftp.xos.nl/pub/linux/ipfwadm/
Istnieją dwie odmienne żyły programów narzędziowych AX.25. Jedna przeznaczona jest do pracy z jądrami 2.0.* a druga albo do jąder 2.1.* lub do kombinacji: jądro 2.0.28+łatka module10. Numer wersji pakietu ax25-utils wskazuje na najstarszą wersję jądra, z którą mogą pracować. Wybierz sobie taką wersję pakietu ax25-utils, która będzie pracować z jądrem twojego systemu.
Programy narzędziowe dla 2.1.22 i późniejszych, oraz ax25-utils+module można znaleźć na domowej stronie Jonathon'a Naylor:
ftp://ftp.cs.nott.ac.uk/jsn/ax25-utils-2.1.22b.tar.gz
lub na:
ftp://sunsite.unc.edu/pub/Linux/apps/ham/ax25/ax25-utils-2.1.22b.tar.gz
Starsze narzędzia, zdolne do pracy z niepołatanym jądrem 2.0.29 nazywają się ax25-utils-2.0.12c.tar.gz w tym samym miejscu.
Aby w sposób udany zainstalować obsługę AX.25/NetRom na systemie Linux należy skonfigurować i zainstalaować właściwe jądro a następnie programy narzędziowe AX.25.
Jeśli jesteś już zaznajomiony z kompilowaniem jądra na Linuxie to możesz pominąć tę sekcję, upewnij się tylko, że wybrałeś właściwe opcje dla jądra. Jeśli nie, to czytaj dalej.
Normalnie, źródła jądra należy rozpakowywać będąc w katalogu /usr/src do podkatalogu zwanego linux. Aby to uczynić należy się zalogować jako root a następnie wykonać takie czynności:
# cd /usr/src
# mv linux linux.old
# tar xvfz linux-2.0.29.tar.gz
# tar xvfz ax25-module-12.tar.gz
# patch -p0 < /usr/src/ax25-module-12/ax25-2.0.29-2.1.22.diff
# cd linux
Po tym jak rozpakowałeś i połatałeś jądro, musisz odpalić skrypt konfiguracyjny i zaznaczyć opcje, które odpowiadają układowi twojego sprzętu oraz te, które chcesz, aby były obecne w jądrze. Wystarczy napisać:
# make config
Jeśli wolisz metodę opartą o menu to można też spróbować:
# make menuconfig
Opiszę tutaj metodę zasadniczą, a ty wybierz taką jaka ci najbardziej odpowiada. W obu przypadkach zostaniesz postawiony wobec pytań, na które trzeba odpowiedzieć "tak" lub "nie". (Zauważ, że można też odpowiedzieć naciśnięciem "M" jeśli używaż modułów w Linuxie. Dla uproszczenia jednak przyjmuję, że ich nie używasz, więc dokonaj właściwych poprawek jeśli jest przeciwnie.)
Najbardziej zasadniczymi opcjami dla skonfigurowania AX.25 są:
Code maturity level options --->
...
[*] Prompt for development and/or incomplete code/drivers
...
General setup --->
...
[*] Networking support
...
Networking options --->
...
[*] TCP/IP networking
[?] IP: forwarding/gatewaying
...
[?] IP: tunneling
...
[?] IP: Allow large windows (not recommended if <16Mb of memory)
...
[*] Amateur Radio AX.25 Level 2
[?] Amateur Radio NET/ROM
[?] Amateur Radio X.25 PLP (Rose)
...
Network device support --->
[*] Network device support
...
[*] Radio network interfaces
[?] BAYCOM ser12 and par96 driver for AX.25
[?] Soundcard modem driver for AX.25
[?] Soundmodem support for Soundblaster and compatible cards
[?] Soundmodem support for WSS and Crystal cards
[?] Soundmodem support for 1200 baud AFSK modulation
[?] Soundmodem support for 4800 baud HAPN-1 modulation
[?] Soundmodem support for 9600 baud FSK G3RUH modulation
[?] Serial port KISS driver for AX.25
[?] BPQ Ethernet driver for AX.25
[?] Gracilis PackeTwin support for AX.25
[?] Ottawa PI and PI/2 support for AX.25
[?] Z8530 SCC KISS emulation driver for AX.25
...
Opcje, które oznakowałem jako '*' to te, na które musisz odpowiedzieć 'Y' - tak. Reszta jest zależna od sprzętu, jaki posiadasz oraz od opcji, które sobie życzysz. Niektóre z tych opcji są opisane trochę poźniej, więc jeśli nie wiesz jeszcze czego chcesz to czytaj dalej a potem tutaj wróć.
Po skończeniu konfiguracji jądra powinieneś teraz gładko skompilować jądro:
# make dep
# make clean
# make zImage
Upewnij się, aby skopiować plik arch/i386/boot/zImage tam gdzie być powinien oraz zrób edycje /etc/lilo oraz restartuj lilo, abyś faktycznie odpalił system z nowego jądra.
Jądra 2.1.* zawierają udoskonalone wersję niemalże wszyskich protokołów oraz sterowników. Najbardziej znaczące nowinki to:
modularyzacja
protokoły i sterowniki zostały zmodularyzowane tak, że można nimi do woli żąglować poleceniami insmod, rmmod. Redukuje to wymogi pamięciowe dla jądra przy sporadycznie używanych modułach oraz sprawia, że polowanie na pluskwy i pielęgancja są łatwiejsze.
wszystkie sterowniki są teraz sterownikami sieciowymi
wszelkie urządzenia jak Baycom, SCC, PacketTwin, Gracillis itp. oferują teraz normalny interfejs sieciowy, tzn. wyglądają teraz tak jak sterownik Ethernetu; nie wyglądają już tak jak TNC w trybie KISS. Na życzenie, można zbudować interfejs kiss do tych urządzeń przy pomocy programiku 'net2kiss'.
usunięto pluskwy
wiele pluskw zostało wykrytych i zniszczonych dodano też do sterowników i protokołów sporo nowych cech i funkcji.
Teraz, po wykompilowaniu jądra, powinieneś również skompilować nowe narzędzia do konfiguracji sieci. Przy ich pomocy będziesz mógł manipulować interfejsami sieciowymi oraz dodawać routing do tablic routingowych.
Nowa wersja alpha standardowego pakietu net-tools zawiera obsługę AX.25 i NetRom. Sprawdzałem to i wydaje się, że u mnie działa to świetnie.
Nie zapomnij przeczytać pliku Readme i zastosować się to wszelkich tam podanych wskazówek. Czynności jakie ja wykonałem, by skompilować net-tools to:
# cd /usr/src
# tar xvfz net-tools-1.32-alpha.tar.gz
# cd net-tools-1.32-alpha
# make config
W tym stadium zaoferowane ci zostaną pytania podobnie jak przy kompilacji jądra. Upewnij się, aby zaznaczyć obsługę jakichkolwiek protoków, które zamierzasz używać.W razie, gdybyś nie wiedział co odpowiedzieć, zaznacz "Y".
Net-tools powinny skompilować się gładko ze źródłami jądra bez żadnych ostrzeżeń. gdy kompilacja ustanie, wówczas wydaj polecenie:
# make installto zainstaluje programy w ich właściwe miejsca.
Jeśli planujesz używać usługę IP firewall to potrzebujesz ostatnich narzędzi ipfwadm do administracji ściany ogniowej. Narzędzie to podmienia starsze ipfw, które nie pracuje już z nowszymi jądrami.
Programik ipfwadm skompilowałem w taki sposób:
# cd /usr/src
# tar xvfz ipfwadm-2.0beta2.tar.gz
# cd ipfwadm-2.0beta2
# make install
# cp ipfwadm.8 /usr/man/man8
# cp ipfw.4 /usr/man/man4
Po skompilowaniu i restarcie nowego jądra, potrzebujesz jeszcze skompilować programy narzędziowe. Aby skompilować programy narzędziowe należy wykonać takie czynności:
# cd /usr/src
# tax xvfz ax25-utils-2.1.22b.tar.gz
# cd ax25-utils-2.1.22b
# make config
# make
# make install
Pliki zostaną zainstalowane pierwotnie do katalogu /usr w podkatalogi takie jak:
bin, sbin, etc and man.
Jeśli pokażą ci się ostrzeżenia podobnej treści:
gcc -Wall -Wstrict-prototypes -O2 -I../lib -c call.c call.c: In function `statline': call.c:268: warning: implicit declaration of function `attron' call.c:268: `A_REVERSE' undeclared (first use this function) call.c:268: (Each undeclared identifier is reported only once call.c:268: for each function it appears in.)zatem powinieneś pozprawdzać czy masz na swoim systemie zainstalowany poprawnie pakiet
ncurses. Skrypt konfiguracyjny stara się zlokalizować pakiet ncurses na twoim systemie w znanych katalogach. Niektóre jednak instalacje źle wpisują ncurses i skryp nie potrafi ich znaleźć.
Każdy port AX.25 lub NetRom na twoim systemie musi mieć przydzielony znak i przypięty do niego numeryczny identyfikator stacji. Rzeczy te konfigurujemy w plikach, które zostały opisane dalej. Niektóre implementacje AX.25, np. BPQ lub NOS, pozwalają na przypisanie tego samego znaku/indentyfikatora na obu portach AX.25 i NetRom. Linux na to nie pozwala z pewnych technicznych, skomplikowanych powodów. W praktyce, nie jest to taki wielki problem.
Oznacza to, że przy konfigurowaniu trzeba być świadomy tych rzeczy i wziąć je pod uwagę:
znakach/identyfikatorach i w dodatku można te znaki duplikować po wszelakich portach.Analogicznie, tak jak nie każdy radiooperator jest inżynierem, tak samo nie każda implementacja AX.25 jest zgodna ze standardem TNC2. Linux stosuje nomenklaturę, która różni się w pewnym względzie od tej, jakiej używałbyś,jeśli jedynym twoim doświadczeniem w packet radio byłby TNC. Podana niżej tablica powinna być pomocna w interpretacji czym są poszczególne elementy, które daje się konfigurować, zatem jeśli napotkasz je później w tym tekście pomoże ci to w ich zrozumieniu.
-------------------------------------------------------------------
Linux | TAPR TNC | Description
-------------------------------------------------------------------
T1 | FRACK | czas wyczekiwania przed retransmisją
| | niepotwierdzonej ramki
-------------------------------------------------------------------
T2 | RESPTIME | minimalny czas wyczekiwania na inną ramkę
| | przed transmisją potwierdzenia
| |
-------------------------------------------------------------------
T3 | CHECK | czas wyczekiwania pomiędzy sprawdzeniami czy
| | lącze jest nadal aktywne
-------------------------------------------------------------------
N2 | RETRY | ilość retransmisji zanim założymy, że lącze
| | padło
-------------------------------------------------------------------
Idle | | okres czasu, który łącze może stać bezczynnie
| | zanim zostanie zamknięte
-------------------------------------------------------------------
Window | MAXFRAME | maksymalna liczba niepotwierdzonych,
| | wytransmitowanych ramek
-------------------------------------------------------------------
Jądra 2.1.* oraz 2.0.29+module mają nową cechę, która pozwala na zmianę uprzednio niemożliwych do manipulacji wartości w trakcie pracy. Jeśli uważnie przyjrzysz się strukturze katalogu /proc/sys/net/ to zauważysz parę plików o sugestywnych nazwach, które wskazują na różne parametry do konfigurowania sieci. Każdy plik w katalogu /proc/sys/net/ax25 reprezentuje jeden ustawiony port AX.25. Nazwa pliku odnosi się do nazwy portu. Struktura plików wygląda następująco:
No. Nazwa Znaczenie Wartość domyślna 1 IP Default Mode 0=DG 1=VC 0 2 AX.25 Default Mode 0=Normal 1=Extended 0 3 Allow Vanilla Connects 0=No 1=Yes 1 4 Backoff 0=Linear 1=Exponential 1 5 Connected Mode 0=No 1=Yes 1 6 Standard Window 1 <= N <= 7 2 7 Extended Window 1 <= N <= 63 32 8 T1 Timeout 1s <= N <= 30s 10s 9 T2 Timeout 1s <= N <= 20s 3s 10 T3 Timeout 0s <= N <= 3600s 300s 11 Idle Timeout 0m <= N 20m 12 N2 1 <= N <= 31 10 13 AX.25 Frame Length 1 <= N <= 512 256 14 Max Queue 1 <= N <= 20 2 15 Digipeater Mode 0=None 1=Inband 2=XBand 3=Both 3
W powyższej tablicy T1, T2, T3 zostały podane w sekundach a Idle Timout podano w minutach. Zauważ jednak, że wartości używane przez interfejs sysctl mierzone są wartościami wewnętrznymi, gdzie czas w sekundach mnożony jest przez 10, co pozwala na rozdrobnienie na 1/10 sekundy. Tam, gdzie liczniki pozwalają na wartość zero, np. T3 lub Idle, zero oznacza, że licznik jest wyłączony.
Każdy program AX.25 wpierw czyta plik konfiguracyjny, aby uzyskać potrzebne parametry poszczególnego portu AX.25, obecnego na twoim systemie Linux. Dla portów AX.25 jest to plik /etc/ax25/axports. Każdy port AX.25, który chcesz mieć na swoim systemie, musi być w tym pliku opisany.
Plik /etc/ax25/axports to prosty tekstowy plik, który tworzymy zwykłym edytorem. Format pliku /etc/ax25/axports jest następujący:
portname callsign baudrate paclen window description
portname
to wolna nazwa, krórą należy ochrzcić port, używana do nazewnictwa tego portu
callsign
znak/identyfikator, który przypisujesz dla portu AX.25
paclen
to maksymalna długość pakietów, które będą możliwe na tym porcie przy transmisjch AX.25 w trybie 'connected'.
window
to parametr (K) AX.25 window. To samo co MAXFRAME w wielu urządzeniach TNC.
description
to dowolny opis tego portu
W moim przypadku wygląda to tak:
radio VK2KTJ-15 4800 256 2 4800bps 144.800 MHz
ether VK2KTJ-14 10000000 256 2 BPQ/ethernet device
Pamiętaj, że należy przypisać unikalny znak/identyfikator dla każdego portu AX.25, który utworzysz. Wprowadź jeden wpis dla każdego urządzenia AX.25, które chcesz używać. Odnosi się to do portów: KISS, Baycom, SCC, PI, PT, DźwiękoModem. W tym miejscu każdy wpis ma odnosić się do każdego z osobna urządzenia AX.25. Wpisy w tym pliku powiązane są z interfejsami sieciowymi poprzez ich znak/identyfikator.
Plik ten używany będzie przez programy opisane dalej.
Interfejs sieciowy jest tym, co widać na ekranie po wydaniu polecenia 'ifconfig'. Jest to objekt, poprzez który jądro Linuxa odbiera i wysyła dane sieciowe. Prawie zawsze interfejs sieciowy związany jest z fizycznym portem, są jednak wypadki, kiedy nie jest to konieczne. Interfejs sieciowy odnosi się wówczas bezpośrednio do sterownika urządzenia fizycznego. W oprogramowaniu AX.25 pod Linuxem istnieje wiele sterowników urządzeń fizycznych. Najpopularniejszym jest zapewne sterownik KISS, lecz są też inne jak np. sterownik SCC, Baycom czy SoundModem (DźwiękoModem).
Każdy z tych sterowników, przy uruchomianiu go, spowoduje również otworzenie interfejsu sieciowego.
Najczęściej spotykaną konfiguracją bedzię chyba KISS TNC na porcie seryjnym. Należy uprzednio skonfigurować sam TNC i doczepić go do portu seryjnego. Aby wprowadzić swój TNC w tryb KISS można użyć programu terminala, jak np. minicom lub seyon. Z kolei, aby utworzyć urządzenie KISS należy użyć polecenia 'kissattach', które to polecenie w swej najprostszej formie może wyglądać tak:
# /usr/sbin/kissattach /dev/ttyS0 radio
# kissparms -p radio -t 100 -s 100 -r 25
Polecenie kissattach utworzy też sieciowy interfejs KISS. Interfejsy te noszą wtedy nazwę od 'ax[0-9]'. Przy pierwszym wydaniu polecenia 'kissattach' powstaje 'ax0', przy następnym 'ax1', itd. Każdy interfejs KISS powiązany jest ze swoim portem seryjnym.
Polecenie 'kissparms' pozwala na manipulowanie różnymi parametrami interfejsu KISS.
W podanym wyżej przykładzie dołączony zostałby sieciowy interfejs KISS do seryjnego urządzenia w Linuxie '/dev/ttyS0' i do portu oznaczonego w pliku /etc/ax25/axports jako 'radio'. Następnie konfigurowany on jest z wartościami 100 milisekund dla txdelay oraz slottime i wartością 25 dla ppersist.
Więcej informacji można znaleźć w man pages w Linuxie.
Programik 'mkiss', zawarty w programach narzędziowych ax25-utils, pozwala na wykorzystanie obydwu modemów w urądzeniach TNC o dwóch portach. Ustawienie jest dość proste. Programik ten działa tak, że biorąc pojedyncze urządzenie dołaczone do wieloportowego TNC przedstawia je tak, iż wygląda ono, jakby to były dwa urządzenia, każde z własnym TNC. Czynność tę trzeba wykonać zanim zaczniesz jakąkolwiek konfigurację AX.25. Powstałe na skutek tego interfejsy pseudo-TTY, (/dev/ttypf*), które nie są rzeczywistymi urządzeniami seryjnymi, wykorzystywane są z kolei do konfiguracji AX.25. Interfejsy Pseudo-TTY wyprowadzają swego rodzaju fajkę, poprzez którą programy umiejące nadawać do urządzeń /dev/tty mogą sie porozumiewać między sobą. Każda fajka posiada końcówkę master i slave. Końcówki master są ogólnie oznaczane jako /dev/ptyp*, końcówki slave mają emblem /dev/ttyp*. Pomiędzy master a slave istnieje intymna zależnośc, zatem /dev/ptyp0 stanowi koncówkę master dla przewodu, ktory ma /dev/ttyp0 na końcówce slave. Zanim otworzysz końcówkę slave, musisz najpierw otworzyć końcówkę master. 'mkiss' wykorzystuje ten właśnie mechanizm do rozczepienia pojedynczego urządzenia seryjnego, na osobne.
Przykład: jeśli posiadasz TNC o dwóch portach i jest ono doczepione do seryjnego urządzenia /dev/ttyS0 o prędkości 9600 bps, to polecenie:
# /usr/sbin/mkiss -s 9600 /dev/ttyS0 /dev/ptyp0 /dev/ptyp1
# /usr/sbin/kissattach /dev/ttyp0 port1
# /usr/sbin/kissattach /dev/ttyp1 port2
utworzy dwa interfejsy pseudo-tty, a każde z nich wyglądać będzie tak, jakby było pojedynczym seryjnym portem, każde z własnym TNC. Wowczas interfejsy /dev/ttyp0 i /dev/ttyp1 możesz potraktować tak jak inne konwencjonalne seryjne porty z doczepionymi do nich urządzeniami TNC. W praktyce oznacza to, ze odpaliłbyś dla obydwu polecenie 'kissattach' przy zachowaniu wpisów o portach AX.25 jako port1 i port2. Nie należy odpalać polecenia 'kissattach' dla rzeczywistego urządzenia /dev/ttyS0 ponieważ zajęte zostało ono przez program 'mkiss'.
Polecenie 'mkiss' przyjmuje szereg dodatkowych argumentów, które są do twojej dyspozycji. Oto ich streszczenie:
-c pozwala na dodanie checksum o jednym byte.
Większość implementacji KISS tego nie obsluguje, jest to
możliwe przy użyciu Rom'u G8BPG KISS.
-s <speed>
ustawia prędkość portu urządzenia seryjnego.
-h omożliwia hardware handshaking na porcie seryjnym, pierwotnie
jest wyłączone. Większść implementacji KISS tego nie obsługuje.
Niektóre jednak to mają.
-l umożliwia prowadzenie log'u do plików typu syslog.
Wbrew powszechnemu przekonaniu, że nie będzie to zbyt dobrze działać, Thomas Sailor podjął się rozbudowy obsługi modemów Baycom pod Linuxem. Jego sterowniki obsługują modemy Ser12 na port seryjny, oraz Par96 i udoskonalony PicPar na porty równoległe. Więcej informacji o samych modemach można uzyskać na Web Serverze Baycoma
Najpierw musisz sprawdzić adres wejścia/wyścia oraz adresy bazowe portu seryjnego lub równoległego, do którego masz doczepiony modem Baycom. Z tą informacją możesz dopiero konfigurować sterownik samego Baycom'a.
Programik sethdlc pozwala na użycie tych parametrów ze sterownikiem, lub, jeśli masz tylko jeden modem Baycom i używasz modułów w Linuxie to można te parametry podać ręcznie jako opcje dla programu 'insmod' ładującego moduł Baycom'a.
Dla przykladu, prosty układ. Wyłączenie sterownika urządzenia seryjnego COM1:, a następnie ustawienie tam sterownika modemu Baycom Ser12 na COM1: z użyciem detekcji typu software DCD:
# setserial /dev/ttyS0 uart none # insmod baycom mode="ser12*" iobase=0x3f8 irq=4
Albo modem Par96 na porcie równoległym LPT1: z użyciem detekcji hardware DCD:
# insmod baycom mode="par96" iobase=0x378 irq=7 options=0Nie jest to jednak najlepszy sposób. Programik
sethdlc działa dobrze zarówno z jednym jak i z wieloma urządzeniami.
Podręcznik systemowy 'man' programiku sethdlc opisuje szczegóły na ten temat, jednak kilka przykładów pozwoli zilustrować ważniejsze aspekty tejże konfiguracji. Poniższy przykład zakłada, że załadowałeś już moduł Baycom'a poleceniem:
# insmod baycomUstawienie sterownika dla interfejsu bc0 stusując równoległy modem Baycom na LPT1: detekcja typu software DCD:
# sethdlc -p -i bc0 mode par96 io 0x378 irq 7
Ustawienie sterownika dla interfejsu bc1 stosując seryjny modem Baycom na COM1::
# sethdlc -p -i bc1 mode "ser12*" io 0x3f8 irq 4
Parametry dostępu do kanałów AX.25 są analogiczne do parametrów KISS, takich jak ppersist, txdelay, slottime. Tutaj też używamy programiku sethdlc.
I znów podręcznik systemowy 'man' jest głównym źródłem informacji na temat sethdlc, ale jak zwykłe jeden czy drugi przykład nie zaszkodzi:
Ustawienie interfejsu bc0 z wartością 200ms dla TxDelay, 100ms dla Slottime, wartość 40 dla ppersist oraz half-duplex:
# sethdlc -i bc0 -a txd 20 slot 10 ppersist 40 half
Zauważ, że wartości licznika są tutaj podane w 10-tkach milisekund.
Thomas Sailor napisał nowy sterownik dla jądra Linuxa pozwalający na użycie karty dźwiękowej komputera jako modemu do packet radio. Można teraz podłączyć radio bezpośrednio do karty dźwiękowej i zabawić się w packet!! Thomas poleca przynajmniej procesor 486DX/66 ponieważ cały ciężar obliczeniowy sygnału cyfrowego spada w tym wypadku na CPU.
Obecnie sterownik emuluje takie typy modemów: 1200 bps AFSK, 4800 HAPN and 9600 FSK (G3RUH compatible). Jedyne karty, które są obługiwane tym sterownikiem to te, zgodne z SoundBlaster oraz WindowsSoundSystem. Karty dźwiękowe potrzebują dodatkowego układu wspomagającego układ PTT a informację na ten tema można zasięgnąć na domowej stronie Thomas'a Sailora, tutaj. Istnieje szereg możliwości: detekcja syganłu z karty dźwiękowej, lub przez port równoległy, seryjny, port midi. Przykłady schematów są na stronie Thomas'a.
Przy załączeniu sterownik DźwiękoModemu dołącza interfejsy sieciowe: sm0, sm1, sm2, itp.
Uwaga: Sterownik DźwiękoModemu współzawodniczy w zagarnianiu zasobów komputera ze sterownikiem karty dźwiękowej. Jeśli więc planujesz używać sterownik DźwiękoModemu to upewnij się, czy sterownik karty dźwiękowej jest wyinstalowany. Jak zwykłe możesz obydwa skompilować jako moduły i używać je wtedy, gdy jest to wygodne.
Sterownik DźwiękoModemu nie wzbudza karty dźwiękowej przy ładowniu się systemu. Pakiet ax25-utils zawiera programik 'setcrystal', który obluguje karty oparte o Crystal Chipset. jeśli posiadasz inną kartę to potrzebujesz innego oprogramowania, aby ją pobudzić. Składnia programiku jest oczywista:
setcrystal [-w wssio] [-s sbio] [-f synthio] [-i irq] [-d dma] [-c dma2]
Jeśli, zatem życzysz sobie doczepić kartę soundblaster na adresie 0x388, irq 10 i DMA 1, to dj tak:
# setcrystal -s 0x388 -i 10 -d 1
Jeśli ustawiasz kartę WinSoundSystem na adresie 0x534, irq 5, DMA 3, to daj tak:
# setcrystal -w 0x534 -i 5 -d 3
Parametr [-f synthio] służy do zdeklarowania adresu syntezatora, a [-c dma2] do podania drugiej wartości dla DMA, ktora pozwala na operację full-duplex.
Po skonfigurowaniu karty dźwiękowej musisz teraz powiedzieć strownikowi DźwiękoModemu gdzie może jej szukać oraz jakiego rodzaju modem ma emulować.
Parametry te mogą zostać zdeklarowane programikiem 'sethdlc', lub, jeśli używać będziesz tylko jednej karty można je podać ręcznie programowi 'insmod', który ładuje sterownik Dźwiękomodemu. Dla przykładu, prosta konfiguracja: jedna karta dźwiękowa SoundBlaster ustawiona według powyższego przykładu i emulująca modem 1200 pbs:
# insmod soundmodem mode="sbc:afsk1200" iobase=0x220 irq=5 dma=1
Nie jest to jednak najlepszy sposób. Programik sethdlc działa dobrze zarówno z jednym jak i z wieloma urządzeniami.
Man pages programiku sethdlc piszą w szczegółach na ten temat, jednak kilka przykładów pozwoli zilustrować ważniejsze aspekty tejże konfiguracji. Poniższy przykład zakłada, ze załadowałeś już moduł sterownika DźwiękoModemu poleceniem:
# insmod soundmodem
Ustawienie sterownika do obługi uprzednio skonfigurowanej karty WinSoundSystem, aby emulował modem G3RUH 9600 jako interfejs sieciowy sm0, na porcie równoległym z układem PTT o adresie 0x378:
# sethdlc -p -i sm0 mode wss:fsk9600 io 0x534 irq 5 dma 3 pario 0x378
# ifconfig sm0 up
Ustawienie sterownika uprzednio skonfigurowanej karty SoundBlaster, aby emulował modem HAPN 4800 bps jako interfejs sieciowy sm1 z ukladem PTT na porcie seryjnym o adresie 0x2f8:
# sethdlc -p -i sm1 mode sbc:hapn4800 io 0x388 irq 10 dma 1 serio 0x2f8
# ifconfig sm1 up
Ustawienie sterownika uprzednio skonfigurowanej karty SoundBlaster, aby emulował modem AFSK 1200 bps jako interfejs sieciowy sm1, na seryjnym porcie z układem PTT o adresie 0x2f8:
# sethdlc -p -i sm1 mode sbc:afsk1200 io 0x388 irq 10 dma 1 serio 0x2f8
# ifconfig sm1 up
Parametry dostępu do kanałów AX.25 są analogiczne do parametrów KISS, takich jak ppersist, txdelay, slottime. Tutaj też używamy programiku sethdlc.
I znów man pages są głównym źródłem informacji na temat sethdlc, ale jak zwykle jeden czy drugi przykład nie zaszkodzi:
Ustawienie interfejsu sm0 z wartością 100ms dla TxDelay, 50ms dla Slottime, wartość 128 dla ppersist oraz half-duplex:
# sethdlc -i sm0 -a txd 10 slot 5 ppersist 128 full
Zauważ, że wartości licznika są tutaj podane w 10-tkach milisekund.
Każdy modem radiowy domaga się do poprawnej pracy właściwej regulacji poziomu audio. Dotyczy to również DźwiękoModem'u. Thomas napisał programy narzędziowe, które ułatwiają to zadanie. Są to: 'smdiag' i 'smmixer'.
smdiag
dostarcza dwóch typów wyświetlacza, typu oscyloskopowego i typu "eye pattern"
smmixer
pozwała na właściwe wyregulowanie poziomu nadawania i odbioru.
To polecenie odpala programik 'smdiag' w trybie "eye" dla interfejsu sm0:
# smdiag -i sm0 -e
To polecenie odpala programik 'smmixer' dla interfejsu sm0:
# smmixer -i sm0
Sterownik DźwiękoModemu powoduje dołączenie standardowego interfejsu sieciowego, gotowego do wykorzystania przez jądro. Konfiguracja przypomina tę, jaką stosujemu przy kartach PacketTwin oraz PI.
Najpierw, interfejsowi trzeba przypisać znak/identyfikator. Używamy programu 'ifconfig'. Polecenie:
# /sbin/ifconfig sm0 hw ax25 VK2KTJ-15 upprzypisze interfejsowi sm0, należącemu do DźwiękoModemu, znak/identyfikator VK2KTJ-15 w protokole AX.25.
Następny krok to dokonanie wpisu do pliku /etc/ax25/axports podobnie jak dla innych urządzeń fizycznych. Tenże wpis w pliku ax25ports jest powiązany z interfejsem sieciowym, który powyżej skonfigurowałeś na tymże znaku/identyfikatorze. Wpis w pliku axports noszący znak/identyfikator, ktorego użyłeś przy DźwiękoModemie będzie używany jako odnośnik do tego modemu.
Tak ustawione urządzenie AX.25 możesz teraz spożytkować jak każde inne. Skonfiguruj je do pracy w TCP/IP, dodaj je do demona ax25d, użyj do NetRom lub Rose, jak tylko chcesz.
Sterownik karty PI generuje powstanie interfejsów sieciowych typu `pi[0-9][ab]. Pierwszej wykrytej karcie PI zostanie przypisany interfejs pi0, kolejnej pi1, itd. Literki 'a' i 'b' odnoszą sie do fizycznych portów znajdujących się na karcie PI. Jeśli zbudowałeś jądro z obsługą karty PI, oraz jeśli została ona poprawnie wykryta to możesz skonfigurować sobie interfejs sieciowy w taki sposób:
# /sbin/ifconfig pi0a hw ax25 VK2KTJ-15 up
Polecenie to skonfigurowałoby pierwszy port pierwszej wykrytej karty PI przypisując jej znak/identyfikator VK2KTJ-15 i uczyniłoby go aktywnym. Zauważ, że znak musi mieć swój odpowiednik w pliku /etc/ax25/axports, aby móc używać tego portu.
Sterownik do karty PI napisany został przez David'a Perry, dp@hydra.carleton.edu
Sterownik karty PacketTwin generuje powstanie interfejsów sieciowych typu `pt[0-9][ab]. Pierwszej wykrytej karcie PacketTwin zostanie przypisany interfejs pt0, kolejnej pt1, itd. Literki 'a' i 'b' odnoszą sie do fizycznych inerfejsów znajdujących się na karcie PacketTwin. Jeśli zbudowałeś jądro z obsługą karty PacketTwin, oraz jeśli została ona poprawnie wykryta to możesz skonfigurować sobie interfejs sieciowy w taki sposób:
# /sbin/ifconfig pt0a hw ax25 VK2KTJ-15 up
Polecenie to skonfigurowałoby pierwszy port pierwszej wykrytej karty PacketTwin przypisując jej znak/identyfikator VK2KTJ-15 i uczyniłoby go aktywnym. Zauważ, że znak musi mieć swój odpowiednik w pliku /etc/ax25/axports, aby móc używać tego portu.
Sterownik karty PacketTwin został napisany przez Craig Small, VK2XLZ, csmall@triode.apana.org.au.
Joerg Reuter, DL1BKE, jreuter@lykos.tng.oche.de wypracował sterownik do generycznej obsługi kart opartych o scalak Z8520 SCC. Sterownik ten daje się konfigurować do obsługi wielorakich kart oferując interfejs, który zachowuje się tak jak TNC w trybie KISS. Traktuj więc go tak, jakby to był TNC w trybie KISS.
Choć sterownik zawarty jest w standardowym żródle jądra to jednak Joerg uwalnia wciąż nowsze wersje źródłowe razem ze specjalnymi narzędziami do konfiguracji, które również potrzebujesz.
Pakiet z narzędziami do konfiguracji znajdziesz tutaj:
db0bm.automation.fh-aachen.de
/incoming/dl1bke/
lub:
insl1.etec.uni-karlsruhe.de
/pub/hamradio/linux/z8530/
lub:
ftp.ucsd.edu
/hamradio/packet/tcpip/linux
/hamradio/packet/tcpip/incoming/
Znajdziesz tam różnorakie wersje, więc wybierz te, które odpowiadają twojej wersji jądra:
z8530drv-2.4a.dl1bke.tar.gz 2.0.* z8530drv-utils-3.0.tar.gz 2.1.6 lub nowszeOto polecenia, które musiałem wykonać, aby skompilować i zainstalować ów pakiet z jądrem 2.0.25:
# cd /usr/src # gzip -dc z8530drv-2.4a.dl1bke.tar.gz | tar xvpofz - # cd z8530drv # make clean # make dep # make module # jeśli chcesz aby sterownik był modułem # make for_kernel # Jeśli chcesz, aby sterownik był wbudowany w jądro # make installPo zakończonej operacji powinieneś mieć trzy programy w katalogu /sbin: gencfg, sccinit i sccstat. To właśnie one nadają się do tego, aby skonfigurować sterownik dla twojej karty.
Zostanie rownież utworzona specjalna grupa plików w katalogu /dev/ zwanych scc0 .. scc7. Zostaną one później użyte jako urządzenia KISS i właśnie te będziesz stosował.
Jeśli zdecydujesz sie na polecenie 'make for_kernel', wówczas będziesz musiał przebudować jądro. Przy budowaniu jądra po wydaniu polecenia 'make config' zadbaj o to, abyś odpowiedział "Y" na pytanie o obsługę `Z8530 SCC kiss emulation driver for AX.25'.
Nie potrzebyjesz przebudowywać jądra jeśli wybierzesz polecenie 'make module', wówczas plik scc.o zostanie umieszczony w odpowiednim katalogu /lib/modules. Nie zapomnij o poleceniu 'insmod' przed próbą użycia i konfiguracji starownika.
Sterownik Z8530 SCC został pomyślany, tak aby dał się nagiąć do niemalże każdej karty. Lecz z elastycznością idzie w parze trud jej konfiguracji. Bardziej pouczającej lektury dostarczą pliki samego pakietu i powinieneś tam szukać informacji. A w szczególności należy zajrzeć tutaj: doc/scc_eng.doc or doc/scc_ger.doc. Zparafrazowałem poniżej parę ważniejszych detali, lecz w rezultacie pominąłem szczegóły niższego rzędu.
Program sccinit czyta najpierw plik /etc/z8530drv.conf. Plik dzieli się na dwa etapy: ustawienie parametrów dla sprzętu i dla kanału AX.25. Po tym wystarczy tylko dać polecenie:
# sccinit
pierwsza sekcja dzieli się na strofy, każda strofa reprezentuje scalak 8530. Strofy to poprostu lista 'słów' i 'argumentów'. Można w tym pliku zdeklarować do 4 scalaków SCC. Jeśli potrzebujesz więcej to da się to zrobić w pliku scc.c ustawiając żądaną wartosć w #idef MAXSCC 4.
Dozwolone 'słowa' i 'argumenty' to:
chip
słowo chip służy do oddzielania strof. jego argumentem może być wszystko. Argumenty nie są używane.
data_a
używane do zdeklarowania adresu portu "data" dla kanału 'A'. Argument w formie hexadecymalnej, tj. 0x300.
ctrl_a
używany do zdeklarowania adresu portu "control" dla kanału 'A'. Argument w formie hexadecymalnej, tj. 0x304
data_b
używany do zdeklarowania adresu portu "data" dla kanału 'B'. Argument w formie hexadecymalnej, tj. 0x301.
ctrl_b
używany do zdeklarowania adresu portu "control" dla kanału 'B'. Argument w formie hexadecymalnej, tj. 0x305
irq
używany do zdeklarowania IRQ używanego przez 8530 SCC w beżącej strofie. Argument w formie liczby całkowitej, tj. 5
pclock
używany do zdeklarowania częstotliwości zegara na igle PCLK w 8530.. Argument w formie liczby całkowitej w Hz. Wartość domyślna wynosi 4915200.
board
typ płyty. Argumentem jest napis. A oto dozwolone wartości:
PA0HZP
karta PA0HZP SCC
EAGLE
karta Eagle
PC100
karta DRSI PC100 SCC
PRIMUS
karta PRIMUS-PC (DG9BL)
BAYCOM
karta BayCom (U)SCC
escc
jest nie dobowiązkowe i dołącza obsługę polepszonych scalaków, takich jak:8580, 85180, lub 85280. Argumentem jest tylko 'yes' lub 'no'.
vector
dla kart PA0HZP jest to wartość tzw. "intack port". Może być tylko jeden dla wszystkich scalaków. Wartość domyślna = 0. Nieobowiązkowy.
special
określa rejestry funkcyjne na niektórych kartach. Nieobowiązkowy. Wartość domyślna = 0.
option
jest nieobowiązkowy i przyjmuje warość domyślną 0.
Oto przykładowe konfiguracje dla najbardziej popularnych kart:
BayCom USCC
chip 1
data_a 0x300
ctrl_a 0x304
data_b 0x301
ctrl_b 0x305
irq 5
board BAYCOM
#
# SCC chip 2
#
chip 2
data_a 0x302
ctrl_a 0x306
data_b 0x303
ctrl_b 0x307
board BAYCOM
PA0HZP SCC
chip 1
data_a 0x153
data_b 0x151
ctrl_a 0x152
ctrl_b 0x150
irq 9
pclock 4915200
board PA0HZP
vector 0x168
escc no
#
#
#
chip 2
data_a 0x157
data_b 0x155
ctrl_a 0x156
ctrl_b 0x154
irq 9
pclock 4915200
board PA0HZP
vector 0x168
escc no
DRSI SCC
chip 1
data_a 0x303
data_b 0x301
ctrl_a 0x302
ctrl_b 0x300
irq 7
pclock 4915200
board DRSI
escc no
Jeśli twoja karta pracuje pod NOS'em i masz do niej konfigurację, to możesz użyć polecenia 'gencfg' do konwersji poleceń sterownika PE1CHL NOS. Powstaje wtedy plik przydatny do załączenia w pliku konfiguracyjnym dla sterownika z8530.
Polecenia 'gencfg' odpala się z tymi samymi paramatrami co sterownik PE1CHL pod NET/NOS, np.:
# gencfg 2 0x150 4 2 0 1 0x168 9 4915200
Powyższe wygeneruje szkic konfiguracyjny dla karty OptoSCC.
Sekcja Konfiguracji Kanału zajmuje się zdeklarowniem tych wszystkich parametrów, które rządzą portem , na którym chcesz pracować. Znów mamy tutaj strofy. Każda strofa reprezentuje jeden logiczny port, zatem będziemy mieli dwie strofy ponieważ każda karta 8530 SCC może mieć dwa porty.
Poniższe 'słowa' i 'argumenty' są również zapisywane do pliku /etc/z8530drv.conf i muszą występować za sekcją o parametrach sprzętu.
Kolejność w tej sekcji jest bardzo istotna, lecz jeśli będziesz podążał za sugerowaną sekwencją to powinno działać wszystko w porządku. Dozwolone 'słowa' i 'argumenty to:
device
musi stać w pierszym wierszu deklaracji portu i określa nazwę pliku w katalogu /dev/ stanowiącego podstawę dalszej konfiguracji, tj. /dev/scc0
speed
określa prędkość interfejsu w bitach na sekundę. Argumentem jest liczba calkowita, np. 1200.
clock
określa w parametry dla zegara. Dozwolone wartości to:
dpll
normalny tryb halfduplex
external
MODEM dostarcza swój własny zegar Rx/Tx
divider
użycie devidera fullduplex, jeśli jest zainstalowany
mode
określa czy kodowanie danych ma być załaczone. Argumentami są: nrzi lub nrz
rxbuffers
określa liczbę buforów odbioru, dla których należy rezerwować pamięć. Argumentem jest liczba całkowita, np. 8.
txbuffers
określa liczbę buforów nadawania, dla których należy rezerwować pamięć. Argumentem jest liczba całkowita, np. 8.
bufsize
określa rozmiary buforów odbioru i transmisji. Argumentem jest liczba bytów i stanowi on od sumę wszystkich 'ramek', zatem trzeba więc wziąć pod uwagę również nagłówki protokołu AX.25 a nie li tylko pole danych. Słowo to jest nieobowiązkowe i przyjmuje wartość domyślną 384.
txdelay
to wartość opóżnienia transmisji dla KISS, argumentem jest liczba całkowita.
persist
to wartość parametru persist dla KISS, argumentem jest liczba całkowita.
slot
to jest wartość slottime dla KISS. argumentem jest liczba całkowita w mS.
tail
to jest wartość tail dla KISS. argumentem jest liczba całkowita w mS.
fulldup
to jest oznaczenie fullduplex dla KISS, argumentem jest liczba całkowita. 1==Full Duplex, 0==HALF DUPLEX.
wait
to jest wartość wait dla KISS, argumentem jest liczba całkowita w mS.
min
to jest wartość min dla KISS, argumentem jest liczba całkowita w S.
maxkey
to jest wartość maximum keyup dla KISS, argumentem jest liczba całkowita w S.
idle
to jest wartość licznika idle dla KISS, argumentem jest liczba całkowita w S.
maxdef
to jest wartość maxdef dla KISS, argumentem jest liczba całkowita.
group
to jest wartość group dla KISS, argumentem jest liczba całkowita.
txoff
to jest wartość txoff dla KISS, argumentem jest liczba całkowita w mS.
softdcd
to jest wartość softdcd dla KISS, argumentem jest liczba całkowita.
slip
to jest oznaczenie slip dla KISS, argumentem jest liczba całkowita.
Przy używaniu sterownika traktujemy urządzenia /dev/scc* tak, jak urządzenie seryjne tty z doczepionym TNC w trybie KISS. Na przykład, aby skonfigurować jądro do obługi sieci pod Linuxem przy użyciu swojej karty należy użyć polecenia:
# kissattach -s 4800 /dev/scc0 VK2KTJ
Można też doczepić NOS'a w dokładnie taki sam sposób. Z JNOS'a, np. wykonać mógłbyś polecenie:
attach asy scc0 0 ax25 scc0 256 256 4800
Pomocnym przy diagnostyce urządzenia SCC jest program 'sccstat'. Wyświetla on bieżącą konfigurację. Spróbuj go tak uruchomić:
# sccstat /dev/scc0
wyświetli to szeroką gamę informacji związanych z ustawieniem i ogólną kondycją portu /dev/scc0 SCC.
Polecenie 'sccparam' pozwala na zmianę i modyfikowanie parametrów podczas pracy. Składnia przypomina polecenie 'param' z NOS'a, zatem aby ustawić txtail urządzenia na 100mS, należałoby napisać:
# sccparam /dev/scc0 txtail 0x8d
Linux jest kompatybilny z BPQ Ethernet. Umożliwia to na przepust protokołu AX.25 po Lokalnej Sieci ethernetowej i doczepienie swojej maszyny do innej obsługującej BPQ na Lokalnej Sieci.
Interfejsy sieciowe typu BPQ noszą nazwę 'bpq[0-9]'. Interfejs 'bpq0' powiązane jest z interfejsem 'eth0', a 'bpq1' z interfejsem 'eth1', itd.
Konfiguracja jest trywialna. Najpierw trzeba ustawić standardowe urządzenie Ethernet. To oznacza, że po wkompilowaniu obsługi karty Ethernet do jądra należy zobaczyć czy pracuje poprawnie. Zajrzyj do Ethernet-HOWTO jak tego dokonać.
Aby ustawić obsługę BPQ potrzebujesz przypisać interfejsowi Ethernet znak/identyfikator AX.25. Oto polecenie, które to spowoduje:
# /sbin/ifconfig bpq0 hw ax25 vk2ktj-14 up
I znów, nie zapomnij, że znak/identyfikator, który tutaj podajesz musi zgadzać się z wpisem w pliku /etc/ax25/axports dla portu, którego chcesz używać.
W normalnych warunkach BPQ Ethernet stosuje adres multicast. Pod Linuxem tak nie jest, zamiast tego stosowany jest zwyczajny Ethernetowy adres broadcast. Należy zatem zmodyfikować plik NET.CFG dla sterownika BPQ ODI w nasępujący sposób:
LINK SUPPORT
MAX STACKS 1
MAX BOARDS 1
LINK DRIVER E2000 ; lub inne MLID według własnej karty
INT 10 ;
PORT 300 ; według własnej karty
FRAME ETHERNET_II
PROTOCOL BPQ 8FF ETHERNET_II ; wymagane dla BPQ - zmienić PID
BPQPARAMS ; nieobowiązkowe - tylko wtedy,
; gdy znieniasz docelowy adres
ETH_ADDR FF:FF:FF:FF:FF:FF ; docelowy adres
Pakiet ax25-utils zawiera w sobie program narzędziowy 'axctl', który pozwala na ustawienie różnorodnych parametrów interfejsu AX.25.
Polecenie to jest zupełnie proste w użyciu a podręcznik systemowy 'man' dostarcza kompletnego opisu, przykładowym jednak sposobem użycia tego programu może być:
# /usr/sbin/axctl radio -window 2 -t1 5 -n2 10
Powyższe polecenie ustawiłoby wartości takie jak Window, T1 oraz N2 dla portu AX.25 nazwanego tu 'radio'.
Jeśli jest potrzeba można ustawić domyślne ścieżki do digipeaterów dla konkretnych węzłow. Przydaje się to przy zarówno czystych łączach AX.25 jak i opartych o IP. Robimy to poleceniem 'axparms'. Znowu, podręcznik systemowy 'man' podaje wszystkie szczegóły, lecz prosty przykład może być taki:
# /usr/sbin/axparms -route add radio VK2XLZ VK2SUT
Polecenie to utworzyłoby ścieżkę digipeatera dla stacji VK2XLZ przez stację VK2SUT na porcie AX.25 noszącego nazwę 'radio'.
Ustawienie portu AX.25 do pracy w TCP/IP jest bardzo proste. Jeśli posiadasz interfejs KISS to masz dwie metody do ustawienia adresu IP. Polecenie 'kissattach' posiada opcję, która pozwala na określenie adresu IP. Metoda konwencjonalna przy użyciu polecenia 'ifconifg' zadziała na wszystkich typach interfejsów.
A zatem, zmieniając poprzedni przykład dla KISS:
# /usr/sbin/kissattach -i 44.136.8.5 -m 512 /dev/ttyS0 radio
# /sbin/route add -net 44.136.8.0 netmask 255.255.255.0 ax0
# /sbin/route add default ax0
utworzy to interfejs AX.25 z adresem IP 44.136.8.5 oraz MTU 512 bytów. Jeśli zachodzi potrzeba to należy inne parametry ustawić tez poleceniem 'ifconfig' raz jeszcze.
Jeśli posiadasz jakikolwiek inny typ interfejsu to stosujesz polecenie 'ifconfig' do ustawienia adresu ip i netmask dla danego portu i dodajesz routing przez ów port, tak jak zrobiłbyś to dla każdego jednego interfejsu TCP/IP. Poniższy przykład jest dla interfejsu Karty PI, ale zadziała równie dobrze dla każdego interfejsu sieciowego AX.25:
# /sbin/ifconfig pi0a 44.136.8.5 netmask 255.255.255.0 up
# /sbin/ifconfig pi0a broadcast 44.136.8.255 mtu 512
# /sbin/route add -net 44.136.8.0 netmask 255.255.255.0 pi0a
# /sbin/route add default pi0a
Polecenia powyższe powinny być znane dla tych, którzy używali NOS lub jego pochodne lub jakiekolwiek inne oprogramowanie TCP/IP. Zauważ, że jeśli masz już ustawione jakiś interfejs sieciowy to routing domyślny nie jest ci potrzebny.
Aby to wypróbować zpróbuj 'zapingować' lub zrób telnet do lokalnego węzła:
# ping -i 5 44.136.8.58Zauważ zastosowanie '-i 5', które sprawia, że pingowanie odbywa się co 5 sekund, a nie jak pierwotnie co 1 sekundę.
Protokół Netrom wykorzystuje i zależy od portów AX.25, które utworzyłeś uprzednio. Protokół NetRom biega po plecach protokołu AX.25. Należy zrobić edycję dwóch plików, aby ustawić sobie NetRom na interfejsie AX.25. Jeden plik określa interfejsy NetRomu, a drugi porty AX.25, po których NetRom będzie biegał.
Na początek plik /etc/ax25/nrports. Plik ten określa porty NetRomu podobnie jak plik /etc/ax25/axports określa porty AX.25. Każde urządzenie NetRom musi zawierać swój wpis w pliku /etc/ax25/nrports. Normalnie, na Linuxie spotykamy tylko jedno urządzenie Netrom, które używa wielu zdeklarowanych portów AX.25. W niektórych tylko wypadkach, jak np. z BBS'em, można utworzyć dodatkowy pseudonim dla węzła NetRom, wówczas będzie więcej niż jeden.
Plik ten ma taką formę:
name callsign alias paclen description
Gdzie:
name
to tekst, według którego chcesz odwoływać sie do tego portu.
callsign
to jest znak/identyfikator, na którym pracować będzie protokół NetRom. Uwaga: nie jest to znak, do którego użytkownicy będą się łączyć, aby wejść do twojego węzła. (program 'node' opisany jest dalej). Znak ten powinien być unikalny i nie powinien powtarzać się nigdzie w pliku /etc/ax25/axports lub /etc/ax25/nrports.
alias
to jest przypisany pseudonim dla portu NetRom
paclen
to jest maksymalny rozmiar ramek NetRom transmitowanych przez ten port
description
dowolna nazwa dla tego portu
Oto jak może to wyglądać:
netrom VK2KTJ-9 LINUX 236 Linux Switch Port
Plik ten używany jest m. in. przez program call.
Następny plik to /etc/ax25/nrbroadcast. Zawiera on parę wpisów. Normalnie potrzebny jest jeden apis dla każdego portu AX.25 po którym puszczany będzie protokół NetRom.
Plik przyjmuje taki format:
axport min_obs def_qual worst_qual verbose
Gdzie:
axport
to nazwa portu uzyskana z pliku /etc/ax25/axports. Jeśli w pliku /etc/ax25/axports nie ma wpisu dla danego portu oznacza to, że zabraknie routingu dla NetRom na tym porcie oraz, że broadcasts będą ignorowane.
min_obs
jest to wartość dla min obscelecence dla tego portu
def_qual
określa wartość default quality dla NetRomu na tym porcie
worst_qual
określa wartość 'worst quality' dla NetRomu na tym porcie, wszystki routingi o tej wartości będą ignorowane
verbose
to jest oznakowanie czy z tego portu wychodzić będzie NetRom broadcast w pełnej formie czy też jednynie broadcast o tym wężle.
Oto przykład:
radio 1 200 100 1
Po ustawieniu powyższych dwóch plików należy teraz utworzyć urządzenie NetRom w bardzo podobny sposób do tego, w jaki czyniliśmy do dla urządzeń AX.25. Tym razem stosujemy polecenie 'nrattach'. Działa ono tak samo jak 'axattach' z tą różnicą, że powoduje doczepienie sieciowych interfejsów zwanych 'nr[0-9]'. I znów, przy pierwszym użyciu utworzon zostaje interfejs 'nr0', przy następnym użyciu, 'nr1' itd. Zatem, aby doczepić sieciowy interfejs do portu NetRom, który zdefiniowaliśmy uprzednio, wydalibyśmy polecenie:
# nrattach netrom
Polecenie to wygenerowało by pojawienie się interfejsu (nr0), z parametrami według szczegółów określonych w pliku /etc/ax25/nrports dla portu 'netrom'.
Jądro Linuxa obsługuje wszystkie mechanizmy protokołu NetRom, nie potrafi tylko wykonać niektórych funkcji. Demon NetRomu bierze na siebie tablice routingowe i broadcasty NetRomu. Uruchamiamy go poleceniem:
# /usr/sbin/netromd -i
Po pewnej chwili powinieneś zobaczyć jak plik /proc/net/nr_neigh wypełnia się powoli informacjami o sąsiednich stacjach NetRom.
Nie zapomnij umieścić polecenia /usr/sbin/netromd w jednym z plików *rc, aby zostało odpalone przy ładowaniu systemu operacyjnego.
Możliwe jest ustawienie statycznych ścieżek NetRom do poszczególnych węzłów. Pozwala na to polecenie 'nrparms'. podręcznik systemowy 'man' podaje kompletny opis, a tutaj mamy prosty przkład:
# /usr/sbin/nrparms -nodes VK2XLZ-10 + #MINTO 120 5 radio VK2SUT-9
Polecenie to utworzyłoby ścieżkę statyczną #MINTO:VK2XLZ-10 poprzez sąsiada VK2SUT-9 na porcie AX.25 o nazwie 'radio'.
Można też ręcznie dokonać wpisu dla sąsiednich stacji przy użyciu polecenia nrparms, Przyklad:
# /usr/sbin/nrparms -routes radio VK2SUT-9 + 120
polecenie to wpisałoby VK2SUT-9 jako sąsiada z wartością 'quality' 120, wpis nie zostanie usunięty automatycznie lecz jest stały.
Ustawianie interfejsu NetRom dla pracy w TCP/IP przypomina zupełnie konfigurowanie interfejsu AX.25 dla pracy w TCP/IP. Tutaj też, można albo określić adres IP i wartość MTU w wierszu poleceń dla 'nrattach', albo zastosować polecenie 'ifconfig' i 'route'. Należy jednak ręcznie wprowadzić wpisy ARP dla węzłów, do których chcesz mieć routing ponieważ brakuje mechanizmu, dzięki któremu twój komputer mógłby dowiedzieć się o adresach NetRom, które powinien użyć aby dotrzeć do poszczególnego węzła IP.
Zatem, doczepimy teraz interfejs nr0 z adresem IP 44.136.8.5 i MTU 512 oraz ustawimy go według szczegółów zawartych w pliku /etc/ax25/nrports na porcie NetRom o nazwie "netrom":
# /usr/sbin/nrattach -i 44.136.8.5 -m 512 netrom
# route add 44.136.8.5 nr0
lub można zrobić to tak, ale ręcznie:
# /usr/sbin/nrattach netrom
# ifconfig nr0 44.136.8.5 netmask 255.255.255.0 hw netrom VK2KTJ-9
# route add 44.136.8.5 nr0
Następnie, dla każdego węzła IP, który chesz aby był osiągalny, potrzeba dopisać recznie wartości dla ARP i route. Dopiszmy zatem węzeł docelowy z adresem IP 44.136.80.4 o adresie NetRom BBS:VK3BBS osiągalnego przez sąsiada VK2SUT-0:
# route add 44.136.80.4 nr0
# arp -t netrom -s 44.136.80.4 vk2sut-0
# nrparms -nodes vk3bbs + BBS 120 6 sl0 vk2sut-0
Argumenty '120' i '6' podane dla 'nrparms' to 'quality' i 'absolecence' dla NetRomu, który używa ich dla tej ścieżki.
Sieciowa warstwa packet protokołu Rose przypomina trzecią warstwę specyfikacji protokołu X.25. Obsługa Rose w jądrze Linuxa jest odmianą implementacji Rose przyjętej przez FPAC. http://fpac.lmi.ecp.fr/f1oat/f1oat.html
Sieciowa warstwa packet protokołu Rose używa i polega na portach AX.25, które uprzednio utworzyłeś. Protokół Rose biega po plecach protokołu AX.25. Aby ustawić Rose potrzeba dopisać plik konfiguracyjny dla portów Rose.
Plikiem, gdzie dopisujemy interfejsy dla Rose jest /etc/ax25/rsports. Określa on porty Rose w podobny sposób jak plik /etc/ax25/axports robi to dla portów AX.25. Oto jego format:
name addresss description
Gdzie:
name
jest tekstem, według którego chcesz odwoływać się do tego portu.
address
jest 10-cio cyfrowym adresem Rose, który przypisujesz temu portowi.
description
jest dowolnym tekstem opisującym port.
Oto jak można to wpisać:
rose 5050294760 Rose Port
Zauważ, że Rose używać będzie domyślnie znaku/identyfikatora podanego dla portu AX.25 , chyba że specjalnie podasz inny.
Aby podać osobny znak/identyfikator dla Rose, który używany będzie na każdym używanym porcie, trzeba wydać polecenie 'rsparms' w taki sposób:
# /usr/sbin/rsprams -call VK2KTJ-10
Przykład ten spowodowałby, że Linux słuchałby na znaku/identyfikatorze VK2TKJ-10 i używałby tegoż znaku na wszystkich portach AX.25 ustawionych dla łączności drogą Rose.
Po utworzeniu pliku /etc/ax25/rsports można doczepić urządzenie Rose w taki sam spoób jak urządzeia AX.25. Tym razem używa się polecenia 'rsattach'. Polecenie 'rsattach' doczepia sieciowe interfejse zwane 'rose[0-5]'. Przy pierwszym poleceniu rsattach powstaje interfejs 'rose0', przy drugim, 'rose1', itd. Przykład:
# rsattach rose
Polecenie to wygeneruje interfejs Rose (rose0) ustawiony według szczegółów podanych w pliku /etc/ax25/rsports dla wpisu nazwanego 'rose'.
Obecnie, protokół Rose obsługuje jedynie ścieżki statyczne. Program 'rsparms' pozwala na zapisanie tablic routingowych dla Rose pod Linuxem.
Na przykład:
# rsparms -nodes add 5050295502 radio vk2xlz
Powyższe dodałoby ścieżkę do węzła Rose 5050295502 na porcie AX.25 'radio' znajdującego w pliku /etc/ax25/axports przez stację sąsiednią o znaku VK2XLZ.
Możliwe jest ustawienie ścieżki, która uchwyci wiele docelowych stacji Rose w formacie jednego wpisu. Składnia wygląda następująco:
# rsparms -nodes add 5050295502/4 radio vk2xlz
co jest jednoznaczne w wyżej podanym przykładem z tą różnicą, że uchwycone zostają tutaj wszystkie stacje docelowe rozpoczynające się od 4 cyfr początkowych, w tym wypadku 5050. Jeszcze inaczej można zapisać to tak:
# rsparms -nodes add 5050/4 radio vk2xlz
co jest chyba mniej dwuznaczne.
Po zaktywizowaniu i ustawieniu wszystkich interfejsów AX.25, NetRom i Rose można w końcu popróbować łaczności.
Pakiet programów narzędziowych AX.25 zawiera program zwany 'call', który jest programem terminala z rozłącznym ekranem dla AX.25, NetRom i Rose.
Prosta łączność wygląda tak:
/usr/bin/call radio VK2DAY via VK2SUT
Łączność z węzłem NetRom o pseudonimie SUNBBS wygląda tak:
/usr/bin/call netrom SUNBBS
Łączność przez Rose do stacji HEARD o węźle 5050882960, w ten sposób:
/usr/bin/call rose HEARD 5050882960
Uwaga: 'call' musi wiedzieć na jakim porcie odbywa się łączność ponieważ te same stacje mogą być przecież osiągalne przez jakikolwiek port uprzednio skonfigurowany.
'call' pracuje w trybie liniowym w łącznościach przez AX.25. Traktuje on wiersze rozpoczynające się od '~' jako polecenia. Polecenie '~.' zamyka łączność.
Więcej informacji można znaleźć w podręczniku systemowym 'man'.
Linux jako system operacyjny posiada ogromne możliwości i nagina się do wielu sytuacji, gdy trzeba go konfigurować. Z elastycznością przychodzi też trud ustawiena go tak, żeby robił to czego chcemy. Trzeba zadać sobie wiele pytań przed rozpoczęciem ustawienia Linuxa do przyjmowania łączności z zewnątrz przez Rose, AX.25 i NetRom. Najważniejszym z nich jest:"Co chcę, aby użytkownicy zobaczyli podczas łączności?". Ludzie piszą rozmaite ciekawe programy, które mogą służyć użytkownikom, na przykład 'pms' zawarty w ax25-utils, lub 'node', bardziej rozbudowany' też dostępny w ax25-utils. Można też dać użytkownikom szansę zalogowania sie i użycia powłoki systemowej lub napisać własny program, jakąś grę lub bazę danych i pozwolić użytkownikom zrobić do niej łączność. Cokolwiek postanowisz musisz określić to oprogramowaniu AX.25, aby wiedziało co odpalić podczas wchodzących łączności.
Program 'ax25d' przypomina 'inetd' stosowany powszechnie do przyjmowania wchodzących łączności TCP/IP na unixach. Czuwa on i nasłuchuje na wchodzące łączności. Jeśli ją wykryje to sprawdza swój plik systemowy, aby zdecydować jakim programem usłużyć tej konkretnej łączności. Wytłumaczymy zatem jak ustawić ten plik, który jest standardowy, narzędziem do przyjmowania wchodzących łączności.
Plik ten ustawia demona 'ax25d' protokołu AX.25, który to demon zajmuje się wchodzącymi łącznościami AX.25, NetRom i Rose.
Na perwszy rzut oka jest troche powikłane ale po chwili przekonasz się, że "nie taki diabeł czarny, jak go malują". Trzeba być tylko świadomy paru małych pułapek.
Ogólny format pliku ax25d.conf jest taki:
# This is a comment and is ignored by the ax25d program.
[port_name] || <port_name> || {port_name}
<peer1> window T1 T2 T3 idle N2 <mode> <uid> <cmd> <cmd-name> <arguments>
<peer2> window T1 T2 T3 idle N2 <mode> <uid> <cmd> <cmd-name> <arguments>
parameters window T1 T2 T3 idle N2 <mode>
<peer3> window T1 T2 T3 idle N2 <mode> <uid> <cmd> <cmd-name> <arguments>
default window T1 T2 T3 idle N2 <mode> <uid> <cmd> <cmd-name> <arguments>
Gdzie:
#
stając na początku wiersza oznacza komentarz i jest całkowicie pomijane przez program 'ax25d'.
<port name>
nazwa portu AX.25, NetRom lub Rose korespondująca kolejno do plików /etc/ax25/axports, /etc/ax25/nrports and /etc/ax25/rsports. Nazwa portu objęta jest nawiasem '[]' dla portu AX.25, '<>' dla NetRom, '{}' dla Rose. Można też inaczej zapisać to pole stosując 'znak/identyfikator via' przed nazwą portu, pokazując w ten sposób, że będzie można łączyć się do tego interfejsu przez podany tutaj znak. Podamy dalej przykład, który to zilustruje.
<peer>
znak/identyfikator węzła wchodzącego, dla którego te ustawienia będą obowiązywać. Jeśli nie podasz tutaj numerycznego identyfikatora to każdy będzie pasował.
window
parametr Window dla AX.25 (K) lub MAXFRAME dla tego ustawienia
T1
licznik retransmisji Ramki (T1) w jednoskach półsekundowych
T2
czas wyczekiwania oprogramowania AX.25 na następną ramkę przed przygotowaniem odpowiedzi, w jednostkach jednosekundowych.
T3
czas wyczekiwania zanim oprogramowanie AX.25 zamknie bezczynną łączność, mierzone w jednostkach 1 sekundy.
idle
wartość licznika braku akrywności w sekundach
N2
liczba kolejnych retransmisji, które nastąpią zanim łącze zostanie zamknięte.
<mode>
dostarcza mechanizmu pozwalającego na określenie pewnego typu zezwoleń. Podając rozmaite literki, każda reprezentuje jakieś zezwolenie, można manipulować tą funkcją. Literki muszą być albo małe albo duże i muszą być w jednym ciągu bez spacji. Oto do one:
u/U
UTMP - nie używane
v/V
Validate call - nie używane
q/Q
Quiet - nie prowadzi log-u dla łączności
n/N
check NetRom Neighbour - nie używane
d/D
Disallow Digipeaters - łączność musi być bezpośrednia, bez digi
l/L
Lockout - odrzuca łączność
*/0
marker - ustawia znaczek, nie zmienia zezwoleń
<uid>
'userid' w Linuxie dla programu, który będzie obsługiwał wchodzącą łącznśść
<cmd>
pełna ścieżka dostępu programu, bez żadnych argumentów
<cmd-name>
tekst, który wystąpi dla tego programu po wydaniu polecenia systemowego
'ps' (Najczęsciej nazwa własna programu bez ścieżki dostępu).
<arguments>
są to argumenty podawane w wierszu poleceń dla <cmd>. Argumenty
te przybierają rozmaite znaczenie w zależności od poniższych ustawień:
%d Nazwa portu, na którym przyjęto łączność.
%U znak/identyfikator AX.25 dołączonej stacji bez numerka SSID, dużymi
literami.
%u znak/identyfikator AX.25 dołączonej stacji bez numerka SSID, małymi
literami.
%S znak/identyfikator AX.25 dołączonej stacji z numerkiem SSID, dużymi
literami.
%s znak/identyfikator AX.25 dołączonej stacji z numerkiem SSID, małymi
literami.
%P znak/identyfikator węzła, od którego dokonuje się
łączność, bez numerka SSID, dużymi literami
%p znak/identyfikator węzła, od którego dokonuje się
łączność, bez numerka SSID, małymi literami
%R znak/identyfikator węzła, od którego dokonuje się
łączność, z numerkiem SSID, dużymi literami
%r znak/identyfikator węzła, od którego dokonuje się
łączność, z numerkiem SSID, małymi literami
Potrzebna jest jedna sekcja według powyższego formatu dla każdego interfejsu AX.25, NetRom i Rose, na którym przyjmowane mają być wchodzące łączności typu AX.25, NetRom i Rose.
W paragrafie tym są jeszcze dwa specjalne wiersze, jeden rozpoczyna się od słowa 'parameters' a drugi od 'default' (tak, tak, różnią się). Wiersze te służą do specjalnych cełów.
Wiersz 'default' służy jako siatka-na-wszystko. Wchodzące łączności, które nie mają własnych zezwoleń na danym interfejsie <interface_call> dostaną wartości domyślne podane w 'default'. Jeśli wpisu 'default' nie ma w ogóle to wszystkie wchodzące łączności nie posiadające własnych zezwoleń będą natychmiast odrzucone bez ostrzeżenia.
Wiersz 'parameters' jest trochę bardziej subtelny i to tutaj jest ta pułapka, o której wspominałem u początku. Jakiekolwiek pole, którejkolwiek deklaracji dla węzła wchodzącego można wypełnić znaczekiem '*' by uzyskać 'wartość domyślną'. Wiersz 'parameters' jest wierszem, który deklaruje wspomniane 'wartości domyślne'. Oprogramowanie jądra z kolei posiada swoje własne wartości domyślne, których użyje jeśli nic nie określisz w wierszu 'parameters'. Pułapka polega na tym, że wartościustawione wierszem 'parameters' działają tylko w dól, a nie w górę. Można mieć więcej niż tylko jeden wpis 'parameters' dla poszczególnych interfejsów grupując sobie wartości domyślne.
No dobrze, teraz ilustracja:
# ax25d.conf for VK2KTJ - 02/03/97
# This configuration uses the AX.25 port defined earlier.
# <peer> Win T1 T2 T3 idl N2 <mode> <uid> <exec> <argv[0]>[<args....>]
[VK2KTJ-0 via radio]
parameters 1 10 * * * * * root /usr/sbin/axspawn axspawn %u +
VK2XLZ * * * * * * *
VK2DAY * * * * * * *
NOCALL * * * * * * L
default 1 10 5 100 180 5 * root /usr/sbin/pms pms -a -o vk2ktj
[VK2KTJ-1 via radio]
default * * * * * 0 root /usr/sbin/node node
<netrom>
parameters 1 10 * * * * *
NOCALL * * * * * * L
default * * * * * * 0 root /usr/sbin/node node
{VK2KTJ-0 via rose}
parameters 1 10 * * * * * root /usr/sbin/axspawn axspawn %u +
VK2XLZ * * * * * * *
VK2DAY * * * * * * *
NOCALL * * * * * * L
default 1 10 5 100 180 5 * root /usr/sbin/pms pms -a -o vk2ktj
{VK2KTJ-1 via rose}
default * * * * * 0 root /usr/sbin/node node radio
Powyżej ukazane jest, że ktokolwiek usiłujący łączności do znaku `VK2KTJ-0' na porcie AX.25 o nazwie 'radio' otrzyma takie zezwolenia:
Jeśli ktoś ma ustawione 'NOCALL' zostanie odrzucony, patrz użycie literki 'L'.
Wiersz 'parameters' zmienia dwie wartości spośród domyślnych wartości jądra (Windows i T1) oraz wyznacza program /usr/sbin/axspawn program, aby był odpalony. Ktorakolwiek instancja programu 'axspawn' uruchomiona w ten sposób będzie widoczna po wydaniu polecenia 'ps' w Linuxie jako axspawn. Dwa następne wiersze dostarczają definicji dla dwóch stacji, do których powyższe reguły zostaną zastosowane.
Ostatni wiersz w paragrafie jest definicją typu siatka-na-wszystko i zostanie zastosowana do wszystkich innych stacji (łącznie z VK2XLZ i VK2DAY jeśli mieć będą inne numerki SSID niż -1). Definicja ta ustawia wprost wszystkie wartości, dodatkowo odpala wchodzącym łącznościom typu AX.25 program 'pms' informując go, że łączność jest typu AX.25 i że właścicielem jest znak VK2KTJ. (Patrz 'Ustawianie PMS'a' poniżej).
Następna konfiguracja przyjmuje łączności do znaku VK2KTJ-1 przez port 'radio'. Odpala ona program 'node' dla wszystkich, którzy się do niego łączą.
Kolejna konfiguracja obsługuje NetRom. Zauważ zastosowanie nawiasów znaku-większości i znaku-mniejszości zamiast nawiasów kwadratowych. One właśnie deklarują wejście do NetRom. Ustawienie jest prostsze i mówi tylko tyle, że ktokolwiek wchodzi do stacji przez NetRom na porcie zwanym 'netrom' otrzyma program 'node', chyba że ma znak 'NOCALL' i wtedy zostanie odrzucony.
Dwie ostanie konfiguracje przeznaczone są dla wchodzących łączności Rose. Pierwsza dla ludzi, którzy poprzez adres naszego węzła Rose wołają znak 'vk2ktj-0' a druga dal tych, co wołają znak 'VK2KTJ-1'. Działają one w dokładnie ten sam sposób. Zauważ zastosowane nawiasy, które odróżniają port Rose.
Powyższy przykład jest zmyślony ale myślę, że jasno ilustruje ważne cechy składni pliku konfiguracyjnego. Pełny opis pliku znajdziesz w podręczniku systemowym 'man' dla ax25d.conf. Załączono bardziej szczegółowy przykład w pakiecie ax25-utils, który też się może przydać.
Po edycji wspomnianych dwóch plików można odpalić program ax25d poleceniem:
# /usr/sbin/ax25d
Gdy program pracuje, wówczas użytkownicy powinni móc łączyć się przez AX.25 do twojego Linuxa. Pamiętaj, abyś umieścił polecenie ax25d w plikach rc, aby startowało za każdym razem gdy właczasz komputer.
Oprogramowanie węzła zostało zrobione przez Tomi'ego Manninen tomi.manninen@hut.fi i opierało się głownie na programie PMS. Dostarcza ono dość elastycznych i kompletnych możliwości dla węzła, które łatwo ustawić. Użytkownicy, po ustaleniu łączności, mogą odpalić Telnet, wykonać dalsze łączności NetRom, Rose lub AX.25 jak również uzuskiwać rozmaite informacje tak jak Finger, lista Węzłow i stacji ostanio słyszanych, itp. Węzeł można ustawić dość prosto tak, że zaserwuje on jakąkolwiek usługę dostępną pod Linuxem.
Normalnie, 'node' wywoływany może być przez program 'ax25d', odpowie on też na wezwania wchodzące drogą TCP/IP dzięki 'inetd', który wpuści użytkownika i odpali go dla niego, lub można go uruchomić z wiersza poleceń.
Plik node.conf decyduje o głównej konfiguracji węzła. Jest prostym plikiem tekstowym, a jego składnia jest taka:
# /etc/ax25/node.conf # configuration file for the node(8) program. # # Linie rozpoczynające się od # są komentarzami i są ignorowane. # Hostname # deklaruje nazwę 'hostname' dla węzła hostname radio.gw.vk2ktj.ampr.org # Local Network # pozwala na określenie tego co 'local' w celach rewizji zezwoleń # przy użyciu node.perms localnet 44.136.8.96/29 # Hide Ports # Jeśli wpisane, pozwala na ukrycie portów przed użytkownikami. Podane porty # nie będą wyświetlane poleceniem (P)orts. hiddenports rose netrom # Callserver # jeśli wpisane, pozwoli użytkownikom na dostęp do callserver'a. callserver zone.oh7rba.ampr.org # Node Identification. # to pojawi się w zachęcie systemowej węzła NodeId LINUX:VK2KTJ-9 # NetRom port # To jest nazwa portu NetRom, który używany będzie do wychodzących łączności # z węzła 'node'. NrPort netrom # Node Idle Timeout # Określa w sekundach wartość "idle time" dla łączności z tym węzłem idletimout 1800 # Connection Idle Timeout # określa licznik "idle" dla łączności uczynionych przez ten węzeł, w sekundach # seconds. conntimeout 1800 # Reconnect # Określa czy łączność z użytkownikami powinna być ponowiona gdy ich łączność # z innymi stacjami została przerwana czy też mają być rozłączeni na dobre. # reconnect on # Pseudonimy dla poleceń # pozwala na uproszczenie uwikłanych poleceń węzła alias CONV "telnet vk1xwt.ampr.org 3600" alias BBS "connect radio vk2xsb" # Pseudonimy dla poleceń zewnętrzych # Pozwala na odpalanie programów z zewnątrz spod węzła 'node'. # extcmd <cmdname> <flag> <userid> <command> # Flag == 1 to jest jedyna dotychczas stosowana funkcja. # <command> jest pisane tak jak dla ax25d.conf extcmd PMS 1 root /usr/sbin/pms pms -u %U -o VK2KTJ # Logging # Ustawienie log-u do log-u systemowego. 3 - najbardziej gadatliwe, # 0 - wyłączone. loglevel 3
Węzeł 'node' pozwala na ustawienie pewnych zezwoleń dla użytkowników. Zezwolenia te pozwalają ci decydować, którzy użytkownicy mogą używać opcji takich jak (T)elnet, i (C)onnect, na przykład, a którzy nie mogą. Plik node.perms zawiera właśnie te informacje i składa się z pięciu kluczowych pól. Jeśli pole zawiera znaczek '*' to zastępuje cokolwiek. Przydaje się to do definicji reguł domyślnych.
user
zawiera znak lub użytkownik do którego kolejne zezwolenia się tyczą.
Numerki SSID są ignorowane, zatem umieścić tutaj należy goły znak.
method
każdy protokól i metoda dostępu może otrzymać swoje zezwolenia. Na przyklad
możesz zezwolić użytkownikom dołączonym protokołem AX.25 i NetRom używać
opcji (C)onnect, ale zabronić tego innym, którzy weszli telnetem
z nie-lokalnego węzła. Drugie pole zatem pozwala określenie reguł
dla łączności, które weszły różnymi metodami. Oto te metody:
method description
------ -----------------------------------------------------------
ampr Użytkownik wszedł telnetem z adresu amprnet (44.0.0.0)
ax25 Użytkownik wszedł drogą AX.25
host Użytkownik wszedł odpalając 'node' z wiersza poleceń
inet Użytkownik wszedł telnetem z adresu 'non-local'i z poza amprnet
local Użytkownik wszedł telnetem z komputera typu 'local'
netrom Użytkownik wszedł drogą NetRom
rose Użytkownik wszedł drogą Rose
* Użytkownik wszedł jakkolwiek.
port
Dla użytkowników wchodzących przez AX.25 można udzielać zezwoleń osobno
każdy port Ax.25. Pozwala to decydować co użytkownicy AX.25 mogą robić
zależnie od tego do jakiego portu się podłączyli. Trzecie pole zawiera
nazwę owych portów, jeśli używasz tej funkcji. Działa to tylko dla
łączności przez AX.25.
password
nieobowiązkowo, można ustawić węzeł tak, że przedstawi on użytkownikom
zachętę systemową, aby wprowadzili hasło zanim się dołączą. Przydaje się
to do ochrony tych użytkowników, którzy ustawiony mają wysoki stopień
zezwoleń. Jeśli czwarte pole ma być wypełnione to jego wartość jest
hasłem, które będzie przyjęte.
permissions
to pole stoi jako ostanie dla każdego wpisu w pliku. Jest ono kodowane
bitowo tak, że każda usługa posiada swoją wartość bitową, której wpisanie
powoduje, że zezwolenie na usługę jest udzielone lub zabronione. Oto
lista usług i im korespondujących warości bitowych:
value description
----- -------------------------------------------------
1 Zezwolenie na Login
2 Zezwolenie na (C)onnect drogą AX.25
4 Zezwolenie na (C)onnect drogą NetRom
8 Zezwolenie na (T)elnet do 'lokalnych' węzłów
16 Zezwolenie na (T)elnet do węzłów z sieci amprnet (44.0.0.0)
32 Zezwolenie na (T)elnet do 'nie-lokalnych', węzłów z poza amprnet
64 Zezwolenie na (C)onnect drogą AX.25 przez ukryte porty
128 Zezwolenie na (C)onnect drogą Rose
Aby zakodować wartość zezwoleń dla danej reguły poprostu wybierz te zezwolenia, które chcesz, aby użytkownik miał i dodaj ich wartości bitowe. Otrzymaną w ten sposób cyfrę należy umieścić w polu nr. 5.
Oto jak można ustawić plik node.perms:
# /etc/ax25/node.perms
#
# Operatorem węzła jest VK2KTJ, posiada hasło 'secret' i wolno mu szystko
# jakąkolwiek metodą wszedł
vk2ktj * * secret 255
# Ci użytkownicy są nie wejdą w ogóle
NOCALL * * * 0
PK232 * * * 0
PMS * * * 0
# Użytkownicy INET też nie wejdą w ogóle
* inet * * 0
# Ci, którzy weszli drogą AX.25,NetRom, Local, Host i AMPR mają zezwolenie
# na (C)onnect i (T)elnet do węzłów 'lokalnych' i amprnet, ale nie innych
# adresów IP.
* ax25 * * 159
* netrom * * 159
* local * * 159
* host * * 159
* ampr * * 159
Program 'node' powinien normalnie być uruchamiany przez program 'ax25d'. Dokonujemy tego wpisując odpowiednie reguły w pliku /etc/ax25/ax25d.conf. Na mojej maszynie chcialem, aby użytkownicy mieli wybór łączności do węzła lub innych programów usługowych. 'ax25d' pozwala właśnie na to jeśli sprytnie powpisujesz pseudonimy portów. Dla przykładu, stosując powyższą konfigurację ax25d chcę ustawić 'node' tak, aby użytkownicy łączący się do VK2KTJ-1 dostali się do węzła 'node'. Wpisałem zatem takie wiersze do pliku /etc/ax25/ax25d.conf:
[vk2ktj-1 via radio]
default * * * * * 0 root /usr/sbin/node node
To oznacza, że oprogramowanie jądra Linuxa odpowie na prośbę o łączność dla znaku 'VK2KTJ-1' na porcie AX.25 nazwanego 'radio', i odpali potem program node.
Jeśli chcesz, aby użytkownicy mogli wejść telnetem do twojej maszyny i uzyskać dostęp do węzła 'node' to nie ma nic prostszego. Najpierw zdecyduj na jaki port użytkownicy powinni się łaczyć. W tym wypadku wybrałem arbitralny numer 4000, choć Tomi podaje w swojej dokumentacji szczegóły na temat jak podmienić zwyczajnego demona telnetu na demona węzła 'node'.
Potrzebujesz zmodyfikować dwa pliki.
Do pliku /etc/services powinieneś dodać:
node 4000/tcp #OH2BNS's node software
a do pliku /etc/inetd.conf dodaj:
node stream tcp nowait root /usr/sbin/node node
Po wykonaniu tego i po restarcie programu 'inetd' użytkownicy, którzy wchodzą telnetem na port 4000 w twojej maszynie dostaną zachętę systemową, aby się zalogować, i jeśli zostało to dla nich skonfigurowane to hasło, po podaniu którego podłączeni zostaną do węzła 'node'.
Program axspawn pozwala wchodzącym drogą AX.25 stacjom na zalogowanie się do twojego komputera. Może on zostać wywołany programem ax25d w taki sam sposób jak program 'node'. Należy dodać tego typu zapis do pliku /etc/ax25/ax25d.conf, jeśli pragniesz, aby użytkownicy mogli logować się do twojego komputera:
default * * * * * 1 root /usr/sbin/axspawn axspawn %u
Jeśli wiersz zakończony zostanie znaczniek '+' to użytkownicy, przed zalogowaniem, będą musieli uderzyć przycisk 'Return'. Wartość domyślna ma to wyłączone. Poszczególne zapisy dla stacji, które występują pod tym wierszem spowodują uruchomienie programu 'axspawn' podczas wchodzącej łączności. Po uruchomieniu, 'axspawn' najpierw sprawdza czy na wierszu poleceń ukazał się legalny znak/edentyfikator, pozbawia go numerka SSID, a potem sprawdza plik /etc/passwd czy użytkownik posiada założone konto. Jeśli tak, i hasło jest ""(puste) lub '+', wtedy wpuszcza użytkownika. Jeśli w polu hasła jest cokolwiek innego to użytkownik jest odpytywany o swoje hasło. Przy nieistaniejących kontach w pliku /etc/passwd 'axspawn' można ustawić tak, że utworzy je sam.
Zachowanie programu axspawn można zmieniać plikiem /etc/ax25/axspawn.conf. Plik ten ma formę:
# /etc/ax25/axspawn.conf
#
# pozwala na automatyczne zakładanie kont dla użytkowników
create yes
#
# wpuszcza użytkownika 'gość' jeśli wyżej jest 'no' lub niepowiodły sie
# inne rzeczy. Wyłacza sie 'no'.
guest no
#
# ID dla groupy lub nazwa konta dla samozakładania konta
group ax25
#
# first user id to use
first_uid 2001
#
# maximum user id
max_uid 3000
#
# gdzie umieszczać katalog domowy dla nowych użytkowników
home /home/ax25
#
# powłoka systemowa dla użytkownika
shell /bin/bash
#
# kojarzenie znaków z użytkownikami dla łączności wychodzących.
associate yes
Powyższe osiem ustawialnych przełaczników mają takie znaczenie:
# wskazuje, ze to komentarz
create
jeśli ustawione na 'yes' to 'axspawn usiłuje sam założyć konto dla
użytkownika, który jeszcze nie ma wpisu w pliku /etc/passwd.
guest
pole to określa nazwę login-u konta dla ludzi włączających się ale
nie mających jeszcze konta przy 'create' ustawionym na 'no'. Zwykle
jest to ax25 lub guest
group
to pole określa nazwę grupy, jaka zostanie użyta dla włączających się
użytkowników nie mających jeszcze wpisu w pliku /etc/passwd.
first_uid
jest to cyfra pierwszego userid wybieranego automatycznie dla nowych
użytkowników.
max_uid
jest to najwyższy numer, jaki będzie użyty dla userid nowych użytkowników
home
to jest katalog domowy (login) dla nowych uzytkowników
shell
to określa powłokę systemową dla nowych użytkowników
associate
to oznaczenie wskazuje czy użytkownik, po zalogowaniu się, wykonujący
łączność wychodzącą będzie miał swój własny znak, czy też znak twojej
stacji.
Program pms to implementacja prostego 'personal message system' napisanego początkowo przez Alan'a Cox. Dalszy rozwój podjęty został przez David'a Brown, N2RGT, dcb@vectorbd.com. Obecnie jest nadal bardzo prosty mający mozliwość wysłania e-mail'a do właściciela systemu i uzyskać ograniczone informacje maszynie lecz David pracuje nad tym, jak poszerzyć jego możliwości i uczynić go bardziej użytecznym.
Pozostało więc teraz parę prostych plików do stworzenia, które udzielą użytkownikom pewnych informacji o samym systemie, a potem dodać odpowiedni zapis do pliku ax25d.conf, aby dołączający się użytkownicy dostali się do PMS.
Plik /etc/ax25/pms.motd zawiera 'wiadomość dnia', którą użytkownicy ujrzą po ustaleniu łączności i zwykłym nagłóku BBS. Ten prosty plik jest tekstowy i wiadomość w nim zawarta będzie wysłana do użytkowników.
Plik /etc/ax25/pms.info również ma zawierać tekstowe, bardziej szczegółowe informacje na tremat twojej stacji. Informacja w nim zawarta przedstawiana jest użytkownikom w odpowiedzi na ich polecenie 'Info' z zachęty PMS>.
Gdy jakiś użytkownik wysyła pocztę do znaku AX.25 to 'pms' spodziewa się, że znak ten jest własnością prawdziwego użytkownika z kontem na twojej maszynie. Opisane jest to w osobnej sekcji.
Dodanaie programu 'pms' do pliku /etc/ax25/ax25d.conf jest bardzo proste. Trzeba jednak pamiętać o jednej malutkiej rzeczy. Dave dodał możliwość podania argumentów dla PMS na wierszu poleceń, które kontrolują kilkanaście konwencji związanych z końcem wiersza. Konwencje AX.25 i NetRom oczekują, że 'end-of-line' to 'carriage return', 'linefeed' podczas gdy w unixach to jest poprostu 'newline'.Więc, dla przykładu, jeśli checiałbyś dodać zapis, który oznaczałby, że należy odpalić PMS dla wchodzącej łączności przez port AX.25, to dadaj taki wiersz:
default 1 10 5 100 5 0 root /usr/sbin/pms pms -a -o vk2ktj
To poprostu odpala program pms mówiąc mu, że jest to łączność wchodząca drogą AX.25 i że właścicielem PMS'a jest vk2ktj. Popatrz na podręcznik systemowy 'man' w sprawie innych argumentów dla innych metod dostępu.
Aby sprawdzić czy PMS działa sprubuj taką komendę z wiersza poleceń:
# /usr/sbin/pms -u vk2ktj -o vk2ktjPodstaw swój własny znak w miejsce mojego. Polecenie to odpali PMS mówiąc mu, że ma używać uniksowych konwencji end-of-line, i że użytkownikiem logującym się jest vk2ktj. Możesz zrobić teraz wszystko to, co użytkownicy łączący się z zewnątrz.
Dodatkowo mógłbyś poprosić jakąś inną stację, aby się do ciebie dołączyła, aby potwierdzić, że ustawienie pliku ax25d.conf działa poprawnie.
Programy 'user_call' to w rzeczywistości są 'ax25_call' i 'netrom_call'. Pomuślane są one tak, że mogą być wezwane z 'ax25d', w celu zautomatyzowania łączności z odległymi komputerami. Naturalnie można je wywołać z wielu innych miejsc, np. z powłoki systemowej, lub innych demonów, jak np. programu 'node'.
Przupominają w swej prostocie program 'call'. Nie zajmują się obróbką żadnych danych, zatem sam musisz zadbać o to jak traktowane będzie end-of-line.
Rozpocznijmy od tego jak można ich używać. Wyobraź sobie, że posiadasz małą sieć w domu i że jednym komputerem jest Linux spelniający rolę bramki radiowej, oraz drugi komputer, który jest węzłem BPQ. Komputery złączone są razem ethernetem.
Noramlnie, użytkownicy radiowi, aby móc łączyć się z węzłem BPQ musieliby robić to przez digipeating poprzez twojego linuxa, lub połączyć się wpierw z programem 'node' na twoim linuxie, a stamtąd wykonać następne połączenie do węzła BPQ.
Wyobraź sobie, że węzeł BPQ ma znak VK2KTJ-9 a linux ma port o nazwie 'bpq' obsługujący AX.25/ethernet. Również dodajmy, że bramka radiowa Linux posiada port radiowy 'radio'.
Zapis do pliku /etc/ax25/ax25d.conf wyglądałby w ten deseń:
[VK2KTJ-1 via radio]
default * * * * * * *
root /usr/sbin/ax25_call ax25_call bpq %u vk2ktj-9
i umożliwiłby użytkownikom połączenie wprost do `VK2KTJ-1' co w gruncie rzeczy jest demonem ax25d pod Linuxem a następnie przełoczyłoby ich na łączność AX.25 do `VK2KTJ-9' przez interfejs 'bpq'.
Jest cały asortyment innych możliwych kombinacji, które są do wypróbowania. Programy 'netrom_call' oraz 'rose_call' pracują w podobny sposób. Jeden z radioamatorów wykorzystał tę funkcję, aby ułatwić łączność do odległego BBS-u. Noramalnie użytkownik musiałby wprowadzić dlugą strunę poleceń, aby wykonać tę łączność więc on dokonał wpisu, który sprawiał, że wspomniany BBS wyglądał tak, jakby dostępny on był na sieci lokalnej; demon ax25d pośredniczył w łączności do odległego BBS-u.
Istnieje wiele sutuacji, w których pożądane jest, aby powiązać znak z kontem użytkownika Linuxa. Jedną z takich sutuacji byłaby, gdy wielu radioamatorów dzielą ze sobą tę samą maszynę a chcą używać swoich znaków dla wychodzących łączności. Innym przykładem jest PMS, którego użytkownicy chcieliby rozmawiać z jakimś użytkownikiem na twoim komputerze.
Oprogramowanie AX.25 dostarcza sposobu pozwalającego na skojarzenie znaku z kontem użytkownika. Wspominaliśmy to już wcześniej w sekcji o PMS, ale podkreślam to raz jeszcze, żeby nie umknęło to twej uwadze.
Kojarzenia dokonujemy poleceniem 'axparms'. Ota jak wygląda przykład:
# axparms -assoc vk2ktj terry
Polecenie to kojarzy powyższy znak AX.25 vk2ktj z kontem 'terry' na tym komputerze. Więc przykładowo, każda poczta dla vk2ktj z pms-u będzie dostarczona do konta 'terry' pod Linuxem.
Zapamiętaj, aby wpisać te kojarzenia do plików rc, aby dostępne były za każdym razem, gdy odpalasz komputer.
Zauważ, że nigdy nie powinieneś kojarzyć znaku z kontem 'root' ponieważ spowoduje to dużo problemów konfiguracyjnych w innych programach.
Wielu ludzi preferuje którąś z wersji NOS uruchamianą w Linuxie ponieważ oferują one wiele cech funkcji, do któtych przywykli. Większość tych ludzi chciałoby również mieć taką mozliwość, aby NOS mógł mówić do jądra Linuxa po to, by móc zaoferować jego niektóre usługi dla użytkowników radiowych.
Następująca informacja jest wkładem Brandon'a S. Albery, KF8NH, który wytłumaczył jak wzajemnie połączyć NOS'a uruchomionego pod Linuxem z samym jądrem Linuxa przy użyciu urządzenia 'fajka'.
Ponieważ zarówno Linux jak NOS obsługują protokół 'slip' możliwe jest połączenie nich obu ustawiając łącze slip. Kosztownym sposobem możnaby to zrobić za pomocą pętli kablowej i dwóch portów seryjnych; byłoby to powolne łącze. Linux dostarcza funkcji, która dostępna jest na wielu innych Unixo-podobnych systemach operacyjnych, zwanej 'fajką'. Są to specjalne pseudo interfejsy, które przedstawiają się dla oprogramowania jako standardowe urządzenia tty, lecz faktycznie są tylko pętlami do następnej 'fajki'. Urządzenia te mogą być używane jeśli program pierwszy otworzy je ze strony 'master', a następnie program drugi ze strony 'slave'. Gdy oba końce zostaną otworzone, wówczas programy mogą się komunikować ze sobą pisząc poprostu literki przez 'fajkę' jakby to było normalne urządzenie terminalowe.
Zanim połączysz jakąś wersję NOS-a lub innego programu z jadrem Linuxa, wpierw musisz wybrać jakąś 'fajkę'. Znajdziesz ją szukając w katalogu '/dev'. Końcówki 'master' nazywają się ptyp[1-f] a końcówki 'slave' znane są jako: ttyp[1-f]. Pamiętaj, że występują parami. Jeśli weźmiesz 'fajkę' /dev/ptypf jako końcówkę 'master' to musisz dobrać 'fajkę' /dev/ttypf jako 'slave'.
Po wybraniu pary urządzeń 'fajka', należy przypisać końcówkę 'master' dla jądra a końcówkę 'slave' dla programu NOS ponieważ jądro Linuxa rozpoczyna jako pierwsze, a 'master' musi być otworzone na początku. Linux, warto wiedzieć, powinien mieć odmienny IP adres od adresu NOS-a, zatem musisz mu przypisać unikalny adres, jeśli jeszcze tego nie uczyniłeś.
'Fajkę' ustawiamy tak samo jak urządzenie seryjne, więc aby utworzyć łącze slip na jądrze Linuxa mógłbyś użyć coś takiego:
# /sbin/slattach -s 38400 -p slip /dev/ptypf &
# /sbin/ifconfig sl0 broadcast 44.255.255.255 pointopoint 44.70.248.67 /
mtu 1536 44.70.4.88
# /sbin/route add 44.70.248.67 sl0
# /sbin/route add -net 44.0.0.0 netmask 255.0.0.0 gw 44.70.248.67
W tym przykładzie jądro linuxa otrzynało adres IP 44.70.4.88 a program NOS adres IP 44.70.248.67. Polecenie 'route' w ostatnim wierszu instruuje jądro linuxa, że wszelkie datagramy z przeznaczeniem dla amprnet-u mają iść poprzez łącze slip utworzone poleceniem slattach. Zwykle polecenia powyższe umieścić należałoby w w plikach /etc/rc.d/rc.inet2 po tym jak wszystkie inne ustawienia siciowe zostaną wykonane, po to, aby łącze slip było dostępne po przeładowaniu komputera. Uwaga: nie ma powodów, aby używać cslip zamiast slip gdyż to właściwe redukuje osiągi ponieważ łącze to jest virtualne i zachodzi wystarczająco szybko, a uprzenia kompresja nagłówków zabiera więcej czasu aniżeli przesył nieskompresowanych datagramów.
Ustawienie łącza po stronie NOS-a można pokusić się i zrobić tak:
# interfejs można nazwać jak ci się podoba. ja nazwałem go dla wygody
# 'linux'
#
attach asy ttypf - slip linux 1024 1024 38400
route addprivate 44.70.4.88 linux
Polecenia te utworzą port slip zwany 'linux' na 'fajce' z końcówką 'slave' i dołączą go do jadra linuxa, dodadzą 'ścieżkę', aby łącze pracowało. Po wystartowaniu NOS-a pod Linuxem powinieneś móc 'zapingować' Linuxa i odwrotnie. Jeśli nie, posprawdzaj, że nie popełniłeś żadnych błędów, szczególnie przy adresach i na końcówkach 'fajek'.
System plików /proc zawiera pewną liczbę plików związanych bezpośrednio z oprogramowaniem jądra dla AX.25 i NetRom. Używane są one głownie przez programy z pakietu ax25-utils ale mają taki format,że być może chciałbyś je przeczytać. Foramt jest naprawdę łatwy i nie sądzę, że trzeba wiele tłumaczyć.
/proc/net/arp
zawiera mapę dla protokołu Address Resolution pomiędzy adresami IP
a adresami protokołu warstwy MAC. Te obejmują AX.25, ethernet i niektóre
protokoły wartstwy MAC
/proc/net/ax25
zawiera listę otwartych gniazd AX.25. Mogą one albo sluchać na
nadchodzące łączności lub są aktywne.
/proc/net/ax25_bpqether
zawiera mapę dla AX.25 a BPQ o znakach
/proc/net/ax25_calls
zawiera mapę o userid i znakach ustawioną przez polecenie
axparms -assoc command.
/proc/net/ax25_route
zawiera informację na temat ścieżki digipeaterów
/proc/net/nr
zawiera listę gniazd NetRom, które są otwarte na skutek tego, że
sluchają lub, że są aktywne.
/proc/net/nr_neigh
zawiera informacje o sąsiadach, o których NetRom jest świadome.
/proc/net/nt_nodes
zawiera informacje o węzłach znanych dla oprogramowania NetRom
/proc/net/rose
zawiera listę otwartych gniazd Rose na skutek tego, że albo słuchają
albo są aktywne
/proc/net/Rose_nodes
zawiera mapę o docelowych stacjach Rose przez sąsiadów Rose
/proc/net/rose_neigh
zawiera listę węzłów, które Rose zna
/proc/net/rose_routes
zawiera listę wszystkich aktywnych łączy Rose
Podane są poniżej przykłady niektórych typowych konfiguracji. Są to tylko rady ponieważ jest tyle sposobów ustawienia swojej sieci ile istnieje sieci do skonfigurawania, ale te mogą przydać ci się na początek.
Wielu z was posiada małe, lokalne sieci w domu i chcecie podłaczyć te komputery do swojej lokalnej sieci radiowej. Właśnie takiego układu używam sam w domu. Zadbałem o to, aby dostać odpowiednią liczbę właściwych adresów, tak, aby można było je uchwycić jednym routingiem dla wygody i używam ich na swojej lokalnej sieci ethernet. Wasz koordynator adresów IP pomoże wam w tym również jeśli chcecie tego sprobować. Adresy mojej lokalne sieci Ethernet tworzą podsekcję adresów sieci radiowej. Następujące ustawienie jest rzeczywistę dla linuxa jako routera na mojej sieci w domu:
--- .
| Network /---------\ . Network
| 44.136.8.96/29| | . 44.136.8/24 \ | /
| | Linux | . \|/
| | | . |
| eth0 | Router | . /-----\ /----------\ |
|---------------| |-----| TNC |----| Radio |---/
| 44.136.8.97 | and | . \-----/ \----------/
| | | sl0
| | Server | 44.136.8.5
| | | .
| | | .
| \_________/ .
--- . . . . . .
#!/bin/sh
# /etc/rc.net
# To ustawienie dostarcza jednego portu AX.25 w KISS i jednego interfejsu
# Ethernet.
echo "/etc/rc.net"
echo " Configuring:"
echo -n " loopback:"
/sbin/ifconfig lo 127.0.0.1
/sbin/route add 127.0.0.1
echo " done."
echo -n " ethernet:"
/sbin/ifconfig eth0 44.136.8.97 netmask 255.255.255.248 \
broadcast 44.136.8.103 up
/sbin/route add 44.136.8.97 eth0
/sbin/route add -net 44.136.8.96 netmask 255.255.255.248 eth0
echo " done."
echo -n " AX.25: "
kissattach -i 44.136.8.5 -m 512 /dev/ttyS1 4800
ifconfig sl0 netmask 255.255.255.0 broadcast 44.136.8.255
route add -host 44.136.8.5 sl0
route add -net 44.136.8.0 window 1024 sl0
echo -n " Netrom: "
nrattach -i 44.136.8.5 netrom
echo " Routing:"
/sbin/route add default gw 44.136.8.68 window 1024 sl0
echo " default route."
echo done.
# end
/etc/ax25/axports
# name callsign speed paclen window description
4800 VK2KTJ-0 4800 256 2 144.800 MHz
/etc/ax25/nrports
# name callsign alias paclen description
netrom VK2KTJ-9 LINUX 235 Linux Switch Port
/etc/ax25/nrbroadcast
# ax25_name min_obs def_qual worst_qual verbose
4800 1 120 10 1
W jądrze trzeba uaktywnić IP_FARWARDING.
Pliki konfiguracyjne AX.25 są mniej więcej takie same ja przykłady we wcześniejszych sekcjach, więc zajrzyj do nich gdy trzeba.
Zdecydowałem się przypisać adres IP dla portu radiowego, który nie nałeży do bloku mojej domowej sieci. Nie musiałem tak robić, można było śmiało użyć 44.136.8.97 na tym porcie.
44.136.8.68 to moja lokalna bramka do enkapsulacji IPIP, zatem tutaj kieruję ścieżkę domyślną.
Każdy komputer na sieci Ethernet ma ścieżkę:
route add -net 44.0.0.0 netmask 255.0.0.0 \
gw 44.136.8.97 window 512 mss 512 eth0
Stosowanie parametrów mss i window oznacza, że uzyskuję maksymalne osiągi zarówno na płączeniach Ethernet jak i radiowych.
- na routerze mam odpalone rzownież ftp, http, smail i inne demony więc jest on jedynym komputerem, który innym serwuje usługi - mój router to pokorne 386DX20 z 20 Mb twardego dysku i bardzo minimalną wersją linuxa.
Linux jest obecnie pospolicie używany jako bramka dla enkapsulacji TCP/IP po całym świecie. Nowy sterownik 'tunnel' obsługuje wielokrotne ścieżki enkapsulacji i sprawia, że demon ipip jest przestarzały.
Typowa konfiguracja wygłądałaby w takowy sposób:
--- .
| Network /---------\ . Network
| 154.27.3/24 | | . 44.136.16/24 \ | /
| | Linux | . \|/
| | | . |
| eth0 | IPIP | . /-----\ /----------\ |
---|---------------| |-----| TNC |----| Radio |---/
| 154.27.3.20 | Gateway | . \-----/ \----------/
| | | sl0
| | | 44.136.16.1
| | | .
| | | .
| \_________/ .
--- . . . . . .
Pliki którymi trzeba się zająć to:
# /etc/rc.net
# ustawiamy tutaj jeden port radiowy AX.25 w trybie KISS, jeden Ethernet,
# używamy sterownika 'tunnel' do IPIP encap/decapsulation
#
#
echo "/etc/rc.net"
echo " Configuring:"
#
echo -n " loopback:"
/sbin/ifconfig lo 127.0.0.1
/sbin/route add 127.0.0.1
echo " done."
#
echo -n " ethernet:"
/sbin/ifconfig eth0 154.27.3.20 netmask 255.255.255.0 \
broadcast 154.27.3.255 up
/sbin/route add 154.27.3.20 eth0
/sbin/route add -net 154.27.3.0 netmask 255.255.255.0 eth0
echo " done."
#
echo -n " AX.25: "
kissattach -i 44.136.16.1 -m 512 /dev/ttyS1 4800
/sbin/ifconfig sl0 netmask 255.255.255.0 broadcast 44.136.16.255
/sbin/route add -host 44.136.16.1 sl0
/sbin/route add -net 44.136.16.0 netmask 255.255.255.0 window 1024 sl0
#
echo -n " tunnel:"
/sbin/ifconfig tunl0 44.136.16.1 mtu 512 up
#
echo done.
#
echo -n "Routing ... "
source /etc/ipip.routes
echo done.
#
# end.
and:
# /etc/ipip.routes
# This file is generated using the munge script
#
/sbin/route add -net 44.134.8.0 netmask 255.255.255.0 tunl0 gw 134.43.26.1
/sbin/route add -net 44.34.9.0 netmask 255.255.255.0 tunl0 gw 174.84.6.17
/sbin/route add -net 44.13.28.0 netmask 255.255.255.0 tunl0 gw 212.37.126.3
...
...
...
/etc/ax25/axports
# name callsign speed paclen window description
4800 VK2KTJ-0 4800 256 2 144.800 MHz
Niektóre uwagi do zanotowania:
- Nowy sterownik 'tunnel' używa pola gw w tablicach routingowych w miejsce parametru 'pointopoint' do określenia adresu odległej bramki IPIP. Oto dlaczego obecnie obsługuje wielokrotne ścieżki na każdym interfejsie. - Można ustawić dwa interfejsy sieciowe z tym samym adresem. W tym przykładzie zarówno interfejs sl0 jak i tunl0 przyjęły adres IP portu radiowego. Czyni się tak w tym celu, aby odległa bramka widziała poprawne adresy na enkapsulo- wanych datagramach wysyłanych do niej z twojej bramki. - polecenia 'route' do określania enkapsulowanych ścieżek można wygenerować używając modyfikowanej wersji "skryptu munge". Podane jest to niżej. Polecenia route wpisane byłyby potem do osobnego pliku i czytane przez bash z /etc/ipip.routes (założywszy, że nazwałeś plik z poleceniami routingu nazwą /etc/ipip.routes) tak jak na ilustracji. Plik źródłowy musi mieć format w stylu poleceń 'route' pod NOS-em. - Zauważ stosowanie argumentu 'window' dla polecenia 'route'. Ustawienie tego parametru na właściwą wartość polepsza osiągi na łączu radiowym
Oto nowy skrypt 'tunnel-munge':
#!/bin/sh
#
# From: Ron Atkinson <n8fow@hamgate.cc.wayne.edu>
#
# This script is basically the 'munge' script written by Bdale N3EUA
# for the IPIP daemon and is modified by Ron Atkinson N8FOW. It's
# purpose is to convert a KA9Q NOS format gateways route file
# (usually called 'encap.txt') into a Linux routing table format
# for the IP tunnel driver.
#
# Usage: Gateway file on stdin, Linux route format file on stdout.
# eg. tunnel-munge < encap.txt > ampr-routes
#
# NOTE: Before you use this script be sure to check or change the
# following items:
#
# 1) Change the 'Local routes' and 'Misc user routes' sections
# to routes that apply to your own area (remove mine please!)
# 2) On the fgrep line be sure to change the IP address to YOUR
# gateway Internet address. Failure to do so will cause serious
# routing loops.
# 3) The default interface name is 'tunl0'. Make sure this is
# correct for your system.
echo "#"
echo "# IP tunnel route table built by $LOGNAME on `date`"
echo "# by tunnel-munge script v960307."
echo "#"
echo "# Local routes"
echo "route add -net 44.xxx.xxx.xxx netmask 255.mmm.mmm.mmm dev sl0"
echo "#"
echo "# Misc user routes"
echo "#"
echo "# remote routes"
fgrep encap | grep "^route" | grep -v " XXX.XXX.XXX.XXX" | \
awk '{
split($3, s, "/")
split(s[1], n,".")
if (n[1] == "") n[1]="0"
if (n[2] == "") n[2]="0"
if (n[3] == "") n[3]="0"
if (n[4] == "") n[4]="0"
if (s[2] == "1") mask="128.0.0.0"
else if (s[2] == "2") mask="192.0.0.0"
else if (s[2] == "3") mask="224.0.0.0"
else if (s[2] == "4") mask="240.0.0.0"
else if (s[2] == "5") mask="248.0.0.0"
else if (s[2] == "6") mask="252.0.0.0"
else if (s[2] == "7") mask="254.0.0.0"
else if (s[2] == "8") mask="255.0.0.0"
else if (s[2] == "9") mask="255.128.0.0"
else if (s[2] == "10") mask="255.192.0.0"
else if (s[2] == "11") mask="255.224.0.0"
else if (s[2] == "12") mask="255.240.0.0"
else if (s[2] == "13") mask="255.248.0.0"
else if (s[2] == "14") mask="255.252.0.0"
else if (s[2] == "15") mask="255.254.0.0"
else if (s[2] == "16") mask="255.255.0.0"
else if (s[2] == "17") mask="255.255.128.0"
else if (s[2] == "18") mask="255.255.192.0"
else if (s[2] == "19") mask="255.255.224.0"
else if (s[2] == "20") mask="255.255.240.0"
else if (s[2] == "21") mask="255.255.248.0"
else if (s[2] == "22") mask="255.255.252.0"
else if (s[2] == "23") mask="255.255.254.0"
else if (s[2] == "24") mask="255.255.255.0"
else if (s[2] == "25") mask="255.255.255.128"
else if (s[2] == "26") mask="255.255.255.192"
else if (s[2] == "27") mask="255.255.255.224"
else if (s[2] == "28") mask="255.255.255.240"
else if (s[2] == "29") mask="255.255.255.248"
else if (s[2] == "30") mask="255.255.255.252"
else if (s[2] == "31") mask="255.255.255.254"
else mask="255.255.255.255"
if (mask == "255.255.255.255")
printf "route add -host %s.%s.%s.%s gw %s dev tunl0\n"\
,n[1],n[2],n[3],n[4],$5
else
printf "route add -net %s.%s.%s.%s gw %s netmask %s dev tunl0\n"\
,n[1],n[2],n[3],n[4],$5,mask
}'
echo "#"
echo "# default the rest of amprnet via mirrorshades.ucsd.edu"
echo "route add -net 44.0.0.0 gw 128.54.16.18 netmask 255.0.0.0 dev tunl0"
echo "#"
echo "# the end"
Największą bodajże zaletą stosowania protokołów radioamatorskiego radia packet opartego o jądro linuxa jest łatwość, z jaką możesz pisać aplikacje i programy i je na nim używać.
Choć temat Programowania Sieci pod Unixem przekracza ramy tegoż dokumentu, to jednak opiszę tutaj elementarne szczegóły dotyczące jak wykorzystać protokoły AX.25, NetRom i Rose wewnątrz swojego oprogramowania.
Programowanie sieciowe pod Linuxem dla AX.25, NetRom i Rose przypomina programowanie dla TCP/IP. Najwięszą różnicą jest stosowana rodzina adresu i jego struktura, którą należy poprzekręcać w odpowiednie miejsce.
Nazwy rodziny adresów dla AX.25, NetRom i Rose to kolejno AF_AX25, AF_NETROM oraz AF_ROSE.
Zawsze należy dołączyć plik 'ax25.h', 'netrom.h' i rose.h' jeśli masz do czynienia z tymi protokołami. Prosty szkielet górnej części wyglądałby tak:
Dla AX.25:
#include <ax25.h>
int s, addrlen = sizeof(struct full_sockaddr_ax25);
struct full_sockaddr_ax25 sockaddr;
sockaddr.fsa_ax25.sax25_family = AF_AX25
Dla NetRom:
#include <ax25.h>
#include <netrom.h>
int s, addrlen = sizeof(struct full_sockaddr_ax25);
struct full_sockaddr_ax25 sockaddr;
sockaddr.fsa_ax25.sax25_family = AF_NETROM;
Dla Rose:
#include <ax25.h>
#include <rose.h>
int s, addrlen = sizeof(struct sockaddr_rose);
struct sockaddr_rose sockaddr;
sockaddr.srose_family = AF_ROSE;
W bibliotekach /lib/ax25.a zawartych w pakiecie progamów narzędziowych ax25-utils znajdują się wbudowane rutyny konwerujące znaki wywoławcze. Jeśli chcesz możesz napisać swoje własne.
Program narzędziowy user_call jest wyśmienitym przykładem na początek. Źródła dla tych rutyn zawarte są w pakiecie programów narzędziowych AX.25-utils. Po spędzeniu paru chwil pracując nad nimi zauważysz, że 90 procent roboty to przygotowanie otworzenia 'socket-u'. Wykonanie łączności jest łatwe podczas gdy przygotowanie zajmuje trochę czasu.
Przykłady są na tyle proste, że nie wprowadzają zamieszania. Jeśli masz jakieś pytanie to kieruj je na listę linux-hams, gdzie znajdą się ludzie gotowi udzielć ci odpowiedzi.
Jest wiele miejsc, gdzie dyskutuje się na temat Radio Amatorskiego i Linuxa, na przykład na comp.os.linux.* lub na liście pocztowej vger.rutgers.edu. Inne miejsca, gdzie się to czyni, to listy pocztowe tcp-group na ucsd.edu (ojczyzna dyskusji na temat TCP/IP i radia amatorskiego), jak również kanał #linpeople w sieci linuxnet na IRC.
Aby zapisać się na listę dyskusyjną linux-hams, wyślij pocztę do:
Majordomo@vger.rutgers.edu
z tekstem:
subscribe linux-hamsw częsci listu. Wiersz 'subject:' jest pomijany.
Archiwum listy linux-hams znajduje się na: http://zone.pspt.fi/archive/linux-hams/ oraz na http://zone.oh7rba.ampr.org/archive/linux-hams/. Staraj się zajrzeć tam zanim rozpoczniesz dyskusję ponieważ odpowiedziano tam na wiele powszechnych pytań.
Aby zapisać się na listę tcp-group, wyślij list do:
listserver@ucsd.edu
z tekstem:
subscribe tcp-group
w częsci listu.
Zauważ, że lista tcp-group jest przeznaczona głównie do dyskusji o zaawansowanych protokołach, których TCP/IP jest przykładem, w Radiu Amatorskim. Nie zadaje się tam pytań dotyczących Linuxa.
Następujące osoby przyczyniły się do stworzenia tego dokumentu na przeróżne sposoby, w sposób świadomy lub nieświadomy. Podaję ich bez szczególnego uszeregowania (tak jak pamiętam): Jonathon Naylor, Thomas Sailer, Joerg Reuter, Rot Atkinson, Alan Cox, Craig Small, John Tanner, Brandon Allbery.
AX25-HOWTO, informacja na temat jak zainstalować i ustawić niektóre z ważniejszych pakietów obsługujących AX.25 pod Linuxem.
Jest to oproramowanie darmowe; może być modyfikowane i rozprowadzane na warunkach Ogólnej Licencji Publicznej GNU opublikowanej przez
Copyright © 1996 Terry Dawson.Free Software Foundation; licencja o wersji numer 2, lub dowolnie, jakakolwiek późniejsza.
Program ten rozprowadzany jest z nadzieją, że będzie użyteczny, lecz BEZ JAKIEJKOLWIEK GWARANCJI; nawet bez gwarancji, że moze być SPRZEDAWANY lub UŻYTECZNY DLA JAKIEGOKOLWIEK CELU. Więcej szczegółów znajdzesz w Ogólnej Licencji Publicznej GNU.
Powinieneś był otrzymać egzemplarz Ogólnej Licencji Publicznej z tym programem; jeśli nie to napisz do:
Free Software Foundation, Inc., 657 Mass Ave, Cambridge, MA 02139, USA.
AX25-HOWTO - tłumaczenie na język polski. Informacja jak zainstalować i ustawić niektóre z najważniejszym pakietów do obsługi protokołu AX.25 pod Linuxem.
Copyright © 1997 Benedict P. Barszcz.
Wiele terminów, które w tym dokumencie zastosowałem może brzmieć dziwnie w uszach polskiego czytelnika. Przepraszam, wynika to z tego, że polska terminologia radia packet jest mi zupełnie nie znana. Radioamatorem zostałem tutaj w USA i polskie nazewnictwo nie było wymogiem do egzaminu. To jest błąd.
Niektórych zwrotów nie tłumaczyłem ze wzgłędow na ich ewidentność, ale na pewno w tym miejscu się grubo mylę. Inne zwroty są niezgrabne i w tym miejscu masz szerokie pole do popisu, czytelniku. Ślij poprawki do poseidon@ziplink.net. Zwroty idiomatyczne starałem się zastępować naszymi, polskimi odpowiednikami. Czasem przesadziłem, albo zupełnie minąłem się z celem:-)
Mam wrażenie, że popełniłem też błędy merytoryczne. Nie poprawiłem ich bo nie wiem gdzie:-).
Są też neologizmy, które nie zostały konsekwentnie używane w dokumencie, np. DźwiękoModem.
Fragmenty w skrypcie 'munge' nie są tlumaczone ponieważ należą do pliku i są komentarzem autora pliku.
Zmiany w stosunku do oryginału:
Port 4000 i port 3694/tcp dla node przez inetd; autor nie był konsekwentny. Wybrałem port 4000.
Odwałanie do Net-2-HOWTO zamieniłem na NET-3-HOWTO wskazując jednocześnie na jego polskie tłumaczenie. Zdaje się, że Net-2-howto już nie istnieje.
W jednym z odwołań, Terry podał tylko imię, a na innym miejscu również nawisko. Dla czytelności w pierwszym wypadku podałem zarówno imię jak i nazwisko.
kolejność komend budowy jądra poprawiona, aby faktycznie działalo tak, jak autor zamierzył. cd /usr/src postawione przed mv linux linux.old. Odciąłem też ścieżkę od nazwy pliku ax25-utils-12.tar.gz tak, aby zadziałało zgodnie z zamierzeniem autora.
Bardzo serdecznie chciałbym podziękować Terry'emu Dawson, że napisał ten dokument. Dopiero przy tłumaczeniu go, zrozumiałem jaki kawał roboty odwalił!
Chciałbym podziękować Bartkowi Maruszewskiemu, Piotrowi Tęczyńskiemu oraz Piotrowi Pogorzelskiemu za (świadomą i nie świadomą) pomoc i natchnienie, aby ten dokument powstał.
Jednocześnie chciałbym przypomnieć Waldkowi Ogonowskiemu, SP2ONG, że to on jest wszystkiemu winiem - zaraził mnie Linuxem i nie wskazał kliniki, gdzie sie to paskuctwo leczy:-).
Oraz dziękuje wszystkim, którzy nadeślą poprawki, które na pewno udoskonalą to tłumaczenie.