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

5GHz channel property ignored for AP (client1 interface) #386

Closed
scosu opened this Issue May 30, 2015 · 9 comments

Comments

Projects
None yet
2 participants
@scosu

scosu commented May 30, 2015

I noticed that the 5GHz AP interface is on channel 36 although the site.conf has it set to channel 40, HT40+. This breaks the mesh interface on 5ghz as it tries to join the mesh on channel 40.

Disabling the client1 interface in uci leads to a working mesh1 interface which then shows up on channel 40 correctly.

I noticed this while debugging the mesh1 interface in gluon2015.1. But it seems this problem already existed in 2014.* as all my other 5GHz router operate on the wrong channel as well.

I am using tp-link wdr3600 as hardware to test this.

This is the site.conf I used:
https://github.com/ffhi/ffhi-site/blob/7d72e9a8d2d87f3d7c31bc1be02f587363d86ab7/site.conf

@NeoRaider

This comment has been minimized.

Show comment
Hide comment
@NeoRaider

NeoRaider Jun 5, 2015

Member

I can't reproduce this on a WDR4900, neither with 2015.1 nor with the current (CC-based) master. I'll check with a WDR3600 next week. I've used your site.conf to build a firmware myself, if you provide your firmware images, I can test those as well.

Member

NeoRaider commented Jun 5, 2015

I can't reproduce this on a WDR4900, neither with 2015.1 nor with the current (CC-based) master. I'll check with a WDR3600 next week. I've used your site.conf to build a firmware myself, if you provide your firmware images, I can test those as well.

@scosu

This comment has been minimized.

Show comment
Hide comment
@scosu

scosu Jun 6, 2015

Unfortunately I don't have any other 5ghz routers around to test this. I further tested this with different 5ghz channels:

channel 36:

    Interface client1
            ifindex 17
            wdev 0x100000004
            addr c2:4c:02:40:62:d4
            ssid freifunk-hi.de_5ghz
            type AP
            wiphy 1
            channel 36 (5180 MHz), width: 40 MHz, center1: 5190 MHz

    mesh1 interface active

channel 40:

    Interface client1
            ifindex 17
            wdev 0x100000004
            addr c2:4c:02:40:62:d4
            ssid freifunk-hi.de_5ghz
            type AP
            wiphy 1
            channel 36 (5180 MHz), width: 40 MHz, center1: 5190 MHz

    mesh1 interface inactive

channel 44:

    Interface client1
            ifindex 17
            wdev 0x100000004
            addr c2:4c:02:40:62:d4
            ssid freifunk-hi.de_5ghz
            type AP
            wiphy 1
            channel 48 (5240 MHz), width: 40 MHz, center1: 5230 MHz

    mesh1 interface inactive

channel 48:

    Interface client1
            ifindex 17
            wdev 0x100000004
            addr c2:4c:02:40:62:d4
            ssid freifunk-hi.de_5ghz
            type AP
            wiphy 1
            channel 48 (5240 MHz), width: 40 MHz, center1: 5230 MHz

    mesh1 interface active

scosu commented Jun 6, 2015

Unfortunately I don't have any other 5ghz routers around to test this. I further tested this with different 5ghz channels:

channel 36:

    Interface client1
            ifindex 17
            wdev 0x100000004
            addr c2:4c:02:40:62:d4
            ssid freifunk-hi.de_5ghz
            type AP
            wiphy 1
            channel 36 (5180 MHz), width: 40 MHz, center1: 5190 MHz

    mesh1 interface active

channel 40:

    Interface client1
            ifindex 17
            wdev 0x100000004
            addr c2:4c:02:40:62:d4
            ssid freifunk-hi.de_5ghz
            type AP
            wiphy 1
            channel 36 (5180 MHz), width: 40 MHz, center1: 5190 MHz

    mesh1 interface inactive

channel 44:

    Interface client1
            ifindex 17
            wdev 0x100000004
            addr c2:4c:02:40:62:d4
            ssid freifunk-hi.de_5ghz
            type AP
            wiphy 1
            channel 48 (5240 MHz), width: 40 MHz, center1: 5230 MHz

    mesh1 interface inactive

channel 48:

    Interface client1
            ifindex 17
            wdev 0x100000004
            addr c2:4c:02:40:62:d4
            ssid freifunk-hi.de_5ghz
            type AP
            wiphy 1
            channel 48 (5240 MHz), width: 40 MHz, center1: 5230 MHz

    mesh1 interface active
