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

4 komentarze

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:

Dodaj komentarz
Czy urządzenie potrafiące realizować tylko funkcję NAT powinno się nazywać router? Lepszą nazwą jest np. "nater" :)
3 komentarze
Przygotowuję się do przerutowania YT na drugie łącze, jak do tej pory ustaliłem co następuje:

NetRange:   74.125.0.0 - 74.125.255.255
CIDR:       74.125.0.0/16
NetName:    GOOGLE

NetRange:   209.85.128.0 - 209.85.255.255
CIDR:       209.85.128.0/17
NetName:    GOOGLE

NetRange:   64.15.112.0 - 64.15.127.255
CIDR:       64.15.112.0/20
NetName:    YOUTUBE2

NetRange:   208.117.224.0 - 208.117.255.255
CIDR:       208.117.224.0/19
NetName:    YOUTUBE3

Dodaj komentarz

Dostałem dzisiaj wiadmość na GG - ot, kolejny "kąsek" dla naiwnych:

12397520 :: 11:35:20 / S 11:40:04
Przesyłam ci obiecany program którym za darmo doladujesz tel komórkowe! program generuje kody gsm którymi doladujesz dowolny tel za 50 zł! program znajdziesz tutaj
http://2000.cba.pl/7.exe

ps nie dawaj go nikomu!!!

Co by nikt się nie naciął, to na swoim squidzie zablokowałem domenę 2000.cba.pl.

3 komentarze

Uaktualniałem dzisiaj OpenSSH z wersji 4.3 do 4.5. Niestety po aktualizacji zaczęło dziać się źle - serwer zaczął odrzucać połączenia a w jego logach to:

Jul  7 22:27:42 mynet101 sshd[30488]: error: ssh_rsa_sign: EVP_get_digestbynid 64 failed
Jul  7 22:27:42 mynet101 sshd[30488]: fatal: mm_answer_sign: key_sign failed

Trochę pokombinowałem, a w końcu wpadłem na to, że może OpenSSL jest zbyt stary. Sprawdziłem i faktycznie - w systemie archaizm, bo jeszcze wersja 0.9.7i wisiała. Po zainstalowaniu aktualnej wersji tej biblioteki (0.9.8d) i przekompilowaniu pakietu OpenSSH wszystko zaczęło działać jak na leży.

Może komuś się to przyda :)

1 komentarz

Czasem zdarza się, że net przestaje działać, a w logach komunikat 'ip_conntrack: table full, dropping packet'. Wtedy przydaje się to:

echo "2400" > /proc/sys/net/ipv4/tcp_keepalive_time
echo "30" > /proc/sys/net/ipv4/tcp_fin_timeout
echo "60" > /proc/sys/net/ipv4/netfilter/ip_conntrack_generic_timeout
echo "20" > /proc/sys/net/ipv4/netfilter/ip_conntrack_icmp_timeout
echo "60" > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_close_wait
echo "1" > /proc/sys/net/ipv4/igmp_max_memberships
echo "0" > /proc/sys/net/ipv4/tcp_window_scaling
echo "0" > /proc/sys/net/ipv4/tcp_sack
echo "32768-64000" > /proc/sys/net/ipv4/ip_local_port_range
echo "43200" > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_established
echo "5" > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_close
echo "20" > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_fin_wait
echo "30" > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_last_ack
echo "20480" > /proc/sys/net/ipv4/ip_conntrack_max
echo "10240" > /proc/sys/net/ipv4/netfilter/ip_conntrack_max
echo "40" > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_time_wait
echo "30" > /proc/sys/net/ipv4/netfilter/ip_conntrack_udp_timeout
echo "180" > /proc/sys/net/ipv4/netfilter/ip_conntrack_udp_timeout_stream
echo "20" > /proc/sys/net/ipv4/ipfrag_time
echo "1280" > /proc/sys/net/ipv4/tcp_max_syn_backlog 
1 komentarz

W sumie nic nowego w powyższym stwierdzeniu, ale dzisiaj zmieniłem Neostradę na w/w usługę. I co? Ano pingi do wszelkich hostów na świecie wzrosły o ok. 20 ms w porównaniu do neo. Dla przykładu: średni ping do onet.pl wcześniej wynosił ok. 19 ms; teraz na DSL:

ping -n onet.pl -c 4
PING onet.pl (213.180.130.200) 56(84) bytes of data.
64 bytes from 213.180.130.200: icmp_seq=1 ttl=58 time=39.2 ms
64 bytes from 213.180.130.200: icmp_seq=2 ttl=58 time=38.2 ms
64 bytes from 213.180.130.200: icmp_seq=3 ttl=58 time=38.9 ms
64 bytes from 213.180.130.200: icmp_seq=4 ttl=58 time=45.2 ms

