Manager can access, but API can not access?

[haiyunaixueye]

@GALewis ，@mkuai,Did you come across this situation?When I enter 127.0.0.1:9999, the web page prompts "NOT FOUND"

[sebastian-echeverria]

A couple of comments:

• If you want to access the manager, you should use http://127.0.0.1:9998/manager
• If you want to access the API, you should make a specifi API call. There is nothing to see at 127.0.0.1:9999. And even so, the URL for the API is 127.0.0.1:9999/api .... but still, there is nothing there unless you add a specific API command after that URL. It is not a GUI webpage, it is a REST API. For example, for a list of services, you can do 127.0.0.1:9999/api/services, and it should show your a JSON list of the available services.

Also, do remember that the Manager and the API are started separately, so you have to start them both separately if you need access to both of them. Let me know if this helps.

[haiyunaixueye]

This is very helpful to me。Thank you very much. I still have a problem. Now the Speech Client cannot find the cloudlet server. Looking forward to your reply

[sebastian-echeverria]

There are multiple possible reasons for that, depending on your setup:

• The Pycloud API is not running on the server
• The phone is not connected through WiFi to the same network where the Pycloud API is running
• The Avahi daemon is stuck or not running properly, and should be restarted
• Something was not properly configured or installed during setup (though it's hard for this to happen if you are using the default values)

One way to debug this is to try to run the Cloudlet Client app on the phone, and see how far you can get. If the Cloudlet Client does not find any cloudlets, for example, the issue may be that you are connected to another network, or that the Avahi daemon is not running properly. If Cloudlet Client can see the cloudlet, then the issue could be with the Pycloud API not running, or some configuration issue.

[haiyunaixueye]

Thank you for your reply. Based on the debugging method you provided, I found out that my Android cloudlet client could not find any cloud. I can ensure that: First, the Android and the server are in the same network. Second, the server's Avahi daemon service is up and running.

Looking forward to your answer again

[sebastian-echeverria]

Ok, the devices are on the same network, and Avahi is running. However, you say that Cloudlet Client can't find any cloudlets on the network? If the Cloudlet Client lists no cloudlets on the network, that is an issue with the Avahi daemon, since that is the only component accessed when finding and listing available cloudlets. Possible reasons for this:

• The Avahi daemon is simply stuck. Try stopping and starting the daemon again. I've seen this happening sometimes.
• Access to the Avahi daemon is being blocked by the router/access point. Either the multicast addresses, or the port used by Avahi, is being blocked.
• The Avahi daemon is not properly configured. It should have been automatically configured during the setup process, but if that didn't work for some reason, it may not be advertising the cloudlet. If you go to /etc/avahi/services/, there should be a file called cloudlet.service, and the file should be an XML file containing the same as the file in this repo, in pycloud/discovery/cloudlet.service. Unless there is something really weird with that file, or it is missing, it should be ok.

[haiyunaixueye]

Excuse me. I have already opened the avahi-daemon service on the server and ensured that the configuration was correct, but the Android client still could not find the cloudlet cloud. Does the Android client need to configure avahi-daemon service? Is there any need to configure Android client?

[sebastian-echeverria]

There is nothing that needs to be configured in the Android side for the discovery to work. If the avahi-daemon is working properly, and there is no network issue (device is in same network, multicast is not being blocked by router, etc), the Cloudlet Client Android app should be able to see the cloudlet.

The Avahi daemon uses the Zeroconf/Bonjour discovery protocol. This works by the client (the Android device in this case) requesting information by sending a DNS message on a multicast address in the network, and the Avahi daemon, which is listening on that multicast address, replies the DNS-SD request with a reply with the service information. The multicast address used for this, and the protocol, is standard, so there shouldn't be anything else needed for this to work.

Another way to debug and check if Avahi is properly responding (or if the request or reply is being intercepted somewhere in between) is to install a program such as ZeroConf Browser (from Google Play) on your android device. This a generic ZeroConf service scanner, and when it scans for services, it should find the cloudlet too, as a service. Again, if this doesn't work, there is either an issue with Avahi, or with the network connection between the phone and the Avahi daemon.

[haiyunaixueye]

Thanks for your reply, I downloaded the application, ZeroConf Browser. The app can find the server, but the cloudlet client still can't find server.

Looking forward to your reply.

[sebastian-echeverria]

Oh, thank you very much for your screenshots! The issue (or at least the current issue) is just a misunderstanding. The "List Cloudlet Networks" menu option finds WiFi networks that are setup with cloudlets. In reality, it just finds WiFI networks with a specific prefix ("cloudlet") in its SSID. However, this is only to find WiFi networks, if you don't know what WiFi network your cloudlet is in. You know this, and have already connected to that network, so you dont need that functionality.

In Cloudlet Client, there is another option that should say something like "List Cloudlets" (NOT List Cloudlet Networks). Try that option, but, from what I see in the Browser, the cloudet should properly show up in there. If it does, that means that your original problem is not really discovering the cloudlet, but at a step after that.

Do try that and let me know how that goes.

[haiyunaixueye]

Thank you so much for replying me so quickly. I can not find the server under the option list cloudlet, as shown below:

[sebastian-echeverria]

That is strange. If the Zeroconf Browser sees it, so should the Cloudlet Client app, since they work in the same way. I'll try to run some tests tomorrow, to see if I can reproduce this, though I have not seen this behavior lately. What version of Cloudlet Client are you using?

[haiyunaixueye]

Thank you very much. The cloudlet client I use is version 3.4.0

[sebastian-echeverria]

There is in fact an issue with the code, which will only try to find cloudlets if the SSID of the current Wi-Fi network has a certain structure. Let me try to patch this up and I'll let you know when I have it working.

[haiyunaixueye]

Thank you very much. Look forward to your reply.

[sebastian-echeverria]

Ok, the master branch of both Cloudlet Client and Speech Android have now a new version (3.4.1 and 3.0.1, respectively), that use a new version of client-lib-android (3.0.1), which fixes the issue. Before, it was only trying to find cloudlets if the SSID had a certain structure. Now, it checks for that structure but only logs the result, and tries to find cloudlets in the current network any time it is requested. This should solve this issue; at least it did locally in my test environment. Let me know how it works for you.

[haiyunaixueye]

Thank you for your help. I have tried Speech Client (3.0.1) and Cloudlet Client (3.4.1). Now the Speech Client can search for cloudlet and start a service, and Cloudlet Clinet can list cloudlets.However, "LIST CLOUDLETS NETWORKS" still cannot be displayed correctly, and what is the difference between "LIST CLOUDLETS NETWORKS" and "LIST CLOUDLETS"?

[sebastian-echeverria]

Great!

The List Cloudlet Networks functionality is for a use case that is different from yours, so you don't really need it. The idea is that a phone should be able to find a WiFi network with a Cloudlet, without being connected to any WiFi networks first. What the List Cloudlet Networks does is, simply, to see if there are WiFi networks nearby that could contain a Cloudlet in them. It does this by assuming that a WiFi network whose SSID starts with "cloudlet" could be a network with a cloudlet in it. So the List Cloudlet Networks function only does that, lists WiFi networks that could contain a cloudlet. Once you are connected to a WiFi network, the List Cloudlets functionality uses Zeroconf to find the actual cloudlet details inside the current network.

[haiyunaixueye]

Thank you very much for your answer. I will do the following. I will consult you when i have other question.

[sebastian-echeverria]

No problem, glad to help. I will close this issue, but feel free to open a new one if you have problems or questions. Thank you for helping us find and debug this issue. Good luck!