Can't get AX86U to work with bridged router (Link DOWN)

[Neo-ST]

Hi all, new here.

I'm having problems with connecting a brand new AX86U with my 4G router set in bridge mode.
Steps I've taken:
- Set my 4G router (Teltonika RUTX09) into bridge mode (straightforward process, just needed to type in MAC address of my Asus)
- Enabled DHCP server on LAN on Teltonika (otherwise it won't work)
- Set Teltonika to static address 192.168.1.1
- Asus is on 192.168.50.1
- On Asus in WAN - Wan Connection type, set to Automatic
- On same page, set DNS to Google's
- On LAN settings, DHCP server is enabled

Then:
- Plugged RUTX09 to Asus' WAN port
- I can access RUTX09 normally, log shows mobile connection established, bridge mode working
- In Asus dashboard, network map shows external WAN IP (which is good) - connection established, I have access to Internet
- RUTX09 assigns 192.168.1.139 to be WAN IP for Asus

However, after a few minutes, problems start.
Constant connection drops, in log visible as "Link DOWN". Multiple times it tries to re-establish connection, succeeds eventually after 4-5 tries. Then access to Internet is restored but not for long, again after a few minutes the problems start, and so on in circle...

I'm not sure why is this happening. Is there any specific setting that I didn't set properly or messed up ? If so, which one?

Note:
I tried connecting RUTX09 with bridge mode enabled directly to my PC, and it works flawlessly, no connection drops, so it's not RUT's problem.
Problems start after connecting it to Asus.

Clean log of Asus, before disconnects start to happen till the connection restore:

Spoiler: Code

Dec 19 19:07:39 kernel: eth0 (Int switch port: 0) (Logical Port: 0) (phyId: 1) Link DOWN.
Dec 19 19:07:44 WAN(0) Connection: WAN(0) link down.
Dec 19 19:07:46 kernel: eth0 (Int switch port: 0) (Logical Port: 0) (phyId: 1) Link Up at 1000 mbps full duplex
Dec 19 19:07:47 WAN(0) Connection: WAN(0) link up.
Dec 19 19:07:47 rc_service: wanduck 1521:notify_rc restart_wan_if 0
Dec 19 19:07:53 wan: finish adding multi routes
Dec 19 19:07:56 BWDPI: force to flush flowcache entries
Dec 19 19:07:56 kernel: udb_core lock_num = 4
Dec 19 19:07:56 WAN(0) Connection: WAN was restored.
Dec 19 19:07:56 BWDPI: rollback fc
Dec 19 19:07:58 kernel: SHN Release Version: 2.0.7 371dd35_RELS_8
Dec 19 19:07:58 kernel: UDB Core Version: 0.2.20
Dec 19 19:07:58 kernel: Registered DNS Req parsing
Dec 19 19:07:58 kernel: sizeof forward pkt param = 280
Dec 19 19:07:58 BWDPI: fun bitmap = 4bf
Dec 19 19:07:58 A.QoS: qos_count=0, qos_check=0
Dec 19 19:08:01 rc_service: udhcpc_wan 23447:notify_rc stop_samba
Dec 19 19:08:01 Samba Server: smb daemon is stopped
Dec 19 19:08:02 rc_service: udhcpc_wan 23447:notify_rc start_samba
Dec 19 19:08:03 dhcp client: bound 192.168.1.139/255.255.255.0 via 192.168.1.1 for 43200 seconds.
Dec 19 19:08:09 kernel: eth0 (Int switch port: 0) (Logical Port: 0) (phyId: 1) Link DOWN.
Dec 19 19:08:12 kernel: eth0 (Int switch port: 0) (Logical Port: 0) (phyId: 1) Link Up at 1000 mbps full duplex
Dec 19 19:08:14 WAN(0) Connection: WAN(0) link up.
Dec 19 19:08:14 rc_service: wanduck 1521:notify_rc restart_wan_if 0
Dec 19 19:08:22 kernel: eth0 (Int switch port: 0) (Logical Port: 0) (phyId: 1) Link DOWN.
Dec 19 19:08:25 kernel: eth0 (Int switch port: 0) (Logical Port: 0) (phyId: 1) Link Up at 1000 mbps full duplex
Dec 19 19:08:25 wlceventd: wlceventd_proc_event(662): eth6: Disassoc A8:xxxxxx:52, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Dec 19 19:08:25 wlceventd: wlceventd_proc_event(645): eth6: Deauth_ind A8:xxxxxxx:52, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3), rssi:0
Dec 19 19:08:26 WAN(0) Connection: WAN(0) link up.
Dec 19 19:08:26 rc_service: wanduck 1521:notify_rc restart_wan_if 0
Dec 19 19:08:46 kernel: eth0 (Int switch port: 0) (Logical Port: 0) (phyId: 1) Link DOWN.
Dec 19 19:08:48 kernel: eth0 (Int switch port: 0) (Logical Port: 0) (phyId: 1) Link Up at 1000 mbps full duplex
Dec 19 19:08:50 WAN(0) Connection: WAN(0) link up.
Dec 19 19:08:50 rc_service: wanduck 1521:notify_rc restart_wan_if 0
Dec 19 19:08:50 kernel: eth0 (Int switch port: 0) (Logical Port: 0) (phyId: 1) Link DOWN.
Dec 19 19:08:50 rc_service: cfg_server 2387:notify_rc update_nbr
Dec 19 19:08:50 rc_service: waitting "restart_wan_if 0" via wanduck ...
Dec 19 19:08:53 kernel: eth0 (Int switch port: 0) (Logical Port: 0) (phyId: 1) Link Up at 1000 mbps full duplex
Dec 19 19:08:56 WAN(0) Connection: WAN(0) link up.
Dec 19 19:08:56 rc_service: wanduck 1521:notify_rc restart_wan_if 0
Dec 19 19:09:04 wan: finish adding multi routes
Dec 19 19:09:05 WAN(0) Connection: WAN was restored.
Dec 19 19:09:07 BWDPI: force to flush flowcache entries
Dec 19 19:09:07 kernel: udb_core lock_num = 4
Dec 19 19:09:07 BWDPI: rollback fc
Dec 19 19:09:09 kernel: SHN Release Version: 2.0.7 371dd35_RELS_8
Dec 19 19:09:09 kernel: UDB Core Version: 0.2.20
Dec 19 19:09:09 kernel: Registered DNS Req parsing
Dec 19 19:09:09 kernel: sizeof forward pkt param = 280
Dec 19 19:09:09 BWDPI: fun bitmap = 4bf
Dec 19 19:09:09 A.QoS: qos_count=0, qos_check=0
Dec 19 19:09:11 kernel: eth0 (Int switch port: 0) (Logical Port: 0) (phyId: 1) Link DOWN.
Dec 19 19:09:12 rc_service: udhcpc_wan 24852:notify_rc stop_samba
Dec 19 19:09:12 Samba Server: smb daemon is stopped
Dec 19 19:09:13 rc_service: udhcpc_wan 24852:notify_rc start_samba
Dec 19 19:09:14 dhcp client: bound 192.168.1.139/255.255.255.0 via 192.168.1.1 for 43200 seconds.
Dec 19 19:09:17 WAN(0) Connection: WAN(0) link down.
Dec 19 19:09:18 kernel: eth0 (Int switch port: 0) (Logical Port: 0) (phyId: 1) Link Up at 1000 mbps full duplex
Dec 19 19:09:20 WAN(0) Connection: WAN(0) link up.
Dec 19 19:09:20 rc_service: wanduck 1521:notify_rc restart_wan_if 0
Dec 19 19:09:22 wan: finish adding multi routes
Dec 19 19:09:23 WAN(0) Connection: WAN was restored.
Dec 19 19:09:25 BWDPI: force to flush flowcache entries
Dec 19 19:09:25 kernel: udb_core lock_num = 3
Dec 19 19:09:25 BWDPI: rollback fc
Dec 19 19:09:27 kernel: SHN Release Version: 2.0.7 371dd35_RELS_8
Dec 19 19:09:27 kernel: UDB Core Version: 0.2.20
Dec 19 19:09:27 kernel: Registered DNS Req parsing
Dec 19 19:09:27 kernel: sizeof forward pkt param = 280
Dec 19 19:09:27 BWDPI: fun bitmap = 4bf
Dec 19 19:09:27 A.QoS: qos_count=0, qos_check=0
Dec 19 19:09:30 rc_service: udhcpc_wan 25758:notify_rc stop_samba
Dec 19 19:09:30 Samba Server: smb daemon is stopped
Dec 19 19:09:31 rc_service: udhcpc_wan 25758:notify_rc start_samba
Dec 19 19:09:32 dhcp client: bound 10.xxxxxxx/255.255.255.248 via 10.xxxxxxx for 3600 seconds.

Screenshot of WAN settings in Asus:

So if someone can solve this mistery, I'd be grateful. I thought I bought a good (and expensive) router, but so far it rejects to work the way I'd want it.

The only way it works properly with RUTX09 is if they're both in router mode and then I have double NAT which I don't want.

Thanks

 

[ColinTaylor]

This is an issue with your RUTX09. It is physically dropping the network connection to the router.

 

[Neo-ST]

This is an issue with your RUTX09. It is physically dropping the network connection to the router.

Ok, can you be more specific, which part of system log proves it's RUT's issue? It'll help me in debate with support over on their forums. Thanks.

P.S.
My ISP uses cg-nat, could that be causing these problems ?

 

[ColinTaylor]

Ok, can you be more specific, which part of system log proves it's RUT's issue? It'll help me in debate with support over on their forums. Thanks.

Dec 19 19:07:39 kernel: eth0 (Int switch port: 0) (Logical Port: 0) (phyId: 1) Link DOWN.
Dec 19 19:07:46 kernel: eth0 (Int switch port: 0) (Logical Port: 0) (phyId: 1) Link Up at 1000 mbps full duplex
Dec 19 19:08:09 kernel: eth0 (Int switch port: 0) (Logical Port: 0) (phyId: 1) Link DOWN.
Dec 19 19:08:12 kernel: eth0 (Int switch port: 0) (Logical Port: 0) (phyId: 1) Link Up at 1000 mbps full duplex
Dec 19 19:08:22 kernel: eth0 (Int switch port: 0) (Logical Port: 0) (phyId: 1) Link DOWN.
Dec 19 19:08:25 kernel: eth0 (Int switch port: 0) (Logical Port: 0) (phyId: 1) Link Up at 1000 mbps full duplex
Dec 19 19:08:46 kernel: eth0 (Int switch port: 0) (Logical Port: 0) (phyId: 1) Link DOWN.
Dec 19 19:08:48 kernel: eth0 (Int switch port: 0) (Logical Port: 0) (phyId: 1) Link Up at 1000 mbps full duplex
Dec 19 19:08:50 kernel: eth0 (Int switch port: 0) (Logical Port: 0) (phyId: 1) Link DOWN.
Dec 19 19:08:53 kernel: eth0 (Int switch port: 0) (Logical Port: 0) (phyId: 1) Link Up at 1000 mbps full duplex
Dec 19 19:09:11 kernel: eth0 (Int switch port: 0) (Logical Port: 0) (phyId: 1) Link DOWN.
Dec 19 19:09:18 kernel: eth0 (Int switch port: 0) (Logical Port: 0) (phyId: 1) Link Up at 1000 mbps full duplex

