Bridge Mode - LTE USB Modem

The modem and eth port must be only in that bridge. Then the other router will use it as its WAN. The Pi cannot be directly connected to the Internet, when you get to that point in the setup, it has to loop through the other router.

By convention, use only lowercase in interface names. (Luci shows them in all caps, which is confusing.)

Isn't it the case (according to the screenshots)??? :worried:

Should I add firewall rules???

EDIT:
Can't I setup a rule somewhere that would only allow a specific MAC address to ask for/receive the internet IP?

This usually won't work. The wwan0 interface is not an ethernet interface, even if it might appear like one in some cases. That's an illusion created by the modem firmware and/or driver. But the illusion is not perfect and does not necessarily support clients with a mac address different from the fake wwan0 one.

You are better off with a half-bridge. Maybe relayd will work? See https://openwrt.org/docs/guide-user/network/wifi/relay_configuration

Or you can create something similar using routing rules, proxy-arp and a local dhcp server on the Pi.

2 Likes

Is that because wwan0 is created using a usb interface? How about minipcie based modem?

@Tantalum, I am trying to do the same and found this.

Minipcie slots have USB 2.0 data lanes too, usually used by the modem cards.
I don't think this changes with M.2 (NGFF) modems either, as there is USB 2.0 and USB 3.0 mode in that interface, again usually used by the modems.

1 Like

No, it's because the mobile network connection is on layer 3. If you want to see it as a layer 2 interface, then you have ot fake that. Which is what many modems and/or drivers do.

1 Like

Can you elaborate more on this please? Are you talking about setting a static route between PI and downstream router and why is a dhcp required on PI?

You need more than just a route. You need default routing in both directions, which means that you need rules based on ingress interface.

DHCP is of course optional. But it makes the setup more convenient by automatically forwarding the IP configuration from the modem to the client. This assumes that you create the necessary modem connection scripts to make a DHCP configuration every time the modem changes its address

1 Like

Thanks. Will this setup cause double NAT for the clients behind the downstream router?

I tried this on OpenWrt but was not able to get it to work. My config below. Any advice?

config interface 'wan'
	option ifname 'eth1'
	option proto 'static'
	option ipaddr '0.0.0.0'
	option netmask '0.0.0.0'
	option gateway '10.68.168.226'        # IP address given by the MNO
	option dns '10.5.133.45 10.4.27.70'   # DNS given by the MNO

/etc/config/dhcp

config dhcp 'wan'
	option interface 'wan'
	option start '100'
	option limit '100'
	option leasetime '2m'
	option netmask '255.255.255.248'

Result: When I hook up a client device no DHCP is given to the client because the modem has already taken it - I get an error "this IP is already being used by another device".

I don't know how to configure it using uci, but setting up something similar to this should work (I just tried tried it right now):

root@OpenWrt:~# ip link add link eth0 name eth0.9 type vlan id 9
root@OpenWrt:~# brctl addbr br-foo
root@OpenWrt:~# brctl addif br-foo eth0.9
root@OpenWrt:~# ip link set eth0.9 up
root@OpenWrt:~# ip link set br-foo up

root@OpenWrt:~# swconfig dev switch0 vlan 9 set ports '4t 5t'
root@OpenWrt:~# swconfig dev switch0 set apply 1

root@OpenWrt:~# mmcli -m 0 --simple-connect=apn=telenor.smart,ip-type=ipv4v6
root@OpenWrt:~# mmcli -b 1
  --------------------------------
  General            |  dbus path: /org/freedesktop/ModemManager1/Bearer/1
                     |       type: default
  --------------------------------
  Status             |  connected: yes
                     |  suspended: no
                     |  interface: wwan0
                     | ip timeout: 20
  --------------------------------
  Properties         |        apn: telenor.smart
                     |    roaming: allowed
                     |    ip type: ipv4v6
  --------------------------------
  IPv4 configuration |     method: static
                     |    address: 10.195.138.65
                     |     prefix: 30
                     |    gateway: 10.195.138.66
                     |        dns: 193.213.112.4, 130.67.15.198
                     |        mtu: 1500
  --------------------------------
  IPv6 configuration |     method: static
                     |    address: 2a02:2121:28a:b893:bc8e:ed5d:115c:426a
                     |     prefix: 64
                     |    gateway: 2a02:2121:28a:b893:3cd1:8fe3:11c0:ef4c
                     |        dns: 2001:4600:4:fff::52, 2001:4600:4:1fff::52
                     |        mtu: 1540

root@OpenWrt:~# ip link set wwan0 up
root@OpenWrt:~# ip route add 10.195.138.64/30 dev br-foo
root@OpenWrt:~# ip route add 2a02:2121:28a:b893::/64 dev br-foo
root@OpenWrt:~# ip route add default dev wwan0 table 9
root@OpenWrt:~# ip -6 route add default dev wwan0 table 9
root@OpenWrt:~# ip rule add iif br-foo lookup 9 pref 10000
root@OpenWrt:~# ip -6 rule add iif br-foo lookup 9 pref 10000
root@OpenWrt:~# sysctl net.ipv4.conf.br-foo.proxy_arp=1
root@OpenWrt:~# sysctl net.ipv4.conf.br-foo.proxy_arp_pvlan=1

root@OpenWrt:~# iptables -I FORWARD -i br-foo -j ACCEPT
root@OpenWrt:~# iptables -I FORWARD -i wwan0 -j ACCEPT
root@OpenWrt:~# iptables -t nat -I POSTROUTING -o wwan0 -j ACCEPT

Note that you obviously should have saner firewall rules. And that this is missing the dhcp server config. Which really should be trivial, except that there doesn't seem to be a way to use dnsmasq for this since it makes too many assumptions. And you can of course don't have to configure vlan 9 for your inside interface. That was just for my test. The inside interface could be anything. But it will only support one IPv4 client.

I'm close, but the client device (Mac computer in this case) cannot access the Internet.

root@OpenWrt:~# ifconfig
br-lan    Link encap:Ethernet  HWaddr 20:0D:B0:B1:50:11  
          inet addr:192.168.1.1  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: fd53:a2e8:46c7::1/60 Scope:Global
          inet6 addr: fe80::220d:b0ff:feb1:5011/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1042 errors:0 dropped:0 overruns:0 frame:0
          TX packets:254 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:129240 (126.2 KiB)  TX bytes:30153 (29.4 KiB)

br-lan:0  Link encap:Ethernet  HWaddr 20:0D:B0:B1:50:11  
          inet addr:120.157.35.78  Bcast:120.157.35.79  Mask:255.255.255.248
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

eth0      Link encap:Ethernet  HWaddr 20:0D:B0:B1:50:11  
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:644 errors:0 dropped:0 overruns:0 frame:0
          TX packets:148 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:93915 (91.7 KiB)  TX bytes:30780 (30.0 KiB)
          Interrupt:5 

eth1      Link encap:Ethernet  HWaddr 20:0D:B0:B1:50:0F  
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
          Interrupt:4 

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:1281 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1281 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:125002 (122.0 KiB)  TX bytes:125002 (122.0 KiB)

wlan0     Link encap:Ethernet  HWaddr 20:0D:B0:B1:50:10  
          inet6 addr: fe80::220d:b0ff:feb1:5010/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:397 errors:0 dropped:0 overruns:0 frame:0
          TX packets:490 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:50037 (48.8 KiB)  TX bytes:102449 (100.0 KiB)

wwan0     Link encap:Ethernet  HWaddr 8A:1A:A5:AF:37:62  
          inet addr:120.157.35.73  Bcast:120.157.35.75  Mask:255.255.255.252
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:29 errors:0 dropped:0 overruns:0 frame:0
          TX packets:14 errors:420 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:1144 (1.1 KiB)  TX bytes:1872 (1.8 KiB)
root@OpenWrt:~# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         120.157.35.74   0.0.0.0         UG    0      0        0 wwan0
default         120.157.35.74   0.0.0.0         UG    0      0        0 wwan0
120.157.35.72   *               255.255.255.252 U     0      0        0 wwan0
120.157.35.72   *               255.255.255.248 U     0      0        0 br-lan
120.157.35.73   *               255.255.255.255 UH    0      0        0 br-lan
120.157.35.74   *               255.255.255.255 UH    0      0        0 wwan0
192.168.1.0     *               255.255.255.0   U     0      0        0 br-lan

Hello

I wanted to ask if someone managed to make the bridge mode work with a LTE modem?

I read that some people made it work using modemmanager:
https://s4gru.com/forums/topic/7844-build-your-own-devices-routers-relays-iot-etc/page/2/?tab=comments#comment-536006

But I getting an error message:
1

I also found a solution on a German forum from someone who actually modified dnsmaq (actually dhcp.c file), in order to make the bridge work (I don't really know how).

But I couldn't make it work either :-/

Is there really no easy solution?

It seems that one of the solutions mentioned was authored by @Westrem
I'll be interested to test his build if the project is still alive.

Why doesn't adding the modemmanager-controlled wwan0 into the br-lan bridge work?

Because wwan0 isn't a real ethernet device, and the driver/firmware doesn't support addressing non-local ethernet hosts

I see. So if I understand your idea from earlier, and please correct me if I am wrong, the strategy to get this "pseudo bridging" to work is to create a new bridge which will be able to address non-local hosts (I presume because it will be using the regular Linux networking driver then it is capable of doing proxy_arp), and that this new bridge interface will have the route to the network held by the wwan0 interface.

I am trying to do it just using eth1 for simplification in a proof of concept. I set a default route via wwan0 (which appears to be connected according to ModemManager). but I am unable to get any packets out to any non-local network at all, so I am feeling very confused at the moment.

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         0.0.0.0         0.0.0.0         U     0      0        0 wwan0
120.157.29.40   0.0.0.0         255.255.255.252 U     0      0        0 eth1
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 br-lan
root@OpenWrt:~# ip -c route
default dev wwan0 scope link 
120.157.29.40/30 dev eth1 scope link 
192.168.1.0/24 dev br-lan proto kernel scope link src 192.168.1.1 
root@OpenWrt:~# mmcli -b 0
  ------------------------------------
  General            |      dbus path: /org/freedesktop/ModemManager1/Bearer/0
                     |           type: default
  ------------------------------------
  Status             |      connected: yes
                     |      suspended: no
                     |      interface: wwan0
                     |     ip timeout: 20
  ------------------------------------
  Properties         |            apn: telstra.extranet
                     |        roaming: allowed
  ------------------------------------
  IPv4 configuration |         method: static
                     |        address: 120.157.29.41
                     |         prefix: 30
                     |        gateway: 120.157.29.42
                     |            dns: 10.4.149.70, 10.4.130.164
                     |            mtu: 1500
  ------------------------------------
  Statistics         |       duration: 2070
                     |       bytes rx: 7807
                     |       bytes tx: 1440
                     |       attempts: 1
                     | total-duration: 2070
                     | total-bytes rx: 7807
                     | total-bytes tx: 1440

Did you enable IP forwarding on wwan0 and eth1, and proxy arp on eth1? All these should return 1:

 grep . /proc/sys/net/ipv4/conf/eth1/proxy_arp
 grep . /proc/sys/net/ipv4/conf/eth1/forwarding
 grep . /proc/sys/net/ipv4/conf/wwan0/forwarding

Make sure you don't have any iptables rules blocking the traffic. Might be easiest to just let anything through these interfaces while you are testing, but make sure to fix that before you put this into production.

An "LTE bridge" is nothing more than an ordinary router with proxy arp enabled on the LAN. And most often, for convenience, a DHCP server config generated from the values assigned by the LTE network. There is nothing magic to this.

You might want to tune the ARP and DHCP timeouts based on the fact that there will be only one IPv4 address to play with on the LAN side, but that limitation is pretty much the only thing special about the setup.

It's obviously even simpler for IPv6, where you will have 2^64 addresses and therefore can serve as many clients as you like. You can even use a couple of those addresses for the router.

Just for information, someone on a German forum, arrived to make the bridge mode to work in MBIM mode, by slightly modifying the source code of dnsmasq.
Apparently it works.

Hey Bjørn, thanks for having a look. Here's what I have at the moment, still cannot access internet from the host, which I have configured statically with the IP configuration of wwan0, and which is connected to eth1.

I have stopped/disabled mwan3 and firewall for testing.

root@OpenWrt:~# ip rule
0: from all lookup local
5042: from all iif eth1 lookup 42
5043: from all iif wwan0 lookup 43
32766: from all lookup main
32767: from all lookup default

root@OpenWrt:~# ip route
default via 120.157.99.120 dev wwan0 proto static src 120.157.99.119 metric 50 
120.157.99.112/28 dev eth1 scope link 
120.157.99.112/28 dev wwan0 proto static scope link metric 50 
192.168.1.0/24 dev br-lan proto kernel scope link src 192.168.1.1 
root@OpenWrt:~# mmcli -b 1
  ------------------------------------
  General            |      dbus path: /org/freedesktop/ModemManager1/Bearer/1
                     |           type: default
  ------------------------------------
  Status             |      connected: yes
                     |      suspended: no
                     |      interface: wwan0
                     |     ip timeout: 20
  ------------------------------------
  Properties         |        roaming: allowed
  ------------------------------------
  IPv4 configuration |         method: static
                     |        address: 120.157.99.119
                     |         prefix: 28
                     |        gateway: 120.157.99.120
                     |            dns: 10.4.130.164, 10.4.149.70
                     |            mtu: 1500
  ------------------------------------
  Statistics         |       duration: 2009
                     |       bytes rx: 1419238
                     |       bytes tx: 481595
                     |       attempts: 1
                     | total-duration: 2009
                     | total-bytes rx: 1419238
                     | total-bytes tx: 481595
root@OpenWrt:~# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: seq=0 ttl=115 time=83.401 ms

root@OpenWrt:~#  grep . /proc/sys/net/ipv4/conf/eth1/proxy_arp
1
root@OpenWrt:~#  grep . /proc/sys/net/ipv4/conf/eth1/forwarding
1
root@OpenWrt:~#  grep . /proc/sys/net/ipv4/conf/wwan0/forwarding
1