angyalz

Épp most, anonymus írta:

Elhiszem hogy zavar, de nincs külön céges fw mindenki ezt kapja. Kisebb nagyobb eltérések vannak max a hardver verziók közti fw-ben de azok Docsis oldali dolgok ink.

Nem másik FW-t várok, hanem egy működő eszközt. Bármilyet. (Új bekötésnél már belengették, hogy D-Link eszközt kapunk, de a jelenlegi cseréje nem megoldható... :-/ )

1 perce, acel írta:

Talán előbb utóbb megoldják (2év elég rövid idő). Gondolom a hiba valamelyik felhasznált komponenesben van nem a sagem írja  a  hálózati szoftvert , ezért a hosszadalmas javítás. Ha jól nézem talán a motorolla vagy surfboard eszközöknek vannak hasonló problémáik (teksavvy fórum stb).

Igen, 2 év elég rövid idő, de nem az IT szegmensben szerintem. A termékek jelentős részének lassan ennyi az életciklusa. És mindenkitől elnézést, de őszintén szólva céges tarifával számlázott előfizetés mellett pont nem érdekel, hogy miért nem működik a router alapvető szolgáltatásainak a fele. Tényleg elnézést, de ma pont megint nagyon tele a puttony ezzel a guánóval.

Csak egy kiemelt példa: ha nem alap szinten áll a tűzfal biztonsági szintje (hanem közép vagy magasabb), akkor miért blokkolja a portforward-ban beállított portok forgalmát? Eleve meg sem jelenik az engedélyezett szolgáltatások között, bár ez önmagában nem zavarna. Ha engedélyezem az "IP elárasztás észlelése", vagy a "Töredezett IP csomagok blokkolása" funkciót, akkor az Alma gépek net nélkül maradnak (bár a Win gépek is instabilak lesznek, egyedül a linux marad életben)

Ekkor: 2017. 05. 21. at 12:30, tsilver írta:

Kicserélték a Cisco routeremet egy ilyenre, Képtelen vagyok wifin összelőni vele a B110-es HP nyomtatómat. webes felületen néha látja és szkennel is de a osx már csak ritkán találja meg.Ha látja akkor elindul a szkennelés utána eldobja a kapcsolatot, innentől csak minden gép újrainditásával tudom néha rávenni hogy lássa megint. nyomtatni egyáltalán nem hajlandó. Ciscoval jól ment minden. tűzfal alacsonyba kapcsolva.

windows gépről sem látni

Valami ötlet?

Szokj hozzá. Ez egy feature ebben a routerben.

És még egy apróság (ami nem tudom miért csak most esik le): a leszakadós hiba ma is, tegnap is többször előfordult, de mai és tegnapi bejegyzés pl egyáltalán nincs a log-ban.

Na 11-es sor tartalmát ezentúl jobban figyelem, vadászom. Nem perverzióm, hogy a log-ot turkáljam naphosszat, de párszor már ránéztem. Úgy emlékszem, hogy ez a bejegyzés mindig benne van, de egynél többször szerintem sosem láttam. 

@anonymus Valóban elég szemléletes és meggyőző érvelés... 

8 perce, acel írta:

11-re azt mondanám ez a hiba, ha többször lenne. Eldobja a kapcsolatot mert nem kompatibilis a a másik féltől kapott dhcp megújitási adattal. Talán nem sikerült megegyezni az ipari cím megtartásáról.

Na most inkább csak hangosan gondolkodok: az "idő nem jegyzett" kezdetű bejegyzés azért lehet nagyon csodás, mert így akár az is könnyen előfordulhat, hogy két azonos hiba nem kerül be egynél többször a naplóba, avagy felülíródik. Vajon az létezhet?

De ha már újra ide tévedtem: 

Kedves Adminok!

