Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FS#408 - Archer C7 has incorrect default bssid addresses for wifi networks #8185

Closed
openwrt-bot opened this issue Jan 18, 2017 · 11 comments
Closed
Labels

Comments

@openwrt-bot
Copy link

@openwrt-bot openwrt-bot commented Jan 18, 2017

howl:

Using LEDE Reboot SNAPSHOT r3022-7fb11c8.

This is at least for Archer C7 v2. The default bssids for the networks in my particular device are:

:::::*D for the 2,4 GHz radio and
::
:::*C for the 5 GHz radio

In LEDE they result in

:::::*C for the 2,4 GHz radio and
::
:::*B for the 5 GHz radio

The problem in LEDE is that the bssid set up for the 2,4 GHz is the one for 5 GHz and then the 5 GHz gets minus one. Don't know if it could be because the ethernet lan gets also ::::**:*D and wlan1 can't have the same mac address as eth1. In the original firmware this seems to be possible, both ethernet lan and 2,4 GHz radio have the same mac/bssid.

Also, at least with the 2,4 GHz radio, when you set up another connection with the device as client, the bssid of the master one change *(+2):::::*C the second hex digit gets plus 2, the bssid that should get a second connection as ap, but in this case there is one ap one client connections. This one could be right and I have to test with another router to see if it happens because I didn't notice this before.

@openwrt-bot
Copy link
Author

@openwrt-bot openwrt-bot commented Jan 19, 2017

howl:

I have tested with a tp-link tl-wr1043nd and I could see that it also happens that the default bssid of the wlan is used for the client connection and the the ap connection gets another one with the second hex digit incremented by 2, so that it's not a bug.

I also could see that the eth1 (lan) and the bssid of the wlan is the same, so it's possible for lede to have two networks with the same mac address, so indeed in the C7 the default bssid of the wlans are wrong.

The bssid of the 2,4 GHz network should be the same as the eth1 mac address, and the default bssid of the 5 GHz network should be the same one minus 1 to conform the mac and bssids that the default firmware has.

@openwrt-bot
Copy link
Author

@openwrt-bot openwrt-bot commented Jan 28, 2017

howl:

Some one else can confirm this one?

@openwrt-bot
Copy link
Author

@openwrt-bot openwrt-bot commented Feb 12, 2017

bjonglez:

Can you explain whether this causes actual issues? Or is it just a matter of doing the same thing as the stock firmware?

@openwrt-bot
Copy link
Author

@openwrt-bot openwrt-bot commented Feb 21, 2017

howl:

The second one, the mac address doesn't correspond to the original ones in the wifi networks. I'm using macaddr in the wireless config to set the original macs.

@openwrt-bot
Copy link
Author

@openwrt-bot openwrt-bot commented Aug 7, 2017

howl:

https://git.lede-project.org/?p=source.git;a=commitdiff;h=370aacf53280ca78fb3570558d5e1f29d0ae8d18

Here are a recent example that the rule seems to be to follow the default firmware behavior. Have seen another C7 that I do not own does the same thing for the mac addresses that I have described

@openwrt-bot
Copy link
Author

@openwrt-bot openwrt-bot commented Jul 20, 2018

howl:

https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=290c54473eadf3ea3ddef81e051b436bcb09224f

This commit is not right:
wlan doesn't need to be decremented, wlan 2 ghz and eth 1 lan has the same mac address in the original firmware.

So correct MAC adress increments for this board are:
wlan0 (5GHz) : -1
wlan1 (2.4GHz) : 0
eth1 (LAN) : 0
eth0 (WAN) : 1

@openwrt-bot
Copy link
Author

@openwrt-bot openwrt-bot commented Jul 25, 2018

mkresin:

Is it fixed with the "ath79: really fix TP-Link Archer C7 v2 MAC address" commit in my [[https://git.openwrt.org/?p=openwrt/staging/mkresin.git;a=summary|staging tree]]?

@openwrt-bot
Copy link
Author

@openwrt-bot openwrt-bot commented Aug 5, 2018

howl:

Actually there is no ath79 builds yet to test https://downloads.openwrt.org/snapshots/targets/

Perhaps they should be enabled in the development tree.

PD: If there is and issue to be enabled I could try to compile myself in the following days.

@openwrt-bot
Copy link
Author

@openwrt-bot openwrt-bot commented Feb 24, 2019

howl:

Tested, in ath79 it's solved.

@openwrt-bot
Copy link
Author

@openwrt-bot openwrt-bot commented Nov 13, 2019

adrianschmutzler:

I just stumbled over this and fixed it in ar71xx master:
a021268

You can test a backport to 19.07 from my staging tree for 19.07:
https://git.openwrt.org/?p=openwrt/staging/adrian.git;a=shortlog;h=refs/heads/staging-19.07

Please confirm that the assignment is correct, so we can close this bug report.

FYI: ar71xx mach file also includes setup for wdr4900v2, which is even more messed up.
I aligned it with c5/c7 in the ar71xx patch for now. Despite, I asked for information on the correct setup for this device in #1260

@openwrt-bot
Copy link
Author

@openwrt-bot openwrt-bot commented Sep 6, 2020

howl:

Sorry for being so much late.

It's fixed for Archer C7 v2.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant