edison-fw / meta-intel-edison

Here is the meta-intel-edison that builds, tries to stay up to date. Master is based on Yocto Poky Gatesgarth LTS 5.10.yy vanilla kernels. It builds a 32bit kernel (Gatesgarth branch 64bit) with ACPI enabled and corresponding rootfs. Telegram group: https://t.me/IntelEdison Web-site:
https://edison-fw.github.io/meta-intel-edison/
MIT License
60 stars 38 forks source link

Fix hostapd conf path - main #31

Closed alext-mkrs closed 6 years ago

alext-mkrs commented 6 years ago

This is the main part of the fix for #24 (the second one is in https://github.com/edison-fw/edison-oobe/pull/1). I've corrected the hostapd.conf paths in those scripts and switched to using our copy of the edison-oobe repo.

Build-tested on current master.

htot commented 6 years ago

Note: I removed lots of stuff from postinstall, maybe even too much in commit b38c0fe Also, I think yocto added a postinstall system, and we might consider moving our stuff there and removing this one. I rebased this PR on top of sumo32. Building resulted in the following warning (harmless?): [log_check] warning: TCG doesn't support requested feature: CPUID.80000001H:EDX.lm [bit 29]

To test I unblocked wifi, disabled wpa_supplicant and started hostapd

rfkill unblock 0
systemctl stop wpa_supplicant
systemctl stop hostapd

On my phone open network EDISON-4D-70 appears. I believe with the factory image you have a closed network and need to use the serial number as password? When I try to connect it fails after for not receiving a network address.

lybtongji commented 6 years ago

@htot You need a DHCP server (like dnsmasq) to give IPs.

For example:

dnsmasq -k -p 0 -x /var/run/dnsmasq.pid -i wlan0 -F wlan0,192.168.1.2,192.168.1.10,12h -O wlan0,3,192.168.1.1 
alext-mkrs commented 6 years ago

So this PR is for fixing just the path itself - as it was breaking the postinstall script (and your earlier cleanup didn't touch that part, which is IMHO good, as it's useful).

Now if the hostapd actually doesn't fully work (at least partially it does - the network is created as you see), that needs to be fixed separately, after this one is merged.

That bitbake warning is a 32bit build artifact I believe (I saw it when testing the sumo swithcing PR), has nothing to do with this change (and it really cannot technically cause it due to the nature of the change). Looks like it's from some qemu log probably being run as a part of building some [of the] package[s]. I believe it's harmless, it apparently says that it doesn't see https://en.wikipedia.org/wiki/Long_mode capability in CPUID and as we're building 32bit image, that's expected.

alext-mkrs commented 6 years ago

Oh and the lack of passphrase is indeed because of that cleanup, now I see it :)

/factory/serial_number stored the serial number and it got removed in https://github.com/edison-fw/meta-intel-edison/commit/b38c0fec27797b906593091fcb26badb6c526758#diff-6ae83b99829fe64a9082facc28b8538bL70. But we can correct that later.

htot commented 6 years ago

@alext-mkrs Thanks, I didn't mean to criticize, just to summarize as a note to self what I tested and what could be added later.

The patch does what it advertises. So let's go ahead and merge.

@lybtongji Thanks too, unfortunately we currently don't have dnsmasq on the image. I built the deb and installed manually and tried your command. Unfortunately it didn't work. I noticed it creating a systemd dnsmasq.service. And we also have systemd-networkd. Now trying to figure out how that works.

I would like to know what you guys would like to use hostapd for. For me: 1) I have a usb->ethernet port connected. It would be cool to bridge that to wifi. 2) In a iot application, with redundant edisons it would be nice to have peer-to-peer or one hostap / one client as a fallback when ethernet fails.

alext-mkrs commented 6 years ago

@htot, thanks for the review. No offense taken! :) On the contrary, I really appreciate that you flag things you notice - that's the way for us to find them and fix.

As for the hostapd use cases - to be honest I personally have none, so I'm open to all the suggestions/asks people may have. One that was used in the offical image was that initial configuration - out of the box Edison starts in AP mode, so a user can connect to it and configure basic stuff using web interface (as opposed to manually running configure_edison in the console, which is what I used to do, or just doing plain config file editing). We can collect those use cases and try to implement.

I'll merge this one and then look into why the address is not given out, I'd expect it to. Probably something else got swcrewed up along the way or changed behavior due to package version changes. :) The basic idea I have right now is to get back the official image functionality I described above. After that we could look into other use cases and see what it takes to implement them.

htot commented 6 years ago

@lybtongji BTW I managed a DHCP server in the AP. First removed dnsmasq., the created 20-wlan-dhcp.network in /etc/systemd/network with:

[Match]
Name=wlan*

[Network]
#Bridge=br0
DHCPServer=yes
PoolOffset=192.168.1.10
PoolSize=20
Address=192.168.1.1/24
Gateway=192.168.1.1

With this I can connect my phone (as long as it doesn't check the 'network quality' as the gateway doesn't work). I can't create a bridge (yet): br0: netdev could not be created: Operation not supported I think we need to enable kernel support for this first? And @alext-mkrs I was thinking the same on the config server oobe. ~I think it worked with a web server in nodejs. But where is that? Maybe I removed that in the past, with out much consideration.~ I started that with systemctl start edison_config but it is not yet working. Just starting node /usr/lib/edison_config_tools/edison-config-server.js and accesing from my laptop crashes the server:

  if ((result.code != 0) || (result.output.trim() === "Master")) {
                                           ^

TypeError: Cannot read property 'trim' of undefined
    at inWhiteList (/usr/lib/edison_config_tools/edison-config-server.js:349:44)
    at Server.requestHandler (/usr/lib/edison_config_tools/edison-config-server.js:361:8)
    at emitTwo (events.js:126:13)
    at Server.emit (events.js:214:7)
    at parserOnIncoming (_http_server.js:602:12)
    at HTTPParser.parserOnHeadersComplete (_http_common.js:116:23)

I can login using ssh, so at least we know hostapd is working fine.

lybtongji commented 6 years ago

@htot I have no problem with dnsmasq in rocko32. After edison boot into system, I unblock the wlan0 by

rfkill unblock all

Then I run dnsmasq in screen:

screen -S dnsmasq
dnsmasq -k -p 0 -x /var/run/dnsmasq.pid -i wlan0 -F wlan0,192.168.1.2,192.168.1.10,12h -O wlan0,3,192.168.1.1

Then start hostapd in another screen:

screen -S hostapd
hostapd hostapd.conf

Finally, I will see an AP named "test" without password. And I can connect to it directly. IP will be assigned automatically.


To make the network work, you can also try NAT mode like this way:

echo 1 > /proc/sys/net/ipv4/ip_forward # Enable IP Forwarding
iptables -A POSTROUTING -t nat -s 192.168.1.0/24 -j MASQUERADE

I hope the bridge mode can work fine too.

htot commented 6 years ago

I got node /usr/lib/edison_config_tools/edison-config-server.js to work. There are multiple problems: 1) iwlist is installed, but probably compatibility in the kernel is not enabled 2) the modern replacement is not installed in the image 3) manually installing, the output is different, requiring changes to configure_edison 4) shelljs used to have output field, but changed to stdout

I will open a new issue for this.

alext-mkrs commented 6 years ago

Merged.

lybtongji commented 6 years ago

@htot After I added CONFIG_BRIDGE=m to kernel conf file and rebuilt the rocko32 image, hostapd is working fine in bridge mode.

root@edison:~# brctl show
bridge name     bridge id               STP enabled     interfaces
br0             8000.90b6860de3b2       yes             wlan0