Mikorra várható már a beharangozott, megváltó frissítés? Lassan megőrülök tőle, hogy a wifi részlegen dhcp-vel csatlakozó eszközök kapcsolata látszólag megmarad, valójában bizonyos portokon megszakad a kapcsolat, másokon továbbra is élő marad (pl netrádió / SSH / VNC tovább szól / él, böngészés leakad, oldalt nem jeleníti meg, űrlapot nem küldi el, máskor meg pont fordítva; esetleg netrádió megszakad, majd újra megszólal pár perc után). A hiba meglehetősen random jelentkezik, de pl a böngészés kizárólag a hálózatról lecsatlakozás és újracsatlakozás esetén áll helyre. Ez a hiba napjában többször jelentkezik minden dhcp eszközön. A másik tipikus hiba, hogy a 2,4GHz és 5GHz hálózat eszközei néha látják egymást, néha nem. Tipikusan ilyenkor a 2,4GHz hálózat eszközei látják a LAN-on található (kábeles kapcsolatú) eszközöket, az 5GHz-en kapcsolódók a LAN-t sem.

Hibanapló folyton rogyásig, de hajlamosak belőle elpárologni a bejegyzések.

Konfigot érdemes menteni, mert az egyik Sagem (több is van nálunk) egyszer már megszívatott vele, hogy resetelte magát, elfelejtett mindent.

Kiegészítés: a hálózatról való random leszakadás egyébként produkálható LAN kapcsolattal, fix IP-vel is. DVR rendszeresen, periodikusan eldobja a streamet (ilyenkor maga az eszköz is hálózati hibát jelez és jegyez), de ebben az esetben a kapcsolat pár másodperc-fél perc után helyreáll — úgy egy percre, majd elölről kezdődik... Még mielőtt kérdés lenne belőle: ugyanez a DVR ugyanezzel a konfiggal más routeren ilyen hibát sosem produkál(t). (Volt/van lehetőségem összehasonlítani, négyféle környezetben tudom cserélgetni és tesztelni az eszközöket). Az viszont tény, hogy a LAN-on, fix IP-vel csatlakozó eszközök kapcsolata lényegesen stabilabb, mint a DHCP-vel WIFI-n csatlakozóké.

51 perce, anonymus írta:

Én ilyet akkor láttam, amikor a szolgáltató (T) eszközei térdeltek le a Démász félnapos áramszünete után (amit véletlenül a beharangozott időpont előtt egy nappal sikerült produkálni). Jót vitáztunk a hibabejelentővel, de sehogy sem látta be, hogy ez bizony nem eszközhiba (azaz nem a Sagemcom hibája), hanem csoportos hiba lesz. Az is lett. 

Akkor nyúljék meg a nyakam, ami a vak fejem tartja, valamint köszönet!

(mondjuk ritka b*zi helyen van)

Még egy javaslat ezúton a fejlesztőnek, ha szabad Tisztelt Teszter Urakon keresztül: ha újraindítás menüpontot lennének szívesek létrehozni, mint a routerek többségében ez fellelhető – talán nem ok nélkül... Kicsit elmebaj, hogy távolról nem megoldható, pedig sokszor orvosolná a problémámat.

Nem idegesítene annyira, ha nem NAV-os kassza készletkezelése menne róla. Ha nincs net, nincs értékesítés.

A külön pw miatt az ötletgazdával leülnék egy baráti csevelyre... Csak mert nem nagyon láttam, hogy bármi utalna rá.

Böngészés / kapcsolat: korábban említettem (akkor tévesen DNS hibára gyanakodva), hogy időnként egy-két (gyanúsan csakWiFi-n kapcsolódó eszközöket érintve) egyszerűen megszűnik a böngészés lehetősége, nem talál meg semmit, nem létesít új kapcsolatot. Csakhogy egy ilyen esetben arra figyeltem fel, hogy egy lokális SSH és egy távoli VNC mindezek mellett működő maradt. A random kapcsolatmentesség viszont szinte kötelezően felüti a fejét (legalábbis nálunk), ha a teljesen lebutított (minden pipa kivéve, tűzfal szintje alap) állapotától bármilyen módon eltérek. A wi-fi kapcsolat azonban látszólag minden esetben megmarad, csak éppen böngészni, új kapcsolatot létesíteni nem lehet.

Az hogyan lehetséges, hogy belső IP-ről vidáman belépek az eszközbe, külső elérés esetén pedig hibás felhasználónév/jelszóra hivatkozva nem enged be? Természetesen engedélyeztem a menüben, természetesen https, természetesen tudom a jelszót. 

Korábbi panaszomhoz, miszerint egyes eszközökön random nincs net (hogy melyik eszközökön, az is véletlenszerű) annyi a kiegészítés, hogy a probléma fokozódik, ha a tűzfalon nincs minden kikapcsolva, és nem a legalacsonyabb fokozatban van.

