Internet data verbruik van één apparaat monitoren

[kwibox]

is het niet handiger om op de server wat te installeren wat met een externe partij praat zodat jij weet of ie online is? als je ESP geen verbinding meer heeft werkt het ook niet. Plus dat je nog moet DIY'n voor een manier om je een berichtje te sturen (wat wederom niet gaat werken als je ESP ook geen verbinding meer heeft).

Daarbij moet je altijd rekening mee houden dat je server misschien af een toe een pakketje mist of dat er een korte onderbreking is. Dan is het fijn dat je niet ineens meldingen krijgt dat ie down terwijl dat niet het geval is. Menig tooltje wat daarvoor gemaakt is houd daar rekening mee.

Niet het wiel opnieuw willen uitvinden is mijn advies. Wel leuk natuurlijk om te doen, maar ik heb het vermoeden dat dit niet voor de hobby gebruikt gaat worden.

[ Voor 5% gewijzigd door kwibox op 13-02-2023 11:59 ]

[Scott81]

RiDo78 schreef op maandag 13 februari 2023 @ 11:47:
Als je toch al Ubiquiti spul gebruikt, koop dan dit speeltje: uitvoering: Ubiquiti UniFi Switch Flex Mini (per stuk)

Dan kun je ook je ethernetpoort op dezelfde manier meten. Wel zo duidelijk, wel zo consistent.

Dat is wellicht een mooie optie.
Nu vraag ik me wel af of dat in mijn geval werkt. Ik heb alleen de accesspoint van Ubiquiti. De software is op een synology geïnstalleerd (via docker).
Als ik de switch koop, kan ik dat dan gewoon koppelen in mijn situatie? Of heb ik dan meer hardware nodig van Ubiquiti?


@kwibox wat bedoel je met "is het niet handiger om op de server wat te installeren wat met een externe partij praat zodat jij weet of ie online is?"

Gebeurt dan niet hetzelfde? Continu verbinding maken om te checken of het online is en indien ik geen verbinding heb is het offline? Of snap ik niet helemaal wat je bedoeld?

Het doel is juist om op het apparaat (de ESP32) een melding te geven als er geen verbinding gemaakt kan worden met de server

[ Voor 5% gewijzigd door Scott81 op 13-02-2023 12:02 ]

[kwibox]

Ja dat werkt op dezelfde manier als je ESP. Alleen het voordeel is dat die externe partij vaak wel een noodstroom backup heeft en vaak een failover uplink.

Het stukje software op je server maakt dan bv elke minuut even kort verbinding met een externe partij en verzend dan ook nog wat nuttige informatie (load, disk smart status enz.). Mocht je server geen verbinding meer hebben, kan ie dat natuurlijk niet. Dan gaat er bij die externe partij na een x tijd een melding uit naar jou toe om je te attenderen dat je server eruit ligt.

Wat is het probleem trouwens dat je je hebt met data? Ook al ping je elke seconde, dan verstook je nog maar ~500MB / maand...? Als je het elke minuut doet gebruik je nog niet eens 10 MB / maand. Dat is zelfs op een mobiel abbo te verwaarlozen.

Maar wat als je niet in de buurt ben van die ESP? Dan heb je er toch nog steeds niks aan? Tis toch veel handiger een email/sms/push notificatie te krijgen als er wat uit ligt?

[ Voor 18% gewijzigd door kwibox op 13-02-2023 12:36 ]

[Scott81]

Ik weet even niet of ik je volg.

Wat werkt op dezelfde manier, de Switch of het verbinden met de server?

De server die ik ping is niet zelf gehost maar bij een extern bedrijf in combinatie met SLA. Hier zit noodstroom backup etc achter. Zodra deze server offline is wil ik juist een melding geven op de ESP32 (die lokaal hangt). Het is geen tool om te zien of mijn servers online zijn maar een apparaat dat de server nodig heeft om te kunnen functioneren.

Ik heb ooit het probleem gehad dat een klant via een 4g abonnement werkte. Hier kreeg ik toen een flinke rekening van omdat het apparaat (destijds een raspberry pi) teveel internet verbruikte. Dit wil ik niet nog een keer meemaken.

[kwibox]

@Scott81 als je maar de helft van het verhaal verteld, krijg je natuurlijk ook een half antwoord.

Met deze constructie is je ESP defacto een indicator of ie zelf een internet verbinding heeft; ik acht de kans dat je server onverwacht offline is, een stuk kleiner dan de verbinding waar die ESP aan hangt.

Wellicht heeft je server iets van ilo (OOB-management of IPMI). Daar kan je misschien ook iets mee en lijkt mij een stuk handiger voor monitoring dan een ESP.

Als je je ESP gaat gebruiken voor meer dan alleen een "je server is offline, doe er wat aan"-melding is het natuurlijk zeker zinvol om een packetsniffer setup te maken, door met bv je PC als bridge, om je apparaat te ontwikkelen. Maar dan is mij niet duidelijk wat je nu precies gaat doen met de ESP.

Je kunt prima met een raw socket zelf een ICMP ping maken en versturen. Aangezien je dan zelf het packet maakt, weet je ook hoeveel bytes daar inzitten. Neem dan een ruime marge (15% ofzo) voor overhead en dan kan kan je echt wel inschatten hoeveel data er weg gaat. Voor een simpele ping een packetsniffer setup optuigen lijkt mij met een kanon op een mug schieten.

[ Voor 22% gewijzigd door kwibox op 13-02-2023 12:28 ]

[jeroen3]

4G abonnementen ronden sessies vaak omhoog af. Een ping van een paar bytes ronden ze dan af naar kilobytes.

Is het niet eenvoudiger om via een uptime robot service zijn api o.i.d. te werken?

[kwibox]

jeroen3 schreef op maandag 13 februari 2023 @ 12:37:
4G abonnementen ronden sessies vaak omhoog af. Een ping van een paar bytes ronden ze dan af naar kilobytes.

Is het niet eenvoudiger om via een uptime robot service zijn api o.i.d. te werken?

Precies zoiets bedoel ik. Dan heb je ook nog wat aan je monitoring. Leuk om te weten of je server nog icmp pings beantwoord, maar veel zinvoller is toch om te weten of je HDD's aan het doodgaan zijn of je applicatie is gecrashed.

[Scott81]

Ik denk dat mijn vraag niet duidelijk genoeg was of we de verkeerde kant op gaan.

De ESP32 hangt op een willekeurige plek (bij klanten).
Op deze ESP wil ik een melding geven zodra er geen internet is (of de verbinding met onze server verbreekt, wat dus ook zal gebeuren zodra er geen internet is op de ESP).
De oplossing lijkt mij om elke X seconde te pingen naar mijn server. Monitoren of HDD's etc aan het doodgaan zijn is dus niet van toepassing hier.

Nu gaat mijn vraag niet over het pingen maar over het verbruik wat dit "pingen" dan kost. Dit wil ik monitoren. De ESP is geen tool om te kijken of m'n servers online zijn maar een apparaat dat alleen KAN werken als ik verbinding heb met mijn servers. De ESP hangt dus niet in mijn eigen netwerk en een bridge of iets dergelijks kan ik dan ook niet instellen.

[kwibox]

@Scott81 bij het ontwikkelen van je ping functionaliteit kan je toch gewoon een bridge opzetten met je pc zodat je dan kan meten hoeveel data ie verstookt? (wat nogmaals, als je het mij vraagt niet, de moeite waard is omdat het bizar weinig is bij typisch gebruik).

Als je je ESP bij je klanten ophangt heb je natuurlijk geen brigde oid nodig, het verbruik is niet anders als de taken van de ESP niet veranderen...

[ Voor 58% gewijzigd door kwibox op 13-02-2023 13:15 ]

[Scott81]

Ah okay, ik snap nu dat je dit alleen tijdens ontwikkelen bedoeld.
Dit idee kan wellicht alleen ben ik geen experts in netwerken.

Ik werk op een Macbook Pro dus een ethernet connector heb ik helaas niet (ook niet in de hub voor randapparatuur).

Nu gaf iemand de tip om een Ubiquiti UniFi Switch Flex Mini te kopen (die bij Ubiquiti zelf maar 29€ kost) te kopen. Als ik het hiermee ook kan monitoren ben ik geholpen. Maar weet niet of dit zo gemakkelijk werkt (zoals gezegd, ben geen netwerk expert)

Als ik de ESP32 via WiFi koppel kan ik bepaalde gegevens uitlezen, maar bij elke seconde pingen blijven de "Activity (24hrs)" gegevens gelijk.

Dit is de data die ik hierop uitlees:

Uptime
1h 5m 11s
Activity (24hrs)
167 KB
Rx Rate
72.0 Mbps
Tx Rate
26.0 Mbps
Down Pkts/Bytes
4.969 / 296 KB
Up Pkts/Bytes
5.099 / 472 KB

Naar welke gegevens moet ik kijken, en als ik die ubiquiti swicht koop, kan ik dan hetzelfde zien via kabel?

[kwibox]

Ook voor de mac heb je usb ethernet dongels en usb wifi dongels,

Waar komt dat overzicht vandaan?

Overigens lijkt pingen nu niet nodig, als je ESP nog op op een andere manier verbinding maakt met de server voor "de functionaliteit die alleen kan werken bij verbinding met je server", dan merk je toch vanzelf als ie eruit ligt?

Ik begrijp nu nog iets minder van de beoogde functie van die ESP, zal wel aan mij liggen.

[ Voor 67% gewijzigd door kwibox op 13-02-2023 13:23 ]

[Scott81]

Uit het Unify Network overzicht waarbij ik de ESP32 selecteer als verbonden netwerk device

[kwibox]

Kan best zijn dat unify icmp pings niet mee telt bij activiteit omdat ze niet onder tcp of udp verkeer vallen.

Gaan de counters daar onder wel omhoog? Dan zou ik daar naar kijken.

Tis natuurlijk nogal gerommel in de marge met deze kleine hoeveelheden.

[Orion84]

Scott81 schreef op maandag 13 februari 2023 @ 11:44:
Ik krijg het niet voor elkaar via de ESP i.c.m. de W5500 module het ICMP ping aan te roepen. Ik gebruik dus mijn eigen "ping" functie en weet niet of dit ook de 74kb per request verbruikt.

Het is een module die met mijn eigen online server communiceert, en zodra de server niet bereikbaar is (liefst zo snel mogelijk) wil ik dit kunnen vermelden op het display.

Dan kan je toch gewoon een netwerk capture tool op je server installeren en daarmee de verschillende berichten die worden gestuurd door je ESP opvangen. Dan kan je per soort bericht kijken hoe groot dat is en op basis daarvan doorrekenen wat het verbruik per dag/maand is afhankelijk van bepaalde keuzes in hoe vaak je communiceert etc.

[Scott81]

Down Pkts/Bytes en Up Pkts/Bytes gaan wel omhoog. De "Ping" functie is momenteel het enige wat aangeroepen wordt op de ESP32

Orion84 schreef op maandag 13 februari 2023 @ 13:20:
[...]

Dan kan je toch gewoon een netwerk capture tool op je server installeren en daarmee de verschillende berichten die worden gestuurd door je ESP opvangen. Dan kan je per soort bericht kijken hoe groot dat is en op basis daarvan doorrekenen wat het verbruik per dag/maand is afhankelijk van bepaalde keuzes in hoe vaak je communiceert etc.

Waarschijnlijk wel, maar zover rijkt mijn kennis niet. En ik wil wel al het verbruik meenemen, niet dat ik iets mis doordat ik het op de foute manier monitor. Ik ga er van uit dat de router of accesspoint alle data heeft?

[ Voor 73% gewijzigd door Scott81 op 13-02-2023 13:25 ]

[kwibox]

@Scott81 kan je ook vertellen wat dan die "de functionaliteit die alleen kan werken bij verbinding met je server" ongeveer inhoud? Ik snap namelijk nu even niet wat de toegevoegde waarde is van dat pingen.

Edit: ja ip wel, maar ¨not all data is created equal" want er moeten keuzes gemaakt worden. ICMP pings zijn namelijk vrij low level in de ip stack en zou je soms als "overhead" kunnen zien. Daarom kan ik mij voorstellen dat ze niet altijd meegeteld worden.

[ Voor 38% gewijzigd door kwibox op 13-02-2023 13:29 ]

[Scott81]

De module met de ESP32 module is een kaartlezer. Zodra de gebruiker zijn kaart voor de module houdt moet er een call worden gemaakt naar de server. Nu kan ik telkens bij het lezen van de kaart pas controleren of de verbinding met de server gemaakt kan worden maar ik wil dit al op het scherm laten zien zodra de verbinding wegvalt. Dan kan de klant al actie ondernemen voordat de kaart uitgelezen wordt.

[Orion84]

Scott81 schreef op maandag 13 februari 2023 @ 13:23:
[...]
Waarschijnlijk wel, maar zover rijkt mijn kennis niet.

Dat is natuurlijk iets waar we je prima mee op weg kunnen helpen hier. Als je die richting in wil is het in elk geval goed om te weten wat voor OS die server draait.

En ik wil wel al het verbruik meenemen, niet dat ik iets mis doordat ik het op de foute manier monitor.

Uiteraard. Al neem ik aan dat gezien de beperkte functionaliteit van zo'n ESP, je een goed beeld hebt van welk verkeer er zou moeten zijn (zodat je ook goed kan vaststellen of je van al dat verkeer het volume in kaart hebt gebracht).

Ik ga er van uit dat de router of accesspoint alle data heeft?

In die zin dat het verkeer door die apparatuur loopt. Maar tenzij de apparatuur die je nu hebt ook functionaliteit heeft om dat verkeer inzichtelijk te maken, heb je daar dus niet per se wat aan. Genoeg apparatuur die vooral ontworpen is om zo efficient mogelijk de data door te zetten en daardoor beperkt is in monitoring etc. Mijn Asus kan bijvoorbeeld heel gedetailleerd al het verkeer monitoren/loggen, maar als ik die functie aan zet gaat wel (een deel van) de hardware acceleratie uit, waardoor de performance van het netwerk inkakt.

Ik ben verder niet bekend met de apparatuur die je hebt, dus ik laat het aan anderen om te kijken of je daar wat mee kan.

[Scott81]

Mijn setup:

Router: DrayTek Vigor 2927
AccessPoint: Ubiquiti U6-Lite
Server: Ubuntu 20.04.3 LTS

De server waar ik tijdens ontwikkeling mee verbind staat lokaal op een Virtuele Machine op mijn Synology
Zodra de ontwikkeling klaar is wordt er verbinding gemaakt naar mijn productie server (draait niet lokaal) maar daarbij zou het verbruik hetzelfde moeten blijven.

Nu zal ik wellicht verschillende dingen vergeten te vermelden maar dan hoor ik dat graag.

[kwibox]

Tja dan ligt het er aan hoe belangrijk die paslezer is. Voor deuren/toegangsbeheer werken die dingen met een lokaal systeem. Het is natuurlijk absoluut onwenselijk als je internet eruit ligt en je deur gaat niet meer open.

Voor andere functionaliteiten kan je misschien iets cachen lokaal op de ESP? Als ik je zou mogen adviseren: dit zijn dingen waar vanaf dag 1 over na moet denken, afhankelijk van de applicatie en het belang van behoud van functie vs up to date gegevens).

- Een deur die niet opengaat als er geen internet is: absoluut onacceptabel (=behoud functionaliteit prio)
- Een in- en uitklok paslezer, die werktijden bijhoud: lokaal cachen en periodiek met server babbelen (=mix van functionaliteit/up to date, maar geen van beide kritisch)
- Een pin terminal, internet down? geen pin. (=up to date gegevens prio)

[RiDo78]

Een plaatje zegt meer dan 1000 woorden, dus even een screenshotje gemaakt.



Dit kun je zien bij die Ubiquiti flex switch. Je kunt per poort een mooi grafiekje opvragen en door met de muis erover heen te gaan krijg je wat cijfers te zien.

Zoals je ziet op poort 1 is de switch verbonden met de router (Ubiquiti Dream Router), op poort 2 hangt een AC Pro accesspoint en op poort 3 heb ik mijn RPi met Home Assistant geplugd.

[Orion84]

Scott81 schreef op maandag 13 februari 2023 @ 13:38:
Mijn setup:

Router: DrayTek Vigor 2927
AccessPoint: Ubiquiti U6-Lite
Server: Ubuntu 20.04.3 LTS

De server waar ik tijdens ontwikkeling mee verbind staat lokaal op een Virtuele Machine op mijn Synology
Zodra de ontwikkeling klaar is wordt er verbinding gemaakt naar mijn productie server (draait niet lokaal) maar daarbij zou het verbruik hetzelfde moeten blijven.

Nu zal ik wellicht verschillende dingen vergeten te vermelden maar dan hoor ik dat graag.

Draai op je server dit commando (IP adres vervangen door dat van de ESP):
tcpdump host 192.168.2.2

En je krijgt netjes alle pakketjes te zien die heen en weer gaan tussen ESP en server, incl. een "length" die het aantal bytes vertegenwoordigt. Op die manier kan je in elk geval alvast prima vaststellen hoe groot die ping pakketjes zijn (en de responses daarop).

Je kan evt. met de -w flag ook een output file meegeven aan dat commando en dan die output file analyseren in een tool als Wireshark.
Zie voor wat meer voorbeelden: https://danielmiessler.com/study/tcpdump/

Edit: zo te zien is die length wel de length van de data, zonder de headers van de pakketjes, dus dat is niet helemaal wat je zoekt bedenk ik me nu. Maar door het naar een capture file te schrijven kan je het alsnog wel uitzoeken op die manier. De pakketjes volledig weergeven met de -A flag kan ook een manier zijn om de volledige grootte te bepalen.

