setting up with wireless or fixed connection

[diveguy84]

I want to setup Networking for my Pi3 with a camera. It will be used mostly in wireless mode.
But I can get faster access from an either cable. I dont care what is used for an IP for the cable but the wireless should have a static IP.

In order to work on other problems with my network setup, which I will ask in Part 2 after Part 1 is solved.
I have made the following changes from a Raspbian install.
systemctl disable dhcpcd
systemctl stop dhcpcd
apt-get remove openresolv.

I have an:

Code: Select all

pi@camera:~ $ sudo more /etc/wpa_supplicant/wpa_supplicant.conf 
ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
update_config=1
country=US

network={
	ssid="XXXX"
	key_mgmt=NONE
	id_str="wireless-static"
}

and:

Code: Select all

pi@camera:~ $ more /etc/network/interfaces
# interfaces(5) file used by ifup(8) and ifdown(8)

# Please note that this file is written to be used with dhcpcd
# For static IP, consult /etc/dhcpcd.conf and 'man dhcpcd.conf'

# Include files from /etc/network/interfaces.d:
source-directory /etc/network/interfaces.d

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet dhcp

auto wlan0
allow-hotplug wlan0
iface wlan0 inet manual
    wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf

allow-hotplug wlan1
iface wlan1 inet manual
    wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf

iface wireless-static inet static
    address 192.168.0.2
    gateway 192.168.0.1
    broadcast 192.168.0.255
    dns-search XXX YYY
    dns-servers 127.0.1

and these last short files:

Code: Select all

pi@camera:~ $ cat /etc/hostname
camera.XXX
pi@camera:~ $ cat /etc/resolv.conf
domain XXX
search XXX
nameserver 192.168.0.1

With /etc/resolv.conf having a date that matches the last boot.

Currently the eth0 connect comes up with the router provided IP.
As can be seen the /etc/resolveconf provided dnsserver is provided by dhcp as well.

UPDATE:
When I commented out the "auto wlan0" and left the "allow-hotplug wlan0"
ifconfig shows wlan0 with a inet6 addr:
but no inet addr:

[epoch1970]

In your "wireless-static" block, you have 2 errors in the dns server specification line (wrong keyword, wrong address).
Try this instead: "dns-nameservers 127.0.0.1"

[diveguy84]

In your "wireless-static" block, you have 2 errors in the dns server specification line (wrong keyword, wrong address).
Try this instead: "dns-nameservers 127.0.0.1"

Thanks for the extra set of eyes been looking at this for far to long .
No change in results thou.
I made an additional change after the reboot since I seem to have lots of energy in the morning.
Changed the 'dns-search XXX YYY' to just XXX as my generated /etc/resolv.conf only shows XXX.

I have also tried to set VERBOSE=yes in /etc/default/networking to try and get more info.
Any help with locating/setting/changing flags to collecting more info would also help.

[epoch1970]

"dns-search XXX YYY" should be correct, you can also have "dns-domain XXX" if you want.
In my static blocks I always specify the full monty: address, network, netmask, broadcast. That's redundant, yes. I doubt it would change anything, but you could include "netmask 255.255.255.0" if you wanted.
I would absolutely leave "auto" for interfaces that are not detachable. In my experience, this hotplug thing works whenever it wants, adding "auto" is much safer. (To get events that work, I ususally write an udev rule/script myself.)

