Merlin NAT Loopback Problem

[tbrock47]

Keep telling someone who does not have any issues that it is a bug. Not really credible.
And don't forget to mention that Wireshark data does not prove the issue to be caused by a bug. It only confirms you have an issue, not the cause.

And it might be a coincidence, but all of these reports are made but new users. Long time visitors and testers have not observed this before....quite odd, wouldn't you think?

Really just interested in your hardware version, not your rambling. Corey had a point about hardware differences. It really could matter and could have an impact.
And FYI, I'm a network technician for a Fortune 100 company. So this is sorta what I do... I'm not really a new user, just experienced enough to not need to forums often...

 

[Corey Zamara]

Keep telling someone who does not have any issues that it is a bug. Not really credible.
And don't forget to mention that Wireshark data does not prove the issue to be caused by a bug. It only confirms you have an issue, not the cause.

And it might be a coincidence, but all of these reports are made but new users. Long time visitors and testers have not observed this before....quite odd, wouldn't you think?

Right because I don't know how to debug these router's yet, for home I came from DD-WRT but when I see a packet hit the WAN interface with status accepted but never leave the LAN interfaces with packet capturing on it's a bug.

And yes, I am new to SNB for posts

Keep telling someone who does not have any issues that it is a bug. Not really credible.
And don't forget to mention that Wireshark data does not prove the issue to be caused by a bug. It only confirms you have an issue, not the cause.

And it might be a coincidence, but all of these reports are made but new users. Long time visitors and testers have not observed this before....quite odd, wouldn't you think?

Right because I don't know how to debug these router's yet, for home I came from DD-WRT but when I see a packet hit the WAN interface with status accepted but never leave the LAN interfaces with packet capturing on it's a bug.

And yes, I am new to SNB for posts but I'm quite active in other forums, it's only because I found SNB to be the best spot for Asus router's and in particular Merlin. [emoji3]

Like I said, it could be hardware related or it could be how newer firmware's are applied, again not knowing these router's well, are the partitions completely wiped each time an upgrade is applied or are legacy files left? I would guess that some of you come from previous versions flashing on top? For my self I had the latest Asus firmware when I booted the device and then flashed the latest Merlin.

When I said I'm new to the router I meant it, this would be day 2.

 

[eddiez]

Really just interested in your hardware version, not your rambling. Corey had a point about hardware differences. It really could matter and could have an impact.
And FYI, I'm a network technician for a Fortune 100 company. So this is sorta what I do... I'm not really a new user, just experienced enough to not need to forums often...

A1. And the rambling...telling me I should have an issue when there is no issue is not credible only because a Fortune 100 network dude says so (which also does not automatically proves your personal qualifications).

I won't be boasting about my IT background (about 20 years) because the simple fact is that having no issues in comparable conditions makes it quite hard to believe that a simple bug is the cause. The great thing about bugs is that they don't exclude anyone. Unless...there are other factors that cause the observed behaviour. So do some more deep diving I would say. Your advertised qualifications should make that a piece of cake.

 

[eddiez]

Right because I don't know how to debug these router's yet, for home I came from DD-WRT but when I see a packet hit the WAN interface with status accepted but never leave the LAN interfaces with packet capturing on it's a bug.

And yes, I am new to SNB for posts

Right because I don't know how to debug these router's yet, for home I came from DD-WRT but when I see a packet hit the WAN interface with status accepted but never leave the LAN interfaces with packet capturing on it's a bug.

And yes, I am new to SNB for posts but I'm quite active in other forums, it's only because I found SNB to be the best spot for Asus router's and in particular Merlin. [emoji3]

Like I said, it could be hardware related or it could be how newer firmware's are applied, again not knowing these router's well, are the partitions completely wiped each time an upgrade is applied or are legacy files left? I would guess that some of you come from previous versions flashing on top? For my self I had the latest Asus firmware when I booted the device and then flashed the latest Merlin.

When I said I'm new to the router I meant it, this would be day 2.

Observations do not constitute a 'bug'. When you upgrade your firmware and it contains a new SDK, you can experience unwanted behaviour if you do not clear nvram. It doesn't mean the code contains a bug.

 

[Corey Zamara]

Observations do not constitute a 'bug'. When you upgrade your firmware and it contains a new SDK, you can experience unwanted behaviour if you do not clear nvram. It doesn't mean the code contains a bug.

I should have said, I did do an nvram erase after applying Merlin and enabling ssh.

 

[eddiez]

I should have said, I did do an nvram erase after applying Merlin and enabling ssh.

It was just an example, but a serious one. Still plenty of other circumstances possible to cause unexpected behaviour. But a network expert can tell you that of course .

 

[Corey Zamara]

It was just an example, but a serious one. Still plenty of other circumstances possible to cause unexpected behaviour. But a network expert can tell you that of course .

Exactly! So when you see something as simple as a packet being accepted on WAN but never leaving LAN it's pointing largely to a software bug.

If I saw it leave the LAN interface then I would know it's my own issue.

 

[eddiez]

Exactly! So when you see something as simple as a packet being accepted on WAN but never leaving LAN it's pointing largely to a software bug.

