cjimti/iotwifi

Add disconnect endpoint.

cecchisandrone opened this issue · 6 comments

  • I'm submitting a ...

    • bug report
    • feature request
    • support request => Please do not submit support request here, see note at the top of this template.
  • What is the current behavior?
    Killing the iotwifi container, keeps WIFI ssid visible, probably some processes stay alive.

  • If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem

  1. Start with docker run --rm --privileged --net host \ -v $(pwd)/wificfg.json:/cfg/wificfg.json \ cjimti/iotwifi
  2. Hit CTRL+C
  3. Configured WIFI network is still visible by devices
  • What is the expected behavior?
    After killing the container I expect everything cleaned in terms of resources / processes.

  • Please tell us about your environment:

    • Device: Raspberry Pi Zero W
    • OS: Linux raspberrypi 4.9.59+ #1047 Sun Oct 29 11:47:10 GMT 2017 armv6l GNU/Linux

@cecchisandrone The container configures the host network on the device, so that part is purposely not isolated, nor can it be since we are dealing with the physical wifi device on the Pi. It's the Pi's wifi device that is "connected" so when the container goes away it has not effect on the host network, which is usually a good thing since it avoids disruption on events like container restarts or upgrades. I use this container quite a bit with the Watchtower Container used for keeping all the containers up to date. Watchtower is my "firmware updater" and if the network went down when the container updated it could cause an unnecessary disruption for a number of services.

I think useful feature would be to add an APi call to revert the network state. Thoughts?

It could be useful having some optional parameter in the container that can be used to revert initial condition if it is terminated. I agree with you that in general container restarts should’t affect current network setup.

Is there also a disconnect API call?

The only requirement should be basic networking. Can you run sudo dhclient wlan0 -v and see if you can force it to get an IP address? It's possible that it is not properly connected.

There is no disconnect API call but you are welcome to submit an enhancement issue that I can assign the next release.

This comment is related to #4 ...I answered there.
Can you also suggest the commands to run to restore initial condition after terminating the container? In this way I can do different tests of the container, restoring initial conditions.

@cecchisandrone Usefull commands for resetting state.

  • iw dev uap0 del will remove the virtual interface used for the AP.
  • ifconfig wlan0 down will bring down the station interface

If you don't have these commands on your local machine you can execute them in the container.

docker run -it --rm CONTAINER sh