:
Check je IGMP Proxy !
128.0.0.0/32 dat moet 128.0.0.0/1 zijn!
En ja met deze config neem je afscheid van je Fritzbox.
JAAAAAAAAAAAAA, He scores !!!! (ik ben vannacht tot 01:30 door gegaan en heb vanochtend vanaf scratch af alles opnieuw opgebouwd en dan mis je 1 klikje blijkbaar 
) Member of the Ukraine IT Army
:fill(white):strip_exif()/f/image/ZSENDK8EK2NTt1z4QSNL2oF6.png?f=user_large)
:fill(white):strip_exif()/f/image/F3qmOfV32QPAJeTheoI5ExZt.png?f=user_large)
[ Voor 37% gewijzigd door Woetter22 op 14-07-2024 18:19 . Reden: Afbeelsingen ingevoegd ]
Asustor AS6704T (32GB, 4x16TB MG08), OpenWrt (3x GL.iNet Flint 2 MT6000), Lyrion Media Server, Odroid H2/N2+/C4/C2, DS918+ (4x8TB WD RED)
Ask yourself if you are happy and then you cease to be.
:fill(white):strip_exif()/f/image/WDxT75JbI73dXd3Rm394FUnh.png?f=user_large)
:fill(white):strip_exif()/f/image/M2thx0NTpTHnHSFBDZOo5nE1.png?f=user_large)
:fill(white):strip_exif()/f/image/mX7U38jTn1wmfeelcgLnlI8W.png?f=user_large)
:fill(white):strip_exif()/f/image/B9A544LDjOZgqhuiVsuC38gi.png?f=user_large)
:fill(white):strip_exif()/f/image/m8hFHqOZdNlULGy6jxiCjxOX.png?f=user_large)
:fill(white):strip_exif()/f/image/tXzhyoby3NfURdCNYt2lRnDw.png?f=user_large)
:fill(white):strip_exif()/f/image/xShuWY04IalLEeYKLbbLgdaX.png?f=user_large)
:fill(white):strip_exif()/f/image/hhGouqx99rfVeKToTDSpvf0m.png?f=user_large)
:fill(white):strip_exif()/f/image/zq0wuruiGg2XB688JacPujEZ.png?f=user_large)
[ Voor 30% gewijzigd door Woetter22 op 15-07-2024 15:35 ]
Dat artikel staat al in mijn bookmarks
Ik heb uiteraard al een lijst met artikelen van mensen die het wel aan de praat hebben.Ask yourself if you are happy and then you cease to be.
lijkt er wel op.
(bijna de CAT6 uit de muur getrokken) en vooral heel veel gezeur over "slechte wifi" 
Toch leuk als je iets kunt relateren aan zoiets specifieks als deze update! Tof.:
[...]
lijkt er wel op.
Heeft me uren gekost, complete netwerk rebuild
Ik ben over naar een UCG Max router, maar ik dacht laat ik mijn OPNsense VM eens bijwerken als standby router. VPN config's dhcp reserveringen etc, kortom bij een activatie van OPNsense wil ik er zo min mogelijk van merken.
:strip_exif()/f/image/cRN2SWxvYLWeAw14tZTnqP7R.png?f=user_large)
[ Voor 10% gewijzigd door Weiman op 28-10-2024 22:28 ]
Sure. De ONT gaat een managed switch in op een trunk poort met de nodige vlans tagged. Deze gaan ook weer tagged vanuit een andere switchpoort naar een Hyper-V server een netwerkpoort in van een Intel Pro/1000PT NIC. Deze poort is onderdeel van een virtual switch waar alleen de PFsense VM aan hangt. Deze heeft weer een interface tagged in VLAN 6 met PPPoE voor internet.
:strip_exif()/f/image/xnHz8jzW1PO9Imct48i9weej.png?f=user_large)
:strip_exif()/f/image/D6xgSvW0hSSW58a72Ea39KXj.png?f=user_large)
Thanks! Deze ONT is inmiddels uit 2015 dus het zou me niks verbazen als die wat issues heeft.
:strip_exif()/f/image/O25zWj8LW8Ob9NMj9smQuR0y.png?f=user_large)
:strip_exif()/f/image/oJ15YltXen5KU1jq488ngfJM.png?f=user_large)
:strip_exif()/f/image/S08KLhhefDSbW6eUy24rmOQV.png?f=user_large)
:strip_exif()/f/image/Q6msSZVs8ThCXO1Y4P849MGD.png?f=user_large)
:strip_exif()/f/image/x72nLen5vuTGGPjO04mp0e27.png?f=user_large)
:strip_exif()/f/image/FkDFvT0A2FUpmu5nGukVs2qC.png?f=user_large)
:strip_exif()/f/image/8m3QREL2pbZmXu4l5RUWnId8.png?f=user_large)
:strip_exif()/f/image/bUZAQCX7D1vlwQ4lTg74eUta.png?f=user_large)
Dank je. Het is gelukt. Uiteindelijk zat het in de config van de iptv WAN fw rules. Ik moest daar het nieuwe adres ook toevoegen.
Voor UDP en IGMP heb ik die FW rules volledig open staan voor het STB subnet, een extra laag beheer die je kan nekken als iets niet werkt als je daar ook rules plaatst.:
[...]
Dank je. Het is gelukt. Uiteindelijk zat het in de config van de iptv WAN fw rules. Ik moest daar het nieuwe adres ook toevoegen.
Tjonge, dat heeft wat tijd gekost
:strip_exif()/f/image/6Rx6d6RCje8knHrCsetzVH8v.png?f=user_large)
:strip_exif()/f/image/PJSRHO2vK3cYZS5uk65GEaND.png?f=user_large)
:strip_exif()/f/image/h1fWBAHTLeoKMoqOQs3yWNDM.png?f=user_large)
:strip_exif()/f/image/x1slrrntMBkp6wJV5DLYuEWC.png?f=user_large)
Ook voor mij werkt het uitschakelen van IGMP Snooping ook niet, ik ontvang nog steeds geen TV. In eerste instantie heb ik PfSense geprobeerd, maar zonder succes voor de TV. Er bevinden zich twee fysieke switches tussen mijn router en de TV, echter functioneren deze switches prima met de KPN Router, dus het lijkt erop dat het probleem niet aan de switches ligt.
. Bleef hangen op het downloaden van packages...Had je wel herstart?:
Afgelopen paar dagen werd het internet thuis slechter, apps bleven hangen, X laadde plaatjes niet. Ik had niks veranderd aan mijn OPNsense setup.
Gisteravond dacht ik, laat ik OPNsense updaten. Dit lukte ook niet
Kwam ik via Reddit uit op het uitschakelen van IPv6.
Nu zag ik in het KPN Glasvezel topic dat er ook met de KPN Box IPv6 problemen zijn, zou het daarmee te maken hebben?
Hoe is IPv6 ingesteld? Track interface? of heb je static IP's op de VLAN's gezet?
:strip_exif()/f/image/sePF5uCp3VNSXavl6gAzZ2h5.png?f=user_large)
[ Voor 30% gewijzigd door Vorkie op 22-03-2025 17:04 ]
Ja zo had ik het ook, adhv deze guide https://www.eigenrouter.n...kpn/opnsense-without-vlan
[ Voor 3% gewijzigd door Arnout op 22-03-2025 23:04 ]
:strip_exif()/f/image/IUyucDj5SAfR535UTMionbWP.png?f=user_large)
Ik ben benieuwd naar meer onderbouwing dan kan ik wat leren 👍 met 0,53% verschil lijkt mij dat je het niet waar kunt nemen in dagelijks gebruik? Uiteindelijk ligt MSS er voor TCP ook overheen.
Omdat je met een te grote MTU juist gaat fragmenten of raar gedrag van websites kan krijgen die niet lekker inladen. [ Voor 55% gewijzigd door stormfly op 23-03-2025 10:00 ]
Zeker, hoe lager de MTU des te lager kans is op fragmentatie. Het fragmenteren van pakketten: MTU >1500 over een pad van 1500 versturen kost meer CPU time dan een extra datapakket voor een MTU van bijvoorbeeld 1400. Fragmentatie is niet alleen een kwestie van CPU-tijd, maar verhoogt ook significant de kans op packet loss. Als er meerdere fragmenten zijn en er raakt er maar één kwijt, moet het hele pakket opnieuw worden verzonden. Dit zorgt voor extra vertraging en inefficiëntie. Bij een goed gekozen lagere MTU vermijd je dit probleem volledig en krijg je een veel consistentere performance, zeker op drukkere verbindingen.
Ja exact een te grote MTU moeten alle routers in het pad het pakket opknippen, daarom is mijn punt ook: waarom die laatste paar byte eruit halen (vergroten MTU) terwijl het risico op uitdagingen groter wordt. 1 byte te hoog ingesteld is een recept voor gedoe
Dat is een goed idee, blijf van je MTU af tenzij je CCNA hebt behaald
Dat is exact waarover ik dit gesprek begon kennis over de materie vermogen tot issues oplossen tov de beperkte winst. Overigens helemaal niet persoonlijk naar jou, vat het aub niet zo op. Vorige week kwam het ook voorbij in het UniFi topic. Dit is denk ik ook een Tweaker, goede kwalitatieve post met mooie plaatjes.We weten dat KPN PPPoE MTU 1500 ondersteund, doen Delta en Glasnet dat ook? (ik weet het niet).
Het gaat mij erom dat 1492 out of the box heel goed werkt en dat beeld wil ik voor minder ingelezen Tweakers delen. Ik zie de laatste tijd veel nieuwe usersnames in de netwerk topics en wilde eens een ander licht schijnen op de MTU casus.
Maar is 1492 dan niet te klein voor het pakket verzonden vanuit de bron die gewoon 1500 verwacht (zoals de pc of webserver) waarna die op jouw router gefragmenteerd moet worden?:
[...]
Zeker, hoe lager de MTU des te lager kans is op fragmentatie. Het fragmenteren van pakketten: MTU >1500 over een pad van 1500 versturen kost meer CPU time dan een extra datapakket voor een MTU van bijvoorbeeld 1400. Fragmentatie is niet alleen een kwestie van CPU-tijd, maar verhoogt ook significant de kans op packet loss. Als er meerdere fragmenten zijn en er raakt er maar één kwijt, moet het hele pakket opnieuw worden verzonden. Dit zorgt voor extra vertraging en inefficiëntie. Bij een goed gekozen lagere MTU vermijd je dit probleem volledig en krijg je een veel consistentere performance, zeker op drukkere verbindingen.
Fragmentatie ontstaat bij een te grote MTU.
Als een pakket groter is dan de MTU van een tussenliggende router, moet dat pakket worden opgesplitst (gefragmenteerd) in kleinere delen om door te kunnen. Dit gebeurt bijvoorbeeld als:
• De afzender een MTU van 1500 bytes gebruikt, maar een router onderweg slechts 1492 bytes toestaat (zoals bij PPPoE).
• Een VPN extra headers toevoegt, waardoor het totale pakket groter wordt dan de ingestelde MTU.
Kleine MTU = minder kans op fragmentatie, omdat pakketten sowieso klein genoeg zijn om overal zonder opsplitsen door te komen
MSS berekening bij een MTU van 1500 bytes - de header = netto.
Voor IPv4: MSS = 1500 - 40 = 1460 bytes
Voor IPv6: MSS = 1500 - 60 = 1440 bytes
[...]
Ja exact een te grote MTU moeten alle routers in het pad het pakket opknippen, daarom is mijn punt ook: waarom die laatste paar byte eruit halen (vergroten MTU) terwijl het risico op uitdagingen groter wordt. 1 byte te hoog ingesteld is een recept voor gedoe
[...]
Dat is een goed idee, blijf van je MTU af tenzij je CCNA hebt behaald
[...]
We weten dat KPN PPPoE MTU 1500 ondersteund, doen Delta en Glasnet dat ook? (ik weet het niet).
Die "groener" opmerking snap ik niet helemaal. In theorie heb je bij grotere pakketten minder overhead per byte (minder headers), maar deze marginale winst wordt volledig teniet gedaan door de extra verwerkingstijd bij fragmentatie en mogelijke retransmissies als fragmenten verloren gaan. Een gefragmenteerd pakket dat opnieuw moet worden verzonden is juist minder "groen" dan twee kleinere pakketten die direct goed aankomen
[...]
Het gaat mij erom dat 1492 out of the box heel goed werkt en dat beeld wil ik voor minder ingelezen Tweakers delen. Ik zie de laatste tijd veel nieuwe usersnames in de netwerk topics en wilde eens een ander licht schijnen op de MTU casus.
Tweakers kunnen zelf kiezen wat ze willen gebruiken, en besluiten hoe goed ze netwerken doorgronden om deze 0.5% winst te pakken. Zoals je zelf laat doorschemeren, iedereen is er helemaal vrij in
MSS in TCP/IP lost dat op, MSS bepaald op basis van de onderhandeling tussen verzender & ontvanger wat er maximaal aan pakketgrootte gebruikt kan worden binnen de geldende MTU mogelijkheden. MSS onderhandelt dat bij het opzetten van de TCP sessie op getal wat matched met de PPPoE MTU mogelijkheden. Bij een PPPoE verbinding leggen de pakketten sowieso een andere weg af, de router moet elk pakket encapsuleren in PPP wat op zich al CPU intensief is.
1
2
3
4
5
6
7
8
9
10
| wlp2s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.2.2 netmask 255.255.255.0 broadcast 192.168.2.255
inet6 fe80::f1e8:3eab:54c2:d848 prefixlen 64 scopeid 0x20<link>
inet6 2a02:a452:xxxx:1:d23f:aa8a:d344:bda9 prefixlen 64 scopeid 0x0<global>
inet6 2a02:a452:xxxx:1:2450:8180:38f2:57a5 prefixlen 64 scopeid 0x0<global>
ether 5c:93:a2:ad:f6:fe txqueuelen 1000 (Ethernet)
RX packets 1603 bytes 304903 (304.9 KB)
RX errors 0 dropped 240 overruns 0 frame 0
TX packets 833 bytes 115939 (115.9 KB)
TX errors 0 dropped 12 overruns 0 carrier 0 collisions 0 |
Dit lijkt op mijn probleem, maar wat gaan ze fixen in de Box 12 dan? Dit lijkt me meer een netwerk issue?
[ Voor 9% gewijzigd door EricNL op 27-03-2025 17:27 ]
My PC Steam Profile PSN: AfcaEricNL
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
| Mar 30 07:16:21 igmpproxy 50914 Inserted route table entry for 239.255.255.250 on VIF #-1 Mar 30 07:16:18 igmpproxy 50914 MRT_DEL_MFC; Errno(49): Can't assign requested address Mar 30 07:16:18 igmpproxy 50914 Removing MFC: 192.168.10.11 -> 239.255.255.250, InpVIf: 0 Mar 30 07:15:57 igmpproxy 50914 Inserted route table entry for 239.255.255.250 on VIF #-1 Mar 30 07:15:57 igmpproxy 50914 RECV Membership query from 10.60.125.152 to 224.0.0.1 Mar 30 07:15:54 igmpproxy 50914 MRT_DEL_MFC; Errno(49): Can't assign requested address Mar 30 07:15:54 igmpproxy 50914 Removing MFC: 192.168.10.11 -> 239.255.255.250, InpVIf: 0 Mar 30 07:15:33 igmpproxy 50914 Inserted route table entry for 239.255.255.250 on VIF #-1 Mar 30 07:15:30 igmpproxy 50914 MRT_DEL_MFC; Errno(49): Can't assign requested address Mar 30 07:15:30 igmpproxy 50914 Removing MFC: 192.168.10.11 -> 239.255.255.250, InpVIf: 0 Mar 30 07:15:09 igmpproxy 50914 Inserted route table entry for 239.255.255.250 on VIF #-1 Mar 30 07:15:06 igmpproxy 50914 MRT_DEL_MFC; Errno(49): Can't assign requested address Mar 30 07:15:06 igmpproxy 50914 Removing MFC: 192.168.10.11 -> 239.255.255.250, InpVIf: 0 Mar 30 07:14:51 igmpproxy 50914 Inserted route table entry for 239.255.255.250 on VIF #-1 Mar 30 07:14:50 igmpproxy 50586 Joining group 224.0.0.22 on interface ix0.10 Mar 30 07:14:50 igmpproxy 50586 Joining group 224.0.0.2 on interface ix0.10 Mar 30 07:14:50 igmpproxy 50586 adding VIF, Ix 1 Fl 0x0 IP 0x010aa8c0 ix0.10, Threshold: 1, Ratelimit: 0 Mar 30 07:14:50 igmpproxy 50586 adding VIF, Ix 0 Fl 0x0 IP 0xccaf590a ix1.4, Threshold: 1, Ratelimit: 0 Mar 30 07:14:39 igmpproxy 98491 Shutdown complete.... Mar 30 07:14:39 igmpproxy 98491 All routes removed. Routing table is empty. Mar 30 07:14:39 igmpproxy 98491 Removing MFC: 192.168.10.11 -> 239.255.255.250, InpVIf: 0 Mar 30 07:14:39 igmpproxy 98491 Got a interrupt signal. Exiting. Mar 30 07:14:39 igmpproxy 98491 select() failure; Errno(4): Interrupted system call Mar 30 07:14:33 igmpproxy 98491 Inserted route table entry for 239.255.255.250 on VIF #-1 Mar 30 07:14:30 igmpproxy 97826 Joining group 224.0.0.22 on interface ix0.10 Mar 30 07:14:30 igmpproxy 97826 Joining group 224.0.0.2 on interface ix0.10 Mar 30 07:14:30 igmpproxy 97826 adding VIF, Ix 1 Fl 0x0 IP 0x010aa8c0 ix0.10, Threshold: 1, Ratelimit: 0 Mar 30 07:14:30 igmpproxy 97826 adding VIF, Ix 0 Fl 0x0 IP 0xccaf590a ix1.4, Threshold: 1, Ratelimit: 0 Mar 30 07:14:30 igmpproxy 67323 Shutdown complete.... Mar 30 07:14:30 igmpproxy 67323 All routes removed. Routing table is empty. Mar 30 07:14:30 igmpproxy 67323 Got a interrupt signal. Exiting. Mar 30 07:14:30 igmpproxy 67323 select() failure; Errno(4): Interrupted system call Mar 30 07:14:27 igmpproxy 67323 The source address 192.168.10.11 for group 239.255.255.250 is from downstream VIF[0]. Ignoring. Mar 30 07:14:21 igmpproxy 67323 The source address 192.168.10.11 for group 239.255.255.250 is from downstream VIF[0]. Ignoring. Mar 30 07:14:15 igmpproxy 67323 The source address 192.168.10.11 for group 239.255.255.250 is from downstream VIF[0]. Ignoring. Mar 30 07:14:09 igmpproxy 67323 The source address 192.168.10.11 for group 239.255.255.250 is from downstream VIF[0]. Ignoring. Mar 30 07:14:03 igmpproxy 67323 The source address 192.168.10.11 for group 239.255.255.250 is from downstream VIF[0]. Ignoring. Mar 30 07:13:57 igmpproxy 67323 The source address 192.168.10.11 for group 239.255.255.250 is from downstream VIF[0]. Ignoring. Mar 30 07:13:52 igmpproxy 67323 RECV Membership query from 10.60.125.152 to 224.0.0.1 Mar 30 07:13:51 igmpproxy 67323 The source address 192.168.10.11 for group 239.255.255.250 is from downstream VIF[0]. Ignoring. |
:strip_exif()/f/image/vCCLTj2k8OryOu8skSoeI1nl.png?f=user_large)
:strip_exif()/f/image/V1XBmptDgznamxKwx3By4kgN.png?f=user_large)
:strip_exif()/f/image/UBUMaPXDAGppxYbfqrsHqBo0.png?f=user_large)
[ Voor 13% gewijzigd door Remie op 30-03-2025 08:34 ]
[ Voor 4% gewijzigd door Kees op 03-05-2025 21:14 ]
"Een serveradmin, voluit een serveradministrator, is dan weer een slavenbeheerder oftewel een slavendrijver" - Rataplan
Als ik dit zo lees als ouwe rot in het vak zou mijn eerste gedachte zijn dat er bij KPN ergens een lijn vol loopt of zelfs packetloss heeft. En dat die lijn afhankelijk van source en destination wordt gebruikt (zoals in een trunk/lag/lacp of vorm van L3 routing loadbalancing). Dat je er dan niet last van hebt als je het KPN modem gebruikt zou kunnen verklaren dat je dan een ander IP adres krijgt.:
Ik heb een vreemd probleem met opnsense en KPN en ik hoop dat iemand gelijke ervaringen heeft en mischien zelfs een oplossing weet
....
Als ik het KPN modem gebruik dan werkt het wel goed..
Heeft iemand dit eerder gezien?
Zie je dat TCP windowsize 0 afgeeft waardoor de flow afremt en inzakt? Ik zou de headers eens door een TCP analyzer heen halen. Heb je al getest met IPv4 only met iPv6 uitgeschakeld?:
Ik heb een vreemd probleem met opnsense en KPN en ik hoop dat iemand gelijke ervaringen heeft en mischien zelfs een oplossing weet
Mijn setup werkt; ik heb internet, ik kan tv kijken, ik kan dingen downloaden en uploaden.
Maar ik haal op sommige hosts hele lage snelheden. Een download van ftp.bit.nl bijvoorbeeld komt binnen met maximaal 40-100Mbit/s. Maar dezelfde download op een externe server (*kuch* de server die dit forum host *kuch*) komt gewoon met 3+Gbits binnen, dus aan bit ligt het niet.
Vervolgens viel het mij op dat als ik diezelfde file van verschillende tweakers servers probeerde af te halen, dat het dan soms traag was, en soms snel. De file direct van een loadbalancer afhalen was bijvoorbeeld snel, maar vanaf een webserver was het traag.
Als ik dan verder kijk, dan zie ik iets opvallend. Een download van een server is heel erg langzaam afhankelijk van het gebruikte congestion protocol.. Als op die server het tcp_congestion_protocol op bbr staat; dan komt de download binnen met gbit snelheden, maar als het congestion_protocol op cubic staat dan is het bijzonder traag.
Als ik het KPN modem gebruik dan werkt het wel goed..
Heeft iemand dit eerder gezien?
Dat is een hoax, dat hoeft niet. Het is fijn dat KPN de modernere variant met PPP MTU 1500 ondersteund, je hebt slechts 0,53% snelheidswinst tussen 1492 en 1500. Maar als MTU bij een willekeurige provider 1 byte te groot is dan heb je kans op veel meer procenten snelheidsderving door fragmentatie.
1492 is de veilige standaard als je start met een setup, veel verkochte routers van de bekende merken Asus, UniFi gebruiken default allemaal 1492 voor PPP omdat sommige ISP's de 1500 variant niet ondersteunen.
"Een serveradmin, voluit een serveradministrator, is dan weer een slavenbeheerder oftewel een slavendrijver" - Rataplan
Klopt wat je zegt als je vanaf het LAN komt met 1500 en dat moet in 1492. Dan is er fragmentatie nodig, want dat past niet
Ik zette het wat scherp aan als tegengeluid. Er loopt een topic op UI.com (ooit hier begonnen) waarbij een Tweaker beweert dat het noodzaak is dat ze 1500 gaan ondersteunen vanwege KPN compatibiliteit. Dat is voor mij hoax want ik haal hier thuis 4/4Gbps met MTU 1492.
Veuillez agréer, Madame, Monsieur, l'expression de mes sentiments distingués.
:strip_icc():strip_exif()/u/55696/crop66942ced176a1_cropped.jpg?f=community)
:strip_icc():strip_exif()/u/232736/tweakers.jpg?f=community)
:strip_icc():strip_exif()/u/20047/neptunus.jpg?f=community)
:strip_icc():strip_exif()/u/16677/crop5db01361a1e1e_cropped.jpeg?f=community)
:strip_exif()/u/52746/eric-cartman_small.gif?f=community)
/u/298857/crop6471d9676d431.png?f=community)
/u/459815/crop5e17a83fc69b7.png?f=community)
:strip_exif()/u/87698/avatarline.gif?f=community){kind=avatar}
:strip_icc():strip_exif()/u/655387/crop61f7a5bca3e6c_cropped.jpg?f=community)
:strip_icc():strip_exif()/u/465790/crop67aba99dedb53_cropped.jpg?f=community)
:strip_exif()/u/34750/Trooper.gif?f=community)
/u/35508/crop61e6aa7b579e2_cropped.png?f=community)
/u/363743/crop61aa1329d36b8_cropped.png?f=community)
:strip_icc():strip_exif()/u/298324/avatar.jpg?f=community){kind=avatar}
/u/8/oog3.png?f=community)
:strip_icc():strip_exif()/u/82893/crop5f93bf643b4bd_cropped.jpeg?f=community)
