MERAKI - osiwieje przez nie.

Wszystko co się wiąże z technologiami bezprzewodowymi
ODPOWIEDZ
Wiadomość
Autor
Kyniu
wannabe
wannabe
Posty: 3595
Rejestracja: 04 lis 2006, 16:23
Kontakt:
Skontaktuj się z Kyniu

MERAKI - osiwieje przez nie.

#1

#1 Post autor: Kyniu »

Dwa AP - oba taki sam model MR12. Konfiguracja identyczna, oba w tej samej lokalizacji.

AP1:

Obrazek

AP2:

Obrazek

AP1 bez problemu przyjmuje informacje o VLANie, AP2 ma głęboko w d.... że ma statycznie narzucony VLAN. Oba wpięte w ten sam switch, oba mają konfigurację sieci "z palca", oba wręcz identyczną, różnią się adresem IP.

Ktoś ma jakieś sugestie?
Na górę
Kyniu
wannabe
wannabe
Posty: 3595
Rejestracja: 04 lis 2006, 16:23
Kontakt:
Skontaktuj się z Kyniu

#2

#2 Post autor: Kyniu »

Cóż, wychodzi na to, że MERAKI MR12 != MERAKI MR12.

Zrestartowałem AP do ustawień fabrycznych, podłączyłem się do jego domyślnej sieci WiFi którą rozgłasza przy braku konfiguracji, wszedłem w zakładkę konfiguracji i niespodzianka, w tym egzemplarzu nie ma opcji ustawienia VLAN'u:

Obrazek

Czyli nowszy MR12 nie jest tym samym co starszy MR12 ;(
Na górę
meeple
member
member
Posty: 28
Rejestracja: 27 mar 2012, 09:19

#3

#3 Post autor: meeple »

czy ten MR gdzieś wcześniej pracował?
może ma na sobie jakiś stary firmware?
Na górę
Kyniu
wannabe
wannabe
Posty: 3595
Rejestracja: 04 lis 2006, 16:23
Kontakt:
Skontaktuj się z Kyniu

#4

#4 Post autor: Kyniu »

meeple pisze:czy ten MR gdzieś wcześniej pracował?
NIE.
meeple pisze:może ma na sobie jakiś stary firmware?
Po 24h kiedy to miał komunikację z kontrolerem i raportuje w dashboardzie, że jest "up to date", zakładam że powinien mieć aktualny. Inna sprawa że mam wątpliwości co i jak jest aktualizowane ale o tym za chwilę.
Na górę
Kyniu
wannabe
wannabe
Posty: 3595
Rejestracja: 04 lis 2006, 16:23
Kontakt:
Skontaktuj się z Kyniu

#5

#5 Post autor: Kyniu »

Z bezsilności postanowiłem zabrać się za ten co działa, przywróciłem go do ustawień fabrycznych, połączyłem się z nim i tak wygląda jego konfiguracja:

Obrazek

Rzuca się w oczy obecność pola na wpisanie VLAN ID ale jak widać samo okno wygląda inaczej. Słowem są to nie tylko fizycznie inne urządzenia, mają też inne oprogramowanie.

Oj Meraki, Meraki, ...... Mimo pierwszego pozytywnego wrażenia mam coraz gorsze zdanie o tym produkcie.
Na górę
meeple
member
member
Posty: 28
Rejestracja: 27 mar 2012, 09:19

#6

#6 Post autor: meeple »

Kyniu pisze:
meeple pisze:czy ten MR gdzieś wcześniej pracował?
NIE.
meeple pisze:Po 24h kiedy to miał komunikację z kontrolerem.
Czyli jednak pracował ;-) i firmware powinien być aktualny. W takim razie ciekawostka.
Proponuję zgłosić to jako case. Ciekaw jestem co odpowiedzą :-)
Na górę
Kyniu
wannabe
wannabe
Posty: 3595
Rejestracja: 04 lis 2006, 16:23
Kontakt:
Skontaktuj się z Kyniu

#7

#7 Post autor: Kyniu »

