I’m not sure why you’re encountering this issue, it should be possible to use WiFi normally without having to do that first. I would suggest you to first flash your Edison module, that might solve the issue: https://communities.intel.com/docs/DOC-98643.
Now, for your second question, you can create a service to do this automatically every time the Edison starts, you can check Peter’s instructions to achieve that in this thread: https://communities.intel.com/thread/86993.
I flashed my Edison when i got it a couple weeks ago so I don't think that's the issue. It appears the guy in the thread you linked to has the identical issue as me, and must emit ifconfig usb0 down before doing anything with the board wirelessly, so this must be a common problem for some reason.
I will set it up to do this automatically on boot as per the links you provided.
I know you flashed the board recently, but which version did you use? Maybe you are using an old one that may be causing this, please run the command uname -a and let us know the outcome. With the latest image you should get: Linux edison 3.10.17-poky-edison+ #2 SMP PREEMPT Mon Mar 14 15:26:16 PDT 2016 i686 GNU/Linux
If you have the latest image and you still need to use ifconfig usb down, I suggest you to create a service to run at boot with this command, take a look at: https://communities.intel.com/docs/DOC-111103 The Edison also uses systemd, so this works for Edison too, instead of the blink example you will need a .sh script with the command ifconfig usb0 down; or you can include it in the service (this would be easier).
Try with this and let us know.
Here is the result when I run that:
Linux andrew 3.10.17-poky-edison+ #2 SMP PREEMPT Mon Mar 14 15:26:16 PDT 2016 i686 GNU/Linux
I have tried this many times and I always replicate with identical results: When I turn on the board and it boots up, wireless access is not available. I screen in using the USB cable, turn down usb0, then wireless works. There are a few other threads on this site and elsewhere that show at least a few guys with identical experience. Also, I participated in the IoT hackathon a couple weeks ago and several guys there had similar problems, I suspect this was the culprit: those guys (including me) could only work with the Edison tethered to a USB since the instructions for wireless access never mention the option of turning off usb0. Perhaps they should be added as a troubleshooting step. It also never occurred to the Intel folks who were helping us at the hackathon that this option might be a useful fix, so perhaps this sporadic problem for some people is not widely known.
Anyway, happy to know the solution is simple enough to create a startup script.
Actually, it is already included in: https://software.intel.com/en-us/getting-started-troubleshooting-edison-for-windows I think you missed that document.
I have seen that running systemctl stop connman also helps in some times, so you could try with that too.
That documents suggests running these four together:
ifconfig usb0 down
ifconfig wlan0 down
ifconfig usb0 up
ifconfig wlan0 up
Doing so leaves the usb0 turned on, but I need it turned off to get wifi going. I had tried these four steps together as they are implied in the document, but that didn't have any effect until I skipped the line:
ifconfig usb0 up
In fact it is because of this that I eventually realized that turning off usb0 was necessary, so the document got me halfway there, but only after plenty of extra experimentation.
I think a more explicit mention of leaving the board with usb0 turned off could have saved me several hours.
1 of 1 people found this helpful
I had this same problem. At least in my case the cause seems to be that my wifi network works with the same segment of the default usb0 ip address (192.168.2.x). When I turn usb0 down or keep it up using a different ip (example: 192.168.5.15) everything works fine.
I found usb0 default ip can be changed editing /etc/systemd/network/usb0.network
Hope this helps,
I have multiple Edisons that I've flashed multiple times and the usb0 problem is quite common. I was disappointed to discover that after flashing with the 6/2016 build that the problem still has not been addressed in the build itself.
If you look at the routing table that gets created by default, I don't see how anyone could NOT have this problem if they're using 192.168.2.0.
How can we get this issue addressed by the developers?
We have passed your feedback to the engineering team so they can tackle this issue soon. We apologize for the inconveniences that this is causing.