Jogos felvetés, meg is dőlt az elméletem (közben más ponton is). IP alapján sem működik, miközben pl domain alapján felépített VNC és SSH kapcsolat továbbra is működik. Akkor nem tudom... Ettől függetlenül a probléma többszöri újraindítás után is fennáll.

Akkor még egy észrevétel, hátha közelebb jutunk a megoldáshoz: nálunk az a móka, hogy a net (pontosabban a böngészés) látszólag random megszűnik egyes gépeken, másokon elérhető marad. Igyekszem figyelni az okokat és az összefüggéseket, amik alapján nekem úgy tűnik, hogy a sagemcom DNS kezelése a ludas. Most pl a saját gépemen nem érek el böngészőből semmit, míg más, szintén wifin, dhcp-vel kapcsolódó gépeken viszont minden működik; ezzel párhuzamosan VNC, SSH, SFTP és társai működnek a saját eszközömön.

Tesztelő Urak! 

Azt én is kénytelen vagyok aláírni, hogy ha a sagemcom-hoz egy nem PC eszköz (esetemben DVR) statikus IP-vel kapcsolódik, akkor bizonyos, egyelőre szabályszerűséget nem mutató időközönként vagy fagy, vagy a béka *****e alá esik a net sebessége. (Az utóbbi egyelőre többször fordult elő). Tudományos T "szakember" volt már kint (sajnos éppen a távollétemben), és nemes egyszerűséggel kiiktatta a DVR-t, és közölte, hogy az *****. Nem, nem volt az, mitöbb más környezetben hibátlan, ahogyan az a sagemcom másik, de azonos típusú DVR-rel (fix IP-vel) ugyanígy reagál. (Az IP res problémáit szintén tapasztaltam, de mire leírtam volna, addigra itt is pont olvastam...) 

update: másik egységünkben egy másik sagemcom az ottani DVR-rel, szintén fix IP-vel semmilyen hibát sem produkál. Fw azonos.

Portforwardokat beállítottad ezen a routeren is?

Akkor békés nyugalomban bizakodunk.

19 órája, root írta:

1.5 a CUPS verzió. Felejtsd el. A büdös életben nem fog működni. Minimum 2 es cups kellene és akkor menne hplip nélkül is. vegyél printservert:  http://www.jofogas.hu/budapest/Linksys_Wpsm54G_EU_Print_server_elado___nyomtato_szerver__50768643.htm?first=1

Egyszer azért szeretném megérteni, hogy a fejlesztőnek mi jár a fejében, amikor kitalálja, hogy Print Server, de ezer éves szoftververzióval. Ha pedig tudja, hogy ez nem nagyon fog menni, akkor meg minek hagyja benne a menüt? Úgyis csak cseszegetni fogják a nem működő szolgáltatás miatt. Kár érte, mert egyébként *****i jó ötletnek tűnt. De attól tartok, hogy a mostani állapotnál egy integető Micimackóval is többre mennénk. 

Köszi, bár pont hasonlót (szintén Linksys) akartam kiváltani ezzel, mert a HP egy hisztis dög, és lényegében csak a saját nyelvét beszéli – illetve CUPS világban még egészen vállalhatóan működik.

Urak! 

A Print Server funkció működött már valaha valakinek? Ha igen, akkor hogyan sikerült rávenni? 

Az általam használni kívánt nyomtatót (HP Laserjet Professional m1132 MFP) legalább ismeri, de nyomtatnia sosem sikerült, hibával leáll ("/apps/usr/local/lib/cups/filter/pstoraster failed")

Mondjuk nem csoda, mert akár a saját listájából próbálok drivert választani, akár megszülöm nagy nehézségek árán az általa igényelt .ppd fájlt, még mindig üzenet marad a végén: requires proprietary plugin

CUPS leírásokban megtalálom, hogy hplip telepítése után minden zökkenőmentes, de itt olyat ugye nem lehet – ahogy CUPS frissítés sem lehetséges.

Bárkinek bármi ötlete, vagy tesztelő Urak esetleg jeleznék a dolgot T. Fejlesztő Uraknak?

Köszönettel!