Hoe werkt D-STAR??

[PE2AAB]

Bijzonder; ik zat weer wat forums door te akkeren over portforwarding en Pi-Star en zag ergens een reactie van iemand die niet alleen UDP maar TCP & UDP instelde in zijn router. Aldus de beste man gaf dat minder 'hoofdpijn'. Ik citeer:

5. The next one should be protocol. This is either TCP, UDP, Or Both. I set mine to both as it seems to cause less headaches.

Bron: http://pi-star.blogspot.com/2020/11/pi- ... rward.html

Ik heb de instelling in mijn router ook veranderd van UDP naar TCP&UDP (of 'Both' in sommige routers) en zie het resultaat!
De link naar DCS007B is weer zichtbaar:

PiStarSetting2.PNG (16.55 KiB) 1137 keer bekeken

Nou dat was het dus. Volgens het overzichtje van de poorten voor D-Star heb ik een hele range open gezet. Maar alléén UDP. In de router veranderd in TCP & UDP en het werkte haast direct.

Weer een issue 'opgehelderd' wellicht?

De hele range poorten die open staat. Ik heb de ranges 'samengevat'.
UDP/30001 - DExtra
UDP/30051-30059 - DCS Connections
UDP/30061-30065 - CCS Routing

Ik heb dat dus samengevat en naar mijn IP Adres van de Pi-Star ge route volgens onderstaande range:

PiStarSetting3.PNG (9.73 KiB) 1137 keer bekeken

[PA0ETE]

Alles wat 'stream' is, moet UDP zijn. Dus dingen als dashboard, APRS is gewoon TCP. Veel kwaad kan het volgens mij niet om beide open te zetten. In mijn geval moet ik in dat geval afzonderelijke entries aanmaken voor de TCP- en UDP-opening.

Er zijn overigens instellingen op veel routers waar bijv. als er verkeer op een poort naar buiten gaat, die poort ook voor inbound verkeer open wordt gezet. Hij gaat dan na X-tijd weer dicht, maar het uitgaande verkeer is voldoende om ook ingaand de poort open te houden. De poortinstellingen zijn niet in alle gevallen noodzakelijk.

Ik stuur je per mail nog een aanvulling op mijn mail van gisteren, met informatie die mogelijk relevant is.

[PE1PQX]

Alles wat 'stream' is, moet UDP zijn. Dus dingen als dashboard, APRS is gewoon TCP. Veel kwaad kan het volgens mij niet om beide open te zetten. In mijn geval moet ik in dat geval afzonderelijke entries aanmaken voor de TCP- en UDP-opening.

Er zijn overigens instellingen op veel routers waar bijv. als er verkeer op een poort naar buiten gaat, die poort ook voor inbound verkeer open wordt gezet. Hij gaat dan na X-tijd weer dicht, maar het uitgaande verkeer is voldoende om ook ingaand de poort open te houden. De poortinstellingen zijn niet in alle gevallen noodzakelijk.

Ik stuur je per mail nog een aanvulling op mijn mail van gisteren, met informatie die mogelijk relevant is.

Normaal gesproken laten routers alle verkeer "van binnen naar buiten" door, "van buiten naar binnen" moet via port-forwarding en goede firewall regels ingesteld worden.

[PA0ETE]

Dat is niet zo. Ik heb hier een Fritz Box, en daar staat UPnP standaard aan. Ik geloof dat dat ook wel een callback-functie genoemd wordt.

Het komt hierop neer dat bij een uitgaande verbinding, het inkomende verkeer via dezelfde poort ook kortdurend als veilig wordt beschouwd. Dus na uitgaand verkeer staat enige tijd de inkomende poort op hetzelfde poortnummer (naar dezelfde client in het lokale netwerk) ook open. Het pingen van de reflectorverbinding is frequent genoeg om de poort permanent open te houden, en zodoende hoef je dan de boel niet zelf te configureren. Ik doe dat zelf liever wel, want stel dat het pingen niet helemaal goed gaat, of de herhaalfrequentie wordt bij een update gewijzigd, dan kun je gaan zoeken waardoor het komt. Verder zet ik, als dat mogelijk is ook het liefst de UPnP-functie in mijn eigen router uit. Ook al vanwege veiligheidsredenen.

Zie:
https://forum.kpn.com/modems-123/hoe-ze ... 590-574718
En:
https://en.wikipedia.org/wiki/Universal_Plug_and_Play

[PE1PQX]

Dan heb je 'last' van UPnP wat op zich een veiligheidsrisico is. UPnP wordt ook door malware etc. gebruikt om ongewenst poorten open te zetten in je router.
Ultieme advies hierin is: zet altijd UPnP uit!

Via het UPnP protocol kun je het poort beheer van je router volledig overnemen, en dat wil je gewoon niet.
Het verbaast me zelfs dat UPnP überhaupt nog in routers geprogrammeerd/ingebouwd wordt.

https://www.avg.com/nl/signal/what-is-unpn

Ik heb hier geen FritzBox in gebruik voor het verbinden met het internet (glasvezel), maar spullen van Ubiquity (UDM-Pro)

[PA0ETE]

Ik zie de instelmogelijkheid er bij de Fritz.box niet bij staan, maar in een aantal gevallen werkt het wel zo. Dat is nog ernstiger want dan kun je het ook niet uit zetten.

Aan de andere kant: wat is het probleem? Mensen kunnen via de betreffende poort je lokale netwerk in. Echter, het apparaat dat daar staat (bij mij) wordt ordentelijk afgeschermd (met een eigen firewall van het OS) en hij wordt dagelijks geüpdatet.

Maar bovenal is UPnP veiliger dan de poort permanent open zetten wat in veel gevallen het alternatief hiervoor is, al is het verschil niet zo heel groot...

Daarnaast heb ik een gesegmenteerd thuisnet, met sterk beveiligde en minder sterk beveiligde segmenten. Als ze langs deze weg (mijn D-STAR-repeater) binnenkomen zijn ze alleen pas in het minst beveiligde segment, en niet het segment waar de vertrouwelijke info zich bevindt. Als ze de repeater zouden weten te ontregelen dan ligt er een kaartje naast met het besturingssysteem volledig operationeel, ik hoef dat alleen om te prikken om het weer in de originele staat werkend te krijgen en in 20 minuten heb ik weer een nieuw kaartje gekopieerd ook.

[PE1PQX]

...

Maar bovenal is UPnP veiliger dan de poort permanent open zetten wat in veel gevallen het alternatief hiervoor is, al is het verschil niet zo heel groot...

...

Dat vind ik nogal een claim. Er wordt overal aangeraden om juist UPnP uit te zetten juist i.v.m. het veiligheids verhaal. Via het UPnP protocol kan ongemerkt open gezet worden wat jij juist niet wilt. Zoals poort 3389 (TCP): remote desktop. Dan staat jouw hele PC ter beschikking van de hele wereld. Dat wil je denk ik ook niet.

