Setting up WiFi over SSH, without using DietPi-config

beerenheini · 5 April 2016 06:49

Okay, after much testing I think I have the issue: https://github.com/raspberrypi/linux/issues/1355
It’s a kernel bug and the hardware does not support channels 12 & 13 in Germany. Kernel 4.4 apparently fixes it.

Can you help me with upgraden the kernel in DietPi?

Thanks again for your great help!

Update:

I updated the Kerne to 4.4 with

BRANCH=next rpi-update

but the problem still persists. My network does not appear in the network configuration in diet-config. Several others from my neighbors do. I Guess I’ll have to wait until an update is available. I Don’t want to switch to WPA.

k-plan · 6 April 2016 08:28

Hi,

Switching to WPA will not solve your problem.
Change channels will do it. If possible, let your router set channel by itself.
( FRITZ!Box Hilfe )

Is it RPi3 with build-in Wifi or RPi with USB Wifi dongle?

Same Wifi devices build for USA market do not have support for channel 12 / 13. Sometimes a other firmware or driver can fix it.
But not always. USA certificated devices will not be free to do switching specifications by software after manufacturing. (not all)

Can you read german? WLAN-Frequenzen und WLAN-Kanäle

Dummerweise sind in den USA die Kanäle 12 und 13 nicht für WLAN freigegeben. Dort wird deshalb die Kanalverteilung 1-6-11 verwendet, was uns in Deutschland bzw. EU egal sein könnte. Leider unterstützen die in Deutschland erhältlichen Geräte die Kanäle 12 und 13 nicht immer. Beispielsweise wenn die Geräte für die USA hergestellt wurden. Die Rede ist von ca. 30% der in Deutschland erhältlichen Geräte. In diesen Fällen ist die Hardware und Software nicht auf das Frequenzspektrum in Deutschland und die EU angepasst. Das bezieht sich sowohl auf WLAN-Clients in Notebooks, Smartphones und Tablets, als auch auf WLAN-Basisstationen. Manchmal hilft ein Firmware- oder Treiber-Update. Wenn nicht, dann muss der WLAN-Adapter oder eventuell das ganze Gerät getauscht werden. Im Zweifelsfall muss man mit einem kastrierten Gerät leben.

beerenheini · 12 April 2016 20:29

Guys, thank you for your help! I switched the channel to “11” and now all is working. I’ve read that kernel 4.4 is now considered safe and that it should support channels 12 and 13 so probably I’ll have a second go later on. But for now this topic should be solved.

It’ the Pi3. Thanks for the interesting link. What a pity. Germany alone is a pretty big market…

Fourdee · 13 April 2016 12:16

In the next DietPi release (v116):
You will now be able to configure both adapters in dietpi-config, at the same time, without having to disable the other.
https://github.com/Fourdee/DietPi/issues/265

V116 should be out in a few days.

beerenheini · 17 April 2016 22:26

Perfect, thanks for the update!

k-plan · 1 May 2016 12:19

RPi3 with build-in Wifi

 ───────────────────────────────────────
 DietPi     | 13:18 | Sun 01/05/16
 ───────────────────────────────────────
 V117       | Raspberry Pi 3 Model B
 ───────────────────────────────────────
 
 root@RPi-3-test:~# dmesg
  . . .
[    3.675159] brcmfmac: brcmf_sdio_drivestrengthinit: No SDIO Drive strength init done for chip 43430 rev 1 pmurev 24
[    3.676350] usbcore: registered new interface driver brcmfmac
[    3.870719] brcmfmac: brcmf_c_preinit_dcmds: Firmware version = wl0: Dec 15 2015 18:10:45 version 7.45.41.23 (r606571) FWID 01-cc4eda9c
[    4.027452] brcmfmac: brcmf_cfg80211_reg_notifier: not a ISO3166 code
[    4.027500] cfg80211: World regulatory domain updated:
[    4.027510] cfg80211:  DFS Master region: unset
[    4.098267] brcmfmac: power management disabled



root@RPi-3-test:~# lshw
 . . .
  *-network:0
       description: Wireless interface
       physical id: 2
       logical name: wlan0
       serial: b8:27:eb:xx:xx:xx
       capabilities: ethernet physical wireless
       configuration: broadcast=yes driver=brcmfmac driverversion=7.45.41.23 firmware=01-cc4eda9c ip=192.168.0.100 multicast=yes wireless=IEEE 802.11bgn
       
       
