warpinator no longer has network access after I changed networking to use bridges

[gadgets-on-github]

After I changed my network configuration Warpinator stopped working on Mint 20.2 - it says "Something went wrong. You don't appear to be connected to a network." Running in debug mode, warpinator says "No network access". I suspect it is now because I use bridges instead of having IP address on the actual interface names in my networking. ie.

martin@martin-cube:~$ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: enp3s0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether a8:a1:59:78:8b:3b brd ff:ff:ff:ff:ff:ff
3: enp0s31f6: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether a8:a1:59:78:8b:3a brd ff:ff:ff:ff:ff:ff
4: enp1s0f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master br0 state UP group default qlen 1000
    link/ether 00:15:17:20:fe:4e brd ff:ff:ff:ff:ff:ff
5: enp1s0f1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master br1 state UP group default qlen 1000
    link/ether 00:15:17:20:fe:4f brd ff:ff:ff:ff:ff:ff
6: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 00:15:17:20:fe:4e brd ff:ff:ff:ff:ff:ff
    inet 192.168.2.72/24 brd 192.168.2.255 scope global br0
       valid_lft forever preferred_lft forever
    inet6 fe80::6cd3:2ff:fecb:2465/64 scope link 
       valid_lft forever preferred_lft forever
7: br1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 00:15:17:20:fe:4f brd ff:ff:ff:ff:ff:ff
    inet 192.168.22.1/24 brd 192.168.22.255 scope global br1
       valid_lft forever preferred_lft forever
    inet6 fe80::1844:baff:fee4:aee0/64 scope link 
       valid_lft forever preferred_lft forever
8: wlp0s20f3: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 1c:c1:0c:c4:95:69 brd ff:ff:ff:ff:ff:ff

Even if you go into the connection settings for warpinator and look at the interfaces available, the bridges are not listed there. Drats.

Any chance of getting this fixed - I was happy to find warpinator just a few weeks ago and I really miss it.

Cheers,

-Martin

[mtwebster]

Hi, can you go into a bit more detail on the rest of your network?

Also, please paste the output of:

python3 -c 'exec("import netifaces\nfor iface in netifaces.interfaces():\n    print(netifaces.ifaddresses(iface))")'

Thanks

[gadgets-on-github]

Hi, for detail on the network it's probably easiest if I show here my netplan config.

/etc/netplan$ more 1-network-manager-all.yaml 
network:
  version: 2
  renderer: networkd
  ethernets:
    enp1s0f0:
      dhcp4: no
    enp1s0f1:
      dhcp4: no

# Bridges are used by KVM

  bridges:
    br0:
      interfaces: [enp1s0f0]
      addresses:
      - 192.168.2.72/24
      dhcp4: false
      gateway4: 192.168.2.1
      nameservers:
        addresses:
        - w.x.y.z (altered)
        search:
        - somedomain.co.nz (altered)
      routes:
        - to: 192.168.2.0/24
          via: 192.168.2.1

    br1:
      interfaces: [enp1s0f1]
      addresses:
      - 192.168.22.1/24
      dhcp4: false

The way I use warpinator is to have the android device on the 192.168.2.0/24 network. So the same segment that enp1s0f0 is on. From the Linux Mint machine I can ping the android device. As I say it's only since introducing bridges that warpinator now seems to be unable to set itself up to receive connections, either with automatic assignment or by manually selecting the interface from within warpinator (br0 simply isn't listed as an option).

Here is the output from the python script as requested:

/etc/netplan$ python3 -c 'exec("import netifaces\nfor iface in netifaces.interfaces():\n    print(netifaces.ifaddresses(iface))")'
{17: [{'addr': '00:00:00:00:00:00', 'peer': '00:00:00:00:00:00'}], 2: [{'addr': '127.0.0.1', 'netmask': '255.0.0.0', 'peer': '127.0.0.1'}], 10: [{'addr': '::1', 'netmask': 'ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff'}]}
{17: [{'addr': 'a8:a1:59:78:8b:3b', 'broadcast': 'ff:ff:ff:ff:ff:ff'}]}
{17: [{'addr': 'a8:a1:59:78:8b:3a', 'broadcast': 'ff:ff:ff:ff:ff:ff'}]}
{17: [{'addr': '00:15:17:20:fe:4e', 'broadcast': 'ff:ff:ff:ff:ff:ff'}]}
{17: [{'addr': '00:15:17:20:fe:4f', 'broadcast': 'ff:ff:ff:ff:ff:ff'}]}
{17: [{'addr': '00:15:17:20:fe:4e', 'broadcast': 'ff:ff:ff:ff:ff:ff'}], 2: [{'addr': '192.168.2.72', 'netmask': '255.255.255.0', 'broadcast': '192.168.2.255'}], 10: [{'addr': 'fe80::4d3:6cff:fe19:4b04%br0', 'netmask': 'ffff:ffff:ffff:ffff::'}]}
{17: [{'addr': '00:15:17:20:fe:4f', 'broadcast': 'ff:ff:ff:ff:ff:ff'}], 2: [{'addr': '192.168.22.1', 'netmask': '255.255.255.0', 'broadcast': '192.168.22.255'}], 10: [{'addr': 'fe80::5c11:e9ff:febe:637c%br1', 'netmask': 'ffff:ffff:ffff:ffff::'}]}
{17: [{'addr': '1c:c1:0c:c4:95:69', 'broadcast': 'ff:ff:ff:ff:ff:ff'}]}

[juanpc2018]

As a Rule: Software Bridges is a Bad idea, unless its a dedicated Hardware and OS, like Mikrotik RouterOS.

in Windows creates so much interrupts and CPU latency problems, similar to removing cores & setting the Power Management CPU speed hard limited to the minimum.

unless its a dedicated Windows machine, for nothing else, and still its very limited vs. a pro Router.