Questions about awus036axm - mt7921 chipset

[randomxusr]

I'd like to use my adapter in both managed and ap mode for reasons. I'm a bit green as to how everything fits together via OSI here, when dealing with wifi.

My goal is to use a few devices in mesh point and bridge to the local network while some traffic is on a vlan, while other traffic may be available to the entire network.

I'm trying to understand whether my adapter can be placed in both AP and managed, as I believe that's where I need to start. I'm guessing that I'm missing some functional concept here, but not entirely certain what that may be.

My adapter also states that it supports a total of two combinations, being managed, and ap with a total of 2 interfaces and no more than two channels.

Do I have the right idea here?
If not, what do I need to reference to better understand this?
Is it correct that the 'total <= 2' in valid interface combinations means that I can use any available supported interface modes to hit that total, or do they need to be grouped like they show in this section?

Thanks

[fhteagle]

what is the raw output of iw phy for this device?

[morrownr]

@randomxusr

I usually use iw list but it will give information for all wireless devices in your system so you have to make sure you are looking at the right one. What you are looking for is valid interface combinations:. When you find it, paste it here

The below is an example:

valid interface combinations:
		 * #{ managed, P2P-client } <= 2, #{ AP, P2P-GO } <= 1,
		   total <= 2, #channels <= 2

I am quite sure the AXM supports interface combinations but with the requested information, we can explain what you can do.

[randomxusr]

Thanks for the check in here.

Here's the section for the valid combinations on this device.

valid interface combinations:
* #{ managed, P2P-client } <= 2, #{ AP, P2P-GO } <= 1,
total <= 2, #channels <= 2

I read this as meaning I could use this device as both in Managed Mode/Client, and as an AP, on up to two channels.

Is that correct?

[morrownr]

@randomxusr

That is correct. Let me make a suggestion: When you run into networking problems, and you will, post a new issue that describes the new subject.

[randomxusr]

Sounds good, but I have one add on this issue....

Does this also mean that I could set up something like Managed mode or Bridged mode and a separate AP or Mesh point to separate traffic for purpose?

The answer to this will give me an idea about How I could move forward, and I could better identify what constitutes or requires a new issue.

PS
Also plan to do a write up/review about the awus036axm and awus036axml. These have been problematic but I got them working outside bluetooth by disabling the bluetooth stack. Alas, this is unrelated and more heads up that I've been reading the comments in the discussions and supported devices.

[fhteagle]

Okay let's break up your various ideas into usable chunks:

1. STA aka client aka managed mode: Yes this adapter absolutely should be able to do this
2. AP mode: again yes, this is how I am using the AXML ... my working (but possibly less than optimal) hostapd.conf using WPA3 on 2ghz is here ( pardon the piles of cruft, make sure to change anything that starts with your_ ) : https://pastebin.com/YJys706k
3. Bridged mode: My example hostapd.conf does ethernet bridging with other devices using the bridge= line. This bridge is configured by systemd-networkd on boot first, and that line allows hostapd to join that br0 bridge after the br0 is set up. Use After= and PartOf= in your systemd service definition files if you want to go this route. Also, you may need "hairpin mode" to get certain UDP things to work right, like mDNS, kdeconnect, etc.
4. STA+AP: I have not done this combination, but it looks like it should be doable. Arch Wiki talks about adding two virtual interfaces to extend the real interface first, then bring up STA's virtual interface, then bring up hostapd AP on its virtual interface. Only the AP virtual interface can be added to the ethernet bridge AFAIK, as wifi interfaces in STA mode and ethernet bridges are effectively oil and water.
5. Mesh: this is totally different animal, and not one that I have DIY'd into existence. If you get that to work, I would love to see a writeup about how.

Agreed that disabling/masking systemd's bluetooth.service makes the AXML run much better. Unfortunate, but true, and not something I really need on the host that runs the AXML for me anyway. That's already a known road and much has already been written about the AXML here, so take a look at what already exists before putting work into duplicating all that.

[randomxusr]

Thanks. This gives me some direction.

I'm not the greatest with any of the individual parts; so I'll need to do some reading prior to attempting an implementation.

My Thought was that I could setup STA and AP modes and add virtual or software interfaces to sculpt the network from my imagination into physical/logical existence.

Given your comments about bridge mode; I plan to investigate a number of use cases and implementations to determine the most realistic path forward.

I'm not too worried about MESH points, as the devices support it, and I only need determine what physical/virtual combinations may or may not work.

Thanks again for all the input.

I'm also going to close this discussion and will open a new discussion for specific networking issues as needed, per morrownr's post.