WiFi connection always breaks down after a few hours #15
Comments
|
Hi. We have experienced similar problems on our own and pointed our fingers against the abundance of wifi networks surrounding our office (not to mention those created by iphones and such). We ended up using the plain old and reliable ethernet cable. A solution has been proposed on the forum: scheduling a script for restarting network when pinging google fails I don't think we can just put such a script into every yun and make everyone happy. For example, restarting the network interface, on which you've scripted a python socket to listen to, would probably kill that script. How to restart it properly is a knowledge only you have. Your thoughts? |
That’s always preferrable if it’s possible, but there are many situations where it’s not, and clearly you would expect a WiFi equipped device to work in these situations, too.
But that's not a fix of the issue; it's a (quite an ugly) workaround. (BTW, I don't understand why pinging Google was suggested; pinging the router should be sufficient. Constantly pinging Google will probably lead to IP blacklisting on their side; not a good idea.)
Certainly not.
I think WiFi is one of the main selling points of the Yún. As such it must work reliably out of the box, and the issue should be really tracked down and fixed. I never encountered a WiFi enabled device with this kind of problem before. There must be a bug somewhere. For instance, https://forum.openwrt.org/viewtopic.php?id=44877 looked like it was possibly what I would consider an actual fix; unfortunately, the last entry reports that this modification doesn't help either in the latest release version of OpenWrt. |
|
Your laptop/computer, in attempting to re-establish a broken network connection, is doing the same thing: checking and restarting the network interface at will. Most of the time, this happens without requiring your attention. The difference with the yun is that there is no "network manager" of any sort, so bash comes to the rescue. Of course we are open to more elegant and reliable solutions. PS: the last fix you mention was actually applied at a155167 as yun users reported it working |
Yup, but it most certainly doesn't check the connection by pinging Google. And does it break sockets when restarting the network interface (as you mentioned above wrt/ a python script)? I’ve never run into this kind of issue when writing scripts running on computers.
Once it's clear how to best deal with this issue, a small, dedicated Unix utility in C might be more efficient, no?
As I wrote above, I have basically no experience with OpenWrt, so I'm afraid I cannot suggest anything profound here. But from my POV, the first and foremost task would be to have any solution at all that works out of the box and is installed on the Yún by default.
Ah, OK, so now we definitely know it doesn’t help here … ;–) |
|
Yeah, I think it only cares about things like having an IP address or being authenticated with the hotspot |
|
I tried to reproduce the incorrect behaviour with no success. I configured my Yun to connect to an access point, and if I turn off the AP and then turn on again, the Yun recover the connection. I waited 5 minutes and 2 hours before turning on the AP and I tried with WPA2 and with no encryption. I have the latest version of the firmware on my Yun. |
|
@sngl |
|
@sngl |
|
I've only just started using the Yun myself and came across this topic by chance, but one thing I have seen is that the board seems to get very warm in a short period of time. Worst case its in a small box, no ventilation outside in direct sunlight bolted hard up agents the floor of the box. Other factor that may make weird things happen is you power. The yun has no regulator on board and must get a solid 5v (not sure of tolerance. USB standards?). If you are using an unreliable power supply or you get regular power spikes or drops even for a second or so this may cause the voltage to drop below 5v and put the Yun in a bad state. Don't just rule out the power as I thought my work had very reliable power until I looked at my UPS logs and found we get very short drops over night (never during the day) every few days to a week. The above may explained why so many people have the problem and why it would affect all 3 of your units. This may not the issue but it is still worth checking especially for any system that is going to run 24/7. |
No. For one, my Yuns don’t get that hot (never more than 40°C / 104°F). And if I reboot them, the connection will last again for at least several hours, although there was no cooling in the meantime.
Again, I’m quite sure that this isn’t the problem. I use different power supplies for my Yuns, one is USB powered, one is connected to a high quality laboratory power supply and one is connected to its dedicated high quality power supply. Also, the rest of the Yun/Linino keeps working just fine. It’s just WiFi that breaks down. From what I understand, WiFi is fragile and interruptions might not be unusual. The bug might not be the interruptions as such, but rather that the Yun does not automatically recover from them. (But I’m by no means an expert in this matter.) |
|
I too have had similar issues as the OP. As previously mentioned, there are no onboard regulators, so ensure your power is clean and consistent. A laptop USB is in spec, and should not fluctuate. |
|
Well, as I wrote before, I used various high quality power supplies during my tests, in my case to no avail. But that’s beside the point. The WiFi connection can get lost for a number of reasons; the important thing is that it will be automatically reestablished as soon as possible. Every WiFi device I know of seems to do that, except the Yun. Github says that no-one is assigned to this bug, so it seems this will not be fixed (the Yun is 1 year old already …). Why that is is beyond me. This is a most basic, crucial bug that effectively renders the Yun useless for any serious wireless application. I would certainly volunteer to fix this if I could, but unfortunately, wireless networking is beyond my area of expertise. Could someone of the Arduino team please comment on the state of this bug? I’ve invested a lot of time and resources in the Arduino Yun and planned to do various things with it, but if nobody even cares to try and fix this bug, I’ll have to let go and look somewhere else. :–( |
|
I´m having this issue too, and for now if i mantain a steady flow of ping packets from my laptop to the arduino it´ll stay up. There must be a work around. |
|
Any stranger dmesg debug error when disconnects? |
|
I have stopped the pings, and then starts the problem: [ 56.140000] wlan0: authenticate with c8:d7:19:50:fb:eb |
|
In the many disconnects I have researched, I could not find "typical" error messages before the event. But maybe this is beside the point, anyway? WiFi disconnections can and obviously do happen. Isn’t the real issue at hand that the Yún does not register these disconnections and does not automatically try to reconnect? IIRC every other WiFi equipment I have does this. BTW, I just now realize that @ffissore labelled this bug report a question back in May 2014. This is kind of absurd; I can’t think of a more critical bug for the Yún than an unreliable WiFi connection. Can someone with the required permissions please remove this label or replace it by bug? |
|
I have now had two Yuns in place which I use 24/7 for regulating my fish tank and a security application for months now. I have not had any issues with disconnections and have found them to be very reliable. I do occasionally turn off / update my router or have power failures so I know disconnections and connections are occurring but my Yuns are recovering. Both are running: From using wifi repeaters (nothing to do with the Yuns) of different brands together I have seen issues where I would have to reset the repeater or a secondary router after a period of time, just because they "don't play nice together". Apple airport express and netgear routers seem to have this issue, as well as asus routers with a client wifi bridge running dd-wrt firmware. |
|
I´m using a Linksys ABGN (802.11 AC) router. Already tryed on a Buffalo N and same problem. With the constant ping to the router, the connection is stable for many days now. Stop the ping ans 20 mins after it hangs wifi. |
|
I just loaded my ASUS RT-AC68U with an updated version of firmware that Since I have an audience, so to speak,has anyone found a way to keep the Any way, I am trudging on into Temboo-land. Posting when I get it to On Wed, Jan 28, 2015 at 4:29 AM, NerfyGeko [email protected] wrote:
|
|
My router is a DrayTek Vigor2750n.
While this might theoretically be the case, what help is this? I’m using a plethora of WiFi devices, all without any problems except the Yún. It is just not realistic to assume anyone would change their complete WiFi infrastructure to make it (possibly) work with Yún. It’s the Yún which must adapt here.
Unfortunately, no. BTW, I’ve just run another test with my three test Arduinos, and this time, it took 6 days until the first of them dropped the WiFi connection. Longest uptime I’ve had so far (with no configuration changes at all), for whatever reason. |
|
Yun WiFi 'wlan" indicator is just as temperamental. Any sketch that uses the bridge, which is essential, will diable the wlan LED. The configuration file remains set to default ON for all of the netdev triggers. It will comeback after power-down. Would love to have a bridge command that can be invoked from a sketch that resets it. |
|
I have the dragino shield attached to my Arduino Uno and have the same issue. I can't seem to find any solutions to the problems, and perhaps most disturbing, it doesn't seem to be a priority to resolve. As @UliZappe has mentioned, there is almost no point in owning one of these if the Wifi connection is unreliable. The other issue mentioned, about the use of Bridge and the WLAN LED, is also pretty disturbing, but at least there are some workarounds. Perhaps I take a more cynical view of things, but a product this mature and a bug this devastating, it seems apparent that support of the success of the product really isn't all that important to its maker. Solution: At $80+ dollars, for functionality that doesn't even work reliably, I think i'm done with the Arduino platform. Thankfully I only bought the one. It was cute for simple things, but asking it to be part of "The-internet-of-things" is apparently asking too much. |
|
In all ways I can agree with you about the bridge/open-wrt link. I have three Yun's in a personal house monitor system. They require too much babysitting. // Added 5-25-2015, to restart LED triggers for Wireless LAN. |
|
I'm also experiencing this WiFi bug with several router. |
|
As this issue does not seem to get solved I would like to remember people you can just have a simple python script running in the background that wil monitor the wifi status and restart it if needed: e.g. http://forum.arduino.cc/index.php?topic=261103.msg1846380#msg1846380 |
|
That's great Nico. Workarounds are just that. A bug like, for this On Saturday, July 18, 2015, NicoLugil [email protected] wrote:
|
|
new to site and the Yun. Very similar problem as above but also cuts out on Ethernet. Has there been a permenant fix yet or do i look for a differant platform? |
|
Yes, I just bought arduino Yùn and arduino Tian. And guess what, they all have the same wifi problem. Which is annoying given the price. A smartphone I got for a bit more of the same price is able to work properly with any DC-to-microUSB out there, but the two arduinos can't start the wifi except if there are plugged in to a laptop. |
|
@nifovap Can you try the new version? https://github.com/arduino/openwrt-yun-1505 |
|
I wrote on Jan 29, 2015:
FWIW, my DrayTek router died a few months ago, and I replaced it with a FRITZ!Box 7490 (a popular brand in Germany). From that day on, the Yùn has not lost the connection once. So now I can confirm that the occurrence of the bug does depend on the WiFi access point that is used. Of course, as I wrote before, that does not mean that the Yùn has no bug – you would expect it to work with any kind of WiFi access point that other devices can work with successfully. Also, even with a working access point, the connection might break down once in a while for whatever reason, and I would still expect the Yùn to reconnect automatically. In any case, this new situation means that unfortunately, I cannot test if the new OpenWRT version helps, as unfortunately 😉, the Yùn currently works for me. |
Hi everyone,
I’m fairly new to the Arduino Yún and don’t even know if this is the best place to report this issue, but here we go …
Since starting out with the Yún last October, I’ve never been able to get a stable WiFi connection. Everything works fine for a few hours (something between 5 and 50), and then the connection breaks down (i.e. all network requests to the Yún time out). This has happened in 100% of my trials.
So far, what I could verify is that it’s not:
Since I found some at least similar reports on the Arduino-Yún forums, I was hoping that updating to the new OpenWrt-Yún software version would finally fix this issue, but it’s completely unchanged.
What I don’t get is that clearly, built-in WiFi is one of the main points why you would use an Arduino-Yún, so this issue is central to the whole product. For anyone who intends to use the Yún for something where permanent network connection over long periods of time is crucial (like home automation), this issue makes the Yún basically unusable. So I wonder why there’s seemingly not much attention given to this issue; I can’t be the only one who experiences it?!?
As I said, having basically no experience with OpenWrt, I cannot help much in fixing this issue, but of course I could help tracking it down if it doesn’t reproduce easily, if I’m told what to do/which information to gather.
Uli
The text was updated successfully, but these errors were encountered: