Jakiś czas temu pisałem, że szukam rozwiązania dla pewnego problemu związanego z PPPoE. Sprawa sprowadza się do tego, że gdy zostanie zerwana sesja PPPoE (np. z powodu rozłączenia z nadajnikiem lub z powodu wyciągnięcia wtyczki sieciowej), a klient nawiąże drugie połączenie, w tablicy routingu serwera są dwie (lub więcej) trasy dotyczące tego samego "peera", np.

# ip route show
192.168.101.10 dev ppp0  proto kernel  scope link  src 192.168.101.254
192.168.101.10 dev ppp1  proto kernel  scope link  src 192.168.101.254

Stary wpis wisi dopóki koncentrator PPPoE nie zorientuje się, że link jest martwy - wtedy usuwa wpis, a net u klienta zaczyna działać. Jednakże chwilę to trwa, w zależności od konfiguracji koncentratora.

Rozwiązanie jest banalne; opierając się na powyższym przykładzie wystarczy tylko wpisać:

ip route del 192.168.101.10

No i dochodzimy do sedna. Wystarczyłoby tylko podpiąć to polecenie do pliku /etc/ppp/ip-up. Byłoby jednak zbyt pięknie, gdyby dało się to zrobić w takiej czystej postaci. Trzeba to opakować w pętlę, która usunie wszystkie zdublowane wpisy i zostawi ten jeden właściwy. Sztuczka polega na tym, że wpisy w tablicy routingu są kasowane "od góry", dzięki czemu ten ostatni jest tym działającym.

#!/bin/bash

# /etc/ppp/ip-up
# this is a script which is executed after connecting the ppp interface.
# look at man pppd for details

# the followings parameters are available:
# $1 = interface-name
# $2 = tty-device
# $3 = speed
# $4 = local-IP-address
# $5 = remote-IP-address
# $6 = ipparam

ROUTES=$(ip route|grep -w "$5"|wc -l)

while [ "$ROUTES" -gt 1 ]
do

ip route del $5

ROUTES=$(ip route|grep -w "$5"|wc -l)

done

W gruncie rzeczy to wszystko - powyższy skrypt sprawdza się doskonale na moim serwerze.

Właściwie tytuł wpisu powinien brzmieć "one session per IP", ponieważ opcja w Mikrotiku, o której wspominałem, opiera się na sprawdzaniu adresu MAC klienta, a nie jak w przypadku mojego skryptu, na adresie IP. Z tego powodu nie da się podpiąć kilku komputerów do MT poprzez AP (w trybie client), który maskuje adresy MAC (fixme?).

Powiązane wpisy:

• Serwer PPPoE na Gentoo

Żeby zainstalować sobie KDE w wersji 4 w pod Gentoo trzeba skorzystać z overlay-a o nazwie kde-crazy.

W skrócie:

• instalujemy najnowszy portage (v. 2.2)
• emerge -va layman
• w pliku /etc/make.conf dodajemy: source /usr/portage/local/layman/make.conf
• layman -a kde-crazy
• layman -S
• w pliku /etc/portage/package.keywords dodajemy listę pakietów "odmaskowanych"
• emerge -va @kdebase

Uwagi:

• lepiej sobie właczyć flagę "kdeprefix", dzięki czemu nowe KDE trafi do /usr/kde/4.2 zamiast do głównego drzewa (jeśli mamy KDE 3.5 może nam to namieszać)
• lepiej wyłączyć flagę "python" - u mnie kompilacja się wysypuje z powodu modułu "sip"
• nowe KDE jest podzielone na "sety", więc jeśli chcemy zainstalować np. całe kdegraphics to wpisujemy 'emerge -va @kdegraphics
• polski pakiet językowy nazywa się teraz "kde-l10n"

Źródło

Korzystam czasami z programu Skype i denerwująca dla mnie jest ciągła konieczność odłączania głośników i podłączania słuchawek. Wpadłem na pomysł, że skoro w Skajpie da się wybrać dedykowane urządzenie do obsługi dźwięku, to przecież mogę skorzystać z drugiej karty dźwiękowej i nie gimnastykować się za każdym razem, gdy ktoś zechce sobie ze mną pokonwersować, tym bardziej że trafienie do jednej z pięciu dziurek w słabych warunkach oświetleniowych do łatwych zadań nie należy ;)

Sytuacja u mnie (w moim kompie) wygląda tak: mam wbudowaną kartę marki nVidia,

00:04.0 Multimedia audio controller: nVidia Corporation CK804 AC'97 Audio Controller (rev a2)

którą do tej pory miałem wyłączoną w BIOS-ie, ponieważ korzystałem z innej karty na PCI

01:08.0 Multimedia audio controller: Creative Labs SB Live! EMU10k1 (rev 08)

gdyż w moim subiektywnym odczuciu ta karta generuje dźwięk lepszej jakości niż jakieś tam AC-97.

Niestety, po włączeniu karty wbudowanej automagicznie stała się ona domyślną kartą dźwiękową w systemie (snd-card-0), a założenie jest takie, że nVidia dla Skype, a Live! dla całej reszty. Trzeba to zmienić!

W tym momencie dochodzimy do pliku konfiguracyjnego '/etc/modules.d/alsa'. Jest to ten sam pliczek, w którym swoją konfigurację zapisuje narzędzie 'alsaconf'. Co ciekawe narzędzie to tak jakby nie potrafi zapisać ustawień dla dwóch kart - po prostu nadpisuje poprzednią konfigurację. Mniejsza z tym.

Googlając doszedłem do wniosku, że wystarczy poniższa konfiguracja, aby SB stał się domyślną kartą:

alias snd-card-0 snd-emu10k1
alias sound-slot-0 snd-card-0

alias snd-card-1 snd-intel8x0
alias sound-slot-1 snd-card-1

Niestety, tak się nie stało - nadal ta wbudowana miała numer 0. Okazało się, że trzeba jeszcze dodać opcję 'index':

options snd-emu10k1 index=0
options snd-intel8x0 index=1

