Recent Posts

Pages: [1] 2 3 ... 10
1
Falcon Player (FPP) / Re: FPP 2.0 & hidden WiFi networks?
« Last post by cpnbnanamn on Today at 07:48:01 AM »



You could try editing the SetupFPPNetworkConfigViaConnMann function in /opt/fpp/scripts/functions and where we add the Passphrase/SSID to the config file, add another line of "Hidden=true" .  If that doesn't work, I'm not really sure.  You'll need to research how to do it via connman.
I'm looking to do this to my pi's as well.  My SSID's are hidden as a rule, but I wanted to make sure that I'm editing the correct part of the file. 
This is under my SetupFPPNetworkConfigViaConnMann function.  I'm guessing that I'm just going to add a line under the echo "Passphrase....." like I have placed in red.  Is this correct?  Or would it be better suited to put in the /var/tmp/fpp.config file, as is referenced in the function?



 for f in $CONFIGS; do
        . ${f}

        echo "[service_$INTERFACE]" >> ${TMPFILE}
        if [ "x$SSID" != "x" ]
        then
            echo "Name=${SSID}" >> $TMPFILE
        fi
        if [ "x$PSK" != "x" ]
        then
            echo "Security=psk" >> $TMPFILE
            echo "Passphrase=${PSK}" >> $TMPFILE
            echo "Hidden=true"
2
Falcon Player (FPP) / Re: Pi Zero W and FPP 2.0 - Wifi setup on first boot
« Last post by dkulp on Today at 07:44:19 AM »





Looks like the BBB's are going to be tough.  It seems that we EITHER get the tether mode or we get the ability to connect via the USB cable, not both.  :(


Still investigating to see what might be possible.   Problem is that as soon as I mess something up, nothing works and I have no way to get in and investigate.  :(
3
I think I have the auto-tether mode stuff working on master.    It turns out, I have to turn on tethering AFTER connman starts.  That greatly simplifies thing.   Thus, what it does now is if there is a valid IPv4 address, it leaves everything alone.   Otherwise, it will turn on tethering.   Thus, if wlan0 or eth0 has a valid IP, nothing happens.  If not, you get the tethering.


It does NOT turn off tethering.   Thus, if it auto-turns on, and you go to the networks settings and setup the wlan0 and don't turn off tethering, it will stay on.   


Would be great if folks could test it.   :)     If it works, this WILL warrant new images for 2.1.  No real OS or kernel updates, really just a git pull on the /opt/fpp to pick this up.   Thus, you wouldn't need to re-image anything.

Dan, testing on a BBG with Edimax dongle, on an updated uSD card (to v2.x-master-683, started from the Beta ext4 image) it does boot and eventually broadcasts the FPP SSID.
But, when I enter the password Christmas, it never issues an IP address.
I've tried on two Samsung Smartphones and on a Chromebook. None will give me a usable connection.
Will try a few other devices.
And will try on a RasPi.
4
Falcon Player (FPP) / Re: FPP2.0 on Pi Zero
« Last post by Cjlocey on Today at 06:38:29 AM »
I ran the pixels on my garage last year (about 800 pixels) from a Pi Zero (non W) with a reference designer and it worked fine.  I am running all 5V lights so I just used the big power supply for my pixels to power the Zero and never had any issues :)
5
Falcon Player (FPP) / Re: FPP2.0 on Pi Zero
« Last post by MartinP on Today at 04:58:00 AM »
Well, wouldn't you know it!


I've just put the SD card back in the ZeroW, attached the USB to NTP gizmo to the ZeroW via a powered hub, and it's working fine!!
So it seems the issue may have been the constraint in the power capability of the USB port on the ZeroW.


This of course negates the tiny footprint of using just the ZeroW to run these lights, so I shall use the Pi3 - Ho Hum  ::)


Just thought it was worth an update here.


