While you're here, please consider supporting GamingOnLinux on:
Reward Tiers:
Patreon. Plain Donations: 
PayPal.
This ensures all of our main content remains totally free for everyone! Patreon supporters can also remove all adverts and sponsors! Supporting us helps bring good, fresh content. Without your continued support, we simply could not continue!
You can find even more ways to support us on this dedicated page any time. If you already are, thank you!
Reward Tiers:
Patreon. Plain Donations: PayPal.This ensures all of our main content remains totally free for everyone! Patreon supporters can also remove all adverts and sponsors! Supporting us helps bring good, fresh content. Without your continued support, we simply could not continue!
You can find even more ways to support us on this dedicated page any time. If you already are, thank you!
Login / Register
- GOG launch their Preservation Program to make games live forever with a hundred classics being 're-released'
- Valve dev details more on the work behind making Steam for Linux more stable
- NVIDIA detail upcoming Linux driver features for Wayland and explain current support
- GE-Proton 9-19 brings fixes for Horizon Zero Dawn Remastered, Monster Hunter Wilds and more
- Direct3D to Vulkan translation layer DXVK v2.5 released with rewritten memory management
- > See more over 30 days here
-
Proton Experimental adds DLSS 3 Frame Generation suppor…
- 14 -
Linux GPU Configuration Tool 'LACT' adds NVIDIA support…
- Purple Library Guy -
Half-Life 2 free to keep until November 18th, Episodes …
- StalePopcorn -
Half-Life 2 free to keep until November 18th, Episodes …
- Piejacker875 -
Linux GPU Configuration Tool 'LACT' adds NVIDIA support…
- DamonLinuxPL - > See more comments
- Types of programs that are irritating
- dvd - New Desktop Screenshot Thread
- pilk - What do you want to see on GamingOnLinux?
- Linas - Weekend Players' Club 11/15/2024
- StoneColdSpider - Our own anti-cheat list
- Xpander - See more posts
View PC info
While I eventually figured out how to force it away from 172.17.0.1 - I do wonder why the default setting is to announce it to other wifi clients?
It's possible that he has been drinking from the chamber pot - but I'd appreciate some feedback.
$ docker network inspect c0bf044950bc
[
{
"Name": "bridge",
"Id": "c0bf044950bc5cc555e3418a3f50815e493df863bee03a91c29a29bbc416a3ef",
"Created": "2022-09-08T13:26:18.318941442+02:00",
"Scope": "local",
"Driver": "bridge",
"EnableIPv6": false,
"IPAM": {
"Driver": "default",
"Options": null,
"Config": [
{
"Subnet": "172.15.0.0/16",
"Gateway": "172.15.0.1"
}
]
},
"Internal": false,
"Attachable": false,
"Ingress": false,
"ConfigFrom": {
"Network": ""
},
"ConfigOnly": false,
"Containers": {},
"Options": {
"com.docker.network.bridge.default_bridge": "true",
"com.docker.network.bridge.enable_icc": "true",
"com.docker.network.bridge.enable_ip_masquerade": "true",
"com.docker.network.bridge.host_binding_ipv4": "0.0.0.0",
"com.docker.network.bridge.name": "docker0",
"com.docker.network.driver.mtu": "1500"
},
"Labels": {}
}
]
It says 'Scope: local' so I don't see how it could interfere - but the I'm oblivious to the finer points of docker configuration - I just run containers :P
The only change I've ever made to docker apart from installing it just a few minuts ago adding the file
$ cat /etc/docker/daemon.json
{
"bip": "172.15.0.1/16"
}
Are you sure it was docker doing this to their network? Based on your config I can't see a reason why docker would do that.
If it really did that (tbh I doubt it, I could be wrong though!) then changing the IP address alone will not be enough to stop it announcing itself as the default gateway (It'll still try to do it, just under a different IP).
Also, those bridge configurations usually only work within the host machine. That is, pinging 172.15.0.1 in this case from another device on the network almost certainly won't work (at least, not to your docker container, it might ping another device which is assigned that IP, but not your docker).
That's why in most cases there are (automated) forwarding rules in place for a docker container within the host that says in simple terms, incoming data from public ip X forward to internal ip 172.15.0.X that belongs to container X for example.
So I think it's very unlikely that your docker container was announcing itself over the network unless there is something very, very wrong with your config. In most instances if a docker containers network is not setup correctly you'll end up knocking yourself off the network before you knock others off.
Try it again, see if it happens again (probably best with networks permission). If it does, ask to see their network logs just to verify it really is coming from your device.
Lastly, why doesn't their corporate router stop that from happening in the first place?
Is the corporate network even using that IP range? Run "ip addr" check your local ip on the wlan0 interface.
With that said, for further reading this may be of help:
https://docs.docker.com/network/bridge/
If you can, I suggest checking out Podman, and run it rootless mode. Might take a bit more setup, and it is somewhat less mature than Docker, but it was built from the ground up to run without root privileges, and not messing with your networks/firewalls/mountpoints/etc.
View PC info
That was my first question "why aren't wifi clients isolated?" - that did not go over well
Relevant lines:
3: wlp4s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 14:5a:fc:2b:5f:db brd ff:ff:ff:ff:ff:ff
inet 172.17.0.187/24 brd 172.17.0.255 scope global dynamic noprefixroute wlp4s0
valid_lft 824sec preferred_lft 824sec
inet6 fe80::6d59:256d:e4b1:3fb/64 scope link noprefixroute
valid_lft forever preferred_lft forever
5: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default
link/ether 02:42:45:4f:bb:46 brd ff:ff:ff:ff:ff:ff
inet 172.15.0.1/16 brd 172.15.255.255 scope global docker0
valid_lft forever preferred_lft forever
anyway I think I will just turn off wifi around the office unless I need to print :P
Just avoid using 172.17.* for anything local, and you should be good.
It's the first time I've seen it happen with docker though! I've only ever seen that happen when someone tries to setup a dhcpd server on their machine for one network interface and it gets set to the wrong (or all) interfaces and it tries grabbing clients.
Though to be fair, I very rarely use docker since I prefer manual setups
View PC info
I usually prefer using vagrant, but for plesk development that wasn't my choice ;)
View PC info
That's it! We use Docker extensively at work and I've never seen or heard of this. That's because as far as I know Docker networks aren't capable of announcing themselves as a gateway. They're just network connections.
I think it is your image that you're running that has a DHCP server or something that is announcing itself as a gateway.
If you can't control that, I think either scope, driver or some of the other settings, or perhaps port mappings on the docker-compose or your command-line equivalent can be changed to prevent what gateway is running from accessing the outside. What does your docker-compose look like? And what is the default network driver? (There can be big differences in how they act, especially with older versions of Docker.)