Author Topic: Why default route on WiFi?  (Read 594 times)

Offline k6ccc

  • Sr. Member
  • ****
  • Join Date: Mar 2015
  • Location: Glendora, Calif, U.S.A. (near Los Angeles)
  • Posts: 339
  • Kudos: 3
    • Newburgh Lights
Why default route on WiFi?
« on: August 06, 2018, 01:50:29 PM »
Let me describe my network.  eth0 is connected to my wired E1.31 LAN, eth1 is connected to a ColorLight card, and wlan0 connects to one of my WiFi networks.  All three are DHCP because there have been some issues when using static IPs.  Of course eth1 can't find a DHCP server, but it does not matter since it only connects to the ColorLight.  eth0 and wlan0 both properly get DHCP assigned addresses and work fine.  Both eth0 and wlan0 should be getting a gateway as part of the DHCP assignment.  However, the Pi 3B ALWAYS uses the WiFi connection for the default route.  I would prefer it to route via the wired LAN, and I can't find any way to set which interface to use as the default route.  I'm sure there is a way by getting into the Linux and manually setting it, but I'm wondering if there is a setting for default routing in FPP?  Note, this is NOT critical (or even very important - just a preference).
Excerpt from the Troubleshooting page:
Code: [Select]
Kernel IP routing table
 Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
 0.0.0.0         192.168.203.250 0.0.0.0         UG        0 0          0 wlan0
 4.2.2.3         192.168.203.250 255.255.255.255 UGH       0 0          0 wlan0
 8.8.4.4         192.168.203.250 255.255.255.255 UGH       0 0          0 wlan0
 8.8.8.8         192.168.203.250 255.255.255.255 UGH       0 0          0 wlan0
 8.8.8.8         192.168.131.250 255.255.255.255 UGH       0 0          0 eth0
 169.254.0.0     0.0.0.0         255.255.0.0     U         0 0          0 eth1
 192.168.131.0   0.0.0.0         255.255.255.0   U         0 0          0 eth0
 192.168.131.250 0.0.0.0         255.255.255.255 UH        0 0          0 eth0
 192.168.203.0   0.0.0.0         255.255.255.0   U         0 0          0 wlan0
 192.168.203.250 0.0.0.0         255.255.255.255 UH        0 0          0 wlan0

BTW, both networks route through the same router (on different interfaces of course), so it's VERY easy to compare DHCP network settings to make sure they are the same (other than different subnet addresses of course).
Using LOR (mostly SuperStar) for all sequencing - using FPP only to drive P5 and P10 panels.
Jim

Offline nmiller0113

  • Hero Member
  • *****
  • Join Date: Aug 2015
  • Location: Santa Rosa, CA
  • Posts: 672
  • Kudos: 8
    • The Miller Lights
Re: Why default route on WiFi?
« Reply #1 on: August 06, 2018, 03:28:05 PM »
It's not an FPP issue.  You have two default routes...you can't do that and get expected results as there is no way to weigh one higher than the other.  The routing table is very basic.  Your only option is to configure one interface as static.  Honestly, you should never have a problem with static vs. DHCP, and if you are, there are other problems that need to be looked more deeply into.

Offline k6ccc

  • Sr. Member
  • ****
  • Join Date: Mar 2015
  • Location: Glendora, Calif, U.S.A. (near Los Angeles)
  • Posts: 339
  • Kudos: 3
    • Newburgh Lights
Re: Why default route on WiFi?
« Reply #2 on: August 06, 2018, 03:43:28 PM »
I'm enough of a networking guy to understand a routing table.  The question is how to tell FPP to use eth0 as opposed to wlan0 for the 0.0.0.0 route.  Either would work, but it is always choosing the WiFi over the wired LAN.  I would prefer the opposite.

As for the problem with static, that IS an FPP problem.  If I set a static for eth1, then BOTH eth0 AND eth1 are assigned that address.  This was documented months ago.  Even if I set a static address for eth0 and eth1, then again, both wired connections take the address that is entered for eth1.  As I recall, a similar issue occurred with wlan0, but honestly it's been long enough that I don't remember for sure.  The only workaround was to just let everything run DHCP.  The router has DHCP reservations for both FPP installations, so they get assigned the desired addresses.


Offline pixelpuppy

  • Hero Member
  • *****
  • Join Date: Aug 2015
  • Location: Dallas, TX
  • Posts: 991
  • Kudos: 32
Re: Why default route on WiFi?
« Reply #3 on: August 06, 2018, 03:59:47 PM »
..you can't do that and get expected results as there is no way to weigh one higher than the other. 
Actually you can weigh one higher than the other.  That is what the "metric" value is for.  When there are two similarly equal routes, the one with the lowest metric is the one that gets used.   However, the default metric is 0 (the lowest) so to give one priority over the other, you have to raise the metric value on the one you don't want (higher metric = lower priority).  Unfortunately there (currently) is no option to set that directly within the FPP user interface.  You need to do it in the Linux command line.


Quote
Honestly, you should never have a problem with static vs. DHCP, and if you are, there are other problems that need to be looked more deeply into.
I agree, this should not be a concern.  Some of the early builds of FPP 2.x had problems with static/dynamic IPs coexisting but those problems have been fixed for a while now.  Need to run new SD image build, not just FPP updates through the FPP gui
« Last Edit: August 06, 2018, 04:16:25 PM by pixelpuppy »
xLights and Vixen3 for sequencing / FPP for scheduling and playing / Falcon controllers for pixels / homemade controllers for everything else

Offline pixelpuppy

  • Hero Member
  • *****
  • Join Date: Aug 2015
  • Location: Dallas, TX
  • Posts: 991
  • Kudos: 32
Re: Why default route on WiFi?
« Reply #4 on: August 06, 2018, 04:06:51 PM »
I'm enough of a networking guy to understand a routing table.  The question is how to tell FPP to use eth0 as opposed to wlan0 for the 0.0.0.0 route.  Either would work, but it is always choosing the WiFi over the wired LAN.  I would prefer the opposite.

Assuming you know how to get to the command line, try this:

#add the new preferred route
sudo ip route add    default via 192.168.131.250 dev eth0  metric 0

#delete the old unwanted route
sudo ip route delete default via 192.168.203.250 dev wlan0 metric 0

#optional add backup default route with higher metric if desired
sudo ip route add    default via 192.168.203.250 dev wlan0 metric 1

Quote
As I recall, a similar issue occurred with wlan0, but honestly it's been long enough that I don't remember for sure.  The only workaround was to just let everything run DHCP.  The router has DHCP reservations for both FPP installations, so they get assigned the desired addresses.
I thought that was fixed in the current SD image build (20180709).  Are you certain that you're using that image build?  It contains kernel updates that you wont have if you used an earlier build and just did the FPP manual updates through the web interface
« Last Edit: August 06, 2018, 04:21:23 PM by pixelpuppy »

Offline MyKroFt

  • Administrator
  • *****
  • Join Date: Mar 2013
  • Location: NC Montana
  • Posts: 1,409
  • Kudos: 57
Re: Why default route on WiFi?
« Reply #5 on: August 06, 2018, 04:11:36 PM »
Another reason Wifi is taking presidence over eth0 is because its routing was setup last.  Metric the same, the last route always get priority.



It was initially designed to only have one route back when Dave and I started this project.  Most people will static their eth0, and DHCP the wlan0, hence the Wlan0 gets a gateway.  Another reason for this is to keep show data off your home network.  Most ppl will use a 2nd switch for eth/show data and talk/control master/slave the FPPs via wireless


Tony


Offline MyKroFt

  • Administrator
  • *****
  • Join Date: Mar 2013
  • Location: NC Montana
  • Posts: 1,409
  • Kudos: 57
Re: Why default route on WiFi?
« Reply #6 on: August 06, 2018, 04:14:15 PM »
As for the problem with static, that IS an FPP problem.  If I set a static for eth1, then BOTH eth0 AND eth1 are assigned that address.


It is, its a GUI design problem that has not be corrected yet.  GUI was only ever designed for eth0 and wlan0.  You can manually modify the eth1 config file on the usb stick with custom modification with will stick thru a reboot


Tony


Offline k6ccc

  • Sr. Member
  • ****
  • Join Date: Mar 2015
  • Location: Glendora, Calif, U.S.A. (near Los Angeles)
  • Posts: 339
  • Kudos: 3
    • Newburgh Lights
Re: Why default route on WiFi?
« Reply #7 on: August 06, 2018, 04:29:32 PM »

Assuming you know how to get to the command line, try this:

#add the new preferred route
sudo ip route add    default via 192.168.131.250 dev eth0  metric 0

#delete the old unwanted route
sudo ip route delete default via 192.168.203.250 dev wlan0 metric 0

#optional add backup default route with higher metric if desired
sudo ip route add    default via 192.168.203.250 dev wlan0 metric 1

Quote
As I recall, a similar issue occurred with wlan0, but honestly it's been long enough that I don't remember for sure.  The only workaround was to just let everything run DHCP.  The router has DHCP reservations for both FPP installations, so they get assigned the desired addresses.
I thought that was fixed in the current SD image build (20180709).  Are you certain that you're using that image build?  It contains kernel updates that you wont have if you used an earlier build and just did the FPP manual updates through the web interface
Yes, I can follow specific instructions to edit the route table in Linux.  My last expertise in Unix was with Solaris about 30 years ago - and A LOT has changed since then (including my gray matter).  Everything I do these days is Windows based...

