NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
M6 and IP-passthrough with routable static IP
I have an M6 Pro (MR6550) and a T-Mobile business internet account, and I'm unable to use the M6 in passthrough mode.
The M6 (the hotspot) does some pretty inexplicable things. Like ARP my firewall from 192.168.3.1.
As I said, my firewall has a public routable (non RFC-1918) address, so 192.168.3.1 is not going to be adjacent on the subnet, and therefore my firewall will drop the ARP request at a minimum, and potentially trigger the IDS as there being misconfiguration of a peer on the network or even someone doing malicious probes.
It also sends SSDP packets to my network segment as multicasts. Why? Only hackers use SSDP on a WAN interface: to figure out (1) if you're misconfigured and (2) to know what sort of machines are on your network so they can tailor attacks after fingerprinting the hosts and looking up their attack surfaces and vulnerabilities.
But more to the point, it's a modem/bridge. It should be operating at layer 2 on the Ethernet side, and layer 3 on the 4G/5G side.
The correct behavior is trivial:
(1) When the APN provisioning is received from the 5G carrier, PROXY ARP the default gateway's IP address with your own (M6's) MAC address (or GARP it, that works too if the firewall has been sysctl'd to accept GARP's on a public interface... which is sometimes used for man-in-the-middle attacks on public networks).
(2) Then ARP REQUEST the firewall's IP address so you know where to forward the packets.
That 2nd step is likely unnecessary, since most IP neighbor implementations cache the address of an ARP requestor in anticipation of their being return traffic (i.e. some sort of answer).
You don't need SSDP. Or mDNS. Or to be trying to figure out anything about what's attached to the firewall. That's just suspicious behavior.
Also, don't IPv6 SSDP me if I'm not provisioned for IPv6! That just fills my logs with noise.
If I do a ping -c 1000 8.8.8.8 then I see spans of 8 or 9 packets being passed, then 20 or so dropped, then 8 or 9 passed, then 20 or so dropped... until the test completes.
How did this not turn up during homologation testing? I'm getting 62-70% packet loss!!!
17 Replies
Because for some mysterious reason, .txt attachments aren't allowed:
root@OpenWrt2:~# iperf3 -c 84.17.41.11 -p 5201 -t 60 -Z Connecting to host 84.17.41.11, port 5201 [ 5] local 162.191.234.12 port 40326 connected to 84.17.41.11 port 5201 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 2.12 MBytes 17.8 Mbits/sec 0 729 KBytes [ 5] 1.00-2.00 sec 7.38 MBytes 61.8 Mbits/sec 0 1.17 MBytes [ 5] 2.00-3.00 sec 8.12 MBytes 68.2 Mbits/sec 0 1.54 MBytes [ 5] 3.00-4.00 sec 6.88 MBytes 57.7 Mbits/sec 0 1.91 MBytes [ 5] 4.00-5.00 sec 3.12 MBytes 26.2 Mbits/sec 390 592 KBytes [ 5] 5.00-6.00 sec 1.25 MBytes 10.5 Mbits/sec 671 2.71 KBytes [ 5] 6.00-7.00 sec 1.75 MBytes 14.7 Mbits/sec 92 1.08 MBytes [ 5] 7.00-8.00 sec 8.12 MBytes 68.1 Mbits/sec 0 1.45 MBytes [ 5] 8.00-9.00 sec 6.88 MBytes 57.7 Mbits/sec 0 1.82 MBytes [ 5] 9.00-10.00 sec 2.62 MBytes 22.0 Mbits/sec 1 1.36 KBytes [ 5] 10.00-11.00 sec 0.00 Bytes 0.00 bits/sec 32 24.4 KBytes [ 5] 11.00-12.00 sec 2.75 MBytes 23.1 Mbits/sec 1453 1.39 MBytes [ 5] 12.00-13.00 sec 6.75 MBytes 56.6 Mbits/sec 0 1.76 MBytes [ 5] 13.00-14.00 sec 4.00 MBytes 33.5 Mbits/sec 3 1.75 MBytes [ 5] 14.00-15.00 sec 0.00 Bytes 0.00 bits/sec 6 1.70 MBytes [ 5] 15.00-16.00 sec 0.00 Bytes 0.00 bits/sec 6 1.69 MBytes [ 5] 16.00-17.00 sec 0.00 Bytes 0.00 bits/sec 6 1.69 MBytes [ 5] 17.00-18.00 sec 0.00 Bytes 0.00 bits/sec 7 1.67 MBytes [ 5] 18.00-19.00 sec 0.00 Bytes 0.00 bits/sec 7 1.66 MBytes [ 5] 19.00-20.00 sec 0.00 Bytes 0.00 bits/sec 6 1.65 MBytes [ 5] 20.00-21.00 sec 0.00 Bytes 0.00 bits/sec 6 1.64 MBytes [ 5] 21.00-22.00 sec 2.12 MBytes 17.8 Mbits/sec 7 1.56 MBytes [ 5] 22.00-23.00 sec 2.12 MBytes 17.8 Mbits/sec 7 1.40 MBytes [ 5] 23.00-24.00 sec 0.00 Bytes 0.00 bits/sec 5 1.22 MBytes [ 5] 24.00-25.00 sec 0.00 Bytes 0.00 bits/sec 6 1.18 MBytes [ 5] 25.00-26.00 sec 0.00 Bytes 0.00 bits/sec 4 1.17 MBytes [ 5] 26.00-27.00 sec 0.00 Bytes 0.00 bits/sec 127 86.8 KBytes [ 5] 27.00-28.00 sec 6.12 MBytes 51.4 Mbits/sec 356 1.26 MBytes [ 5] 28.00-29.00 sec 8.38 MBytes 70.3 Mbits/sec 0 1.64 MBytes [ 5] 29.00-30.00 sec 5.62 MBytes 47.2 Mbits/sec 1 1.88 MBytes [ 5] 30.00-31.00 sec 0.00 Bytes 0.00 bits/sec 6 1.60 MBytes [ 5] 31.00-32.00 sec 1.62 MBytes 13.6 Mbits/sec 6 1.58 MBytes [ 5] 32.00-33.00 sec 0.00 Bytes 0.00 bits/sec 7 1.53 MBytes [ 5] 33.00-34.00 sec 0.00 Bytes 0.00 bits/sec 4 1.36 KBytes [ 5] 34.00-35.00 sec 2.50 MBytes 21.0 Mbits/sec 325 1.42 MBytes [ 5] 35.00-36.00 sec 0.00 Bytes 0.00 bits/sec 7 1.19 MBytes [ 5] 36.00-37.00 sec 0.00 Bytes 0.00 bits/sec 6 1.16 MBytes [ 5] 37.00-38.00 sec 0.00 Bytes 0.00 bits/sec 5 2.71 KBytes [ 5] 38.00-39.00 sec 0.00 Bytes 0.00 bits/sec 252 174 KBytes [ 5] 39.00-40.00 sec 3.50 MBytes 29.4 Mbits/sec 199 950 KBytes [ 5] 40.00-41.00 sec 0.00 Bytes 0.00 bits/sec 7 893 KBytes [ 5] 41.00-42.00 sec 0.00 Bytes 0.00 bits/sec 3 884 KBytes [ 5] 42.00-43.00 sec 3.12 MBytes 26.2 Mbits/sec 23 907 KBytes [ 5] 43.00-44.00 sec 7.00 MBytes 58.7 Mbits/sec 0 1.22 MBytes [ 5] 44.00-45.00 sec 7.12 MBytes 59.8 Mbits/sec 0 1.58 MBytes [ 5] 45.00-46.00 sec 6.75 MBytes 56.6 Mbits/sec 0 1.95 MBytes [ 5] 46.00-47.00 sec 0.00 Bytes 0.00 bits/sec 6 1.68 MBytes [ 5] 47.00-48.00 sec 0.00 Bytes 0.00 bits/sec 6 1.67 MBytes [ 5] 48.00-49.00 sec 0.00 Bytes 0.00 bits/sec 6 1.66 MBytes [ 5] 49.00-50.00 sec 0.00 Bytes 0.00 bits/sec 6 1.65 MBytes [ 5] 50.00-51.00 sec 0.00 Bytes 0.00 bits/sec 7 1.64 MBytes [ 5] 51.00-52.00 sec 0.00 Bytes 0.00 bits/sec 6 1.63 MBytes [ 5] 52.00-53.00 sec 0.00 Bytes 0.00 bits/sec 6 1.62 MBytes [ 5] 53.00-54.00 sec 1.62 MBytes 13.6 Mbits/sec 8 1.46 MBytes [ 5] 54.00-55.00 sec 0.00 Bytes 0.00 bits/sec 6 1.43 MBytes [ 5] 55.00-56.00 sec 0.00 Bytes 0.00 bits/sec 16 17.6 KBytes [ 5] 56.00-57.00 sec 2.88 MBytes 24.1 Mbits/sec 10 1.30 MBytes [ 5] 57.00-58.00 sec 0.00 Bytes 0.00 bits/sec 7 1.16 MBytes [ 5] 58.00-59.00 sec 0.00 Bytes 0.00 bits/sec 17 10.8 KBytes [ 5] 59.00-60.00 sec 3.50 MBytes 29.3 Mbits/sec 468 1.09 MBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-60.00 sec 126 MBytes 17.6 Mbits/sec 4624 sender [ 5] 0.00-60.14 sec 123 MBytes 17.1 Mbits/sec receiver iperf Done. root@OpenWrt2:~#Note the intervals were zero packets got through: 15, 19-25, 28-31, ...
I've even been told by tech support that my SLA didn't have enough bandwidth and that's why a one packet-per-second test was failing (the ping below).
# ping -c 100 24.116.100.90 PING 24.116.100.90 (24.116.100.90): 56 data bytes 64 bytes from 24.116.100.90: seq=0 ttl=54 time=90.591 ms 64 bytes from 24.116.100.90: seq=1 ttl=54 time=52.553 ms 64 bytes from 24.116.100.90: seq=2 ttl=54 time=164.566 ms 64 bytes from 24.116.100.90: seq=3 ttl=54 time=124.372 ms 64 bytes from 24.116.100.90: seq=4 ttl=54 time=60.166 ms 64 bytes from 24.116.100.90: seq=5 ttl=54 time=50.402 ms 64 bytes from 24.116.100.90: seq=6 ttl=54 time=162.617 ms 64 bytes from 24.116.100.90: seq=7 ttl=54 time=57.555 ms 64 bytes from 24.116.100.90: seq=8 ttl=54 time=59.098 ms 64 bytes from 24.116.100.90: seq=25 ttl=54 time=639.718 ms <======= 64 bytes from 24.116.100.90: seq=26 ttl=54 time=60.880 ms 64 bytes from 24.116.100.90: seq=27 ttl=54 time=67.038 ms 64 bytes from 24.116.100.90: seq=28 ttl=54 time=56.424 ms 64 bytes from 24.116.100.90: seq=29 ttl=54 time=63.629 ms 64 bytes from 24.116.100.90: seq=30 ttl=54 time=58.553 ms 64 bytes from 24.116.100.90: seq=31 ttl=54 time=110.747 ms 64 bytes from 24.116.100.90: seq=32 ttl=54 time=56.388 ms 64 bytes from 24.116.100.90: seq=33 ttl=54 time=70.281 ms 64 bytes from 24.116.100.90: seq=52 ttl=54 time=66.309 ms <======= 64 bytes from 24.116.100.90: seq=53 ttl=54 time=181.092 ms 64 bytes from 24.116.100.90: seq=54 ttl=54 time=55.216 ms 64 bytes from 24.116.100.90: seq=55 ttl=54 time=55.123 ms 64 bytes from 24.116.100.90: seq=56 ttl=54 time=53.488 ms 64 bytes from 24.116.100.90: seq=57 ttl=54 time=71.008 ms 64 bytes from 24.116.100.90: seq=58 ttl=54 time=54.779 ms 64 bytes from 24.116.100.90: seq=59 ttl=54 time=64.302 ms 64 bytes from 24.116.100.90: seq=74 ttl=54 time=2816.721 ms <======= 64 bytes from 24.116.100.90: seq=75 ttl=54 time=1816.697 ms 64 bytes from 24.116.100.90: seq=76 ttl=54 time=816.189 ms 64 bytes from 24.116.100.90: seq=77 ttl=54 time=56.368 ms 64 bytes from 24.116.100.90: seq=78 ttl=54 time=58.980 ms 64 bytes from 24.116.100.90: seq=79 ttl=54 time=56.697 ms 64 bytes from 24.116.100.90: seq=80 ttl=54 time=52.612 ms 64 bytes from 24.116.100.90: seq=81 ttl=54 time=66.038 ms 64 bytes from 24.116.100.90: seq=82 ttl=54 time=76.089 ms 64 bytes from 24.116.100.90: seq=83 ttl=54 time=69.489 ms 64 bytes from 24.116.100.90: seq=84 ttl=54 time=205.059 ms <======= --- 24.116.100.90 ping statistics --- 100 packets transmitted, 37 packets received, 63% packet loss round-trip min/avg/max = 50.402/235.076/2816.721 msI've put arrows next to interruptions of packet flows (losses).
I opened a case 7 weeks ago. No progress. Not even a confirmation that they understand the problem or were able to reproduce it on the test bench.
It should be operating at layer 2 on the Ethernet side, and layer 3 on the 4G/5G side.
And when I say "operating at [...] layer 3 on the 4G/5G side", I mean stripping the Ethernet encapsulation of 0x800 packets and forwarding them over the radio. Easy peasy.
I cannot seem to find where to set the M6 to bridge mode in the user manual.
https://www.downloads.netgear.com/files/GDC/MR6500/MR6500_MR6110_UM_EN.pdf
Is this an "Advanced" feature that is not in the user manual?
On the screen, it's "Settings", "More", "IP Passthrough".
Thanks for explaining where the IP Passthrough option is found.
my firewall has a public routable (non RFC-1918) address
Is this firewall public IP address the same as the public IP address that the M6 receives from the ISP?
Not sure I understand the question: if the hotspot is in IP passthrough mode, then it doesn't have an IP address because it's supposedly operating at layer 2.
Suppose that the Firewall public IP address is 111.222.333.a and the public IP address assigned to the M6 is 333.222.111.b.
If the M6 is put into passthrough mode, then it will send packets to the Firewall addressed to 333.222.111.b and the Firewall will ignore them because it is expecting packets addressed to 111.222.333.a
Put another way, if the M6 is in the default (router) mode, what public IP address does it display?
Um... first, they'd need to be on the same subnet.
So do you mean the M6 is on 111.222.333.b?
Again, in passthrough mode the M6 won't have an address. But it will know the address that the firewall behind it has. It will also know the address of the (provider-side) default gateway.
Or are we not talking about IP-passthrough mode any more?
Because:
if the M6 is in the default (router) mode
then that sounds like we're talking about routing mode and not IP passthrough mode.
My concern is that the ISP may believe that the device their network is connecting to has a public IP address that they have assigned to that connection and the Firewall believes that it has a different public IP address. If packets keep arriving through the M6 that are addressed to the ISP public IP, the Firewall will ignore them. The goal is to confirm what IP the ISP is sending packets to, and the only way to do that appears to temporarily put the M6 into the default router mode.
If someone misconfigures their firewall with the wrong IP address, prefix, and default gateway then this is going to fail no matter what... Doesn't matter if they're on Ethernet, cellular, DOCSIS, or whatever.
5 weeks since I provided both all of the debugging information requested, and an engineering solution to the problem (basically just do Proxy ARP like every other modem on the market does) and I still don't have working firmware.
Or even confirmation that they understand the problem or have been able to reproduce it in the lab.
And now 6 weeks have passed, and absolutely no progress.
No confirmation that this has been reproduced in the lab, or that a fix is undergoing testing.... or that a drop-dead date has been assigned to getting a fix published...
Shockingly bad technical support.
Not even a pretense of an SLA in time-to-resolution.
But the clincher is that this was a known issue with the M5, so they had foreknowledge of it supposedly before the M6 was even released.
