Oönskad extern KNXnet/IP Routing multicast trafik

Diskussion om KNX standard
Användarvisningsbild
Phiplex
Medlem
Medlem
Inlägg: 11
Blev medlem: 07 apr 2009, 18:04
Kontakt:

Oönskad extern KNXnet/IP Routing multicast trafik

Oläst inläggav Phiplex » 12 dec 2017, 19:31

Nedanstående är en sammanställning av det jag skrivit nyss om i en Facebook grupp för att jag behövde hjälp. Därför blev det lite utförligt eftersom de flesta där inte vet så mycket om KNX. Kanske kan det finnas några även i detta forum är intresserade av vad som hände mig och vad jag till slut kom fram till och hur jag löste det (tror jag). Kanske t.o.m någon som har varit med om något liknande?

Hur blockerar jag inkommande multicast internet IP-paket från specifika avsändare, dvs från vissa IP-adresser (source-address) eller till vissa multicast-adresser.

Jag har upptäckt ett märkligt problem jag behöver hjälp med att lösa. Gissar att jag först behöver ge lite (tyvärr lång) bakgrundsinformation för att kunna förklara.

Min hemautomation är baserad på KNX. För kontroll av olika enheter används i grunden en TP-bus (Twisted Pair - som kommunicerar med 9600 b/s). Den logiska styrningen sker dock i datorer som kommunicerar över ett internt IP-nätverk (192.168.x.x). För kopplingen mellan TP-bussen och IP-nätverket används en gateway (KNXnet/IP Router) som är en Linux daemon (eibd) i en Raspberry PI. All KNX-trafik på IP-nätverket sker enligt KNX-standard med UDP multicast på IP-adress 224.0.23.12 och port 3671. Det interna IP-nätverket är kopplat med fiber till Internet via en Telia router (Technicolor TG799vn v2) vilken är öppen för all multicast trafik då vi även använder Telia DigitalTV som baseras på just multicast.

Sedan en tid tillbaka har jag ibland noterat att ”konstiga saker” kunde hända, t.ex. att en lampa plötsligt kunde släckas eller tändas utan att jag (eller automatiken) vidtagit någon åtgärd. Eftersom jag loggar varje händelse i mitt KNX-system upptäckte jag efter ett tag att vissa (men inte alla) av dessa händelser också alltid inträffade vid exakt samma tidpunkt.

Inledningsvis trodde jag att orsaken kunde vara störningar på KNX-bussen eller i UDP-trafiken (som ju inte har samma fel-kontroller som TCP). Efter ett tag bestämde jag mig dock att undersöka saken närmare och skrev ett litet program i C för logga och exakt se hur KNX multicast-trafiken såg ut. Alla IP-paket innehåller ju, förutom en IP mottagaradress (KNX multicast-adressen enl. ovan) även en IP avsändaradress. Denna IP avsändaradress används aldrig av någon mottagare, men borde tillhöra någon av mina ”KNX-datorer” i det interna IP-nätverket, dvs ha en IP-adress inom intervallet 192.168.x.x.

Jag upptäcker då att vissa multicast-paket, som dock hade helt korrekt utseende enligt KNX-standarden, emellertid alltid hade en och samma avsändaradress jag inte kände igen (193.147.115.184). Ibland råkade nyttolasten i dessa ”externa” multicast-paket också innehålla en KNX-mottagaradress dvs. så kallad group-address x/x/x (inte samma som IP-mottagaradress) som överensstämde med någon av mina KNX-enheter och kunde därmed påverka denna.

Se bilden jag bifogat nedan.

När jag kontrollerar denna okända IP-adress (193.147.115.184) visar den sig tillhöra en dator med DNS-namnet eibport.eeza.csic.es där eib är det gamla namnet för KNX och där eibport är namnet på en känd KNX-enhet (tillverkas av bab-tec.de och säljs även av ABB). Kollar jag sedan www.eeza.csic.es visar det sig vara en spansk organisation som är ”The Experimental Station of Arid Zones (EEZA) - an Institute of the Superior Council of Scientific Investigations pertaining to the Area of Natural Resources, created in 1947”. Det är därför troligen en legitim KNX-installation, men där man felaktigt konfigurerat sin KNX multicast-trafik så att den ”läcker ut” på Internet. Det kan man göra genom att sätta TTL (Time To Live) till ett för högt värde - ska normalt vara 1 enl nedan.

TTL Scope
----------------------------------------------------------
0 Restricted to the same host. Won't be output by any interface.
1 Restricted to the same subnet. Won't be forwarded by a router.
<32 Restricted to the same site, organization or department.
<64 Restricted to the same region.
<128 Restricted to the same continent.
<255 Unrestricted in scope. Global.

Tillsvidare har jag kommit runt problemet genom att låta min egen KNX multicast-trafik använda en annan IP multicast-adress och port än den som är standard. Men denna oönskade KNX multicast-trafik kommer fortfarande in, men stör just nu inte längre min KNX-installation.

Ett annat sätt att göra hade t.ex. varit att köra all egen KNX multicast-trafik i ett eget VLAN. Men då hade jag inte enkelt kommit åt att bl.a. konfigurera mina egna ”KNX-datorer och enheter” från mina ordinarie PC från vilka jag också vill ha åtkomst till Internet.

Jag vill dock filtrera bort denna externa multicast-trafik helt och hållet, men vet inte hur jag skall göra och behöver hjälp. Telias Router förefaller vara tämligen stängd och jag hittar inga inställningar i dess firewall för att få bort denna oönskade trafik. Tacksam för idéer.

PS Skulle någon vilja kolla sitt eget interna nätverk och se om samma oönskade multicast-trafik förekommer även där finns källkoden till mitt c program här: https://1drv.ms/f/s!ApmotS4N2WF8zDi3GZ2zjIiuGu_B

Körs på en Linux-burk t.ex en Raspberry PI. 
Kompileras med: gcc -o mc mc.c
Körs: ./mc

=====================================================================

Ni ska ha många tack för alla idéer, förslag och synpunkter. 

Jag har avvaktat med att återkomma tills nu då jag ville invänta alla idéer, men ska nu ge lite kommentarer och berätta vad jag kommit fram till. 

Allra enklast hade nog varit att bara göra en portmappning i Telias Router. Glömde ursprungligen dock att nämna att jag redan hade testat det, och tyvärr blev det ingen översättning till unicast som jag hade hoppats. 

Att sedan endast använda iptables i Raspberry PI gateway’en skulle ju helt klart spärra dessa oönskade KNX multicast paket att komma vidare in på TP-bussen och där påverka de ”riktiga” KNX-enheterna. Emellertid skulle multicast-paketen fortfarande komma fram till de styrande KNX-datorerna på det interna IP-nätverket. Dessa datorer är dessvärre helt stängda/låsta av tillverkaren, så här kan jag inte komma åt några iptables, och i dessa datorer finns också "virtuella” KNX-enheter som har reagerat på inkommande multicast trafik för att initiera olika scenario till exempel. 

För att verkligen kunna blockera dessa paket, som var min ursprungliga tanke, hade det nog behövts att sättas en separat firewall/router (eller dator med t.ex pfsense) framför Telias Router, som flera varit inne på. Då hade billigast nog varit att använda en Mikrotek (kollade specarna som hastigast och är dock lite fundersam på om den billiga alltid klara överföringshastigheten mot Internet >= 100 Mbps). 

