search

OpenELEC / OpenELEC.tv

OpenELEC - The living room PC for everyone
http://openelec.tv
1.61k stars 881 forks source link

4.2.1, rpi: wifi no longer connecting automatically #3536

Closed thelmstedt closed 9 years ago

thelmstedt commented 10 years ago

Running 4.2.1, with a rpi. Previously wifi was coming up as part of boot, was fine in < 4.2.1

OpenELEC:~ # uname -a Linux OpenELEC 3.16.3 #1 PREEMPT Sat Oct 4 09:49:44 CEST 2014 armv6l GNU/Linux

OpenELEC:~ # lsusb Bus 001 Device 005: ID 04d9:1818 Holtek Semiconductor, Inc. Bus 001 Device 004: ID 148f:5370 Ralink Technology, Corp. RT5370 Wireless Adapter Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp. SMSC9512/9514 Fast Ethernet Adapter Bus 001 Device 002: ID 0424:9512 Standard Microsystems Corp. SMC9512/9514 USB Hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Pertinent bits of dmesg: ... [ 10.577221] usb 1-1.2: reset high-speed USB device number 4 using dwc_otg [ 10.681609] ieee80211 phy0: rt2x00_set_rt: Info - RT chipset 5390, rev 0502 detected [ 11.025730] ieee80211 phy0: rt2x00_set_rf: Info - RF chipset 5370 detected [ 11.034982] ieee80211 phy0: Selected rate control algorithm 'minstrel_ht' [ 11.058400] usbcore: registered new interface driver rt2800usb ... [ 13.901560] ieee80211 phy0: rt2x00lib_request_firmware: Info - Loading firmware file 'rt2870.bin' [ 13.940657] ieee80211 phy0: rt2x00lib_request_firmware: Info - Firmware detected - version: 0.29 [ 14.482521] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready

...Manually connecting later..

[ 165.833555] wlan0: authenticate with 20:4e:7f:91:66:0b [ 165.883919] wlan0: send auth to 20:4e:7f:91:66:0b (try 1/3) [ 165.888433] wlan0: authenticated [ 165.897036] wlan0: associate with 20:4e:7f:91:66:0b (try 1/3) [ 165.901202] wlan0: RX AssocResp from 20:4e:7f:91:66:0b (capab=0x431 status=0 aid=5) [ 165.912733] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready [ 165.916718] wlan0: associated

thelmstedt commented 10 years ago

Full dmesg: http://sprunge.us/QCJb

OpenELEC:~ # journalctl --no-pager -b -0 | pastebinit http://sprunge.us/QALb

stefansaraev commented 10 years ago

this is a bug with connman when a technology is manualy disabled via OE settings addon and then re-enabled. it also affects ethernet, not only wifi. this also affects 5.0 betas. I confirm that. unfortunately I have no idea whats wrong. last time I could reproduce /storage/.cache/connman/ethernet_*_cable/settings looked just fine to me..

that means something is VERY broken, either in connman, or in OE settings addon.

rm -rf /storage/.cache/connman && sync && reboot then reconfiguring the connection helps (at least for wired)

//ping @sraue try reverting connman to 1.25 or 1.24 and make a beta testbuild for @thelmstedt //cc @lfiebach

both 4.2.0 and 4.2.1 have connman 1.25, so did something change in our settingsaddon @sraue ?

stefansaraev commented 9 years ago

can you still reproduce with oe beta3 ?

one just reported in irc that it's now fine (of course, after removing .cache/connman)

lonewasp commented 9 years ago

Had similar problems with Wifi connectivity since 4.2 and on 4.97.2/3 - The problem varied from unreliable DHCP over Wifi to inability to connect to new Wifi router (TP-LINK 941ND on latest official firmware). Haven't tried clean 5.0, but rebuilt 5.0 with the following patch for connman-1.27 helped (removes one of the changes introduced after conman used in OE 4.0.7):

diff --git a/gdhcp/client.c b/gdhcp/client.c index ec61731..7f21c5c 100644 --- a/gdhcp/client.c +++ b/gdhcp/client.c @@ -490,8 +490,6 @@ static int send_request(GDHCPClient *dhcp_client) dhcp_add_option_uint32(&packet, DHCP_SERVER_ID, dhcp_client->server_ip);

- dhcp_add_option_uint16(&packet, DHCP_MAX_SIZE, 576);

    add_request_options(dhcp_client, &packet);

    add_send_options(dhcp_client, &packet);
stefansaraev commented 9 years ago

@lonewasp unfortunately this does not fix the issue here

I have a wired network. right from fresh install it works:

