wlan1>mon1 disconnects wlan0

[sonettguy]

I'm a stumped newbie. I am trying to follow Alasdar Allan's article on Adding a Second Wireless Adapter to a Raspberry Pi for Network Monitoring. In his instructions he suggests editing the file etc/network/interfaces to include the following.

Code: Select all

allow-hotplug wlan1
 iface wlan1 inet manual
 pre-up iw phy phy1 interface add mon1 type monitor
 pre-up iw dev wlan1 del
 pre-up ifconfig mon1 up

When I do this, the third line in this added code causes my wlan0 to disconnect from the access point. I know this by rebooting each time after adding one line at a time. It changes wlan1 to mon1 in monitor mode, just like it is supposed to, but wlan0 loses its connection and trying to add it manually give "Network is unreachable."

I'm using Rasbian Stretch on a Pi Zero W. If I do a "iw dev" query, It says the following of wlan0.

Code: Select all

phy#0
             Interface wlan0
                       ifindex 2
                       wdev 0x1
                       addr XX:XX:XX:XX:XX (actual is correct)
                       type managed
                       channel 1 (2412 MHz), width: 20 MHz, center1: 2412 MHz
                       txpower 31.00 dBm

When I removed the code from 'Interface' and tried to manually enter the same code, 'pre-up' was an unknown command. I entered the code back into 'Interface' without the 'pre-up', but it didn't work to change wlan1 to mon1 and thus wlan0 stayed connected. I tried adding 'sudo' to the lines in the file, but that didn't work either. Is this because wlan0 and mon1 are both on channel 1? I thought that wasn't a problem. I'm baffled.

[sonettguy]

With mon1 enabled and wlan0 connection broken, I tried manually to do the following.

Code: Select all

$ sudo iw dev wlan0 disconnect
$sudo ifconfig wlan0 down
$sudo ifconfig wlan0 up
$sudo iw dev wlan0 connect wsiit
$sudo dhclient -r wlan0
$sudo dhclient wlan0

All seemed to complete, except the last line, which just seemed to sit in an infinite loop. Had to ctl-z out. So, I can't even seem to force wlan0 back into operation...except by deleting the first changes to 'interfaces' and rebooting...upon which everything is fine and wlan1 is in managed mode. I'm still stumped.

[ejolson]

With mon1 enabled and wlan0 connection broken, I tried manually to do the following.
$ sudo iw dev wlan0 disconnect
$sudo ifconfig wlan0 down
$sudo ifconfig wlan0 up
$sudo iw dev wlan0 connect wsiit
$sudo dhclient -r wlan0
$sudo dhclient wlan0

All seemed to complete, except the last line, which just seemed to sit in an infinite loop. Had to ctl-z out. So, I can't even seem to force wlan0 back into operation...except by deleting the first changes to 'interfaces' and rebooting...upon which everything is fine and wlan1 is in managed mode. I'm still stumped.

For reasons unknown to me Stretch and Debian upstream switched to dhcpcd.conf from using network/interfaces. Try placing the line

denyinterfaces wlan0 wlan1 eth0

at the beginning of the dhcpcd.conf before following instructions designed for previous versions of Raspbian.

[sonettguy]

I greatly appreciate the suggestion. I note that the file ejolson suggested modifying; dhcpcd.conf, is in folder /etc/ while 'interfaces' is in /etc/network/. Does that matter?

I added the suggested code to the beginning of dhcpcd.conf.

Code: Select all

denyinterfaces wlan0 wlan1 eth0

Actually, my device has the name wlx followed by its MAC, instead of being wlan1.

I left the code creating mon1 in 'interfaces.' Rebooted. There was no difference. mon1 was created and killed wlan0.
Then, I wondered if ejolson meant for me to move the code creating mon1 to dhcpcd.conf, so I tried that. So this does something different. It does NOT create mon1 and leaves wlan1 in managed mode, but it DOES kill the wlan0 connection. Huh. That is really strange. Of course, wlan0 isn't even mentioned in the code.

[ejolson]

I greatly appreciate the suggestion.

Sorry it didn't help. Did you try putting mon1 in the deny line?

[sonettguy]

Wait a second! I mentioned that my device is shown with an interface name of wlx+MAC address. Shouldn't it be assigned wlanX by Raspbian Stretch? Is this part of the problem I'm encountering?

I did not try adding mon1, ejolson, but I will. Am I supposed to keep the code creating mon1 in 'interfaces'?

[ejolson]

Wait a second! I mentioned that my device is shown with an interface name of wlx+MAC address. Shouldn't it be assigned wlanX by Raspbian Stretch? Is this part of the problem I'm encountering?

I did not try adding mon1, ejolson, but I will. Am I supposed to keep the code creating mon1 in 'interfaces'?

That would be my suggestion. While it may not work, telling dhcpcd to ignore the network devices that you wish to configure using network/interfaces makes the current version of Raspbian more like previous versions.

I currently have a Pi 3B+ with an extra WiFi dongle in it acting as a wireless access point. I'm not terribly interested in inspecting the traffic so I haven't configured things the way you are trying.

[sonettguy]

Adding mon1 to the list did nothing. Same result as in the beginning. When wlx... is changed to mon1, the Ralink goes to monitor mode and disconnects wlan0 permanently.

[sonettguy]

Now, I'm really curious. In my first attempt, I added code to create mon1 in 'Interfaces'. But, what I read confirmed by what you tell me is that the Stretch version of Raspbian changed handling of the physical-to-interface definitions, moving from the Interface file to the dhcpcd file. But, if that is the case, then why did my first attempt succeed in linking phy1 to a newly defined mon1? In that attempt, I didn't make any changes to dhcpcd.

I do have a feeling that you have your finger on the source of the problem. I wonder if I need to somehow define wlan0 with a static definition. I wouldn't know even where to do that now; too confused about how dhcpcd and Interface work together.

[sonettguy]

More testing reveals something I didn't catch previously. I commented-out all code I've entered in dhcpcd and Interfaces. Reboot. All works well. wlan0 is connected to the Internet. Then, I edit dhcpcd.conf. I now have two additional WiFi adapters attached, in addition to the on-board Pi Zero W WiFi interface, so you see two interface definitions for each of them, 'wlx' with the MAC address following.

Code: Select all

denyinterfaces wlan0 wlx... wlx... eth0 mon1 wlan1 wlan2

Reboot. Now, recall that nothing has been added to Interfaces. It is in its default code. So, when it comes up, wlan0 is disconnected from the Internet. iw dev shows phy#0, phy#1, and phy#2 all correctly ID'd with their MACs and all managed mode, just as one would expect. ifconfig shows lo and wlan0 only. The latter shows flags=4099<UP, BROADCAST, MULTICAST> mtu 1500 and 'ether'. It shows no activity.

So, denyinterfaces in dhcpcd kills the wlan0 connection.

[sonettguy]

Still hot on the trail.

I see that Jarrod Sept 02, 2017 in viewtopic.php?t=191453, said

It seems that wpa_supplicant.conf needs to have the default contents and in particular no networks defined. dhcpcd looks carefully at this file, I believe due to hooks in the new GUI and CLI interfaces for configuring Wifi. It seems that if there is a network defined in wpa_supplicant and also a static IP defined for wlan0 in dhcpcd.conf, dhcpcd opts to deactivate the interface altogether. This was not the case in Jessie. Jessie would simply ignore wpa_supplicant.conf if you had a static ip defined for wlan0 in /etc/network/interfaces as outlined in the official docs for bringing up an AP.

This is perhaps why

Code: Select all

denyinterfaces wlan0

works for you. I do indeed have a network defined in wpa_supplicant (but, I'd really like to keep it defined so I don't have to log in each time). In my case, I am not defining a static IP address for wlan0 in dhcpcd.conf, nor anywhere else. There must be something more behind this deactivation of the interface.

[sonettguy]

Another clue; but, I'm still completely baffled. As I read more forums, it seems many are. Here's the next clue:
I again went back to the original files and tested the system to see that everything works as it should...and it does. So, the changes were all undone to "/etc/network/Interfaces" and "/etc/dhcpcd.conf". Reboot. Wlan0 connects merrily to my router. My second WiFi adapter, wlx... is in managed mode. Back to the beginning.

Following a suggestion from the previously linked forum thread, I moved the code for my defined network from /etc/wpa_supplicant/wpa_supplicant.conf to a new file /etc/wpa_supplicant/wpa_supplicant-wlan0.conf. Reboot. It comes up fine, seeming to find the new definition and connect to my local router again.

Next, I edited /etc/network/interfaces adding the code from the first referenced article. Then, I added new code to see if I could force wlan0 back into operation. It looks like this.

Code: Select all

allow-hotplug wlx...
 iface wlx... inet manual
 pre-up iw phy phy1 interface add mon1 type monitor
 pre-up iw dev wlx... del
 pre-up ifconfig mon1 up