meeple pisze:Czyli jednak pracował ;-) i firmware powinien być aktualny. W takim razie ciekawostka.
Przez "wcześniej pracował" rozumiem, że był dodany w innej sieci. A taka sytuacja nie miała miejsca. Jest to o tyle istotne, że AP dodaje się do zasobów firmy i pobiera przypisaną do niego licencję.
meeple pisze:Proponuję zgłosić to jako case. Ciekaw jestem co odpowiedzą :-)
Na razie to mam z nim jeszcze inny problem we współpracy z Makiem Mini. Skończę wszystkie testy to się zastanowię czy zawracać sobie tym głowę czy uznać za kolejny ślepy zaułek w jakie Cisco czasem zagląda (a potem sprząta jak było z zakupem a potem sprzedażą Linksys'a).
Na górę
Kyniu
wannabe
wannabe
Posty: 3595
Rejestracja: 04 lis 2006, 16:23
Kontakt:
Skontaktuj się z Kyniu

#8

#8 Post autor: Kyniu »

Wspominałem o jeszcze jednym problemie z MERAKI - poniżej opis.

Na początek kilka testów. Acha, dla jasności, 172.21.1.1 to router - AP ma adres 172.21.1.15 jak widać z poprzednich screnów.

Komputer HP ProBook, system Linux Mint:

Kod: Zaznacz cały

kyniu@HP ~ $ ping 172.21.1.1
PING 172.21.1.1 (172.21.1.1) 56(84) bytes of data.
64 bytes from 172.21.1.1: icmp_seq=1 ttl=64 time=1.01 ms
64 bytes from 172.21.1.1: icmp_seq=2 ttl=64 time=1.79 ms
64 bytes from 172.21.1.1: icmp_seq=3 ttl=64 time=0.964 ms
64 bytes from 172.21.1.1: icmp_seq=4 ttl=64 time=3.97 ms
64 bytes from 172.21.1.1: icmp_seq=5 ttl=64 time=0.960 ms
64 bytes from 172.21.1.1: icmp_seq=6 ttl=64 time=2.15 ms
64 bytes from 172.21.1.1: icmp_seq=7 ttl=64 time=0.922 ms
64 bytes from 172.21.1.1: icmp_seq=8 ttl=64 time=3.12 ms
64 bytes from 172.21.1.1: icmp_seq=9 ttl=64 time=7.51 ms
64 bytes from 172.21.1.1: icmp_seq=10 ttl=64 time=1.78 ms
64 bytes from 172.21.1.1: icmp_seq=11 ttl=64 time=0.941 ms
64 bytes from 172.21.1.1: icmp_seq=12 ttl=64 time=1.83 ms
64 bytes from 172.21.1.1: icmp_seq=13 ttl=64 time=4.70 ms
64 bytes from 172.21.1.1: icmp_seq=14 ttl=64 time=1.80 ms
64 bytes from 172.21.1.1: icmp_seq=15 ttl=64 time=373 ms
64 bytes from 172.21.1.1: icmp_seq=16 ttl=64 time=218 ms
64 bytes from 172.21.1.1: icmp_seq=17 ttl=64 time=1.95 ms
64 bytes from 172.21.1.1: icmp_seq=18 ttl=64 time=1.98 ms
64 bytes from 172.21.1.1: icmp_seq=19 ttl=64 time=1.86 ms
64 bytes from 172.21.1.1: icmp_seq=20 ttl=64 time=1.93 ms
64 bytes from 172.21.1.1: icmp_seq=21 ttl=64 time=1.85 ms
64 bytes from 172.21.1.1: icmp_seq=22 ttl=64 time=1.75 ms
64 bytes from 172.21.1.1: icmp_seq=23 ttl=64 time=1.79 ms
64 bytes from 172.21.1.1: icmp_seq=24 ttl=64 time=1.75 ms
64 bytes from 172.21.1.1: icmp_seq=25 ttl=64 time=1.76 ms
64 bytes from 172.21.1.1: icmp_seq=26 ttl=64 time=2.29 ms
64 bytes from 172.21.1.1: icmp_seq=27 ttl=64 time=1.97 ms
64 bytes from 172.21.1.1: icmp_seq=28 ttl=64 time=1.79 ms
64 bytes from 172.21.1.1: icmp_seq=29 ttl=64 time=1.76 ms
64 bytes from 172.21.1.1: icmp_seq=30 ttl=64 time=1.78 ms
^C
--- 172.21.1.1 ping statistics ---
30 packets transmitted, 30 received, 0% packet loss, time 29045ms
rtt min/avg/max/mdev = 0.922/21.717/373.574/75.982 ms
MAX RTT 373.574

Komputer HP ProBook, system Windows 7:

Kod: Zaznacz cały

C:\windows\system32>ping -n 30 172.21.1.1

Badanie 172.21.1.1 z 32 bajtami danych:
Odpowiedü z 172.21.1.1: bajtów=32 czas=3ms TTL=64
Odpowiedü z 172.21.1.1: bajtów=32 czas=1ms TTL=64
Odpowiedü z 172.21.1.1: bajtów=32 czas=1ms TTL=64
Odpowiedü z 172.21.1.1: bajtów=32 czas=1ms TTL=64
Odpowiedü z 172.21.1.1: bajtów=32 czas=1ms TTL=64
Odpowiedü z 172.21.1.1: bajtów=32 czas=1ms TTL=64
Odpowiedü z 172.21.1.1: bajtów=32 czas=1ms TTL=64
Odpowiedü z 172.21.1.1: bajtów=32 czas=4ms TTL=64
Odpowiedü z 172.21.1.1: bajtów=32 czas=1ms TTL=64
Odpowiedü z 172.21.1.1: bajtów=32 czas=1ms TTL=64
Odpowiedü z 172.21.1.1: bajtów=32 czas=1ms TTL=64
Odpowiedü z 172.21.1.1: bajtów=32 czas=1ms TTL=64
Odpowiedü z 172.21.1.1: bajtów=32 czas=1ms TTL=64
Odpowiedü z 172.21.1.1: bajtów=32 czas=1ms TTL=64
Odpowiedü z 172.21.1.1: bajtów=32 czas=1ms TTL=64
Odpowiedü z 172.21.1.1: bajtów=32 czas=1ms TTL=64
Odpowiedü z 172.21.1.1: bajtów=32 czas=1ms TTL=64
Odpowiedü z 172.21.1.1: bajtów=32 czas=1ms TTL=64
Odpowiedü z 172.21.1.1: bajtów=32 czas=1ms TTL=64
Odpowiedü z 172.21.1.1: bajtów=32 czas=1ms TTL=64
Odpowiedü z 172.21.1.1: bajtów=32 czas=1ms TTL=64
Odpowiedü z 172.21.1.1: bajtów=32 czas=1ms TTL=64
Odpowiedü z 172.21.1.1: bajtów=32 czas=1ms TTL=64
Odpowiedü z 172.21.1.1: bajtów=32 czas=1ms TTL=64
Odpowiedü z 172.21.1.1: bajtów=32 czas=1ms TTL=64
Odpowiedü z 172.21.1.1: bajtów=32 czas=1ms TTL=64
Odpowiedü z 172.21.1.1: bajtów=32 czas=4ms TTL=64
Odpowiedü z 172.21.1.1: bajtów=32 czas=1ms TTL=64
Odpowiedü z 172.21.1.1: bajtów=32 czas=1ms TTL=64
Odpowiedü z 172.21.1.1: bajtów=32 czas=1ms TTL=64

Statystyka badania ping dla 172.21.1.1:
    Pakiety: Wys≥ane = 30, Odebrane = 30, Utracone = 0
             (0% straty),
Szacunkowy czas błądzenia pakietów w millisekundach:
    Minimum = 1 ms, Maksimum = 4 ms, Czas średni = 1 ms
Tu jest wzorcowo.

Ale czas na gwóźdź programu - MacMini z OS X 10.9.2

Kod: Zaznacz cały

$ ping 172.21.1.1
PING 172.21.1.1 (172.21.1.1): 56 data bytes
64 bytes from 172.21.1.1: icmp_seq=0 ttl=64 time=26.549 ms
64 bytes from 172.21.1.1: icmp_seq=1 ttl=64 time=101.595 ms
64 bytes from 172.21.1.1: icmp_seq=2 ttl=64 time=247.235 ms
64 bytes from 172.21.1.1: icmp_seq=3 ttl=64 time=55.527 ms
64 bytes from 172.21.1.1: icmp_seq=4 ttl=64 time=88.836 ms
64 bytes from 172.21.1.1: icmp_seq=5 ttl=64 time=8.982 ms
64 bytes from 172.21.1.1: icmp_seq=6 ttl=64 time=217.456 ms
64 bytes from 172.21.1.1: icmp_seq=7 ttl=64 time=151.000 ms
64 bytes from 172.21.1.1: icmp_seq=8 ttl=64 time=59.608 ms
64 bytes from 172.21.1.1: icmp_seq=9 ttl=64 time=3.677 ms
64 bytes from 172.21.1.1: icmp_seq=10 ttl=64 time=2.960 ms
64 bytes from 172.21.1.1: icmp_seq=11 ttl=64 time=3.813 ms
64 bytes from 172.21.1.1: icmp_seq=12 ttl=64 time=3.951 ms
64 bytes from 172.21.1.1: icmp_seq=13 ttl=64 time=4.784 ms
64 bytes from 172.21.1.1: icmp_seq=14 ttl=64 time=14.710 ms
64 bytes from 172.21.1.1: icmp_seq=15 ttl=64 time=27.371 ms
64 bytes from 172.21.1.1: icmp_seq=16 ttl=64 time=142.390 ms
64 bytes from 172.21.1.1: icmp_seq=17 ttl=64 time=62.867 ms
64 bytes from 172.21.1.1: icmp_seq=18 ttl=64 time=85.783 ms
64 bytes from 172.21.1.1: icmp_seq=19 ttl=64 time=1.272 ms
64 bytes from 172.21.1.1: icmp_seq=20 ttl=64 time=30.893 ms
64 bytes from 172.21.1.1: icmp_seq=21 ttl=64 time=64.500 ms
64 bytes from 172.21.1.1: icmp_seq=22 ttl=64 time=89.203 ms
64 bytes from 172.21.1.1: icmp_seq=23 ttl=64 time=1.004 ms
64 bytes from 172.21.1.1: icmp_seq=24 ttl=64 time=125.898 ms
64 bytes from 172.21.1.1: icmp_seq=25 ttl=64 time=65.949 ms
64 bytes from 172.21.1.1: icmp_seq=26 ttl=64 time=88.959 ms
64 bytes from 172.21.1.1: icmp_seq=27 ttl=64 time=92.345 ms
64 bytes from 172.21.1.1: icmp_seq=28 ttl=64 time=3.573 ms
64 bytes from 172.21.1.1: icmp_seq=29 ttl=64 time=36.923 ms
64 bytes from 172.21.1.1: icmp_seq=30 ttl=64 time=162.950 ms
^C
--- 172.21.1.1 ping statistics ---
31 packets transmitted, 31 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 1.004/66.857/247.235/64.397 ms
Tu już jest tragedia - nie idzie pracować. A przy dłuższym teście ginie całkiem sporo pakietów.

Słowem Windows 7 działa jak ta lala, przy 500 pakietach zero straconych, czas średni 3 ms, maksymalny 23 ms. Linux jako tako daje radę ale też nie jest różowo. Widać wyraźny regres w stosunku do Windows 7. I Mac Mini - właściwie można powiedzieć, że nie działa (na innj próbce round-trip min/avg/max/stddev = 1.114/92.528/2695.725/173.184 ms).

Jeszcze na wypadek gdyby ktoś uznał że Mac ma ogólnie problemy z obsługą sieci albo router nie daje rady - po kabelku wynik jest taki:

Kod: Zaznacz cały

$ ping 172.21.1.1
PING 172.21.1.1 (172.21.1.1): 56 data bytes
64 bytes from 172.21.1.1: icmp_seq=0 ttl=64 time=0.460 ms
64 bytes from 172.21.1.1: icmp_seq=1 ttl=64 time=0.509 ms
64 bytes from 172.21.1.1: icmp_seq=2 ttl=64 time=0.618 ms
64 bytes from 172.21.1.1: icmp_seq=3 ttl=64 time=0.641 ms
64 bytes from 172.21.1.1: icmp_seq=4 ttl=64 time=0.483 ms
64 bytes from 172.21.1.1: icmp_seq=5 ttl=64 time=0.509 ms
64 bytes from 172.21.1.1: icmp_seq=6 ttl=64 time=0.470 ms
64 bytes from 172.21.1.1: icmp_seq=7 ttl=64 time=0.525 ms
64 bytes from 172.21.1.1: icmp_seq=8 ttl=64 time=0.558 ms
64 bytes from 172.21.1.1: icmp_seq=9 ttl=64 time=0.472 ms
64 bytes from 172.21.1.1: icmp_seq=10 ttl=64 time=0.574 ms
64 bytes from 172.21.1.1: icmp_seq=11 ttl=64 time=0.565 ms
64 bytes from 172.21.1.1: icmp_seq=12 ttl=64 time=0.608 ms
64 bytes from 172.21.1.1: icmp_seq=13 ttl=64 time=0.591 ms
64 bytes from 172.21.1.1: icmp_seq=14 ttl=64 time=0.499 ms
64 bytes from 172.21.1.1: icmp_seq=15 ttl=64 time=0.447 ms
^C
--- 172.21.1.1 ping statistics ---
16 packets transmitted, 16 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.447/0.533/0.641/0.059 ms
Oczywiście łatwo też o wniosek, że czepiam się Meraki skoro na Windows 7 działa. Tyle, że wszystkie te same urządzenia (i systemy operacyjne) z AP Cisco, konkretnie 1130, działają bez zarzutu. Tak, wiem, taka mała próba losowa o niczym nie świadczy ale dla mnie to wyraźne, mocne, żółte światło ostrzegawcze. Coś jest z Meraki nie tak.

Jeszcze mały update - tak to wygląda z Cisco 1131:

Kod: Zaznacz cały

$ ping 172.21.1.1
PING 172.21.1.1 (172.21.1.1): 56 data bytes
64 bytes from 172.21.1.1: icmp_seq=0 ttl=64 time=3.471 ms
64 bytes from 172.21.1.1: icmp_seq=1 ttl=64 time=3.531 ms
64 bytes from 172.21.1.1: icmp_seq=2 ttl=64 time=3.534 ms
64 bytes from 172.21.1.1: icmp_seq=3 ttl=64 time=3.460 ms
64 bytes from 172.21.1.1: icmp_seq=4 ttl=64 time=3.456 ms
64 bytes from 172.21.1.1: icmp_seq=5 ttl=64 time=3.452 ms
64 bytes from 172.21.1.1: icmp_seq=6 ttl=64 time=0.913 ms
64 bytes from 172.21.1.1: icmp_seq=7 ttl=64 time=3.567 ms
64 bytes from 172.21.1.1: icmp_seq=8 ttl=64 time=3.465 ms
64 bytes from 172.21.1.1: icmp_seq=9 ttl=64 time=3.458 ms
64 bytes from 172.21.1.1: icmp_seq=10 ttl=64 time=3.511 ms
64 bytes from 172.21.1.1: icmp_seq=11 ttl=64 time=3.493 ms
64 bytes from 172.21.1.1: icmp_seq=12 ttl=64 time=3.478 ms
64 bytes from 172.21.1.1: icmp_seq=13 ttl=64 time=0.962 ms
64 bytes from 172.21.1.1: icmp_seq=14 ttl=64 time=3.495 ms
64 bytes from 172.21.1.1: icmp_seq=15 ttl=64 time=3.383 ms
64 bytes from 172.21.1.1: icmp_seq=16 ttl=64 time=3.523 ms
64 bytes from 172.21.1.1: icmp_seq=17 ttl=64 time=3.577 ms
64 bytes from 172.21.1.1: icmp_seq=18 ttl=64 time=3.515 ms
64 bytes from 172.21.1.1: icmp_seq=19 ttl=64 time=3.514 ms
64 bytes from 172.21.1.1: icmp_seq=20 ttl=64 time=3.468 ms
64 bytes from 172.21.1.1: icmp_seq=21 ttl=64 time=3.517 ms
64 bytes from 172.21.1.1: icmp_seq=22 ttl=64 time=3.545 ms
64 bytes from 172.21.1.1: icmp_seq=23 ttl=64 time=3.474 ms
64 bytes from 172.21.1.1: icmp_seq=24 ttl=64 time=3.517 ms
64 bytes from 172.21.1.1: icmp_seq=25 ttl=64 time=3.550 ms
64 bytes from 172.21.1.1: icmp_seq=26 ttl=64 time=3.443 ms
64 bytes from 172.21.1.1: icmp_seq=27 ttl=64 time=3.447 ms
64 bytes from 172.21.1.1: icmp_seq=28 ttl=64 time=3.444 ms
64 bytes from 172.21.1.1: icmp_seq=29 ttl=64 time=3.424 ms
64 bytes from 172.21.1.1: icmp_seq=30 ttl=64 time=3.429 ms
^C
--- 172.21.1.1 ping statistics ---
31 packets transmitted, 31 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.913/3.323/3.577/0.628 ms
Na górę
Kyniu
wannabe
wannabe
Posty: 3595
Rejestracja: 04 lis 2006, 16:23
Kontakt:
Skontaktuj się z Kyniu

#9

#9 Post autor: Kyniu »

Robi się jeszcze ciekawiej - nie mogąc powstrzymać mojej wrodzonej ciekawości poddałem oba AP wiwisekcji. Są .... identyczne. Czyli różnica tkwi tylko w oprogramowaniu, które rzekomo powinno się zaktualizować z chmury i być identyczne.
Na górę
mihu
wannabe
wannabe
Posty: 762
Rejestracja: 10 kwie 2006, 10:37
Lokalizacja: Kraina Deszczowcow

#10

#10 Post autor: mihu »

Kyniu pisze:Robi się jeszcze ciekawiej - nie mogąc powstrzymać mojej wrodzonej ciekawości poddałem oba AP wiwisekcji. Są .... identyczne. Czyli różnica tkwi tylko w oprogramowaniu, które rzekomo powinno się zaktualizować z chmury i być identyczne.
Widzę, że zaczynasz prowadzić polemikę sam ze sobą :)

