Server migration complete, Welcome to version 2.1.1



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

+-Site Stats

Total Members: 15187
Latest: 3636lightshow
New This Month: 4
New This Week: 0
New Today: 0
Total Posts: 123961
Total Topics: 15067
Most Online Today: 49
Most Online Ever: 7634
(January 21, 2020, 02:14:03 AM)
Users Online
Members: 2
Guests: 15
Total: 17

Bug in 5.5

Started by lrhorer, June 22, 2022, 03:23:40 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.


There is an apparent bug in 5.5.  Admittedly this is a corner case, but it makes the status page mostly useless.  I do not know if it impacts other pages, but so far I have not seen any other issues.

I am going to be deploying (hopefully) a large number of remote FPP systems all over town.  In order to manage them, I need to be able to get to them from a central location.  The router I am using employs WireGuard VPN for secure VPN communications.  Each FPP host will have WireGuard installed, and the host will be attached to a WiFi Hotspot with cellular service.  The FPP host will come up on the WiFi LAN of the HotSpot, and the HotSpot will keep up a cellular connection to the internet.  When the host comes up, it initiates a VPN connection back to my router, allowing me to manage the host remotely.

The issue is, whenever the VPN is activated (automatically upon boot), the FPP status page gets blasted.  Much of the information disappears.  The controls do seem to still work - at least the ones I have tried, but most of the status is gone.  This includes all the playlist information, including the elapsed and remaining times.  Although not always required, there are times some of this information can become important, and it is always nice to have.

The issue occurs when the very first command is processed:

ip link add dev wg0 type wireguard

The issue  clears when he VPN is shut down - although for these purposes it never will be.  The only error that pops up is in apache2-error.log:
[Tue Jun 21 10:31:24.902193 2022] [php7:notice] [pid 3515] [client] PHP Notice:  Undefined index: address in /opt/fpp/www/common.php on line 1990, referer:

No errors at all are apparent if the VPN is shut down.  Here is a normal screen shot from another FPP host (ignore the abnormal conditions - the F16 hosts are not online):

 You cannot see attachments on this board.

and a screen shot from a VPN client:

You cannot see attachments on this board.


It's likely an issue with the wg0 device name.   There are definitely places that assume devices that start with "w" are wifi and are looking for wifi properties.      I know for FPP6 I removed some of the places that assumed various network device names.  There might still be some issues left as most of the problems I was seeing were between eth0 and the en###### naming so those were better tested.

That said, not likely something that will be fixed for 5.x.   If you would like to help diagnose things for FPP6, it's possible we'd get it fixed there, but since it's not a normal setup, we'd really need your help in digging through things to figure out where the problem would be. 
Daniel Kulp -


I can probably help a it, yeah.  Also, I can try renaming the interface.  It doesn't have to be wg0.

Meanwhile, is there a command line option which will show the status?


Can you SSH in and run the following command when the VPN is up and the error is happening?

ip --json address show

Paste the results here and we can take a look.

You could also try modifying line 1990 in /opt/fpp/www/common.php to make it look like this:

$add = isset($rec["address"]) ? $rec["address"] : "";

If that doesn't help, try changing the "" at the end to "" which should cause the rest of the code to ignore that interface.


OK, note I did not fully bring up the VPN, because the error occurs well before the VPN is up.  It happens when the dev is first created using the `ip link add...` command.  I also tried it using a dev other than wg0 (I used vpn0), and the result is the same.  I can bring up a VPN if necessary, but for now I have simply created the dev / link.  Note at this point the IP is not set and the link is not up.

For completeness, here is the link info.
7: vpn0: <POINTOPOINT,NOARP> mtu 1420 qdisc noop state DOWN group default qlen 1000
    link/none  promiscuity 0 minmtu 0 maxmtu 2147483552
    wireguard numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535


Thanks, those confirm it.  The 'vpn0' interface doesn't have a hardware address element, so this issue would affect any interface without a hardware address.  Here is part of eth0 vs vpn0.

        "ifindex": 3,
        "ifname": "eth0",
        "flags": [
        "mtu": 1500,
        "qdisc": "pfifo_fast",
        "operstate": "UP",
        "group": "default",
        "txqlen": 1000,
        "link_type": "ether",
        "address": "b8:27:eb:85:01:ff",    <<<< vpn0 doesn't have this entry.
        "broadcast": "ff:ff:ff:ff:ff:ff",
        "addr_info": [

        "ifindex": 7,
        "ifname": "vpn0",
        "flags": [
        "mtu": 1420,
        "qdisc": "noop",
        "operstate": "DOWN",
        "group": "default",
        "txqlen": 1000,
        "link_type": "none",
        "addr_info": []

Since this is the hardware address field, I think that the line of code I gave would fix at least part of the issue.  Did you have a chance to try changing that line of code in /opt/fpp/www/common.php?


Quote from: CaptainMurdoch on June 22, 2022, 11:57:01 PMYou could also try modifying line 1990 in /opt/fpp/www/common.php to make it look like this:

$add = isset($rec["address"]) ? $rec["address"] : "";

That seems to have worked!  I first tried it on a test system with the dev created and then made the change to a live system with the VPN fully up, and everything looks normal.

I definitely appreciate the help.  Let me know if there is something you need on the v6 development, and I will take a look.  My experience with PHP is exceedingly tiny, but I can always try.  I have a bit more experience with Python, and considerably more with c and assembly - although I am certainly no developer.  I have a considerable amount of experience with bash and sh.

That brings up a subject in my mind.  I will be more than happy to work with you folks in some development and I certainly can do testing.  I have RPi 2s 3s, 4s, and Zero Ws.  I am running Debian on my servers.  I also have some Banana Pis, if they are of any interest.  More in mind, however, it has been a while since I contributed any cash to the project.  I need to do that.  I have very limited funds, because I have been unemployed for quite a while, but I will give what I can.


Dan pushed this change to the master branch and I also pushed to the v5.5 branch, so you should be able to revert the manual change and pull in FPP updates and have it working.


Quote from: CaptainMurdoch on June 23, 2022, 11:36:46 AMDid you have a chance to try changing that line of code in /opt/fpp/www/common.php?
Give me a minute, will you!  ;D

I have poked around some more on the production system, and everything seems normal.  Again, thanks loads.  I am partnering with a friend who provides concierge services.  A large part of his business involves installing holiday lights for his customers, and he wants to look into providing more than just static lights.  That is where I come in, and by association, you.  (I know, being associated with me is a horrifying thought.)  I have placed a small system (one string of 150 lights on GPIO pin 12 of a Raspberry Pi Zero W) at his house and am managing it for a proof of concept.  For his house, there is no huge problem with simply attaching the Pi to his WiFi and creating a few port forwards on his router.  This would not be at all practical for many reasons on customer's premises.  My solution has been to buy a Moxee HotSpot with inexpensive data service and adding a WireGuard VPN to my home router, which employs WireGuard.  I can't say much about the router, because I am under ND, but everything seems to be coming together.

It is certainly possible I may wind up the only person ever using this approach, but I can see where it might appeal to others.  People with large estates (too large for simple WiFi) might like to use this sort of arrangement.  An entire neighborhood could band together to coordinate their displays.  People with family members who are very tech limited could manage their family's displays.  With pre-paid cellular plans, one can activate the HotSpot for a month and then shut down until the next season, limiting the cost considerably.


Quote from: CaptainMurdoch on June 23, 2022, 11:59:38 AMDan pushed this change to the master branch and I also pushed to the v5.5 branch, so you should be able to revert the manual change and pull in FPP updates and have it working.

Support FPP

+- Recent Topics

Bridging networks so show network can access internet by bloojoop
July 04, 2022, 03:08:03 PM

Looking for FPP Initial Setup screen by Poporacer
July 04, 2022, 11:51:56 AM

FPP 5.4 Released! by Poporacer
July 04, 2022, 08:42:52 AM

Falcon player dynamic tempo from some kind of input. How would I go about it? by JonD
July 03, 2022, 03:20:37 AM

FPP Startup - Newbee by Poporacer
July 02, 2022, 08:51:24 AM

EDM Audio FPP Plugin - RDS Expectations? by JonD
July 02, 2022, 06:12:35 AM

The Blenders - Rudolph by breese
July 01, 2022, 08:21:41 AM

fpp error when writing to emmc on BBB by neilric99
June 30, 2022, 11:28:59 PM

Any idea when more will be available by Poporacer
June 30, 2022, 09:39:31 PM

Trouble with wifi tethering/ initial setup by Poporacer
June 29, 2022, 09:14:53 PM

Powered by EzPortal
Powered by SMFPacks Menu Editor Mod