Edit2: zo krijg je ook de volledige size te zien (de eerstgenoemde length na de protocol indicatie):
tcpdump -v host 192.168.2.2

Dit is bijvoorbeeld de output voor een ping (source en destination heb ik even vervangen door "esp" en "server"):

code:

14:02:18.837022 IP (tos 0x0, ttl 128, id 60240, offset 0, flags [none], proto ICMP (1), length 60)
    esp > server: ICMP echo request, id 1, seq 66, length 40
14:02:18.837081 IP (tos 0x0, ttl 64, id 35118, offset 0, flags [none], proto ICMP (1), length 60)
    server > esp: ICMP echo reply, id 1, seq 66, length 40

Dus 60 bytes heen en 60 bytes terug.

[ Voor 29% gewijzigd door Orion84 op 13-02-2023 14:06 ]

[Scott81]

@kwibox Bedankt voor je reacties maar dit gaat niet meer echt over mijn vraag. Ik wil graag monitoren hoeveel mijn ESP32 verbruikt. Niet meer en niet minder. Het is geen toegangsbeheer en ik heb er duidelijk over nagedacht wat de gevolgen kunnen en mogen zijn van geen internet toegang. Het enige wat ik wil ik monitoren hoeveel mijn ESP32 gebruikt zodat ik daarop een gepast aantal "pings" kan doen om niet teveel internet te verbruiken.

@RiDo78 Bedankt voor de screenshot! Ik heb geen Dream router maar de Unify Software via een Synology Docker omgeving. Als ik de switch koop, krijg ik dan ongeveer hetzelfde te zien? Jouw grafiek ziet er enorm duidelijk uit, deze krijg ik nu via de Accesspoint echter niet te zien als ik mijn ESP32 (dus via WiFi verbonden) aanklik. Of moet ik dit op een andere manier tevoorschijn krijgen?

[kwibox]

@Scott81 nee dat klopt, gezien je vraag gaat over iets vrij triviaals en ik niet het idee krijg dat je weet waar je mee bezig bent, vond ik het belangrijk om dat gezegd te hebben.

Succes met je project.

[Scott81]

Aparte redenatie naar mijn idee. Mijn vraag gaat over het monitoren van het internet verbruik, niet of het verstandig is het apparaat afhankelijk te laten zijn van internet. In mijn geval is dat absoluut noodzakelijk en zodra internet wegvalt heeft het hele apparaat geen "nut" meer. Dus ja, er is over nagedacht en ik weet in dit geval waar ik mee bezig ben.

@RiDo78 Ik heb bij mijn ESP32 geen extra gegevens als ik op "Insights" klik. Kan het dat ik niet de juiste apparaat heb? Of ligt dit wellicht aan de software variant die ik via Docker draai (Dacht dat ik thuis wel meer informatie had bij insights)

[dion_b]

Scott81 schreef op maandag 13 februari 2023 @ 13:48:
[...]

@RiDo78 Bedankt voor de screenshot! Ik heb geen Dream router maar de Unify Software via een Synology Docker omgeving. Als ik de switch koop, krijg ik dan ongeveer hetzelfde te zien? Jouw grafiek ziet er enorm duidelijk uit, deze krijg ik nu via de Accesspoint echter niet te zien als ik mijn ESP32 (dus via WiFi verbonden) aanklik. Of moet ik dit op een andere manier tevoorschijn krijgen?

Dit is hoe het in Wireshark eruit ziet:


Per MAC-adres netjes overzicht van verzonden/ontvangen verkeer.

Als je een pcap hebt van verkeer vanuit je apparaat (ik gebruik mijn MikroTik router voor captures, maar je kunt ook gewoon mirror poort op je Draytek doen zoals @Orion84 hierboven uitlegt.

Met een capture filter kun je zorgen dat je alleen verkeer vangt van je eigen device, dan 24u aan laten staan en je hebt wat je zoekt.

[RiDo78]

Scott81 schreef op maandag 13 februari 2023 @ 13:57:
Aparte redenatie naar mijn idee. Mijn vraag gaat over het monitoren van het internet verbruik, niet of het verstandig is het apparaat afhankelijk te laten zijn van internet. In mijn geval is dat absoluut noodzakelijk en zodra internet wegvalt heeft het hele apparaat geen "nut" meer. Dus ja, er is over nagedacht en ik weet in dit geval waar ik mee bezig ben.

@RiDo78 Ik heb bij mijn ESP32 geen extra gegevens als ik op "Insights" klik. Kan het dat ik niet de juiste apparaat heb? Of ligt dit wellicht aan de software variant die ik via Docker draai (Dacht dat ik thuis wel meer informatie had bij insights)

Ik ga via:
UNIFI DEVICES -> <switchnaam> -> Ports -> Port Management en klik daar op Insights.

Bij de AP kan ik niet een dergelijke grafiek per client te voorschijn halen.

Dus ik denk dat als jij de flex-switch gewoon adopteert in je Unifi Network, je net zoveel kunt zien als ik. Maar ik moet wel zeggen, ik heb nooit de software los gedraaid. Dus helemaal zeker ben ik daar niet van,

[Scott81]

Bedankt voor de reactie! Ik ga een switch bestellen. Hopelijk haal ik daar genoeg data uit.
Het gene waar ik naar moet kijken is de som van Down Bytes / Up Bytes? Of Activity (24hrs)

[W1ck1e]

Scott81 schreef op maandag 13 februari 2023 @ 13:48:
.. Bedankt voor je reacties maar dit gaat niet meer echt over mijn vraag.

Ik hoop dat ik mij wel beperk tot jouw vraag. Heb je niet een smartphone die je als hotspot kan instellen waarnaar je connect met je device over wifi zodat je op je telefoon kan zien hoeveel data je verstookt met je pings ?

[Scott81]

Dat heb ik maar dan meet ik alsnog alleen de data die via WiFi verbruikt wordt.
En aangezien ik aparte code moet schrijven voor WiFi en aparte code voor Ethernet wil ik beide graag individueel kunnen meten.

[W1ck1e]

@Scott81 Niet jouw vraag maar wel de mijne: waarom is het zo dat jouw device meer of minder data gebruikt met wifi dan met ethernet ?

[Scott81]

Omdat ik op de ESP32 twee aparte libraries moet gebruiken. Eentje voor WiFi en eentje voor Ethernet. Nu weet ik dus niet hoezeer dit verschilt in het gebruik van data. Ook bevat de WiFi library een "Ping" functie die ik kan aanroepen maar de Ethernet functie niet. Deze moet ik dus zelf maken. En juist bij het maken van deze eigen ping functie wil ik kijken of ik niet teveel data verbruik.

[W1ck1e]

RiDo78 schreef op maandag 13 februari 2023 @ 13:43:
Een plaatje zegt meer dan 1000 woorden, dus even een screenshotje gemaakt. ...

Dat klopt maar jouw plaatje kost ook meer dan 1000 woorden het is namelijk 177 kilobytes groot.

[sh4d0wman]

Wat gaat je ESP praten met de server? Hij kan best pingbaar zijn maar als je ESP een (web)service gebruikt welke er uit ligt.... Dan heb je alsnog niks

Dus teken het eens uit of verduidelijk het hier. Anders verdoe je wellicht een hoop tijd. Je hebt tevens beperkte ruimte op een ESP. Dus hou code zo kort en simpel mogelijk.

[Scott81]

Ik breng een verbinding tot stand via de "Ethernet.connect(server, port)" functie.
Hier krijg ik 0 of 1 terug. Dit is mijn "Ping". Zodra internet eruit ligt (of de server) weet ik dus dat ik 0 terug krijg en geef ik de melding.

De ESP heeft 16MB flash dus dit is voldoende voor mijn applicatie

[Orion84]

Draai gewoon even tcpdump op je server (zie onderaan mijn inmiddels bijgewerkte reactie: Orion84 in "Internet data verbruik van één apparaat monitoren") en je weet binnen no-time hoe groot zo'n connectie test is.

Tip: tcpdump vangt dat verkeer ook op als je server niet luistert op die poort, dus je kan ook dat negatieve scenario testen om te zien of de library op je ESP dan bijvoorbeeld onder water meerdere pogingen doet of iets dergelijks.

[ Voor 32% gewijzigd door Orion84 op 13-02-2023 15:10 ]

[Scott81]

Daar krijg ik dit resultaat bij (ethernet)

15:12:27.530968 IP (tos 0x0, ttl 128, id 17, offset 0, flags [DF], proto TCP (6), length 40)
192.168.2.67.51069 > devserver04.http: Flags [F.], cksum 0xe699 (correct), seq 2492078888, ack 51757278, win 2048, length 0
15:12:27.531724 IP (tos 0x0, ttl 64, id 25356, offset 0, flags [DF], proto TCP (6), length 40)
devserver04.http > 192.168.2.67.51069: Flags [.], cksum 0x85e0 (incorrect -> 0xf3a9), ack 1, win 64239, length 0
15:12:27.532066 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has _gateway tell 192.168.2.67, length 46
15:12:27.532400 IP (tos 0x0, ttl 64, id 25357, offset 0, flags [DF], proto TCP (6), length 40)
devserver04.http > 192.168.2.67.51069: Flags [F.], cksum 0x85e0 (incorrect -> 0xf3a8), seq 1, ack 1, win 64239, length 0
15:12:27.533105 IP (tos 0x0, ttl 128, id 19, offset 0, flags [DF], proto TCP (6), length 40)
192.168.2.67.51069 > devserver04.http: Flags [.], cksum 0xe698 (correct), ack 2, win 2048, length 0
15:12:27.582714 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has devserver04 tell 192.168.2.67, length 46
15:12:27.582729 ARP, Ethernet (len 6), IPv4 (len 4), Reply devserver04 is-at 02:11:32:27:ed:e5 (oui Unknown), length 28
15:12:27.582992 IP (tos 0x0, ttl 128, id 20, offset 0, flags [DF], proto TCP (6), length 44)
192.168.2.67.51070 > devserver04.http: Flags [S], cksum 0x9627 (correct), seq 2743404773, win 2048, options [mss 1460], length 0
15:12:27.583016 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 44)
devserver04.http > 192.168.2.67.51070: Flags [S.], cksum 0x85e4 (incorrect -> 0x1905), seq 2716461110, ack 2743404774, win 64240, options [mss 1460], length 0
15:12:27.583217 IP (tos 0x0, ttl 128, id 21, offset 0, flags [DF], proto TCP (6), length 40)
192.168.2.67.51070 > devserver04.http: Flags [.], cksum 0x23b3 (correct), ack 1, win 2048, length 0