I teraz wszystko działa tak jak chciałem - domyślną kartą (snd-card-0), do której są podłączone głośniki jest SoundBlaster, a dla Skype jest AC'97 (snd-card-1), do której są podłączone (już na stałe) słuchawki :)

Chcąc mieć dostęp do swojego komputera musimy znać jego IP. Nic trudnego. Sprawa się komplikuje, gdy dostawca przydziela nam zmienne IP - jeśli zmiana następuje raz na miesiąc to pół biedy, można raz na miesiąc wkuć/zapisać sobie to IP i po problemie. Jednak w przypadku neo zmiana następuje co 24 godziny i tutaj ten sposób jest już mało przydatny.

Co możemy zrobić?
Ano możemy napisać sobie skrypt, który będzie co jakiś czas sprawdzał czy IP uległo zmianie i jeśli tak wyśle nam sms lub e-mail. Podoba wam się ten pomysł?
To był taki żart :)

Lepszym rozwiązaniem jest skorzystanie z usługi określanej mianem Dynamic DNS, w skrócie DDNS. Sposób w jaki to działa, jest w miarę przystępnie opisany na stronie firmy Dipol, dlatego daruję sobie odkrywanie koła ;)

Tak jakoś wyszło, że posiadając neostradę używam programu ez-ipupdate - chyba dlatego, że był to pierwszy program, który mi zadziałał :)

Instalacja:

emerge -va ez-ipupdate

These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild  N    ] net-dns/ez-ipupdate-3.0.11_beta8-r1  80 kB
Total size of downloads: 80 kB

Konfiguracja:

Ez-ipupdate posiada pokaźną liczbę przykładowych plików dla różnych serwisów oferujących usługę DDNS. Najłatwiej jest przekopiować sobie przykład i zmienić w nim poszczególne opcje; przykład dla DynDNS.org:

zcat /usr/share/doc/ez-ipupdate-3.0.11_beta8-r1/example-dyndns.conf.gz > /etc/ez-ipupdate.conf 

W pliku konfiguracyjnym należy wpisać swoją nazwę użytkownika, hasło, zarezerwowaną domenę i interfejs, który ma być monitorowany.
Oczywiście wcześniej trzeba się zarejestrować w serwisie DynDNS.org i aktywować odpowiednią usługę.

Pozostaje już tylko uruchomić naszego demona:

/etc/init.d/ez-ipupdate start
 * Starting ez-ipupdate for zibik.ath.cx on ppp0 ...    [ ok ]

Poleceniem ping możemy sprawdzić czy aktualizacja się powiodła:

ping -n zibik.ath.cx
PING zibik.ath.cx (83.28.71.129) 56(84) bytes of data.
64 bytes from 83.28.71.129: icmp_seq=1 ttl=57 time=30.9 ms
64 bytes from 83.28.71.129: icmp_seq=2 ttl=57 time=47.2 ms
64 bytes from 83.28.71.129: icmp_seq=3 ttl=57 time=37.8 ms
64 bytes from 83.28.71.129: icmp_seq=4 ttl=57 time=30.2 ms

--- zibik.ath.cx ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3000ms
rtt min/avg/max/mdev = 30.210/36.575/47.278/6.855 ms

Jeśli aktualizacja adresu IP nie powiodła się warto zajrzeć do logów (/var/log/messages), żeby zobaczyć co jest nie tak.

Jeśli wszystko gra to warto sprawić, aby nasz programik uruchamiał się przy starcie:

rc-update add ez-ipupdate default

Wpis ten dedykuję wszystkim, którzy posiadają dostęp do Internetu ze zmiennym, publicznym IP i korzystają z Linuksa (tak, Przemek to do Ciebie :P )

Sterownik ntfs-3g jest wolnym, na licencji GPL, linuksowym sterownikiem NTFS trzeciej generacji dla 32-bitowych architektur little-endian, który został zaimplementowany przez projekt Linux-NTFS. Wprowadza możliwość pełnego dostępu (odczyt/zapis) NTFS, jednakże bez dostępu do szyfrowanych plików, zapisu skompresowanych plików, zmiany właściciela plików i praw dostępu.

Instalacja

Pod Gentoo instalacja jest klasyczna:

ACCEPT_KEYWORDS="~x86" emerge -va ntfs3g

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild  N    ] sys-fs/ntfs3g-1.0  550 kB

Total size of downloads: 550 kB

Would you like to merge these packages? [Yes/No]

Pakiet jako zależności wymaga podsystemu FUSE (Filesystem in User Space) dostępnego w jądrze od wersji 2.6.14:

Symbol: FUSE_FS [=m]  
  │ Prompt: Filesystem in Userspace support  
  │   Defined at fs/Kconfig:517 
  │   Location:    
  │     -> File systems  

Jeśli mamy starsze jądro lub nie włączyliśmy FUSE w jądrze przy instalacji pakietu sys-fs/fuse zostanie skompilowany moduł 'fuse.ko', jednakże wydaje mi się, że lepiej korzystać z FUSE zawartego w jądrze - chociażby dlatego, że przy aktualizacji kernela nie będzie trzeba przebudowywać tegoż modułu.

Użycie

Montowanie systemu plików NTFS nie odbiega bardzo od standardowego sposobu:

mount /dev/hda2 -t ntfs-3g /mnt/windows 

W pliku /etc/fstab wpis może wyglądać tak:

/dev/hda2     /mnt/windows     ntfs-3g     defaults     0 0 

Oprócz dostępu w trybie RW dodatkową zaletą ntfs-3g jest duża wydajność. Pobieżny test, który zrobiłem wykazał, że kopiowanie plików zamontowanych za pomocą tego sterownika jest tylko odrobinę wolniejsze niż w przypadku ext3. W porównaniu do Captive NTFS - rewelacja :)

Myślę, że można bez obaw spróbować - mi żadne dane nie wyparowały, a i w necie można znaleźć mnóstwo pozytywnych opinii.

Gdy zaczynałem pisać tę notkę moim zamierzeniem było powiedzieć wszem i wobec, że kart opartych o chipset RTL8180 (np. WL-8303) nie da się zmusić do poprawnej pracy jako AP pod kontrolą systemu Linux.

Po drodze okazało się jednak, że się myliłem - przy którejś kolejnej próbie, gdy już miałem dać sobie spokój z tym problemem okazało się, że to jednak działa! Powiem jeszcze raz: można postawić punkt dostępowy na karcie z chipsetem RTL8180 pod Linuksem!

O tym, że te karty mogą pracować w trybie master już wiedziałem - pod Windowsem jest możliwość ustawienia trybu AP korzystając z dołączonego przez producenta oprogramowania, jednak robienie tego pod wspomnianym systemem... hmm... jakoś nie widzę tego :)

Ok, wystarczy tych wstępów - bierzemy się za robotę :)

Na początek sprawdzamy, czy nasza karta jest widoczna:

lspci
00:0b.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8180L 802.11b MAC (rev 20)

Żeby uruchomić tę kartę pod linuksem najlepiej posiadać najnowsze sterowniki. Na stronie projektu można pobrać sterowniki w wersji 0.21, lecz ciut świeższe są w repozytorium CVS. Nie wiem jak działa v0.21 - ja użyłem wersji z CVS-a.

cvs -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/rtl8180-sa2400 login
cvs -z3 -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/rtl8180-sa2400 co -P rtl8180-sa2400-dev

Jeśli ktoś korzysta z Gentoo może użyć najnowszych z portage'a - wychodzi na to samo ponieważ projekt już praktycznie nie jest rozwijany i ciężko się spodziewać nowinek.

ACCEPT_KEYWORDS="~x86" emerge -va rtl8180

---

Po skompilowaniu i zainstalowaniu modułów (make, make install w przypadku źródeł ze strony/CVS) ładujemy moduł r8180.ko

modprobe -v r8180
insmod /lib/modules/2.6.15-gentoo-r1/net/ieee80211_crypt-r8180.ko
insmod /lib/modules/2.6.15-gentoo-r1/net/ieee80211-r8180.ko
insmod /lib/modules/2.6.15-gentoo-r1/net/r8180.ko

Za pomocą polecenia dmesg sprawdzamy co się stało. U mnie wypisało to, co poniżej:

dmesg
--cut--
Linux kernel driver for RTL8180 / RTL8185 based WLAN cards
Copyright (c) 2004-2005, Andrea Merello
rtl8180: Initializing module
rtl8180: Wireless extensions version 19
rtl8180: Initializing proc filesystem
rtl8180: Configuring chip resources
ACPI: PCI Interrupt 0000:00:0b.0[A] -> GSI 19 (level, low) -> IRQ 19
rtl8180: Memory mapped space @ 0xd7003000
rtl8180: Hardware frame sequence numbers disabled
rtl8180: MAC controller is a RTL8180 (v. F)
rtl8180: This is a PCI NIC
rtl8180: Reported EEPROM chip is a 93c56 (2Kbit)
rtl8180: Card MAC address is 00:40:f4:9d:9b:e1
rtl8180: EEPROM version 102
rtl8180: RfParam: 5
rtl8180: Card reports RF frontend by Philips.
rtl8180: OK! Philips SA2400 radio chipset is supported.
rtl8180: Analog PHY found
rtl8180: Energy threshold: b
rtl8180: PAPE from CONFIG2: 1
rtl8180: Antenna A is default antenna
rtl8180: Antenna diversity is disabled
rtl8180: Carrier sense 1
rtl8180: 40-bit WEP is NOT supported in hardware
rtl8180: 104-bit WEP is NOT supported in hardware
rtl8180: IRQ 19
rtl8180: Driver probe completed

Wygląda poprawnie, a polecenie ifconfig powinno nam wyświetlić nowy interfejs o nazwie wlan0.

---

Teraz konfiguracja. Ważną rzeczą jest, aby przed konfiguracją karty radiowej najpierw ją "położyć"; bez tego cały nasz misterny plan może wziąć w łeb ;)

ifconfig wlan0 down

Konfigurujemy "radio":

iwconfig wlan0 mode master	# każemy karcie pracować jako AP
iwconfig wlan0 essid MOJ.AP	# pod nazwą widoczną w eterze MOJ.AP
iwconfig wlan0 channel 9	# na kanale 9

Teraz klasycznie nadajemy adres IP i "podnosimy" interfejs:

ifconfig wlan0 192.168.200.254 up

... i w logach powinniśmy zobaczyć coś na podobieństwo:

dmesg
--cut--
rtl8180: Bringing up iface
rtl8180: Card successfully reset
rtl8180: Creating BSS on ch 9
rtl8180: Enabling beacon TX

---

Mając w drugim komputerze drugą kartę radiową próbuję się połączyć, co mi się nawet udaje, a dmesg na serwerze to potwierdza :)

--cut--
IEEE802.11: New client associated: 00:50:fc:f2:76:e9

 

Próba ostateczna - sprawdzamy działanie sieci:

ping 192.168.200.254
PING 192.168.200.254 (192.168.200.254) 56(84) bytes of data.
64 bytes from 192.168.200.254: icmp_seq=1 ttl=64 time=1.37 ms
64 bytes from 192.168.200.254: icmp_seq=2 ttl=64 time=4.40 ms
64 bytes from 192.168.200.254: icmp_seq=3 ttl=64 time=1.07 ms
64 bytes from 192.168.200.254: icmp_seq=4 ttl=64 time=1.10 ms

Hurra - działa!

Obciążyłem jeszcze na koniec nowego AP co nieco - dwóch klientów WIFI i transfer z serwera FTP maksymalną przepustowością łącza radiowego 11Mb/s (czyli w praktyce wyszło ~560KB/s).

ping 192.168.200.254
PING 192.168.200.254 (192.168.200.254) 56(84) bytes of data.
64 bytes from 192.168.200.254: icmp_seq=1 ttl=64 time=116 ms
64 bytes from 192.168.200.254: icmp_seq=2 ttl=64 time=115 ms
64 bytes from 192.168.200.254: icmp_seq=3 ttl=64 time=132 ms
64 bytes from 192.168.200.254: icmp_seq=4 ttl=64 time=134 ms
64 bytes from 192.168.200.254: icmp_seq=5 ttl=64 time=125 ms
64 bytes from 192.168.200.254: icmp_seq=6 ttl=64 time=67.4 ms
64 bytes from 192.168.200.254: icmp_seq=7 ttl=64 time=116 ms

