Wifi Hotspot

[amanharitsh123]

Made the necessary changes to start wifi ap at boot .

• Update 1 : Testing Script , build is in progress
• Update 2 : Hotspot starts after the boot but disconnects after some time , any attemp to connect again results in authentication failure
• Update 3 :

1. Issue #8 Exists only in the first run of the image . after a reboot it disappears and wifi hotspot works perfectly .
2. Issue #9 After a reboot it almost take a minute for iptables to load . Hence ethernet bridging works after 1-2 min of starting hotspot.
3. So , Everything works fine after the first successful run of 1 hour.

[quozl]

Thanks, reviewed.

da6eb3e,

• heavy-handed approach of using a generic out-of-tree network management facility has risks; many of the restarts are not necessary and waste time, ifconfig is deprecated, it should be simpler just to configure wpa_supplicant.conf, and use systemd directly, that said;
• typo hostpot.log should be hotspot.log,
• first line of hotspot.sh should reference /bin/bash because of the use of $() syntax,
• your script.sh and hotspot.sh are set by rc.local to execute simultaneously, and the network transitions by hotspot.sh will disrupt the network requests of script.sh,
• you are using a fixed passphrase and have made it public; this is a security risk.

70138dc,

• your change to using /bin/bash is not necessary if (a) first line of hotspot.sh contains /bin/bash, (b) chmod +x hotspot.sh, and (c) rc.local runs the script directly rather than prefix with bash, (mentioned this already in your prior pull request, and you did not respond; perhaps you don't yet know how scripts can be executed using their self-described interpreter).

Hope that helps! Let me know if you have any questions.

[amanharitsh123]

da6eb3e

• The script I am using to start and setup hotspot , practically does the same thing as suggested by the most of hotspot setup tutorials I have found. Although after running "ap" command once , hotspot starts automatically after any reboot but it cant throw an IP to the devices . All I can find for this is a temporary fix , that is to restart the services after every boot. Therefore I added the "ap" command to the rc.local file.

• Thanks , I will fix that.

• Earlier I had some confusions regarding the method to invoke a script. I get it now and will make the suggested changes soon .

• Yes it could , may be I should run the hotspot.sh after the completion of script.sh

• I will add it to the instructions in README.md to change the default passphrase before building.

70138dc,

• Sorry I didnt responded earlier , because I didnt have a clear view at that time . I will make the suggested changes soon

Authentication Problem still exists , Do you have any suggestions to fix this ?

[quozl]

Yes, there are many tutorials, often using heuristic rather than analytical techniques. You are using now a recent systemd and the documentation for it should be considered rather than tutorials that were intended for older releases. It is best to do the minimum necessary, rather than add steps that are not tested. Result will be efficient and quick.

Diagnose the authentication problem further. Access the system using local keyboard and display, or serial port, or ethernet, and check the network interface configuration for the wireless device. Check the logs written to by the rc.local. Try repeating the ap command by hand. My guess is that something in the network management facility you've used may not have been tested with the most recent systemd packages from Debian.

[amanharitsh123]

@quozl I have made some interesting observations

• Issue #8 Exists only in the first run of the image . after a reboot it disappears and wifi hotspot works perfectly .

• Issue #9 After a reboot it almost take a minute for iptables to load . Hence ethernet bridging works after 1-2 min of starting hotspot.

[quozl]

Interesting, thanks.

Issue #8 Exists only in the first run of the image . after a reboot it disappears and wifi hotspot works perfectly .

As you have both docker initialisation and install of your network management facility happening at the same time; they are probably competing for the same CPU and memory resources, slowing each other down.

it almost take a minute for iptables to load . Hence ethernet bridging works after 1-2 min of starting hotspot.

It should not take that long. An average iptables loading should take no more than a few milliseconds. You could diagnose further; add timestamps to your logs, find which command is causing the delay.

Is another reason to use the absolute minimum of commands. Many of the services are restarted without justification; many services know to re-read configuration files or detect network interface transitions.

[amanharitsh123]

@quozl I think that the reason behind the delay is the access speed of my SD card . I am using a class 4 8GB sd card. After every boot, docker containers boots up .I think they cause some decent amount of load on SD card . Hence , network setup experiences delay .

[quozl]

Certainly the SD card can become a point of contention in any attempt to do simultaneous operations; which is why doing unnecessary operations (such as stopping and starting network services) should be avoided. You can monitor /proc/diskstats to measure the length of the request queue at intervals during boot. Class 4 only refers to write request speed, and has to do with the program running on the CPU of the microSD card and the Flash cell array beyond it. Do your best to avoid writes; avoid unnecessary operations, and use a tmpfs for any file that does not need to be saved. While the FTL is doing a write to the array, it cannot do a read, so a read is queued.

[quozl]

Reviewed to 20c906a. "keep the Rpi running for an hour" may be frustratingly inexact. It will depend on internet speed, microSD card class, and how new the microSD card is (they get slower as they age).

You're targeting Raspberry Pi 3, aren't you? If so, you can provide a limited user interface to indicate progress of the docker setup on the two built-in LEDs.

There's a green LED and a red LED. These can be changed from their default purpose to some other purpose. For example on a Raspberry Pi 3 to be used in complete darkness, my rc.local ends with;

# turn off the lights
echo default-on > /sys/class/leds/led0/trigger
echo default-on > /sys/class/leds/led1/trigger

echo oneshot > /sys/class/leds/led0/trigger
echo oneshot > /sys/class/leds/led1/trigger

You can cat the trigger file to find the options, and read the kernel documentation for the LED class driver for more details on the option formats. You can communicate state using different blink rates;

• one red blink every five seconds, docker setup,
• one green blink every second, finished, ready to go, please connect.

You should experiment to find something appropriate.

Hope that helps!

[amanharitsh123]

@quozl Thanks a lot for such a great idea to use LEDs. I would like to inform you that , rpi image is not using internet for anything. All the docker packages and images are already added in the image , docker will only load those images and will make containers.

[quozl]

Oh! Why not make docker load those images and make containers before writing to the final image?

[amanharitsh123]

@quozl I was having trouble executing them in chroot environment :\

[quozl]

Best to resolve that trouble. qemu should be used to execute not only in the chroot, but in a processor environment that matches the installed binaries.

[amanharitsh123]

This https://github.com/drtyhlpr/rpi23-gen-image script has a parameter to add a directory which can contain scripts that should be run inside chroot . I think that will work , what do you think?

[quozl]

I'm not trying it for you. You should experiment. :grin: Yes, you can add custom scripts, as you have already done. Read and understand the existing scripts. bootstrap.d/11-apt.sh for example installs packages in the context of both chroot and qemu.

If there was a way to make a .deb file with what you need, then the debian/postinst script could do everything needed during 11-apt.sh.

[amanharitsh123]

Thanks a lot for the suggestions :) .