takie są zalety jak się daje komuś "władzę" nad zarządzanym przez siebie sprzętem. Idea "chmury" jest ciekawa i wygląda na to, że to jedyny słuszny kierunek, ale coś się przez to traci, szczególnie jeśli mówimy o chmurze publicznej.

Sam testuję od jakiegoś czasu Meraki AP, ale nie jestem przekonany do sposobu zarządzania, pomysł sam w sobie super, wszystko sprowadza się do point-and-click i właściwie nie potrzeba działu IT w firmie i można ciąć koszty. Ale jak się mu bliżej przyjrzeć to ma spore ograniczenia i patrząc długofalowo to trochę ślepa uliczka z której trudno może być zawrócić.
ML
-------------------------------------------------------------------------------------
"Minds are like parachutes, they work best when they are open"
Na górę
Kyniu
wannabe
wannabe
Posty: 3595
Rejestracja: 04 lis 2006, 16:23
Kontakt:
Skontaktuj się z Kyniu

#11

#11 Post autor: Kyniu »

mihu pisze:Widzę, że zaczynasz prowadzić polemikę sam ze sobą :)
Zostawiam ślad dla innych by nie wyważali otwartych drzwi. Szczegółowy opis obu problemów z prośbą o ustosunkowanie się do nich poleciał do Meraki - zobaczymy czy i co odpowiedzą.
Na górę
Kyniu
wannabe
wannabe
Posty: 3595
Rejestracja: 04 lis 2006, 16:23
Kontakt:
Skontaktuj się z Kyniu