Jak widać pingi wzrosły, ale są akceptowalne jak na łącze radiowe.

Na koniec muszę powiedzieć, że stawianie AP na tej karcie w celu udostępniania internetu innym to nie jest dobry pomysł. Na dłuższą metę ten sprzęt zachowuje się niestabilnie i potrafi się zawiesić.

Od jakiegoś czasu... eee właściwie to już nie pamiętam od kiedy, miałem problem z monitorem, a konkretnie z zarządzaniem energią. Bestia po prostu nie chciała sama się wyłączać, co powodowało, że czasem całą noc monitor się świecił jeśli zdarzyło mi się niepostrzeżenie zasnąć %-)

Wszystkiemu okazała się winna opcja "dpms", a właściwie jej brak w pliku xorg.conf. Od czasów przesiadki na X.org do konfiguracji X-ów używam polecenia xorgconfig, które nie dodaje automatycznie tej opcji w sekcji "Monitor".

Poniżej kawałek xorg.conf:

Section "Monitor"
        Identifier   "Monitor0"
        VendorName   "Monitor Vendor"
        ModelName    "Lite-On A1570NSL"
        DisplaySize  280        200
        HorizSync    30.0 - 69.0
        VertRefresh  50.0 - 160.0
        Option      "dpms"
EndSection

Teraz już jest dobrze - monitor się wyłącza i nawet robi to sam ;)

Opisów instalacji neostrady pod linuksem można w sieci znaleźć całe mnóstwo. Trochę gorzej jest jeśli chodzi o instalację tej usługi pod Gentoo - tu opisów jest o wiele mniej, tym bardziej, że od jądra w wersji 2.6.16 zmienił się sposób instalacji modemu Sagem.

Zaczynamy zabawę od konfiguracji jądra:

ATM

Networking --->
Networking options --->
[*] Asynchronous Transfer Mode (ATM)
[*] Classical IP over ATM 
[ ] LAN Emulation (LANE) support (EXPERIMENTAL)
[M] RFC1483/2684 Bridged protocols

Firmware loader

Device Drivers --->
Generic Driver Options --->
[*] Select only drivers that don't need compile-time external firmware
[*] Prevent firmware from being built
<*> Hotplug firmware loading support
[ ] Driver Core verbose debug messages

Obsługa USB (z reguły to jest już w większości jąder)

Device Drivers --->
USB support --->
[M] Support for Host-side USB
[M] EHCI HCD (USB 2.0) support
[M] OHCI HCD support
[M] UHCI HCD (most Intel and VIA) support

Obsługa modemów (w jądrze 2.6.16 obsługa modemów Sagem F@st 800 została dodana do oficjalnego wydania kernela)

USB DSL modem support --->
[M] USB DSL modem support
[M] Speedtouch USB support
[ ] Conexant AccessRunner USB support
[M] ADI 930 and eagle USB DSL modem
[ ] Other USB DSL modem support

PPP over ATM

Device Drivers --->
Network device support --->
[M] PPP (point-to-point protocol) support
[ ]PPP multilink support (EXPERIMENTAL)
[ ]PPP filtering
[*] PPP support for async serial ports
[M] PPP support for sync tty ports
[*] PPP Deflate compression
[*] PPP BSD-Compress compression
[ ] PPP MPPE compression (encryption) (EXPERIMENTAL) (NEW)
[ ] PPP over Ethernet (EXPERIMENTAL)
[*] PPP over ATM

To tyle jeśli chodzi o jądro.
Oprócz tego w systemie musimy jeszcze zainstalować (lub zaktualizować) następujące pakiety:

• baselayout (>=1.12)
• linux-atm (>=2.4.1),
  
• ppp (>=2.4.3-r15 z flagą 'atm'),
  
• ueagle-atm (>=1.1; gdy posiadamy Sagem),
  
• speedtouch-usb (>=3.0.1.2; gdy posiadamy Speedtouch)

W pliku /etc/conf.d/net trzeba dodać:

config_ppp0=( ppp ) # Runs /lib/rcscripts/net/pppd.sh
link_ppp0='/dev/null' # Not required by PPPoA links, but must be specified

plugins_ppp0=( 'pppoa 0.35' ) # Dla Neostrady VPI=0, VCI=35

pppd_ppp0=( usepeerdns updetach noauth debug defaultroute noaccomp nobsdcomp noccp
nodeflate nopcomp novj novjccomp child-timeout 60 )

username_ppp0='login@neostrada.pl' # jeśli jeszcze nie mamy to wpisujemy 'rejestracja@neostrada.pl'

password_ppp0='password' # do rejestracji hasło 'rejestracja'

# If the kernel modules are not built-in, then they must be loaded
# before starting the PPP daemon:
function preup() {
if [[ "$1" = "ppp0" ]] ; then
modprobe -q ueagle-atm # lub 'modprobe -q speedtch' jeśli mamy Thompsona
return 0
fi
}

Jeśli nie ma pliku /etc/init.d/net.ppp0 to robimy dowiązanie do net.lo

ln -s /etc/init.d/net.lo /etc/init.d/net.ppp0

ls -alh /etc/init.d/net.ppp0
lrwxrwxrwx 1 root root 18 cze 22 04:12 /etc/init.d/net.ppp0 -> /etc/init.d/net.lo

Dobrze byłoby gdyby nasz linux dostawał adresy serwerów DNS od peera. W tym celu musimy zrobić odpowiednie dowiązanie:

rm /etc/resolv.conf
ln -s /etc/ppp/resolv.conf /etc/resolv.conf

Możemy w końcu spróbować uruchomić połączenie. Upewniamy się, że dioda synchronizacji na modemie świeci się światłem ciągłym i wpisujemy:

