Modem Mode | Hub 5x | Cooling off period

[greganew]

The dream came true and Virgin laid the fibre and offered FTTP in an area where my ADSL would be lucky to get 32 Megabits per second. I did my research and found that Modem Mode is possible so that I can use my existing Asus router / Wifi 🙂

Service was installed and as soon as the engineer left I logged in and there is no Modem Mode 😞

Found this, https://www.reddit.com/r/VirginMedia/comments/1ah1boq/hub_5x_working_modem_mode, which worked first time and my Asus got a Public IP and I was in business 🙂 

Wife complained about where I had meticulously setup all the kit, there's a lesson in there, so I moved it all, and it never worked again, despite running through it several times.

Before I cancel the service is there anything that can be done from the Virgin side of things to get Modem Mode working in a stable fashion within the next 5 days?

I see people have been asking for this for a very long time. I also see that some people report they have newer firmware than me, 1.2.1b / 2.40.13-2210.4, but it sounds like it's some phased roll out.

I also found some threads talking about a device that can be used but found that very high temperatures are reported and cooling may be required, so I'm not tempted by the option.

So, before I cancel, dig out my Vigor 130 and go back to BT, is there anything that can be done?

Thanks in advance.

Greg

[greganew]

Thanks for the link @IPFreely 🙂  I'm speaking to the altnet to see if they can get me dug in. It's only 30m so I'll keep my fingers crossed. Of course the altnet provides an ONT and #CustomerChoice

[Client62]

We should be very grateful to greganew for posting in such detail.

There have been a number of claims that what has been attempted here works,
but no threads that have confirmed in quite so much detail the challenges and pitfalls and brick walls.

[legacy1]

All this could have been avoided if them people who did NAT in routers for DMZ but the right way 30 years ago

[IPFreely]

Please elaborate. 

[IPFreely]

The DHCP lease comes from a BNG, VM have them in a few of their sites and customers on the XGSPON are routed over the VM network via EVPN-VPWS to get to them.

TL;DR the network emulates a wire between the customer and the BNG and the BNG terminates the customer alongside providing the lease.

Sorry for acronym soup.

[legacy1]

DMZ should have your WAN IP forwarded with NAT support what I mean by that is you can have a PC non DMZ with 192.168.0.2 NAT from WAN1 but it is possible and was always possible to code to have a PC with your WAN IP as if it was in modem mode but with NAT support with all traffic forwarded.

[IPFreely]

Okay, I understand.

Old school DMZ functionality I remember did not forward public IP it did static NAT. If the DMZ device served a separate network and did NAT as well it didn't matter: source NAT preserved the source port.

This needs a rewrite of a whole bunch of core stuff for zero actual benefit. It would be a net loss of functionality as neither the DMZ device or the devices behind it would be able to communicate with the rest of the LAN without more bodgery. Have to have a dedicated DMZ interface on hardware, can't use physical interfaces going to a regular logical bridge as wanting that bridge to also behave as a numbered interface depending on source MAC. That or write a custom filter driver. Can't fast track flows once through a NAT table evaluation and send to HW acceleration with the hardware just doing a fast look up on destination: no cut-through forwarding. Needs custom treatment of ARP and IP so regular Ethernet and IP stacks have to be modified.

Just a few things that came to mind immediately. For the sake of the DMZ device having a public IP address on WAN interface. Forwarding everything without a flow state to the DMZ will do everything this solution does which is why it isn't a thing. Excessively complicated solution looking for a problem that creates edge cases where things may go wrong such as flow table collisions, forwarding loops, etc.

[legacy1]

So then we will not have real internet forwarded we will never see the WAN IP we really get this is the future you want?

[greganew]

I cancelled during cooling off and am now back on my very slow ADSL, but at least I know it will be reliable!

I wanted to thank all those who commented, offered help or just got their point across about the lack of support for Modem Mode.

My conclusion is that on my version of firmware, using the Modem Mode hidden URL, with my Asus RT-AX86U WAN port configured for DHCP with Continuous Mode, it was not reliable, most likely a DHCP renewal issue.

If I was to try again then I would try the suggestion from @legacy1 to set the MAC address of the Asus WAN port, see page 2.

In the meantime please all keep your fingers crossed that Fibre Heroes dig me in some fibre, it's only 30 meters!

It's worth me saying that if you are cancelling during your cooling off period you may get cut off early! I was supposed to be cut off on the 4th but they did it in the early hours of the 1st, which wasn't ideal as I had a house full of friends and with a stinking hangover had to dig out the ADSL modem and get it all working again.

With a proper Modem Mode I'd sign back up in a flash!

Good luck to you all.

Cheers,
Greg

[IPFreely]

---

@legacy1 wrote:

So then we will not have real internet forwarded we will never see the WAN IP we really get this is the future you want?

---

IPv6 is the future I want and the one many are delivering. This post will arrive via IPv6.

IP Address of Last Visit

2a0e:1d47:8a07:redacted:a2ac:7715

On IPv4 as I said in my original response bodging how networks work for the sake of seeing a public IP on the LAN side without it making any functional difference to Internet access and breaking LAN is pointless and silly. If mapping IP addresses to RFC1918 addresses forwarding all ports not used by source NAT via destination NAT is good enough for data centres, all well understood and implemented in both software and hardware ASICs, it's probably adequate for residential users.