cross-posted to: https://sh.itjust.works/post/12856684


I have the following topology:

The device running Nextcloud (snap) used to be connected to Router A, but I have recently added a bridge (Router B) and I moved Nextcloud’s device to that bridged network; however, as soon as Nextcloud was moved to Router B, the portforward on Router A seemed to stop working – as in I cannot connect to nexcloud from the public IP anymore. Bridges operate at layer 2, so this should make no difference whatsoever (this is reflected in the fact that other services (like SSH) still work perfectly fine portforwarded – it’s only Nextcloud that doesn’t work), which leads me to think that it is a Layer 7 (i.e. Nextcloud) issue. What’s going on here? How can Nextcloud even tell that it’s been placed on a bridged network?

EDIT (2024-01-16T00:19Z):

I performed a network capture on the device running Nextcloud, and it appears that it’s receiving the incoming request (SYN), and responds appropriately (SYN, ACK), but then Router B responds with Destination unreachable (Network unreachable), which is then, of course, followed by many requests for retransmission as the packets are being dropped. But what’s causing the packets to be dropped? Why aren’t they making it through the network?

EDIT (2024-01-25T08:37Z):

I’m not 100% sure what the previous problem was, but I think that it had to do with the bridge that I was using – not necessarily that it was broken, but perhaps it was jsut incompatible with the setup in some way. What I ended up doing was buying a different router that supported WDS, and then I created a WDS bridge between the two routers. The network seems to be working reliably, and as expected now.

  • BearOfaTime
    link
    fedilink
    arrow-up
    1
    arrow-down
    1
    ·
    edit-2
    10 months ago

    After looking at the docs you linked, I’m not sure why you’d need to bridge the wifi to the LAN - it already is via the inbuilt switch ports (it’s been a while but when I tinkered with WRT it was for consumer wireless routers, which are a router, a switch, and a wireless access point rolled into one.).

    Just disable DHCP, DNS, and connect one of the network ports (NOT the uplink) to the network that Router A is on, and Bob’s your uncle. (

    The switch part will provide all the bridging (since that’s what switches do) and the wireless is already bridged to that switch.

    So I don’t even see a need for relayd software and it’s config. The router, with DHCP and DNS off, the uplink port not used, is essentially just being a switching bridge. If you can disable the uplink port that would be even better, but so long as it’s set to use DHCP for an address, it’ll never get one. Or you could set it to a private class that you won’t use: say your network is 192.168.x.x, set the uplink to use 10.0.0.x. You’ll never have traffic wanting to use that network.

    Edit: Ah, I see. You’re using 2 wifi access points as a bridge to each other. Hmm, yea, that’s not typically a thing (though I’ve seen it more recently) which is why you’re using relayd.

    Definitely looks like relayd is playing pretend at bridging somehow, but not perfectly. Is there a forum for relayd?

    • Kalcifer@sh.itjust.worksOP
      link
      fedilink
      arrow-up
      1
      ·
      10 months ago

      Ah, I see. You’re using 2 wifi access points as a bridge to each other.

      Yeah, this is a requirement for how I am trying to implement it.