quasarframework / quasar

Quasar Framework - Build high-performance VueJS user interfaces in record time
https://quasar.dev
MIT License
25.87k stars 3.51k forks source link

quasar dev -m capacitor -T android changes my external ip of window to the internal ip of wsl #16842

Closed amav96 closed 7 months ago

amav96 commented 8 months ago

What happened?

When my application compiles for Android Studio and runs in the Android Studio emulator, it works very well because Android Studio works on the same local machine and that's why I can access the internal WSL. But when instead of using the emulator I try to use my phone via USB, it does not allow access to the wsl IP from my phone obviously because it should access the external IP of window. Then I try to run the application in dev mode but on the external port of window and quasar always changes the IP and puts the IP of wsl, or it directly tells me: Invalid host specified. No network address matches. Please specify another one. So I am not being able to run the application on the external port of window

What did you expect to happen?

is there something way to force run dev mode on specific ip?

Reproduction URL

https://mycode.com

How to reproduce?

see example

Flavour

Quasar CLI with Vite (@quasar/cli | @quasar/app-vite)

Areas

Quasar CLI Commands/Configuration (@quasar/cli | @quasar/app-webpack | @quasar/app-vite)

Platforms/Browsers

No response

Quasar info output

amav96@alvaropc:/var/www/html/alvaro/ruteador/application (main)$ quasar dev -m capacitor -T android -H  192.xxx.0.226 --force

 .d88888b.
d88P" "Y88b
888     888
888     888 888  888  8888b.  .d8888b   8888b.  888d888
888     888 888  888     "88b 88K          "88b 888P"
888 Y8b 888 888  888 .d888888 "Y8888b. .d888888 888
Y88b.Y8b88P Y88b 888 888  888      X88 888  888 888
 "Y888888"   "Y88888 "Y888888  88888P' "Y888888 888
       Y8b

 App •  TIP  • 🚀  You specified an explicit quasar.config.js > devServer > port. It is recommended to use a different devServer > port for each Quasar mode to avoid browser cache issues. Example: ctx.mode.ssr ? 9100 : ...

 App • ⚠️  Invalid host specified. No network address matches. Please specify another one.

Relevant log output

No response

Additional context

quasar config

 `devServer: {
  // https: true
  open: true, // opens browser window automatically
  port: 3000,
  allowedHosts: "all",
  proxy: "http://192.423.0.626:3000",

}`

capacitor.config.json

{ "appId": "org.capacitor.quasar.app", "appName": "Quasar App", "webDir": "www", "server": { "androidScheme": "https", "url": "http://192.423.0.626:3000", "cleartext": true } }

when i run

quasar dev -m capacitor -T android change url to "url": "http://172.21.66.209:3000/" automaticly and i cant acces from my device throught android studio

(https://github.com/quasarframework/quasar/assets/59234915/a7ddc17f-3174-420b-98b5-c1ad61e252eb) ip ip2

github-actions[bot] commented 8 months ago

Hi @amav96! 👋

It looks like you provided an invalid or unsupported reproduction URL. Do not use any service other than Codepen, jsFiddle, StackBlitz, Codesandbox, and GitHub. Make sure the URL you provided is correct and reachable. You can test it by visiting it in a private tab, another device, etc. Please edit your original post above and provide a valid reproduction URL as explained.

Without a proper reproduction, your issue will have to get closed.

Thank you for your collaboration. 👏

amav96 commented 8 months ago

@steveclarke @kevindamm @dmitry

kevindamm commented 7 months ago

Sorry I didn't notice this message sooner, I'm not really an active contributor on this project.

I may be reading the bug description wrong but it sounds like the problem is two applications (one connected via Android Studio as the client, and Quasar for the server) and these two applications are operating on different subnets (one in the 172.16/12 private subnet and another on 192/8 private subnet).

While these are both private IPs, many things could be getting in the way. If they are on different routing devices they would be on different private subnets -- but putting the routers in bridge mode would fix that. The routing tables of your OS could also be blocking traffic between these subnets. If either client is being run in a docker container there is another area that could be blocking communication between these IPs. Normally, however, for the two IP addresses shown they should be able to communicate.