ETH0 is staying the WLAN0 is where the issue is one note I found a issue with the password I use for wireless It contained an & sign and this was causing it to blank the inputs. what I did was did the ip address then update network that stuck then tired the SSID and PSK that still blanked. Tired a plain word as password and that stayed. Change PSK on router and still no luck.

ETH0 is staying the WLAN0 is where the issue is one note I found a issue with the password I use for wireless It contained an & sign and this was causing it to blank the inputs. what I did was did the ip address then update network that stuck then tired the SSID and PSK that still blanked. Tired a plain word as password and that stayed. Change PSK on router and still no luck.

What are the contents of /home/fpp/media/config/interface.wlan0 and /home/fpp/media/config/interface.eth0? The /etc/network/interfaces file is generated at each boot time based on the contents of these two files.

Thank you very much for providing this guide. It is very organized and concise and is a great help.

Nonetheless, I am having difficulties. Hopefully someone can steer me in the right direction. I am trying to implement Option 1. I am starting with a very simplified network consisting of an Asus RT-AC68U router, a Raspberry Pi with a WiFi Adapter, and a Pixlite Controller.

I cannot access the Pixlite controller from the network. Hopefully someone can show me what I am doing wrong.

Here is my simplified network diagram:I have set the Pixlite to a static IP address of 192.168.101.50 with a subnetmask of 255.255.255.0. It's ethernet port is physically connected to the ethernet port on the Pi.

I can access the Pi on wlan0 just fine. My wlan0 configuration via the FPP interface is as follows:

Remove the gateway on the FPP's eth0 and then also make sure the Pixlite has a gateway configured of 192.168.101.1.

I removed the gateway from the FPP's eth0. There is no option in the PixLite's interface to specify a gateway. The Pixlite does not have a web interface. Access to the controller settings is via their Advatek Assistant. I cannot access the PixLite via their Advatek Assistant. I can however, ping it and get a reply. I don't quite understand how I can get a reply if I cannot assign a gateway.

Because a "reply' knows where the original request came from. Gateway is needed when a device inititiates the conversation.

A reply only knows the original source of the packet not the route the packet needs to take. Replies need a route just like any other packet. It is very common for the route to a host be different than a route from a host and for the route to even change between packets. Everybody only knows the next hop in the route not the full route.

In this case because the Pixlite is directly connected to the FPP, the FPP will see any packet put on the wire by the Pixlite and it will know what to do with the packet. This is very similar behavior to ProxyARP where the FPP advertises itself as the destination for anybody asking for a destination next hop via ARP. If there was a switch in-between the Pixlite and the FPP you would need to specifically turn on ProxyARP in the FPP to get the same behavior (echo 1 > /proc/sys/net/ipv4/conf/eth0/proxy_arp) since the switch would filter the traffic the FPP would see.

These statements were incorrect. See PixelPuppy's comments in the next couple of messages.

Because a "reply' knows where the original request came from. Gateway is needed when a device inititiates the conversation.

A reply only knows the original source of the packet not the route the packet needs to take. Replies need a route just like any other packet. It is very common for the route to a host be different than a route from a host and for the route to even change between packets. Everybody only knows the next hop in the route not the full route.

In this case because the Pixlite is directly connected to the FPP, the FPP will see any packet put on the wire by the Pixlite and it will know what to do with the packet. This is very similar behavior to ProxyARP where the FPP advertises itself as the destination for anybody asking for a destination next hop via ARP. If there was a switch in-between the Pixlite and the FPP you would need to specifically turn on ProxyARP in the FPP to get the same behavior (echo 1 > /proc/sys/net/ipv4/conf/eth0/proxy_arp) since the switch would filter the traffic the FPP would see.

Good to know because, I may well want to control more than one PixeLite from the same Pi and have to introduce a switch.