[Ubiquiti-apparatuur] Ervaringen & Discussie - Deel 3

[rinkel]

ApC_IcE schreef op vrijdag 21 februari 2020 @ 09:13:
[...]


Vreemd, ik kan bij configure interfaces alleen LWAN2/LAN2 op disabled zetten. Ik zie geen andere optie.

Ow ik zie het al. Moet een nieuw netwerk aanmaken. Doe ik vanavond even.

Bedenk wel dat op de LAN2 poort een (of meerdere) eigen netwerk-range draait, je kunt dus niet het verkeer over beide poorten sturen dacht ik. Het is dus geen "echte" switch-poort waarbij je trunks op een meerdere poorten kan zetten. Je moet bij het maken van een netwerk dus kiezen: LAN1 of LAN2.

[RobertMe]

rinkel schreef op vrijdag 21 februari 2020 @ 11:01:
[...]


Bedenk wel dat op de LAN2 poort een (of meerdere) eigen netwerk-range draait, je kunt dus niet het verkeer over beide poorten sturen dacht ik. Het is dus geen "echte" switch-poort waarbij je trunks op een meerdere poorten kan zetten. Je moet bij het maken van een netwerk dus kiezen: LAN1 of LAN2.

Via de JSON kun je ze wel aan elkaar hacken, waarbij je dus een software bridge aanmaakt tussen de twee individuele poorten. Voor performance dus niet geweldig, maar het kan wel. En dus uiteraard niet aan te raden om te doen.

[Richo999]

ApC_IcE schreef op vrijdag 21 februari 2020 @ 09:13:
[...]


Vreemd, ik kan bij configure interfaces alleen LWAN2/LAN2 op disabled zetten. Ik zie geen andere optie.

Ow ik zie het al. Moet een nieuw netwerk aanmaken. Doe ik vanavond even.

Klopt, vergeten te vermelden inderdaad. Heb niet moeilijk gedaan er gewoon .2.xxx van gemaakt.
Voor mijzelf is directe communicatie niet nodig tussen beide netwerken aangezien ik er alleen de media player op heb zitten en de tv.

[ Voor 14% gewijzigd door Richo999 op 21-02-2020 11:14 ]

[xbeam]

rally schreef op vrijdag 21 februari 2020 @ 08:17:
Helaas is de confguratie van mijn UDM-Pro vanochtend "overleden"

Internet werkte niet meer en ik had een "Unconfigured WAN" toen ik ging kijken in de UDM.
Dus "dan maar weer een reboot", want dat werkte daarvoor prima, dat resulteerde in een melding op het LCM: "Recovery mode, please contact support".
Reboot heb ik trouwens gewoon via de interface gedaan. Geen stekkers o.i.d. er uit getrokken.

Dus de USG 3P maar uit de kast gehaald (was nog geconfigureerd) zodat er i.i.g. weer "prik" in huis is.

Van het weekend kan ik er helaas niet naar kijken, maar dit was (zelfs voor Ubiquiti) wel een heel kort avontuur

Ik heb heb hier 4P liggen die mag je wel overnemen. Wel snel beslissen, grote kans als het zo blijft ik mijn UDM in de verkoop gooi en die 4P weer terug hang.

Maar heb je ook geen SSH acces meer op je UDM. Je zou namelijk denken/verwachten dat door het niet correct afsluiten de fout melding komt vanwege een beschadigde SDN database.

Wanneer dus nog ssh toegang hebt kan misschien de containers herstellen door een update.bin opnieuw in te laden of door in de systemen.propertie de first-run regel te verwijderen. Dan installeert SDN zichzelf en de database namelijk opnieuw.

[ Voor 19% gewijzigd door xbeam op 21-02-2020 11:35 ]

[Ethirty]

ApC_IcE schreef op vrijdag 21 februari 2020 @ 08:00:
[...]

Nou echt. Daar had ik even niet op gerekend haha. Maar de USB-UTP adapter doet het prima.
Echter dus niet op de com poort van de USG moet dat een crosscable zijn?

USB-LAN of een USB-COM adapter? Die zijn niet uitwisselbaar!

Groot verschil, ook al is de stekker aan de andere kant in beide gevallen RJ45 ("netwerk")

[EricDi]

Ik heb sinds deze week een UDM-pro. Wat een drama. Constante packet loss bij mijn clients.

Zodra ik de UDM-pro wissel voor mijn edgerouter zijn de problemen voorbij. Support van Ubiquiti is de logs aan het bekijken, want ze komen er tot nu toe ook niet uit.

Ping statistics for 8.8.8.8:
Packets: Sent = 30, Received = 24, Lost = 6 (20% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 1ms, Average = 0ms

[ Voor 28% gewijzigd door EricDi op 21-02-2020 12:05 ]

[Phoolie]

LightStar schreef op vrijdag 21 februari 2020 @ 09:23:
[...]


Werkt dat laatste nog ? ik weet niet beter dan dat dat niet meer zou werken bij o.a. XS4ALL

Jep, kijk maar eens, onderstaand staat wat instructies:
[T-Mobile Thuis Glasvezel] Ervaringen & Discussie

[Arfman]

Toevallig nog mensen tips voor mij? Ik speel battlefield 4 samen met een vriend bij mij thuis op 2 pc's maar als de ene een server joined kan de andere er niet meer bij en vice versa. Ik gebruik een edgerouter x, is er ergens een instelling die ik na kan kijken?

[Richo999]

Arfman schreef op vrijdag 21 februari 2020 @ 13:10:
Toevallig nog mensen tips voor mij? Ik speel battlefield 4 samen met een vriend bij mij thuis op 2 pc's maar als de ene een server joined kan de andere er niet meer bij en vice versa. Ik gebruik een edgerouter x, is er ergens een instelling die ik na kan kijken?

Probeer eens een VPN, zou kunnen dat Battlefield meerdere identieke IP blokkeerd.

[nero355]

ApC_IcE schreef op vrijdag 21 februari 2020 @ 08:00:
Zijn gegoten stekkers met Cat 7a korte kabels. Diezelfde kabels zaten in het ziggo modem. Ik heb 2 kabels omgeruild met nieuwe uit de verpakking maar geen verschil.

Volgens mij is dat een nog niet echt 100% vastgelegde CAT standaard en kan je die sowieso beter alleen aan een patchpanel en outlets vastmaken dan direct een stekker erop zetten

Kijk anders eens rond in : Het grote topic voor nette lan afwerking deel 4

Nou echt. Daar had ik even niet op gerekend haha. Maar de USB-UTP adapter doet het prima.
Echter dus niet op de com poort van de USG moet dat een crosscable zijn?

Zie tips van anderen en hou er rekening mee dat je daarbij zoiets nodig hebt : pricewatch: Aten USB-to-Serial Converter

En dan daarbij nog eens de juiste kabel van bijvoorbeeld HP : https://www.ebay.ca/itm/H...0-5188-3836-/233042678979

Richo999 schreef op vrijdag 21 februari 2020 @ 13:22:
Probeer eens een VPN, zou kunnen dat Battlefield meerdere identieke IP blokkeerd.

Zou niet mogen ondanks dat ik die hele reeks BuggyField noem want ik heb meerdere keren twee spelers op dezelfde server zien spelen vanaf hetzelfde IP

Dus @Arfman heeft ergens anders last van...

[ Voor 15% gewijzigd door nero355 op 21-02-2020 13:25 ]

[RobertMe]

nero355 schreef op vrijdag 21 februari 2020 @ 13:22:
[...]

Zie tips van anderen en hou er rekening mee dat je daarbij zoiets nodig hebt : pricewatch: Aten USB-to-Serial Converter

En dan daarbij nog eens de juiste kabel van bijvoorbeeld HP : https://www.ebay.ca/itm/H...0-5188-3836-/233042678979

Dat kan wel een stuk simpeler en goedkoper. Zelf heb ik een RJ45 <=> USB console kabel van AliExpress. Koste zo te zien iets van in de €5. Heb helaas geen specifieke link want wordt niet meer aangeboden. Maar op AliExpress zoeken op RJ45 USB console vind je er genoeg. Levertijden zullen momenteel wel sub-optimaal zijn. Maar zo te zien vind je exact dezelfde kabel ook op een Ebay (.co.uk) voor een paar pond. Wel iets duurder dan via AliExpress, maar waarschijnlijk stuk sneller geleverd en dan betaal je nog steeds niet ruim €15.

[gitaarwerk]

Vraagje betreft de DPI. Ik vind het een interessante feature om te kijken welke data welk apparaat naar stuurt, maar het lijkt me overkill deze altijd aan te laten staan. Daarnaast krijg je niet hele specifieke info. Hoe doen jullie dit?

[nero355]

RobertMe schreef op vrijdag 21 februari 2020 @ 13:33:
Dat kan wel een stuk simpeler en goedkoper. Zelf heb ik een RJ45 <=> USB console kabel van AliExpress. Koste zo te zien iets van in de €5. Heb helaas geen specifieke link want wordt niet meer aangeboden. Maar op AliExpress zoeken op RJ45 USB console vind je er genoeg. Levertijden zullen momenteel wel sub-optimaal zijn. Maar zo te zien vind je exact dezelfde kabel ook op een Ebay (.co.uk) voor een paar pond. Wel iets duurder dan via AliExpress, maar waarschijnlijk stuk sneller geleverd en dan betaal je nog steeds niet ruim €15.

Mwa, bestel je die een keer mee bij een grotere Amazon bestelling en betaal je effectief net geen € 11 en is je probleem opgelost!

Jij bedoelt trouwens waarschijnlijk deze die je ooit had gepost : RobertMe in "[Ubiquiti-apparatuur] Ervaringen & Discussie - Deel 3" en die link werkt inderdaad niet meer, terwijl ik bovenstaande gewoon hier heb liggen en me nog nooit in de steek heeft gelaten i.c.m. HP switches!

gitaarwerk schreef op vrijdag 21 februari 2020 @ 13:36:
Vraagje betreft de DPI. Ik vind het een interessante feature om te kijken welke data welk apparaat naar stuurt, maar het lijkt me overkill deze altijd aan te laten staan. Daarnaast krijg je niet hele specifieke info. Hoe doen jullie dit?

Staat hier uit, want Pi-Hole vertelt me alles wat ik wil weten

[ Voor 16% gewijzigd door nero355 op 21-02-2020 13:42 ]

[gitaarwerk]

nero355 schreef op vrijdag 21 februari 2020 @ 13:40:
[...]

Staat hier uit, want Pi-Hole vertelt me alles wat ik wil weten

Cool, kun je uitleggen wat je bijvoorbeeld hier kan vinden tov DPI op de USG doet? :-)
Kan me namelijk zo voorstellen dat bijvoorbeeld mijn TV updates nodig heeft, maar ook gebruikersdata naar eenzelfde endpoint zou kunnen sturen ?

[nero355]

gitaarwerk schreef op vrijdag 21 februari 2020 @ 13:43:
Cool, kun je uitleggen wat je bijvoorbeeld hier kan vinden tov DPI op de USG doet? :-)
Kan me namelijk zo voorstellen dat bijvoorbeeld mijn TV updates nodig heeft, maar ook gebruikersdata naar eenzelfde endpoint zou kunnen sturen ?

Precies dat!

- Mijn nVidia Shield TV stuurt 500 berichten de wereld in per dag, terwijl ik hem niet eens gebruik!
- Een Chromecast Ultra gaat daar met 2500 stuks nog eens dik overheen!
- De TV is eigenlijk best wel stil, maar haalt ook reclames binnen waar ik geen behoefte aan heb dus : Geblokkeerd!
- Mijn laptop met Kubuntu is vreselijk braaf!

Echt mijn favoriet van alle dingen die hier draaien!

[RobertMe]

nero355 schreef op vrijdag 21 februari 2020 @ 13:40:
[...]

Mwa, bestel je die een keer mee bij een grotere Amazon bestelling en betaal je effectief net geen € 11 en is je probleem opgelost!

Jij bedoelt trouwens waarschijnlijk deze die je ooit had gepost : RobertMe in "[Ubiquiti-apparatuur] Ervaringen & Discussie - Deel 3" en die link werkt inderdaad niet meer, terwijl ik bovenstaande gewoon hier heb liggen en me nog nooit in de steek heeft gelaten i.c.m. HP switches!

Klopt, is die. En ik schreef dat ik hem nog nooit nodig heb gehad. Uiteraard heb ik hem wel al eens gebruikt en doet het zowel op een USG 3P als USW 16-150W prima.

En gezien console port bij mijn weten een vrij "dom" protocol is kan ik mij niet indenken dat het met andere hardware (HP, Cisco, ...) ineens niet zou werken.

[gitaarwerk]

nero355 schreef op vrijdag 21 februari 2020 @ 13:49:
[...]

Precies dat!

- Mijn nVidia Shield TV stuurt 500 berichten de wereld in per dag, terwijl ik hem niet eens gebruik!
- Een Chromecast Ultra gaat daar met 2500 stuks nog eens dik overheen!
- De TV is eigenlijk best wel stil, maar haalt ook reclames binnen waar ik geen behoefte aan heb dus : Geblokkeerd!
- Mijn laptop met Kubuntu is vreselijk braaf!

Echt mijn favoriet van alle dingen die hier draaien!

Nice! PiHole staat op de planning. Maar heb denk ik nog een beetje hardware nodig. Chromecast gebruiken we heel vaak. Ben benieuwd hoeveel daar te blokkeren valt

[RobertMe]

gitaarwerk schreef op vrijdag 21 februari 2020 @ 13:43:
[...]


Cool, kun je uitleggen wat je bijvoorbeeld hier kan vinden tov DPI op de USG doet? :-)
Kan me namelijk zo voorstellen dat bijvoorbeeld mijn TV updates nodig heeft, maar ook gebruikersdata naar eenzelfde endpoint zou kunnen sturen ?

Pi-Hole geeft je natuurlijk wel alleen inzicht in welk DNS verkeer er plaatsvindt. Bv "TV doet 10 requests naar *.netflix com". Daar waar DPI echt kan zeggen "TV heeft 5GB van Netflix gedownload en 1MB geupload". Beiden geven op een bepaalde manier inzicht in wat een apparaat communiceert met internet. Maar de uitwerking en wat je specifiek ziet is compleet anders. DPI kan geen DNS requests laten zien, en herkent lang niet alle verkeer. Terwijl Pi-Hole juist niet laat zien hoeveel GB er door de pijp gaat naar een website/dienst.

[Arfman]

nero355 schreef op vrijdag 21 februari 2020 @ 13:22:

Zou niet mogen ondanks dat ik die hele reeks BuggyField noem want ik heb meerdere keren twee spelers op dezelfde server zien spelen vanaf hetzelfde IP

Dus @Arfman heeft ergens anders last van...

Klopt. Het heeft ook altijd gewerkt, ook met nieuwere titels als BF1 en BFV. Ik zat te denken aan iets als UPNP maar ook nou random dingen te proberen is ook lastig en tijdrovend. Heb zelf maar 1 account dus kan het ook alleen proberen als hij hier is...

[nero355]

Arfman schreef op vrijdag 21 februari 2020 @ 14:18:
Klopt. Het heeft ook altijd gewerkt, ook met nieuwere titels als BF1 en BFV. Ik zat te denken aan iets als UPNP maar ook nou random dingen te proberen is ook lastig en tijdrovend. Heb zelf maar 1 account dus kan het ook alleen proberen als hij hier is...

Dat kan je sowieso doorstrepen, want wij zaten achter een Router die dat niet eens als optie heeft!

[JimSR]

Ik zat zelf te denken aan de UDM Pro i.c.m een USW-16 PoE.
Ik wil namelijk iig al 3 camera's op PoE en 2 access points op PoE.

Nu zie ik hier wel heel wat wisselende berichten over de UDM pro..
Wat raden jullie aan?
Aansluiting gaat KPN glasvezel + IPTV zijn.

[EricDi]

JimSR schreef op vrijdag 21 februari 2020 @ 14:26:
Ik zat zelf te denken aan de UDM Pro i.c.m een USW-16 PoE.
Ik wil namelijk iig al 3 camera's op PoE en 2 access points op PoE.

Nu zie ik hier wel heel wat wisselende berichten over de UDM pro..
Wat raden jullie aan?
Aansluiting gaat KPN glasvezel + IPTV zijn.

Mijn ervaring heb ik hierboven gedeeld. UDM pro is buggy. Ding is echt nog niet klaar voor consumenten.

[hermanh]

JimSR schreef op vrijdag 21 februari 2020 @ 14:26:
Ik zat zelf te denken aan de UDM Pro i.c.m een USW-16 PoE.
Ik wil namelijk iig al 3 camera's op PoE en 2 access points op PoE.

Nu zie ik hier wel heel wat wisselende berichten over de UDM pro..
Wat raden jullie aan?
Aansluiting gaat KPN glasvezel + IPTV zijn.

Deze combi gaat in de komende 3-6 NIET werken.
De software van de Netwerk controller in de UDM Pro staat nog in de kinderschoenen.
Er zit ontzettend veel potentie in het product en ik volg het zelf ook op de voet.

Meer detail waarom het niet werkt.

1. IGMP Proxy voor ITV kun je niet instellen. Software is aanwezig (std linux)
2. Op je KPN Glasvezel heb je 3 VLANS (internet, TV en VoIP) je kunt maar 1 VLAN op je WAN instellen de rest is onmogelijk
3. gelinkt aan het vorige puntje, static routes kun je niet dynamisch laten aanpassen op basis van DHCP optie XX functies. Kortom dat zijn handmatige acties op een VLAN die je nu niet kunt configgen
4. Ik lees zoveel stabiliteits problemen dat je zowiezo nog even wil wachten.

[ApC_IcE]

rinkel schreef op vrijdag 21 februari 2020 @ 11:01:
[...]


Bedenk wel dat op de LAN2 poort een (of meerdere) eigen netwerk-range draait, je kunt dus niet het verkeer over beide poorten sturen dacht ik. Het is dus geen "echte" switch-poort waarbij je trunks op een meerdere poorten kan zetten. Je moet bij het maken van een netwerk dus kiezen: LAN1 of LAN2.

Ja snap ik. Ik heb hem aan de praat.
Voor alleen de thermostaat. Die hoeft niet met de rest te communiceren.

[Anoniem: 120539]

@All, iemand nog tips om ergens voor wat minder dan de gebruikelijke Nederlandse prijzen de 8 poort Unifi switch met of zonder POE aan te kunnen schaffen?

Er is geen haast bij; ik heb ze niet persé snel nodig, het is gewoon ter vervanging van wat domme switches.

[rally]

xbeam schreef op vrijdag 21 februari 2020 @ 11:20:
[...]


Ik heb heb hier 4P liggen die mag je wel overnemen. Wel snel beslissen, grote kans als het zo blijft ik mijn UDM in de verkoop gooi en die 4P weer terug hang.

Maar heb je ook geen SSH acces meer op je UDM. Je zou namelijk denken/verwachten dat door het niet correct afsluiten de fout melding komt vanwege een beschadigde SDN database.

Wanneer dus nog ssh toegang hebt kan misschien de containers herstellen door een update.bin opnieuw in te laden of door in de systemen.propertie de first-run regel te verwijderen. Dan installeert SDN zichzelf en de database namelijk opnieuw.

Nope. De UDM is zelfs niet meer te pingen. Ik probeerde positief te blijven, maar ik *denk* dat de UDM Pro nog even op de plank blijft liggen de komende weken/maanden tot hij stabiel is. Jammerrrrrrr

[Ethirty]

nero355 schreef op vrijdag 21 februari 2020 @ 13:49:
[...]

- Een Chromecast Ultra gaat daar met 2500 stuks nog eens dik overheen!

Jij hebt duidelijk geen Philips Hue of Google Nest, die zijn nog veel drukker met DNS queries.

[MewBie]

Ethirty schreef op vrijdag 21 februari 2020 @ 15:59:
[...]

Jij hebt duidelijk geen Philips Hue of Google Nest, die zijn nog veel drukker met DNS queries.

Mijn Samsung tv doet er vrolijk tienduizenden per dag als ie de servers niet kan bereiken.

[ed1703]

nero355 schreef op vrijdag 21 februari 2020 @ 13:49:
[...]

Precies dat!

- Mijn nVidia Shield TV stuurt 500 berichten de wereld in per dag, terwijl ik hem niet eens gebruik!
- Een Chromecast Ultra gaat daar met 2500 stuks nog eens dik overheen!
- De TV is eigenlijk best wel stil, maar haalt ook reclames binnen waar ik geen behoefte aan heb dus :

Heb ik nu een druk netwerk met 400.000-500.000 DNS-requests totaal per dag en 4-5tb aan verkeer per jaar?

[Cyrus The Virus]

Weet iemand of het met de UDM pro mogelijk is om te zien naar welke landen een apparaat communiceert ? Ik heb namelijk een Siemens oven met Home connect maar die deed het niet meer nadat GeoIP had aan gezet met groot deel van de wereld geblokkeerd. Maar kon onder DPI geen ip's zien.

[HKLM_]

ed1703 schreef op vrijdag 21 februari 2020 @ 17:57:
[...]

Heb ik nu een druk netwerk met 400.000-500.000 DNS-requests totaal per dag en 4-5tb aan verkeer per jaar?

4-5 terra per jaar valt nog wel mee toch? Ik verstook samen met mijn vrouw +- 10 Gb per dag aan internet, Netflix, YouTube etc. Kom je op jaarbasis ook op 3,5 TB uit.

Zie net dat de USG 3P 108 dagen uptime heeft

[ Voor 6% gewijzigd door HKLM_ op 21-02-2020 18:19 ]

[geenwindows]

ed1703 schreef op vrijdag 21 februari 2020 @ 17:57:
[...]

Heb ik nu een druk netwerk met 400.000-500.000 DNS-requests totaal per dag en 4-5tb aan verkeer per jaar?

Qua DNS requests zou ik ja zeggen (hier is het 18.4k requests, incl. een Nest thermostaat) maar qua verkeer, nee. (verkeer staat hier momenteel op 685gb (7 dagen)

[Slonzo]

Mijn UDM Pro draait nu een week en heeft welgeteld 0 threats gedetecteerd.

Dat kan toch niet?

Ik heb een tijdje geleden even op pfSense gedraaid met Suricata en die gaf honderden hits per dag, zelfs met een niet al te gekke ruleset. Ik kan niet geloven dat er geen port scans gebeurd zijn, dat niemand op een open poort heeft proberen te connecten, of...

Op mijn USG3P heb ik het nooit gebruikt vanwege de performance hit... (85Mbit max)

Hoe kan ik nakijken of IDS/IPS draait en zijn ding doet?

[ Voor 9% gewijzigd door Slonzo op 21-02-2020 19:23 ]

[Tylen]

Slonzo schreef op vrijdag 21 februari 2020 @ 19:23:
Mijn UDM Pro draait nu een week en heeft welgeteld 0 threats gedetecteerd.

Dat kan toch niet?

Ik heb een tijdje geleden even op pfSense gedraaid met Suricata en die gaf honderden hits per dag, zelfs met een niet al te gekke ruleset. Ik kan niet geloven dat er geen port scans gebeurd zijn, dat niemand op een open poort heeft proberen te connecten, of...

Op mijn USG3P heb ik het nooit gebruikt vanwege de performance hit... (85Mbit max)

Hoe kan ik nakijken of IDS/IPS draait en zijn ding doet?

Er is een commando om het te starten/restarten.

Edit: sudo /etc/init.d/utm restart
Is overigens wel voor de usg. Maar misschien werkt ie ook op de udm. Anders even rebooten.

[ Voor 8% gewijzigd door Tylen op 21-02-2020 19:37 ]

[geenwindows]

Slonzo schreef op vrijdag 21 februari 2020 @ 19:23:
Mijn UDM Pro draait nu een week en heeft welgeteld 0 threats gedetecteerd.

Dat kan toch niet?

Ik heb een tijdje geleden even op pfSense gedraaid met Suricata en die gaf honderden hits per dag, zelfs met een niet al te gekke ruleset. Ik kan niet geloven dat er geen port scans gebeurd zijn, dat niemand op een open poort heeft proberen te connecten, of...

Op mijn USG3P heb ik het nooit gebruikt vanwege de performance hit... (85Mbit max)

Hoe kan ik nakijken of IDS/IPS draait en zijn ding doet?

GeoIP in gebruik?
Die Russen en Chinese lopen mijn logboek op dit moment van schrijven mooi vol te spammen (port scans)

[_Arthur]

Na al het negatieve geweld, ben ik eigenlijk wel tevreden met mijn UDM-Pro. Draait nu 3 dagen. Van de week 2x de stroom er af geweest in verband met wat werkzaamheden (UDM-Pro niet specifiek uitgezet, gewoon hop stroom er af). En nog 0x gecrashed oid. Ook setup vorige week verliep zonder errors.

20GiB traffic (RX&TX) per dag over deze 3 dagen. ~55k DNS req (via pi.hole).

Geheugen gebruik staat nu op 47% (denk een paar procent minder als je/ik niet in de interface zit).

1x 8P Unifi switch hangt er aan, 2 AP-AC-Lite en 1 AP-AC-Mesh. Met gemiddeld 20 clients (TV, servers, temp. sensoren etc). Dit dus achter de UDM-Pro aan 1Gbit Tweak Glasvezel (de door Tweak geleverde SPF zit in de UDM-Pro).

Lokale netwerk is simpel; geen IPTV en geen VLAN's (moet ik tzt nog eens inrichten).

[Slonzo]

Ik vond ondertussen dit (even naar onder scrollen, bij 'intrusion detection'):
https://help.ubnt.com/hc/en-us/articles/360006893234#4

Een lookup van blacklistthisdomain.com resolvet gewoon, geen melding.
Alle categorieën staan aan

Net de honeypot ook even getest (ssh en telnet), ik krijg daar ook geen melding...

geenwindows schreef op vrijdag 21 februari 2020 @ 19:39:
GeoIP in gebruik?
Die Russen en Chinese lopen mijn logboek op dit moment van schrijven mooi vol te spammen (port scans)

GeoIP staat aan, maar niks op de blacklist.

Tylen schreef op vrijdag 21 februari 2020 @ 19:27:
Er is een commando om het te starten/restarten.

Edit: sudo /etc/init.d/utm restart
Is overigens wel voor de usg. Maar misschien werkt ie ook op de udm. Anders even rebooten.

Helaas:

# /etc/init.d/utm restart
-sh: /etc/init.d/utm: not found

[ Voor 30% gewijzigd door Slonzo op 21-02-2020 20:01 ]

[geenwindows]

Slonzo schreef op vrijdag 21 februari 2020 @ 19:44:
Ik vond ondertussen dit (even naar onder scrollen, bij 'intrusion detection'):
https://help.ubnt.com/hc/en-us/articles/360006893234#4

Een lookup van blacklistthisdomain.com resolvet gewoon, geen melding.
Alle categorieën staan aan


[...]

GeoIP staat aan, maar niks op de blacklist.

ik moet zeggen nu ik geen Ubiquiti gateway meer gebruik, ik een stuk meer te zien krijg. ik wordt elke 5 sec wel weer "aangevallen" (meestal portscans, anders is het iets wat IDS oppikt) met de USG had ik heel stuk minder meldingen...

overigens, als je GeoIP aanzet en niks Blacklist, zal die ook niks blokkeren (of whitelist, ligt eraan hoe je wilt filteren..)

[ Voor 9% gewijzigd door geenwindows op 21-02-2020 19:54 ]

[_Arthur]

Slonzo schreef op vrijdag 21 februari 2020 @ 19:44:
GeoIP staat aan, maar niks op de blacklist.

Ik zie wel dat de Iptables rules worden aangemaakt als je bv Rusland blokkeert;

Dan komt deze rule er bij:

code:

Chain UBIOS_IN_GEOIP (4 references)
 pkts bytes target     prot opt in     out     source               destination
    0     0 RETURN     all  --  *      *       0.0.0.0              0.0.0.0/0
    0     0 RETURN     all  --  *      *       255.255.255.255      0.0.0.0/0
    4   288 RETURN     all  --  *      *       185.227.72.0/22      0.0.0.0/0
    0     0 RETURN     all  --  *      *       192.168.1.0/24       0.0.0.0/0
    0     0 RETURN     all  --  *      *       10.0.0.0/8           0.0.0.0/0
    0     0 RETURN     all  --  *      *       172.16.0.0/12        0.0.0.0/0
    0     0 RETURN     all  --  *      *       192.168.0.0/16       0.0.0.0/0
    0     0 RETURN     all  --  *      *       100.64.0.0/10        0.0.0.0/0
   16  8131 RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED
    0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0            -m geoip --source-country RU
    1    98 RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0

De een na laatste regel dropt al het verkeer uit RU.

Ik heb het idee dat de IDS/IPS wel werkt; alleen dat er niets gerapporteerd wordt.

Blokkeer je ook Brazilie, dan komt er "-m geoip --source-country RU,BR" te staan (helemaal aan de rechter kant).

Als je met SSH inlogt op je UDM-Pro, kan je met "iptables -L -v -n |more" deze rules zien.

[ Voor 3% gewijzigd door _Arthur op 21-02-2020 20:12 ]

[Comp User]

RobertMe schreef op donderdag 20 februari 2020 @ 22:40:
[...]

Niet mee eens. Of ja, voor echte consumenten wel. Maar dit is het forum van Tweakers en IMO moet iedereen met IT affiniteit een UniFi setup toch wel aan de praat kunnen krijgen. En met behulp van tutorials / YouTube al helemaal. Persoonlijk vind ik het in ieder geval echt geen rocket science achtige apparaten. En OpenWRT inregelen met VLANs in de config file is dan nog stukken erger

Zeker als je de tutorials van Willie of Crosstalk Solutions - mijn persoonlijke voorkeur - volgt kan er weinig fout.

Ja, Ik weet dat er digibeten zijn die nog geen computer kunnen opstarten, maar daarvoor zijn imho de connectboxen van deze wereld uitgevonden.

[JanAd]

_Arthur schreef op vrijdag 21 februari 2020 @ 19:43:
Na al het negatieve geweld, ben ik eigenlijk wel tevreden met mijn UDM-Pro. Draait nu 3 dagen. Van de week 2x de stroom er af geweest in verband met wat werkzaamheden (UDM-Pro niet specifiek uitgezet, gewoon hop stroom er af). En nog 0x gecrashed oid. Ook setup vorige week verliep zonder errors.

20GiB traffic (RX&TX) per dag over deze 3 dagen. ~55k DNS req (via pi.hole).

Geheugen gebruik staat nu op 47% (denk een paar procent minder als je/ik niet in de interface zit).

1x 8P Unifi switch hangt er aan, 2 AP-AC-Lite en 1 AP-AC-Mesh. Met gemiddeld 20 clients (TV, servers, temp. sensoren etc). Dit dus achter de UDM-Pro aan 1Gbit Tweak Glasvezel (de door Tweak geleverde SPF zit in de UDM-Pro).

Lokale netwerk is simpel; geen IPTV en geen VLAN's (moet ik tzt nog eens inrichten).

Hier ook geen problemen met een vergelijkbare vrij simpele thuis-setup.
Geheugen blijft hier ook rond de 50% zitten, uptime is nu 3 dagen.
Ik moet alleen m'n Pihole terug aansluiten en instellen op de UDM Pro. Hoe heb jij hem ingesteld?

[The Eagle]

gitaarwerk schreef op vrijdag 21 februari 2020 @ 13:36:
Vraagje betreft de DPI. Ik vind het een interessante feature om te kijken welke data welk apparaat naar stuurt, maar het lijkt me overkill deze altijd aan te laten staan. Daarnaast krijg je niet hele specifieke info. Hoe doen jullie dit?

Ik heb DPI (beta) aan staan en draai een pihole. In principe gaat daar alle dns verkeer van alle clients door.
DPI is wel handig om aan te hebben staan, omdat je in de unify app dan al een beetje kunt zien wat er per device gebeurt. En pas als je gekke dingen ziet log je in om te kijken wat Pihole zegt. Die DPI vreet geen resources of bandbreedte. IDS/IPS kennelijk wel, maar dat heb ik uit staan (USG en een 250 ziggo lijn hierzo). Vraag me af of het het waard is. Binnenkort misschien voor een test eens een weekje draien, kijken of het iets oplevert.

[Slonzo]

Suricata lijkt wel te draaien, maar toch geen meldingen...

# ps | grep suricata
14865 root {Suricata-Main} /usr/bin/suricata --pcap --pidfile /run/suricata.pid -c /usr/share/ubios-udapi-server/ips/config/suricata_ubios_high.yaml
30772 root grep suricata
# cat /var/log/suricata/suricata.log
# cat /usr/share/ubios-udapi-server/ips/config/
classification.config reference.config suricata_ubios_high.yaml
# cat /usr/share/ubios-udapi-server/ips/rules/
alien.list emerging-deleted.rules.md5 emerging-mobile_malware.rules.md5 emerging-tftp.rules.md5
botcc.portgrouped.rules emerging-dns.rules emerging-netbios.rules emerging-trojan.rules
botcc.portgrouped.rules.md5 emerging-dns.rules.md5 emerging-netbios.rules.md5 emerging-trojan.rules.md5
botcc.rules emerging-dos.rules emerging-p2p.rules emerging-user_agents.rules
botcc.rules.md5 emerging-dos.rules.md5 emerging-p2p.rules.md5 emerging-user_agents.rules.md5
ciarmy.rules emerging-exploit.rules emerging-policy.rules emerging-voip.rules
ciarmy.rules.md5 emerging-exploit.rules.md5 emerging-policy.rules.md5 emerging-voip.rules.md5
compromised-ips.txt emerging-ftp.rules emerging-pop3.rules emerging-web_client.rules
compromised.rules emerging-ftp.rules.md5 emerging-pop3.rules.md5 emerging-web_client.rules.md5
compromised.rules.md5 emerging-games.rules emerging-rpc.rules emerging-web_server.rules
custom.rules emerging-games.rules.md5 emerging-rpc.rules.md5 emerging-web_server.rules.md5
dnp3-events.rules emerging-icmp.rules emerging-scada.rules emerging-web_specific_apps.rules
dns-events.rules emerging-icmp.rules.md5 emerging-scada.rules.md5 emerging-web_specific_apps.rules.md5
drop.rules emerging-icmp_info.rules emerging-scan.rules emerging-worm.rules
drop.rules.md5 emerging-icmp_info.rules.md5 emerging-scan.rules.md5 emerging-worm.rules.md5
dshield.rules emerging-imap.rules emerging-shellcode.rules files.rules
dshield.rules.md5 emerging-imap.rules.md5 emerging-shellcode.rules.md5 gen-msg.map
emerging-activex.rules emerging-inappropriate.rules emerging-smtp.rules rbn-malvertisers.rules
emerging-activex.rules.md5 emerging-inappropriate.rules.md5 emerging-smtp.rules.md5 rbn.rules
emerging-attack_response.rules emerging-info.rules emerging-snmp.rules sid-msg.map
emerging-attack_response.rules.md5 emerging-info.rules.md5 emerging-snmp.rules.md5 spamhaus.rules
emerging-chat.rules emerging-malware.rules emerging-sql.rules tor.list
emerging-chat.rules.md5 emerging-malware.rules.md5 emerging-sql.rules.md5 tor.rules
emerging-current_events.rules emerging-misc.rules emerging-telnet.rules tor.rules.md5
emerging-current_events.rules.md5 emerging-misc.rules.md5 emerging-telnet.rules.md5 ubiquiti.rules
emerging-deleted.rules emerging-mobile_malware.rules emerging-tftp.rules unicode.map
# cat /run/ips/suricata.log
...
[14865] 21/2/2020 -- 19:08:06 - (suricata.c:1107) <Notice> (LogVersion) -- This is Suricata version 4.0.0-dev
[14865] 21/2/2020 -- 19:08:31 - (runmodes.c:647) <Warning> (RunModeInitializeEveOutput) -- [ERRCODE: SC_ERR_INVALID_ARGUMENT(13)] - No output module named eve-log.files
[14865] 21/2/2020 -- 19:08:34 - (tm-threads.c:2182) <Notice> (TmThreadWaitOnThreadInit) -- all 8 packet processing threads, 4 management threads initialized, engine started.
# cd /run/utm
# ls -al
total 8
drwxr-xr-x 3 root root 180 Feb 21 19:08 .
drwxr-xr-x 19 root root 1300 Feb 21 20:34 ..
-rw-r--r-- 1 root root 0 Feb 19 18:16 dnsfilter.conf
-rw-r--r-- 1 root root 0 Feb 19 18:16 dnsreputation.conf
drwxr-xr-x 3 root root 60 Feb 19 18:16 endpoint
srwxr-xr-x 1 root root 0 Feb 19 18:16 eve_alert.json
srwxr-xr-x 1 root root 0 Feb 19 18:16 eve_stat.json
-rw-r--r-- 1 root root 21 Feb 19 18:16 honeypot.conf
-rw-r--r-- 1 root root 16 Feb 21 19:08 runmode
#

Het enige rare wat ik zie is:
<Warning> (RunModeInitializeEveOutput) -- [ERRCODE: SC_ERR_INVALID_ARGUMENT(13)] - No output module named eve-log.files

Snap er niets van.

_Arthur schreef op vrijdag 21 februari 2020 @ 20:11:
Als je met SSH inlogt op je UDM-Pro, kan je met "iptables -L -v -n |more" deze rules zien.

Ik bedoelde dat ik gewoon niets op de blacklist heb gezet, de geoip filtering boeit me momenteel minder

[RobertMe]

The Eagle schreef op vrijdag 21 februari 2020 @ 20:57:
[...]

Ik heb DPI (beta) aan staan en draai een pihole. In principe gaat daar alle dns verkeer van alle clients door.
DPI is wel handig om aan te hebben staan, omdat je in de unify app dan al een beetje kunt zien wat er per device gebeurt. En pas als je gekke dingen ziet log je in om te kijken wat Pihole zegt. Die DPI vreet geen resources of bandbreedte. IDS/IPS kennelijk wel, maar dat heb ik uit staan (USG en een 250 ziggo lijn hierzo). Vraag me af of het het waard is. Binnenkort misschien voor een test eens een weekje draien, kijken of het iets oplevert.

Op de USG blijft hardware offloading in gebruik als je DPI aan hebt staan. Daardoor dat het (vrijwel) geen impact op de performance heeft.

Smart queues en IDS/IPS schakelt hardware offloading uit. Elk pakketje moet dan door het OS/software worden verwerkt, en dat kost al redelijk wat performance AFAIK. Voeg daaraan toe dat Suricata (voor IDS/IPS) een zwaar pakket is in gebruik en er blijft niks meer van de snelheid over (~100Mbit/s dus op de USG 3P).

Bij de UDM zit dat volgens mij wel weer anders. Daarin zit geen dedicated hardware meer en wordt alles door de CPU/ het OS gedaan. In principe zou dat het voor Ubiquiti simpeler moeten maken, omdat ze niet dingen met en zonder hardware offloading hoeven te maken (zonder offloading moet het sowieso werken, en vervolgens dus ook nog liefst met hardware offloading, wat dus "dubbel" werk geeft). Daarnaast kunnen ze nu ook veel makkelijker betere hardware er tegenaan gooien voor hogere snelheden. En zijn ze niet meer afhankelijk van de SDK van de hardware leverancier.
Want dat is IIRC ook het probleem met de (oudere) EdgeRouters en USGs. De Calvium SDK is niet goed up-to-date gehouden met bv nieuwere Linux versies en daardoor heeft Ubiquiti ook problemen om te updaten. (Zie EdgeOS 2 dat wel stable is maar eigenlijk toch niet).

[_Arthur]

Slonzo schreef op vrijdag 21 februari 2020 @ 21:01:
Suricata lijkt wel te draaien, maar toch geen meldingen...

In cat /run/ips/suricata.log zie ik het volgende:

code:

[1010] 21/2/2020 -- 18:43:59 - (util-device.c:283) <Notice> (LiveDeviceListClean) -- Stats for 'br0':  pkts: 4895205, drop: 68945 (1.41%), invalid chksum: 15
[20077] 21/2/2020 -- 18:48:43 - (util-device.c:283) <Notice> (LiveDeviceListClean) -- Stats for 'br0':  pkts: 66803, drop: 0 (0.00%), invalid chksum: 0
[27151] 21/2/2020 -- 18:53:53 - (util-device.c:283) <Notice> (LiveDeviceListClean) -- Stats for 'br0':  pkts: 40513, drop: 0 (0.00%), invalid chksum: 0
[2450] 21/2/2020 -- 19:16:21 - (util-device.c:283) <Notice> (LiveDeviceListClean) -- Stats for 'br0':  pkts: 177583, drop: 0 (0.00%), invalid chksum: 0

Ik zie hier ook dezelfde error als jij ziet:

code:

[3832] 21/2/2020 -- 19:16:21 - (suricata.c:1107) <Notice> (LogVersion) -- This is Suricata version 4.0.0-dev
[3832] 21/2/2020 -- 19:16:44 - (runmodes.c:647) <Warning> (RunModeInitializeEveOutput) -- [ERRCODE: SC_ERR_INVALID_ARGUMENT(13)] - No output module named eve-log.files

Mijn IPS level heb ik net naar 5 gezet (-alles- staat aan). En heb nu 2 meldingen op het dashboard.

Wanneer ik weer eens kijk met "iptables -L -v -n |more" zie ik het volgende (tussen alle rules):

code:

Chain UBIOS_IN_GEOIP (4 references)
 pkts bytes target     prot opt in     out     source               destination
  470 18800 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0            -m geoip --source-country RU

Er zijn door mijn Rusland GeoIP block dus 470 packets gedropped.

Het werkt wel; alleen dus geen rapportage in het dashboard.

[ Voor 10% gewijzigd door _Arthur op 21-02-2020 22:23 ]

[Cyleo]

The Eagle schreef op vrijdag 21 februari 2020 @ 20:57:
[...]

Ik heb DPI (beta) aan staan en draai een pihole. In principe gaat daar alle dns verkeer van alle clients door.
DPI is wel handig om aan te hebben staan, omdat je in de unify app dan al een beetje kunt zien wat er per device gebeurt. En pas als je gekke dingen ziet log je in om te kijken wat Pihole zegt. Die DPI vreet geen resources of bandbreedte. IDS/IPS kennelijk wel, maar dat heb ik uit staan (USG en een 250 ziggo lijn hierzo). Vraag me af of het het waard is. Binnenkort misschien voor een test eens een weekje draien, kijken of het iets oplevert.

Ik heb (na een aantal recensie te hebben gelezen van de UDM, enthousiast geworden, maar te duur bevonden) IPS aangezet op mijn USG. Dit zou de bandwidth moeten cripplen tot 85, maar in de praktijk haal ik nu nog overal 100/100 en merk ik er weinig van. Het levert daarentegen wel een boel inzicht op, dus ik laat het nog even aanstaan. Het is wel een leuke tool, maar ik zie dat alle attacks naar mijn webserver gaan, dus als je dat niet hebt heeft het denk ik beperkte nut.

[ed1703]

Cyleo schreef op vrijdag 21 februari 2020 @ 22:32:
Het is wel een leuke tool, maar ik zie dat alle attacks naar mijn webserver gaan, dus als je dat niet hebt heeft het denk ik beperkte nut.

Zeg maar gerust niet. Geoblocking is dan nog wel aardig, is al lastig vaak door gebruik van cloud omgeving in verschillende landen. Het is vooral een enorme lijst aan blocks die in de praktijk useles is. Of je moet gaan whitelisten. De enorme honger naar IPS is er vooral eentje van een roepende community om meer features. Echter hoppen scanbots van hoster naar hoster of via malware. Dan eindig je al snel op geoblocking en wat kleine blacklists. Want homeland-honkvast zijn die botjes meestal wel. Met een default firewall zonder portforwards zeker minder nuttig.

Ik vraag mij dan vooral af, wat ga je afgezien dat portscans er gewoon bijhoren, met die informatie doen?

[ Voor 11% gewijzigd door ed1703 op 21-02-2020 23:01 ]

[nero355]

hermanh schreef op vrijdag 21 februari 2020 @ 14:44:

1. gelinkt aan het vorige puntje, static routes kun je niet dynamisch laten aanpassen op basis van DHCP optie XX functies. Kortom dat zijn handmatige acties op een VLAN die je nu niet kunt configgen

Volgens mij is dat al sinds de USG generatie al heel lang een probleem!

Anoniem: 120539 schreef op vrijdag 21 februari 2020 @ 14:59:
@All, iemand nog tips om ergens voor wat minder dan de gebruikelijke Nederlandse prijzen de 8 poort Unifi switch met of zonder POE aan te kunnen schaffen?

Er is geen haast bij; ik heb ze niet persé snel nodig, het is gewoon ter vervanging van wat domme switches.

Ik heb gewoon zo :
op de bestelknop van de non-PoE versie gedrukt destijds...

Ethirty schreef op vrijdag 21 februari 2020 @ 15:59:
Jij hebt duidelijk geen Philips Hue of Google Nest, die zijn nog veel drukker met DNS queries.

Als ik al die paars en groen verlichte huizen hier in de buurt zie : Gelukkig niet!

De Chromecast samen met de Android/Android TV apparaten is al eigenlijk teveel Google in huis wat mij betreft, maar ja... het moet maar hé!

MewBie schreef op vrijdag 21 februari 2020 @ 16:08:
Mijn Samsung tv doet er vrolijk tienduizenden per dag als ie de servers niet kan bereiken.

Bekend probleem : https://discourse.pi-hole...ke-with-a-samsung-tv/3165

ed1703 schreef op vrijdag 21 februari 2020 @ 17:57:
Heb ik nu een druk netwerk met 400.000-500.000 DNS-requests totaal per dag en 4-5tb aan verkeer per jaar?

Als dat allemaal van apparaten komt die daadwerkelijk in gebruik zijn door iemand of voor iets : Prima!

[Anoniem: 120539]

Slonzo schreef op vrijdag 21 februari 2020 @ 19:23:
Mijn UDM Pro draait nu een week en heeft welgeteld 0 threats gedetecteerd.

Dat kan toch niet?

Ik kreeg op mijn USG ook best veel aanvallen; bijna dagelijks.
Allemaal met mijn webserver (die alleen 1 pagina en wat plaatjes op poort 80, http aanbood) als target.
Omdat ik die eigenlijk niet meer gebruikte de forwarding van 80 gewoon uitgezet.
Sindsdien zo goed als geen aanvallen meer geconstateerd.
Behalve: als ik een keer een torrent aan zet dan komen er soms TOR related (wat ik niet gebruik) meldingen naar voren.

Je zou dus eens kunnen proberen een http webserver te publishen, of eens een paar Linux-distro’s te torrenten.

[EricDi]

Voor mensen met een udm pro. Zouden jullie een ping test kunnen doen en de packet loss kunnen melden?

Ping -n 60 8.8.8.8

[JanAd]

EricDi schreef op zaterdag 22 februari 2020 @ 08:13:
Voor mensen met een udm pro. Zouden jullie een ping test kunnen doen en de packet loss kunnen melden?

Ping -n 60 8.8.8.8

Geen packet loss hier.

Fw 1.6.4

[EricDi]

JanAd schreef op zaterdag 22 februari 2020 @ 08:39:
[...]


Geen packet loss hier.

dank.

Mijn udm pro via ssh heeft ook geen packet loss. Maar de clients wel. Andere router heeft geen issues.

Ik denk dat het een hardware issue is. Elke reset/downgrade/upgrade heeft geen effect. Zodra de udm pro aanstaan en verbinding maakt krijg ik packet loss.

[Tylen]

EricDi schreef op zaterdag 22 februari 2020 @ 08:46:
[...]
dank.

Mijn udm pro via ssh heeft ook geen packet loss. Maar de clients wel. Andere router heeft geen issues.

Ik denk dat het een hardware issue is. Elke reset/downgrade/upgrade heeft geen effect. Zodra de udm pro aanstaan en verbinding maakt krijg ik packet loss.

Ips even uitzetten??

[EricDi]

Tylen schreef op zaterdag 22 februari 2020 @ 08:53:
[...]


Ips even uitzetten??

de packet loss is aanwezig zodra het apparaat met internet verbind. Compleet standaard settings, zelfs nog veel dat de unifi controller is aangeraakt.

Ips etc staat dan nog uit.

[Tylen]

EricDi schreef op zaterdag 22 februari 2020 @ 08:59:
[...]
de packet loss is aanwezig zodra het apparaat met internet verbind. Compleet standaard settings, zelfs nog veel dat de unifi controller is aangeraakt.

Ips etc staat dan nog uit.

Raar. Rotte kabel?? Of zelfde kabel als waar het wel mee werkt? Eventueel zou je nog met fd/hd/auto kunnen spelen. Vroegah zetten we altijd alles op een vaste snelheid (disable autonegotiate) voor beste performance. Wil niet zeggen dat het een oplossing is natuurlijk maar kan je wel een beetje pin poiten waar het issue zich bevind.

[_Arthur]

EricDi schreef op zaterdag 22 februari 2020 @ 08:59:
[...]
de packet loss is aanwezig zodra het apparaat met internet verbind. Compleet standaard settings, zelfs nog veel dat de unifi controller is aangeraakt.

Ips etc staat dan nog uit.

Vraag; is die client direct op 1 van de lan-poorten van de UDM aangesloten? Of zitten er nog switches tussen?

Terwijl je de ping hebt lopen; ssh naar je UDMPro, doe een "ifconfig" en kopieer de info van de br0 interface en de port waarop je client geconnect is.

Zoiets dus:

code:

br0       Link encap:Ethernet  HWaddr E2:63:XX:XX:XX:XX
          inet addr:192.168.1.1  Bcast:0.0.0.0  Mask:255.255.255.0
          inet6 addr: fe80::/64 Scope:Link
          UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1500  Metric:1
          RX packets:46057104 errors:0 dropped:0 overruns:0 frame:0
          TX packets:36172464 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:63133854409 (58.7 GiB)  TX bytes:31670866712 (29.4 GiB)

Mijn ping (client achter 2 switches):

code:

>ping -n 60 8.8.8.8 -l 1024

Pinging 8.8.8.8 with 1024 bytes of data:
Reply from 8.8.8.8: bytes=68 (sent 1024) time=4ms TTL=56
Reply from 8.8.8.8: bytes=68 (sent 1024) time=4ms TTL=56
Reply from 8.8.8.8: bytes=68 (sent 1024) time=4ms TTL=56
Reply from 8.8.8.8: bytes=68 (sent 1024) time=4ms TTL=56
Reply from 8.8.8.8: bytes=68 (sent 1024) time=4ms TTL=56
Reply from 8.8.8.8: bytes=68 (sent 1024) time=4ms TTL=56

Ping statistics for 8.8.8.8:
    Packets: Sent = 6, Received = 6, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 4ms, Maximum = 4ms, Average = 4ms

[ed1703]

EricDi schreef op zaterdag 22 februari 2020 @ 08:59:
[...]
de packet loss is aanwezig zodra het apparaat met internet verbind. Compleet standaard settings, zelfs nog veel dat de unifi controller is aangeraakt.

Ips etc staat dan nog uit.

Even trouble-shoot backtracking..

Heb je dit ook op pingen naar je UDM?
Wat zit daarachter? Ping dat device eens.
enz enz..
check op de UDM eens of er errors op de poort zitten? ifconfig commando zal vast wel werken.

Aangezien je aangeeft dat het met een andere router wel werkt heeft vervanging kabel nu nog niet veel zin denk ik.

Overigens weet ik van het forum dat er gebruikers zijn die packetloss hebben met de normale UDM, dus ik kijk hier niet van op.

[ Voor 9% gewijzigd door ed1703 op 22-02-2020 09:29 ]

[EricDi]

ed1703 schreef op zaterdag 22 februari 2020 @ 09:24:
[...]

Even trouble-shoot backtracking..

Heb je dit ook op pingen naar je UDM?
Wat zit daarachter? Ping dat device eens.
enz enz..
check op de UDM eens of er errors op de poort zitten? ifconfig commando zal vast wel werken.

Aangezien je aangeeft dat het met een andere router wel werkt heeft vervanging kabel nu nog niet veel zin denk ik.

Overigens weet ik van het forum dat er gebruikers zijn die packetloss hebben met de normale UDM, dus ik kijk hier niet van op.

Heb meerdere ports, clients, en kabels geprobeerd. Met mijn edgerouter geen issues, met de UDM pro wel.


Links is een client in windows die direct met een kabel op de UDM pro is aangesloten.
Rechts is een SSH van de UDM pro die dezelfde ping uitvoert op hetzelfde moment.

Lijkt dus echt alsof er tussen de LAN port en de WAN port van de UDM pro iets mis gaat.

[ed1703]

EricDi schreef op zaterdag 22 februari 2020 @ 09:39:
[...]
Heb meerdere ports, clients, en kabels geprobeerd. Met mijn edgerouter geen issues, met de UDM pro wel.

[Afbeelding]
Links is een client in windows die direct met een kabel op de UDM pro is aangesloten.
Rechts is een SSH van de UDM pro die dezelfde ping uitvoert op hetzelfde moment.

Lijkt dus echt alsof er tussen de LAN port en de WAN port van de UDM pro iets mis gaat.

Wat @_Arthur al aangeeft... check ifconfig op je br0.

[EricDi]

ed1703 schreef op zaterdag 22 februari 2020 @ 09:41:
[...]

Wat @_Arthur al aangeeft... check ifconfig op je br0.

code:

# ifconfig
br0       Link encap:Ethernet  HWaddr E2:63:DA:5A:D2:41
          inet addr:192.168.1.1  Bcast:0.0.0.0  Mask:255.255.255.0
          inet6 addr: fe80::47a:afff:fed1:1112/64 Scope:Link
          UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1500  Metric:1
          RX packets:10672 errors:0 dropped:12 overruns:0 frame:0
          TX packets:21412 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:1967600 (1.8 MiB)  TX bytes:22238170 (21.2 MiB)

br10      Link encap:Ethernet  HWaddr E0:63:DA:5A:D2:4B
          inet addr:10.10.10.1  Bcast:0.0.0.0  Mask:255.255.255.0
          inet6 addr: fe80::491:92ff:fe03:5a27/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:10 errors:0 dropped:0 overruns:0 frame:0
          TX packets:689 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:808 (808.0 B)  TX bytes:214140 (209.1 KiB)

eth0      Link encap:Ethernet  HWaddr E0:63:DA:5A:D2:41
          inet6 addr: fe80::e263:daff:fe5a:d241/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:945 errors:0 dropped:2 overruns:0 frame:0
          TX packets:15 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:130401 (127.3 KiB)  TX bytes:3530 (3.4 KiB)

eth1      Link encap:Ethernet  HWaddr E0:63:DA:5A:D2:42
          inet6 addr: fe80::e263:daff:fe5a:d242/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:949 errors:0 dropped:2 overruns:0 frame:0
          TX packets:15 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:130602 (127.5 KiB)  TX bytes:3530 (3.4 KiB)

eth10     Link encap:Ethernet  HWaddr E0:63:DA:5A:D2:4B
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:10000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

eth10.10  Link encap:Ethernet  HWaddr E0:63:DA:5A:D2:4B
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

eth2      Link encap:Ethernet  HWaddr E0:63:DA:5A:D2:43
          inet6 addr: fe80::e263:daff:fe5a:d243/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:941 errors:0 dropped:2 overruns:0 frame:0
          TX packets:15 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:130149 (127.0 KiB)  TX bytes:3530 (3.4 KiB)

eth3      Link encap:Ethernet  HWaddr E0:63:DA:5A:D2:44
          inet6 addr: fe80::e263:daff:fe5a:d244/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:945 errors:0 dropped:2 overruns:0 frame:0
          TX packets:15 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:130336 (127.2 KiB)  TX bytes:3530 (3.4 KiB)

eth4      Link encap:Ethernet  HWaddr E0:63:DA:5A:D2:45
          inet6 addr: fe80::e263:daff:fe5a:d245/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:941 errors:0 dropped:2 overruns:0 frame:0
          TX packets:15 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:130136 (127.0 KiB)  TX bytes:3530 (3.4 KiB)

eth5      Link encap:Ethernet  HWaddr E0:63:DA:5A:D2:46
          inet6 addr: fe80::e263:daff:fe5a:d246/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:936 errors:0 dropped:2 overruns:0 frame:0
          TX packets:15 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:129745 (126.7 KiB)  TX bytes:3530 (3.4 KiB)

eth6      Link encap:Ethernet  HWaddr E0:63:DA:5A:D2:47
          inet6 addr: fe80::e263:daff:fe5a:d247/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:947 errors:0 dropped:2 overruns:0 frame:0
          TX packets:15 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:130443 (127.3 KiB)  TX bytes:3530 (3.4 KiB)

eth7      Link encap:Ethernet  HWaddr E0:63:DA:5A:D2:48
          inet6 addr: fe80::e263:daff:fe5a:d248/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:941 errors:0 dropped:2 overruns:0 frame:0
          TX packets:15 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:130124 (127.0 KiB)  TX bytes:3530 (3.4 KiB)

eth8      Link encap:Ethernet  HWaddr E0:63:DA:5A:D2:49
          inet addr:185.227.74.155  Bcast:0.0.0.0  Mask:255.255.252.0
          inet6 addr: fe80::e263:daff:fe5a:d249/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:18220 errors:0 dropped:0 overruns:0 frame:0
          TX packets:7564 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:21189101 (20.2 MiB)  TX bytes:1503141 (1.4 MiB)

eth9      Link encap:Ethernet  HWaddr E0:63:DA:5A:D2:4A
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:10000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

honeypot0 Link encap:Ethernet  HWaddr 1E:DD:AB:00:23:6B
          inet addr:192.168.1.99  Bcast:192.168.1.99  Mask:255.255.255.255
          inet6 addr: fe80::1cdd:abff:fe00:236b/64 Scope:Link
          UP BROADCAST RUNNING NOARP  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

ifb0      Link encap:Ethernet  HWaddr 9E:CB:E7:05:6E:FC
          inet6 addr: fe80::9ccb:e7ff:fe05:6efc/64 Scope:Link
          UP BROADCAST RUNNING NOARP  MTU:1500  Metric:1
          RX packets:10894 errors:0 dropped:0 overruns:0 frame:0
          TX packets:10894 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:21021377 (20.0 MiB)  TX bytes:21021377 (20.0 MiB)

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:12944 errors:0 dropped:0 overruns:0 frame:0
          TX packets:12944 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:7894650 (7.5 MiB)  TX bytes:7894650 (7.5 MiB)

switch0   Link encap:Ethernet  HWaddr E2:63:DA:5A:D2:41
          inet6 addr: fe80::e063:daff:fe5a:d241/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:10807 errors:0 dropped:0 overruns:0 frame:0
          TX packets:22182 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:1975083 (1.8 MiB)  TX bytes:22161186 (21.1 MiB)

switch0.1 Link encap:Ethernet  HWaddr E2:63:DA:5A:D2:41
          inet6 addr: fe80::e063:daff:fe5a:d241/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:10692 errors:0 dropped:20 overruns:0 frame:0
          TX packets:21421 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:1970039 (1.8 MiB)  TX bytes:22241040 (21.2 MiB)

switch0.10 Link encap:Ethernet  HWaddr E2:63:DA:5A:D2:41
          inet6 addr: fe80::e063:daff:fe5a:d241/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:10 errors:0 dropped:0 overruns:0 frame:0
          TX packets:704 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:808 (808.0 B)  TX bytes:217670 (212.5 KiB)

Dit is de ifconfig waarbij het apparaat enkele minuten aan is. De ping staat ongeveer 2 minuten aan.

[ed1703]

EricDi schreef op zaterdag 22 februari 2020 @ 10:01:
[...]


[...]

Dit is de ifconfig waarbij het apparaat enkele minuten aan is. De ping staat ongeveer 2 minuten aan.

dropped packets is meestal een driver-issue (kun je nu niets mee en zal het waarschijnlijk ook niet zijn), MTU (jumbo frames), of speed/duplex-settings. Ik zou dat laatste vooral eens checken.
Dus ik ga wat dat betreft met @Tylen mee.. eerst speed/duplex checken, Firmware upgraden. e.d. , daarna pas kabel vervangen voor een andere. Ik ken echt voorbeelden dat het soms wel eens kritisch is.. maar in deze ben ik daar zeker nog niet van overtuigd.

[_Arthur]

EricDi schreef op zaterdag 22 februari 2020 @ 10:01:

code:

honeypot0 Link encap:Ethernet  HWaddr 1E:DD:AB:00:23:6B
          inet addr:192.168.1.99  Bcast:192.168.1.99  Mask:255.255.255.255
          inet6 addr: fe80::1cdd:abff:fe00:236b/64 Scope:Link
          UP BROADCAST RUNNING NOARP  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

Dit is de ifconfig waarbij het apparaat enkele minuten aan is. De ping staat ongeveer 2 minuten aan.

Je Honeypot staat wel aan; zeker weten dat je al je IPS/IDS etc etc uitstaat? Geen DNS filters? Geen Deep Packet inspection etcetc

Eigenlijk terug naar een zo kaal mogelijke (default) config.

[ Voor 3% gewijzigd door _Arthur op 22-02-2020 10:20 ]

[EricDi]

_Arthur schreef op zaterdag 22 februari 2020 @ 10:20:
[...]

Je Honeypot staat wel aan; zeker weten dat je al je IPS/IDS etc etc uitstaat? Geen DNS filters? Geen Deep Packet inspection etcetc

Eigenlijk terug naar een zo kaal mogelijke (default) config.

Je hebt gelijk. Ik had een backup terug gezet. Ik doe nu weer een set-default en begin opnieuw.

Clean install, auto optimize uitgezet zodat ie geen instellingen zelf gaat veranderen. Niets aangepast in Unifi:

code:

# ifconfig
br0       Link encap:Ethernet  HWaddr E2:63:DA:5A:D2:41
          inet addr:192.168.1.1  Bcast:0.0.0.0  Mask:255.255.255.0
          inet6 addr: fe80::e479:2dff:feae:1a2f/64 Scope:Link
          UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1500  Metric:1
          RX packets:12052 errors:0 dropped:0 overruns:0 frame:0
          TX packets:10295 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:1560735 (1.4 MiB)  TX bytes:47819426 (45.6 MiB)

eth0      Link encap:Ethernet  HWaddr E0:63:DA:5A:D2:41
          inet6 addr: fe80::e263:daff:fe5a:d241/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:727 errors:0 dropped:0 overruns:0 frame:0
          TX packets:15 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:149036 (145.5 KiB)  TX bytes:3326 (3.2 KiB)

eth1      Link encap:Ethernet  HWaddr E0:63:DA:5A:D2:42
          inet6 addr: fe80::e263:daff:fe5a:d242/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:727 errors:0 dropped:0 overruns:0 frame:0
          TX packets:15 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:149036 (145.5 KiB)  TX bytes:3326 (3.2 KiB)

eth10     Link encap:Ethernet  HWaddr E0:63:DA:5A:D2:4B
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:10000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

eth2      Link encap:Ethernet  HWaddr E0:63:DA:5A:D2:43
          inet6 addr: fe80::e263:daff:fe5a:d243/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:729 errors:0 dropped:0 overruns:0 frame:0
          TX packets:15 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:149128 (145.6 KiB)  TX bytes:3326 (3.2 KiB)

eth3      Link encap:Ethernet  HWaddr E0:63:DA:5A:D2:44
          inet6 addr: fe80::e263:daff:fe5a:d244/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:735 errors:0 dropped:0 overruns:0 frame:0
          TX packets:15 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:149474 (145.9 KiB)  TX bytes:3326 (3.2 KiB)

eth4      Link encap:Ethernet  HWaddr E0:63:DA:5A:D2:45
          inet6 addr: fe80::e263:daff:fe5a:d245/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:730 errors:0 dropped:0 overruns:0 frame:0
          TX packets:15 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:149174 (145.6 KiB)  TX bytes:3326 (3.2 KiB)

eth5      Link encap:Ethernet  HWaddr E0:63:DA:5A:D2:46
          inet6 addr: fe80::e263:daff:fe5a:d246/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:734 errors:0 dropped:0 overruns:0 frame:0
          TX packets:15 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:149428 (145.9 KiB)  TX bytes:3326 (3.2 KiB)

eth6      Link encap:Ethernet  HWaddr E0:63:DA:5A:D2:47
          inet6 addr: fe80::e263:daff:fe5a:d247/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:735 errors:0 dropped:0 overruns:0 frame:0
          TX packets:15 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:149474 (145.9 KiB)  TX bytes:3326 (3.2 KiB)

eth7      Link encap:Ethernet  HWaddr E0:63:DA:5A:D2:48
          inet6 addr: fe80::e263:daff:fe5a:d248/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:728 errors:0 dropped:0 overruns:0 frame:0
          TX packets:15 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:149082 (145.5 KiB)  TX bytes:3326 (3.2 KiB)

eth8      Link encap:Ethernet  HWaddr E0:63:DA:5A:D2:49
          inet addr:185.227.74.155  Bcast:0.0.0.0  Mask:255.255.252.0
          inet6 addr: fe80::e263:daff:fe5a:d249/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:2279905 errors:0 dropped:0 overruns:0 frame:0
          TX packets:3176297 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:3075625997 (2.8 GiB)  TX bytes:3172042587 (2.9 GiB)

eth9      Link encap:Ethernet  HWaddr E0:63:DA:5A:D2:4A
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:10000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:56986 errors:0 dropped:0 overruns:0 frame:0
          TX packets:56986 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:28691429 (27.3 MiB)  TX bytes:28691429 (27.3 MiB)

switch0   Link encap:Ethernet  HWaddr E2:63:DA:5A:D2:41
          inet6 addr: fe80::e063:daff:fe5a:d241/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:12102 errors:0 dropped:0 overruns:0 frame:1
          TX packets:39286 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:1565471 (1.4 MiB)  TX bytes:48847786 (46.5 MiB)

switch0.1 Link encap:Ethernet  HWaddr E2:63:DA:5A:D2:41
          inet6 addr: fe80::e063:daff:fe5a:d241/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:12024 errors:0 dropped:19 overruns:0 frame:0
          TX packets:10294 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:1559622 (1.4 MiB)  TX bytes:47821056 (45.6 MiB)

En op mijn client een ping -n 60 8.8.8.8:

code:

Ping statistics for 8.8.8.8:
    Packets: Sent = 60, Received = 50, Lost = 10 (16% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 1ms, Average = 0ms

[ed1703]

EricDi schreef op zaterdag 22 februari 2020 @ 10:33:
[...]
Je hebt gelijk. Ik had een backup terug gezet. Ik doe nu weer een set-default en begin opnieuw.

Clean install, auto optimize uitgezet zodat ie geen instellingen zelf gaat veranderen. Niets aangepast in Unifi:

Serieus zeg? W.T.F. een apparaat wat last krijgt van packet-loss en gaat pakketten droppen als je een extra interface en wat bijbehorende software aanzet? Wat is dit in godsnaam voor software-rommel?

[EricDi]

Het aanpassen van de link speed van de lan ports van de UDM pro werkt trouwens niet. Ik heb mijn client als test op 100 FDX gezet. Zelfs na een reboot blijft die op 1,000 FDX.

Tijd voor een refund

[ Voor 6% gewijzigd door EricDi op 22-02-2020 10:53 ]

[ed1703]

EricDi schreef op zaterdag 22 februari 2020 @ 10:52:
Het aanpassen van de link speed van de lan ports van de UDM pro werkt trouwens niet. Ik heb mijn client als test op 100 FDX gezet. Zelfs na een reboot blijft die op 1,000 FDX.

Ik zou zo ondertussen dat ding RMA'en of iig eens met support in de chat gaan als je alle mogelijke zaken al hebt getest.
Je bent wat de UDM lijn betreft niet de enige:
https://community.ui.com/...97-42a6-9a68-b9251acba85c
We kunnen zo ondertussen de conclusie wel trekken dat het geen apparaat is zonder grote hobbels in het traject om volwassen te worden.

[ Voor 29% gewijzigd door ed1703 op 22-02-2020 11:00 ]

[EricDi]

ed1703 schreef op zaterdag 22 februari 2020 @ 10:54:
[...]

Ik zou zo ondertussen dat ding RMA'en of iig eens met support in de chat gaan als je alle mogelijke zaken al hebt getest.

Support heeft het ge-escaleerd naar hun tech dienst. Geen ETA wanneer ze bij me terugkomen. Ik zit nu nog binnen een week, dus kan de bak nu gewoon nog terug sturen zonder vragen

[Slonzo]

EricDi schreef op zaterdag 22 februari 2020 @ 08:13:
Voor mensen met een udm pro. Zouden jullie een ping test kunnen doen en de packet loss kunnen melden?

Ping -n 60 8.8.8.8

Hier ook 0% loss.
Maar je bent niet de eerste die het meldt; ik zag het op de UI forums ook al voorbij komen.
Even afwachten of RMA'en?

[EricDi]

Slonzo schreef op zaterdag 22 februari 2020 @ 11:08:
[...]

Hier ook 0% loss.
Maar je bent niet de eerste die het meldt; ik zag het op de UI forums ook al voorbij komen.
Even afwachten of RMA'en?

Kun je nog een ding testen? Als je de link speed van een port op 10 FDX zet, werkt dat dan ook werkelijk voor jou? Ik blijf 1000mbps krijgen terwijl Unifi 10FDX aangeeft.

[xbeam]

EricDi schreef op zaterdag 22 februari 2020 @ 08:13:
Voor mensen met een udm pro. Zouden jullie een ping test kunnen doen en de packet loss kunnen melden?

Ping -n 60 8.8.8.8

Bekend probleem. Er lijken hardware/driver problemen te zijn. Hier stort het internet verkeer een paar keer per dag helemaal in.

Zie ook dit filmpje. Op 1min30 zie dit tijds een ipref review ook gebeuren.
YouTube: Testing Ubiquiti UDM-Pro LAN-to-WAN Throughput

[ Voor 25% gewijzigd door xbeam op 22-02-2020 14:09 ]

[rally]

Hier ook drama.

Internet dat regelmatig helemaal weg valt, trage verbindingen, packet loss.

Ergste was gisteren. Geen internet en op de UDM Pro stond de melding “no WAN interface configured”
Reprovision bood geen soelaas, en na een reboot stond er de melding “recovery mode, please contact support”

En toen was ik er even klaar mee. De USG is weer terug en ik kijk de komende weken even aan of Ubiquiti in staat is de boel stabiel te krijgen.

Anders gaat deze in de verkoop en wacht ik op de UMG of zo....

[ed1703]

rally schreef op zaterdag 22 februari 2020 @ 14:04:
Hier ook drama.

Internet dat regelmatig helemaal weg valt, trage verbindingen, packet loss.

Ergste was gisteren. Geen internet en op de UDM Pro stond de melding “no WAN interface configured”
Reprovision bood geen soelaas, en na een reboot stond er de melding “recovery mode, please contact support”

En toen was ik er even klaar mee. De USG is weer terug en ik kijk de komende weken even aan of Ubiquiti in staat is de boel stabiel te krijgen.

Anders gaat deze in de verkoop en wacht ik op de UMG of zo....

Als sommigen het wel hebben en anderen niet, dan is het tijd om firmware, geactiveerde services en andere zaken te vergelijken.

[rally]

ed1703 schreef op zaterdag 22 februari 2020 @ 14:42:
[...]

Als sommigen het wel hebben en anderen niet, dan is het tijd om firmware, geactiveerde services en andere zaken te vergelijken.

Mij FW is 1.6.5 en controller versie 5.12.65

De factory FW was overigens nog erger. Daar liep hij iedere paar uur vast.

[Slonzo]

EricDi schreef op zaterdag 22 februari 2020 @ 12:04:
Kun je nog een ding testen? Als je de link speed van een port op 10 FDX zet, werkt dat dan ook werkelijk voor jou? Ik blijf 1000mbps krijgen terwijl Unifi 10FDX aangeeft.

Ben momenteel niet thuis, maar wat ik wel kan zeggen is dat het er voor mij op begint te lijken dat de provisioning van de poorten niet altijd goed gaat. Ik had problemen met de LAN SFP+ poort, die kreeg geen link en bleef waarschlijnlijk in de 'Disabled' state vasthangen (waar ze eerder op stond). Na een factory reset (en restore van de backup) werkte het opeens wél.

Verder heb ik geen framedrops, maar ik lijk wel een hogere latency met meer 'spikes' te hebben. Voorheen (USG3P) bleef de latency redelijk constant op zo'n ~10 à 20ms, nu zie ik veel meer fluctuatie tussen 10ms en 50ms, zowel overdag als 's nachts (zonder throughput):



FW 1.6.4
Controller 5.12.59

[ Voor 3% gewijzigd door Slonzo op 22-02-2020 15:12 ]

[abusimbal]

EricDi schreef op zaterdag 22 februari 2020 @ 08:13:
Voor mensen met een udm pro. Zouden jullie een ping test kunnen doen en de packet loss kunnen melden?

Ping -n 60 8.8.8.8

Ping statistics for 8.8.8.8:
Packets: Sent = 60, Received = 60, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 13ms, Maximum = 25ms, Average = 16ms

[LightStar]

rally schreef op zaterdag 22 februari 2020 @ 14:47:
[...]

Mij FW is 1.6.5 en controller versie 5.12.65

De factory FW was overigens nog erger. Daar liep hij iedere paar uur vast.

Ik draai vanaf het begin de default controller en firmware, tot op heden nog geen issue’s gehad.

[rally]

LightStar schreef op zaterdag 22 februari 2020 @ 18:22:
[...]


Ik draai vanaf het begin de default controller en firmware, tot op heden nog geen issue’s gehad.

Dat is volgens mij 1.6.4 en 5.12.59.

Daar had ik ook veel time-outs en stabiliteitsproblemen mee.

Mijn internet is overigens van T-mobile en loopt via een tranceiver en op VLAN 300 (geen IPv6)

Wellicht dat dit ook van invloed is.

[Mech-Warrior]

EricDi schreef op zaterdag 22 februari 2020 @ 08:13:
Voor mensen met een udm pro. Zouden jullie een ping test kunnen doen en de packet loss kunnen melden?

Ping -n 60 8.8.8.8

Geen packet loss bij mij.
FW 1.6.4.2306

Systeem is nog steeds stabiel.
En mijn vriendin klaagt nog niet en die is de eerste om problemen op te merken 😂

[ Voor 17% gewijzigd door Mech-Warrior op 22-02-2020 22:32 ]

[ewoutw]

Weet iemand of het mogelijk is om met een USG3P een VLAN over zowel lan1 als lan/wan2 te gooien. Zodat die als een L3 switch gaat werken?

Zit met 2 fysieke locaties (binnen het zelfde gebouw) waar ik eigenlijk het zelfde Broadcast-domein wil hebben.

[ Voor 1% gewijzigd door ewoutw op 22-02-2020 23:29 . Reden: Typo ]

[nero355]

ewoutw schreef op zaterdag 22 februari 2020 @ 23:28:
Weet iemand of het mogelijk is om met een USG3P een VLAN over zowel lan1 als lan/wan2 te gooien. Zodat die als een L3 switch gaat werken?

Zit met 2 fysieke locaties (binnen het zelfde gebouw) waar ik eigenlijk het zelfde Broadcast-domein wil hebben.

Lees een stukje terug of gebruik de Search : rinkel in "[Ubiquiti-apparatuur] Ervaringen & Discussie - Deel 3"

[EricDi]

rally schreef op zaterdag 22 februari 2020 @ 21:14:
[...]

Dat is volgens mij 1.6.4 en 5.12.59.

Daar had ik ook veel time-outs en stabiliteitsproblemen mee.

Mijn internet is overigens van T-mobile en loopt via een tranceiver en op VLAN 300 (geen IPv6)

Wellicht dat dit ook van invloed is.

Ik heb een static IP dat ik via dhcp van me glasvezel provider krijg.
Lijkt erop dat het IP gebonden is aan het MAC address van de router. Als ik me edgerouter aansluit heb ik een ander static IP.

Als ik de gateway en next hop van de verbinding kan achterhalen kan ik het fixed IP van de edgerouter bij de UDM pro gebruiken. Wie weet maakt dat nog een verschil.

Iemand een tip om daar achter te komen?

[_Arthur]

EricDi schreef op zondag 23 februari 2020 @ 09:37:
[...]
Ik heb een static IP dat ik via dhcp van me glasvezel provider krijg.
Lijkt erop dat het IP gebonden is aan het MAC address van de router. Als ik me edgerouter aansluit heb ik een ander static IP.

Als ik de gateway en next hop van de verbinding kan achterhalen kan ik het fixed IP van de edgerouter bij de UDM pro gebruiken. Wie weet maakt dat nog een verschil.

Iemand een tip om daar achter te komen?

Je kan het MAC adres van de Edgerouter wan-port clonen naar je UDMPro wan-port.

Voorbeeld hoe ifconfig werkt (wlan0 is er natuurlijk niet op de UDMPro).

code:

ifconfig wlan0 down
ifconfig wlan0 hw ether 00:28:C7:0A:42:A2
ifconfig wlan0 up

Dit overleefd trouwens niet een reboot/herstart.

[ Voor 3% gewijzigd door _Arthur op 23-02-2020 09:41 ]

[EricDi]

_Arthur schreef op zondag 23 februari 2020 @ 09:41:
[...]

Je kan het MAC adres van de Edgerouter wan-port clonen naar je UDMPro wan-port.

Voorbeeld hoe ifconfig werkt (wlan0 is er natuurlijk niet op de UDMPro).

code:

ifconfig wlan0 down
ifconfig wlan0 hw ether 00:28:C7:0A:42:A2
ifconfig wlan0 up

Dit overleefd trouwens niet een reboot/herstart.

aaah slim. Zal het testen

[Tylen]

EricDi schreef op zondag 23 februari 2020 @ 09:37:
[...]
Ik heb een static IP dat ik via dhcp van me glasvezel provider krijg.
Lijkt erop dat het IP gebonden is aan het MAC address van de router. Als ik me edgerouter aansluit heb ik een ander static IP.

Als ik de gateway en next hop van de verbinding kan achterhalen kan ik het fixed IP van de edgerouter bij de UDM pro gebruiken. Wie weet maakt dat nog een verschil.

Iemand een tip om daar achter te komen?

Een ip verkregen middels dhcp is geen static ip maar een dynamic ip. Ik denk niet dat je provider het waardeert als je een ip static maakt op je router terwijl je eigenlijk een ander ip op dat mac adres behoort te hebben.

[ed1703]

Tylen schreef op zondag 23 februari 2020 @ 09:55:
[...]


Een ip verkregen middels dhcp is geen static ip maar een dynamic ip. Ik denk niet dat je provider het waardeert als je een ip static maakt op je router terwijl je eigenlijk een ander ip op dat mac adres behoort te hebben.

Zolang je het laat lopen via DHCP maakt het weinig uit met een mac-address spoof.
Static opgeven werkt soms niet omdat een aantal providers werkt met dhcp-snooping en arp-inspection.
Lang verhaal kort: 2 databases worden tegen elkaar gehouden en als je in de dhcp-snooping tabel ontbreekt krijg je geen toegang tot het netwerk.

[Tylen]

ed1703 schreef op zondag 23 februari 2020 @ 10:03:
[...]

Zolang je het laat lopen via DHCP maakt het weinig uit met een mac-address spoof.
Static opgeven werkt soms niet omdat een aantal providers werkt met dhcp-snooping en arp-inspection.
Lang verhaal kort: 2 databases worden tegen elkaar gehouden en als je in de dhcp-snooping tabel ontbreekt krijg je geen toegang tot het netwerk.

Mac adres spoofing had ik het niet over .

[ed1703]

Tylen schreef op zondag 23 februari 2020 @ 10:28:
[...]
Mac adres spoofing had ik het niet over .

Aanname dat je de andere berichten ook had gelezen

[Duskwither]

Ik heb sinds een paar dagen een UDM pro en lijk een (voor mij) vreemd DNS probleem te hebben. Vanaf een willekeurige machine in mijn netwerk kan ik prima een nslookup doen naar een machine, maar zodra ik de machine wil pingen op hostname lijkt name resolution te falen.

• Ik heb alle alpha en beta features uitgezet
• Mijn netwerk is zo plat als maar zijn kan, vooralsnog geen vlans oid
• Ik kan in de UDM geen settings vinden die ik verder aan zou moeten willen passen
• Het valt me op dat de in de DHCP instellingen meegegeven "domain name" niet op mijn windows machine aan lijkt te komen, hij staat niet in de dns search suffix

Test vanaf mijn Windows machine

code:

C:\Users\duskwither>nslookup plex
Server:  unifi.localdomain
Address:  192.168.1.1

Name:    plex
Address:  192.168.1.201

######

C:\Users\duskwither>ping plex
Ping request could not find host plex. Please check the name and try again.

######

C:\Users\duskwither>ping 192.168.1.201

Pinging 192.168.1.201 with 32 bytes of data:
Reply from 192.168.1.201: bytes=32 time<1ms TTL=64

Relevante ipconfig /all gegevens:

code:

Default Gateway . . . . . . . . . : 192.168.1.1
DHCP Server . . . . . . . . . . . : 192.168.1.1
DNS Servers . . . . . . . . . . . : 192.168.1.1

Op de UDM zelf gaat het wel goed:

code:

# nslookup plex
Server:    127.0.0.1
Address 1: 127.0.0.1 localhost

Name:      plex
Address 1: 192.168.1.201 plex

# ping plex
PING plex (192.168.1.201): 56 data bytes
64 bytes from 192.168.1.201: seq=0 ttl=64 time=0.290 ms

Iemand nog een briljante tip om dit verder te troubleshooten of zelfs op te lossen?

Update 11:47:
ping plex. (met een punt erachter dus) werkt wel...

Update 12:32:
En het antwoord lijkt een reboot van de UDM

[ Voor 4% gewijzigd door Duskwither op 23-02-2020 12:32 ]

[HKLM_]

Gisteren komt mijn vrouw thuis met een coolblue pakje, geeft het pakje aan * HKLM_ vervroegt verjaardags cadeautje

Zit er een Ubnt 8 poort switch in krijg ik als reden dan kan je mooi de kabel zooi onder de tv gaan opruimen

Vanmorgen direct maar eens actie in de tent en mijn topology ziet er nu wel gaaf uit al zeg ik het zelf

[EricDi]

Duskwither schreef op zondag 23 februari 2020 @ 11:38:
Ik heb sinds een paar dagen een UDM pro en lijk een (voor mij) vreemd DNS probleem te hebben. Vanaf een willekeurige machine in mijn netwerk kan ik prima een nslookup doen naar een machine, maar zodra ik de machine wil pingen op hostname lijkt name resolution te falen.

• Ik heb alle alpha en beta features uitgezet
• Mijn netwerk is zo plat als maar zijn kan, vooralsnog geen vlans oid
• Ik kan in de UDM geen settings vinden die ik verder aan zou moeten willen passen
• Het valt me op dat de in de DHCP instellingen meegegeven "domain name" niet op mijn windows machine aan lijkt te komen, hij staat niet in de dns search suffix

Test vanaf mijn Windows machine

code:

C:\Users\duskwither>nslookup plex
Server:  unifi.localdomain
Address:  192.168.1.1

Name:    plex
Address:  192.168.1.201

######

C:\Users\duskwither>ping plex
Ping request could not find host plex. Please check the name and try again.

######

C:\Users\duskwither>ping 192.168.1.201

Pinging 192.168.1.201 with 32 bytes of data:
Reply from 192.168.1.201: bytes=32 time<1ms TTL=64

Relevante ipconfig /all gegevens:

code:

Default Gateway . . . . . . . . . : 192.168.1.1
DHCP Server . . . . . . . . . . . : 192.168.1.1
DNS Servers . . . . . . . . . . . : 192.168.1.1

Op de UDM zelf gaat het wel goed:

code:

# nslookup plex
Server:    127.0.0.1
Address 1: 127.0.0.1 localhost

Name:      plex
Address 1: 192.168.1.201 plex

# ping plex
PING plex (192.168.1.201): 56 data bytes
64 bytes from 192.168.1.201: seq=0 ttl=64 time=0.290 ms

Iemand nog een briljante tip om dit verder te troubleshooten of zelfs op te lossen?

Update 11:47:
ping plex. (met een punt erachter dus) werkt wel...

Welcome to the Nightmare Machine Pro party.

[rinkel]

HKLM_ schreef op zondag 23 februari 2020 @ 11:45:
Gisteren komt mijn vrouw thuis met een coolblue pakje, geeft het pakje aan * HKLM_ vervroegt verjaardags cadeautje

Zit er een Ubnt 8 poort switch in krijg ik als reden dan kan je mooi de kabel zooi onder de tv gaan opruimen

Vanmorgen direct maar eens actie in de tent en mijn topology ziet er nu wel gaaf uit al zeg ik het zelf

[Afbeelding]

Is die core1-switch ook een 8-poort?
Kan natuurlijk niet
Tellen is ook een kunst...

[ Voor 4% gewijzigd door rinkel op 23-02-2020 12:20 ]

[HKLM_]

rinkel schreef op zondag 23 februari 2020 @ 12:19:
[...]

Is die core1-switch ook een 8-poort?
Kan natuurlijk niet

Neen dat is nog een 16 poort 150watt

[RobertMe]

Over switches gesproken... Had gehoopt dat de USW Flex Mini intussen beschikbaar zou zijn in de EU store, maar helaas. Maar nog "erger": in de US store is die niet meer op voorraad. Eigenlijk vermoed ik dus dat ze maar een batch hebben/hadden en die in de US verkocht is. En we in de EU dus moeten wachten totdat die in de US goed leverbaar is. En zelfs als die in de EU beschikbaar komt lijkt de kans mij dus groot dat je er snel bij moet zijn.

Mogelijk dat beperkte voorraad ook komt door Coronavirus? Grote kans dat UI ook veel in China laat produceren en dat dat nu stil ligt en de nu verkochte uit een kleine batch komt van voordat China in lockdown ging.

[gastje01]

RobertMe schreef op zondag 23 februari 2020 @ 12:27:
Over switches gesproken... Had gehoopt dat de USW Flex Mini intussen beschikbaar zou zijn in de EU store, maar helaas. Maar nog "erger": in de US store is die niet meer op voorraad. Eigenlijk vermoed ik dus dat ze maar een batch hebben/hadden en die in de US verkocht is. En we in de EU dus moeten wachten totdat die in de US goed leverbaar is. En zelfs als die in de EU beschikbaar komt lijkt de kans mij dus groot dat je er snel bij moet zijn.

Mogelijk dat beperkte voorraad ook komt door Coronavirus? Grote kans dat UI ook veel in China laat produceren en dat dat nu stil ligt en de nu verkochte uit een kleine batch komt van voordat China in lockdown ging.

Gewoon wachten tot de voorraad stabiel is geworden lijkt me? Voor die prijs kan ik er ook wel 2 kwijt hier in huis. Nu zit ik aan de duurdere 8p versie vast en dat is t me niet waard op dit moment.

[Ethirty]

RobertMe schreef op zondag 23 februari 2020 @ 12:27:
Mogelijk dat beperkte voorraad ook komt door Coronavirus? Grote kans dat UI ook veel in China laat produceren en dat dat nu stil ligt en de nu verkochte uit een kleine batch komt van voordat China in lockdown ging.

Ik gok dat dit er zeker mee te maken kan hebben. Alles wat daar vandaan komt is vertraagd, want volgens mij mag/mocht er vrijwel niks op transport.

Maar goed, UI staat er ook om bekend de eerste batches veel te klein te bestellen, waardoor alles in een dag weg is.

[Slonzo]

Duskwither schreef op zondag 23 februari 2020 @ 11:38:
Iemand nog een briljante tip om dit verder te troubleshooten of zelfs op te lossen?

Update 11:47:
ping plex. (met een punt erachter dus) werkt wel...

Update 12:32:
En het antwoord lijkt een reboot van de UDM

Als de UDM je DNS server is (en dus niet pihole of iets dergelijks), probeer ipv

code:

ping plex

dan eerst eens

code:

ping plex.localdomain

(of welk domein je ook geconfigureerd hebt in de UDM). Wellicht werkt dat wel goed.

Lijkt op NetBIOS vs DNS gedoe.

[xbeam]

Voor de UDM-pro bezitters onder ons.
1.6.5 RC 6 is beschikbaar. Deze heeft Wat verbeteringen op RC3

Features
Add SFP+ speed configuration.
Add ability to download a support file.
Improvements
Improved switch stability.
Improved LCM timing for recovery image.
Improved filesystem reliability.
Improved response time for LAN subnet change when it conflicts with WAN.
Improved storage status UI. (Improved in RC4)
Improve internet detection on setup. (New in RC4)
Allow 2FA field to be auto-filled.

Bugfixes
Fix upload of large images on a remote connection.
Fix support for fallback DNS (1.1.1.1).
Fix issue with CPU load gauge.
Fix PPPoE with DHCPv6.
Fix advanced setup. (New in RC4)
Fix updating status on LCM. (New in RC6)
Fix NAT hairpin interface matching.
Fix timezone sync between container and host.
Fix disconnects from the Network Controller during cloud outage.

Fix the issue causing network loss and missed heartbeat for UDM. (New in RC4)
Various bug fixes and enhancements. (New in RC4)
Minor UI fixes and updates.

Known issues
With user-defined firewall rules on both IPv4 and IPv6, a commit error will result from duplicate rule IDs. Those with only IPv4 or only IPv6 user-added rules, or who have not added any custom firewall rules, are not impacted.
Login page UI does not display any errors when using invalid credentials.
Auto-upgrade frequency settings lacks "Disabled" option.
You might experience some UI issues on Chrome 80 ( Chrome Canary v82.x resolves this ).
Instructions

Let op dit is een BETA en kan je UDM-pro beschadigen

code:

ubnt-upgrade https://fw-download.ubnt.com/data/udm/7e96-udmpro-1.6.5-rc.6-9d953d030b504b258336335aa445ca55.bin

[ Voor 88% gewijzigd door xbeam op 23-02-2020 14:32 ]

[ed1703]

Ethirty schreef op zondag 23 februari 2020 @ 13:37:
[...]

Ik gok dat dit er zeker mee te maken kan hebben. Alles wat daar vandaan komt is vertraagd, want volgens mij mag/mocht er vrijwel niks op transport.

Maar goed, UI staat er ook om bekend de eerste batches veel te klein te bestellen, waardoor alles in een dag weg is.

Waarschijnlijk dezelfde reden waarom de UDMP al 2 weken via de eigen UI-store in de VS niet meer bestelbaar is.

[Slonzo]

xbeam schreef op zondag 23 februari 2020 @ 14:25:
Voor de UDM-pro bezitters onder ons.
1.6.5 RC 6 is beschikbaar.

Let op dit is BETA

ubnt-upgrade https://fw-download.ubnt....04b258336335aa445ca55.bin

Linkje naar de UI thread/changelog is wel zo handig:
https://community.ui.com/...98-4fb7-9772-5b94b071f87b

En dan vooral dit:

Known issues

With user-defined firewall rules on both IPv4 and IPv6, a commit error will result from duplicate rule IDs. Those with only IPv4 or only IPv6 user-added rules, or who have not added any custom firewall rules, are not impacted.
Login page UI does not display any errors when using invalid credentials.
Auto-upgrade frequency settings lacks "Disabled" option.
You might experience some UI issues on Chrome 80 ( Chrome Canary v82.x resolves this ).

[ Voor 35% gewijzigd door Slonzo op 23-02-2020 14:29 ]

[_Arthur]

xbeam schreef op zondag 23 februari 2020 @ 14:25:
Voor de UDM-pro bezitters onder ons.
1.6.5 RC 6 is beschikbaar. Deze heeft Wat verbeteringen op RC3

Nou, hopelijk lost dit eea problemen op voordegene die problemen ondervinden.

Ik blijft nog wel even op 1.6.4.2306 / 5.12.59 hangen totdat er een nieuwe Stable is.