Martin
6
Falcon Player (FPP) / Re: FPP2.0 on Pi Zero
« Last post by MartinP on Today at 04:44:12 AM »
Hi Mr Miller(?)
Sorry for keeping you up!  :-[


I've transferred the SD card from the ZeroW to a Pi3 with no changes made by myself, and all seems to be working fine with that Pi3, so I guess the config is OK!!
I had wondered previously if it may have been a power issue as I have a USB to NTP adapter in the ZeroW to drive the E682. However, I did try the ZeroW using a Pi3 power plug (2Amps I believe) to no avail. Not too sure how much power the ZeroW can kick out via USB though.
So, the upshot of this is that I can use the Pi3 for this purpose and won't need to worry anyone any more  :)


I have a separate network of several FPP Pi running my Christmas stuff, so I have played with FPP for a while, just not the ZeroW which I thought would be neat to try.
I will tinker with the ZeroW some more to try and resolve the issue, but I won't lose any sleep over it, and I hope I have not caused you to lose too much sleep either!  ::)
Thanks for your time.
Martin
7
Falcon Player (FPP) / Re: No DNS by default
« Last post by lrhorer on Today at 04:07:31 AM »
First of all, I'm glad to hear your problem is solved, but it would be good to hear what solved it...it's late and maybe I'm just missing that point.
I am not entirely certain.  The system had re-set the resolv.conf to nothing but the localhost with a comment "# Generated by resolvconf".  I added a DNS by hand, and it worked.  I went in to the UI and updated the DNS entries with 2 DNS servers, and the system updated resolv.conf with a comment "# Generated by fpp".  Why the file was reverted to one updated by resolvconf and removed the former values, I don't really know.

Second, I can say without a doubt it has never been per interface in FPP....unless there was a bug?!? :)
I suppose it is possible, although I doubt it.  It's also possible I could be mis-remembering.  I have a lot going on.
 
Third, I'm not sure there is an interface specific DNS setup I've ever seen in 25+ years in the tech industry, primarily as a network engineer.

I have.

 
I honestly don't know of how you'd easily do it
That one is easy.  A;though the use of /etc/network/interfaces is deprecated in some distros, the utility was available there.  Example:

Code: [Select]
auto eth0 iface eth0 inet static 
address 192.168.1.58 
gateway 192.168.1.1
network 192.168.1.0 
broadcast 192.168.1.255
dns-nameservers 66.212.63.228 66.212.48.10
I could, for example, set up 2 DNS servers here, one on the 192.168.1/24 interface and one on the 192.168.8/24, which are, respectively, the subnets hosted by the wlan0 and eth0 interfaces on the Raspberry Pi.  After turning off forwarding (of course!), I could then use dnsmasq or some such to set up a proxy on the Pi.  Why anyone would  do such an odd thing is another matter.

I also don't know of a use case that makes sense off the top of my head and this I highly doubt "There are a number of network topologies that require it." as you stated, since I've yet to see it in 25+ years in this space.
One example is a corporate hosting server that has clients on separate interfaces, both of which have separate DNS servers.  The corporation I just left has such a setup, since the newly merged companies still must maintain different networks for the time being, yet must also be able to have certain specific access to each other's networks.

I did a quick Google search to check myself, again, because it's late...and the first hit I got sort of backs the logic as to why it isn't a normal practice and all path / interface selection is dictated by destination address and routing to DNS host:
I agree it is a pathological situation but then so are corporate mergers, not to mention private DNS servers on public networks.  'Definitely not my idea.

and they should be a good use cases that it provides more value than the standard setup...not just proof it could be done haha :)
That they are definitely arguably not.  All I can say is it can be done, not  that it should be.
8
Falcon Player (FPP) / Re: FPP2.0 on Pi Zero
« Last post by nmiller0113 on Today at 03:08:50 AM »
I'd be happy to help you troubleshoot during more normal hours tomorrow.  As for me, I'm in California and should be already in bed as it is :)
9
Falcon Player (FPP) / Re: No DNS by default
« Last post by nmiller0113 on Today at 03:05:23 AM »
First of all, I'm glad to hear your problem is solved, but it would be good to hear what solved it...it's late and maybe I'm just missing that point.

Second, I can say without a doubt it has never been per interface in FPP....unless there was a bug?!? :)

Third, I'm not sure there is an interface specific DNS setup I've ever seen in 25+ years in the tech industry, primarily as a network engineer.  I honestly don't know of how you'd easily do it, but I've learned to never say never :) I also don't know of a use case that makes sense off the top of my head and this I highly doubt "There are a number of network topologies that require it." as you stated, since I've yet to see it in 25+ years in this space.

I did a quick Google search to check myself, again, because it's late...and the first hit I got sort of backs the logic as to why it isn't a normal practice and all path / interface selection is dictated by destination address and routing to DNS host:

https://serverfault.com/questions/423882/configure-a-dns-server-per-nic-interface-eth0-eth1

Again, I never say never and I'm sure there is a way...I just don't agree that there are a lot of configurations out there using that sort of DNS hack....but I'm always open to correction and to learn more....examples please :)  and they should be a good use cases that it provides more value than the standard setup...not just proof it could be done haha :)
10
Falcon Player (FPP) / Raspberry Pi UPS under FPP
« Last post by lrhorer on Today at 03:03:26 AM »
I originally posted this query in the 2.0 Beta thread, but I fear it rather got lost in all the messages there.  In any case, I never saw a response, and I am in need of some assistance with this.  Halloween is coming up fast.
I have a UPS attached which requires the use of two GPIO pins and the I2C bus.  I will work on the I2C bus daemon after I get the GPIO working.
I tried setting the GPIO pins using a simple System V script.  The script itself works, but something in the FPP init apparently resets the pins.  GPIO 19 gets asserted during boot, but after a few seconds the pin gets reset.  This pin attaches the battery to the UPS so the system will remain up during a power failure.  So much for the UPS functionality.  As a data point, when I restart FPPD manually from within the GUI, the pin remains asserted.  I am not all that familiar with SystemD, but I did my best to create a SystemD script instead of a SystemV script.  The questions are:


1.  Is a boot script the best way to handle this, or is there functionality within FPP that handles it better?  I know FPP can manage the GPIO pins, but offhand I don't see a way to enable GPIO 19 set high and GPIO 17 set as an input with a pull-up resistor.  If there is a way to handle this natively in FPP, it would be terriffic!

2.  If a boot script is the way to go, what is wrong with my script?  Details below.

Link to target:
Code: [Select]
FPP:/etc/systemd/system# ll gpioset.target
lrwxrwxrwx 1 root root 58 May 27 23:37 gpioset.target -> /etc/systemd/system/multi-user.target.wants/gpioset.target

Target script:
Code: [Select]
FPP:/etc/systemd/system# cat gpioset.target
[Unit]
Description=gpioset
After=network.target getty.target apache2.target generic-board-startup.service remote-fs.target fppd.service

[Service]
Type=oneshot
RemainAfterExit=no
ExecStart=/etc/init.d/gpioset.sh

[Install]
WantedBy=multi-user.target


Shell script:
Code: [Select]
FPP:/etc/systemd/system/multi-user.target.wants# cat /etc/init.d/gpioset.sh
#!/bin/sh

/usr/local/bin/gpio mode 24 out
/usr/local/bin/gpio write 24 1
/usr/local/bin/gpio mode 17 up


SystemD Response:
Code: [Select]
FPP:/etc/systemd/system/multi-user.target.wants# systemctl status gpioset
? gpioset.service
   Loaded: loaded (/etc/init.d/gpioset.sh; generated; vendor preset: enabled)
   Active: active (exited) since Sun 2018-05-27 23:47:08 UTC; 40min ago
     Docs: man:systemd-sysv-generator(
   CGroup: /system.slice/gpioset.service

May 27 23:47:08 FPP systemd[1]: Starting LSB: Sets GPIO pins for UPS management...
May 27 23:47:08 FPP gpioset.sh[2340]: basename: missing operand
May 27 23:47:08 FPP gpioset.sh[2340]: Try 'basename --help' for more information.
May 27 23:47:08 FPP systemd[1]: Started LSB: Sets GPIO pins for UPS management.


I don't understand the "basename" reference, at all.
Pages: [1] 2 3 ... 10
Back to top