Eller som några undrade varför jag använde Telias enkla (leksaks-)router och inte redan hade något mer kompetent. Visst det hade också varit ett alternativ, men svaret är helt enkelt att jag (hittills) inte sett något behov, utan istället tvärtom. För då hade jag behövt (tror jag) köra Telias DigitalTV box på ett separat VLAN och då inte heller kommit åt tvboxen från mitt övriga LAN inkl de styrande KNX-datorerna. Detta eftersom jag också styr tvboxen via hemautomatiken (istället för Telias Zappa app använder jag egenskrivna C/Python-program. (Se https://1drv.ms/f/s!ApmotS4N2WF8zC2IdqbrvuvxIcaR jag lagt upp efter andra frågat efter detta). Hade säkerligen gått att lösa med mer kompetent router också, men eftersom allt jag (hittills) behövt fanns i Telias Router fick den vara kvar. 

MEN ... sedan har jag börjat fundera lite till och även läst på mer om hur multicast egentligen fungerar. 

Jag skrev ju i mitt första inlägg att den ”oönskade KNX multicast-trafik fortfarande kommer in, men att den just nu inte längre stör min KNX-installation eftersom jag nu använder en inte standard multicast-adress och port”. 

Det är visserligen sant att denna oönskade multicast-trafik kom in och att jag kunde se den med hjälp av mitt C-program, MEN jag tror nu att det endast berodde på att jag just letade efter denna trafik och specifikt frågade efter den med hjälp av mitt program. Och det var endast därför trafiken då fortfarande kom in via Telias Router. 

Innan jag ändrade min egen KNX multicast trafik till en ny egen inte standard multicast-adress och port, så var det från min KNX-gateway och KNX-datorer som begäran kom om att få in den då standardiserade men oönskade KNX multicast-trafiken. 

Låt mig förklara lite närmare:

För att man skall få tillgång till multicast-trafik måste man begära det. Det görs med hjälp av ett speciellt protokol som heter IGMP - Internet Group Management Protocol, som just är avsett för detta, dvs för en host att be om att få vara med i (Join) och även lämna (Leave) en multicast-ström (eller multicast-grupp, som det också kallas) på en viss multicast-adress och port. 

Och det var just att ”Join” denna multicast-grupp (adress och port) jag gjorde i mitt C-program med dessa kodrader:

Kod: Markera allt

/* use setsockopt() to join a multicast group */
mreq.imr_multiaddr.s_addr = inet_addr(DEFAULT_GROUP); 
mreq.imr_interface.s_addr = htonl(INADDR_ANY); 
setsockopt(sock, IPPROTO_IP, IP_ADD_MEMBERSHIP, &mreq, sizeof(mreq));


Det är alltså inte så att all multicast-trafik som finns på Internet kommer in via en multicast-öppen router. Dvs. multicast är inte, som mycket riktigt påpekades, det samma som broadcast, utan man måste be om att få in (få tillgång till) varje specifik multicast-trafik (vilket ju när man tänker efter är ganska självklart eftersom annars skulle vi bli översvämmade med multicast-trafik ). 

Men inte nog med det, utan från och med version 3 av IGMP (IGMPv3) kan man faktiskt också begära att få in/tillgång till multicast-trafik inte bara från en viss multicast-grupp (adress+port) utan också att endast få multicast-trafik från ev viss eller vissa avsändare (source IP-adresser), alternativt att slippa få multicast-trafik från vissa source IP-adresser. Allt detta sköts sedan av routern så att den bara släpper in den trafik man vill ha. 

Och det är ju precis detta jag ville ha ...

Men jag har istället just bett om att på in all multicast-trafik från alla source IP-adresser när jag i koden ovan skriver:

Kod: Markera allt

mreq.imr_interface.s_addr = htonl(INADDR_ANY); 


... där INADDR_ANY just betyder ge mig multicast-trafik från ANY source IP-adress. Dumt va’! Det var alltså detta som gjorde att jag trodde att den oönskade KNX multicast-trafiken fortfarande kom in, trots att jag ändrade multicast-adress och port på min egen interna KNX-trafik. 

Se mer på de bilder som finns på [url]https://mrncciew.com/2012/12/25/igmp-basics/ [/url] där mer info också finns. 

Men när jag sedan kollar närmare och lusläser manualen till mina HP Procurve 2524 switchar står det tyvärr följande:

”When an IGMPv3 Join is received by the switch, it accepts the host request version 3 and begins to forward the IGMP traffic. ... The switch does not support the IGMPv3 “Exclude Source” or “Include Source” options in the Join ... Rather, the group is simply joined from all sources.”

Så det är den sista meningen att ”the group is simply joined from all sources” som fördärvar det hela igen. Dvs switchen bryr sig inte om att tala om för routern att den bara vill ha/eller exkludera multicast-trafik från en viss source IP-adress. 

Nåväl, strunt i det för i och med att jag nu bytt min interna KNX multicast-trafik till en inte standardiserad multicast-adress och port så begär jag ju aldrig numera av routern att få in den oönskade multicast-trafiken. 

Åtminstone så länge jag inte också använder mitt eget C-program för att kolla om den kommer in - vilket ju tyvärr också i så fall innebär att jag då samtidigt begär att få in denna oönskade trafik. Att jag inte tänkte på det från början. :oops:

Min egen slutsats av allt ovan blir då till slut att jag nog inte behöver göra mer just nu utöver det som redan är gjort (bytet av multicast-adress och port). 

Detta var en liten resa för mig så jag tänkte jag skulle dela med mig av min erfarenhet. Det är kanske självklarheter för alla ni som kan KNX utan och innan, men nytt för mig. Den erfarenhet jag tar med mig är att INTE använda den standardiserade KNX multicast-adresssen 224.0.23.12 och porten 3671 - åtminstone om IP-nätverket samtidigt har en anslutning till Internet via en router som är öppnad för multicast-trafik.

Skulle också kännas skönt om någon som kan detta bättre än jag kunde kommentera om jag tänkt rätt.
Bilagor
KNX.jpg
Senast redigerad av Phiplex 01 jan 1970, 01:00, redigerad totalt 0 gånger.
Anledning: ""

Videonisse
Betrodd medlem
Betrodd medlem
Inlägg: 331
Blev medlem: 30 aug 2011, 23:39
Kontakt:

Re: Oönskad extern KNXnet/IP Routing multicast trafik

Oläst inläggav Videonisse » 13 dec 2017, 15:01

Intressant inlägg men hinner inte läsa hela nu.

Men undrar hur många KNX-enheter som du planerar ha på IP-nätet och vilka funktioner dessa kommer ha?

Frågar eftersom du låst in dig på KNX routing med sina för- och nackdelar. Går väl ofta bra (bättre?) att köra KNX tunnel istället och då kanske slippa mycket av det du har problem med.
Senast redigerad av Videonisse 01 jan 1970, 01:00, redigerad totalt 0 gånger.
Anledning: ""
Bygger ut & renoverar villa från 1943, 8 rum+kök+2 WC/dusch. KNX i utbyggnaden, utökar när renoveringen fortskrider. Bel.plan från ljusdesigner för hela huset, ca 100 downlights totalt+övriga fasta armaturer+lamputtag. Styrning via Dali eller DMX.

Rikard Ågren
Betrodd medlem
Betrodd medlem
Inlägg: 219
Blev medlem: 22 mar 2015, 20:01
Ort: Västerbotten
Kontakt:

Re: Oönskad extern KNXnet/IP Routing multicast trafik

Oläst inläggav Rikard Ågren » 13 dec 2017, 20:18

Intressant och informativ läsning!

Vi har alla fastigheter på en multipunktnät hos vår ISP så vi kan prata mellan utan att gå via internet. Förhoppningsvis slipper vi dylika problem
Senast redigerad av Rikard Ågren 01 jan 1970, 01:00, redigerad totalt 0 gånger.
Anledning: ""
El & styrteknik


Återgå till "Allmänt"

Vilka är online

Användare som besöker denna kategori: 2 och 0 gäster