Does the RUT have a system log that you can check?

P.S.
My ISP uses cg-nat, could that be causing these problems ?

That shouldn't cause a problem. There are plenty of Asus owners using their routers with CGNAT.

P.S. You said the Asus' Network Map shows it has an external (i.e. public) WAN IP but that contradicts everything else you said. i.e. it's WAN IP was 192.168.1.139, the log also showing it getting a 10.xxxxxxx address and your screenshot showing a static address of 192.168.1.10.

 

[Neo-ST]

Dec 19 19:07:39 kernel: eth0 (Int switch port: 0) (Logical Port: 0) (phyId: 1) Link DOWN.
Dec 19 19:07:46 kernel: eth0 (Int switch port: 0) (Logical Port: 0) (phyId: 1) Link Up at 1000 mbps full duplex
Dec 19 19:08:09 kernel: eth0 (Int switch port: 0) (Logical Port: 0) (phyId: 1) Link DOWN.
Dec 19 19:08:12 kernel: eth0 (Int switch port: 0) (Logical Port: 0) (phyId: 1) Link Up at 1000 mbps full duplex
Dec 19 19:08:22 kernel: eth0 (Int switch port: 0) (Logical Port: 0) (phyId: 1) Link DOWN.
Dec 19 19:08:25 kernel: eth0 (Int switch port: 0) (Logical Port: 0) (phyId: 1) Link Up at 1000 mbps full duplex
Dec 19 19:08:46 kernel: eth0 (Int switch port: 0) (Logical Port: 0) (phyId: 1) Link DOWN.
Dec 19 19:08:48 kernel: eth0 (Int switch port: 0) (Logical Port: 0) (phyId: 1) Link Up at 1000 mbps full duplex
Dec 19 19:08:50 kernel: eth0 (Int switch port: 0) (Logical Port: 0) (phyId: 1) Link DOWN.
Dec 19 19:08:53 kernel: eth0 (Int switch port: 0) (Logical Port: 0) (phyId: 1) Link Up at 1000 mbps full duplex
Dec 19 19:09:11 kernel: eth0 (Int switch port: 0) (Logical Port: 0) (phyId: 1) Link DOWN.
Dec 19 19:09:18 kernel: eth0 (Int switch port: 0) (Logical Port: 0) (phyId: 1) Link Up at 1000 mbps full duplex

Does the RUT have a system log that you can check?


That shouldn't cause a problem. There are plenty of Asus owners using their routers with CGNAT.

P.S. You said the Asus' Network Map shows it has an external (i.e. public) WAN IP but that contradicts everything else you said. i.e. it's WAN IP was 192.168.1.139, the log also showing it getting a 10.xxxxxxx address and your screenshot showing a static address of 192.168.1.10.

Yes, here's RUT sys log (don't mind the date, log was cleaned before reboot). Attached because too long to paste here.

 

[ColinTaylor]

I am not familiar with your RUT device. It looks like it's bouncing it's interfaces multiple times when it boots up and switches to bridged mode. That is probably the cause of all the LINK DOWN/UP messages in the Asus' System Log.

In any case the RUT ends up giving an IP address of 10.x.x.x to the Asus. Both of the log files end at this point so I don't know what problem you have after this.

You don't need to obscure the 10.x.x.x addresses in your log files because that is a private IP address not a public IP address. You said you were getting a public IP address but I can't see any evidence of that.

 

[Neo-ST]

I am not familiar with your RUT device. It looks like it's bouncing it's interfaces multiple times when it boots up and switches to bridged mode. That is probably the cause of all the LINK DOWN/UP messages in the Asus' System Log.

In any case the RUT ends up giving an IP address of 10.x.x.x to the Asus. Both of the log files end at this point so I don't know what problem you have after this.

After that the connection works for a while, then just restarts on Asus (link down).

You don't need to obscure the 10.x.x.x addresses in your log files because that is a private IP address not a public IP address. You said you were getting a public IP address but I can't see any evidence of that.

I just learned that now (I'm noob)
I'll see with guys from Teltonika what they have to say on this.

Thanks for your time.

 

[ColinTaylor]

Looking at the RUT's manual I don't understand the difference between Bridge and Passthrough mode. Try using Passthrough mode and seeing if the Asus gets a different WAN IP address.

 

[Neo-ST]

Looking at the RUT's manual I don't understand the difference between Bridge and Passthrough mode. Try using Passthrough mode and seeing if the Asus gets a different WAN IP address.

I too don't understand what's Passthrough mode.

In Passthrough mode, there are two options.

OPTION 1 - with "disable DHCP" set to ON
In this mode, RUT doesn't give option to type in MAC address of recipient WAN device.
Looks like this:

Spoiler: Picture 1

In this mode, Asus gets a local IP:

And this is log after plugging in RUT and turning it on:

Spoiler: Log

Dec 19 22:45:09 kernel: eth0 (Int switch port: 0) (Logical Port: 0) (phyId: 1) Link Up at 1000 mbps full duplex
Dec 19 22:45:11 WAN(0) Connection: WAN(0) link up.
Dec 19 22:45:11 rc_service: wanduck 1521:notify_rc restart_wan_if 0
Dec 19 22:45:17 wan: finish adding multi routes
Dec 19 22:45:17 WAN(0) Connection: WAN was restored.
Dec 19 22:45:19 BWDPI: force to flush flowcache entries
Dec 19 22:45:19 kernel: udb_core lock_num = 3
Dec 19 22:45:20 BWDPI: rollback fc
Dec 19 22:45:22 kernel: SHN Release Version: 2.0.7 371dd35_RELS_8
Dec 19 22:45:22 kernel: UDB Core Version: 0.2.20
Dec 19 22:45:22 kernel: Registered DNS Req parsing
Dec 19 22:45:22 kernel: sizeof forward pkt param = 280
Dec 19 22:45:22 BWDPI: fun bitmap = 4bf
Dec 19 22:45:22 A.QoS: qos_count=0, qos_check=0
Dec 19 22:45:25 rc_service: udhcpc_wan 11195:notify_rc stop_samba
Dec 19 22:45:25 Samba Server: smb daemon is stopped
Dec 19 22:45:26 rc_service: udhcpc_wan 11195:notify_rc start_samba
Dec 19 22:45:27 dhcp client: bound 192.168.1.139/255.255.255.0 via 192.168.1.1 for 43200 seconds.
Dec 19 22:45:29 kernel: eth0 (Int switch port: 0) (Logical Port: 0) (phyId: 1) Link DOWN.
Dec 19 22:45:32 kernel: eth0 (Int switch port: 0) (Logical Port: 0) (phyId: 1) Link Up at 1000 mbps full duplex
Dec 19 22:45:33 WAN(0) Connection: WAN(0) link up.
Dec 19 22:45:33 rc_service: wanduck 1521:notify_rc restart_wan_if 0
Dec 19 22:45:41 kernel: eth0 (Int switch port: 0) (Logical Port: 0) (phyId: 1) Link DOWN.
Dec 19 22:45:45 WAN(0) Connection: WAN(0) link down.
Dec 19 22:45:45 kernel: eth0 (Int switch port: 0) (Logical Port: 0) (phyId: 1) Link Up at 1000 mbps full duplex
Dec 19 22:45:48 WAN(0) Connection: WAN(0) link up.
Dec 19 22:45:48 rc_service: wanduck 1521:notify_rc restart_wan_if 0
Dec 19 22:46:05 kernel: eth0 (Int switch port: 0) (Logical Port: 0) (phyId: 1) Link DOWN.
Dec 19 22:46:08 kernel: eth0 (Int switch port: 0) (Logical Port: 0) (phyId: 1) Link Up at 1000 mbps full duplex
Dec 19 22:46:09 WAN(0) Connection: WAN(0) link up.
Dec 19 22:46:09 rc_service: wanduck 1521:notify_rc restart_wan_if 0
Dec 19 22:46:10 kernel: eth0 (Int switch port: 0) (Logical Port: 0) (phyId: 1) Link DOWN.
Dec 19 22:46:13 kernel: eth0 (Int switch port: 0) (Logical Port: 0) (phyId: 1) Link Up at 1000 mbps full duplex
Dec 19 22:46:15 WAN(0) Connection: WAN(0) link up.
Dec 19 22:46:15 rc_service: wanduck 1521:notify_rc restart_wan_if 0
Dec 19 22:46:24 wan: finish adding multi routes
Dec 19 22:46:24 WAN(0) Connection: WAN was restored.
Dec 19 22:46:26 BWDPI: force to flush flowcache entries
Dec 19 22:46:26 kernel: udb_core lock_num = 3
Dec 19 22:46:26 BWDPI: rollback fc
Dec 19 22:46:28 kernel: SHN Release Version: 2.0.7 371dd35_RELS_8
Dec 19 22:46:28 kernel: UDB Core Version: 0.2.20
Dec 19 22:46:28 kernel: Registered DNS Req parsing
Dec 19 22:46:28 kernel: sizeof forward pkt param = 280
Dec 19 22:46:28 BWDPI: fun bitmap = 4bf
Dec 19 22:46:29 A.QoS: qos_count=0, qos_check=0
Dec 19 22:46:31 kernel: eth0 (Int switch port: 0) (Logical Port: 0) (phyId: 1) Link DOWN.
Dec 19 22:46:32 rc_service: udhcpc_wan 12477:notify_rc stop_samba
Dec 19 22:46:32 Samba Server: smb daemon is stopped
Dec 19 22:46:33 rc_service: udhcpc_wan 12477:notify_rc start_samba
Dec 19 22:46:34 dhcp client: bound 192.168.1.139/255.255.255.0 via 192.168.1.1 for 43200 seconds.
Dec 19 22:46:36 WAN(0) Connection: WAN(0) link down.
Dec 19 22:46:37 kernel: eth0 (Int switch port: 0) (Logical Port: 0) (phyId: 1) Link Up at 1000 mbps full duplex
Dec 19 22:46:39 WAN(0) Connection: WAN(0) link up.
Dec 19 22:46:39 rc_service: wanduck 1521:notify_rc restart_wan_if 0
Dec 19 22:46:45 wan: finish adding multi routes
Dec 19 22:46:45 WAN(0) Connection: WAN was restored.
Dec 19 22:46:47 BWDPI: force to flush flowcache entries
Dec 19 22:46:47 kernel: udb_core lock_num = 3
Dec 19 22:46:47 BWDPI: rollback fc
Dec 19 22:46:49 kernel: SHN Release Version: 2.0.7 371dd35_RELS_8
Dec 19 22:46:49 kernel: UDB Core Version: 0.2.20
Dec 19 22:46:49 kernel: Registered DNS Req parsing
Dec 19 22:46:49 kernel: sizeof forward pkt param = 280
Dec 19 22:46:49 BWDPI: fun bitmap = 4bf
Dec 19 22:46:49 A.QoS: qos_count=0, qos_check=0
Dec 19 22:46:53 rc_service: udhcpc_wan 13427:notify_rc stop_samba
Dec 19 22:46:53 Samba Server: smb daemon is stopped
Dec 19 22:46:54 rc_service: udhcpc_wan 13427:notify_rc start_samba
Dec 19 22:46:55 dhcp client: bound 192.168.1.139/255.255.255.0 via 192.168.1.1 for 43200 seconds.

So far, everything works...but is this even bridge mode ? I'm confused.
In their description it says "in this mode the RUTX09 shares its WAN IP to a single LAN device (first connected to LAN or specified with MAC address). The LAN device will get WAN IP of RUTX09 instead of LAN IP." - I have 4 devices in my network and none of them has WAN IP instead of LAN IP. They all have local IPs given to them by Asus (192.168.50.-)


OPTION 2 - with "disable DHCP" set to OFF:

In this mode, RUT gives option to type in MAC address of recipient WAN device.
Looks like this:

Spoiler: Picture 2

I typed in Asus' MAC address.
I didn't type in lease time (probably defaults to 12h).

Now it gives it the "real" WAN IP:

Everything seems to work so far... just as it did in the different mode above, except now Asus has private WAN IP instead of local IP.
No errors in system log.

I can now conclude that I'm still confused, don't know why this works in Passthrough and not in Bridge mode (should be the same thing), also why Asus gets local ip with "disable dhcp ON", and private WAN with "disable dhcp OFF".

 

[ColinTaylor]

I think you will have to ask your 4G network provider whether they supply your mobile connection with a public IP address. I suspect that they don't - most mobile providers don't unless you have a specific contact that says it does. For comparison the 4G IP address of my mobile phone is 10.65.59.57 - not a public address.

So it sounds like there's nothing wrong with the IP address of your Asus or the RUT. Did your 4G network provider tell you you would have a public IP address?

How long after booting up your router do you have the problems? The passthrough/bridge IP address (10.114.x.y) is only getting a lease duration of 60 minutes, which is fairly normal for a mobile connection.

 

[Neo-ST]

I think you will have to ask your 4G network provider whether they supply your mobile connection with a public IP address. I suspect that they don't - most mobile providers don't unless you have a specific contact that says it does. For comparison the 4G IP address of my mobile phone is 10.65.59.57 - not a public address.

So it sounds like there's nothing wrong with the IP address of your Asus or the RUT. Did your 4G network provider tell you you would have a public IP address?

How long after booting up your router do you have the problems? The passthrough/bridge IP address (10.114.x.y) is only getting a lease duration of 60 minutes, which is fairly normal for a mobile connection.

They didn't tell me anything. I bought their prepaid flat mobile internet package with included SIM card. I need to top it up constantly for it to work. It's not one of those plans that require a contract.

I no longer have problems after I switched RUT into Passthrough mode. I'll have to ask Teltonika guys what's that all about.

 

[Neo-ST]

This was their answer to my question why bridge mode doesn't work in my environment, but passthrough mode does:

Hi,

Since you want to bridge the IP address of your SIM to a particular device (ASUS), Passthrough is preferable. It is commonly used when you have a specific device (like a server or another router) that needs a public IP address and requires direct access to the internet without any interference from the Teltonika router.

Hope this clears your doubts.

Regards,

 

[ColinTaylor]

So no answer then.

 

[Neo-ST]

So no answer then.

I gave up. Just glad everything works now.

That's LTE.

 

[Neo-ST]

Although everything seems to be working fine so far (not sure if consistently fine though), I saved system log from fresh reboot this morning to see if there are any errors during a longer period.

Does this look normal? I noticed Link UP/DOWN messages again, but they don't seem to interrupt connection (tested with streaming online radio).

Spoiler: Log

Dec 21 09:20:20 kernel: eth0 (Int switch port: 0) (Logical Port: 0) (phyId: 1) Link Up at 1000 mbps full duplex
Dec 21 09:20:20 WAN(0) Connection: WAN(0) link up.
Dec 21 09:20:20 rc_service: wanduck 1520:notify_rc restart_wan_if 0
Dec 21 09:20:42 kernel: eth0 (Int switch port: 0) (Logical Port: 0) (phyId: 1) Link DOWN.
Dec 21 09:20:44 kernel: eth0 (Int switch port: 0) (Logical Port: 0) (phyId: 1) Link Up at 1000 mbps full duplex
Dec 21 09:20:46 kernel: eth0 (Int switch port: 0) (Logical Port: 0) (phyId: 1) Link DOWN.
Dec 21 09:20:48 kernel: eth0 (Int switch port: 0) (Logical Port: 0) (phyId: 1) Link Up at 1000 mbps full duplex
Dec 21 09:20:50 WAN(0) Connection: WAN(0) link up.
Dec 21 09:20:50 rc_service: wanduck 1520:notify_rc restart_wan_if 0
Dec 21 09:20:59 wan: finish adding multi routes
Dec 21 09:20:59 WAN(0) Connection: WAN was restored.
Dec 21 09:21:01 BWDPI: force to flush flowcache entries
Dec 21 09:21:01 kernel: udb_core lock_num = 5
Dec 21 09:21:01 BWDPI: rollback fc
Dec 21 09:21:03 kernel: SHN Release Version: 2.0.7 371dd35_RELS_8
Dec 21 09:21:03 kernel: UDB Core Version: 0.2.20
Dec 21 09:21:03 kernel: Registered DNS Req parsing
Dec 21 09:21:03 kernel: sizeof forward pkt param = 280
Dec 21 09:21:03 BWDPI: fun bitmap = 4bf
Dec 21 09:21:03 A.QoS: qos_count=0, qos_check=0
Dec 21 09:21:07 dhcp client: bound 192.168.1.139/255.255.255.0 via 192.168.1.1 for 43200 seconds.
Dec 21 09:21:07 kernel: eth0 (Int switch port: 0) (Logical Port: 0) (phyId: 1) Link DOWN.
Dec 21 09:21:12 WAN(0) Connection: WAN(0) link down.
Dec 21 09:21:14 kernel: eth0 (Int switch port: 0) (Logical Port: 0) (phyId: 1) Link Up at 1000 mbps full duplex
Dec 21 09:21:17 WAN(0) Connection: WAN(0) link up.
Dec 21 09:21:17 rc_service: wanduck 1520:notify_rc restart_wan_if 0
Dec 21 09:21:22 wan: finish adding multi routes
Dec 21 09:21:22 WAN(0) Connection: WAN was restored.
Dec 21 09:21:24 BWDPI: force to flush flowcache entries
Dec 21 09:21:24 kernel: udb_core lock_num = 2
Dec 21 09:21:24 BWDPI: rollback fc
Dec 21 09:21:26 kernel: SHN Release Version: 2.0.7 371dd35_RELS_8
Dec 21 09:21:26 kernel: UDB Core Version: 0.2.20
Dec 21 09:21:26 kernel: Registered DNS Req parsing
Dec 21 09:21:26 kernel: sizeof forward pkt param = 280
Dec 21 09:21:26 BWDPI: fun bitmap = 4bf
Dec 21 09:21:27 A.QoS: qos_count=0, qos_check=0
Dec 21 09:21:30 dhcp client: bound 10.94.134.167/255.255.255.240 via 10.94.134.168 for 3600 seconds.
Dec 21 09:23:49 wlceventd: wlceventd_proc_event(685): eth6: Auth EC:35:4D:16:49:F2, status: Successful (0), rssi:0
Dec 21 09:23:49 wlceventd: wlceventd_proc_event(722): eth6: Assoc EC:35:4D:16:49:F2, status: Successful (0), rssi:-43
Dec 21 09:30:02 kernel: eth5 (Int switch port: 5) (Logical Port: 5) (phyId: 11) Link DOWN.
Dec 21 09:30:02 kernel: ^[[0;34m[NTC xport] xport_reset: rc = 0; intf = 1 port = 0 spd = 1G dup = 1
Dec 21 09:30:02 kernel: ^[[0m
Dec 21 09:52:20 wlceventd: wlceventd_proc_event(685): eth6: Auth A8:63:7D:31:17:52, status: Successful (0), rssi:0
Dec 21 09:52:20 wlceventd: wlceventd_proc_event(722): eth6: Assoc A8:63:7D:31:17:52, status: Successful (0), rssi:-44
Dec 21 09:52:31 rc_service: cfg_server 2384:notify_rc update_nbr
Dec 21 10:42:57 wlceventd: wlceventd_proc_event(662): eth6: Disassoc 7E:53:C0:D3:F0:CE, status: 0, reason: Unspecified reason (1), rssi:0
Dec 21 10:42:57 wlceventd: wlceventd_proc_event(645): eth6: Deauth_ind 7E:53:C0:D3:F0:CE, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3), rssi:0
Dec 21 10:42:58 wlceventd: wlceventd_proc_event(662): eth6: Disassoc A8:63:7D:31:17:52, status: 0, reason: Unspecified reason (1), rssi:0
Dec 21 10:42:58 wlceventd: wlceventd_proc_event(645): eth6: Deauth_ind A8:63:7D:31:17:52, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3), rssi:0
Dec 21 10:42:58 wlceventd: wlceventd_proc_event(685): eth6: Auth A8:63:7D:31:17:52, status: Successful (0), rssi:0
Dec 21 10:42:58 wlceventd: wlceventd_proc_event(695): eth6: ReAssoc A8:63:7D:31:17:52, status: Successful (0), rssi:-58
Dec 21 10:43:10 wlceventd: wlceventd_proc_event(685): eth6: Auth 7E:53:C0:D3:F0:CE, status: Successful (0), rssi:0
Dec 21 10:43:10 wlceventd: wlceventd_proc_event(722): eth6: Assoc 7E:53:C0:D3:F0:CE, status: Successful (0), rssi:-33
Dec 21 10:59:00 roamast: sta[7E:53:C0:D3:F0:CE] on ap[C8:7F:54:BF:D5:D0], rcpi is 82 and rssi is -69
Dec 21 11:01:52 wlceventd: wlceventd_proc_event(645): eth6: Deauth_ind EC:35:4D:16:49:F2, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3), rssi:0
Dec 21 11:01:52 wlceventd: wlceventd_proc_event(662): eth6: Disassoc EC:35:4D:16:49:F2, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Dec 21 11:01:53 wlceventd: wlceventd_proc_event(722): eth6: Assoc EC:35:4D:16:49:F2, status: Successful (0), rssi:-56
Dec 21 11:04:50 roamast: sta[7E:53:C0:D3:F0:CE] on ap[C8:7F:54:BF:D5:D0], rcpi is 70 and rssi is -75
Dec 21 11:06:50 roamast: sta[7E:53:C0:D3:F0:CE] on ap[C8:7F:54:BF:D5:D0], rcpi is 62 and rssi is -79
Dec 21 11:10:26 roamast: sta[EC:35:4D:16:49:F2] on ap[C8:7F:54:BF:D5:D0], rcpi is 48 and rssi is -86
Dec 21 11:10:26 roamast: sta[EC:35:4D:16:49:F2] on ap[C8:7F:54:BF:D5:D0], rcpi is 48 and rssi is -86
Dec 21 11:10:36 roamast: sta[EC:35:4D:16:49:F2] on ap[C8:7F:54:BF:D5:D0], rcpi is 44 and rssi is -88
Dec 21 11:10:36 roamast: sta[EC:35:4D:16:49:F2] on ap[C8:7F:54:BF:D5:D0], rcpi is 44 and rssi is -88
Dec 21 11:10:41 roamast: sta[EC:35:4D:16:49:F2] on ap[C8:7F:54:BF:D5:D0], rcpi is 44 and rssi is -88
Dec 21 11:10:41 roamast: sta[EC:35:4D:16:49:F2] on ap[C8:7F:54:BF:D5:D0], rcpi is 44 and rssi is -88
Dec 21 11:10:51 roamast: sta[EC:35:4D:16:49:F2] on ap[C8:7F:54:BF:D5:D0], rcpi is 43 and rssi is -89
Dec 21 11:10:51 roamast: sta[EC:35:4D:16:49:F2] on ap[C8:7F:54:BF:D5:D0], rcpi is 43 and rssi is -89
Dec 21 11:11:01 roamast: sta[EC:35:4D:16:49:F2] on ap[C8:7F:54:BF:D5:D0], rcpi is 44 and rssi is -88
Dec 21 11:11:01 roamast: sta[EC:35:4D:16:49:F2] on ap[C8:7F:54:BF:D5:D0], rcpi is 44 and rssi is -88
Dec 21 11:11:11 roamast: sta[7E:53:C0:D3:F0:CE] on ap[C8:7F:54:BF:D5:D0], rcpi is 58 and rssi is -81
Dec 21 11:11:12 roamast: sta[EC:35:4D:16:49:F2] on ap[C8:7F:54:BF:D5:D0], rcpi is 44 and rssi is -88
Dec 21 11:11:12 roamast: sta[EC:35:4D:16:49:F2] on ap[C8:7F:54:BF:D5:D0], rcpi is 44 and rssi is -88
Dec 21 11:11:17 roamast: sta[EC:35:4D:16:49:F2] on ap[C8:7F:54:BF:D5:D0], rcpi is 44 and rssi is -88
Dec 21 11:11:17 roamast: sta[EC:35:4D:16:49:F2] on ap[C8:7F:54:BF:D5:D0], rcpi is 44 and rssi is -88
Dec 21 11:11:27 roamast: sta[EC:35:4D:16:49:F2] on ap[C8:7F:54:BF:D5:D0], rcpi is 44 and rssi is -88
Dec 21 11:11:27 roamast: sta[EC:35:4D:16:49:F2] on ap[C8:7F:54:BF:D5:D0], rcpi is 44 and rssi is -88
Dec 21 11:11:44 wlceventd: wlceventd_proc_event(645): eth6: Deauth_ind 7E:53:C0:D3:F0:CE, status: 0, reason: Disassociated due to inactivity (4), rssi:-86
Dec 21 11:13:42 roamast: sta[EC:35:4D:16:49:F2] on ap[C8:7F:54:BF:D5:D0], rcpi is 20 and rssi is -100
Dec 21 11:13:42 roamast: sta[EC:35:4D:16:49:F2] on ap[C8:7F:54:BF:D5:D0], rcpi is 20 and rssi is -100
Dec 21 11:14:28 wlceventd: wlceventd_proc_event(645): eth6: Deauth_ind EC:35:4D:16:49:F2, status: 0, reason: Disassociated due to inactivity (4), rssi:-79
Dec 21 11:39:25 wlceventd: wlceventd_proc_event(662): eth6: Disassoc A8:63:7D:31:17:52, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Dec 21 11:39:25 wlceventd: wlceventd_proc_event(645): eth6: Deauth_ind A8:63:7D:31:17:52, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3), rssi:0
Dec 21 11:39:46 rc_service: cfg_server 2384:notify_rc update_nbr
Dec 21 14:14:08 wlceventd: wlceventd_proc_event(722): eth6: Assoc 7E:53:C0:D3:F0:CE, status: Successful (0), rssi:-70
Dec 21 14:15:41 roamast: sta[7E:53:C0:D3:F0:CE] on ap[C8:7F:54:BF:D5:D0], rcpi is 80 and rssi is -70
Dec 21 14:15:46 roamast: sta[7E:53:C0:D3:F0:CE] on ap[C8:7F:54:BF:D5:D0], rcpi is 62 and rssi is -79
Dec 21 15:00:14 kernel: MACSEC: macsec is not enabled
Dec 21 15:00:15 kernel: ^[[0;34m[NTC xport] xport_init: rc = 0; intf = 1 port = 0 spd = 1G dup = 1
Dec 21 15:00:15 kernel: ^[[0m
Dec 21 15:00:15 kernel: eth5 (Int switch port: 5) (Logical Port: 5) (phyId: 11) Link Up at 1000 mbps full duplex
Dec 21 15:00:20 kernel: eth5 (Int switch port: 5) (Logical Port: 5) (phyId: 11) Link DOWN.
Dec 21 15:00:20 kernel: ^[[0;34m[NTC xport] xport_reset: rc = 0; intf = 1 port = 0 spd = 1G dup = 1
Dec 21 15:00:20 kernel: ^[[0m
Dec 21 15:00:22 kernel: MACSEC: macsec is not enabled
Dec 21 15:00:23 kernel: ^[[0;34m[NTC xport] xport_init: rc = 0; intf = 1 port = 0 spd = 1G dup = 1
Dec 21 15:00:23 kernel: ^[[0m
Dec 21 15:00:23 kernel: eth5 (Int switch port: 5) (Logical Port: 5) (phyId: 11) Link Up at 1000 mbps full duplex
Dec 21 15:00:29 kernel: eth5 (Int switch port: 5) (Logical Port: 5) (phyId: 11) Link DOWN.
Dec 21 15:00:29 kernel: ^[[0;34m[NTC xport] xport_reset: rc = 0; intf = 1 port = 0 spd = 1G dup = 1
Dec 21 15:00:29 kernel: ^[[0m
Dec 21 15:00:30 kernel: MACSEC: macsec is not enabled
Dec 21 15:00:31 kernel: ^[[0;34m[NTC xport] xport_init: rc = 0; intf = 1 port = 0 spd = 1G dup = 1
Dec 21 15:00:31 kernel: ^[[0m
Dec 21 15:00:31 kernel: eth5 (Int switch port: 5) (Logical Port: 5) (phyId: 11) Link Up at 1000 mbps full duplex

 

[ColinTaylor]

Looks much the same as before. The Link UP/DOWN messages for eth5 are for whatever device you have plugged into the 2.5GbE port on the router.

 

[Neo-ST]

Looks much the same as before. The Link UP/DOWN messages for eth5 are for whatever device you have plugged into the 2.5GbE port on the router.

That's for my computer I'm using right now. The difference is, those messages would mean connection disruption before, now it doesn't get disrupted. How's that possible ?

 

[ColinTaylor]

That's for my computer I'm using right now. The difference is, those messages would mean connection disruption before, now it doesn't get disrupted. How's that possible ?

Sorry, I don't know anything about your computer or how and when you're using it. All I know it that you have it plugged into the 2.5GbE port even though your PC only has a 1GbE interface.

 

[Neo-ST]

Sorry, I don't know anything about your computer or how and when you're using it. All I know it that you have it plugged into the 2.5GbE port even though your PC only has a 1GbE interface.

Correct. It's getting moved right now.