Wifi issues

[gamut]

Why does wifi not work on a two not-so-recent Eee PCs (including 1015)
using so many of the builds? I don't mean to be crude, truly, but
shouldn't this be issue #1 for a cloud-ish OS with a stated target of
the Eee PC as a hardware platform? Can someone please help? I'd love
to install this and try it, heck, even donate. But I find it really
hard to do anything considering the very base function of Android
doesn't work. Are there Eee PCs with cellular chips out there that I
should have bought instead?

Please don't bother with the flame replies, I know I'm out of line.
However, this seems like it would be a humongous community turn-off to
basically limit use of this release to only those willing to recompile
sources on their own machines, or tinker with app-less screen candy.

I've tried 4.0, as well as all the 3 and 2 releases, and both eeepc
and asus_laptop builds. I'm tired, and moved onto MeeGo for the time
being. The wireless works there, despite the user experience being
grossly inferior.

[Mike C]

Strange, I use android-x86 3.2rc2 for eeepc on an AAO 110 ZG5 (so not
even a real eeepc) and wifi works great. Android-x86 is really rearing
the stat of a fully functioning system with the main important
elements all working. It should work on your system too. Perhaps
something went wrong during creating your install?

Mike

[Chih-Wei Huang]

There are too many EeePC variants.
What model do you have?
Especially, what the driver it used in Meego?
(show us the output of 'lsmod')

2012/1/4 gamut <woj...@grabski.ca>:

--
Chih-Wei
Android-x86 project
http://www.android-x86.org

[Muldy]

Same here ( android-x86-4.0-eeepc )

I have a EEEpc 901, wifi keeps disconnecting/connecting

Was working correctly before the last two android-x86-4.0-eeepc releases.

[Muldy]

PS:

WIFI works as expected in xubuntu.

Will provide lsmod output when i get home

[Kiet]

I did have this problem for a while with wifi. It seemed to be related
to Android/Linux wifi stack handling WEP. Since I changed my router
to WPA2-Personal, wifi seemed to be stable on my EEEPC running
honeycomb-x86.

I did not verify my hypothesis. Please check and try this.
Kiet

[gamut]

Not sure if my previous post went through. lsmod shows brcm80211 on
meego and atl1c for wired. Thank you for the help, though I hope you
can arrive at a more comprehensive solution for other users who don't
have the time or know-how to re-build kernels (I can't even do it at
all, I have a case-insensitive filesystem on my mac).

Best.

[gamut]

I'm running WPA2 only. Thanks for the suggestion.

[gamut]

Thank you for the helpful reply, I appreciate it.

lsmod on meego shows brcm80211 for wifi and atl1c for wired. I didn't
see any broadcom modules in the drivers folder on android-x86-eeepc.
So I suppose it's missing from there entirely.

I do want to stress that though I'm probably capable to get myself
going with your assistance, this recurring wifi issue is really
something that is highly negative for this project. One can only
guess at how many other people are spending their nights downloading
and installing 4 or 5 iso builds, then giving up and moving onto
something else. The most frustrating part for those of us who used to
rebuild kernels back in the red hat 3 days, is that we thought those
days were behind us. It seems to me that since every single other
build of anything seems to work, that the issue here has something to
do with the build target configuration process itself, perhaps you
need to go more generic? I didn't have to download an Eee PC meego
build. Why not? And why do I have to do this on android-x86?

Thanks.

[dscm]

kernel/drivers/staging/brcm80211

[gamut]

Thanks, but why doesn't it show up in the drivers folder after it's
booted? Only some builds?

[dscm]

android-x86/android are platform specific...IMO

so if it's not enabled for your specific platform then it
needs to be configured in and/or if it's configured and
doesn't work notifiy the dev/maintainer...

[Yi Sun]

Part of your statement is Not true.
Android is designed for specific platforms and it has removed common
device auto detection like ubuntu and meego have, but android-x86 is
trying to change it.
I guess at the moment, we don't mind to turn on all the kernel modules
but there are still issues need to be solved. Especially, enabling
stagging drivers without a full test may not be a good thing, since
stagging means unstable.

So we need to have someone to collect correct firmware/driver/hardware
combinations and update our source code and build system correctly.
Sometimes, a source code update may not be legal, so we may have to just
document the instructions in the wiki. We may also need to improve our
auto detecting method so that we can detect the device correctly

The wifi devices are the people complained most. And almost all the
complains are triggered by buggy driver, incompatible firmware (or even
no firmware or no driver). To find right driver version with right
firmware version on right hardware requires a lot test
combinations/resources. People try to compare our system with ubuntu or
meego, but keep in mind, they are backed by large companies with a few
thousand people working on it. For us, the most active developer is
Chih-wei--one person. So, please help.

@gamut, To help on the current issue, I suggest you to find what are the
driver/firmware and the versions for your device used by meego or
Ubuntu. Also collect the hardware detail (submit all the dmi output from
/sys/class/dmi/id/ and send to us. You may complain about you have
already told us your device type (eg, eeepc 901 or something like that).
But only old eeepc 901 with different hardware releases, it can use
totally different components, so the dmi info may help us to identify
the device correctly.

Yi

[jetson224]

Same for me on an 1001P Asus eeepc. Got an Atheros AR2427 wifi chip
in it here and can't switch wifi on ... more about the hardware when i
get meego down on a stick.

What I can say so far: Wifi works up to Andriod 2.2 R2 image, but
seems to be broken in 3.2 and ICS 4.0.

[Muldy]

My wifi card:

on xubuntu: athk5

Atheros AR242X /AR242X

[Yi Sun]

This thing supposed to work. If I remember it right, it is the first
wifi device we ever made it work. Ok, it's time to find out what has
been changed

> --
> You received this message because you are subscribed to the Google
> Groups "Android-x86" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/android-x86/-/iL1rFRBES68J.
> To post to this group, send email to andro...@googlegroups.com.
> To unsubscribe from this group, send email to
> android-x86...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/android-x86?hl=en.

[dscm]

on Dec. 25th
* upgrade to ics-mr1 (4.0.3)
* hybrid iso format (i.e., you can dd the iso to a usb directly)
* experiment renderscript support (builtin livewallpers now work)
* enable audio

on Jan. 1
* Browser fix
* 10 min "crashing"

pre 12-25 wifi was working fine, after that it's been broke for
many...


so as I suggested in another thread...

go back to the pre 12-25-11 version...

* DO NOT upgrade to ics-mr1 (4.0.3)
* include browser patch
* enable audio

and go from there....

small steps sparks...small steps

from Contact(the movie) by Carl Sagan

[Ibidem]

Aspire One (AOA150 aka ZG5)
AR5007 (detected as AR2425-same PCI ID)
I used the nightly generic ISO, from Jan 1.
Kernel detected device, loaded ath5k (good...)
netcfg detected interface wlan0 (good...)
wireless GUI failed to detect wifi & unloaded the driver, regardless
whether I used it before or after following steps: (VERY bad)

so I got a static iwmulticall (built on Ubuntu w/ -static added to
CFLAGS), put up the interface,
manually connected (worked) & ran netcfg dhcp wlan0
At this point, an IP was obtained, but nameservers weren't working
(bad)
so I manually specified dns1 & dns2 via setprop, which finally gave
successful lookups
At this point, Browser would load any web page, but as the first page
was rendering (I could actually read the web page at this point), it
would pop up an error about not being able to load the page because it
wasn't connected to the internet (WHAT ON EARTH?! How does anyone come
up with this sort of setup?).
I clicked OK, & it worked fine until I had to restart Browser (IE,
first web page is the only one to get this behavior, but it occurs on
both cold & warm starts).

The router has two VAPs, one WEP (used for this test--I'd need
wpa_supplicant for WPA), the other WPA.

[Yi Sun]

The dhcp was not run on your wlan0. I'm not sure if generic iso has that
in the init.rc or not. But you may try the Acer build made by someone in
the list. Just search the list for detail.

On 01/05/2012 05:01 PM, Ibidem wrote:
> Aspire One (AOA150 aka ZG5)
> AR5007 (detected as AR2425-same PCI ID)
> I used the nightly generic ISO, from Jan 1.
> Kernel detected device, loaded ath5k (good...)
> netcfg detected interface wlan0 (good...)

> wireless GUI failed to detect wifi& unloaded the driver, regardless

> whether I used it before or after following steps: (VERY bad)
>
> so I got a static iwmulticall (built on Ubuntu w/ -static added to
> CFLAGS), put up the interface,

> manually connected (worked)& ran netcfg dhcp wlan0

> At this point, an IP was obtained, but nameservers weren't working
> (bad)

> so I manually specified dns1& dns2 via setprop, which finally gave

> successful lookups
> At this point, Browser would load any web page, but as the first page
> was rendering (I could actually read the web page at this point), it
> would pop up an error about not being able to load the page because it
> wasn't connected to the internet (WHAT ON EARTH?! How does anyone come
> up with this sort of setup?).

> I clicked OK,& it worked fine until I had to restart Browser (IE,

> first web page is the only one to get this behavior, but it occurs on

> both cold& warm starts).

[Ibidem]

