Skip to content
Snippets Groups Projects

Add web server for app downloading and small fixes

Merged Torsten Grote requested to merge grote/hotspot:web-server into master
3 unresolved threads

Merge request reports

Loading
Loading

Activity

Filter activity
  • Approvals
  • Assignees & reviewers
  • Comments (from bots)
  • Comments (from users)
  • Commits & branches
  • Edits
  • Labels
  • Lock status
  • Mentions
  • Merge request status
  • Tracking
26 }
70 27
71 if (SDK_INT >= 29 && (checkSelfPermission(ACCESS_FINE_LOCATION) != PERMISSION_GRANTED)) {
28 @RequiresApi(29)
29 private void requestPermissions() {
30 if (checkSelfPermission(ACCESS_FINE_LOCATION) != PERMISSION_GRANTED) {
72 31 requestPermissions(new String[]{ACCESS_FINE_LOCATION}, 0);
73 32 }
74 }
75
76 public void onButtonClick(View view) {
77 button.setEnabled(false);
78 if (hotspotStarted) viewModel.stopWifiP2pHotspot();
79 else viewModel.startWifiP2pHotspot();
33 if (viewModel.needToAskForEnablingWifi()) {
34 Intent i = new Intent(Settings.Panel.ACTION_WIFI);
  • 71 105 status.setValue(app.getString(R.string.callback_waiting));
    72 requestGroupInfo(1);
    106 requestGroupInfo(1, networkName);
    73 107 }
    74 108
    75 109 @Override
    76 110 public void onFailure(int reason) {
    77 if (reason == 2) requestGroupInfo(1); // Hotspot already running
    111 if (reason == 2) requestGroupInfo(1, networkName); // Hotspot already running
    78 112 else releaseWifiP2pHotspot(app.getString(R.string.callback_failed, reason));
    79 113 }
    80 114 };
    81 115 try {
    82 wifiP2pManager.createGroup(channel, listener);
    116 if (SDK_INT >= 29) {
    117 String passphrase = getRandomString(8);
  • 25
    26 @Override
    27 public View onCreateView(LayoutInflater inflater, ViewGroup container,
    28 Bundle savedInstanceState) {
    29 viewModel = new ViewModelProvider(requireActivity()).get(MainViewModel.class);
    30 // Inflate the layout for this fragment
    31 return inflater.inflate(R.layout.fragment_server, container, false);
    32 }
    33
    34 @Override
    35 public void onViewCreated(@NonNull View v, @Nullable Bundle savedInstanceState) {
    36 super.onViewCreated(v, savedInstanceState);
    37 qrCode = v.findViewById(R.id.qr_code);
    38 urlView = v.findViewById(R.id.url);
    39
    40 String text = "http://192.168.49.1:9999";
    • TODO: The hotspot IP address should be 192.168.49.1 on all phones, but it isn't always. Discovered this while working on the LAN plugin... I'll try to dig up the details.

    • Please register or sign in to reply
  • Looks good!

  • merged

  • akwizgran mentioned in commit eaddc3c9

    mentioned in commit eaddc3c9

  • akwizgran
    akwizgran @akwizgran started a thread on commit 194701db
  • 124 131 }
    125 132 }
    126 133
    127 private void requestGroupInfo(int attempt) {
    134 private void requestGroupInfo(int attempt, @Nullable String networkName) {
    135 Log.e("TEST", "requestGroupInfo attempt: " + attempt);
    128 136 GroupInfoListener listener = group -> {
    129 if (group == null) {
    137 boolean retry = false;
    138 if (group == null) retry = true;
    139 else if (networkName != null && !networkName.equals(group.getNetworkName())) {
    • What does this name comparison logic do?

      I made some changes that caused the app to crash, and after relaunching it would fail to get the group info. But in the log it looked like it had found a hotspot already running, and then failed to accept the group info because of the network name comparison:

      2021-04-20 11:21:30.748 14475-14475/org.briarproject.hotspot E/TEST: networkName: DIRECT-3m-LBoOcm0ZcD
      2021-04-20 11:21:30.748 14475-14475/org.briarproject.hotspot E/TEST: passphrase: jpA3xmt6
      2021-04-20 11:21:30.767 14475-14475/org.briarproject.hotspot E/TEST: requestGroupInfo attempt: 1
      2021-04-20 11:21:30.791 14475-14475/org.briarproject.hotspot E/TEST: received networkName: DIRECT-nH-D561ZZO3Ey
      2021-04-20 11:21:30.791 14475-14475/org.briarproject.hotspot E/TEST: received passphrase: S3Hy7r1K
      2021-04-20 11:21:31.793 14475-14475/org.briarproject.hotspot E/TEST: requestGroupInfo attempt: 2
      2021-04-20 11:21:31.798 14475-14475/org.briarproject.hotspot E/TEST: received networkName: DIRECT-nH-D561ZZO3Ey
      2021-04-20 11:21:31.798 14475-14475/org.briarproject.hotspot E/TEST: received passphrase: S3Hy7r1K
      2021-04-20 11:21:32.801 14475-14475/org.briarproject.hotspot E/TEST: requestGroupInfo attempt: 3
      2021-04-20 11:21:32.807 14475-14475/org.briarproject.hotspot E/TEST: received networkName: DIRECT-nH-D561ZZO3Ey
      2021-04-20 11:21:32.807 14475-14475/org.briarproject.hotspot E/TEST: received passphrase: S3Hy7r1K
      2021-04-20 11:21:33.809 14475-14475/org.briarproject.hotspot E/TEST: requestGroupInfo attempt: 4
      2021-04-20 11:21:33.815 14475-14475/org.briarproject.hotspot E/TEST: received networkName: DIRECT-nH-D561ZZO3Ey
      2021-04-20 11:21:33.815 14475-14475/org.briarproject.hotspot E/TEST: received passphrase: S3Hy7r1K
      2021-04-20 11:21:34.816 14475-14475/org.briarproject.hotspot E/TEST: requestGroupInfo attempt: 5
      2021-04-20 11:21:34.822 14475-14475/org.briarproject.hotspot E/TEST: received networkName: DIRECT-nH-D561ZZO3Ey
      2021-04-20 11:21:34.822 14475-14475/org.briarproject.hotspot E/TEST: received passphrase: S3Hy7r1K

      I had to turn wifi off and on again to resolve this, but as far as I can tell there was a functional hotspot, it's just that the app didn't accept it.

    • @akwizgran From this log and the experience with my devices, the check is there to ensure a functional hotspot. The SSID requested was DIRECT-3m-LBoOcm0ZcD, but the group info always returns DIRECT-nH-D561ZZO3Ey, so also because of a non-matching password, the client would be unable to connect. You can remove the check and try if this is also true for your device.

    • Yes, I think DIRECT-nH-D561ZZO3Ey is probably the hotspot created by the previous instance of the app, before it crashed. But repeatedly requesting the group info won't cause it to change, so the retries don't seem to achieve anything in this case.

      What might make sense would be to accept the existing network name and password, as long as the network name starts with DIRECT-. We haven't shown the requested name and password to the client yet, so accepting the existing ones and showing them to the client should be fine, shouldn't it?

    • What might make sense would be to accept the existing network name and password, as long as the network name starts with DIRECT-. We haven't shown the requested name and password to the client yet, so accepting the existing ones and showing them to the client should be fine, shouldn't it?

      Depends on what you mean by the existing ones? Assuming that the ones we requested will be really the ones the WiFi is using?

      In my case (and your two exotic phones), the second attempt to request the group info resulted in the correct information. Only here, the information seems to stay outdated.

    • By existing, I mean that a hotspot was already created by the previous instance of the app, which crashed without removing the hotspot.

      When the app was relaunched and requested a different network name, I assume (but haven't verified) that the code hit the reason == 2 check at line 111 and requested the group info. The name and password of the existing hotspot were returned - and as far as I can see, it would have been fine if the app had accepted them and showed them to the client. But instead, the app kept re-requesting the group info because the network name didn't match the one it asked for, and after 5 tries it gave up, so the client wasn't given the chance to connect to the existing hotspot.

      If we just accept any name that starts with "DIRECT-", without requiring it to be the same name we asked for, I think that would solve the problem we saw on my two exotic devices, where the group info was initially wrong, while also handling the case where a hotspot already exists due to a previous crash.

    • If we just accept any name that starts with "DIRECT-", without requiring it to be the same name we asked for, I think that would solve the problem we saw on my two exotic devices, where the group info was initially wrong, while also handling the case where a hotspot already exists due to a previous crash.

      That's correct, but it would not handle the case that I've seen where outdated information (the last hotspot the app had created) was returned in the first attempt and the correct information was only returned with the second attempt.

      If we were to return the outdated information there (like we used to do), the client is unable to connect because it is not what the hotspot is actually using.

    • Ah, I see. Maybe in this case, if we reach the max number of retries and the name still doesn't match, we should accept the details that are being returned?

      Perhaps we should even do the same if the name doesn't start with "DIRECT-"? So the logic would be "wait up to 5 seconds for a hotspot that looks right, and at the end of that time if we've got a hotspot that doesn't look right, try it anyway".

    • Yes that could work. Implemented in 8c2e2f46

    • Please register or sign in to reply
  • Sebastian
    Sebastian @sebkur started a thread on commit b461965f
  • 67 68 return webServerState;
    68 69 }
    69 70
    71 @RequiresApi(29)
    72 boolean needToAskForEnablingWifi() {
    73 return !wifiManager.isWifiEnabled();
    74 }
    75
    70 76 void startWifiP2pHotspot() {
    77 if (!wifiManager.isWifiEnabled() && !wifiManager.setWifiEnabled(true)) {
    • If I read the docs of setWifiEnabled() correctly it always fails as we are targeting API level 30

    • Yeah this won't work. We currently enable it for API 30 when the activity starts I think. In the final app, we have to do this differently. We could of course bring the hotspot app for those things in line with how the final implementation looks like. This probably makes sense if we want to continue to use the hotspot app to debug issues that people are reporting later.

    • Please register or sign in to reply
    Please register or sign in to reply
    Loading