Author Topic: Beta SD image for FPP running on Raspbian Stretch  (Read 7311 times)

Offline JonB256

  • Supporting Member
  • ******
  • Join Date: Mar 2013
  • Location: Granbury, Texas
  • Posts: 4,175
  • Kudos: 86
    • Granbury Christmas Lights
Re: Beta SD image for FPP running on Raspbian Stretch
« Reply #315 on: April 09, 2018, 08:35:58 AM »
New Tethering attempt, using a RasPi 3B+ (got it on Sunday - couldn't resist)
My primary reason is the Gigabit output, used to drive a Colorlight board.

So, with a Gigabit output, I was able to direct connect (no switch) to my Colorlight controlled panel. Verified it worked with direct connect.
You can set Eth0 to just about anything since IP address means little to the Colorlight board.

So with Wireless enabled and then Checked the "Tethering" box, I rebooted.
Now my phone connects to the RasPi 3B+
I can start my playlist manually or have it run scheduled playlists.

This will very convenient for Remote installs of P10/P5/P-etc panels.

What didn't seem to work was changing the SSID from FPP to something else. I'll try again later.

Will also try Audio (with and without an SB3). Updates pending

Offline brichi

  • Sr. Member
  • ****
  • Join Date: Dec 2017
  • Location:
  • Posts: 331
  • Kudos: 0
Re: Beta SD image for FPP running on Raspbian Stretch
« Reply #316 on: April 09, 2018, 08:51:19 AM »
New Tethering attempt, using a RasPi 3B+ (got it on Sunday - couldn't resist)
My primary reason is the Gigabit output, used to drive a Colorlight board.

So, with a Gigabit output, I was able to direct connect (no switch) to my Colorlight controlled panel. Verified it worked with direct connect.
You can set Eth0 to just about anything since IP address means little to the Colorlight board.

So with Wireless enabled and then Checked the "Tethering" box, I rebooted.
Now my phone connects to the RasPi 3B+
I can start my playlist manually or have it run scheduled playlists.

This will very convenient for Remote installs of P10/P5/P-etc panels.

What didn't seem to work was changing the SSID from FPP to something else. I'll try again later.

Will also try Audio (with and without an SB3). Updates pending


so youre running a schedule that is sending the data wireless to trigger the Pi? then the port on the Pi is to your CL card? thats interesting for an area i want to put my matrix, the Pi i have right now couldnt do it but i would get a B+if that worked well from xschedule

Offline JonB256

  • Supporting Member
  • ******
  • Join Date: Mar 2013
  • Location: Granbury, Texas
  • Posts: 4,175
  • Kudos: 86
    • Granbury Christmas Lights
Re: Beta SD image for FPP running on Raspbian Stretch
« Reply #317 on: April 09, 2018, 09:05:36 AM »

so youre running a schedule that is sending the data wireless to trigger the Pi? then the port on the Pi is to your CL card? thats interesting for an area i want to put my matrix, the Pi i have right now couldnt do it but i would get a B+if that worked well from xschedule

Not that complicated. The FSEQ files and schedule are all on that single RasPi3B+. No triggering at all.
It is running as "standalone" but has its own SSID for my smartphone to connect to. (FPP / Christmas)
Inside the P10 box is just the Pi, the CL board and matrix panels. Very self-contained and simpler, since I didn't need to add a gigabit switch.

disclosure - I've never run xschedule. Probably never will. The few times I've used xLights output was just for testing.

Offline brichi

  • Sr. Member
  • ****
  • Join Date: Dec 2017
  • Location:
  • Posts: 331
  • Kudos: 0
Re: Beta SD image for FPP running on Raspbian Stretch
« Reply #318 on: April 09, 2018, 09:09:08 AM »

so youre running a schedule that is sending the data wireless to trigger the Pi? then the port on the Pi is to your CL card? thats interesting for an area i want to put my matrix, the Pi i have right now couldnt do it but i would get a B+if that worked well from xschedule

Not that complicated. The FSEQ files and schedule are all on that single RasPi3B+. No triggering at all.
It is running as "standalone" but has its own SSID for my smartphone to connect to. (FPP / Christmas)
Inside the P10 box is just the Pi, the CL board and matrix panels. Very self-contained and simpler, since I didn't need to add a gigabit switch.

disclosure - I've never run xschedule. Probably never will. The few times I've used xLights output was just for testing.


ok good to know, thanks. I have to use xschedule for the way I want my show to run so I have Xschedule trigger the FSEQ files as I go from sequence to sequence

Offline k6ccc

  • Full Member
  • ***
  • Join Date: Mar 2015
  • Location: Glendora, Calif, U.S.A. (near Los Angeles)
  • Posts: 204
  • Kudos: 0
    • Newburgh Lights
Re: Beta SD image for FPP running on Raspbian Stretch
« Reply #319 on: April 09, 2018, 06:22:48 PM »
With tethering on, it creates an "access point" that someone could then use an iPad or computer or something to connect to it to configure things.   Not really a "normal" thing, but there are cases (particularly with BBB+WIFI or Pi3) where you could be using the ethernet to run the show, but have the Wifi setup as a tether so you can login and reconfigure thing.     

Version: v2.x-master-572-g42ca6eac (master branch)  Host: FPP-1 (192.168.131.81 192.168.31.81 192.168.203.81)
Not that I expect any particular use of this function, but I figured I would give it a try on the Pi 3B.  Had some interesting (negative) results.  The three IPs shows are eth0 on my E1.31 network (static), eth1 direct to the ColorLight card (static), and one of my WiFi networks (DHCP).  I set up continuous pings to the eth0 and WiFi addresses.  I then connected to the Pi via the wired eth0 LAN.  As soon as I checked the box for tethering, both eth0 and wlan0 pings immediately started failing and did not come back by themselves.  Next I took out my $%^&* iPhone and sure enough, there was a FPP SSID showing, and the default "Christmas" password worked.  That led to my next question of "what IP was it using?".  So I tried the same 192.168.203.81, and that worked.  Not wanting to completely lose connectivity, I unchecked the tethering box, and the normal 192.168.203.81 from the house WiFi started responding to pings, and of course I lost connectivity via FPP SSID.  I did a "Update interface" and "restart network" on eth0, and the pings started working on the 192.168.131.81 address.  I saw that it wanted a reboot, which I did.

Second try.  Pretty much the same procedure for the second try except that the FPP SSID came up with a 192.168.0.1 address (which took a while to figure out on my $%^&* iPhone).

Third try.  Started off like #2, but did the requested re-boot from my phone.  After the re-boot, the Pi still had the 192.168.0.1 IP on the FPP SSID and I could connect from the phone.  Both addresses on eth0 and the normal address for wlan0 were dead - of course the normal wlan0 address was expected to be dead.  Went to the network page and did a "Update interface" and "restart network" on eth0, and the pings started working on the 192.168.131.81 address.  Connected from the PC on the eth0 address.
Version: v2.x-master-572-g42ca6eac (master branch)  Host: FPP-1 (192.168.131.81 192.168.31.81 192.168.0.1)
Sent E1.31 traffic to the eth0 address and the P10 panels lit up correctly.
Last was to turn off tethering and after a few seconds, the wlan0 interface connected to the WiFi network that it should have, and the phone lost connectivity (as expected).

Fourth try.  Interesting, this time, wlan0 address continued to work after enabling tethering.  Performed the requested reboot.  wlan0 not responding to pings.  Update and restart on eth0 and it came back up.  E1.31 traffic from LOR correctly lit up the P10 panel.
Wanted to see what it would do after a shutdown and power cycle.  Performed the shutdown from the PC, and then powered off the power supply.  Waited a couple minutes and powered the 5V power supply back up.  The FPP SSID came back up, but I had to update and restart wlan0 to get that one back up.  After that sent E1.31 traffic to the Pi and it lit the panels.  Turned off tethering and the requested reboot.  eth0 did not come back up.  Looked at the status page and got this surprise:
Version: v2.x-master-572-g42ca6eac (master branch)  Host: FPP-1 (192.168.31.81 192.168.31.81 192.168.203.81)
Note that eth0 and eth1 both have addresses of 192.168.31.81 (what eth1 is supposed to have).  So went to the troubleshooting page and it agreed:
Code: [Select]
eth0: flags=-28605  mtu 1500
 inet 192.168.31.81  netmask 255.255.255.0  broadcast 192.168.31.255
 inet6 fe80::ba27:ebff:feb2:3f80  prefixlen 64  scopeid 0x20
 ether b8:27:eb:b2:3f:80  txqueuelen 1000  (Ethernet)
 RX packets 150  bytes 52011 (50.7 KiB)
 RX errors 0  dropped 0  overruns 0  frame 0
 TX packets 100  bytes 18242 (17.8 KiB)
 TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0 eth1: flags=-28605

eth1: flags=-28605  mtu 1500
 inet 192.168.31.81  netmask 255.255.255.0  broadcast 192.168.31.255
 inet6 fe80::daeb:97ff:feb9:34e6  prefixlen 64  scopeid 0x20
 ether d8:eb:97:b9:34:e6  txqueuelen 1000  (Ethernet)
 RX packets 0  bytes 0 (0.0 B)
 RX errors 0  dropped 0  overruns 0  frame 0
 TX packets 171848  bytes 69344404 (66.1 MiB)
 TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
Updated and restarted wlan0 interface and all is well again.  Although I had not looked, I'm suspecting that the same address issue occurred every other time where I had to update and restart eth0 to get the correct IP.

Fifth try.  This one was only to confirm or deny that the Pi was reporting 192.168.31.81 on eth0 after enabling tethering.  Again as soon as I enabled tethering, the proper address for eth0 failed, but when connected via the FPP SID, the Pi status line showed the proper 192.168.131.81 address, but requested a reboot.  After the reboot, sure enough both eth0 and eth1 showed 192.168.31.81.  After update and restart of wlan0, it correctly changed to 192.168.131.81 and pings, the GUI, and E1.31 traffic worked.

Sixth experiment.  This was to see what would happen with the eth0 address after a reboot (no tethering involved).  eth0 came up with the address that eth1 should have had.  See screen capture...

That's enough of a novel for now...

Jim

Offline JonB256

  • Supporting Member
  • ******
  • Join Date: Mar 2013
  • Location: Granbury, Texas
  • Posts: 4,175
  • Kudos: 86
    • Granbury Christmas Lights
Re: Beta SD image for FPP running on Raspbian Stretch
« Reply #320 on: April 09, 2018, 07:30:27 PM »
In my testing, I never checked to see what IP address got assigned to eth0. I don't have an eth1 to worry about.
When I check "Tethering" and reboot, I consistently get a 192.168.0.1 address for wlan0. It gives my phone (Galaxy S8+) an address of 192.168.0.2.
While the 192.168.0.1 address is the same as my Wireless Router, they aren't talking to each other so I wasn't concerned.

I'm guessing it assigned itself 192.168.0.1 because, before Tethering, it had a fixed IP of 192.168.0.90 and Gateway of 192.168.0.1.
Perhaps I'll try other values.

For my current plans, I won't be using the eth0 connection for anything other than driving the ColorLight board. It ran a playlist today for 14 hours without any problems.

Did you try setting any SSID values other than FPP?

update - previously, my change to SSID and password value for Tethering were ignored.
I manually edited the "config" file to a more unique SSID and new password. They are being used.
This would let me have multiple Tethered FPP instances in some future setup. (no plans for that at the moment, but who know)
« Last Edit: April 09, 2018, 07:46:50 PM by JonB256 »

Offline k6ccc

  • Full Member
  • ***
  • Join Date: Mar 2015
  • Location: Glendora, Calif, U.S.A. (near Los Angeles)
  • Posts: 204
  • Kudos: 0
    • Newburgh Lights
Re: Beta SD image for FPP running on Raspbian Stretch
« Reply #321 on: April 09, 2018, 07:59:31 PM »
When I check "Tethering" and reboot, I consistently get a 192.168.0.1 address for wlan0. It gives my phone (Galaxy S8+) an address of 192.168.0.2.

I am gathering that the 192.168.0.1 is coded into it...

Quote
For my current plans, I won't be using the eth0 connection for anything other than driving the ColorLight board. It ran a playlist today for 14 hours without any problems.

For me, eth0 is how it will get traffic, and eth1 is connected to the ColorLight.

Quote
Did you try setting any SSID values other than FPP?

It would not let me change it.  There is no "save" on that section, so all I could do was change the value and then enable tethering.  When I did that, it would come up with the FPP SSID.

Quote
update - previously, my change to SSID and password value for Tethering were ignored.
I manually edited the "config" file to a more unique SSID and new password. They are being used.
This would let me have multiple Tethered FPP instances in some future setup. (no plans for that at the moment, but who know)

I have not tried that.  As I said, I have no use for this feature, it was just something I could test.  I have eth0 connected to my E1.31 network, and a TrendNet gigabit adapter for eth1 to communicate with the ColorLight.  wlan0 connects to one of my WiFi networks which does give me an alternate way to communicate with the Pi if needed.  It's also how the Pi gets updates because the E1.31 network does not have internet connectivity.

Offline k6ccc

  • Full Member
  • ***
  • Join Date: Mar 2015
  • Location: Glendora, Calif, U.S.A. (near Los Angeles)
  • Posts: 204
  • Kudos: 0
    • Newburgh Lights
Re: Beta SD image for FPP running on Raspbian Stretch
« Reply #322 on: April 11, 2018, 07:12:36 AM »
A little additional testing last night with tethering.  First of all, I changed eth0 to DHCP - it has a DHCP reservation with the same 192.168.131.81 address as I had given it as a static.  Then enabled tethering.  As previously, both eth0, and wlan0 stopped responding to pings.  This time I waited about 20 minutes to see if either would self heal - nope.  Once I got back home about two hours later, I connected my phone to FPP and performed the usual restart of eth0 and it restored functionality of the normal erh0 IP address.  Turned tethering back off and all normal.  Next step was to change eth1 to DHCP.  Note that eth1 only connects to the ColorLight card so it will not find a DHCP server, nor does it have any need to get an IP address (I just dont like it self assigning a 169... address).  This time after enabling tethering, eth0 remained on its normal address and functional.
I wanted to do one more test, but I REALLY needed to get to bed.  Maybe some more testing tonight.
BTW, although I saw that there was a new version available, I did not take the time to update, so this was done with the same version as did my testing Monday.




Sent from a $&@#% iPhone using Tapatalk

Offline JonB256

  • Supporting Member
  • ******
  • Join Date: Mar 2013
  • Location: Granbury, Texas
  • Posts: 4,175
  • Kudos: 86
    • Granbury Christmas Lights
Re: Beta SD image for FPP running on Raspbian Stretch
« Reply #323 on: April 11, 2018, 10:36:40 AM »
BTW, although I saw that there was a new version available, I did not take the time to update, so this was done with the same version as did my testing Monday.

The last few updates have had nothing that would impact Tethering or network settings (per Github comments).
currently up to 573

Offline dkulp

  • Developer
  • ******
  • Join Date: Sep 2013
  • Location: Framingham, MA
  • Posts: 698
  • Kudos: 25
Re: Beta SD image for FPP running on Raspbian Stretch
« Reply #324 on: April 11, 2018, 10:51:47 AM »

The last few updates have had nothing that would impact Tethering or network settings (per Github comments).
currently up to 573


Yea... haven't had time to relook at any of the tethering things.  I'm heading on vacation tomorrow (will be mostly out-of-touch for until the 22nd) and wanted to finish up some other things first.   Primarily, I now have uploads from xLights -> FPP for the PiHat and F#-B based controllers "mostly working".   Next release of xLights should have a first pass at that.   It's not "perfect" as it will need to do some more sorting of virtual string starting channels and such, but it's a start.   It also fixes the FPP connect output universe uploads and the FPP bridge mode universe inputs upload for the FPP 2.x changes.


Keep in mind, we're more or less in "add features" mode to get the stuff we want in before the expo.    Then it will be "fix the bugs".   
Dan Kulp

Offline k6ccc

  • Full Member
  • ***
  • Join Date: Mar 2015
  • Location: Glendora, Calif, U.S.A. (near Los Angeles)
  • Posts: 204
  • Kudos: 0
    • Newburgh Lights
Re: Beta SD image for FPP running on Raspbian Stretch
« Reply #325 on: April 14, 2018, 02:46:00 PM »
Although I have been very busy and not done much testing, it would appear that almost all of my wrong IP has nothing to do with tethering, and all or mostly to do with having static IPs.  That brings me back to my early days with FPP where weird stuff was happening that was traced to using static IPs.  Letting the FPP instance run exclusively with DHCP solved the symptoms.  I have left FPP DHCP for a month or two, and after a while of looking at the 169.x.x.x address on eth1, I had set it to a static IP because the 169.x.x.x annoys me.  I did not see the problem until the next re-boot which happened to be the first time I turned on tethering, and at that time, both eth0 and eth1 were taking the static address assigned to eth1.  As a refresher, eth0 is used for my E1.31 traffic and there is a router that will function as a DHCP server on the 131 LAN - and will assign the same IP for my FPP instance as I was giving it as a static IP.  eth1 is used to communicate with my ColorLight card and does not need and IP at all, so assigning a static IP to is only kept it from having a 169.x.x.x address.

 

Back to top