I can't tell exactly what you are trying, it looks like you might just not have Traefik and the services on the same network. Its also helpful to have a domain that's going to resolve to 127.0.0.1 on wildcard queries. This might be a valuable starting point as a working example. networks: traefik: name: demo_traefik services: proxy: image: traefik:latest command: > --accesslog=true --api.insecure=true --log.level=DEBUG --providers.docker=true --providers.docker.network=demo_traefik ports: - "80:80" - "8080:8080" networks: - traefik volumes: - /var/run/docker.sock:/var/run/docker.sock labels: traefik.http.routers.demo_traefik.rule: Host(traefik.localtest.me) traefik.http.services.demo_traefik.loadbalancer.server.port: 8080 example: image: nginx networks: - traefik scale: 4 labels: traefik.http.routers.demo_nginx.rule: Host(example.localtest.me) traefik.http.services.demo_nginx.loadbalancer.server.port: 80 whoami: image: traefik/whoami networks: - traefik labels: traefik.http.middlewares.whoami_strip.stripprefix.prefixes: /whoami traefik.http.routers.whoami.rule: Host(example.localtest.me) && PathPrefix(/whoami) traefik.http.routers.whoami.middlewares: whoami_strip docker compose up and then visit http://example.localtest.me/whoami in your browser.

There are several ways to address this particular problem. Using a dynamic proxy Using a dynamic proxy is nice because you only need a single ip address and port. Incoming requests are directed to the appropriate container based on metadata about the request (such as the hostname, or particular headers, or the request path, etc). This is actually what I'm doing at home: I have a number of web services running on my local system and I want to access them by name. I'm handling this by using https://traefik.io/ , a dynamic proxy designed to work well with systems like Docker. Configuration is primarily via Docker labels. So for example, if I start the Traefik container like this: docker run -d --name traefik \ -v /var/run/docker.sock:/var/run/docker.sock \ -p 80:80 \ -p 127.0.0.1:8080:8080 \ docker.io/traefik:v2.8 \ --api.insecure=true \ --providers.docker (That -p 127.0.0.1:8080:8080 is exposing the Traefik dashboard on http://localhost:8080.) Then I can make a web service available at grafana.local by starting it like this: docker run -d --name grafana \ -l 'traefik.http.routers.grafana.rule=Host(`grafana.local`)' \ docker.io/nginx:mainline Now any host on my network can access that service at http://grafana.local (assuming I have arranged for the hostname "grafana.local" to map to the address of the host running the traefik proxy). I've used docker run commands here, but you can obviously set this all up using docker-compose instead. Using multiple ip addresses It sounds a bit like docker can not share the same port even when it belongs to several IPs on the host. That is in fact not true. Consider this; on my host I have the following addresses assigned on eth0: $ ip -4 addr show eth0 2: eth0: mtu 1500 qdisc fq_codel state UP group default qlen 1000 altname eno2 altname enp0s31f6 inet 192.168.1.175/24 brd 192.168.1.255 scope global dynamic noprefixroute eth0 valid_lft 83583sec preferred_lft 83583sec inet 192.168.1.180/24 scope global secondary eth0 valid_lft forever preferred_lft forever inet 192.168.1.181/24 scope global secondary eth0 valid_lft forever preferred_lft forever inet 192.168.1.182/24 scope global secondary eth0 valid_lft forever preferred_lft forever Let's start up a few containers: docker run -d --name darkhttpd -p 192.168.1.180:80:8080 docker.io/alpinelinux/darkhttpd docker run -d --name nginx -p 192.168.1.181:80:80 docker.io/nginx:mainline docker run -d --name httpd -p 192.168.1.182:80:80 docker.io/httpd:2.4 We can see that the containers are all running successfully: $ docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 283c8e061ebc httpd:2.4 "httpd-foreground" 16 seconds ago Up 15 seconds 192.168.1.182:80->80/tcp httpd 0d2960c07212 nginx:mainline "/docker-entrypoint.…" 18 seconds ago Up 18 seconds 192.168.1.181:80->80/tcp nginx 68e56ed8c180 alpinelinux/darkhttpd "darkhttpd /var/www/…" 18 seconds ago Up 18 seconds 192.168.1.180:80->8080/tcp darkhttpd And I get different services depending on which IP address I use: $ curl 192.168.1.180 / ... $ curl 192.168.1.181 Welcome to nginx!

External IP address is used to access applications from outside, which is running inside the cluster.

There are many layers to that question : How did you deploy Openstack? This will heavily influence the flexibility you have the expose API access. I assume you mean the Openstack API (nova,neutron,keystone,cinder) itself? Usually, the core API services are listening on your internal networks only.

The SERVER_ADDR is a FastCGI variable that is being set inside the fastcgi_params file as fastcgi_param SERVER_ADDR $server_addr; The https://nginx.org/en/docs/http/ngx_http_core_module.html#var_server_addr nginx variable description says it contains an address of the server which accepted a request, which is obviously an nginx server address. If you want to determine an address of upstream server that is chosen to handle the request, you can try to pass an additional FastCGI variable to your PHP-FPM backend using the https://nginx.org/en/docs/http/ngx_http_upstream_module.html#var_upstream_addr nginx internal variable value, e.g. fastcgi_param UPSTREAM_ADDR $upstream_addr; and check its value via the $_SERVER['UPSTREAM_ADDR'] array item value (I didn't check if this would work, so if you'd check it, any positive or negative feedback is welcome). Alternatively you can check https://stackoverflow.com/a/17053582/7121513 StackOverflow answer.

Here are the steps to change to disable ICMP echo response within Docker container: connect to the container with all privileges docker exec -it --privileged container_name bash modify the /proc/sys/net/ipv4/icmp_echo_ignore_all file via the systl conmmand, by default value is 0 See default value : sysctl net.ipv4.icmp_echo_ignore_all Disable icmp echo response : sysctl net.ipv4.icmp_echo_ignore_all=1

The referenced question deals with docker containers being attached to both a bridge and the host network at the same time. However, to expose a service, you publish your service typically via dockers ingress rather than host most networking so this is rarely an issue. i.e. the following compose fragment is legal: services: my-api: image: foo networks: - overlay1 - bridge1 ports: - 9090:8080 Wheras this fragment is illegal: services: my-api: image: foo # docker compose host mode networking. network_mode: host networks: - overlay1 - bridge1 - hostent ports: # docker swarm can publish a port on a host. This should work - target: 80 published: 8080 protocol: tcp mode: host networks: A different swarm compatible take on --net:host Also can't be mixed with ingress networking. hostnet: external: true name: host

Normally, you access services using the name provided by a Service resource. For example, if I have a Pod running Redis, like this: apiVersion: v1 kind: Pod metadata: labels: app: redis name: redis spec: containers: - image: docker.io/redis:latest name: redis ports: - containerPort: 6379 name: redis I might have a service definition that looks like: apiVersion: v1 kind: Service metadata: name: redis spec: selector: app: redis ports: - port: 6379 targetPort: redis With these in place, from another Pod I can refer to the Redis service using the hostname redis: [root@client /]# redis-cli -h redis redis:6379> The name and port to which we connect is controlled by the Service object. If instead of the above example I had: apiVersion: v1 kind: Service metadata: name: bob spec: selector: app: redis ports: - port: 2000 targetPort: redis I would need to connect like this: [root@client /]# redis-cli -h bob -p 2000 bob:2000> For more information: https://kubernetes.io/docs/concepts/services-networking/service/

After many various combinations of minecraft version, java version, server.properties, windows firewall, and PFSense NAT/firewall; I decided to install minecraft server on an Ubuntu 20.04 VM (on the same hardware), which worked perfectly. It may be possible that a clean re-installation of Windows 10 Pro would have solved the issue, however I did not want to loose other things I had setup on that installation. In order to install on Ubuntu I followed a combination of https://minecraft.fandom.com/wiki/Tutorials/Ubuntu_startup_script , and https://unix.stackexchange.com/a/612118/538346 to how to setup minecraft as a service which will run at boot, and still be able to fully interact with the server.

AFAIK hiding the SSID only changes behaviour for initial connection as one has to know the SSID to be able to connect instead of just choosing from the list. Also the WiFi will at some point confirm its network name to devices who would try to connect to it which could be intercepted by a third party that would try to connect to it. In my opinion hiding the SSID is just a tiny security by obscurity measure that only protects from everyday users. Here is some interesting read about the situation with some examples: https://www.acrylicwifi.com/en/blog/hidden-ssid-wifi-how-to-know-name-of-network-without-ssid/

Let me answer my question per the suggestion of Andrew instead of deleting it. The solution I found: Tap Advanced options when adding a network Select Yes for Hidden network I think I missed the saved network when I posted my question. The network was saved on this tablet but it was on a separate list at the bottom:

I assume you refer to a personal mobile hotspot rather than a router. You could try Settings > Connections > Mobile Hotspot> changing the AP band to 5.0Ghz.