Dit is één ping. De grootte is dus? Alle "lengths" opgeteld

[DataGhost]

Dat zijn 4 pings, 3 pongs een actieve TCP-verbinding die gesloten wordt, de handshake van een nieuwe TCP-verbinding, 2 ARP requests en 1 ARP reply. Pings zijn het niet want het is over TCP.

[ Voor 56% gewijzigd door DataGhost op 13-02-2023 15:18 ]

[Scott81]

Dat is dus het resultaat van de "Ethernet.connect(host, port)" functie. Vandaar dat ik graag wil monitoren wat er gebeurd

[RiDo78]

W1ck1e schreef op maandag 13 februari 2023 @ 14:54:
[...]

Dat klopt maar jouw plaatje kost ook meer dan 1000 woorden het is namelijk 177 kilobytes groot.

Flauw . . .

In de tijd van mijn eerste PC met 8086 CPU en 640 kb geheugen zou ik me daar druk over maken.

[Orion84]

Het lijkt of je de tcpdump ergens halverwege de communicatie pas hebt aangezet? Of je ESP houdt de connectie open tot aan de volgende call?

Zoals @DataGhost al zegt zijn de eerste paar regels van het sluiten van een vorige connectie, daarna volgt het opzetten van een nieuwe (met nog wat ARP verkeer tussendoor, dat zou ik negeren).

Met de methode die je gebruikt zou het normaalgesproken dus deze sequence moeten zijn:

code:

SYN ->
         <- SYN.ACK
ACK ->

FIN ->
          <- ACK
          <- FIN
ACK ->

Als ik de pakketjes uit je capture dan in die volgorde zet is het dus:

code:

15:12:27.582992 IP (tos 0x0, ttl 128, id 20, offset 0, flags [DF], proto TCP (6), length 44)
192.168.2.67.51070 > devserver04.http: Flags [S], cksum 0x9627 (correct), seq 2743404773, win 2048, options [mss 1460], length 0
15:12:27.583016 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 44)
devserver04.http > 192.168.2.67.51070: Flags [S.], cksum 0x85e4 (incorrect -> 0x1905), seq 2716461110, ack 2743404774, win 64240, options [mss 1460], length 0
15:12:27.583217 IP (tos 0x0, ttl 128, id 21, offset 0, flags [DF], proto TCP (6), length 40)
192.168.2.67.51070 > devserver04.http: Flags [.], cksum 0x23b3 (correct), ack 1, win 2048, length 0
15:12:27.530968 IP (tos 0x0, ttl 128, id 17, offset 0, flags [DF], proto TCP (6), length 40)
192.168.2.67.51069 > devserver04.http: Flags [F.], cksum 0xe699 (correct), seq 2492078888, ack 51757278, win 2048, length 0
15:12:27.531724 IP (tos 0x0, ttl 64, id 25356, offset 0, flags [DF], proto TCP (6), length 40)
devserver04.http > 192.168.2.67.51069: Flags [.], cksum 0x85e0 (incorrect -> 0xf3a9), ack 1, win 64239, length 0
15:12:27.532400 IP (tos 0x0, ttl 64, id 25357, offset 0, flags [DF], proto TCP (6), length 40)
devserver04.http > 192.168.2.67.51069: Flags [F.], cksum 0x85e0 (incorrect -> 0xf3a8), seq 1, ack 1, win 64239, length 0
15:12:27.533105 IP (tos 0x0, ttl 128, id 19, offset 0, flags [DF], proto TCP (6), length 40)
192.168.2.67.51069 > devserver04.http: Flags [.], cksum 0xe698 (correct), ack 2, win 2048, length 0

En dat is zo te zien 288 bytes alles bij elkaar.

[ Voor 3% gewijzigd door Orion84 op 13-02-2023 15:33 ]

[Scott81]

Dat kan, ik connect tijdens het pingen, maar misschien was mijn "export" van de 2e keer pingen. Hij zal de vorige verbinding wellicht sluiten en een nieuwe starten.

De vraag is of dit uberhaupt kan en ik geen problemen krijg met andere verbindingen die tijdens het pingen gemaakt worden. Een echte "ping" functie zou dus een heel stuk beter zijn

[Orion84]

Scott81 schreef op maandag 13 februari 2023 @ 15:33:
Dat kan, ik connect tijdens het pingen, maar misschien was mijn "export" van de 2e keer pingen. Hij zal de vorige verbinding wellicht sluiten en een nieuwe starten.

De vraag is of dit uberhaupt kan en ik geen problemen krijg met andere verbindingen die tijdens het pingen gemaakt worden. Een echte "ping" functie zou dus een heel stuk beter zijn

Goed om even uit te zoeken inderdaad, je wilt niet dat je een connectie maakt om een kaart te verifiëren en die connectie (voordat je antwoord hebt) onderbroken wordt door een "ping" connectie.

Op zich is het maken van een daadwerkelijke verbinding natuurlijk wel een goede test, beter dan een ping. Want daarmee weet je ook of daadwerkelijk de server luistert op die poort (en niet enkel of ie in algemene zin bereikbaar is over het netwerk).

Maar je zal wel even uit moeten zoeken hoe dat precies werkt in die ESP en hoe de testverbindingen en de echte verbindingen elkaar niet bijten.

[ Voor 23% gewijzigd door Orion84 op 13-02-2023 15:37 ]

[W1ck1e]

RiDo78 schreef op maandag 13 februari 2023 @ 15:26:
[...]

Flauw . . .

In de tijd van mijn eerste PC met 8086 CPU en 640 kb geheugen zou ik me daar druk over maken.

Klopt, maar het gaat mij erom dat vaak een goed stukje tekst toch duidelijker en preciezer is dan een afbeelding. Maar niet in dit geval.

[Scott81]

Ik heb nu dit als "ping".
Is dit beter, en hoe bepaal ik nu de grootte? Is dit 76 bytes, of moet ik meerdere resultaten optellen?

15:54:16.650689 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has devserver04 tell 192.168.2.67, length 46
15:54:16.650721 ARP, Ethernet (len 6), IPv4 (len 4), Reply devserver04 is-at 02:11:32:27:ed:e5 (oui Unknown), length 28
15:54:16.651259 IP (tos 0x0, ttl 255, id 5, offset 0, flags [DF], proto ICMP (1), length 96)
192.168.2.67 > devserver04: ICMP echo request, id 182, seq 2, length 76
15:54:16.651286 IP (tos 0x0, ttl 64, id 46446, offset 0, flags [none], proto ICMP (1), length 96)
devserver04 > 192.168.2.67: ICMP echo reply, id 182, seq 2, length 76

[Minitrooper]

Ik ga hier ook eens wat roepen :-)

Wat ik tot nu toe begrepen heb: een externe partij heeft jouw ESP in handen. Om de x tijd "pingt" die jouw server die ergens op het internet hangt, en indien ok: groen schermpje, indien niet ok: rood schermpje.

Mijn bedenkingen:
- ping is kinda fire&forget: kan aan de wifi liggen, het internet, jouw server...
- indien met ping werken, zou ik dit "gelaagd" durven aanpakken, vooral handig voor debugging:
1. ping IP van ESP zelf: wifi module niet geladen: dit kan gedetecteerd worden en op scherm getoond wordne
2. ping IP van de gateway (via WiFi/Eth verkregen): dit kan al tonen dat de wifi/eth al dan niet okee is
3. ping (bv) 8.8.8.8: dan weet je dat IP gewijs internet bereikbaar is, maar DNS misschien nog niet
4. ping "jouwserver.com": succes!
- de hamvraag is of jij "jouwserver.com" op ICMPs wil laten antwoorden!?
- waarom niet werken met een MQTT (ev. met SSL) voor een iets interactievere manier van communiceren met jouw server

Want mijn buik zegt mij: als je 10 ESP's hebt draaien, dan wil jij toch "pro-actief" weten dat er al 9 de voorbije 10 minuten niets doorgestuurd hebben. Kan je automatisch mailtje uitsturen van: reboot die ESP eens en hang 'm aan de wifi/ethernet. En dan op het scherm de 4 levels van ping doorgeven, weet je ineens op wiens kop je kloppen mag.

En last but not least: als er 1 van de 10 hun "subscription licentie" niet betaald, kan je simpelweg de MQTT access dichtsmijten.

Just my 2c ;-)

[Orion84]

Scott81 schreef op maandag 13 februari 2023 @ 15:55:
Ik heb nu dit als "ping".
Is dit beter, en hoe bepaal ik nu de grootte? Is dit 76 bytes, of moet ik meerdere resultaten optellen?


[...]

96 bytes heen en 96 bytes terug.

[Scott81]

Minitrooper schreef op maandag 13 februari 2023 @ 18:37:
Ik ga hier ook eens wat roepen :-)

Wat ik tot nu toe begrepen heb: een externe partij heeft jouw ESP in handen. Om de x tijd "pingt" die jouw server die ergens op het internet hangt, en indien ok: groen schermpje, indien niet ok: rood schermpje.

Mijn bedenkingen:
- ping is kinda fire&forget: kan aan de wifi liggen, het internet, jouw server...
- indien met ping werken, zou ik dit "gelaagd" durven aanpakken, vooral handig voor debugging:
1. ping IP van ESP zelf: wifi module niet geladen: dit kan gedetecteerd worden en op scherm getoond wordne
2. ping IP van de gateway (via WiFi/Eth verkregen): dit kan al tonen dat de wifi/eth al dan niet okee is
3. ping (bv) 8.8.8.8: dan weet je dat IP gewijs internet bereikbaar is, maar DNS misschien nog niet
4. ping "jouwserver.com": succes!
- de hamvraag is of jij "jouwserver.com" op ICMPs wil laten antwoorden!?
- waarom niet werken met een MQTT (ev. met SSL) voor een iets interactievere manier van communiceren met jouw server

Want mijn buik zegt mij: als je 10 ESP's hebt draaien, dan wil jij toch "pro-actief" weten dat er al 9 de voorbije 10 minuten niets doorgestuurd hebben. Kan je automatisch mailtje uitsturen van: reboot die ESP eens en hang 'm aan de wifi/ethernet. En dan op het scherm de 4 levels van ping doorgeven, weet je ineens op wiens kop je kloppen mag.

En last but not least: als er 1 van de 10 hun "subscription licentie" niet betaald, kan je simpelweg de MQTT access dichtsmijten.

Just my 2c ;-)

Grotendeels doe ik dit inderdaad. Als eerste controleer ik of ik kabel heb ingeplugd of wifi credentials heb ontvangen. Indien kabel is ingeplugd kijk ik of ik een ip adres heb gekregen. Geen kabel en wifi credentials, dan kijk ik of ik verbinding heb met de router en of ik ip adres heb.

Daarna wil ik dus kijken of ik verbinding heb met mijn server. In principe “boeit” het me niks of google online is. Snap het idee maar wat win ik er mee? Als mijn server online is, “weet” ik genoeg. Mqtt kan ook maar weet niet of ik dan problemen krijg met poorten die bij klanten open moeten staan etc. Nu doe ik alles via http(s) requests dus die poorten staan (iig in 99.999%) van de gevallen open. (Maakte in een vorige module rechtstreeks verbinding met mijn database via poort 3306 maar dat werd nogal eens geblokkeerd bij klanten)

Daarbij vraag ik me af of mqtt minder data verbruikt? Aangezien deze verbinding continu actief is. Hierbij krijg ik inderdaad wel direct een “melding” als server offline is.

In principe monitor ik nu continu of er verbinding is met de router. Zo niet probeer ik opnieuw te verbinden. Rebooten zou dus “ingebouwd” zitten in code.

Wat licenties betreft, alles verbind dus met onze server en zodra de licentie “verlopen” is werkt niets meer op de module aangezien de module bij elke call “meestuurd” welk id esp32 het is

@Orion84 bedankt! Dat valt mee qua verbruik

[Scott81]

Nu ben ik er toch verder over gaan nadenken en vraag me af of MQTT idd niet een betere oplossing is.
Alleen de vraag (en ik snap dat hier geen eenduidig antwoord in is), maar in hoeverre is in zakelijke netwerken (bij klanten) MQTT toegankelijk of juist geblokkeerd.

Is dit iets wat standaard geblokkeerd wordt of juist niet? Ik weet (of heb gehoord) dat veel slimme apparaten tegenwoordig MQTT gebruiken, maar ook bij de zakelijke / professionelere apparatuur?

[Minitrooper]

Goede vraag gezien MQTT op unieke poortjes draait - zie https://stackoverflow.com/questions/55443931/changing-mqtt-default-port-to-443 met onderin:

You'd run MQTT over Secure Websockets on port 443. Websocket based protocols should always be run on the normal HTTP/HTTPS ports for best compatibility with proxies/firewalls. (Just because emqtt has chosen 8084 doesn't mean you have to stick to it)

Als in: gaat het altijd & overal werken? Nee, maar het is een grotere kans dan poort 8883 in ieder geval, poort 443 staat 9 kans op 10 open.

[ Voor 7% gewijzigd door Minitrooper op 14-02-2023 10:56 ]

[Scott81]

Nu draai ik de mqtt server dan opdezelfde fysieke server dan de web applicatie. Kan ik voor beide poort 443 gebruiken? Of toch beter poort 8883 gebruiken en als eis stellen dat de klant deze poort niet blokkeert


Nu heb ik op mijn test server MQTT geïnstalleerd, via php verbind ik met de MQTT server (localhost) en vang ik alle subscriptions op. Is dit wel de juiste structuur? Want nu is de PHP code eigenlijk de "client" die gebruik maakt van dezelfde MQTT server (broker) dan waar de ESP32 verbinding mee maakt.
Of moet ik op een of andere manier via PHP een MQTT server opzetten?

[Minitrooper]

Nee hoor, één device (de ESP) published, een ander device (of de server zelf) subscribed van de channels. Dat kan in PHP, of een andere taal.

[Scott81]

Ik ben nu even aan het testen maar ik snap iets niet. Als ik nu (met de nieuwe ubiquiti switch) kijk naar het verbruik dan zie ik het volgende:

Uptime
7m 15s
Activity (24hrs)
19.4 KB
Down Pkts/Bytes
2.442 / 668 KB
Up Pkts/Bytes
20 / 1.90 KB

Activity staat op 19.4 KB (al 7m 15s) maar Down is al op 668 KB en Up op 1.90

Down is 668 KB op 7 minuten dus bijna 100KB / minuut?
Per dag is dat dus 144000KB oftewel 140MB
Per maand dus 4.3 GB?

Dit kan toch niet lijkt me? Hoe verkeerd kijk ik?

Het enige wat ik doe is verbinding maken met de MQTT server en één publish uitvoeren. Daarna doe ik niks behalve de verbinding tot stand houden

[ Voor 12% gewijzigd door Scott81 op 14-02-2023 16:42 ]

[Scott81]

Niemand?

[Scott81]

Ik snap niet hoe de gegevens in Unify Network Controller werken.

Ik meet best wat data die de ESP32 gebruikt. Door alleen verbinding te maken met de MQTT verbinding monitor ik ongeveer 14MB verbruik per dag. Dus door helemaal niks te doen is dat 436MB per maand.

Wat nog aparter is, als ik de EPS32 helemaal leeg schrijf (dus geen libraries etc inlaad), ik hetzelfde meet.
Is dit logisch? De ethernet poort op de switch knippert ook (gelijk met de poort waar de router op aangesloten zit).

Nu draai ik de Unify Network Controller in een Virtuele omgeving op mijn nas. Alle gegevens die ik monitor zijn Local Network Activity (24hrs)

Internet Activity (24hrs) geeft 0.00B aan, maar dit is bij alle clients zo, ook op mijn macbook die nonstop gebruik maakt van internet.

Het verbruik van een apparaat meter kan toch niet zo moeilijk zijn...

