RPI 4b not getting ip from modem ISP in bridged mode

I have a weird problem.

When I put my ISP modem/router in bridge mode, my Raspberry Pi 4b is not getting a WAN ip address.(ipv4 and ipv6)
(everthing is working fine if the modem is in router mode (double nat, the reason I want it in bridgemode offcourse)

When I connect my wrt3200acm or my laptop directly to my bridged modem it's getting a (wan) ip address. So It looks like it's a problem from my Pi setup.

My Pi is using only one port connected to a manageable switch (TL-SG108E) In this setup and without bridge mode it is working fine. (it get's an ipv4 and ipv6 ip address) Does it have to do something with the switch/vlan setup maybe?

I'm using a Raspberry Pi 4 Model B Rev 1.2 with OpenWrt 21.02.1 r16325-88151b8303 / LuCI openwrt-21.02 branch git-22.025.79177-4ec18ec

or you bypass the switch, connect the RPi directly to the modem, and use the console to check if you get IPs ?

you could also try to clone the MAC of the laptop or the wrt3200.

1 Like

That's an idea. I will try this on a calm moment. I have to call the isp to set the modem in bridge.

If I'm going to try to clone the mac of the laptop to get an ip from my isp, what do I edit/config from cli in /etc/config/network to add this cloned mac?

1 Like

This may be your issue. This particular switch is a terrible option for your application for 2 reasons:

  • You cannot set the management interface/VLAN from which it gets its IP address if it is set to obtain an IP via DHCP (more about this later).
  • The switch's administrative interface will respond on all VLANs because, again, you cannot set the management VLAN. This includes potentially responding on the WAN.

On the first point, if the switch is set to get an IP via DHCP, it may be obtaining an address from your ISP, and thus not allowing you to get an IP on your Pi.

On the second point, if your switch has an IP in your management LAN, this is theoretically less of a vulnerability because it will only respond to requests to that address (but it will respond, even if the request comes from another network). The reason this may be less of an immediate concern is that your ISP should (in theory) not allow any routing of RFC1918 addresses (assuming you are issued a proper public IP in the first place). However, the security ramifications here are significant as the switch does not have adequate protections, and it is possible a bad actor on the internet could compromise your network.

This switch isn't great, but it is okay for use inside your network (i.e. behind your router/firewall).

There are 3 options to help address the problem:

  1. set the IP address of the switch manually (static IP) and do not use DHCP.
  2. get a second ethernet interface for your Pi (the UE300 is really popular for this pupose). This way your WAN can be physically isolated from your LAN(s) and it will not need to go through that switch.
  3. purchase a different switch. The TP-Link TL-SG1xxE series is the only one that I know of that has this really poorly designed management firmware. Almost any other managed switch should be better than this (including the low end Netgear, DLink, and others).

I'd recommend #2 as the best solution. #1 is obviously the cheapest. And #3 is worth considering, but if security within your network (behind your router/firewall) isn't a huge concern, there may not be a need to replace the switch.


+ netgear gs-308e

1 Like

Good to know. Thanks.

1 Like

Hi All,

Thanks for your replies. The switch is not on dhcp it has a static ip. But still the problem exists. However I do have a UE300 I use with my laptop now and then. So I will give that a try.

Didn’t know the firmware of the switches is poor, I always used them as a dump switch/hub.
Learned something today :wink:

I’ll let you know how it goes

When I use the UE300 for WAN the RPi does get an ip from my isp. So I think it's probably the cheap ass switch I use :wink:

The only thing is that the jitter and bufferbloat is increasing significant, even when using SQM.(it's a little beter but not enough)

With Vlan jitter is 3-5ms and on load increases to 10-12ms
On UE300 jitter is 20-50ms and on load 70-100ms (with SQM)

So for the time being am back to my old config. So I can shop for a good switch. (I use two TLSG, so I'm looking for an 16 port switch, any suggestions?)

By the way, Is there a way I can check if my vlan WAN is bypassing my firewall and/or is leaking somehow?

If you were using the switch as an unmanaged device (i.e. all on ports on the one untagged network), that would actually be the root of your issue. For your setup, you must configure VLANs on the switch and the Pi.

However, everything I said earlier about this switch still stands, and the UE300 is the better option for your physical configuration.

As far as 16 port switches -- there are tons. You need to select one based on your specific needs: Do you need it to be managed (i.e. VLAN capable)? do you need any advanced management features, or is basic VLAN sufficient? What about PoE? If PoE, how many ports? What PoE standard(s)? What total power budget? And form factor (desktop/wall mount/rack mount)?

I meant that I used them as regular switch before I had the need for a vlan config. I just didn’t know the ones I have is a bad choice for a vlan config.

Basic vlan is just fine, I don’t need PoE
Just as I mentioned, I now use two x 8 port switch, so two with 8 or beter a 16 - 24 ports. I have them mounted on a wall. 200-300 euro’s is not a problem.

If you have the loop detection enabled then it will send out loop detection packets on all ports, and the modem will lock to the MAC address of the switch and refuse to respond to your RPi's mac address.

using the UE300 is the best option, if you need to use the switch do several things:

  1. Turn off loop detection
  2. put the switch in static IP mode with a static IP on your internal network range, but preferably not the or range (make the "attackers" guess more)
  3. Set a cryptographically strong password, like one generated by keepassxc or similar strong password keeper app. I'd suggest 12 characters random upper/lower/numbers
  4. Follow the "modem dance". Turn off modem, disconnect ethernet cord. Turn on modem, wait for it to boot. Reconnect ethernet cord... It should lock to the MAC of the first thing it hears, which should be your RPi4 if the VLANs are set up correctly and no loopback detection.

I personally think with a non-standard non-public IP on the switch, and a cryptographically strong password, the security is probably not worth worrying about. Compromising the switch would require someone to compromise the ISP modem and then from the modem the switch... or compromise your router first and then the switch... With a crypto-strong password most compromises are unlikely.

1 Like

I did disable the loop detection as you suggested. I wil give it try somewhere this week.

On thing is keeping me busy.. When the modem of my ISP is in routermode, the RPi is getting an IP as it should be. But when I put in bridge mode is doesn't. (and a single connected device does) So maybe it's a combined problem?

This is to be expected due to how DOCSIS provisioning works. In bridge mode modem will only provision a few MACs with IP addresses (often just a single one) and often only for a limited time window. If any device first gets noticed by the modem that single slot can be assigned already when your router gets around to ask the modem. ISPs could configure modems to allow more than one MAC address, but apparently rarely do so. DOCSIS provisioning is quite an elaborate dance :wink:

In router mode that is different as the modem-routers DHCP server will allow many more that 1 devices and will also do so as long as the router is running (modulo any bugs).

1 Like