#12

#12 Post autor: Kyniu »

Jak na razie TAC MERAKI kompletnie nie ma pomysłu na rozwiązanie problemu i bardziej zachowują się jak dzieci we mgle niż inżynierowie. Na przykład wyjaśnienie zachowania MacaMini to ich zdaniem efekt wysokiej utylizacji kanału (IMHO niezgodnie z prawdą bo po włączeniu AirMarshal mam poniżej 5% na wszystkich kanałach - zatem kanał utylizuje samo Meraki) oraz nie potrafią powiedzieć czemu nie przeszkadza to notebookowi HP z Windowsem ani temu samemu Makowi z AP'kiem Cisco 1131. Co więcej mam wrażenie, że nie bardzo panują nad tymi urządzeniami bo wystawiłem im tego źle zachowującego się AP na publicu i nic - najwyraźniej nie mają jakieś opcji zdalnego zalogowania się do niego i diagnostyki czy wymuszenia upgrade'u.
Na górę
Awatar użytkownika
krisiasty
wannabe
wannabe
Posty: 483
Rejestracja: 07 lut 2006, 22:26
Lokalizacja: Gdańsk

#13

#13 Post autor: krisiasty »

a nie mogą ci po prostu wymienić tego pudełka na inne?

rozumiem że takie podejście jest niegodne inżyniera, ale może zamiast szukać igły w stogu siana łatwiej i taniej będzie wziąć nową igłę...