[ethernet_00252288b496_cable]
Name=Wired
AutoConnect=true
Modified=2015-01-09T17:29:59.761212Z
IPv4.method=dhcp
IPv4.DHCP.LastAddress=192.168.0.5
IPv6.method=off
IPv6.privacy=disabled

after switching to static:

[ethernet_00252288b496_cable]
Name=Wired
AutoConnect=true
Modified=2015-01-09T17:30:37.599143Z
IPv4.method=manual
IPv4.DHCP.LastAddress=192.168.0.5
IPv6.method=off
IPv6.privacy=disabled
IPv4.netmask_prefixlen=24
IPv4.local_address=192.168.0.5
IPv4.gateway=192.168.0.1
Nameservers=192.168.0.1;

it still works. but after switching back to dhcp and rebooting:

[ethernet_00252288b496_cable]
Name=Wired
AutoConnect=true
Modified=2015-01-09T17:31:33.216684Z
IPv4.method=dhcp
IPv6.method=off
IPv6.privacy=disabled
IPv4.netmask_prefixlen=24
IPv4.local_address=192.168.0.5
IPv4.gateway=192.168.0.1
IPv4.DHCP.LastAddress=192.168.0.5

bam. it fails to auto connect. note the IPv4.netmask_prefixlen IPv4.local_address IPv4.gateway opts in the profile. those are still there after switching back to dhcp and it looks like connman is confused by its own config data. if I manualy remove those and reboot - it can autoconnect on boot just fine.

dhcp in connman is borked as hell. also dhcpv6 (#3746)

I will try to bisect connman this weekend if I have time..

and well //ping @pfl :)

lonewasp commented 9 years ago

Your case sounds like either connman is reading config incorrectly or OpenELEC settings plugin is messing up with config file - not wiping out static setting correctly.

My case a bit different - I never had static config. After update to 4.2.0 Wifi connection started to fail to get DHCP stuff setting up link local address (Wifi ssid and key remebered since 4.0.7 that worked flawlessly). Couple of manual reconnects to Wifi and normal config was obtained... (TP-Link 1043ND with OpenWRT). At that time I had a quick glance on conman changes between version and the only suspicious line was in my fix, though never had time to test it. Recently I gave away RPi as a mediacenter and tried latest 4.97.2/3 it connected ok to my router, but failed against new one TP-Link 941ND with native firmware - I guess due to DHCP failure it is kicking off full Wifi config connect. I'll try official 5.0 to see if problem persists without fix, but I see in 4.97.3 release notes that it uses connman 1.27 same as 5.0 release.

stefansaraev commented 9 years ago 
e22ad5f161a487afc41d12ab630a536cbfa3e2a7 is the first bad commit
commit e22ad5f161a487afc41d12ab630a536cbfa3e2a7
Author: Patrik Flykt <patrik.flykt@linux.intel.com>
Date:   Tue Apr 22 11:21:48 2014 +0300

    dhcp: Restart existing DHCP client with __connman_dhcp_start()

    Check whether the dhcp structure already exists when calling
     __connman_dhcp_start() and initialize callbacks and other data
    only on newly created objects.

    As dhcp_request() now handles initialization, rename it to
    dhcp_initialize().

:040000 040000 099a22e73e02b5bbb8995824fb8e50b0cd060dc7 b46e0caef0d5d04c8690bd1f64911c1e75567eaf M      src

I will revert connman to 1.23

stefansaraev commented 9 years ago

@lonewasp if you can self build, could you pls test #3765 ?

lonewasp commented 9 years ago

I will make build on Monday, but not sure when I'll get a chance to deploy it...

stefansaraev commented 9 years ago

@lonewasp then dont. it will be merged before that :)

stefansaraev commented 9 years ago

should be fixed in 01bf6480e8a0a13089f41ed28a9055295066baa0

pfl commented 9 years ago

Whan an external application configures ConnMan, it would be advisable to use the .config file format, http://git.kernel.org/cgit/network/connman/connman.git/tree/doc/config-format.txt, if possible. It is a supported API and not at all as picky on the correctness of the ConnMan internal save files. Those save files should not be touched by anybody else except ConnMan itself.

There are also important DHCP broadcast/unicast flag handling workarounds in 1.26, helps quite a lot in with weird cases where no DHCP server messages are seen. Don't know if it is one of the causes behind this bug, though.

stefansaraev commented 9 years ago

we dont touch any config files manualy. configuring connman only via dbus.

EDIT: and to be more specific: https://github.com/OpenELEC/service.openelec.settings/blob/master/src/resources/lib/modules/connman.py it's part of our "settings addon" - a GUI to configure network, bluetooth, and few services like samba / ssh

javier-lopez commented 9 years ago

I just tested the latest connman git version and it seems solved now, specifically by commit 3ac3eb, https://www.mail-archive.com/connman@connman.net/msg17191.html