OSX hálózati probléma

Fórumok

Egy érdekes hálózati problémával szembesülünk egy ideje a cégnél.

A hiba csak OSX-en jön elő több kollégánál random és csak reboot oldja meg.

Amikor a hiba jelentkezik a hálózati forgalom bizonytalanná válik, 8.8.8.8-at pingelve 2-3 timeout van, a többi ping hasonlóan jó mint a nem érintett klienseknél. Belső hálót hiba nélkül pingeli.

A következőeket állapítottuk meg eddig:
- Nem függ a hálózati kapcsolat típusától (Wifi, Ethernet, TB2Ethernet egyaránt érintett)
- Linux, Windows kliensek nem érintettek
- Routert lecseréltük Ciscoról egy Ubiquity ER-POE-re
- Nem függ az OSX verziótól (High Sierra 10.13.3, Captainen)
- Nem függ az Apple gépek típusától mind MBP-ken mind iMAC-eken előfordul.
- Mindenki használ Parallelst, amit a hibakeresésnél kikapcsoltunk
- Olyan klienseken is jelentkezik ahol nincs semmilyen antivírus/security megoldás az OSX-re telepítve (kvázi szűz rendszer)
- A 8.8.8.8 ping teszt alatt tudok packet capturet végezni a routeren, ahol az összes kérés válasz megjelenik, azonban Wiresharkkal OSX-en már nem látszanak a csomagok.
- Ha fennáll a hiba csak full reboot oldja meg
- Mobil géppel rendelkező kliensek arról számolnak be, hogy más hálózatokban a hiba nem jelentkezik.

Bármilyen ötletet szívesen fogadok!

Hozzászólások

Van-e fent olyan program, ami a hálózati beállításokat (akár ideiglenesen is) de módosítja? Pl VPN.
Illetve DHCP-vel kapják-e a beállításokat vagy fix IP?

A Google DNS ICMP echo-reply időnkénti kimaradásán kívül mi a konkrét probléma?

Sosem használtam még Parallelst, de ha ő a fő gyanúsított, akkor elképzelhető, hogy a virtuális interface-ek IP tartományai ütköznek azzal, amiből a router oszt DHCP-vel. Ezt alátámasztani látszik, hogy leírásod alapján csak ebben a specifikus hálózatban jelentkezik a hiba. Egy ifconfig -a outputot megnéznék.

Nekem erős a gyanúm, hogy a Parallels lesz ott a ludas. Mit jelent, hogy tesztelés alatt a Parallelst kikapcsoltátok? Mert mégha guest nem is fut, a Parallels kernel kiegészítői igenis futnak.
Kicsit beletúrtam a Parallels fórumaiba, és ott panaszkodnak ilyen jellegű problémára.
Nálunk sok Mac van a cégben és semmiféle ilyen hálózati problémát nem tapasztaltunk. Főleg MBP-k és Air laptopok vannak, de Mac mini is fut. Viszont Parallelst egyik gépen sem használunk.

--
Kinek nem inge, ne vegye gatyára

Sajnos a Parallels meg szükséges a munkájukhoz, konkrétan majdnem mindent a virtuális Windowson végeznek. Állítólag azt próbálták már állítani, hogy natoljon vagy bridgeljen de az sem segített.

Majd lehet futunk egy kört, hogy kiderüljön mennyire használható a VBox OSX-en aztán teszt jelleggel egy gépet migrálunk.

Ha már a Parallels-re terelődött a gyanú, leírok egy VMware jelenséget macOS alatt:

- Fut egy Windows-os VM.
- Meg van osztva az internet, iPhone felé USB/lighting csatlakozón keresztül.

Ha kihúzom, vagy csatlakoztatom az iPhone kábelt, a Windows VM elveszti egy időre az internet kapcsolatot. De van, hogy vissza sem áll a kapcsolat, hiába futtatom a Windows hálózat javító/megújító funkcióját. Ha android is/vagy van csatlakoztatva, és azt húzom ki, vagy csatlakoztatom USB-n, ugyan ez történik.

Ilyenkor MAC reboot, de rájöttem arra, hogy az is elég neki, hogy hibernálom a Windows VM-et, majd újraindítom a VMware Fusiont. Pontosabban az ikonjával elérhető részét.

A Fusionben a network interfacenél mi van beállítva? Ezzel próbálj meg játszani, mert amikor eltűnik a device, akkor teljesen logikus hogy eltűnik a bridge, ez által pedig a network a vm-ben. Talán valamelyik beállítás megoldja ezt, Pl. ha autodetecten volt, akkor fixáld "iPhone USB"-re, és viszont.

Ha nem kell a vm-nek fizikai L2 hozzáférés, akkor próbáld meg a "share with my mac" opciót.

Ha azzal sem jó, akkor el kell könyvelni sajnos, hogy ez ilyen, úgy látszik nem szereti a fusion ha eltűnik/visszajön a fizikai interface alatta, amihez a bridget vagy a nat-ot rendeli. Ez esetben esetleg reportolhatod a bugot a VMwarenek, hátha.

Köszönöm, ezeket már végigpróbáltam. Az a valószínű amit írtál, hogy a nem szereti a Fusion, ha eltűnik alóla akár csak egy pillanatra is a device. Ez akkor bosszantó különösen, amikor több órás olyan feladatot kap a virtuális gép amihez kell a kapcsolat és megszakad a folyamat, pl. network error, vagy timeout üzenettel. Ilyenkor lehet kezdeni előröl.