--- onet.pl ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3002ms
rtt min/avg/max/mdev = 38.254/40.433/45.223/2.793 ms

Program mtr pokazuje, że największe opóźnienia są między moim "modemem" a pierwszym routerem, tzw. brzegowym:

MTR

I co mam zrobić? Chyba pozostaje mi tylko liczyć, że kiedyś nastąpi poprawa, bo nie sądzę, żeby mi przyjęli reklamację :|

I pomyśleć, że w Krakowie (gdzie adminuję) pingi do onet.pl są takie...

ping -n onet.pl -c 4
PING onet.pl (213.180.130.200) 56(84) bytes of data.
64 bytes from 213.180.130.200: icmp_seq=1 ttl=59 time=2.23 ms
64 bytes from 213.180.130.200: icmp_seq=2 ttl=59 time=2.79 ms
64 bytes from 213.180.130.200: icmp_seq=3 ttl=59 time=2.73 ms
64 bytes from 213.180.130.200: icmp_seq=4 ttl=59 time=2.19 ms

--- onet.pl ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3001ms
rtt min/avg/max/mdev = 2.190/2.736/3.730/0.622 ms

Tam dostawcą nie jest TP... :)

8 komentarzy

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 )

4 komentarze
RTL8180Gdy 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ć.

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

2 komentarze

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

Dodaj komentarz

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

konfiguracja kernela


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:

Powiązane wpisy:

8 komentarzy

Może się przydać... (źródło)

Zatrzymaj serwer MySQL:

# /etc/init.d/mysql stop

Uruchom ponownie serwer bez uprawnień użytkownika:

# safe_mysqld --skip-grant-tables &

Połącz się z bazą MySQL jako root bez hasła:

# mysql -u root mysql

W konsoli MySQL wpisz:

mysql> UPDATE user SET password=PASSWORD(’nowe_haslo’)
WHERE User="root" AND Host="localhost";
mysql> FLUSH PRIVILEGES;

Wyloguj się:

mysql> \q

Zrestartuj serwer MySQL:

# killall mysqld
# /etc/init.d/mysql start
1 komentarz

Jakiś czas temu zdarzyło się, że tepsański serwer DNS (194.204.152.34) miał kryzys - tłumaczenie zapytań potrafiło trwać nawet kilka sekund. Jako, że duża część userów w sieci miała go wpisanego w konfiguracji, zaczęły się lamenty, że "sieć powoli chodzi". Taka sytuacja wynikła z tego, że:

a) sieć nie korzysta z DHCP
b) przy instalacji internetu u klienta został wpisany w konfiguracji sieci taki DNS
lub
c) klient sam sobie zmienił, bo przecież jajko mądrzejsze jest od kury :/

Pomyślałem, że można tak zrobić, aby wszystkie zapytania DNS przechodziły przez lokalny serwer nazw (w tej roli dnsmasq), korzystając z prostego przekierowania dostępnego w iptables:

iptables -t nat -A PREROUTING -p tcp -s 192.168.100.0/24 --dport 53 -j REDIRECT --to-port 53 
iptables -t nat -A PREROUTING -p udp -s 192.168.100.0/24 --dport 53 -j REDIRECT --to-port 53

Oczywiście nie ma sensu przekierowywać, gdy pytanie jest bezpośrednio do lokalnego DNS-a:

iptables -t nat -A PREROUTING -p tcp -s 192.168.100.0/24 -d ! 192.168.100.254 --dport 53 -j REDIRECT --to-port 53 
iptables -t nat -A PREROUTING -p udp -s 192.168.100.0/24 -d ! 192.168.100.254 --dport 53 -j REDIRECT --to-port 53

Zalety

  • uodparniamy sieć na tak newralgiczną usługę, jaką jest tłumaczenie nazw domenowych. W sytuacji, gdy któryś serwer "globalny" nawala, wystarczy przekonfigurować dnsmasq (co jest w tym przypadku banalne) i wszystko wraca do normy (w opisywanej sytuacji skorzystałem z serwerów TELE2 - 213.173.209.70 i 71)
  • przyspieszamy działanie sieci poprzez "caching DNS"
  • chronimy serwery globalne przed ewentualnym atakiem DoS przeprowadzanym z naszej sieci - wszystkie zapytania zrealizuje nasz serwer korzystając z cache'u (chyba, że nie da rady ;)

