Modify

Opened 5 years ago

Closed 4 years ago

Last modified 2 years ago

#12000 closed defect (wontfix)

ar71xx sta-ap mode connectivity problem.

Reported by: eminarcissus@… Owned by: developers
Priority: normal Milestone: Barrier Breaker 14.07
Component: packages Version: Trunk
Keywords: Cc:

Description

Hi, I've tried sta-ap mode on tplink 703n openwrt compiled with latest trunk r33072.

It is working only when sta wifi-iface correctly configured. If any mistake occurs it will disable ap/sta iface altogether.

(ap iface)
wlan0 Link encap:Ethernet HWaddr EC:88:8F:CB:8B:BE

UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:21 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:32
RX bytes:0 (0.0 B) TX bytes:2444 (2.3 KiB)

(sta iface)
wlan0-1 Link encap:Ethernet HWaddr EE:88:8F:CB:8B:BF

UP BROADCAST MULTICAST MTU:1500 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:32
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

dmesg snapshot
[ 297.270000] ADDRCONF(NETDEV_UP): wlan0-1: link is not ready
[ 298.220000] br-lan: port 1(eth0) entered forwarding state
[ 298.280000] br-lan: port 2(wlan0) entered disabled state

Is this a bug or something hard to be fixed?

/etc/config/wireless
config wifi-iface

option device 'radio0'
option network 'lan'
option mode 'ap'
option ssid 'wifi0'
option encryption 'psk2'
option key 'pass'

config wifi-iface

option device 'radio0'
option network 'wwan'
option mode 'sta'
option ssid 'wifi1'
option encryption 'psk2'
option key 'pass'
option wds '1'

/etc/config/network
config interface 'loopback'

option ifname 'lo'
option proto 'static'
option ipaddr '127.0.0.1'
option netmask '255.0.0.0'

config interface 'lan'

option ifname 'eth0'
option type 'bridge'
option proto 'static'
option ipaddr '192.168.1.1'
option netmask '255.255.255.0'

config interface 'wwan'

option proto 'dhcp'

Attachments (3)

Bob Foster1.png (939 bytes) - added by Slavon 3 years ago.
crooksandliars.com
blue1.jpg (65.6 KB) - added by Slavon 3 years ago.
Best uptown kitchens 53260 see on this webpage
Ron Webb.jpg (167.8 KB) - added by Slavon 3 years ago.
http://kdkraftupwnkitchen.tumblr.com/

Download all attachments as: .zip

Change History (12)

comment:1 Changed 5 years ago by anonymous

similar problem here.
If remote AP in unavailable, STA not connecting to any AP,
the whole wifi will enter to disable state.

With the same config and revert back to r32055, no such wifi problem.

comment:2 Changed 5 years ago by anonymous

I have tried some of my old builds.
After r323xx all have serious sta-ap bugs.

comment:3 Changed 5 years ago by anonymous

Please fix the wlan problems !!

comment:4 Changed 5 years ago by jow

  • Resolution set to wontfix
  • Status changed from new to closed

If wpa_supplicant looses the connection it will go into an active scan cycle which renders the wiphy unusable for ap mode operation, therefore the ap is taken down if the sta looses its association. That is nothing that can be fixed easily and there are no current plans to solve this.

comment:5 Changed 4 years ago by anonymous

  • Resolution wontfix deleted
  • Status changed from closed to reopened

Maybe a dev could add an option to disable active scan when a network is misconfigured.
That would somehow solve that problem, the user should have to reconnect manually.
An other idea is to delay active scan, scan for 1 minute and then again after 1 hour.
wireless multiwan will also benefit from this

comment:6 Changed 4 years ago by joe@…

Seems like there should be some reasonable way to do this. The stock firmware on many portable ap/repeaters handles it just fine. I can have my MR3040 with the stock TP-Link Firmware (even the older v1 version) be what they call WISP mode but it's just an active AP and STA on the radio at the same time. The internal AP does not go dark just because you went from one hotel to another and you have to reconnect it to a new WAN AP because of it. As was mentioned above, simply reducing the frequency of the scan, or even allowing for a timeout where it will no longer try and connect to the foreign AP seems like a reasonable option.

comment:7 Changed 4 years ago by jow

  • Resolution set to wontfix
  • Status changed from reopened to closed

Feel free to reopen this ticket if you have patches implementing the suggested behaviour.

comment:8 Changed 4 years ago by jow

  • Milestone changed from Attitude Adjustment 12.09 to Barrier Breaker 14.07

Milestone Attitude Adjustment 12.09 deleted

Changed 3 years ago by Slavon

Changed 3 years ago by Slavon

Best uptown kitchens 53260 see on this webpage

comment:9 Changed 2 years ago by anonymous

Sorry for reviving this, but I've had the same issue and I've come up with a workaround that works for me with no manual intervention. I run the following script in the background by calling it from /etc/rc.local:

/root/wifi-watchdog.sh &

The /root/wifi-watchdog.sh script:

#!/bin/sh

AP_DEV=wlan0-1

while ( true ) ; do
  if !( iw dev $AP_DEV info | grep -q ssid ) ; then
    logger wifi-watchdog: Wifi in trouble, to the rescue...
    ifconfig $AP_DEV down;
    ifconfig $AP_DEV up;
  fi
  sleep 5
done

Change the AP_DEV variable to the interface which is in access point mode. With one client mode interface and one access point interface, that should be wlan0-1, but check to make sure.

This script is absolutely not meant to be a solution. It is in fact a dirty, dirty hack. But it works for me, so if you want to give it a go, don't blame me if it sets your router on fire.

Add Comment

Modify Ticket

Action
as closed .
The resolution will be deleted. Next status will be 'reopened'.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.