Ticket #1074 (closed defect: worksforme)

Opened 5 years ago

Last modified 3 years ago

no wifi function

Reported by: soplaris Owned by: ainulindale
Priority: major Milestone:
Component: SHR Image Version: SHR-testing
Keywords: mokonnect Cc:

Description

hi i'm using latest shr-u and since i upgraded (about 1 week ago) none of the wifi clients (mokonnect, saskia, hotel wifi) can connect to aps. mokonnect does not scan, if i enter data the output is "~trying to power on", nothing happens, second try: "~ device still not found in connman". before the upgrade mokonnect worked for me.

Change History

comment:1 Changed 5 years ago by Heinervdm

  • Milestone set to MS2

comment:2 Changed 5 years ago by Kev

  • Version changed from SHR-unstable to SHR-testing

Hi,

I can confirm this bug on shr-testing.

After update on shr-testing a few weeks before, wlan stopped working.

Some hints for error finding:
Starting mokonnect from console and scan for wireless networks prints the following:

$ mokonnect
/usr/lib/python2.6/site-packages/dbus/connection.py:242: DeprecationWarning?: object.init() takes no parameters

super(Connection, self).init(*args, kwargs)

DeviceClicked?
Wifi device seems to be off, trying to power it on...
Requesting resource WiFi?
killing and re-running connmand
Failed powering on the device or it was still not found in connman.
DONE

Applying a (working in the past before the update) predefined configuration for wlan prints:
DeviceApplyClicked?
Requesting resource WiFi?
Traceback (most recent call last):

File "elementary.c_elementary_object.pxi", line 30, in elementary.c_elementary._object_callback (elementary/elementary.c_elementary.c:4154)
File "/usr/share/mokonnect/mkmenu.py", line 374, in DeviceApplyClicked?

self.current_device.Apply(self.LogEntry?)

File "/usr/share/mokonnect/mkdev_wifi.py", line 417, in Apply

if not self.PowerOn?(log):

File "/usr/share/mokonnect/mkdev_wifi.py", line 371, in PowerOn?

if not self._ConnmanPowerOn(log):

File "/usr/share/mokonnect/mkdev_wifi.py", line 341, in _ConnmanPowerOn

wifi_dev.RequestResource?('WiFi?')

File "/usr/lib/python2.6/site-packages/dbus/proxies.py", line 68, in call

return self._proxy_method(*args, keywords)

File "/usr/lib/python2.6/site-packages/dbus/proxies.py", line 140, in call

keywords)

File "/usr/lib/python2.6/site-packages/dbus/connection.py", line 622, in call_blocking

message, timeout)

DBusException: org.freesmartphone.Usage.UserExists?: Resource WiFi? already requested by user :1.27

starting wpa_supplicant prints:
wpa_supplicant -i eth0 -c /etc/wpa_supplicant/wpa_supplicant.conf -B
ioctl[SIOCSIWENCODEEXT]: Operation not supported
ioctl[SIOCSIWENCODEEXT]: Operation not supported
ioctl[SIOCSIWENCODEEXT]: Operation not supported
ioctl[SIOCSIWENCODEEXT]: Operation not supported

The only working thing is after trying to scan with mokonnect (see above) a "iwlist scan".
This prints all available wlans as it should.

dmesg prints at the end:
[21474744.760000] BMI Get Target Info: Exit (ver: 0x20000059 type: 0x1)
[21474744.815000] AR6000 Reg Code = 0x40000060
[21474751.600000] AR6000 Reg Code = 0x8000033a
[ 1742.295000] channel hint set to 2462
[ 1742.310000] AR6000 disconnected
[ 1742.380000] AR6000 connected event on freq 2462 with bssid 00:15:0c:5c:78:0d listenInterval=100, beaconInterval = 100,

comment:3 Changed 5 years ago by jeremy-list

Could this be connected with #1085? Both appeared at about the same time and could be caused by the same defect in FSO.
I'm pretty sure both bugs are severe enough regressions that the responsible code should never have made it into the 'testing' branch, that's what the 'unstable' branch is for. Especially when there was a working version before.

comment:4 Changed 5 years ago by jeremy-list

Someone with more spare bandwidth than me: please try rolling fsodeviced back to a version from early April. I expect it to fix this bug as well as #1085 and probably won't break anything except airplane mode which doesn't work properly anyway.

comment:5 Changed 5 years ago by jeremy-list

Ok it looks like this bug is actually unrelated to #1085. It disappears if I reflash with the jffs2 image from April 1. However #1085 appears to be an issue with either the kernel or the modules, which I haven't yet rolled back.

comment:6 Changed 4 years ago by otypoks

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

comment:7 Changed 3 years ago by morphis

  • Milestone MS2 deleted

Milestone MS2 deleted

Note: See TracTickets for help on using tickets.