auto wlan0
ifconfig wlan0 down
ifconfig wlan0 up
allow-hotplug wlan0
iface wlan0 inet manual

I'm not sure if the commands I added beginning with "auto" even make sense. I'm just parroting what I've seen in other threads. Maybe I shouldn't take it down after auto. Maybe hotplugging the on-board WiFi chip doesn't make sense. I don't know. I don't know if the indentation changes the code.

Anyway, without the code I added starting with "auto" I have my original problem for this thread, as soon as I define mon1 it kills the wlan0 connection. WITH the code I added, however, it does the OPPOSITE. The new code re-establishes wlan0 as a working interface and correctly connects to the new file defining my network....BUT, it kills mon1, which reverts back to its default managed mode.

What on earth?! Why is what I would expect would be wlan1 be called wlx+MAC? Why when I make changes to wlx... does it change wlan0? Why when I then change wlan0 does it change wlx...? When I enter an "iw dev", I clearly see phy#1 is wlx... and phy#0 is wlan0. I really don't see why changing one affects the other and vice-versa. Ideas?

[sonettguy]

Huh. I tried just entering from the Terminal the following.

Code: Select all

sudo iw phy phy1 interface add mon1 type monitor

Then, entering an 'iw dev' command shows under Phy#1 both Interface mon1 ifindex 5 (in monitor mode) AND interface wlx... ifindex 3 in managed mode. What? So, phy1 has two interfaces defined, operating differently? Is that because I didn't use the "iw dev wlx... del" command before it? Seems confusing to have two interfaces associated with one physical device.

[sonettguy]

I currently have a Pi 3B+ with an extra WiFi dongle in it acting as a wireless access point. I'm not terribly interested in inspecting the traffic so I haven't configured things the way you are trying.

When you installed the extra dongle, did your pi call it wlx123456789012, the numbers being the MAC address? Or, was it called wlan1?

Did you add anything else to dhcpcd.conf besides the one line you cited earlier? May I see your code from Interfaces? I've read every manual and all posts I could find and tried a dozen fixes, none of which had any impact. I'm now curious as to why the odd interface name is being assigned.

[sonettguy]

Still working daily on this problem. It still behaves as it did when I posted. But, I did make two amazing discoveries yesterday! One discovery was /var/log/. What?! In all the posts I've read (hundreds) I've never seen a log mentioned. There are lots of logs made in this folder! Reading through the daemon.log file opened my eyes to what the pii was doing and where things start falling apart. Very helpful...except I don't understand 90% of the cryptic language in the log, so it is a bit of a challenge.

The second discovery was a bug in the latest versions of Debian and Raspbian Stretch. Buried in the code is a line as follows.

Code: Select all

TEST!="/etc/udev/rules.d/80-net-setup-link.rules", \

But, the udev rule is not in /etc/. It is in /lib/. The result is that a newly installed WiFi dongle cannot be named by network.service and thus takes on the undesirable default name with is wlx+the MAC address.

The following fix is presented by elkberry in Re: Stretch | Not able to rename network interfaces any more, Fri Aug 25, 2017 7:01 pm:

Code: Select all

sudo ln -s /lib/udev/rules.d/80-net-setup-link.rules /etc/udev/rules.d/80-net-setup-link.rules

Which immediately solves the problem on reboot.

[sonettguy]

Oops. Now, I'm reading /usr/share/doc/udev/README.Debian.gz. Although it is mostly Greek to me, it appears the naming convention of wlx+MAC address, like wlx00da55dt55d5, is intentional. If so, then I just reverted a Stretch upgrade back to a Jesse practice. I thought the MAC was being used in cases where the system failed to properly name a new device. So, by reverting back to wlan0, wlan1 type of names, I may be going backwards in Debian evolution. If someone could confirm that, I would be appreciative, since I have a hard time reading the help file.

It seems the downside of going back to wlan0 and wlan1 is that the assignment of these names is not stable and could be different the next reboot. I have not seen this to be the case, but have read some other posts of those who have observed this.

I thought I took a small step forward, after investing two full weeks on this problem, but it seems I took a small step backward.

(Added)
In NEWS.Debian.gz, comes this.

systemd (220-7) unstable; urgency=medium

The mechanism for providing stable network interface names changed.
Previously they were kept in /etc/udev/rules.d/70-persistent-net.rules
which mapped device MAC addresses to the (arbitrary) name they got
when they first appeared (i. e. mostly at the time of installation).
As this had several problems and is not supported any more, this is
deprecated in favor of the "net.ifnames" mechanism. With this most of
your network interfaces will get location-based names. If you have
ifupdown, firewall, or other configuration that relies on the old
names, you need to update these by Debian 10/Ubuntu 18.04 LTS, and
then remove /etc/udev/rules.d/70-persistent-net.rules. Please see
/usr/share/doc/udev/README.Debian.gz for details about this.

