Bug #2
closedCan't use helloworld binding example to create an app through the redpesk UI
100%
Description
When trying to create a new app in an existing project through redpesk UI, step 3 (Choose add method) fails when selecting "# Add Sample App / Helloworld binding". Reason for failure is "408 Request Time-out" (please see attached screenshot).
Debugging information¶
Gathered from various spots/sessions/conversations and centralized here:
2022-04-10¶
- with Emmanuel's machine (OpenSuse VM via Virtualbox on a Windows host)
- using his phone Wifi hotspot (Free network), application creation fails
- on the SAFT network, application creation succeeds (i.e. the problem does not occur)
- using Frederic's phone Wifi hotspot (Orange network), application creation succeeds
- with Frederic's Mac machine using the same OpenSuse VM (via Virtualbox) and the SAFT network, application creation works
Based on the information above, it looks like a particular behavior with the Free mobile network which might be filtering certain network packets when using a Wifi hotspot
2022-04-01¶
Emmanuel mentions that creation via rp-cli
works fine.
2022-09-22 debugging session¶
- with Emmanuel's machine (OpenSuse VM via Virtualbox on a Windows host) on Emmanuel's phone (Android on the Free mobile network)
- changing the Wireguard MTU to 1416 in the OpenSuse VM does not change anything
- Emmanuel mentions that he had the same issue on a native OpenSuse distribution running the Wireguard client (his own machine)
- this rules out an interaction between the VM/hypervisor in Windows and the Wireguard client
- Request type
- application creation uses a
PUT
request and fails (request size = 1089 bytes, as shown viacurl -w '%{size_request} %{size_upload}'
- same is true for project creation/save
- editing the user's profile (changing the telephone number) also uses
PUT
but does NOT fail - doing a build (via a
POST
request) works fine
- application creation uses a
- using
curl
instead of the UI for saving an application/project settings works fine- this works fine whether this is using a token or a session ID
- Emmanuel also sees a similar
408 Timeout
issue when trying to use Chrome to log into the stack (GET
request)
TODOs¶
- Emmanuel
- with Emmanuel's other phone: also on the Free mobile network but with a different Android version (purpose: rule out Android interactions)
- retry with native OpenSuSe machine w/ Wireguard client (purpose: rule out Windows/Virtualbox interactions)
- IoT.bzh
- try the same setup as Emmanuel (Wifi connection sharing over Free network)
2022-09-29¶
Issue solved by adding "MTU = 1280" in the client wireguard configuration file.
More information here : https://keremerkan.net/posts/wireguard-mtu-fixes/
Files
Updated by Vincent Rubiolo over 2 years ago
- Status changed from New to In Progress
Looking into the problem
Updated by Emmanuel Jubera [SAFT] over 2 years ago
- Priority changed from Normal to High
Same problem occurs when trying to add a custom app.
Updated by Vincent Rubiolo over 2 years ago
- File retrieve-UI-logs.png retrieve-UI-logs.png added
- Status changed from In Progress to Submitter feedback needed
Emmanuel, I cannot reproduce the issue since we updated the SAFT stack to the latest version. Can you confirm the issue is fixed on your side too?
If you are still seeing the issue, can you collect the frontend logs via the bell icon on the top-right corner of your screen (see attached capture)?
Thanks much!
Updated by Emmanuel Jubera [SAFT] over 2 years ago
Problem still occurs with new stack, preventing any application creation.
Please see attached logs.
Updated by Vincent Rubiolo over 2 years ago
- Status changed from Submitter feedback needed to In Progress
Following today's discussion, it might be due to the network environment on the SAFT side.
We are looking into it more on the frontend/backend side too
Updated by Emmanuel Jubera [SAFT] over 2 years ago
Same problem occurs when trying to create a project and an application outside of SAFT network.
Updated by Emmanuel Jubera [SAFT] over 2 years ago
Creation through rp-cli works though...
Updated by Vincent Rubiolo over 2 years ago
Additional information from Emmanuel:
- with Emmanuel's machine (OpenSuse VM via Virtualbox on a Windows host)
- using his phone Wifi hotspot (Free network), application creation fails
- on the SAFT network, application creation succeeds (i.e. the problem does not occur)
- using Frederic's phone Wifi hotspot (Orange network), application creation succeeds
- with Frederic's Mac machine using the same OpenSuse VM (via Virtualbox) and the SAFT network, application creation works
Based on the information above, it looks like a particular behavior with the Free mobile network which might be filtering certain network packets when using a Wifi hotspot
Updated by Emmanuel Jubera [SAFT] over 2 years ago
- Priority changed from High to Low
I decrease priority to Low since there're other ways to create applications.
Updated by Vincent Rubiolo over 2 years ago
Emmanuel mentioned today that he is working around the issues by creating projects on the SAFT network instead of his tethered phone.
Leaving open as we might want to get more insight into the network filtering issues that occur on the Free network operator.
Updated by Emmanuel Jubera [SAFT] over 2 years ago
Additional information: building an existing app works while modifying .spec file or settings doesn't.
Updated by Sebastien Douheret [IoT.bzh] over 2 years ago
- Affects Version/s armel-1.0 added
Updated by Vincent Rubiolo over 2 years ago
As pointed out, Emmanuel mentioned that building projects is fine, it is modifying the project settings that is an issue
Updated by Eric Le Quer [IoT.bzh] about 2 years ago
- % Done changed from 0 to 100
Updated by Eric Le Quer [IoT.bzh] about 2 years ago
- Status changed from In Progress to Closed
Updated by Sebastien Douheret [IoT.bzh] about 2 years ago
- Description updated (diff)
Updated by Sebastien Douheret [IoT.bzh] about 2 years ago
Issue solved by adding "MTU = 1280" in the client wireguard configuration file.
More information here : https://keremerkan.net/posts/wireguard-mtu-fixes/
Updated by Vincent Rubiolo about 2 years ago
- Status changed from Closed to Resolved
Updated by Vincent Rubiolo about 2 years ago
- Status changed from Resolved to Closed