root@RPi-3-test:~# uname -a
Linux RPi-3-test 4.1.19-v7+ #858 SMP Tue Mar 15 15:56:00 GMT 2016 armv7l GNU/Linux


root@RPi-3-test:~# cat /proc/version
Linux version 4.1.19-v7+ (dc4@dc4-XPS13-9333) (gcc version 4.9.3 (crosstool-NG crosstool-ng-1.22.0-88-g8460611) ) #858 SMP Tue Mar 15 15:56:00 GMT 2016


root@RPi-3-test:~# iwlist wlan0 channel
wlan0     11 channels in total; available frequencies :
          Channel 01 : 2.412 GHz
          Channel 02 : 2.417 GHz
          Channel 03 : 2.422 GHz
          Channel 04 : 2.427 GHz
          Channel 05 : 2.432 GHz
          Channel 06 : 2.437 GHz
          Channel 07 : 2.442 GHz
          Channel 08 : 2.447 GHz
          Channel 09 : 2.452 GHz
          Channel 10 : 2.457 GHz
          Channel 11 : 2.462 GHz
          Current Frequency:2.412 GHz (Channel 1)

Last official Kernel : Linux 4.1.19-v7+ #858 SMP Tue Mar 15 15:56:00 GMT 2016 armv7l GNU/Linux
and brcmfmac WiFi Firmware version = wl0: Dec 15 2015 18:10:45 version 7.45.41.23 (r606571)

only support Channel 01 - Channel 11 (no Channel 12 + 13)

==============================

It’s a kernel bug and the hardware does not support channels 12 & 13 in Germany. Kernel 4.4 apparently fixes it.

Can you help me with upgraden the kernel in DietPi?

IMPORTANT: - Only for Testing ! - :

Upgrade to the latest Kernel and Firmware (not recommend to do this !!!)

root@RPi-3-test:~# dietpi-config 

=> 4  Advanced Options  
=> 4 Update Firmware
=> reboot

 ───────────────────────────────────────
 DietPi     | 14:02 | Sun 01/05/16
 ───────────────────────────────────────
 V117       | Raspberry Pi 3 Model B
 ───────────────────────────────────────



 root@RPi-3-test:~# dmesg
  . . .
[    4.193627] brcmfmac: brcmf_sdio_drivestrengthinit: No SDIO Drive strength init done for chip 43430 rev 1 pmurev 24
[    4.194241] usbcore: registered new interface driver brcmfmac
[    4.342817] brcmfmac: brcmf_c_preinit_dcmds: Firmware version = wl0: Dec 15 2015 18:10:45 version 7.45.41.23 (r606571) FWID 01-cc4eda9c
[    4.368110] brcmfmac: brcmf_cfg80211_reg_notifier: not a ISO3166 code
[    4.381683] cfg80211: World regulatory domain updated:
[    4.381694] cfg80211:  DFS Master region: unset
[    4.476007] brcmfmac: power management disabled


root@RPi-3-test:~# lshw
 . . .
  *-network:0
       description: Wireless interface
       physical id: 2
       logical name: wlan0
       serial: b8:27:eb:xx:xx:xx
       capabilities: ethernet physical wireless
       configuration: broadcast=yes driver=brcmfmac driverversion=7.45.41.23 firmware=01-cc4eda9c ip=192.168.0.100 multicast=yes wireless=IEEE 802.11bgn



root@RPi-3-test:~# uname -a
Linux RPi-3-test 4.4.8-v7+ #881 SMP Sat Apr 30 12:16:50 BST 2016 armv7l GNU/Linux


root@RPi-3-test:~# cat /proc/version
Linux version 4.4.8-v7+ (dc4@dc4-XPS13-9333) (gcc version 4.9.3 (crosstool-NG crosstool-ng-1.22.0-88-g8460611) ) #881 SMP Sat Apr 30 12:16:50 BST 2016


root@RPi-3-test:~# iwlist wlan0 channel
wlan0     11 channels in total; available frequencies :
          Channel 01 : 2.412 GHz
          Channel 02 : 2.417 GHz
          Channel 03 : 2.422 GHz
          Channel 04 : 2.427 GHz
          Channel 05 : 2.432 GHz
          Channel 06 : 2.437 GHz
          Channel 07 : 2.442 GHz
          Channel 08 : 2.447 GHz
          Channel 09 : 2.452 GHz
          Channel 10 : 2.457 GHz
          Channel 11 : 2.462 GHz
          Current Frequency:2.412 GHz (Channel 1)

edit:

Test and set the correct regulatory domain:

root@RPi-3-test:~# iw reg get
country 00: DFS-UNSET
        (2402 - 2472 @ 40), (N/A, 20), (N/A)
        (2457 - 2482 @ 40), (N/A, 20), (N/A), NO-IR
        (2474 - 2494 @ 20), (N/A, 20), (N/A), NO-OFDM, NO-IR
        (5170 - 5250 @ 80), (N/A, 20), (N/A), NO-IR
        (5250 - 5330 @ 80), (N/A, 20), (0 ms), DFS, NO-IR
        (5490 - 5730 @ 160), (N/A, 20), (0 ms), DFS, NO-IR
        (5735 - 5835 @ 80), (N/A, 20), (N/A), NO-IR
        (57240 - 63720 @ 2160), (N/A, 0), (N/A)


root@RPi-3-test:~# iw reg set DE


root@RPi-3-test:~# iw reg get
country DE: DFS-ETSI
        (2400 - 2483 @ 40), (N/A, 20), (N/A)
        (5150 - 5250 @ 80), (N/A, 20), (N/A), NO-OUTDOOR
        (5250 - 5350 @ 80), (N/A, 20), (0 ms), NO-OUTDOOR, DFS
        (5470 - 5725 @ 160), (N/A, 26), (0 ms), DFS
        (57000 - 66000 @ 2160), (N/A, 40), (N/A)


root@RPi-3-test:~# iwlist wlan0 channel
wlan0     13 channels in total; available frequencies :
          Channel 01 : 2.412 GHz
          Channel 02 : 2.417 GHz
          Channel 03 : 2.422 GHz
          Channel 04 : 2.427 GHz
          Channel 05 : 2.432 GHz
          Channel 06 : 2.437 GHz
          Channel 07 : 2.442 GHz
          Channel 08 : 2.447 GHz
          Channel 09 : 2.452 GHz
          Channel 10 : 2.457 GHz
          Channel 11 : 2.462 GHz
          Channel 12 : 2.467 GHz
          Channel 13 : 2.472 GHz
          Current Frequency:2.412 GHz (Channel 1)

To make this setting permanent:

root@RPi-3-test:~# sed -i "s/REGDOMAIN=/REGDOMAIN=DE/g" /etc/default/crda


root@RPi-3-test:~# cat /etc/default/crda
# Set REGDOMAIN to a ISO/IEC 3166-1 alpha2 country code so that iw(8) may set
# the initial regulatory domain setting for IEEE 802.11 devices which operate
# on this system.
#
# Governments assert the right to regulate usage of radio spectrum within
# their respective territories so make sure you select a ISO/IEC 3166-1 alpha2
# country code suitable for your location or you may infringe on local
# legislature. See `/usr/share/zoneinfo/zone.tab' for a table of timezone
# descriptions containing ISO/IEC 3166-1 alpha2 country codes.

REGDOMAIN=DE

Reboot and testing:

root@RPi-3-test:~# reboot


root@RPi-3-test:~# dmesg
 . . .
[    4.454422] cfg80211: Regulatory domain changed to country: DE
[    4.454444] cfg80211:  DFS Master region: ETSI
[    4.454454] cfg80211:   (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp), (dfs_cac_time)
[    4.454469] cfg80211:   (2400000 KHz - 2483500 KHz @ 40000 KHz), (N/A, 2000 mBm), (N/A)
[    4.454486] cfg80211:   (5150000 KHz - 5250000 KHz @ 80000 KHz, 200000 KHz AUTO), (N/A, 2000 mBm), (N/A)
[    4.454500] cfg80211:   (5250000 KHz - 5350000 KHz @ 80000 KHz, 200000 KHz AUTO), (N/A, 2000 mBm), (0 s)
[    4.454513] cfg80211:   (5470000 KHz - 5725000 KHz @ 160000 KHz), (N/A, 2698 mBm), (0 s)
[    4.454525] cfg80211:   (57000000 KHz - 66000000 KHz @ 2160000 KHz), (N/A, 4000 mBm), (N/A)


root@RPi-3-test:~# iwlist wlan0 channel
wlan0     13 channels in total; available frequencies :
          Channel 01 : 2.412 GHz
          Channel 02 : 2.417 GHz
          Channel 03 : 2.422 GHz
          Channel 04 : 2.427 GHz
          Channel 05 : 2.432 GHz
          Channel 06 : 2.437 GHz
          Channel 07 : 2.442 GHz
          Channel 08 : 2.447 GHz
          Channel 09 : 2.452 GHz
          Channel 10 : 2.457 GHz
          Channel 11 : 2.462 GHz
          Channel 12 : 2.467 GHz
          Channel 13 : 2.472 GHz
          Current Frequency:2.412 GHz (Channel 1)