[laurens0619]

die manier van meten lijkt mij niet betrouwbaar, zit ook bv multicast/broadcast bij bv. (plus dat ik niet durf te leunen op de metrics van ubiuiqiti maar dat is een andere discussie)

Ik zou een packet capture maken en daar in wireshark filteren op het echte verkeer

[Scott81]

laurens0619 schreef op woensdag 15 februari 2023 @ 13:51:
Ik zou een packet capture maken en daar in wireshark filteren op het echte verkeer

Ik zou heel graag willen maar ik snap niet hoe ik dit moet doen. Ik lees vanalles maar dit gaat mijn kennis te boven.

Ik heb op mijn Mac wireshark geïnstalleerd maar ik weet niet hoe ik communicatie tussen de ESP32 en het "internet" moet meten. Er is namelijk geen communicatie tussen mijn Mac en de ESP32

[laurens0619]

Scott81 schreef op woensdag 15 februari 2023 @ 13:53:
[...]


Ik zou heel graag willen maar ik snap niet hoe ik dit moet doen. Ik lees vanalles maar dit gaat mijn kennis te boven.

Ik heb op mijn Mac wireshark geïnstalleerd maar ik weet niet hoe ik communicatie tussen de ESP32 en het "internet" moet meten. Er is namelijk geen communicatie tussen mijn Mac en de ESP32

- Ethernet kabel tussen je ESP32 en je MAC leggen
- MAC via wifi op internet verbinden
- Internet delen inschakelen in je mac. deel je wifi via je lan

Wirehsark starten op de lan interface

[DataGhost]

Als je niet snapt hoe die tellers werken is de eerste plek waar je zou kijken de documentatie. Als daar niks uit blijkt en ook via Google niks duidelijk wordt, kan je eens proberen om te kijken waar de counters op staan, dan bijv. 100MB te downloaden, nogmaals te kijken waar ze op staan, dan 100MB te uploaden, nogmaals te kijken waar ze op staan, dan disconnect je ofzo, probeer hetzelfde op een andere poort voor mijn part, kijk welke getallen resetten en wanneer, welke niet, en hoe ze corresponderen met het verbruik wat je net zelf hebt gedaan.

Of inderdaad zoals laurens0619 zegt op een andere manier meten.

[ Voor 5% gewijzigd door DataGhost op 15-02-2023 13:59 ]

[laurens0619]

Het probleem met meten via de statistics van de switch is dat dit prima kan bij grote volumes maar stuq loopt bij jouw use case: jij probeert namelijk echt bits te tellen en de vervuiling van broadcast verkeer is dus significant in je dataset. Bij grote datasets is dat broadcast verkeer een druppel op een gloeiende plaat en maakt dat niet zoveel uit

Daarom gaat meten via de unifi statisics nooit werken.

[Scott81]

laurens0619 schreef op woensdag 15 februari 2023 @ 13:56:
[...]

- Ethernet kabel tussen je ESP32 en je MAC leggen
- MAC via wifi op internet verbinden
- Internet delen inschakelen in je mac. deel je wifi via je lan

Wirehsark starten op de lan interface

Dit ga ik proberen. Heb nu geen adapter met internet connector maar die kan ik thuis wel pakken.

DataGhost schreef op woensdag 15 februari 2023 @ 13:58:
Als je niet snapt hoe die tellers werken is de eerste plek waar je zou kijken de documentatie. Als daar niks uit blijkt en ook via Google niks duidelijk wordt, kan je eens proberen om te kijken waar de counters op staan, dan bijv. 100MB te downloaden, nogmaals te kijken waar ze op staan, dan 100MB te uploaden, nogmaals te kijken waar ze op staan, dan disconnect je ofzo, probeer hetzelfde op een andere poort voor mijn part, kijk welke getallen resetten en wanneer, welke niet, en hoe ze corresponderen met het verbruik wat je net zelf hebt gedaan.

Of inderdaad zoals laurens0619 zegt op een andere manier meten.

Heb al 2 dagen gegoogeld maar zie geen enkel zinnig resultaat. Daarbij heb ik al 3 of 4 versies van Unify Network Controller geprobeerd en overal zijn de resultaten kwa naamgeving anders.

Verder kan ik geen enkel verband leggen tussen de getallen en verbruiken. Als ik download via mijn mac blijft het Internet verbruik op 0 staan. Geen enkel getal wordt 100MB "groter" bij iets downloaden van 100MB bijvoorbeeld

[laurens0619]

@Scott81 ik ben al een tijdje uit het unifi wereldje maar de controller van unifi is een stukje software om verschillende componenten in unifi mee te beheren. Hoe meer componenten je hebt, hoe vollediger je dashboard.

De "internet activity" slaat dus denk ik op data die normaal uit een router komt als een usg. Als je dat component niet hebt, zal de data daar altijd 0 blijven.

Redeneer ik dan even

edit: maar tegelijk zijn er zoveel quirks met unifi en ook op rapportage/statistics dat ik nooit van die getallen uit zou gaan, ook al zou je wel een usg hebben.

[ Voor 16% gewijzigd door laurens0619 op 15-02-2023 14:08 ]

[Scott81]

Dat dacht ik al. Ik ga een USB-C naar ethernet adapter kopen. Dan kan ik via wireshark proberen te achterhalen wat het verbruik daadwerkelijk is

[HenkEisDS]

Je kunt in windows zonder al te veel problemen je wifi kaart omzetten naar een accesspoint en via dit accesspoint je bedrade internet delen. Vervolgens kun je het netwerkverbruik per adapter zien en als je dan kijkt naar je wifi adapter heb je de data usage van je apparaatje.

[laurens0619]

@Scott81
voordat je dat doet kun je ook kijken naar de suggestie die ik eerder postte. Vanuit je draytek menu een packet capture starten, dan kun je vanuit die interface een pcap downloaden.
Vraag is of dat met jouw model kan

laurens0619 in "Internet data verbruik van één apparaat monitoren"

[ Voor 17% gewijzigd door laurens0619 op 15-02-2023 14:14 ]

[Scott81]

Ik had dat ook al opgezocht maar volgens mij kan mijn router dat niet. En eerlijk gezegd ben ik niet zo goed met netwerken en de instellingen. De handleiding die ik las (wat volgens mij niet voor mijn router geld) snapte ik al niet volledig


@HenkEisDS Ik gebruik voornamelijk Mac (laptop met WiFi). Heb ook wel een windows PC staan maar die heeft maar 1 vaste netwerk connector dus geen wifi adapter

[laurens0619]

@Scott81
Als je windows pc hebt met ethernet kun je ook:
https://draytek.com/downl...Tek_UG_Vigor2927_V1.0.pdf
II-2-4 LAN Port Mirror
- Zet port mirror op enable
- Sluit je PC aan op bv port 5
- Vink port 5 aan Mirror port
- Start wireshark op PC op
- Start capture met promiscious mode aan op alle interfaces

Als het goed is zie je nu verkeer komen vanaf het ip van je ESP device, daarna filter instellen dat je alleen ESP verkeer pakt en voila

edit:
ik lees nu dat je al data had kunnen verzamelen door tcpdump op de server. Is dat niet afdoende?

[ Voor 9% gewijzigd door laurens0619 op 15-02-2023 14:21 ]

[Scott81]

Ik zal dat eens proberen.
Ik kon dat inderdaad monitoren echter kwamen zoveel resultaten per call dat ik geen idee had hoe ik moet bepalen wat nu de "som" is van alle calls.

Vandaar dat ik het via de Unify Controller wilde bereiken. Ik hoopte dat daar een som (per uur of 24uur) getoond werd van het daadwerkelijke verbruik.

Weet niet of ik via WireShark wel een totaal kan krijgen of dat dat ook allemaal losse resultaten zijn. Daar weet ik waarschijnlijk ook niet wat ik wel of niet moet optellen om tot het exacte verbruik te komen

[Orion84]

Scott81 schreef op woensdag 15 februari 2023 @ 14:37:
Ik zal dat eens proberen.
Ik kon dat inderdaad monitoren echter kwamen zoveel resultaten per call dat ik geen idee had hoe ik moet bepalen wat nu de "som" is van alle calls.

Vandaar dat ik het via de Unify Controller wilde bereiken. Ik hoopte dat daar een som (per uur of 24uur) getoond werd van het daadwerkelijke verbruik.

Weet niet of ik via WireShark wel een totaal kan krijgen of dat dat ook allemaal losse resultaten zijn. Daar weet ik waarschijnlijk ook niet wat ik wel of niet moet optellen om tot het exacte verbruik te komen

Als je de capture laadt in wireshark dan kan je er ook statistieken / grafiekjes over laten maken en zo (@dion_b liet daar eerder al wat van zien).

[laurens0619]

@Scott81 makkelijkste is met tcpdump -w file.pcap te maken van een capture
Dan die file downloaden en openen met wireshark. Dan kun je filteren en de statistics zien

Als je niet gaat filteren isdie tcpdump ook gevaarlijk want dan zie je bv je eigen ssh sessie terug

[Scott81]

Bedankt voor alle hulp en info
Maar bij het filteren gaat het wellicht mis. Ik heb geen idee waar ik op moet filteren. En zie ik dan alle data. Ook via MQTT etc

[Minitrooper]

Brutale linkdump: https://www.cyberciti.biz...affic-except-ssh-port-22/

[biomass]

Scott81 schreef op maandag 13 februari 2023 @ 15:33:
Dat kan, ik connect tijdens het pingen, maar misschien was mijn "export" van de 2e keer pingen. Hij zal de vorige verbinding wellicht sluiten en een nieuwe starten.

De vraag is of dit uberhaupt kan en ik geen problemen krijg met andere verbindingen die tijdens het pingen gemaakt worden. Een echte "ping" functie zou dus een heel stuk beter zijn

Euh nee. Als je hoster besluit de ICMP response niet meer door te geven, heb je niks. Omdat je standvastig "ping functie" bleef noemen begreep ik dat je een eigen applicatie vraag/antwoord spel aan het doen was. Daarmee check je ook echt of je applicatie wakker is. Dan geldt ook dat als je binnen 10 minuten moet weten dat een service down is, je elke 5 minuten moet 'pollen' (Nyquist-Shannon) Waarom wil je een dedicated device bij klanten plaatsen die data verbruikt? Kun je dan ook niet gewoon aanbevelen/eisen dat er een flatfee abbonementsvorm wordt gebruikt voor die verbinding?.

Alternatief is een cross platform mobile app in Unity o.i.d?

[Scott81]

Ik zal ook eens kijken met de tcpdump, echter ben ik ook een klein beetje bang dat de library die verbinding maakt met de ethernet controller misschien zelf een soort "ping" naar bv de google server doet. Dit wil ik ook meten dus niet alleen alles naar mijn eigen server.

Ik heb nu een usb-c ethernet adapter van thuis meegenomen en via de mac Internetdeling aangezet.
Bij internetdeling selecteer ik USB 10/100/1000 LAN

Mijn ESP32 krijgt nu ook een ip adres, alleen ligt dit in een andere range dan mijn router.
Mijn router is 192.168.2.x en mijn EPS krijgt nu 192.168.3.2

Als ik wireshark opstart monitor ik op 192.168.3.2 niets en na een minuut is WireShark enorm traag. Ik vraag me af of ik dus het juiste doe

[Scott81]

Ah! Als ik via wireshark de USB 10/100/1000 LAN selecteer dan krijg ik wel data te zien.
Als ik dan filter op ip.host == 192.168.3.2 zie ik alles van de ESP32?
Dit kan ik uiteindelijk na een uur bijvoorbeeld opsommen en dan heb ik het daadwerkelijke internet verbruik?

[Orion84]

Ja, al het verkeer via de machine laten lopen waar Wireshark staat is ook een mooie oplossing om het te monitoren

[Scott81]

Dit is nu het resultaat van 1 uur monitoren.
In dit voorbeeld publish ik elke seconde naar de server (extreem maar goed voor de test).
Mag ik nu aannemen dat het daadwerkelijke verbruik 485kB per uur is?

Ik heb 2 addressen, neem aan dat 1 de ESP32 is (dit mac komt inderdaad overeen) en het andere de server. Ik hoef hier niet het totaal van te pakken? (dus 484kB * 2 = 968kB?)

En is dit reëel? Het is elke seconde pushen maar nog steeds 400mb per maand ongeveer

[laurens0619]

hang er vanaf, heb je nu je broadcast/multicast verkeer eruit gefilterd?

[Scott81]

uhm... oei nee. Dat is een goeie vraag hoe ik dat er nu uithaal

[laurens0619]

Misschien handigste om naar de conversation te kijken, ik weet even niet in welk interface je zit maar denk onder ipv4 in dat plaatje waar je zat
https://www.wireshark.org.../ChStatConversations.html

post daar eens plaatje van.

[Scott81]

Hier zijn de resultaten (in de tabs zie je welke "interface" geselecteerd is.
Dit is overigens van 1u en 10 minuten dus wellicht meer data verbruik dan de vorige screen

[laurens0619]

je hebt address B weggehaald dus nu kan ik niet zien of daar broadcast tussen zit
Echter aangezien ik maar 1 entry zie dan zal dat wel de connectiedie je zoekt
dan klopt jee conclusie denk ik.

Als je deze analyse nog draait dan krijg je wat beter beeld over de protcollen/datagebruik

[Scott81]

Address B is het publieke ip van mijn netwerk. Dit gebruik ik nu als test om een "internet" verbinding te maken in plaats van lokaal aan te roepen




En mijn conclusie van 484kB per uur klopt? Of het dubbele ervan omdat ik 2 records zie

[ Voor 8% gewijzigd door Scott81 op 16-02-2023 11:05 ]

[laurens0619]

mijn wireshark skills zijn wat roestig maar als ik naar dat plaatje kijk dan gaat er dus 49.9 op aan MQTT, waar gaat de ander 50% dan naartoe? unknown protocols?

Ik zou denken 609kb/uur. Dat is het optellen van de TX en RX

[ Voor 16% gewijzigd door laurens0619 op 16-02-2023 11:12 ]

[Scott81]

Misschien zeg ik wat doms, maar elke seconde publish ik een bericht via mqtt (via de ESP32) en in wireshark komen (elke seconde dus) deze 2 regels.

Eentje is MQTT en eentje is TCP. Misschien is dit het?

[DataGhost]

laurens0619 schreef op donderdag 16 februari 2023 @ 11:10:
mijn wireshark skills zijn wat roestig maar als ik naar dat plaatje kijk dan gaat er dus 49.9 op aan MQTT, waar gaat de ander 50% dan naartoe? unknown protocols?

Ik zou denken 609kb/uur. Dat is het optellen van de TX en RX

De packets zijn gemiddeld 71 bytes, dat is best klein. Daar gaat al best veel aan headers op (MAC x2, IP x2, poort x2 heb je al 24 bytes te pakken). Aangezien het TCP is en 5592 bijna de helft is van 11210 gok ik dat de resterende packets voornamelijk ACKs zijn.

[ Voor 39% gewijzigd door DataGhost op 16-02-2023 11:15 ]

[laurens0619]

@Scott81
MQTT is ook TCP maar waarschijnlijk wordt de response niet herkend als MQTT
Dat zal idd die missende 50% verklaren.

Maar dan denk ik dat het klopt

[Scott81]

Als mijn berekening klopt verbruikt het dus 372mb per maand als ik elke seconde publish.
Ik zet het nu eens op eens per minuut (wat ook al veel meer is dan het uiteindelijke realistische gebruik), maar dan valt het achteraf gezien misschien redelijk mee

[dion_b]

Scott81 schreef op donderdag 16 februari 2023 @ 11:14:
Misschien zeg ik wat doms, maar elke seconde publish ik een bericht via mqtt (via de ESP32) en in wireshark komen (elke seconde dus) deze 2 regels.

Eentje is MQTT en eentje is TCP. Misschien is dit het?[Afbeelding]

Hou de OSI-lagen in de gaten. MQTT werkt op layer 7 (applicatie), dus gebruikt het daaronder ook een layer 4 (transport) protocol, specifieker, het gebruikt hier TCP. Dat MQTT bericht zit dus in een TCP segment, en eigenschap van TCP is dat elk bericht bevestigd moet worden met een ACK.

Dit is dus een TCP conversation, specifiek de kleinst mogelijke succesvolle. Je payload (MQTT bericht) is aangekomen en dat bevestigt de ontvanger.

Edit: spuit 11

[laurens0619]

Size of Ethernet frame - 24 Bytes
Size of IPv4 Header (without any options) - 20 bytes
Size of TCP Header (without any options) - 20 Bytes

Total size of an Ethernet Frame carrying an IP Packet with an empty TCP Segment - 24 + 20 + 20 = 64 bytes

In een maand zitten 2,628,288 seconds dus dan kom je op 168210432 Bytes. Dat is 168Mb.
Maar je hebt 2 paketten nodig per transactie, heen en terug.

De wens van iedere seconde communiceren kost je dus al minimaal 336Mb, en dan heb je nog helemaal niets "gezegd". Druk je daar de MQTT headers en wat content bij dan is 372Mb dus inderdaad geen gek getal.

Hopelijk geen rekenfoutjes gemaakt, ik twijfel vooral of die *2 berekening die ik doe klopt. @dion_b enig idee?

[ Voor 10% gewijzigd door laurens0619 op 16-02-2023 13:11 ]

[dion_b]

laurens0619 schreef op donderdag 16 februari 2023 @ 13:08:
[...]

In een maand zitten 2,628,288 seconds dus dan kom je op 168210432 Bytes. Dat is 168Mb.
Maar je hebt 2 paketten nodig per transactie, heen en terug.

De wens van iedere seconde communiceren kost je dus al minimaal 336Mb, en dan heb je nog helemaal niets "gezegd". Druk je daar de MQTT headers en wat content bij dan is 372Mb dus inderdaad geen gek getal.

Hopelijk geen rekenfoutjes gemaakt, ik twijfel vooral of die *2 berekening die ik doe klopt. @dion_b enig idee?

Allereerst is 168210432 Bytes 168MB, niet Mb. het zou ongeveer 1344Mb zijn.

Maar goed, ik zie twee pakketten van 89B en 54B, dus toaal 143B per conversation.

Bij eentje per uur kost dat 3.4kB/dag
Bij eentje per minuut is het 201kB/dag
Bij eentje per seconde is het 12MB/dag

Edit: factor 1024 ernaast

Maar...

Dit is theorie, geextrapoleerd op basis van een enkele conversatie.

Ik zou aanraden om niet te rekenen, maar te meten. Zet gewoon een Wireshark capture aan met capture filter om alleen verkeer van/naar IP of MAC van het Thing. Laat het een etmaal lopen en kijk wat het met huidige instellingen doet. Meet totaal dat je opgevangen hebt (staat gewoon onderaan de capture). Herhaal evt met andere instellingen.

[laurens0619]

dion_b schreef op donderdag 16 februari 2023 @ 13:22:
[...]

Allereerst is 168210432 Bytes 168MB, niet Mb. het zou ongeveer 1344Mb zijn.

Maar goed, ik zie twee pakketten van 89B en 54B, dus toaal 143B per conversation.

Bij eentje per uur kost dat 3.4MB/dag
Bij eentje per minuut is het 201MB/dag
Bij eentje per seconde is het 12GB/dag

Maar...

Dit is theorie, geextrapoleerd op basis van een enkele conversatie.

Ik zou aanraden om niet te rekenen, maar te meten. Zet gewoon een Wireshark capture aan met capture filter om alleen verkeer van/naar IP of MAC van het Thing. Laat het een etmaal lopen en kijk wat het met huidige instellingen doet. Meet totaal dat je opgevangen hebt (staat gewoon onderaan de capture). Herhaal evt met andere instellingen.

Je hebt gelijk, ik had de waarde van de online calculater niet goed overgenomen.

Maar puur theoreitsch gezien: Wat gaat het je aan data kosten door iedere seconde een TCP pakket heen en weer te sturen, is dat 168MB of 168MB*2 (of iets anders?)

Verder ben ik het eens met meten maar het kan wel helpen als je deze baseline weet.

[Scott81]

Hoe komen we nu aan dee getallen?

Bij eentje per uur kost dat 3.4MB/dag
Bij eentje per minuut is het 201MB/dag
Bij eentje per seconde is het 12GB/dag

Mijn resultaten zijn toch de "metingen"?
Daar kom ik uit op 370MB (megabytes) per maand voor elke seconden een publish. Hoe komen we nu aan 12GB per dag?

[laurens0619]

143B per conversation.

1/sec:
1dag == 86400seconde
143B * 86400 =12355200 Byte
= 12MB/dag == 360MB/maand
Dus ik gok dat dion daar een rekenfoutje maakte in de conversie (MB ipv GB)

Met daarbij de voetnooit dat ieder sec communiceren je sowieso al 336MB kost door de overhead van TCP.
Wil je lager uitkomen dan gaat rommelen aan de payload niet zoveel oplossen, afwijken van TCP zou ik ook niet zo snel doen. Dan blijft de frequentie verlagen dus over

[ Voor 42% gewijzigd door laurens0619 op 16-02-2023 13:42 ]

[Scott81]

Okay duidelijk.
Het iedere seconde communiceren is puur voor de test, uiteindelijk gaan er waarschijnlijk maar enkele tientallen communicaties per dag plaatsvinden maar zo kan ik in elk geval een "worst case scenario" monitoren.

Alhoewel ik de MQTT verbinding wel moet openhouden en meet dus meer dan bijvoorbeeld 10x 143 bytes

[dion_b]

Meten is weten. Altijd realistischer en nauwkeuriger dan welke extrapolatie ook.

[ Voor 7% gewijzigd door dion_b op 16-02-2023 18:18 ]

[W1ck1e]

dion_b schreef op donderdag 16 februari 2023 @ 17:14:
Meten is weten. Altijd realistischer en nauwkeuriger dan welke meting ook.

?
(Lees even hardop wat je schrijft)

[ Voor 8% gewijzigd door W1ck1e op 16-02-2023 18:07 ]

[dion_b]

W1ck1e schreef op donderdag 16 februari 2023 @ 17:19:
[...]

?

Gewoon Wireshark 24u laten draaien en werkelijke hoeveelheid data capturen in plaats van te extrapoleren op basis van een enkele communicatie.

[RGAT]

laurens0619 schreef op donderdag 16 februari 2023 @ 13:40:
143B per conversation.

1/sec:
1dag == 86400seconde
143B * 86400 =12355200 Byte
= 12MB/dag == 360MB/maand
Dus ik gok dat dion daar een rekenfoutje maakte in de conversie (MB ipv GB)

Met daarbij de voetnooit dat ieder sec communiceren je sowieso al 336MB kost door de overhead van TCP.
Wil je lager uitkomen dan gaat rommelen aan de payload niet zoveel oplossen, afwijken van TCP zou ik ook niet zo snel doen. Dan blijft de frequentie verlagen dus over

Als je toch al elke seconde pingt, kan je net zo goed naar UDP uitwijken, scheelt je weer een paar Bytes per packet, kan je de payload een nummer meegeven zodat je weet welke reply je verwacht, als je je eigen server pingt iig.

[deHakkelaar]

@Scott81 , als je ping gebruikt, kijk dan ofdat je de afmeting omlaag kunt schroeven:

$ man ping
[..]
       -s packetsize
           Specifies the number of data bytes to be sent. The default is 56, which
           translates into 64 ICMP data bytes when combined with the 8 bytes of
           ICMP header data.

$ ping -c 1 -s 0 127.0.0.1
PING 127.0.0.1 (127.0.0.1) 0(28) bytes of data.
8 bytes from 127.0.0.1: icmp_seq=1 ttl=64

--- 127.0.0.1 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms

$ sudo tcpdump -nti any icmp
[..]
lo    In  IP 127.0.0.1 > 127.0.0.1: ICMP echo request, id 21, seq 1, length 8
lo    In  IP 127.0.0.1 > 127.0.0.1: ICMP echo reply, id 21, seq 1, length 8

Maar ik zou een andere heuristic gebruiken om bij benadering te bepalen ofdat een service up is.
Ik zou kijken ofdat bv met web poortje 80 TCP hieronder alleen een verbinding is te maken.
Alleen het TCP FIN-->ACK-->FIN-->ACK gedeelte:

$ nc -vz 127.0.0.1 80
Connection to 127.0.0.1 80 port [tcp/http] succeeded!

$ sudo tcpdump -nti any tcp port 80
[..]
lo    In  IP 127.0.0.1.46324 > 127.0.0.1.80: Flags [S], seq 2584648338, win 65495, options [mss 65495,sackOK,TS val 3533265509 ecr 0,nop,wscale 6], length 0
lo    In  IP 127.0.0.1.80 > 127.0.0.1.46324: Flags [S.], seq 4198683657, ack 2584648339, win 65483, options [mss 65495,sackOK,TS val 3533265509 ecr 3533265509,nop,wscale 6], length 0
lo    In  IP 127.0.0.1.46324 > 127.0.0.1.80: Flags [.], ack 1, win 1024, options [nop,nop,TS val 3533265509 ecr 3533265509], length 0
lo    In  IP 127.0.0.1.46324 > 127.0.0.1.80: Flags [F.], seq 1, ack 1, win 1024, options [nop,nop,TS val 3533265514 ecr 3533265509], length 0
lo    In  IP 127.0.0.1.80 > 127.0.0.1.46324: Flags [F.], seq 1, ack 2, win 1024, options [nop,nop,TS val 3533265515 ecr 3533265514], length 0
lo    In  IP 127.0.0.1.46324 > 127.0.0.1.80: Flags [.], ack 2, win 1024, options [nop,nop,TS val 3533265515 ecr 3533265515], length 0

Vergelijk "length" maar in de respectievelijke tcpdump outputs.

Nog mooier zou zijn als je al na de FIN-->ACK kunt stoppen want je hebt toch al de ACK ontvangen van de server.
Dat scheelt weer extra communicatie.

EDIT:

$ nc -z 127.0.0.1 80 && echo 'UP' || echo 'DOWN'
UP

$ nc -z 127.0.0.1 9999 && echo 'UP' || echo 'DOWN'
DOWN

[ Voor 3% gewijzigd door deHakkelaar op 16-02-2023 20:28 ]