News:

Server migration complete, Welcome to version 2.1.1

+-+-

+-User

Welcome, Guest.
Please login or register.
 
 
 
Forgot your password?

+-Site Stats

Members
Total Members: 15505
Latest: jduncc
New This Month: 13
New This Week: 5
New Today: 5
Stats
Total Posts: 127161
Total Topics: 15602
Most Online Today: 61
Most Online Ever: 7634
(January 21, 2020, 02:14:03 AM)
Users Online
Members: 4
Guests: 44
Total: 48

Disabling the 'built-in' e131 server?

Started by sirwesley, December 09, 2020, 09:32:54 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

sirwesley

Trying to run my own custom e1.31 server on the FPP.  Is there anyway I can disable the built-in e1.31 server to free up the 5568 port so my custom NODEJS App will run.  

I posted over in the FFP Discussion board, but that was before I saw this more technical board.  

https://falconchristmas.com/forum/index.php/topic,13757.0.html

When starting up the app, I'm getting:

Error: bind EADDRINUSE 0.0.0.0:5568

CaptainMurdoch

You would need to comment out a line of code in the source and recompile to do this. Even when not running in bridge mode, fppd listens on the E1.31 port so that it can log warnings if it is being sent E1.31.

If you want to give it a try, edit /opt/fpp/src/fppd.c and search for 'Fake_Bridge_Initialize' and comment out that line of code.  cd to /opt/fpp/src/ and run "sudo make fppd && systemctl restart fppd' and when fppd restarts it shouldn't be listening if you are not running in Bridge mode.
-
Chris

sirwesley

Just found it prior to your reply.

AddFakeListener(E131_DEST_PORT, "E1.31", callbacks);

Thanks for your feedback.  I'll give it a shot and report back.

sirwesley

Okay, I was able to recompile and get my server running now along side my Node App.  Much thanks for that!

However, now even though I have my controller setup to use e1.31 unicast to 127.0.0.1 (and also tried multicast), for some reason the FPP isn't sending to it / Looping it back to 127.0.0.1.  


  • I'm able to send FPP e131 data and receive it on Xlights PC.   
  • I'm able to send Xlights e131 data and receive it on FPP.   
  • Just can't get the data looped back (internally) to the 127.0.0.1 address, it would appear.  

Any suggestions on configuration for the routing table or whatever so that my local app and FPP can talk?

CaptainMurdoch

I don't recall if there is anything specific preventing 127.0.0.1 loopback, but you could also try the eth0 IP and see if that works.  I thought we recently looked into a case where the user was looping back unintentionally but can't remember the specifics.
-
Chris

sirwesley

Unfortunately, specifically targeting the IP of either eth0 or wlan0 didn't work.  As you can see below in my netstat query, my 6658 port is only listening on 0.0.0.0 and not localhost as is ntp. 

Not sure what I need to do to configure it so that I get localhost added.  Ideas?  Route add <cmd>?  

fpp@FPP:~ $ netstat --listen


Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address          Foreign Address        State
tcp        0      0 0.0.0.0:domain          0.0.0.0:*              LISTEN
tcp        0      0 0.0.0.0:ssh            0.0.0.0:*              LISTEN
tcp        0      0 localhost:smtp          0.0.0.0:*              LISTEN
tcp        0      0 0.0.0.0:microsoft-ds    0.0.0.0:*              LISTEN
tcp        0      0 0.0.0.0:32322          0.0.0.0:*              LISTEN
tcp        0      0 0.0.0.0:4200            0.0.0.0:*              LISTEN
tcp        0      0 0.0.0.0:rsync          0.0.0.0:*              LISTEN
tcp        0      0 0.0.0.0:netbios-ssn    0.0.0.0:*              LISTEN
tcp        0      0 0.0.0.0:http            0.0.0.0:*              LISTEN
tcp6      0      0 [::]:domain            [::]:*                  LISTEN
tcp6      0      0 [::]:ftp                [::]:*                  LISTEN
tcp6      0      0 [::]:ssh                [::]:*                  LISTEN
tcp6      0      0 [::]:microsoft-ds      [::]:*                  LISTEN
tcp6      0      0 [::]:rsync              [::]:*                  LISTEN
tcp6      0      0 [::]:netbios-ssn        [::]:*                  LISTEN
udp        0      0 0.0.0.0:57263          0.0.0.0:*
udp        0      0 0.0.0.0:5568            0.0.0.0:*
udp        0      0 0.0.0.0:37919          0.0.0.0:*
udp        0      0 0.0.0.0:domain          0.0.0.0:*
udp        0      0 0.0.0.0:32320          0.0.0.0:*
udp        0      0 0.0.0.0:bootps          0.0.0.0:*
udp        0      0 FPP:ntp                0.0.0.0:*
udp        0      0 192.168.1.44:ntp        0.0.0.0:*
udp        0      0 localhost:ntp          0.0.0.0:*
udp        0      0 0.0.0.0:ntp            0.0.0.0:*
udp        0      0 192.168.1.25:netbios-ns 0.0.0.0:*
udp        0      0 192.168.1.44:netbios-ns 0.0.0.0:*
udp        0      0 192.168.1.25:netbios-ns 0.0.0.0:*
udp        0      0 FPP:netbios-ns          0.0.0.0:*
udp        0      0 192.168.7.25:netbios-ns 0.0.0.0:*
udp        0      0 192.168.7.2:netbios-ns  0.0.0.0:*
udp        0      0 0.0.0.0:netbios-ns      0.0.0.0:*
udp        0      0 192.168.1.2:netbios-dgm 0.0.0.0:*
udp        0      0 192.168.1.4:netbios-dgm 0.0.0.0:*
udp        0      0 192.168.1.2:netbios-dgm 0.0.0.0:*
udp        0      0 FPP:netbios-dgm        0.0.0.0:*
udp        0      0 192.168.7.2:netbios-dgm 0.0.0.0:*
udp        0      0 192.168.7.2:netbios-dgm 0.0.0.0:*
udp        0      0 0.0.0.0:netbios-dgm    0.0.0.0:*
udp        0      0 0.0.0.0:46225          0.0.0.0:*
udp        0      0 0.0.0.0:45719          0.0.0.0:*
udp        0      0 0.0.0.0:mdns            0.0.0.0:*
udp6      0      0 [::]:domain            [::]:*
udp6      0      0 fe80::ba27:ebff:fe6:ntp [::]:*
udp6      0      0 fe80::ba27:ebff:fe3:ntp [::]:*
udp6      0      0 localhost:ntp          [::]:*
udp6      0      0 [::]:ntp                [::]:*
udp6      0      0 [::]:mdns              [::]:*
udp6      0      0 [::]:48422              [::]:*




fpp@FPP:~ $ route -n
Kernel IP routing table
Destination    Gateway        Genmask        Flags Metric Ref    Use Iface
0.0.0.0        192.168.1.1    0.0.0.0        UG    0      0        0 wlan0
192.168.1.0    0.0.0.0        255.255.255.0  U    0      0        0 eth0
192.168.1.0    0.0.0.0        255.255.255.0  U    0      0        0 wlan0
192.168.1.1    0.0.0.0        255.255.255.255 UH    0      0        0 wlan0
192.168.1.1    0.0.0.0        255.255.255.255 UH    0      0        0 eth0
192.168.7.0    0.0.0.0        255.255.255.0  U    0      0        0 usb0

dkulp

I'm pretty sure the UDPOutput code will specifically block sending any data to itself.   If I try to configure 127.0.0.1, I see:

2020-12-10 16:32:20.682 (19945) channeloutput/UDPOutput.cpp:309: UDP Output set to send data to myself.  Disabling - 127.0.0.1

Surprisingly, if you use "localhost" for the IP address, it seems to allow it.  Thus, that might work.
Daniel Kulp - https://kulplights.com

CaptainMurdoch

Quote from: dkulp on December 10, 2020, 09:34:43 AMSurprisingly, if you use "localhost" for the IP address, it seems to allow it.  Thus, that might work.

ok, I see it now.  I grepped for 127.0.0.1 but didn't see the code that loops through the local IPs to make sure we aren't sending to ourselves.
-
Chris

sirwesley

setting it to "localhost" works! 

Before I saw your replies I also was able to get it working by commenting out the following from the UDPOutput.cpp, but I much prefer not touching the codebase, so I'll go with the 'localhost' trick. 


if (myIps.find(host) != myIps.end()) {
                // trying to send UDP data to myself, that's bad.  Disable
                LogWarn(VB_CHANNELOUT, "UDP Output set to send data to myself.  Disabling - %s\n",
                        host.c_str());
                //o->active = false;  // <-- This was turning it off.
            }


Thanks @dkulp && @CaptainMurdoch !!

My box is now completely self contained and I'm controlling my Philips Illuminate lights without any modifications to its hardware from FPP.  Let there be Light...in a 'controlled' way of course!  ;D 8)

sirwesley

How would I go about requesting a parameter to 'disable e1.31 server' that I had to disable to get my server running?  

Maybe the param would only be visual for developers, but something I could tap into with my future plug-in?

CaptainMurdoch

I am going to look at adding a setting to the master branch for testing.

The eventual goal is to merge bridge and player modes so that you can be playing a sequence and still receive E1.31 to merge with the playing sequence.  This could be useful for something like merging in data coming from a remote camera or another program that can generate E1.31.  In this case, you would be able to disable the network listeners totally since there would be no 'fake' listeners anymore.
-
Chris

Support FPP

+- Recent Topics

Falcon V4 Player by K-State Fan
Today at 07:40:14 AM

Linking FPP Run Command to a Button by tynmar
Today at 06:52:05 AM

Setting Color Order by K-State Fan
Today at 05:59:19 AM

BRP Voting Plugin - Allow others to vote for your songs! by Barkers Random Projects
December 03, 2022, 11:55:24 PM

loading playlist by rangerdan
December 03, 2022, 11:54:31 PM

BBB running 3-4 seconds ahead by MATTS
December 03, 2022, 09:41:41 PM

Remote Pi connection issues by JonD
December 03, 2022, 08:51:55 PM

FPP not releasing control to WLED when idle by cabrio
December 03, 2022, 08:24:43 PM

Setting up new Falcon f16v4 noob question by Scouser10231
December 03, 2022, 03:45:54 PM

Sequence freeze by jnealand
December 03, 2022, 02:51:04 PM

Powered by EzPortal
Powered by SMFPacks Menu Editor Mod