On Tue, Jun 12, 2018, 2:12 PM James Cameron notifications@github.com wrote:

I'm not trying it for you. You should experiment. 😁 Yes, you can add custom scripts, as you have already done. Read and understand the existing scripts. bootstrap.d/11-apt.sh for example installs packages in the context of both chroot and qemu.

If there was a way to make a .deb file with what you need, then the debian/postinst script could do everything needed during 11-apt.sh.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/amanharitsh123/sugarizer-school-box/pull/6#issuecomment-396513218, or mute the thread https://github.com/notifications/unsubscribe-auth/ARKnBKOJ0hGQT-x-JZr9rT2SeKXEAbqzks5t738OgaJpZM4UhmWP .

[amanharitsh123]

@quozl I think making the led to blink to show docker install progress is unnecessary as during the docker load , the green led is running almost continuously because there is heavy load on sdcard. We can mention this in the readme , For ex. Reboot the Rpi after green light turns off.

[quozl]

Your 5a9d701 removed the ap command after the ifconfig. Perhaps you didn't intend that.

Your 5a9d701 shows a need for configuration variables, so that the SSID and passphrase can be set in one place rather than having to be changed in two places.

Your 0b0fbac does delete all lines containing bash in rc.local. Perhaps you didn't intend that.

It is difficult to keep track of the transitions with "self-modifying code", and this is another justification for using filesystem markers instead, for example;

#!/bin/bash -e
[ -e /var/lib/sugarizer-school-box-setup-done ] && exit 0
# ... do the setup steps ...
touch /var/lib/sugarizer-school-box-setup-done
exit 0

Paraphrasing; only do the setup steps if the marker file is missing, then create the empty marker file. On next reboot, the conditional statement will be true and an early exit taken. This also means that if the device loses power or fails during the setup steps, they should be repeated next time.

That said, it is best to work toward completing all setup steps before writing the image.

[amanharitsh123]

@quozl I have added script for status led and I am experimenting on optimization part. PS: Till now the image works , shall I merge this PR?

[quozl]

Reviewed to 287dd34.

Merge whenever you like.

[amanharitsh123]

Everything seems to work perfectly now , Merging the PR.