/etc/init.d/net.ppp0 start
 * Starting ppp0
 *   Running preup function
 *   Bringing up ppp0
 *     ppp
 *       Running pppd ...
 *       ppp0 received address 83.28.2.91

I w tym momencie wszystko powinno już działać. Zauważyłem, że gdy jesteśmy w trybie rejestracji nie można zapingować żadnego hosta, lecz mimo to strona http://rejestracja.neostrada.pl w przeglądarce działa. Oczywiście po przejściu etapu rejestracji i zastąpieniu danych rejestracyjnych własnym loginem i hasłem wszystko już działa jak należy.

Po tygodniu używania neo pod linuksem doszedłem do wniosku, że dobrze zrobiłem kupując dodatkowo modem SpeedTouch. Sagem, którego dostałem od tepsy nie jest szczytem stabilności - średnio dwa razy na dobę zdarza mu się tracić połączenie z netem i muszę ręcznie go przewracać. Z Thompsonem nie ma takich jazd.

UPDATE:

Dokuczało mi to, że średnio raz na dobę połączenie z siecią umierało. Trzeba było je restartować, czasem nawet kilka razy, zanim zaskoczyło. Jednakże pewnego dnia i to przestało pomagać. Pomimo, że modem się zsynchronizował połączenia z siecią nie było. Okazało się, że z jakiegoś powodu znika urządzenie /dev/ppp i przez to demon pppd się wykrzacza. Rozwiązanie jest stosunkowo proste, chociaż może nie idealne - trzeba utworzyć ten plik ręcznie.

mknod /dev/ppp c 108 0

Najlepiej dopisać to do skryptu /etc/conf.d/net:

 function preup() {
if [[ "$1" = "ppp0" ]] ; then
mknod /dev/ppp c 108 0
modprobe -q ueagle-atm # lub 'modprobe -q speedtch' jeśli mamy Thompsona
return 0
fi
}

Po tym zabiegu zwisy neo minęły jak ręką odjął - teraz nawet zmiana IP odbywa się niezauważalne :)

(Dla tych co jeszcze nie przeszli z wersji 2.5 na 2.6)

W najpopularniejszym serwerze proxy w wersji 2.6 zmieniła się konfiguracja dotycząca tzw. "transparent proxy".

Dla przypomnienia, w wersji 2.5, żeby uzuskać przezroczyste proxy trzeba było ustawić następujące opcje:

httpd_accel_host virtual
httpd_accel_port 80
httpd_accel_with_proxy on
httpd_accel_single_host off
httpd_accel_uses_host_header on

Teraz jest o wiele prościej, zgodnie z tym co napisano w dokumentacji Squida:

httpd_accel_* for transparent proxy

Now implemented by the "transparent" http_port option

Tak więc, cała konfiguracja Squida pod kątem przezroczystości sprowadza się teraz do zrobienia w pliku squid.conf następującego wpisu, a konkretnie na dodaniu opcji 'transparent':

http_port 3128 transparent

Stare opcje httpd_accel* można spokojnie usunąć.

To wszystko - u mnie działa :)

Jeśli chcemy, aby osadzone multimedia odtwarzały się w przeglądarkach pracujących pod linuksem możemy zainstalować pakiet mplayerplug-in:

emerge -s mplayerplug-in
Searching...

*  net-www/mplayerplug-in
      Latest version available: 3.21
      Latest version installed: 3.21
      Size of files: 204 kB
      Homepage:      http://mplayerplug-in.sourceforge.net/
      Description:   mplayer plug-in for Gecko based browsers
      License:       GPL-2 

Chcąc go zainstalować (pod Gentoo oczywiście) domyślnie jako zależność jest kompilowana mozilla, jednakże lepiej tego uniknąć ustawiając flage USE="gecko-sdk", co pozwoli na zainstalowanie tylko plików nagłówkowych i niezbędnych bibliotek:

USE="gecko-sdk" emerge -va mplayerplug-in

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild   N   ] net-libs/gecko-sdk-1.7.13  USE="crypt ssl truetype -debug -gnome -ipv6 -java -ldap -mozcalendar
 -mozdevelop -moznocompose -moznoirc -moznomail -moznoxft -mozsvg -postgres -xinerama -xprint" 0 kB
[ebuild   N   ] net-www/mplayerplug-in-3.21  USE="gecko-sdk -gtk" 204 kB

Po zainstalowaniu w katalogu /usr/lib/nsbrowser/plugins/ znajdziemy zestaw wtyczek. U mnie Firefox nie chciał ich znaleźć więć zrobiłem dowiązania do nich w katalogu /opt/netscape/plugins/

Pozostaje tylko sprawdzić czy wtyczki zostały wykryte wpisując w przeglądarce 'about: plugins' i jeśli tak to możemy pójść na naszą ulubioną stronę z osadzonym plikiem multimedialnym i cieszyć się tym co użytkownicy windows mają na codzień ;)

Odtwarzanie "Trójki"

Nie polecam sprawdzać działania tego pluginu na stronie onetu - nie od dziś wiadomo, że ich pliki WMV nie chcą się odtwarzać pod linuksem. Na innych stronach ten plugin działa - również pod Operą :)

Jakiś czas temu kupiłem na aukcji modem ADSL marki BeWAN oparty na chipsecie ST70137. Niestety okazało się, że sterowniki w portage nie chcą kompilować się z jądrem >=2.6.16. Sprawdziłem w Bugzilli Gentoo i jako, że nikt jeszcze tego błędu nie zgłosił postanowiłem to zrobić. Przez pierwsze dwa dni nikt nie reagował na zgłoszony błąd, więc zacząłem się bać, że nic z tego nie będzie, ale Alin Nastac zlitował się i teraz wszystko hula :D

Pokrótce - jeśli mamy ten modem i chcemy używać go pod kontrolą jądra nowszego niż 2.6.16 musimy zainstalować pakiet 'bewan-adsl-0.9.3-r2' (lub nowszy):

emerge -va ">=net-dialup/bewan-adsl-0.9.3-r2"
These are the packages that would be merged, in order:

Calculating dependencies
... done!
[ebuild   R   ] net-dialup/bewan-adsl-0.9.3-r2  USE="-usb -kt400 -pcitimer -slowpcibridge" 0 kB

Total size of downloads: 0 kB

Would you like to merge these packages? [Yes/No] 

Modułem, który nas interesuje jest unicorn_pci_atm:

modprobe unicorn_pci_atm

I to wszystko jeśli chodzi o konfigurację. Jeżeli mielismy wcześniej uruchomioną neostradę na którymś z modemów USB to już powinno działać. W innym przypadku konfiguracja odbywa się tak samo jak w przypadku innych modemów (pisałem o tym).

Zaletą tego modemu jest to, że szybciej się synchronizuje (ok. 5 sek. (Sagem: ok. 15 sek.)). Na necie czytałem też opinie, że zachowuje się stabilniej niż te wszystkie cuda na USB.

Ciekawostka - można sobie sprawdzić status urządzenia poleceniem 'unicorn_status':

Modem State               : SHOWTIME_L0
Remote Report             : Showtime
Last Failure              :
Time Connected            : 02:07:52
Modulation                : ANSI
Rate Us/Ds (Kbps)         :  320 1312
Cap. Occupation Us/Ds (%) :   52   31
Noise Margin Us/Ds (dB)   :   21   20
Attenuation Us/Ds (dB)    :   17   34
Output Power Us/Ds (dBm)  :   12   19
FEC Errors Us/Ds          :    0    0
CRC Errors Us/Ds          :    0    1
HEC Errors Us/Ds          :    0    0
Driver Version            : 0.0.0
Firmware Version          : PCI-AML-1-0.4-0.1.0.10

Protokół PPPoE może być znakomitym rozwiązaniem w środowiskach, gdzie problem nieautoryzowanego dostępu do Internetu jest szczególnie groźny. Sieci radiowe WiFi są idealnym tego przykładem. Tam gdzie wbudowane mechanizmy zabezpieczeń stają się niewystarczające, zastosowanie PPPoE wydaje się dobrym lekarstwem. Wykorzystanie mocnego systemu uwierzytelniania (chap, ms-chap) daje wysoką gwarancję administratorowi, że osoba która w danym momencie korzysta z dostępu nie jest "obcym tworem", pragnącym za darmo korzystać z tego za co płacą inni użytkownicy. Klientowi daje natomiast pewność, że nikt obcy nie będzie w stanie podszyć się pod niego co będzie miało kolosalne znaczenie w spornych sprawach. (źródło)

Przygotowanie

Żeby uruchomić serwer PPPoE na linuksie potrzebujemy trzech rzeczy:

• kernela z obsługą PPPoE
• pakietu 'ppp'
• pakietu 'rp-pppoe'

Konfiguracja kernela jak na screenshocie (Device drivers -> Network device support -> PPP over Ethernet):

Pakiet rp-pppoe instalujemy klasycznie:

emerge -va rp-pppoe

Jako zależność zostanie zainstalowany pakiet 'ppp'; jednakże trzeba zwrócić uwagę na flagi z jakimi zostanie zainstalowany - ja użyłem:

USE="activefilter atm dhcp eap-tls" emerge -va ppp

Konfiguracja

Konfiguracja sprowadza się do edycji pliku '/etc/ppp/pppoe-server-options':

#/etc/ppp/pppoe-server-options

require-chap
ms-dns 192.168.100.254
ms-dns 194.204.152.34
mtu 1472
mru 1472
lcp-echo-interval 50
lcp-echo-failure 20 

W pliku '/etc/ppp/chap-secrets' należy skonfigurować użytkowników:

#/etc/ppp/chap-secrets

# Secrets for authentication using CHAP
# client        server  secret            IP addresses
"kate"          eth0   "kate-password"    192.168.100.10

Uruchomienie

Serwer PPPoE uruchamia się poleceniem 'pppoe-server':

pppoe-server -I eth0 -C ZibikNET -S "TEST" -L 192.168.100.254 -N 1024 -k  

gdzie:
-I - interfejs Ethernet, na którym serwer PPPoE ma nasłuchiwać ramek PADI
-C - nazwa koncentratora
-S - nazwa usługi. Pól tych może być kilka, ale pierwsze używane jest jako domyślne dla ramek PADI bez wyszczególnionej nazwy koncentratora
-L - adres IP serwera PPPoE, na którym będzie zestawiał połączenia
-N - maksymalna liczba jednoczesnych sesji PPPoE
-k - wykorzystanie sterownika jądra

Możemy uruchomić 'tail -f /var/log/messages' i przy próbie połączenia zobaczymy:

Oct 24 04:58:44 zibik pppoe-server[25762]: Session 1 created for client 00:40:f4:6e:0e:73 (10.67.15.1) on eth0 using Service-Name 'TEST'
Oct 24 04:58:44 zibik pppd[25762]: Plugin /etc/ppp/plugins/rp-pppoe.so loaded.
Oct 24 04:58:44 zibik pppd[25762]: RP-PPPoE plugin version 3.3 compiled against pppd 2.4.3
Oct 24 04:58:44 zibik pppd[25762]: pppd 2.4.3 started by root, uid 0
Oct 24 04:58:44 zibik pppd[25762]: Using interface ppp1
Oct 24 04:58:44 zibik pppd[25762]: Connect: ppp1 <--> eth0
Oct 24 04:58:46 zibik pppd[25762]: peer from calling number 00:40:F4:6E:0E:73 authorized
Oct 24 04:58:46 zibik pppd[25762]: local  IP address 192.168.100.254
Oct 24 04:58:46 zibik pppd[25762]: remote IP address 192.168.100.10 

Przy rozłączaniu:

