Ostatnio szukałem dobrej karty do laptopa. Dobrej, czyli spełniającej poniższe wymagania:

• złącze karty Mini Card (PCI-E Mini)
• obsługa kanałów 1-13 w trybie B/G
• obsługa zakresów indoor i outdoor w przypadku zakresu 5GHz
• obsługa standardu N jako dodatkowy atut

Do tej pory w moim netbooku MSI U100 miałem kartę fabryczną RTL8187SE, która nie dość, że nie obsługuje częstotliwości 5 GHz to dodatkowo nie widzi AP-ków pracujących na kanale wyższym niż 11 (nieszczęsne US-domain).

Poszukiwania przyniosły skutek - w jednym serwisowanym lapku, który trafił do mnie do naprawy zauważyłem kartę, która w menadżerze urządzeń przedstawiała się jako "Intel Link 5100 AGN". Mały test wykazał, że jest to karta jakiej szukam :)

Za 40 zł (z przesyłką) kupiłem używkę na allegro i nie muszę już pamiętać o tym, by mieć zawsze ze sobą dodatkowo kartę na USB.

Linki:

• strona produktu
• specyfikacja karty (product brief)

Jako, że adminuję małą siecią radiową, a nie lubię dowiadywać się o padzie któregoś nadajnika od jej użytkowników, wpadłem na pomysł, żeby do monitorowania i sygnalizacji wykorzystać serwerowy głośniczek, co jest dla mnie optymalnym rozwiązaniem, biorąc pod uwagę, że serwer stoi w zasięgu słuchu. Zresztą, zawsze można sobie głośnik podprowadzić kablem...
Skrypt można w łatwy sposób dostosować do tego, aby wykonywał inną akcję, np. wysyłał maile lub sms-y.

Do działania wymaga zainstalowanego programu fping i beep - do zdobycia w większości dystrybucji :)

Skrypt jaki jest każdy widzi, może komuś się przyda :)

#!/bin/bash
 
# Skrypt do monitorowania dostępności hosta w sieci w oparciu o PING (program fping) i sygnalizowania tego - w tym przypadku przez PC speaker.
# Uruchamia się go przez podanie właściwych zmiennych, np. ADRES1="192.168.100.132" INTERVAL_IF_ALIVE="30" DESC="MT2-most5G"  BEEP_PARAM="-r 4 -l 10" /etc/livecheck.sh
 
# zmienne:
#  ADRES1: adres sprawdzanego hosta
#  ADRES2: adres drugiego sprawdzanego hosta, z powyższym tworza parę -  skrypt "zabipa", gdy obydwa hosty nie odpowiedzą na ping
#  DESC: przyjazny opis, jeśli brak to w logu zostanie zapisany adres ADRES1
#  INTERVAL_IF_ALIVE: czas pomiędzy sprawdzeniami, jeśli ostatnie sprawdzenie dało wynik pozytywny
#  INTERVAL_IF_DEAD: czas pomiędzy sprawdzeniami, jeśli ostatnie sprawdzenie dało wynik negatywny (unreachable)
#  FPING_PARAM: parametry jakie można przekazać do programu fping, np. można wydłużyć czas sprawdzania poprzez FPING_PARAM="-t 5000"
#  BEEP_PARAM: parametry jakie można przekazać do programu beep, np. w celu zróznicowania wydawanych dzwięków.
#  LOG: plik, do którego są logowane "pady"
 
# ścieżka do programów na wszelki wypadek
PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/opt/bin" 
TAG_SENT_LOG="0"	# zmienna do ustalenia czy log został wcześniej zapisany
 
 
#sekcja sprawdzania zmiennych
if [ -x $ADRES1 ] 
then
ADRES1="127.0.0.1"
fi
 
if [ -x $ADRES1 ] && [ -x $ADRES2 ]
then
CASE="single"
else
CASE="double"
fi
 
if [ -x $DESC ]
then
DESC=$ADRES1
fi
 
 
if [ -x $LOG ]
then
LOG="/var/log/livecheck.log"
fi
 
if [ -x $INTERVAL_IF_ALIVE ]
then
INTERVAL_IF_ALIVE="300"
fi
 
if [ -x $INTERVAL_IF_DEAD ]
then
INTERVAL_IF_DEAD="10"
fi
 
# sekcja funkcji
dead() {
	if [ $TAG_SENT_LOG -eq 0 ]
	then 
	DATE="`date +%X\,\ %d\ %b`"
	echo "host nie odpowiedział - zaznaczono w logu"
	echo -e "$DATE: DEAD  - $DESC" >> $LOG	
	TAG_SENT_LOG="1"
	fi
INTERVAL=$INTERVAL_IF_DEAD
beep $BEEP_PARAM
 
return $INTERVAL
}
 
alive() {
	if [ $TAG_SENT_LOG -eq 1 ]
	then
	DATE="`date +%X\,\ %d\ %b`"
	echo "host odpowiedział - zaznaczono w logu"
	echo -e "$DATE: ALIVE - $DESC" >> $LOG
	TAG_SENT_LOG="0"
	fi
INTERVAL=$INTERVAL_IF_ALIVE
 
return $INTERVAL
}
 
case "$CASE" in
 
single)		# sekcja sprawdzania pojedynczego hosta
while true 	# nieskończona pętla
do
 