Wady

  • może zdarzyć się, że któryś z naszych "juserów" będzie jednak chciał korzystać z jakiegoś dedykowanego mu serwera DNS - wtedy niestety trzeba zróżnicować te regułki i zrobić tak aby jego zapytania nie były przekierowywane.
  • nie jestem pewien czy przekierowywanie ruchu z danego portu na ten sam port nie rodzi jakichś komplikacji (pętla?) - jednak podany przykład działa i nie zauważyłem niczego niezwykłego.
Dodaj komentarz

Jakiś czas temu pisałem o tym, jak można uprzykrzyć życie użytkownikom w sieci. Dzisiaj to zrobiłem - oczywiście tylko dla treningu i sprawdzenia jak działa - nie jestem aż tak wrednym adminem ;)

Jako, że na oryginalnej stronie jest kilka błędów/niedopowiedzeń zamieszczę swoją wersję.

Potrzebujemy:

  • działającego squida (najlepiej przezroczystego)
  • działający serwer WWW (w tym przypadku Apache)
  • pakiet ImageMagick
  • Perla (to chyba ma każda dystrybucja)

W pliku /etc/squid/squid.conf dopisujemy:

acl blurImage url_regex ^http://.*.jpg
acl blurImage url_regex ^http://.*.gif
redirector_access deny !blurImage
redirector_bypass on
redirect_program /usr/local/squid/bin/image_rewrite

Następnie tworzymy skrypt perlowy (tutaj: /usr/local/squid/bin/image_rewrite), a w nim:

#!/usr/bin/perl
$|=1;
$count = 0;
$pid = $$;
while (<>) {
chomp $_;
if ($_ =~ /(.*\.jpg)/i) {
$url = $1;
system("/usr/bin/wget", "-q", "-O", "/var/www/localhost/htdocs/images/$pid-$count.jpg", "$url");

system("/usr/bin/mogrify", "-blur", "-10", "-flip", "/var/www/localhost/htdocs/images/$pid-$count.jpg");
system("/usr/bin/chmod", "644", "/var/www/localhost/htdocs/images/$pid-$count.jpg");
print "http://192.168.100.254/images/$pid-$count.jpg\n";
}
elsif ($_ =~ /(.*\.gif)/i) {
$url = $1;
system("/usr/bin/wget", "-q", "-O", "/var/www/localhost/htdocs/images/$pid-$count.gif", "$url");
system("/usr/bin/mogrify", "-blur", "-10", "-flip", "/var/www/localhost/htdocs/images/$pid-$count.gif");
system("/usr/bin/chmod", "644", "/var/www/localhost/htdocs/images/$pid-$count.gif");
print "http://192.168.100.254/images/$pid-$count.gif\n";

}
else {
print "$_\n";;
}
$count++;
}

Ciąg 'http://192.168.100.254/images/...' należy zamienić na adres naszego działającego serwera WWW.

I w wielkim skrócie mamy już efekt :)

Flip and blur

Mniej więcej to wszystko - chcąc, aby to było zrobione maksymalnie dobrze trzeba by dorobić jeszcze obsługę plików PNG i zadbać o automatyczne usuwanie plików z katalogu /images/ - są używane tylko raz a z czasem mogą zająć sporo miejsca na dysku.

Dodaj komentarz

Moje mini-projekty

Miniblog

Halo Granie - wypitalać z tym

Orange włączył mi "halo granie" - czyli zastąpił standardowy sygnał oczekiwania na połączenie jakąś muzyczką... Co to, k... ma być? Czy ja prosiłem o to? Czy mądrym głowom w pomarańczy wydaje się, że każdy user POP-a to pryszczate dziecko, którego podniecają takie bajery?

Na szczęście da się to wyłączyć - trzeba zadzwonić na *3333, posłuchać lektora, a potem nacisnąć odpowiedni klawisz (na tę chwilę 4).

2 komentarze

Kolczyki

Uważam, że ci rodzice, którzy swoim dzieciom w wieku niemowlęcym przebijają uszy pod kolczyki, mają coś nie tak z głową.

12 komentarzy

LibreOffice beta2

Odnoszę wrażenie, że LibreOffice 3.3.0-beta2 uruchamia się jakby szybciej niż beta1 (od 3.2.1 również szybciej)

Dodaj komentarz

Ohoho

Też uważam, że "Biblię" "spisał jakiś napruty winem i palący jakieś zioła". Mimo dużych starań ze strony KK w jej ulepszaniu (w przeszłości, nie teraz) to jednak nadal zawiera wiele niespójności.

Czy niezawodny pan Nowak też mnie pozwie?

23 komentarze

Wyszukiwarka

Linki

Ja na blip.pl

Powered by Jogger.PL and Tarski · Ported by alberht