a co do maka - może to jakiś problem z kompatybilnością firmware karty wifi - jaki chip w tym maku siedzi?
Na górę
Kyniu
wannabe
wannabe
Posty: 3595
Rejestracja: 04 lis 2006, 16:23
Kontakt:
Skontaktuj się z Kyniu

#14

#14 Post autor: Kyniu »

krisiasty pisze:a nie mogą ci po prostu wymienić tego pudełka na inne?
To w ich gestii jest wysunięcie takiego rozwiązania - ja testuje produkt i towarzyszącą mu usługę - by wiedzieć czy ewentualnie proponować to klientom. Na razie zarówno produkt jak i usługa mają krechę.
krisiasty pisze:rozumiem że takie podejście jest niegodne inżyniera, ale może zamiast szukać igły w stogu siana łatwiej i taniej będzie wziąć nową igłę...
Co innego gdybym MUSIAŁ to uruchomić. Ale patrz powyżej.
krisiasty pisze:a co do maka - może to jakiś problem z kompatybilnością firmware karty wifi - jaki chip w tym maku siedzi?
Tylko jak wspomniałem po raz pierwszy spotykam się z takim problemem i z AP'ekiem Cisco działa bez problemu. Co do karty to system raportuje jako "Wersja oprogramowania sprzętowego: Broadcom BCM43xx 1.0 (5.106.98.100.22)"
Na górę
Kyniu
wannabe
wannabe
Posty: 3595
Rejestracja: 04 lis 2006, 16:23
Kontakt:
Skontaktuj się z Kyniu