I was hoping there was a setting in FPP that I was missing.
I know for fact that I am running the March image.  I have been doing the updates, but had not re-burned the image.  I had not caught that the IP issue was fixed in the new image.  No Dodger game tonight, so I will plan on that tonight.

Offline k6ccc

  • Sr. Member
  • ****
  • Join Date: Mar 2015
  • Location: Glendora, Calif, U.S.A. (near Los Angeles)
  • Posts: 339
  • Kudos: 3
    • Newburgh Lights
Re: Why default route on WiFi?
« Reply #8 on: August 06, 2018, 11:03:03 PM »
Updated to the new image and then updated to the latest version.
Version: v2.x-master-647-g041f60d3 (master branch)  Host: FPP-1 (192.168.1.81 192.168.1.81 192.168.203.81)

Have the same problem as before with static IPs however.  In the line above, eth0 is DHCP and should be getting 192.168.131.81.  DHCP server shows that it has not requested an address after I rebooted the Pi.  eth1 is set Static of 192.168.1.81 and you can see that the static address has been applied to both eth0 and eth1.

Note that after setting eth1 to static, even after multiple Update Interface and Restart Network commands were issued and completed, eth1 did not take the static IP until I did a reboot.  Same thing when I changed eth1 back to DHCP.  Did the reboot with all three interfaces set to DHCP and:
Version: v2.x-master-647-g041f60d3 (master branch)  Host: FPP-1 (192.168.131.81 169.254.209.233 192.168.203.81)
All correct.  Other than the 169.254.209.233 on eth1 annoys me...

Offline dkulp

  • Moderator
  • *****
  • Join Date: Sep 2013
  • Location: Framingham, MA
  • Posts: 965
  • Kudos: 47
Re: Why default route on WiFi?
« Reply #9 on: August 07, 2018, 07:56:04 AM »



I think I have this fixed....   although it will cause the boot to take slightly longer.


When setting up connman, we need the MAC address of the network adapter to assign the specific config to that adapter.  However, the USB interfaces tend to take a while to appear.   It will now wait up to 10 seconds to see if the adapter will appear so that we can grab the MAC address.

Dan Kulp

Offline k6ccc

  • Sr. Member
  • ****
  • Join Date: Mar 2015
  • Location: Glendora, Calif, U.S.A. (near Los Angeles)
  • Posts: 339
  • Kudos: 3
    • Newburgh Lights
Re: Why default route on WiFi?
« Reply #10 on: August 07, 2018, 08:40:44 AM »
Oops.  Posted before I intended...
I think I have this fixed....   although it will cause the boot to take slightly longer.

When setting up connman, we need the MAC address of the network adapter to assign the specific config to that adapter.  However, the USB interfaces tend to take a while to appear.   It will now wait up to 10 seconds to see if the adapter will appear so that we can grab the MAC address.

Nope.
Updated to 648 and as expected, eth0 and wlan0 had the correct DHCP addresses and eth1 had a 169. address (sorry, did not capture that status line.  Then changed eth1 to static ip and everything looked great...
Version: v2.x-master-648-ge2c8edcb (master branch)  Host: FPP-1 (192.168.131.81 192.168.1.81 192.168.203.81)

Until I rebooted.  After the re-boot, eth1 went back to the 169. address and wlan0 would not connect to the WiFi.
Version: v2.x-master-648-ge2c8edcb (master branch)  Host: FPP-1 (192.168.131.81 169.254.247.53)

Went into Network and did an Update Interface and Restart Network and wlan0 immediately connected to my WiFI, and got it's DHCP address:
Version: v2.x-master-648-ge2c8edcb (master branch)  Host: FPP-1 (192.168.131.81 169.254.247.53 192.168.203.81)

Confirmed that eth0 and wlan0 are set to DHCP and eth1 is set to a static address of 192.168.1.81, and re-booted.  Took 30 seconds before pings to the DHCP address for eth0 started responding.When I first connected to the GUI, only eth0 had an IP.  About 30 seconds later, eth1 showed the 169. address:
Version: v2.x-master-648-ge2c8edcb (master branch)  Host: FPP-1 (192.168.131.81 169.254.178.51)

Again, wlan0 did not connect to the WiFi until I did an Update Interface and Restart Network:
Version: v2.x-master-648-ge2c8edcb (master branch)  Host: FPP-1 (192.168.131.81 169.254.178.51 192.168.203.81)
« Last Edit: August 07, 2018, 09:11:58 AM by k6ccc »

Offline pixelpuppy

  • Hero Member
  • *****
  • Join Date: Aug 2015
  • Location: Dallas, TX
  • Posts: 991
  • Kudos: 32
Re: Why default route on WiFi?
« Reply #11 on: August 07, 2018, 09:39:57 AM »
Updated to the new image and then updated to the latest version.
Version: v2.x-master-647-g041f60d3 (master branch)  Host: FPP-1 (192.168.1.81 192.168.1.81 192.168.203.81)

Just so we're not 2nd-guessing here... Exactly WHICH new image did you use? (there's a few "new" images floating around)  And what does it show for your OS Version and Kernel Version? (under FPP->Help->About)   You've probably got the right one, but it helps to verify and confirm because its possible to update to FPP Version v2.x-master-648 without having the updated Kernel.