@scosu

This comment has been minimized.

Show comment
Hide comment
@scosu

scosu Jun 6, 2015

The images I built are here. They are configured to work on channel 36 right now, but changing the channel to 40 or 44 shows this issue again.

http://firmware.freifunk-hi.de/experimental/factory/gluon-ffhi-0.7.0-tp-link-tl-wdr3600-v1.bin

scosu commented Jun 6, 2015

The images I built are here. They are configured to work on channel 36 right now, but changing the channel to 40 or 44 shows this issue again.

http://firmware.freifunk-hi.de/experimental/factory/gluon-ffhi-0.7.0-tp-link-tl-wdr3600-v1.bin

@NeoRaider

This comment has been minimized.

Show comment
Hide comment
@NeoRaider

NeoRaider Jul 1, 2015

Member

Okay, seems like OpenWrt switches to the channel of other devices using the same cell ID on adhoc, so if there's another node on channel 36, it will switch to the same channel under certain circumstances.

I'll try to find out how to circumvent this issue.

Member

NeoRaider commented Jul 1, 2015

Okay, seems like OpenWrt switches to the channel of other devices using the same cell ID on adhoc, so if there's another node on channel 36, it will switch to the same channel under certain circumstances.

I'll try to find out how to circumvent this issue.

@NeoRaider

This comment has been minimized.

Show comment
Hide comment
@NeoRaider

NeoRaider Jul 6, 2015

Member

I think the basic issue is that hostapd sometimes decides to switch the primary and secondary channel when HT40 is used, as hostapd only managed the AP network and doesn't know it breaks adhoc doing this. As a workaround, HT20 can be used. I think this issue might affect 2.4GHz as well.

Maybe there's a way to prevent this in hostapd...

Member

NeoRaider commented Jul 6, 2015

I think the basic issue is that hostapd sometimes decides to switch the primary and secondary channel when HT40 is used, as hostapd only managed the AP network and doesn't know it breaks adhoc doing this. As a workaround, HT20 can be used. I think this issue might affect 2.4GHz as well.

Maybe there's a way to prevent this in hostapd...

@NeoRaider

This comment has been minimized.

Show comment
Hide comment
@NeoRaider

NeoRaider Jul 6, 2015

Member

I've looked at the hostapd code now... my conclusion:

  • This affects 5GHz only
  • Setting HT20 will prevent this issue
Member

NeoRaider commented Jul 6, 2015

I've looked at the hostapd code now... my conclusion:

  • This affects 5GHz only
  • Setting HT20 will prevent this issue
@scosu

This comment has been minimized.

Show comment
Hide comment
@scosu

scosu Jul 8, 2015

Thanks for debugging this issue. We will use HT20 then for the moment.

I am not sure how it is coded right now. But perhaps hostapd has proper error handling so first the adhoc network could be setup and then the AP interface? Wouldn't this prevent the AP interface to switch to a different channel?

scosu commented Jul 8, 2015

Thanks for debugging this issue. We will use HT20 then for the moment.

I am not sure how it is coded right now. But perhaps hostapd has proper error handling so first the adhoc network could be setup and then the AP interface? Wouldn't this prevent the AP interface to switch to a different channel?

@NeoRaider

This comment has been minimized.

Show comment
Hide comment
@NeoRaider

NeoRaider Jul 8, 2015

Member

hostapd doesn't know anything about the adhoc interface, it handles only the AP interface. In my tests, the adhoc interface lost its configuration (was shown as NO-CARRIER) when hostapd decided to switch the channel...

Member

NeoRaider commented Jul 8, 2015

hostapd doesn't know anything about the adhoc interface, it handles only the AP interface. In my tests, the adhoc interface lost its configuration (was shown as NO-CARRIER) when hostapd decided to switch the channel...

@NeoRaider NeoRaider added the bug label Jul 12, 2015

@NeoRaider NeoRaider added this to the 2015.2 milestone Jul 12, 2015

@NeoRaider

This comment has been minimized.

Show comment
Hide comment
@NeoRaider

NeoRaider Jul 27, 2015

Member

This should be fixed by 75cebd2, please test.

Member

NeoRaider commented Jul 27, 2015

This should be fixed by 75cebd2, please test.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment