Eurotel CDMA: nahla smrt spojeni

[websevak na gmail.com]

Vazeni,

resim problem s Eurotel CDMA pod Linuxem. Modem je pripojen pres USB na
Linuxovy firewall (NAT). Za firewallem mam domaci sit (2 az 3 pocitace
Win, Linux). Nekdy se stava, ze spojeni drzi dost dlouho. Dost casto
vsak se spojeni udrzi jen okolo jedne minuty a musim to stale znovu a
znovu nahazovat. Kdyz modem provozuji pod Win, spojeni je stabilni.

Zjistil jsem, ze casto tesne pred tim, nez to spadne, mam v logu toto:

pppd[1896]: rcvd [LCP ConfReq id=0x6 <asyncmap 0x0> <auth chap MD5>
<magic 0xc99526c6> <pcomp> <accomp>]
pppd[1896]: Connect time 0.7 minutes.

Jindy jen toto:

pppd[1896]: rcvd [LCP TermReq id=0x4]
pppd[1896]: LCP terminated by peer

Nejakym zazrakem jsem se dnes dostal na archiv teto konference, kde
jsem nasel thread "CDMA: PPP connection restart on unexpeted peer LCP
reconfiguration request". Zde Tomas Sieger refereje o podobnem
problemu. Na jeho dotaz odpovedel Vladimir Dvorak, z odpovedi cituji:

"Rad se s vami podelim o svou zkusenost s restartovanim tohoto velice
'kvalitniho' pripojeni. Mam doma malou sit, ktera je pripojena pres
maskaradu do Internetu. NAT resi muj linuxovy pocitac, za nim pak je
heterogenni sit (XP, FreeBSD, W98). Pokud z nejakeho duvodu spojeni na
routeru prerusim a znovunahodim, rozebehne se po kratke dobe zajimavy
cyklus restartovani pripojeni, ktery trva a trva.
Behem analyzy jsem si uvedomil, ze vlastne za NATem jsou stanice, ktere
maji jiz sestavene nejake TCP spojeni a tudiz se snazi do Internetu
propasovat sve treba keep-alive pakety. Tyto ovsem muj NAT neprelozi
(protoze po nove nastartovanem spojeni dostal jinou IP adresu a nezna
pro tuto IP stavy ) a posle je eurotelackemu routeru se zdrojovou
adresou me vnitrni site. To se ET nelibi a posle mi "LCP
reconfiguration
request". Ty stanice o teto situaci nevedi, ktera se deje mezi mym
firewallem a Eurotelem, a vesele dorazeji ACKy do Internetu. A toto je
duvod toho loopu restarovani pripojeni.
Muj workaround je takovy, ze vymazu ip_conntrack stavovou tabulku."

Po precteni tohoto prispevku jsem mel velke nadeje, jenze moje znalosti
sitoveho administratorstvi byly prilis chabe a neprisel jsem na to, jak
konkretne tento workaround realizovat. Tak jsem cetl dal. V dalsi
zprave se Jirka Kosina vyjadril takto:

"Male upresneni - ten reconfiguration request pochazi od toho CDMA
smejdu^W
modemu - on si sam pamatuje jaka IP adresa byla pridelena aktualnimu
spojeni, a pokud zjisti, ze na nej z pocitace dorazil packet se spatnou
zdrojovou IP adresou, tak zahaji proces rekonfigurace a ziskavani nove
IP
adresy."

(Sice nechapu, proc zahajenim rekonfigurace dochazi k preruseni
spojeni, ale to neni dulezite, pokud prijdu na to, jak zabranit
neustale vypadavani spojeni.) V tuto chvili jsem si byl temer jist, ze
panove Dvorak a Kosina popisuji presne muj problem. Jirka se podelil o
nasledujici reseni:

"Ja jsem tenhle problem resil tak ze jsem si do 'up' skriptu pro ppp0
dal
pravidlo, ktere v odchozich chainech zakazalo packety ktere nemaji
spravnou zdrojovou IP adresu."

Jal jsem se tedy podle tohoto vzoru upravit 'up' skript. Protoze
pouzivam debian vlozil jsem do adresare /etc/ppp/ip-up.d soubor s
nasledujicim obsahem:

#!/bin/sh
/sbin/iptables -F OUTPUT
/sbin/iptables -A OUTPUT -o ppp0 -s \! $PPP_LOCAL -j DROP

Chtel jsem se vas zkusenejsich zeptat, co si o tom myslite. Predem
dekuji.

Nathan Cutler