#15

#15 Post autor: Kyniu »

Niestety problem ewidentnie przekracza kompetencje supportu MERAKI i mimo moich sugestii o udostępnienie obrazu oprogramowania celem zreflashowania jednego z urządzeń (oczywiście o tym, że istnieje tajemnicza strona na AP'ku która to umożliwia nie dowiedziałem się od serwisu tylko grzebiąc w necie) zapadła cisza. Support nie potrafi zdalnie wymusić aktualizacji oprogramowania, nie jest też skłonny udostępnić obrazu celem przeprowadzenia operacji lokalnie.

Natomiast jedyne co potrafili rzec w sprawie wolnego działania MacaMini to "Currently you are sitting at 25% (w domyśle chodzi o zajętość kanału, bo to pisemna konkluzja z rozmowy telefonicznej) utilization. Therefore again I'd say that what you are seeing with regards to ping response times are acceptable". Na mój zarzut, że jedyna utylizacja kanału pochodzi od MERAKI (wysłałem im skan pasma 2.4 GHz) i że Windows 7 jakoś nie ma problemu - zapadła cisza. O akceptowalności pinga na poziomie dwóch sekund już mi się nie chciało nic pisać bo musiałbym użyć słów niecenzuralnych.
Na górę
ODPOWIEDZ

Wróć do „Wireless”