Jump to content

Stargazers Lounge Uses Cookies

Like most websites, SGL uses cookies in order to deliver a secure, personalised service, to provide social media functions and to analyse our traffic. Continued use of SGL indicates your acceptance of our cookie policy.



New Members
  • Content Count

  • Joined

  • Last visited

Community Reputation

2 Neutral

About gilesco

  • Rank
  1. Didn't see FLO, but did see Ikarus Imaging on the list.
  2. I don't have a github account, wish there was a way to do this anonymously, I'd rather not subscribe to yet another online account, with yet another password, but all I've done from the 2.0.0 image build is the following: sudo systemctl disable dhcpcd Let me show you the issue I had with these command excerpts: #First let's look at the routing table with the default astroberry setup: root@indi:/home/astroberry# route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface U 303 0 0 wlan0 U 303 0 0 wlan0 U 600 0 0 wlan0 #For some reason the gateway has been set to #Checking the IP address for wlan0, shows it got the IP from DHCP root@indi:/home/astroberry# ifconfig wlan0 wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet netmask broadcast ... So disable the DHCPCD daemon: root@indi:/home/astroberry# systemctl disable dhcpcd Synchronizing state of dhcpcd.service with SysV service script with /lib/systemd/systemd-sysv-install. Executing: /lib/systemd/systemd-sysv-install disable dhcpcd Removed /etc/systemd/system/multi-user.target.wants/dhcpcd.service. Removed /etc/systemd/system/dhcpcd5.service. It is still running (but won't be after a reboot), note the highlighted debug in the status: root@indi:/home/astroberry# systemctl status dhcpcd * dhcpcd.service - dhcpcd on all interfaces Loaded: loaded (/lib/systemd/system/dhcpcd.service; disabled; vendor preset: enabled) Active: active (running) since Sat 2020-01-18 15:49:01 GMT; 1min 47s ago Main PID: 419 (dhcpcd) Tasks: 1 (limit: 4915) Memory: 2.3M CGroup: /system.slice/dhcpcd.service `-419 /sbin/dhcpcd -q -b Jan 18 15:49:11 indi dhcpcd[419]: wlan0: soliciting an IPv6 router Jan 18 15:49:12 indi dhcpcd[419]: wlan0: soliciting a DHCP lease Jan 18 15:49:12 indi dhcpcd[419]: wlan0: offered from Jan 18 15:49:12 indi dhcpcd[419]: wlan0: ignoring offer of from Jan 18 15:49:17 indi dhcpcd[419]: wlan0: probing for an IPv4LL address Jan 18 15:49:23 indi dhcpcd[419]: wlan0: using IPv4LL address Jan 18 15:49:23 indi dhcpcd[419]: wlan0: adding route to Jan 18 15:49:23 indi dhcpcd[419]: wlan0: adding default route Jan 18 15:49:23 indi dhcpcd[419]: wlan0: pid 419 deleted default route Jan 18 15:49:25 indi dhcpcd[419]: wlan0: no IPv6 Routers available So, let's stop dhcpcd: root@indi:/home/astroberry# systemctl stop dhcpcd Now restart network manager: root@indi:/home/astroberry# systemctl restart NetworkManager root@indi:/home/astroberry# route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface UG 600 0 0 wlan0 U 600 0 0 wlan0 I get the correct gateway from DHCP which is managed by NetworkManager.
  3. My problem is resolved, I disabled the dhcpcd daemon, and leave Network Manager to spawn it's own instance of dhcpcd. Giles (CCNP, CCNA Security, CCNA, CCENT)
  4. I know it is a different Linux distro, and not Raspbian, but this link explains the problem better than I can with respect to Network Manager and dhcpcd: https://bbs.archlinux.org/viewtopic.php?id=170813 Astroberry is running both dhcpcd as a service in addition to Network Manager (which spawns its own dhcpcd when you decide to set up a connection as "Automatic") This causes a conflict, you may not notice it because you are on a single subnet network, whereas I have multiple subnets on my network and need the default gateway to operate.
  5. I've just loaded the image onto a Raspberry Pi4, things by and large seem to work, but I used NetworkManager to connect to my own Wireless Network. Something interesting is that while I obtained an IP address from my DHCP server, my default gateway was set to and not the IP address of the gateway (which the DHCP server serves to the clients on this subnet), so network connectivity seemed pretty patchy - I could connect to resources on same subnet from Astroberry, and remote systems on remote subnets can initiate connections to the Astroberry, but the Astroberry itself couldn't connect to the Internet, or other subnets on my network. Turns out that in addition to NetworkManager, dhcpcd is also running as a standalone daemon. So I disabled that (sudo systemctl disable dhcpcd), I still get my IP address via DHCP (through Network Manager), but now the gateway is stable and correct in the configuration (confirmed with route -n). So my advice is if you don't want to use the VAP, remove all that config, and either use the legacy /etc/network/interfaces config and disable NetworkManager, or disable dhcpcd and just use NetworkManager.
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.