If I saw it leave the LAN interface then I would know it's my own issue.

Disagree. It does not prove a bug is the cause. Can you please point out where the bug is located. I assume the publicly available source code would make it easy to locate.

 

[Corey Zamara]

Disagree. It does not prove a bug is the cause. Can you please point out where the bug is located. I assume the publicly available source code would make it easy to locate.

Sure, given time. Like I said I'm 2 days in.

 

[eddiez]

Sure, given time. Like I said I'm 2 days in.

Odd that no one wonders why a generic bug does not affect my router and working of 8 IP CAMS...

 

[Corey Zamara]

Yup, that's why it's a bug.

Before a flame war happens just consider your mobile phone, both Android and iOS have had there share of bugs but not affecting all users, even if the bug is in an area that all users are using their devices.

 

[eddiez]

Yup, that's why it's a bug.

Before a flame war happens just consider your mobile phone, both Android and iOS have had there share of bugs but not affecting all users, even if the bug is in an area that all users are using their devices.

Calling unexpected behaviour a bug without any supporting data is not really useful, don't you think. It's easy but as an IT pro you would know that unless you build your case with supporting data or analysis it has no added value at all. Wireshark data confirming the behaviour is not proof of a bug.

If I would test my teams' (yes, plural) core banking applications like this I would be out of job pretty quickly.

 

[john9527]

AFAIK, there are two things that can come into play here....

(1) The Merlin NAT loopback uses iptables marks while the ASUS method does not. If you have any custom iptables mods using marks, they can corrupt the NAT loopback mark (0xb400). Make sure any marks you use don't conflict and are applied with a correct mask.

(2) The bwdpi engine is not Merlin NAT loopback aware (and is closed source so we can't tell the conditions or everything that it does). But, it has been seen that it can modify/restart the iptables rules in some cases wiping out the Merlin mod. Merlin added code to try and close the exposure, but there may still be cases where it happens.

That's why there are both options.....one may work better than the other depending on your particular setup.

 

[eddiez]

AFAIK, there are two things that can come into play here....

(1) The Merlin NAT loopback uses iptables marks while the ASUS method does not. If you have any custom iptables mods using marks, they can corrupt the NAT loopback mark (0xb400). Make sure any marks you use don't conflict and are applied with a correct mask.

(2) The bwdpi engine is not Merlin NAT loopback aware (and is closed source so we can't tell the conditions or everything that it does). But, it has been seen that it can modify/restart the iptables rules in some cases wiping out the Merlin mod. Merlin added code to try and close the exposure, but there may still be cases where it happens.

That's why there are both options.....one may work better than the other depending on your particular setup.

Thanks for the deep dive. Might shed some more light on the 'bug or not to bug' question at hand.

 

[Corey Zamara]

Calling unexpected behaviour a bug without any supporting data is not really useful, don't you think. It's easy but as an IT pro you would know that unless you build your case with supporting data or analysis it has no added value at all. Wireshark data confirming the behaviour is not proof of a bug.

If I would test my teams' (yes, plural) core banking applications like this I would be out of job pretty quickly.

Well, I did supply evidence on what I did, I don't know the forum rules yet but I can supply the data, is it recommended to dump directly in the thread or link to something like pastebin?

I'm not at all diminishing Merlin's work but it is a bug, as it's a core function that isn't working on a device that is listed as supported.

If it was experimental I'd understand, and I'm not even opposed to switching the method to Asus, Having come from DD-WRT it has bugs between builds all the time but that doesn't diminish them still being bugs. I was just helping to confirm that it is indeed a bug.

 

[RMerlin]

It's a known technical limitation, as explained by John. This is the very reason why I offer both NAT loopback methods, as for some people one method will work more reliably than the other one. This is especially the case if you are using any of the Trend Micro-related features.

 

[eddiez]

It's a known technical limitation, as explained by John. This is the very reason why I offer both NAT loopback methods, as for some people one method will work more reliably than the other one. This is especially the case if you are using any of the Trend Micro-related features.

And that's not a bug. Not being able to breathe in space without additional support also isn't called a bug. It is an inevitable limitation.

 

[Corey Zamara]

It's a known technical limitation, as explained by John. This is the very reason why I offer both NAT loopback methods, as for some people one method will work more reliably than the other one. This is especially the case if you are using any of the Trend Micro-related features.

But it's not, if it was technical it wouldn't work under Asus method as well. For example, due to technical limitations, normal 32-bit computer operating systems have a 4 GiB limit on addressable memory.

 

[eddiez]

But it's not, if it was technical it wouldn't work under Asus method as well. For example, due to technical limitations, normal 32-bit computer operating systems have a 4 GiB limit on addressable memory.

I think you should read John's description once again.

 

[RMerlin]

But it's not, if it was technical it wouldn't work under Asus method as well. For example, due to technical limitations, normal 32-bit computer operating systems have a 4 GiB limit on addressable memory.

Considering that I wrote the code, I'm pretty sure I understand what is a bug and what is a known technical limitation...

Asus's method does not use packet marking, unlike mine. This is a limitation of anything that needs to manipulate that specific iptables chain on a DPI-enabled firmware.