On Jan 5, 7:15 pm, Yi Sun <beyo...@gmail.com> wrote:
> The dhcp was not run on your wlan0. I'm not sure if generic iso has that
> in the init.rc or not.

Not run by the wireless GUI, or not run by manually running "dhcpcd
wlan0" and/or "netcfg dhcp wlan0" (what I did in manually connecting)?

>But you may try the Acer build made by someone in
> the list. Just search the list for detail.

I searched, and couldn't find anything newer than Honeycomb (http://
www.ceh-photo.de/blog/?p=417)
I'd been hoping for Ice Cream Sandwich; some of the changes were ones
that made Android sound interesting for the first time. But then,
after trying ICS, I found quite a few more things missing (X11, middle-
click paste, left-drag select, a full CLI environment...and I like CUA
interfaces!), so I'll probably just stick with Linux.

By the way, no, it's not anything like the Iconia: it's an Atom N270
(hyperthreading), i915-supported graphics at 1024x600x24, etc. More
like an Eeepc than anything else, AFAIK.

[gamut]

Thanks, that Yi Sun, that explains a lot. I suppose the only
suggestion I would still make is to ditch the hardware-specific
builds. I suspect that having a larger and larger driver base would
be a plus as each vendor tries this or that controller. I often see
posts of some person complaining about a driver not working on 'their'
build, but working perfectly on another. Would it not save time to
make one build and the one, ever expanding, basket of drivers captures
whatever variant of controller is found?

On Jan 4, 3:42 pm, Yi Sun <beyo...@gmail.com> wrote:
> Part of your statement is Not true.
> Android is designed for specific platforms and it has removed common
> device auto detection like ubuntu and meego have, but android-x86 is
> trying to change it.
> I guess at the moment, we don't mind to turn on all the kernel modules
> but there are still issues need to be solved. Especially, enabling
> stagging drivers without a full test may not be a good thing, since
> stagging means unstable.
>
> So we need to have someone to collect correct firmware/driver/hardware
> combinations and update our source code and build system correctly.
> Sometimes, a source code update may not be legal, so we may have to just
> document the instructions in the wiki. We may also need to improve our
> auto detecting method so that we can detect the device correctly
>

> Thewifidevices are the people complained most. And almost all the

> >>>> lsmod on meego shows brcm80211 forwifiand atl1c for wired.  I didn't

> >>>> see any broadcom modules in the drivers folder on android-x86-eeepc.
> >>>> So I suppose it's missing from there entirely.
> >>>> I do want to stress that though I'm probably capable to get myself

> >>>> going with your assistance, this recurringwifiissue is really

> >>>> something that is highly negative for this project.  One can only
> >>>> guess at how many other people are spending their nights downloading
> >>>> and installing 4 or 5 iso builds, then giving up and moving onto
> >>>> something else.  The most frustrating part for those of us who used to
> >>>> rebuild kernels back in the red hat 3 days, is that we thought those
> >>>> days were behind us.  It seems to me that since every single other
> >>>> build of anything seems to work, that the issue here has something to
> >>>> do with the build target configuration process itself, perhaps you
> >>>> need to go more generic?  I didn't have to download an Eee PC meego
> >>>> build.  Why not?  And why do I have to do this on android-x86?
> >>>> Thanks.
> >>>>> What model do you have?
> >>>>> Especially, what the driver it used in Meego?
> >>>>> (show us the output of 'lsmod')
> >>>>> 2012/1/4 gamut<woj...@grabski.ca>:

> >>>>>> Why doeswifinot work on a two not-so-recent Eee PCs (including 1015)

[stiltzkin]

I'd like to add my hardware to this list because I, too, can not get wireless working at all, and it's very frustrating. It is more or less the only problem preventing me from using Android - almost everything else works, including hardware acceleration, camera, bluetooth, etc. I have an eeePC 1018P with a Broadcom BCM4313 onboard.

Here is the relevant portion of lshw from my Ubuntu installation. lspci reports:

02:00.0 Network controller: Broadcom Corporation BCM4313 802.11b/g/n Wireless LAN Controller (rev 01)

So I believe this card is handled by the previously-mentioned brcm80211, or more specifically, brcmsmac. As dscm pointed out, this appears to be included in the default kernel. I've tried compiling my own image with the relevant lines uncommented in eeepc_defconfig, but to no avail. I simply don't understand enough of how Android handles wireless drivers to know what the problem here is. But it seems to have something to do with this driver not getting loaded properly.

If I can provide any more information that will assist in getting this fixed, please let me know. This project is pretty amazing otherwise and cwhuang has done some impressive work - it's a shame to have it all go to waste because of a broken driver.