Je hoeft maar één keer de fout in te gaan met een phishing mail of op een verkeerde weblink te klikken en je bent de sjaak, of je je netwerk gesegmenteerd hebt (VLAN's denk ik) of niet.
Ook IoT apparaten die je zelf niet kunt updaten kunnen misbruik maken van UPnP en zijn waarschijnlijk vatbaar voor aanvallen van derden. Één van de grootste redenen is dat IoT apparaten vrijwel altijd een 'phone home' functie hebben. Hier wordt ook overal voor gewaarschuwd.

Ik blijf er bij: zet UPnP gewoon uit,is veel veiliger!

Maar dit gaat nu wel off-topic hier, dus laat ik het er bij.

[PA0ETE]

Daar noem je ook twee dingen die je helemaal nooit moet doen.

In phishing mails op linkjes of bestanden klikken moet je niet doen, en IoT-apparaten die niet updaten al helemaal niet. Dat is best lachen hoor. Ik heb hier een camera, en daar zit een uitgeklede Linux-versie met als datum 1989 in, die in ROM zit gebakken.

Maar ik sprak over mijn eigen situatie. Ik heb voor alle IoT hier (die overigens uitsluitend met Raspberry Pi's werkt, een apart segment in het netwerk.

Ik segmenteer met hardware-firewalls, die zijn allemaal van verschillende merken en ik heb een apart segment voor uitsluitend IoT-achtige toepassingen die een extra risico vormen.

Bij het meest beveiligde segment moet je drie firewalls bij langs (na de fritz-box) en bij de laatste twee staan alle poorten dicht. Daarnaast heb ik een cold gap-computer met een moederbord waar niets wireless op aanwezig is voor de dingen met de hoogste graad aan veiligheidsvereisten.

Als je virtualiseert is dat ook een risico. Als VMware of Virtual Box een flaw heeft kunnen ze ineens ook overal bij.

Maar wat je zei klopt niet: UPnP is niet in alle situaties een probleem. Bij de meeste mensen wel. En ook vooral omdat maar weinig mensen weten dat dit zo werkt.

UPnP is ook niet het grootste probleem als je op een linkje in een spammail klikt. De kans is veel groter dat ze iets anders vervelends doen. UPnP is dan een beetje een omweg.

[PA0ETE]

Wat ik wel tekenend vind is dat de grootste internetcriminelen uit de hackerswereld helemaal niet via Signal of iets dergelijks communiceren. Die communiceren gewoon openbaar op telkens wisselende onbeveiligde IRC-kanalen. Gewoon in het open.

In de brij van alle communicatie die er nog steeds op IRC voorkomt is het zeer lastig te tracken. En zeker als er wisselende IP-nummers gebruikt worden, telkens anders chatters op telkens andere kanalen.

Bij iets als Signal loop je het risico dat je communicatie door een overheid een keer wel met succes wordt opgeëist. Maar bovenal, zodra de quantumcomputers betaalbaar zijn kun je daarmee iedere huidige encryptie gemakkelijk kraken. Overheden slaan nu al veel van de versleutelde communicatie op, om dat wanneer het eenmaal zo ver is nog een keer nauwkeurig te bekijken.

Je ziet daar dus de rare paradox dat de minst beveiligde en meest ouderwetse omgeving toch de meeste zekerheden biedt...

Wat ik daarmee wil zeggen is dat je nooit moet uitgaan van dat een bepaalde techniek in alle gevallen de slechtste optie is. Of in géén van de gevallen. Je moet altijd blijven opletten en de afhankelijk van precies die omstandigheden beste (en betaalbare) optie nemen.

De mensen die de 9/11 aanslagen pleegden communiceerden via één hotmail-adres. Iedereen uit de groep logde daar in, en bewerkte één conceptmail die er in het account stond. Hadden ze het voor hen bestemde bericht gelezen, dan verwijderden ze die uit de concept-mail. Doordat de overheiden uitsluitend keken naar de communicatie waarbij berichten werden verstuurd, vielen ze bij dit bericht dat helemaal nooit verstuurd werd, volledig buiten alle aftappen van internetverkeer (uiteindelijk hebben de diensten ook daar weer van geleerd uiteraard).

[PE2AAB]

Dikke Zucht weer.

Zonder enige netwerkverandering werkt de PiStar weer eens niet. Alle modemsettings welke ik in het verleden heb gemaakt om de zaak weer werkend te krijgen zijn nog altijd zo ingesteld maar op de een of andere manier stopt dat met functioneren.

Verbinding met REF001? Geen probleem. DCS007? Dat werkt niet. Heel raar allemaal. En ik ben niet alleen; diverse mensen klagen over dit issue en nog geen enkele échte oplossing kunnen vinden helaas.

Er kon geloof ik ook Spaanse firmware op die PiStar? Waar vind ik dat? Iemand een idee?

[PA3GNZ, Tjeerd]

Je bedoelt EA7EE

http://wiki.digitalevoice.nl/?p=558

Met de UK versie ben ik nog steeds aan DCS007B geconnect.

Probeer je misschien via 2 devices te connecten? Dat geeft problemen.
1 hotspot aan een reflector.

[PA0ETE]

Rick, wat is het probleem dan? Mijn repeaer draait PI-STAR, en die draait vaak een halfjaar of driekwart jaar zelfs zonder te rebooten. Volkomen stabiel. En dat al een aantal jaren.

Mijn ervaring is dat aler er met een Raspberry iets niet goed gaat, dat het vrijwel altijd aan de voedingsadapter ligt. Namelijk 1 van de volgende drie problemen:

1. de spanning is te laag, 2. de spanning is te hoog, en 3. wat er uit de adapter komt is niet helemaal schoon.

Moderne computers als de Raspberry hebben er foutoplossende systemen in zitten, dat betekent dat een slecht werkende Raspberry niet meteen stopt met werken of fouten maakt. Hij lost de fouten nog een tijdlang zelf op. Maar het oplossen van die fouten kost wel resources. En bij een slechte voeding werkt het dus ook wel, maar de Raspberry moet misschien te hard werken.

Volgens mij staat de watchdog van het OS van de Raspberry standaard aan, maar daar zou je ook nog even naar kunnen kijken. Die watchdog is een hardware watchdog. Als de CPU het te druk krijgt of het geheugen loopt vol waardoor hij niet meer goed functioneert, activeert de watchdog een reboot.

Dat zijn allemaal dingen die de betrouwbaarheid verhogen. PI3XDV werkt met Raspberry Pi's 3B+ Ik denk dat het vijf jaar geleden is dat dat kaartje is aangemaakt. Ik loop vaak net iets achter de updates aan omdat er soms updates zijn geweest waarna het niet meer helemaal goed werkte (wat vervolgens na een paar dagen of een week werd opgelost met een nieuwe update).

Maar ik heb er dus geen enkel omkijken naar. Het is het meest stabiele en probleemloze deel van de hele repeater (die daarnaast ook nog een analoge repater bevat met een eigen Raspberry Pi 3B+ )

Het zou eventueel ook nog een hardwareprobleem kunnen zijn in het modemprintje, maar die werken meestal wel ok.

Oh ja, ik heb met de Spaanse versie nooit wat gedaan. Er schijnt ook nog een Amerikaan te zijn die een eigen versie uitbrengt.

PI3XDV is overigens wel D-STAR-only.

Audiostream van de repeater: http://dm.shorties.be:8032/ShortiesFMlive

Dashboard: http://dm.shorties.be

[PE2AAB]

Hi John,

Ja het échte probleem laat zich moeilijk omschrijven. Ik noem het een ‘intermittent fault’. Soms doet zich het gewoon voor.

De PiStar connect niet met ‘kanalen’ uit de DCS reeks. ‘Not Linked’ krijg je te horen.
Als ik inlog op het dashboard van de PiStar en daar een ander kanaal kies; REF001 bijvoorbeeld; dan komt de verbinding gewoon tot stand.

Enige tijd geleden loste ik dit op met de juiste poortforwarding (de juiste poorten open zetten voor DCS en pakketten doorsturen aan het IP adres van de PiStar).
Dat loste het probleem op. Tijdelijk want later deed zich het probleem wéér voor.
Toen heb ik in die poortforwarding regel in mijn KPN modem UDP aangepast naar UDP&TCP en werkte het weer. Na een tijdje aangestaan te hebben merkte ik van de week weer dat het schermpje wel lang donker was. Geen activiteit op DStar? Nee dat was het niet; het bleek dat op het dashboard van de PiStar het woord ‘not linked’ weer zichtbaar was en ik alleen met REF ‘kanalen’ kan connecten en niet met DCS.

Ter verduidelijking; zonder enige vorm van aanpassing in KPN modem of PiStar.
Ook het toegewezen IP adres van de PiStar is ongewijzigd. Je kunt deze in het KPN modem op Mac adres koppelen aan een vooraf bepaald IP adres. Misschien moet ik daar ook wel jet probleem zoeken en een statisch IP adres in de PiStar zetten. Geen idee.

Ik hoop dat dit mijn probleem een beetje beter verduidelijkt?

[PA0ETE]

Port forwarding moet open staan met UDP voor alle audio-kanalen (dat zijn ze bijna allemaal) en TCP voor het dashboard en APRS en zo.

Ik weet niet of je ook buitenlandse reflectors wilt connecten. Maar alleen als je ouderwetse DCS-reflectors wilt connecten heb je DCS echt nodig. Van alle protocollen is DCS echter wel de beste.

Alle in Nederland gebruikte reflectoren en de meeste in Europa kun je zowel met REF, XRF als DCS ervoor benaderen (XLX kan ook, maar dat is identiek aan DCS). Op zich kun je daarom zonder DCS.

Het blijft wel een raar probleem dat ik niet begrijp. Tenzij je de poort voor DCS niet standaard naar de hotspot gerouteerd hebt.

[PA0ETE]

Volgens Andy, MW0MWZ, de maker van PI-STAR zijn dit alle poorten die je voor een D-STAR-repeater nodig hebt:

**Outbound (from the repeater to the internet)

TCP/21 - FTP updates probably not needed any more
TCP/22 - SSH to Github probably not required
UDP/53 - DNS, not required if they are going to give you internal DNS servers
TCP/80 - HTTP for updates from Raspbian Servers
UDP/123 - Network time
TCP/443 - HTTPS updates from Raspbian servers / Github
TCP/9418 - Github updates

TCP/53 - Used for Zone transfer method by ircDDBGateway as part of the host lookup process (yes this really is TCP)
TCP/9007 - ircDDB callsign routing
TCP/14580 - D-PRS postion data
TCP/20001 - D-Plus Outbound Connections

**Bi-Directional, in and out.
UDP/20001-20007 - D-Plus Voice
UDP/30001 - DExtra Voice
UDP/30051 - DCS Voice
UDP/30061-30064 - CCS
UDP/40000 - Icom G2

You can trim the in-bound ports down, if you only wanted your repeater to take connections on one protocol, for the best results if you can have them all open, open them all.

Source:
https://forum.pistar.uk/viewtopic.php?t=1975