ppareit
FTP server does not return to work after scheduled hotspot reboot
I suppose this is not the only case of this kind here, but I would still like to describe how it happens in my situation.
I use (or would like to use) FTP server in always ON mode, since I never connect to any other WiFi except my own home network which I fully trust, so I believe it's not a big security risk, while still a significant advantage for me. My WiFi router is configured to scheduled reboot every night while I sleep, but it seems that this application cannot work in such scenarios, because every morning I take my phone and find out that FTP server is turned off. Seems it just not capable to recover after only a few minutes of connection loss.
It is noteworthy that this does not depend on the "Autoconnect settngs" state, and even more interesting that primitive ftpd manages this very well, keeping server running 24 hours a day, despite the router reboot (although primitive ftpd is inferior in other critical respects).
I think we have significant reliability gap here, but according to rival's practice, it could certainly be fixed.
@ppareit Maybe using JobScheduler instead of simple background service will help. Something like this, PS. I'd be glad to make necessary changes if you approve.
@ashutoshgngwr In https://github.com/ppareit/swiftp/commit/f53c2ca4e5be13fb9d1fbbee67d88dbecbde283f#diff-27e710c3720be6468dd9d38123b03357R89 I addressed the problem of implicit broadcasts. Especially, see the call to registerReceiver(mWifiStateChangedReceiver, wifiStateChangedFilter); Moving forward, JobScheduler would be better. It seems to be the preferred way to register network changes. I would also merge in changes like that.
The problem the user is seeing will not be solved by this. As there is logic in swiftp to especially stop the server when the wifi goes down. Maybe we should retry connecting for a set time? This could also be easier when using JobScheduler to detect network changes?
I'm aware of broadcast migration. I'm looking into possible solutions but this bug is hard to reproduce. Will try to make a WIP PR ASAP. 👍
@ppareit So i was trying to reproduce this bug on my end. Here's what I got from the logs. I added a log statement for logging NetworkInfo object itself (after line 383). I am connected to a WiFi network and yet NetworkInfo contains details for cellular connection. It is also worth mentioning that there is no active internet connection on WiFi so this might be just that (and OP might also be in same scenario; a typical router takes a few seconds before getting an internet connection). Whatever maybe the case, I can't further debug this due to absence of a dedicated router. If you can help me rule this out, I may be able take it further.
https://github.com/ppareit/swiftp/blob/7ba1d363fc4a1047063fc8c045356ceea7098d35/app/src/main/java/be/ppareit/swiftp/FsService.java#L379-L411
D/FsService: Creating server thread
D/FsService: Server thread running
D/FsService: [type: MOBILE[LTE], state: CONNECTED/CONNECTED, reason: (unspecified), extra: airtelgprs.com, failover: false, available: true, roaming: false]
D/FsService: isConnectedToLocalNetwork: see if it is an WIFI AP
D/FsService: isConnectedToLocalNetwork: see if it is an USB AP
W/FsService: run: There is no local network, bailing out
I/FsService: onDestroy() Stopping server
D/FsService: serverThread join()ed ok
D/FsService: FTPServerService.onDestroy() finished
D/FsNotification: onReceive broadcast: be.ppareit.swiftp.FTPSERVER_FAILEDTOSTART
This should be closable today.
Its possible ppareit changed something since this issue was created (I've not looked at changes made). However, the app stays running. Can drop wifi all one wants and clients will connect without issue when wifi comes back up.
There are some red herrings such as if the app is started without wifi. That's not what this issue is about and would be a different problem. That would also mean that the app was started (hence killed) or device rebooted while wifi was also offline.