Result : Done !

k-plan · 1 May 2016 17:24

Now in DietPi release v117 it works nearly perfect.
You can configure and set active ethernet and wifi connection per dietpi-config, plugging in or out cable or adapter.
Established connection from the device will working along and you can connect via SSH to wlan or eth IP addresses.

https://github.com/Fourdee/DietPi/issues/273

Thanks to @Fourdee for implement this.

Fourdee · 1 May 2016 18:48

And many thanks to you for your assistance with this one

k-plan · 2 May 2016 00:33

No problem, my pleasure!

BTW: - now you have to do a little update on DietPi-Config and explain new feature like Proxy, NAS a. Network Feature, Firmware Update, DNS and so on.
https://dietpi.com/forum/t/dietpi-config-feature-rich-config-tool-for-your-device/61/1

k-plan · 2 May 2016 06:19

Hi,

I have done a update to my previous posting: https://dietpi.com/forum/t/setting-up-wifi-over-ssh-without-using-dietpi-config/287/13

(note for myself: have to do a new test with fresh install)

Gord_W · 7 December 2016 18:27

I’m also having problems setting up a rpi3 with wifi after using ethernet for a time headless.

Using V135.

What I am finding is that when I have ethernet connected to the router and wifi with ip 192.168.1.100 and 192.168.1.103 when I send requests to wifi the Rx byte count increases on the wifi but the tx byte count doesn’t while eth tx byte count increases. Therefore the data to rpi appears to be going in through wifi and the reply comes out through ethernet.

When I unplug ethernet, even though I’m ssh through wifi, the ssh connection fails. There is no return path for ssh data when ethernet is disconnected. There is no way to reconnect. I’ve tried all sorts of things and this has me baffled.

I had this working on a rpi B a year ago and it worked fine. Change in dietpi version?

Regards,
Gordon

Some examples below to try and illustrate the problem.

From the desktop ping 192.168.1.103 wifi to produce some data through .103

root@DietPi:~# ifconfig
eth0 Link encap:Ethernet HWaddr b8:27:eb:9e:47:6e
inet addr:192.168.1.100 Bcast:192.168.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:3095 errors:0 dropped:0 overruns:0 frame:0
TX packets:5453 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:179569 (175.3 KiB) TX bytes:1578246 (1.5 MiB)

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:1126 errors:0 dropped:0 overruns:0 frame:0
TX packets:1126 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1
RX bytes:94312 (92.1 KiB) TX bytes:94312 (92.1 KiB)

wlan0 Link encap:Ethernet HWaddr b8:27:eb:cb:12:3b
inet addr:192.168.1.103 Bcast:192.168.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:2822 errors:0 dropped:8 overruns:0 frame:0
TX packets:9 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:238722 (233.1 KiB) TX bytes:1429 (1.3 KiB)

wait a few seconds … and repeat

root@DietPi:~# ifconfig
eth0 Link encap:Ethernet HWaddr b8:27:eb:9e:47:6e
inet addr:192.168.1.100 Bcast:192.168.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:3097 errors:0 dropped:0 overruns:0 frame:0
TX packets:5530 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:179661 (175.4 KiB) TX bytes:1588008 (1.5 MiB)

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:1126 errors:0 dropped:0 overruns:0 frame:0
TX packets:1126 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1
RX bytes:94312 (92.1 KiB) TX bytes:94312 (92.1 KiB)

wlan0 Link encap:Ethernet HWaddr b8:27:eb:cb:12:3b
inet addr:192.168.1.103 Bcast:192.168.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:2921 errors:0 dropped:8 overruns:0 frame:0
TX packets:9 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:247647 (241.8 KiB) TX bytes:1429 (1.3 KiB)

Difference Rx, Tx between the two
eth0 RX packets:3095
TX packets:5453

RX packets:3097
TX packets:5530
Rx traffic 2 packets
Tx traffic 77 packets

wlan0 RX packets:2822
TX packets:9

RX packets:2921
TX packets:9
Rx traffic 99
Tx traffic none

So to me this means that the data is going into wifi and reply is coming back on ethernet. Why would rpi route it like that?

Other info:
root@DietPi:~# iwconfig
wlan0 IEEE 802.11bgn ESSID:“Williams”
Mode:Managed Frequency:2.412 GHz Access Point: 6F:66:B3:F4:35:AB
Bit Rate=65 Mb/s Tx-Power=31 dBm
Retry short limit:7 RTS thr:off Fragment thr:off
Encryption key:off
Power Management:off
Link Quality=70/70 Signal level=-23 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0

lo no wireless extensions.

eth0 no wireless extensions.

#/etc/network/interfaces

Local

auto lo
iface lo inet loopback

Ethernet

auto eth0
iface eth0 inet static
address 192.168.1.100
netmask 255.255.255.0
gateway 192.168.1.1

Wifi

auto wlan0
iface wlan0 inet dhcp
#address 192.168.1.100
#netmask 255.255.255.0
#gateway 192.168.1.1
#wireless-essid Williams
#wireless-key xxx
wireless-mode Managed
wireless-power off
wpa-ssid Williams
wpa-psk xxx

Gord_W · 7 December 2016 18:30

I will try and do a fresh install to see if that fixes things.

Edit:
OK, I put on the latest version of dietpi. I edited the dietpi.txt file to enable wifi and disable ethernet

I got the wifi up and working.

Went to enable the ethernet through the dietpi menus and set ethernet to static address and filled out IP address parameters. Clicked OK to upadate with the message that connections would be dropped.
Reconnecting Ethernet , please wait

DietPi-Services
─────────────────────────────────────────────────────
Mode: stop
Please wait…

[Ok] cron
[Ok] proftpd

[Info] Dropping connections, please wait…

— So wifi connection was dropped. Now I cant reconnect to wifi
gordon@gordon-linux ~ $ ssh root@192.168.1.103
ssh: connect to host 192.168.1.103 port 22: No route to host

Before I got to this point there were two programs that were downloaded and installed: iproute and netplug (I think) Could it be one of these programs that is screwing things up?

Will try and plug the ethernet in to see if I can get a ssh connection through ethernet.

Gord_W · 7 December 2016 22:47

Plugged in the ethernet and got a ssh connection. Looks like the wifi has been lost ---- Access Point: Not-Associated
root@DietPi:~# ifconfig
eth0 Link encap:Ethernet HWaddr b8:27:eb:9e:47:6e
inet addr:192.168.1.100 Bcast:192.168.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1287 errors:0 dropped:2 overruns:0 frame:0
TX packets:83 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:104217 (101.7 KiB) TX bytes:12682 (12.3 KiB)

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

wlan0 Link encap:Ethernet HWaddr b8:27:eb:cb:12:3b
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:686 errors:0 dropped:30 overruns:0 frame:0
TX packets:4 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:65678 (64.1 KiB) TX bytes:1028 (1.0 KiB)

root@DietPi:~# iwconfig
wlan0 IEEE 802.11bgn ESSID:off/any
Mode:Managed Access Point: Not-Associated Tx-Power=31 dBm
Retry short limit:7 RTS thr:off Fragment thr:off
Encryption key:off
Power Management:off

Gord_W · 7 December 2016 22:54

This is what dietpi-config says

DietPi - Network Options: Adapters ├─────────────┐
│ │
│ Ethernet : Available | Enabled | Connected │
│ Wifi : Available | Enabled | Disconnected │
│ IPv6 : Disabled │
│ Internet : Please run Internet Test │
│ Proxy : Disabled │

Under DietPi - Wireless Network Options my ssid is correct, pw is correct and mode is dhcp.

Why is it not connecting?
Gord_W

Edit: Current interfaces file
root@DietPi:/etc/network# cat interfaces
#/etc/network/interfaces
#Please use DietPi-Config to modify network settings.

Local

auto lo
iface lo inet loopback

Ethernet

allow-hotplug eth0
iface eth0 inet static
address 192.168.1.100
netmask 255.255.255.0
gateway 192.168.1.1
dns-nameservers 8.8.8.8 8.8.4.4

Wifi

allow-hotplug wlan0
iface wlan0 inet dhcp
address 192.168.0.100
netmask 255.255.255.0
gateway 192.168.0.1
wireless-essid Williams
wireless-key xxx
wireless-mode Managed
wireless-power off
wpa-ssid Williams
wpa-psk xxx
#dns-nameservers 8.8.8.8 8.8.4.4

Gord_W · 8 December 2016 00:11

What I am eventually hoping to do is have ethernet on 10.0.0.x network and wifi on 192.168.1.x network.

I change the above interfaces file to:

Wifi

allow-hotplug wlan0
iface wlan0 inet dhcp
#address 192.168.0.100
#netmask 255.255.255.0
#gateway 192.168.0.1
#wireless-essid Williams
#wireless-key xxx
wireless-mode Managed
wireless-power off
wpa-ssid Williams
wpa-psk xxx
#dns-nameservers 8.8.8.8 8.8.4.4

And the wifi is working to the point that I can ssh into .103 but it is back to the original problem with wlan0 is getting the Rx and the Tx reply is coming back through the ethernet.

Gord_W · 8 December 2016 00:52

Here is some information that is way beyond me. Maybe someone can decipher it and explain what is happening.

root@DietPi:~# ip route show
default via 192.168.1.1 dev eth0
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.100
192.168.1.0/24 dev wlan0 proto kernel scope link src 192.168.1.103

root@DietPi:~# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.1.1 0.0.0.0 UG 0 0 0 eth0
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 wlan0

root@DietPi:~# ip link list
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
link/ether b8:27:eb:9e:47:6e brd ff:ff:ff:ff:ff:ff
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DORMANT group default qlen 1000
link/ether b8:27:eb:cb:12:3b brd ff:ff:ff:ff:ff:ff

What is state UP mode DEFAULT/DORMANT above?

ARP
root@DietPi:~# ip neigh show
192.168.1.101 dev wlan0 lladdr 00:22:15:c6:68:4a STALE
192.168.1.101 dev eth0 lladdr 00:22:15:c6:68:4a REACHABLE
192.168.1.1 dev eth0 lladdr 64:66:b3:f4:35:f8 STALE

Gord_W · 8 December 2016 00:58

So, I unplugged the eithernet expecting the whole thing to stop working but I was able to ssh in with the wifi. Go figure!

Anyway, enough for tonight.

Gord_W · 8 December 2016 16:07

I left it on overnight and came back this morning. Ethernet unplugged, using wifi. Everything working so I thought. Then tried to download package from internet and found that external connections were not working. Only local network.

I halted and powered down and up. Tried to ssh through wifi and couldn’t get a connection. ssh: connect to host 192.168.1.103 port 22: Connection timed out NOTE! it didn’t say “No route to host”

Router Wireless Status says MAC address is associated and small number of packets sent and received.
Router DHCP says dietpi with correct MAC is at 192.168.1.103

So I’m guessing but I suspect, even though the eithernet cable is disconnected it is trying to send ssh replies back to eth0 instead of wlan0 as have shown before in my earlier posts.

Something is seriously wrong here.

Gord_W · 8 December 2016 16:32

Looking for help or suggestions here. I’m a beginner and this is beyond my capabilities.

When I couldn’t get to the internet and before I powered down and up discussed above I did a few tests.

root@DietPi:~# ip route show
192.168.1.0/24 dev wlan0 proto kernel scope link src 192.168.1.103

root@DietPi:~# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 wlan0

Note this was - first entry now missing.

root@DietPi:~# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.1.1 0.0.0.0 UG 0 0 0 eth0
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 wlan0

root@DietPi:~# ip neigh show
192.168.1.101 dev wlan0 lladdr 00:22:15:c6:68:4a REACHABLE
192.168.1.1 dev wlan0 lladdr 64:66:b3:f4:35:f8 DELAY

root@DietPi:~# ping http://www.google.com
connect: Network is unreachable

root@DietPi:~# ip neigh show
192.168.1.101 dev wlan0 lladdr 00:22:15:c6:68:4a REACHABLE
192.168.1.1 dev wlan0 lladdr 64:66:b3:f4:35:f8 REACHABLE

Fourdee · 17 December 2016 17:22

I’m also having problems setting up a rpi3 with wifi after using ethernet for a time headless.
Looking for help or suggestions here.

Hi Gordon,

Lets take a look at this for you.

Ok, so from what I can read, WiFi isn’t working correctly, no route to external sources? If that is the case its most likely a DNS/routing issue. As for the cause, not sure yet, but we can run some tests.

Few questions and tests:

Check signal strength (dB) on the RPi, maybe its dropping out:

iwconfig

Is this onboard WiFi on RPi 3, or, USB ? (sorry if i missed you mention this in another post, cant find it)
Have you tried using static IP on WiFi?
Try removing netplug and reboot system:

apt-get purge netplug -y