Van egy cég, 8 kisebb-nagyobb iroda + 2 raktár (részben nagyobb munkaterület.)
- Tcom internet (240mb/s) >> pfSense tűzfal >> gigabites 24 portos switch
- 3db AP (tp-link Archer C60 - openWRT - 802.11n, WPA2 TKIP/AES, 20MHz)
- 17 munkaállomás (gigabites NIC)
- valamint egy tucat laptop (és mobil, de ezek a jelen témában nem számítanak).
a hálózaton belül a sebességgel nincs gond, az eszközök kapacitását figyelembe véve hozzák amit kell. Azonban ha az AP-ként bekötött wifire csatlakozba végzek netről letöltést, vagy akár sebeségtesztet (legyen az a szolgáltatóé, vagy speedtest.net, speedcheck.org, stb...) mindig max. 22-25mb/s a sebesség. Kábeles csatlakozásoknál nincs ilyen gond, ott szárnyal minden.
Teszteltem a wifin keresztül belső hálózatot (iperf3), minden rendben. Kábelesen is minden rendben. Kaptam kölcsön teszthez Ubiquiti UniFi UAP AC Lite eszközt, ezzel is ugyanaz a jelenség. (Hozzá teszem, akkor is ilyen gyöszös a letöltés, amikor senki nem tartózkodik ott, tehát a munkaállomások is lekapcsolva, és más wifi csatlakozás sincs. Tehát a hálózatot nem terheli semmi.)
Van valakinek ötlete ezzel kapcsolatban?
Hozzászólások
sub
"... 20MHz) " Ha átállítod 40MHz-re, akkor mit mutat?
-fs-
Az olyan tárgyakat, amik képesek az mc futtatására, munkaeszköznek nevezzük.
TKIP kodolas eseten csak G mod mukodik, igy a 20-22 Mbps atvitelsebesseg ennek az esetnek a maximuma.
A kapcsolati sebesseg (link speed) ad erdemi informaciot a wifi kapcsolat allapotarol.
Oké, köszönöm. Ezt nem tudtam.
Ennek ellenére még mindig nem értem azt, hogy magán a helyi hálózaton miért megy "full" sebességgel wifin keresztül a fel-le töltés? Nagy méretű fájlok és iperf3 is 95-98mb/s sebességet adnak.
Milyen "hordozón" jön az internet, milyen felületen kapod?
A "Tcom internet (240mb/s) >> pfSense tűzfal >> gigabites 24 portos switch" vonalon nincsen dupla NAT?
A LAN, WiFi ugyanazt a privát subnet-et használja?
Open WRT-ken nincsen esetleg beállítva használaton kívüli default WAN IP, ami ütközik mondjuk a pfSense, vagy a Tcom gw-ével?
...mert ha valóban úgy van ahogy írtad, hogy kizárólag a Wifi -> Internet irány a gyenge, akkor valami L3 hibára, pl IP ütközésre gondolnék.
"Probléma esetén nyomják meg a piros gombot és nyugodjanak békében!"
Mivel kell közvetlen publikus IP, így a tcom egysége bridge módban van, erre csatlakozik egy DELL optiplex 620 (pfSense). Nincs dupla NAT.
Minden ugyanazt a subnetet használja. Az openWRT cuccokon a WAN port kikapcsolva, statikus IP, kábel a LAN4 portba dugva.
Nincs IP ütközés. Akkor is ez a helyzet, amikor csak egyetlen AP van bekötve, a többi eszköz (asztali gépek, másik két ap) pedig lehúzva.
Szia!
Leírtak alapján ezek merültek fel:
1., Pfense és a TCOM router
>> MTU beállítás
2., A "gigabites 24 portos switch"
>> MTU beállítás, full duplex a Wifi port ?
3., UTP kábelhiba vagy RJ45 fej probléma
4., Tranziens hiba - ipari környezet zajos elektromos 230V aljzat
>> Szünetmentes UPS kell az eszközöknek
Ha a belső hálózatban oké minden, akkor TCOM router (bridge) hibára tudnék gondolni csak.
Illetve az IP címek maszk részének nem /24-nek (255.255.255.0) kell lennie ?
Még egyszer a "kakukktojás": kábeles csatlakozás esetében semmi gond, ott nem jelentkezik ez. Valamint wifin keresztül a lokális hálózat is pörög.
Szia!
1., Default 1500 MTU-val mi volt a probléma?
> IP-tunnelek esetén kell levenni a MTU-t 1500 alá
2., Pfsense - Melyik verzió?
> (Van olyan bug, egy interfészen állítasz MTU-t akkor az összes többire is beállítódik)
3., Pfsense - Milyen hálókártya?
> Driver bug is lehet, pl.: hardware-offload kikapcsolod a Pfsense-ben akkor változik valami?
pfsense nélkül próbáltad már?
MSS clamping-re gyanakszom.
https://docs.netgate.com/pfsense/en/latest/troubleshooting/low-throughp…
https://forum.netgate.com/topic/141612/slow-tcp-connections-fixed-by-ms…
De amúgy tcpdumpokat lehetne nézni az egyes interface-eken, hogy hol vannak eldobott csomagok.
ha jol ertem:
- WiFi - WiFi jo
- WiFi - LAN jo
- LAN - net jo
- WiFi - net lassu
az a kerdes, hogy mi a kulonbseg a WiFi - LAN es a WiFi - net kapcsolatok kozott, vagy fizikai, vagy valami routing/switching problema lehet a ludas. En megprobalnam teszt jelleggel kiiktatni az egyes komponenseket, hogy kideruljon, hol van a gond:
pl AP-t kozvetlenul routerbe dugni, hogy akkor is lassu-e. ha az jo, akkor AP - pfsense- router, es AP - switch - router. igy legalabb le tudod szukiteni, melyik eszkozon kell tovabb kutakodni.
Igen, ezeken a próbákon már túl vagyok. Kb. 2 hét múlva fogok náluk járni, addig remélhetőleg megtalálom a hibát. Őket (még) nem zavarja, csak engem. Nem játékra, és nem is filmnézésre használják, tehát egyelőre nincs gondjuk.
Az IP címek maszk részének nem /24-nek (255.255.255.0) kell lennie ?
Nem.
Mert a cégemnél és otthon is /24 a hostok hálózati maszkja ... Igaz 192.168.X.X a belső hálózat IP tartománya.
http://www.szabilinux.hu/ip/
Itt le van írva mi a netmask lényege.
(rejtett subscribe)
Tehát neki B-osztályú címei vannak belső hálózatban ??
Ezt nem a publikus IP -című gépek használják ??
Illetve a hostok milyen IP-ket kapnak a DHCP-től ? Default gw ??
Miért nem jó a C-osztályú tartomány neki belső hálózatban?? 254 gépnél több van ??
8 iroda van meg 2 raktár, sztem van ott jópár vlan. Lokálba lehet bohóckodni az ip címekkel.
GPLv3-as hozzászólás.
De sok kérdés.
https://hu.wikipedia.org/wiki/Mag%C3%A1nh%C3%A1l%C3%B3zat
10.0.0.0/8
172.16.0.0/12
192.168.0.0/16
Privát IPv4 címtartományok. Nem csak a mindenki által ismert 192.168.x.y tartozik ide.
Amilyet beállít a DHCP szerveren.
Ezt ne tőlem kérdezd. Szíve joga olyan privát ip címtartományt használni amilyet csak szeretne, és úgy felosztva alhálózatokra ahogyan csak szeretné. Gondolom megvan rá az oka.
Akkor passz ...
Ahogy nézem, a 3. oktetet használja funkcionális/logikai felosztásra. A dhcp-range az /24-et fed le, de a defgw okán ott is /16-tal oszt címeket. Aztán ha egyszer úgy alakul, hogy tűzfalatni/vlan-ozni kell, akkor tűzfalra /24-eket elég felhuzigálni (.1-es címeket a lábaknak), és a dhcp-ből /16 helyett /24-es maszkot, meg .1/24-es defgw-t osztani - illetve természetesen a fw-on összedrótozni, hogy ki kivel hogyan beszélgethet.
Teljesen jó előrelátó megoldás szerintem.
Elég régóta már "felejtős" az, hogy A/B/C/akármiylen osztályú címek: classless routing van, a.b.c.d/m címtartományokkal, ahol m mondja meg, hogy a cím 32 bitjéből hány bit jelöli a hálózatot, és hány bit marad a hostok címzésére. Én itthon pl. 10.x.y.z/27-et használok, de egy vpn-szerver, ahova néhanapján belépek, a.b.c.d/22-ből oszt címeket (/24 volt, de homeoffice miatt "picit" növelni kellett a kiosztható címek számát).
A hostok természetesen a megadott tartományból kapnak címet, megkapják (nálam pl. a 255.255.255.224-es) netmaszkot, illetve a szintén adott címtartományba eső defgw címet is, ami nálam korábban a .3-volt (a dhcp tartomány meg a .4-től indult), de ez is olyan, hogy tetszőleges host lehet az adott hálózaton belül.
értem .. ok.
Egyébként konkrétan nekem is kb ugyanez a bajom otthon, csak nekem még nem volt időm foglalkozni vele.
Szintén telekom, optika, a router mikrotik, wifi unifi AP-LR csak 2,4 ghz-es és két wifi ssid.
Első körben cseréltem kábelt a router és az ap közt mert valami rágcsáló megrágta a padláson, arra gondoltam az a gond. Aztán játszottam még a 20/40 mhz es csatornaszélességgel, de az sem hozott megoldást.
Jelenleg pedig idő hiányában áll a hibakeresés a családnak pedig még nem tűnt fel.
Most akkor TKIP vagy AES?