-- Martin Pitt <mpitt@debian.org> Mon, 15 Jun 2015 15:30:29 +0200

This seems to confirm that the naming convention is intentional and that I just undid what is seen as an advancement, although a poorly advertised one.

[sonettguy]

Success.

After linking the rules file to the /etc folder (moving backwards in the progression of Debian network management) and changing the original code change cited above for an addition to /etc/network/interfaces to replace wlx+MAC with wlan1 and wlan2, suddenly, wlan0 stays connected and 1 and 2 get changed to monitor mode. Whew. But, I don't feel good about this success. It required going backwards in network naming convention and will mean all of this will stop working with the next release of Raspbian.

I should also note that I found files tcpdumpsetup.service and tcpdump.service which were completely commented-out, but noted that the boot was still trying and failing to execute them. Although I doubt this interfered, I did remove them also.

Anyway, I'm holding my breath now since the slightest breeze may unravel this delicate network configuration. I may toy with it further to try to determine WHY it works now. But for now, I will bask in the glory.

To summarize the final changes that seemed to make it work...

Code: Select all

sudo ln -s /lib/udev/rules.d/80-net-setup-link.rules /etc/udev/rules.d/80-net-setup-link.rules

Add the following code to /etc/network/interfaces, or in more detail, follow instructions given in https://medium.com/@aallan/adding-a-sec ... 7d7db7a9bd

Code: Select all

auto wlan1
allow-hotplug wlan1
 iface wlan1 inet manual
 pre-up iw phy phy1 interface add mon1 type monitor
 pre-up iw dev wlan1 del
 pre-up ifconfig mon1 up

Reboot.

Most helpful to me were the logs located in /var/log/. Particularly daemon.log and daemon.1.log. Also, /usr/share/doc/udev/README.Debian.gz, which one reads with a "zless" command (Cntl-Z out).

[sonettguy]

A footnote. Here is an unanswered question which makes me think I have a kluged solution. Why does phy0 seem to have two identities?

Code: Select all

pi@xxx:~ $ iw dev
phy#2
 Interface mon2
  ifindex 6
  wdev 0x200000002
  addr 00:0f:ff:11:ff:11
  type monitor
  channel 1 (2412 MHz), width: 20 MHz (no HT), center1: 2412 MHz
  txpower 20.00 dBm
phy#1
 Interface mon1
  ifindex 5
  wdev 0x100000002
  addr 00:da:ff:11:ff:11
  type monitor
  channel 1 (2412 MHz), width: 20 MHz (no HT), center1: 2412 MHz
  txpower 20.00 dBm
phy#0
 Unnamed/non-netdev interface
  wdev 0x2
  addr ba:27:ff:11:ff:11
  type P2P-device
  txpower 31.00 dBm
 Interface wlan0
  ifindex 2
  wdev 0x1
  addr b8:27:ff:11:ff:11
  ssid xxxxxxxx
  type managed
  channel 1 (2412 MHz), width: 20 MHz, center1: 2412 MHz
  txpower 31.00 dBm

[sonettguy]

Any ideas, @ejolson?

[ejolson]

Any ideas, @ejolson?

I created custom udev rules so the built-in WiFi is always wlan0 and the USB WiFi is always wlan1.

I'm currently traveling and can't check exact details until sometime next month. I think I modified the dhcpcd.conf file to ignore wlan1 which serves as the access point.
I also added some stuff to rc.local because I couldn't figure out what was going wrong with systemd.

[sonettguy]

OK, Thanks, ejolson. Safe travels. I'm guessing that you will not see the phenomena of multiple identities for phy#0 if you are forcing the interface assignments manually. I am beginning to suspect that it may be due to the fact that dhcpcd and systemd don't play well together. I think I saw a comment early in my search through the forum which said to choose one or the other and stick with it. Unfortunately, for newbies, it is hard to know when you are trying code for one or the other.

It is all still a mystery to me of how I fixed the original problem. I'd love to start from scratch and see if I could reproduce the problem, then fix it again. Yes, but no. That would take another two weeks and I have better things to do.

I now am monitoring RF signals, whether connected to a router or not, recording the unique MACs and counting them. I'm about to display the count on a 7-segment display. I will use it in my research to detect how many RF signals are present at any one place throughout the day.