Oct 24 05:02:19 zibik pppd[25762]: LCP terminated by peer (QM-DN^_^@
Oct 24 05:02:19 zibik pppd[25762]: Connect time 3.6 minutes.
Oct 24 05:02:19 zibik pppd[25762]: Sent 775270 bytes, received 764327 bytes.
Oct 24 05:02:20 zibik pppoe-server[25750]: Sent PADT
Oct 24 05:02:20 zibik pppd[25762]: Terminating on signal 15
Oct 24 05:02:22 zibik pppd[25762]: Connection terminated.
Oct 24 05:02:22 zibik pppd[25762]: Modem hangup
Oct 24 05:02:22 zibik pppd[25762]: Exit.
Oct 24 05:02:22 zibik pppoe-server[25750]: Session 1 closed for client 00:40:f4:6e:0e:73 (10.67.15.1) on eth0

U podłączonego klienta (pod windowsem: ipconfig /all):

Karta Ethernet Połączenie lokalne:

        Sufiks DNS konkretnego połączenia :
        Opis . . . . . . . . . . . . . . :  Karta Realtek RTL8139 Family PCI Fast Ethernet NIC
        Adres fizyczny. . . . . . . . . . : 00-40-F4-6E-0E-73
        DHCP włączone . . . . . . . . . . : Tak
        Autokonfiguracja włączona . . . . : Tak
        Adres IP. . . . . . . . . . . . . : 0.0.0.0
        Maska podsieci. . . . . . . . . . : 0.0.0.0
        Brama domyślna. . . . . . . . . . :
        Serwer DHCP . . . . . . . . . . . : 255.255.255.255

Karta PPP ZibikNet:

        Sufiks DNS konkretnego połączenia :
        Opis . . . . . . . . . . . . . . :  WAN (PPP/SLIP) Interface
        Adres fizyczny. . . . . . . . . . : 00-53-45-00-00-00
        DHCP włączone . . . . . . . . . . : Nie
        Adres IP. . . . . . . . . . . . . : 192.168.100.10
        Maska podsieci. . . . . . . . . . : 255.255.255.255
        Brama domyślna. . . . . . . . . . : 192.168.100.10
        Serwery DNS . . . . . . . . . . . : 192.168.100.254
                                            194.204.252.34
        NetBIOS przez TCP/IP. . . . . . . : Wyłączony

Uwagi

Nie udało mi się uruchomić PPPoE na pakiecie ppp-2.4.4: przy próbie podłączenia u klienta występował tajemniczy błąd 52 (zduplikowana nazwa w sieci); po wstecznej aktualizacji do wersji 2.4.3 problem zniknął.

W opisie na stronie firmy Cyberbajt jest informacja, że karta sieciowa musi mieć zdjęte IP - ja zostawiłem IP, dzięki czemu użytkownicy mogą nadal korzystać z internetu używając klasycznego połączenia ethernetowego - jest to ważne szczególnie wtedy, gdy mamy działającą sieć a chcemy stopniowo i bezszokowo wdrożyć PPPoE u klientów. Oczywiście po zakończeniu wdrożenia można, a nawet należy zdjąć IP z karty sieciowej.

Należy mieć świadomość, że zastosowanie PPPoE zabezpiecza nas jedynie przed nieautoryzowanym dostępem do sieci, cały ruch jest nieszyfrowany i można go bez większych problemów podsłuchać. Jeśli chcemy wykluczyć taką możliwość wtedy należy (można) zastosować np. tunele VPN - w tej roli doskonale sprawdza się pptpd.

Źródła:

• http://www.jtz.org.pl/Html/PPP-HOWTO.pl-11.html
• http://www.cyberbajt.pl/cyber.php?i=raport&id=50&e=1
  

Powiązane wpisy:

• One session per host

Niech mnie gęś kopnie! Przeglądając konfigurację jądra 2.6.14 znalazłem coś takiego:



No ładny postęp, ładny :) Czyżby dzięki temu dało się Neostradę odpalić na modemie USB?

Jest sobie taki programik do przedstawiania logów Squida w formie czytelnej strony HTML (przykład). W samym Squidzie trzeba wcześniej włączyć logowanie dostępu (tag: access_log). Jest to przydatne jeśli chcemy analizować ruch HTTP przechodzący przez nasze proxy.
Instalacja jest banalna - ściągamy ze strony domowej najnowszego Sarga, rozpakowujemy i

./configure --prefix=/usr #prefix jest opcjonalny
make
make install

potem

ln -s /usr/local/sarg/sarg.conf /etc/sarg.conf

ponieważ domyślnie program szuka pliku konfiguracyjnego w /etc/.
Następnie trzeba dopasować plik konfiguracyjny do swoich wymagań, czyli zdefiniować gdzie leżą logi Squida i gdzie mają być zapisywane pliki wynikowe. Poniżej opcje, które zmieniłem w pliki /etc/sarg.conf

language Polish
access_log /var/log/squid/access.log
output_dir /usr/local/sarg/reports
resolve_ip yes
useragent_log /var/log/squid/useragent.log
date_format e
overwrite_report yes

Jeśli coś jest niejasne to mogę wyjaśnić :)

Życie było by prostsze, a ja zaoszczędziłbym godzinę życia, gdyby twórcy LinuxStat-a zrobili poprawną konfigurację aliasu katalogu dla Apache'a

#Include for LinuxStat (http://lstat.sf.net)
Alias /lstat/ "/usr/local/lstat/www/"
#for execute CGI files
Options Indexes ExecCGI
AddHandler cgi-script .cgi
Order allow,deny
Allow from all
AllowOverride AuthConfig Limit

Przez godzinę zastanawiałem się dlaczego ciągle dostaję FORBIDDEN zamiast pięknych statystyk systemowych. Wszystko dlatego, że difoltowo Apache gdy nie ma regułki dotyczącej dostępu do danego zasobu zakłada, że powinien on być zabroniony.
Oryginał wyglądał tak:

#Include for LinuxStat (http://lstat.sf.net)
Alias /lstat/ "/usr/local/lstat/www/"
#for execute CGI files
Options Indexes ExecCGI
AddHandler cgi-script .cgi
AllowOverride AuthConfig Limit

Prawda? Prawda!

Dzisiaj dzień pod znakiem instalacji Linuksa na laptopie Toshiba Satellite 2060CDS. Stary to laptop, bo w środku posiada jeszcze takie zabytki jak:

• 366 MHz AMD K6-2
  
• 96 MB SDRAM
• 4 GB HDD
• 12.1" 800x600 LCD
  

Chciałem sobie ułatwić trochę życie wrzucając na niego VidaLinux i potem przerobić go na Gentoo, jako, że Vida jest dystrybucją opartą o system z rybą w logo :) Niestety jak już przebrnąłem przez instalację to okazało się, że Vida jest kompilowana pod procesory i686 i próba uruchomienia chociażby Bash'a kończyła się komunikatem "Illegal instruction" (AMD K6 należy do rodziny procesorów i586). No i musiałem odpalać jakieś livecd i robić wszystko na chroot-cie korzystając ze stage3.
Innym problemem jest to, że wiatrak w laptopie nie chce się kręcić (pod windą działa - pewnie kwestia dokonfigurowania ACPI) przez co musiałem tymczasowo dokleić zewnętrzny wiatraczek do obudowy, bo się maszyna sama wyłączała przy większym obciążeniu.

Kurde, ile krwi potrafi zepsuć jedna, mała pierdółka. Przez źle wpisaną flagę CFLAGS straciłem pół nocy na dociekanie czemu większość programów nie chce się skompilować. Problemem okazał się cholerny znak końca linii (Enter), który wcisnął się tam gdzie nie powinien.
Było:

CFLAGS="-march-k6-2 -mcpu=k6-2 -s -Os -pipe -fomit-frame-pointer
-mmmx -m3dnow"

A powinno być:

CFLAGS="-march-k6-2 -mcpu=k6-2 -s -Os -pipe -fomit-frame-pointer -mmmx -m3dnow"

Dobrze, że w końcu odkryłem ten problem, bo już zaczęły mi przelatywać przez głowę myśli o wyrzuceniu tego złoma przez okno. Niestety, to nie był jedyny problem. Do tej pory nie udało mi się uruchomić karty sieciowej na PCMCIA Xircom REM-56G. Google mówi, że to czy ona zadziała pod Linuksem to właściwie kwestia przypadku. Jednym działa, innym nie. Już nawet pokusiłem się o upgrade firmware'u na tej karcie, co jednak nie przyniosło żadnych widocznych skutków. Można powiedzieć, że działa połowicznie: przy pingowaniu wysyła pakiety w sieć, ale odebrać ich już nie potrafi.
No cóż, skoro nie działa Ethernet to może by tak uruchomić sieć po WiFi? No dobra, już wiem, że mam kartę WLAN USB na chipsecie Prism2.5 i potrzebuję do tego pakietu linux-wlan-ng. Emerguję (od polecenia emerge) linux-wlan-ng-0.2.1-pre20, pięknie się kompiluje, ale gdy próbuję załadować prism2_usb to dmesg wyrzuca "unknown symbol". Miodzio. Co jest do cholery?? Przecież na moim dużym kompie to działa! Czyżby chłopcy od kernela zdążyli coś zmajstrować od wersji 2.6.11...? (na laptopie jest już 2.6.12). Zainstaluję coś nowszego... patrzę do portage'a, a tam najnowsza wersja wlan-ng to 0.2.1-pre23... eh, najnowsza wersja na stronie to 0.2.1-pre26 z datą 25 stycznia 2005 i do tej pory nie znalazła się w portage'u... Szybcy są... :(
W końcu udało mi się odpalić tego WLAN-a używając wersji pre26 :)

UPDATED:
Coś jest nie tak z tym laptopem. Już 3 razy zaliczył "kernel panic" i to na róznych jądrach; z magicznych informacji, które wypisał przy tej okazji wynika, że to ma coś wspólnego z pamięcią wymiany. Jednak skanowanie dysku pod kątem błędnych bloków niczego nie wykazało.
Upgradowałem mu BIOS: z wersji 7.00 do 7.80 - niestety nie znalazłem żadnej listy zmian, więc nie wiem co wnosi dobrego ta aktualizacja (notabene, ta Toshiba ma najuboższy bios jaki widziałem).
Gdyby ktoś potrzebował to zamieściłem ten BIOS pod adresem: http://zibik.homelinux.org/downloads/1206cv78.exe (musiałem zarejestrować się na driverguide.com, żeby go dostać, brrrr)

UPDATED 2:
Nie wiem czy pomogła aktualizacja biosu, czy coś innego ale jak na razie działa stabilnie. W międzyczasie skompilowałem mu jajko 2.6.11 i karta sieciowa sieciowa (ten nieszczęsny Xircom) zaczęła działać. Wniosek z tego taki, że lepiej używać 2.6.11.12 niż 2.6.12.2.
Tylko to cholerne distcc nie chce teraz działać, przez co kompilacja GCC trwała ponad 12 godzin :(
Ciekaw jestem jak bardzo skompilowanie GLIBC z obsługą NPTL wpłynie na wydajność systemu....

UPDATED 3:
W międzyczasie zrobiłem test i skompilowałem GLIBC na jednym z moich "dużych" komputerów. Chciałem sprawdzić czy system będzie działał na glibc z NPTL bez obsługi linuxthreads. O dziwo, wszystko poszło bezboleśnie - spodziewałem się, że coś "wykrzaczy", a tymczasem cały system działa bez problemu. Teraz widzę, że nie było dobrym pomysłem kompilować na laptopie GLIBC zarówno z obsługą NPTL jak i linuxthreads - czas kompilacji w takim przypadku wydłuża się dwukrotnie, ponieważ najpierw jest kompilowane glibc z obsługą linuxthreads, a potem drugi raz z obsługą NPTL.
Dobrą sprawą jest również użycie flagi "userlocales". O ile dobrze wiem, powoduje ona kompilowanie lokalizacji glibc-a zdefiniowanych w /etc/locales.build, a nie wszystkich dostępnych (po co mi np. obsługa japońskiego czy chorwackiego w systemie?) Plik locales.build u mnie wygląda tak:

en_US/ISO-8859-1
en_US.UTF-8/UTF-8
pl_PL/ISO-8859-2
pl_PL.UTF-8/UTF-8

A całe polecenie do instalacji glibc tak:

USE="nptl nptlonly pic userlocales" emerge -va glibc