TBH, I've never played much with the automagic "mappings" in the interfaces file, and I didn't know there was a hook with wpa_supplicant.
But I wouldn't be surprised if your issue was due to another case of systemd and dhcpcd invasion.
(I removed and purged dhcpcd on my machine, that's one thing done.)

To debug what happens perhaps you can run "ifup -v wlan0" (or with --force if it's already up), this should show which scripts get executed.
To make the scripts themselves verbose... I'd just add "-x" to the shell invocation line.

[diveguy84]

TBH, I've never played much with the automagic "mappings" in the interfaces file, and I didn't know there was a hook with wpa_supplicant.
But I wouldn't be surprised if your issue was due to another case of systemd and dhcpcd invasion.
(I removed and purged dhcpcd on my machine, that's one thing done.)

To debug what happens perhaps you can run "ifup -v wlan0" (or with --force if it's already up), this should show which scripts get executed.
To make the scripts themselves verbose... I'd just add "-x" to the shell invocation line.

Well I ended up taking both pieces/hints of advice.

First I changed the "wirelless-static" to "HOME" in case the string length was an issue. No effect. Second I moved the address/netmask/gateway/broadcast clauses under the "iface wlan0" stanza. No change.
At that point I was frustrated and walked away for the day.

When I came back I was interested in collecting more debuging data. And that is were your 2nd piece of advice came. As I first stated I had set "VERBOSE=yes" in /etc/default/networking. But nothing had shown up in the /var/log/syslog that helped.
But running "ifup -v wlan0" inter-mixed with "ifconfig wlan0 down" and "ifdown wlan0" commands I picked up on the command that was having a problem, it was "ip link add ......".
A "route -n" showed:

Code: Select all

pi@camera:~ $ route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.0.1     0.0.0.0         UG    0      0        0 eth0
192.168.0.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0

i had also played with ifdown/ifup on the eth0 iface. What I found was after those commands sometimes the eth0 no longer worked and the "route -n" showed that the route for eth0 had disappeared. I knew I was on the trail at this point.
I had rerun the ifdown/ifup sequence several times and then suddenly wlan0 was working. Yay.
the output of "route -n when wlan0 was working is:

Code: Select all

pi@camera:~ $ route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.0.1     0.0.0.0         UG    0      0        0 eth0
192.168.0.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
192.168.0.0     0.0.0.0         255.255.255.0   U     0      0        0 wlan0

Then I rebooted and I was back to not working. After several "boot ifdown/ifup" tries that brought the interface up I decided to comment out the "auto wlan0" statement After the reboot.
the "route -n" output showed the default gateway and the route to eth0.
I then ran "ifup wlan0" and the wlan0 interface came up, GREAT.
The last thing I did was to add my ifup statement to /etc/rc.local and reboot. Still works.

Next things to work on:
1) Does somebody have a code snippet to add around my " ifup wlan0" in /etc/rc.local so that it only runs if the machine is in current "runlevel 5".
In cmdline I can run:

Code: Select all

echo zero `runlevel| awk '{print $2}'`
zero 5

But I can't get it into a variable to compare to "5" so this snippet works:

Code: Select all

if [ "$RL" = '5' ]; then
ifup -v eth0
ifup -v wlan0
fi

2)I have dropped openreslv by doing an "apt-get remove openreslv" to drop the nonsense of /etc/resolv.conf being rewritten all the time. It has not solved the problem so I am not even sure what bug to stomp on now.
a) I cannot get it to look the way I want.
b) I do not need its flexibility. My network will always be my local router. If I move and the router sub-net changes I can deal with the with timely edits.

Any help with these last to items would be gratefully received.

[epoch1970]

Hehe, the plot thickens...
You have 2 interfaces on the same network, linux doesn't like that very much by default. You're probably met with ARP flux (to other machines, interfaces seem to move between the wireless and the ethernet links) and if the interface with the default route goes down, that route goes away (the remaining interface has no default route anymore.)
AFAIK there are 2 ways around this: i. use a single interface, or ii. manage to get multiple default routes working. In addition one of your interfaces is wireless, client (aka STA) mode, so that's a special case.

1) Getting to a single interface:
- you could bridge (except with a wifi card in STA mode, this is forbidden, so this option is out), or
- you could use link teaming (aka bonding, trunking, aggregation). Bonding wraps 2 or more interfaces into one link, and you can choose your policy, e.g. 'active-backup' or 'round-robin'. This gives you either a more resilient link, or a fatter pipe.
I suppose active-backup could suit your use case, I have to say I've never tried bonding a wifi interface, but the Internet says it works... Last time I played with that on Debian you needed to add package "ifenslave" to get bonding capability. Module parameters (policy, default master, flip-flop delay...) are set via /etc/network/interfaces or directly from a /etc/modprobe.d/bonding.conf file. I you play with bonding, I'd advise to stick with a simple mode like RR or AB. The bond interface can keep a static MAC or have its MAC change with the active link, with wifi you'll need to pay special attention to that.

2) Getting two default routes to work:
- AFAIK (last time I practiced is a bit far) adding priorities to the interfaces will allow you to have 2 default routes up at the same time. If it works, the setup is quite simple, you have to install package "ifmetric" and then add a priority stanza "metric X" right below the "iface eth0 inet xxxx" stanza in /etc/network/interfaces. You'd give "metric 0" the interface you want to be given priority, and "metric 1" (or 10 or 100...) for the secondary interface. Again, I am not certain this works, I think I've used it (for ethernet/wifi flip/flop) but I could be wrong.
- The other way to do this is to define a "source-based" routing policy. Basically the idea is that "ip route" shows the default routing table but you can add custom routing tables, and attach each table to a specific interface. So an outgoing packet on ethernet would lookup the default route defined for eth0, and an outgoing packet on wlan0 would lookup the default route defined for wlan0. This works, it's not really much more involved, the issue mostly lies in finding the right documentation, IMHO. This recipe should pertain to your use case.

(BTW, if resolv.conf keeps dancing around, that's probably because package "resolvconf" is installed. I don't see why you'd want to get rid of it and use a static resolv.conf file, but I guess doing that is possible)

HTH (!?)