FPP Version:   v2.x-master-648-ge2c8edcb
FPP OS Build:   v2.0alpha
OS Version:   Raspbian GNU/Linux 9 (stretch)
Kernel Version:   4.14.52-v7+

Offline dkulp

  • Moderator
  • *****
  • Join Date: Sep 2013
  • Location: Framingham, MA
  • Posts: 965
  • Kudos: 47
Re: Why default route on WiFi?
« Reply #12 on: August 07, 2018, 09:47:23 AM »



Gahh...   I'm surprised booting has ever worked.  :(


I just discovered that the fppinit service (that configs everything we need) runs BEFORE the root filesystem is mounted read/write, before /tmp is cleaned, etc...   Now that we are waiting for interfaces to come up, those are occurring and the temp files we are creating in /tmp are being wiped out.


I just pushed a fairly large update which includes a config upgrade.  This moves the fppinit service to after a bunch of things that it should depend on.   That should solve much of that.  It also installs cpufrequtils and forces the governor into performance mode.   I'm hoping that will help with some of the "real timish" type issues, panel strobing, etc...   I know it helps USB performance on the BBB and had already done it there. 

Offline k6ccc

  • Sr. Member
  • ****
  • Join Date: Mar 2015
  • Location: Glendora, Calif, U.S.A. (near Los Angeles)
  • Posts: 339
  • Kudos: 3
    • Newburgh Lights
Re: Why default route on WiFi?
« Reply #13 on: August 07, 2018, 09:51:01 AM »
Just so we're not 2nd-guessing here... Exactly WHICH new image did you use? (there's a few "new" images floating around)  And what does it show for your OS Version and Kernel Version? (under FPP->Help->About)   You've probably got the right one, but it helps to verify and confirm because its possible to update to FPP Version v2.x-master-648 without having the updated Kernel.

FPP Version:   v2.x-master-648-ge2c8edcb
FPP OS Build:   v2.0alpha
OS Version:   Raspbian GNU/Linux 9 (stretch)
Kernel Version:   4.14.52-v7+
I knew there was a reason I left my remote session with the home computer up (I'm doing all this from 26 miles away from home)...It was 20180709.  I fully understand the reason for the question.

Version Info
FPP Version:v2.x-master-648-ge2c8edcb
FPP OS Build:v2.0alpha
OS Version:Raspbian GNU/Linux 9 (stretch)
Kernel Version:4.14.52-v7+
Git Branch:master
Local Git Version: e2c8edc (Update is available) ChangeLog               
Remote Git Version: 37ba71f Preview Changes

Offline nmiller0113

  • Hero Member
  • *****
  • Join Date: Aug 2015
  • Location: Santa Rosa, CA
  • Posts: 672
  • Kudos: 8
    • The Miller Lights
Re: Why default route on WiFi?
« Reply #14 on: August 07, 2018, 10:02:52 AM »
..you can't do that and get expected results as there is no way to weigh one higher than the other. 
Actually you can weigh one higher than the other.  That is what the "metric" value is for.  When there are two similarly equal routes, the one with the lowest metric is the one that gets used.   However, the default metric is 0 (the lowest) so to give one priority over the other, you have to raise the metric value on the one you don't want (higher metric = lower priority).  Unfortunately there (currently) is no option to set that directly within the FPP user interface.  You need to do it in the Linux command line.


Sorry, I should have been more clear, was on my phone and traveling all day.  You're 100% correct, it IS entirely possible.  What I was trying to convey was the fact that there is no way to do it from FPP.  I was merely trying to provide a simplified way to correct the behavior they were experiencing.  It's not a good practice in general to have two default routes in a single routing instance, and nothing guarantees that even if they are persistent that they won't get overwritten in an upgrade.  In my opinion the best path was to do it in FPP with only a single gateway via a static configuration.  Sorry if I caused any confusion through my simplification :)

 

Back to top