Az eddig tökéletesen műkődő Samba (sic! :)) elkezdett random megszakadni minden film streamelés közben többször is.
Egyedül a kábeleket cseréltem ki a hosszuk miatt (teszteltem, elvileg jók, akkor is ah Samba épp szakadásban van), ill. bekerült a hálózatba egy Wifi Ap.
Verzió: Samba 3.4.0, ubuntu server 9.10
smb.conf global része: http://pastebin.com/MfXwKbYj
Kliens: Win7 (upgraded)
A megszakadás nem olyan megszakadás, hogy teljesen elszáll a kapcsolat, hanem mintha egy delay-t rakott volna be, ami csak akkor oldódik fel, ha megnyitok egy megosztott mappát, utána folytatódik minden. A fájl másolás is rendben van, tartja az átlag 600 mbitet. A hdd-ken végig futtattam fsck-t hátha velük van baj, de nem.
Van valakinek bármi ötlete mi okozhat iylet?
- 1760 megtekintés
Hozzászólások
Ha valaki találkozott még volna ilyennel:
Talán az segített, hogy a "socket options" sort kitöröltem és marad a tiszta negotiation.
A sebességet már nem befolyásolja.
- A hozzászóláshoz be kell jelentkezni
Micsoda véletlen... Ismét rendszeresen megszűnik a kapcsolat ~óránként.
Jellemzően "nagy" igénybevételnél - pl HD stream, de ez még mindig 5-10%.
Ezuttal logok: http://pastebin.com/tJLqmmbN
Elvileg valamilyen technikai hibára utal a kliens oldalon.?
Ha a Samba kapcsolat meg is szakad, az SSH pl nem. Viszont alátámasztani látszik, hogy ajaxos lekérések is felakadnak, ha épp szakadás van.
Egyszeri eset: A napokban a gépben levő hálókártya - vagy a switch - teljesen eldobott mindent fél percre: Alert("kábel nincs bedugva").
Switch: D-LINK DGS-1005D (Nem egy szörnyeteg...)
If: Realtek RTL8168/8111 (PHY: Realtek RTL8211/8212)
Hibás RAM okozhat ilyesmiket? Figyeltem, 0 hard faults végig, de az egyik RAM-mal volt már gond másik gépben (nem hagyta bootolni), de itt semmi...
Tanácstalan vagyok.
- A hozzászóláshoz be kell jelentkezni
try this:
iptables -I INPUT 1 -p tcp --dport 445 -j DROP
(nem én mondom, google mondja)
- A hozzászóláshoz be kell jelentkezni
Ez adat port tiltásával ugyanazt érem el, mint az apt-get remove samba-val... :)
A levél írója csak PDC-nek használja, így neki valóbban nincs rá szüksége.
- A hozzászóláshoz be kell jelentkezni
- A hozzászóláshoz be kell jelentkezni
Aha, hogy ehhez be kell állítani, hogy a 139-es portot használja.
Kipróbálom. Mindenesetre itt nem XP kliensekről van szó.
Szerk.: Sajnos itt nem vállt be.
- A hozzászóláshoz be kell jelentkezni
hasonlóképpen jártam régen (bár nem periodikusan óránként), akkor a hálókártya volt a baj. kicseréltem és frankó lett. mérj egyet pl. nuttcp-vel...
- A hozzászóláshoz be kell jelentkezni
Lefuttattam párszor, számomra semmi érdekes nem derül ki belőle:
Default window size:
1002.0091 MB / 10.00 sec = 840.4621 Mbps 23 %TX 17 %RX 0 retrans 0.30 msRTT
1011.2005 MB / 10.00 sec = 848.0868 Mbps 22 %TX 17 %RX 0 retrans 0.29 msRTT
1m window size:
1099.3743 MB / 10.00 sec = 922.0376 Mbps 68 %TX 6 %RX 0 retrans 0.30 msRTT
1095.0000 MB / 10.00 sec = 918.4607 Mbps 68 %TX 5 %RX 0 retrans 0.30 msRTT
1105.2500 MB / 10.00 sec = 927.0582 Mbps 69 %TX 8 %RX 0 retrans 1.52 msRTT
Azt jó lenne valahogy kideríteni, hogy a hálókari vagy a switch ügyetlenkedik, nem szeretnék pénzt kidobni rá.
Sajnos nincs elfekvő hálókarim, se switchem. Egy 100-as routerem talán van, előkotrom.
- A hozzászóláshoz be kell jelentkezni
aham, ez jónak néz ki. folyamatosan megvan a sávszél? filmnézés közben mérés/mérés közben filmnézés= hiba jelentkezik?
- A hozzászóláshoz be kell jelentkezni
Úgy néz ki rendben. So far...
Lehet, hogy a bsh által linkelt megoldás működik.
De biztosat csak 1-2 órán belül tudok mondani. :)
- A hozzászóláshoz be kell jelentkezni
de hát ez milyen mán' eldobálni a 445-ös portra érkező kéréseket. elhiszem hogy megoldja, de ez olyan szőnyegalásöprős módszernek tűnik.
- A hozzászóláshoz be kell jelentkezni
Oké, ez 6 percig tartott...
Figyeltem a Resource Monitort, a hálózati forgalom egyik másodpercről a másikra egyszerűen nullázódik.
Kezdetnek a switch-et ki tudom kerülni, utána vagy a kliens oldali hálókártya az, vagy nem...
Szerk.: Helyettesítettem egy 100-as routerrel, folyamatos iperf mellett ~2 óra HD stream gond nélkül.
Utána vissza a G-s switchre újabb ~1-1,5 óra iperf mellett szintén gond nélkül... :D
Közben fél szemmel figyeltem a grafikonokat és akadt pár 0-ás szakadék, de a samba logban már csak egy ilyen error van, ami az kell legyen, amikor visszacseréltem a kütyüket.
Abban sem vagyok biztos, hogy valójában szoftveres vagy hardveres eredetű. Ugyanezekkel a szoftverekkel nem volt gond 1 hónappal ezelőttig. Akkor kezdőttek a gondok, amikor kipróbáltam egy WLAN kártyát, de azóta komplett reinstall volt...
Én már azt se tudom mit gondoljak...
- A hozzászóláshoz be kell jelentkezni
Szóval összegezve:
Samba config:
socket options = SO_KEEPALIVE TCP_NODELAY IPTOS_LOWDELAY IPTOS_THROUGHPUT
smb ports = 445
Lehet, hogy bölcsebb lenne a 139-es portot használni.?
Tűzfalon 137:138 UDP és 445 TCP vannak beengedve, ami a Sambát illeti.
A port megadása megszüntette a "Transport endpoint is not connected" hibákat, de ez önmagában nem ért semmit.
Továbbra is akadnak szakadások és ilyeneket generál[hat].
(Van, hogy szó nélkül hagyja és csak "closed connection to $share".):
"smbd/nttrans.c:2119(call_nt_transact_ioctl)
call_nt_transact_ioctl(0x900eb): Currently not implemented."
Viszont a fenti socket options kombinációval úgy tűnik, még abban a pillanatban sikerül a reconnect, amivel már együtt lehet élni.
Mindenesetre nem kizárt a hardveres vagy driveres/firmwares hiba se (inkább a switch részéről, mint a hálókártyákéról, ha routerrel rövid ideig, de jó volt).
Biztos sok különbség van TCP és TCP között is, de ha iperf nem akasztja ki maxra járatva, akkor ehhez képest elenyésző smb mégis, hogy?
Sidenote: Ami a periodikusságot illeti, nem óramű pontosággal óránként, hanem ~45 perces epizódonként kb 1 alkalom.
- A hozzászóláshoz be kell jelentkezni
ugyanilyen switchem van (és a gépek nagy részsében is rtl8111 van) és nincs vele gond.
- A hozzászóláshoz be kell jelentkezni
Csak egy vad tipp. Én lennék a legboldogabb, ha 100%, hogy nem ők okozzák
Nincs két egyforma rendszer, főleg nem Samba... :)
Szerk.: Újra elkezdődtek a szakadások. Szerencsére még ritkábban, mint eddig.
Már semmi nincs a logokban, csak "connection closed to service *"...
Szerk2.: Apró tech hiba volt.
Worths a shot alapon kipróbáltam cross linkkel. Ugyan az még 1 napos bármi-lehet-még-határban vagyok, de egyelőre nem sikerült kiakasztani, pedig megtettem érte mindent. Fentebb javallott port beállítást kiszedtem, Win7/Vista már alapból a 445-re kérdez, figyeltem minden bejövő kapcsolatot.
A switchnek új helye lesz távol innen, ahol nincs Samba... :)
- A hozzászóláshoz be kell jelentkezni
"socket options = SO_KEEPALIVE TCP_NODELAY IPTOS_LOWDELAY IPTOS_THROUGHPUT"
Én ezt az alábbi kombinációban használom:
socket options = TCP_NODELAY IPTOS_LOWDELAY SO_SNDBUF=65536 SO_RCVBUF=65536
- A hozzászóláshoz be kell jelentkezni
A window size eröltetésének már nem látom sok értelmét 3.4 fölött.
3.3-mal kezdtem, akkor még kellett itt is, de már működik negotiation mellett is ugyanúgy.
- A hozzászóláshoz be kell jelentkezni
tudjafene, most álltam át 3.4.7-re, nem módosítottam a konfot, ártani nem árt gondolom...
viszont ha már samba, van egy sambám, amire a testparm ezt dobja:
"rlimit_max: rlimit_max (1024) below minimum Windows limit (16384)"
gondot nem okoz, viszont zavar. ugyanezzel a konfiggal/verziókkal más gépen nincs ilyen.
- A hozzászóláshoz be kell jelentkezni
gondot nem okoz, mert csak warning, de ha zavar, miért nem oldod meg?
* - nofile 16384az /etc/security/limits.conf fájlba, reboot.
- A hozzászóláshoz be kell jelentkezni
szerinted miért nem? valszeg, mert nem találom az okát...
ja, látom leírtad... már rakom is...
de ez mit csinál, és miért? és ha nem, akkor meg hogyan? :)
--
és done, hát nagyon köszöntem szépen, már megérte megkérdezni...
--
na most beleszaladtam egy olyan esetbe, ahol a limites.conf-ba bevezetett bejegyzésre rá se bagózott. mondjuk ez egy squeeze, elképzelhető hogy itt máshol kell megadni a minimum megnyitható fájlok számát...?!
- A hozzászóláshoz be kell jelentkezni