This issue was caused by my firewall and due to complexity between multiple user profiles. I was able to fix all issues by entirely disabling the firewall setup by the afwall app. However, as a slightly better option, I was able to fix this issue as follows: As the 'Owner' profile, enable Airplane mode. Make sure WiFi and Mobile Data are off if you want to use the phone's own internal DHCP server. Then enable Hotspot In the user's account where afwall is configured, check the box to give "wifi" access to the row named (any app) - Same as selecting all apps - !! WARNING !! Note: I did try to isolate the wifi permissions to a single app, but I found that if every app's "wifi" setting was enabled (except the entry for (any app) of course), then it wouldn't work. But if the "wifi" setting was enabled for the (any app) row, then it worked. So it appears that there is, in fact, a distinction between selecting all apps or selecting the (any app) entry. My guess is this distinction is most relevant when using multiple user profiles. On another handset, I was able to resolve this issue and get an IP address when only enabling the "wifi" permission for the (root) - Apps running as root entry (as opposed to the (any app) entry). YMMV device-to-device, version-to-version, ROM-to-ROM.

I fixed this problem with the instructions written by Darren https://www.technipages.com/fix-google-for-android-shows-as-offline?unapproved=1042149&moderation-hash=c61959b8bfe3e4ed38cf51c03bd8cd25#comment-1042149 : Clearing Google Play Store Settings -> Apps & notifications Google Play services -> Storage Clear Cache & Clear Storage Uninstalling Google Play Updates Settings -> Apps & notifications Google Play services 3 Dots (Top-right corner) Uninstall Updates Afterwards restart the phone and check if the problem is solved!

Android has three MAC modes: Persistent MAC randomization This should be the default mode. For each Wifi a new random MAC address is generated. But if you reconnect to an already known Wifi the same random MAC address is used. Non-persistent MAC randomization In this mode for each Wifi a new random MAC address is generated and this MAC address only persists unless you disconnect from the Wifi. If you reconnect to a known Wifi again a new MAC address is generated. No randomization (device MAC) Disables all randomization for the specified Wifi, only the device MAC is used. From your description I would assume that on your device non-persistent MAC randomization is active. As you have seen persitent randomization and device MAC can be activated in Wifi menu, but the non-persistent randomization is missing there. You can find the non-persistent randomization option in the Developer menu. Most likely this option is active on your device and thus overrides all the other settings you do in Wifi menu.

Ok, I have tried switch mode with access point, same results. I disabled IPv6 option in the secondary router and it works. I guess android 8.0.0 doesn't support IPv6. Not sure why the router still honors IPv6 since it's in bridge mode or switch mode. Again other devices always work. My assumption is this android somehow honors the IPv6 option in the secondary router even though the router is not in router mode.

Irrespective of which bands and network frequencies your device supports, the carriers (in the US especially) are notorious for only enabling VoLTE and VoWiFi calling on devices that have been certified by them. The phone will work with AT&T's 3G and 2G networks if the bands are compatible with them. However, for 4G, the operator is not going to enable VoLTE services since the device is not certified by them. VoLTE provisioning is entirely operator-dependent even if the device hardware supports it. You can follow the list of AT&T's supported devices below. Only these devices will be able to use VoLTE services once they shut down 3G services (early 2022). https://www.att.com/idpassets/images/support/wireless/Devices-Working-on-ATT-Network.pdf Edit: The same is for 5G services as well. They'll only enable VoNR for devices that are certified by them.

From https://community.ui.com/questions/IPS-Alert-1-Potential-Corporate-Privacy-Violation/b435dc41-7d47-4107-b789-198beee2c26d and https://redd.it/r0ok41 , it looks like it was just a false positive. I'm guessing it was triggered by the port or IP.

The issue got fixed, the issue was with the ROM. I had flashed a stock ROM from ASUS' website a month or so ago and due to that even factory resetting didn't help. I flashed a new Pixel Experience ROM on it by unlocking the bootloader and it fixed the issue. I'm now getting full speeds, 50 Mbps+

Android bases on Linux and thus has the same limitations that the root permissions are required to open a socket on ports below 1024. For opening a socket in an app on a port greater than or equal to 1024 the app itself needs to have the static permission: defined in its AndroidManifest.xml. Without that permission no network communication is allowed by the Android operating system. With the permission you can open client and server sockets to perform network operations as usual. When opening a socket for running a server, be aware that usually this only makes sense on the WiFi interface. On the mobile network interface you can open up a socket, but as mobile network providers don't assign a public IP, you can't reach a server running on a Android system connected via mobile data to the Internet.