fping $ADRES1 $FPING_PARAM	 # fping działa w ten sposób, że wysyła ping do hosta; zwraca status wyjścia 0 przy pierwszej pozytywnej odpowiedzi. Jeśli host jest niedostępny, to robi 3 próby i zwraca status wyjścia 1
 
if [ $? -gt 0 ]		# sprawdzenie stanu wyjścia pinga
then
	dead	# wywołanie funkcji dead()
else
	alive	# wywołanie funkcji alive()
fi
 
sleep $INTERVAL
 
 
done
 
;;
 
double)		# sekcja sprawdzania dwóch hostów;  skrypt "zabipa", gdy obydwa hosty nie odpowiedzą na ping
while true 	# nieskończona pętla
do
 
fping $ADRES1 $FPING_PARAM
ADRES1_STATUS=$?
 
fping $ADRES2 $FPING_PARAM
ADRES2_STATUS=$?
 
if [ $ADRES1_STATUS -gt 0 ] && [ $ADRES2_STATUS -gt 0 ]
then
	dead	# wywołanie funkcji dead()
else
	alive	# wywołanie funkcji alive()
fi
 
sleep $INTERVAL
 
done
 
;;
esac
 
 

Przykład logów:

serwer ~ # tail -n 4 /var/log/livecheck.log
12:10:04, 18 kwi: DEAD  - MT1-most5G
12:12:14, 18 kwi: ALIVE - MT1-most5G
19:57:33, 18 kwi: DEAD  - MT2-most5G
20:05:26, 18 kwi: ALIVE - MT2-most5G

Przyszło mi dzisiaj zrobić konfigurację tak, aby linki mailto: pod Operą otwierały się w usłudze pocztowej Gmail, analogicznie do efektu jaki można uzyskać pod Firefoksem.

Sprawa jest stosunkowo prosta:

Zaznaczamy "Otwórz za pomocą innej aplikacji", jako program wybieramy Operę, a jako parametr podajemy adres do Gmaila:
https://mail.google.com/mail/?view=cm&fs=1&fm=0&source=mailto&to=%t&su=%s&cc=%c&bcc=%b

To wszystko, powinno działać.

Dwa słowa jeszcze o argumentach w adresie:

• %t - adres odbiorcy
• %s - temat wiadomości
• fm=[0,1] - definiuje czy ma się ładować cała strona gmaila, czy tylko ramka z tworzonym e-mailem.

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

Swego czasu mój ulubiony serwis z filtrami do rozszerzenia Adblock (niecko.pl) przestał działać i musiałem wziąć sprawy w swoje ręce.

Ale o co chodzi?
Adblock jest rozszerzeniem (dodatkiem) do przeglądarek internetowych blokującym określone elementy stron (grafiki, animacje flash, ale także np. iframe-y, div-y), których nie chcemy oglądać. Najpopularniejszym zastosowaniem Adblocka jest blokowanie wszechobecnych i natrętnych reklam. Każdego chyba irytują banery we flashu, które zasłaniają pół ekranu i zmuszają do poszukiwania mało widocznego "iksa", który czasami pozwala nam zamknąć to natręctwo.

Co trzeba zrobić, aby zablokować niechciane reklamy?
1. Zainstalować przeglądarkę Firefox (lub Mozilla SeaMonkey)
2. Zainstalować rozszerzenie Adblock Plus
3. Zasubskrybować filtry (metoda polecana ze względu na automatyczną aktualizację filtrów)

Filtry w wersji "surowej": dla twardzieli

Zachęcam do używania; filtry te są ukierunkowane głównie na polskie strony, ale dużą część reklam z zagranicznych stron też powinny wychwycić.
Co prawda niecko.pl znowu działa, ale uważam, że moje filtry są lepsze - bardziej aktualne i ciągle aktualizowane :)
Wszelkie uwagi mile widziane - szczególnie błędy i propozycje.

Powiązane wpisy:

• Firefox z Adblockiem

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 :)

11 marca pojawiła się nowa wersja ReactOS-a, stanowiącego system operacyjny równoważny dla systemów z rodziny MS Windows i w założeniach umożliwiający korzystanie z aplikacji i sterowników stworzonych dla systemu z Redmond.
Więcej...

Niestety wciąż jeszcze trochę mu brakuje, aby zacząć używać tego systemu na co dzień - np. brakuje obsługi dźwięku, brak wsparcia dla USB, ale widać, że twórcy wciąż pracują na jego rozwojem.

Myślę, że byłoby wspaniale, gdyby nie mogąc sobie pozwolić na Linuksa (np. ZUS-owski Płatnik) móc zainstalować na komputerze ReactOS-a - zamiast drogiego, zasobożernego i dziurawego systemu spod znaku okien.

Zapraszam do zapoznania się i testowania :)

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 :)

Bardzo przydatnym rozszerzeniem dla Firefoksa, z którego korzystam jest Link Alert. Jest malutkie (61KB) i jego działanie polega na detekcji celu po najechaniu myszą na link i wyświetleniu obok kursora myszy odpowiedniej ikonki. Szczególnie przydatne w przypadku linków target="_blank" i wskazujących na pliki PDF.

Rozszerzenie można zainstalować z Mozilla Addons.

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ą :)

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