Posted: Sun May 15, 2022 7:27 Post subject: Router has a WAN IP, but no internet [Part 2]
phuzi0n wrote:
I created a new ticket for this PPPoE route creation problem. You should still be able to fix it yourself by adding a delay or using cron as I said earlier.
However necroposting a 12 year old thread is wrong, best always start a new thread, which I will now split your comment and mine and refer to this thread.
Sorry, it's a personal preference of mine to necro; just different schools of thought. Thanks much for splitting this out!
As far as build, both r47182 and r48741 completely blocked me resolving this the age old way of Applying Settings; and the issue itself requiring Applying Settings has been present in r45385, r43711, r42729, r41813, r40559, r39866, and I think also r33679...definitely further back too as indicated by the other thread and bug reports, but my self documenting of this didn't start until the 2019 builds. TLDR, I'd be dumbfounded that within a week of me reporting, a build made before I reported just happened to solve a 12 year old issue, haha. But maybe it could've resolved the year long issue where I'm at a standstill currently?
It helps if you provide logs after restarting and after you clicked apply.
Als after restart from CLI:
iptables -vnL FORWARD
iptables -vnL -t nat
and after apply
Furthermore screenshots of setup page.
And any additional commands or firewall rules you added.
If you have added any extra commands/firewall rules does it work without those rules?
This is a split off thread from a previous, where this info was provided. Hence why I didn't here. I've got a family that relies on the Internet unfortunately most of the time, so it may take a few hours (or maybe even late tonight) before I can provide all this info.
Chain INPUT (policy ACCEPT 44147 packets, 3252K bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 9735 packets, 690K bytes)
pkts bytes target prot opt in out source destination
Chain POSTROUTING (policy ACCEPT 10082 packets, 698K bytes)
pkts bytes target prot opt in out source destination
6 288 MASQUERADE all -- * vlan2 0.0.0.0/0 192.168.0.0/24
30092 4114K SNAT all -- * ppp0 192.168.2.0/24 0.0.0.0/0 to:$WAN_IP
0 0 SNAT all -- * ppp0 192.168.20.0/24 0.0.0.0/0 to:$WAN_IP
0 0 SNAT all -- * ppp0 192.168.20.0/24 0.0.0.0/0 to:$WAN_IP
0 0 RETURN all -- * wl0.1 0.0.0.0/0 0.0.0.0/0 PKTTYPE = broadcast
0 0 MASQUERADE all -- * wl0.1 192.168.20.0/24 192.168.20.0/24
0 0 RETURN all -- * wl1.1 0.0.0.0/0 0.0.0.0/0 PKTTYPE = broadcast
0 0 MASQUERADE all -- * wl1.1 192.168.20.0/24 192.168.20.0/24
0 0 RETURN all -- * br0 0.0.0.0/0 0.0.0.0/0 PKTTYPE = broadcast
214 24402 MASQUERADE all -- * br0 192.168.2.0/24 192.168.2.0/24
Startup Script (This is for facilitating access to modem in Transparent Bridging (https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=244239&view=previous&sid=b092049908c8b9bcbf6a9b92fc8ee928))
Code:
ifconfig `nvram get wan_ifname`:0 192.168.0.2 netmask 255.255.255.0
Firewall Script (This is also for facilitating access to modem in Transparent Bridging. Also for blocking IPs that have attacked my network in the past)
Code:
iptables -t nat -I POSTROUTING -o `nvram get wan_ifname` -d 192.168.0.0/24 -j MASQUERADE
iptables -I FORWARD -i vlan2 -s 194.61.54.252/32 -j DROP
iptables -I INPUT -i vlan2 -s 194.61.54.252/32 -j DROP
iptables -I FORWARD -i vlan2 -s 194.61.54.80/32 -j DROP
iptables -I INPUT -i vlan2 -s 194.61.54.80/32 -j DROP
iptables -I FORWARD -i vlan2 -s 194.61.54.1/24 -j DROP
iptables -I INPUT -i vlan2 -s 194.61.54.1/24 -j DROP
iptables -I FORWARD -i vlan2 -s 89.248.172.24/32 -j DROP
iptables -I INPUT -i vlan2 -s 89.248.172.24/32 -j DROP
iptables -I OUTPUT -m mac --mac-source 06:40:E2:E1:CB:52 -j DROP
I've attached screenshots of my Setup page. Please excuse the poor local IP addressing...it's required due to legacy crap here that I've not spent the time to clean up.
Please note, in one of the bug reports, Brainslayer commented on the Service Name and Firewall pieces as a point to check. I've removed both and was still experiencing the issue after a reboot as to boot!
I have to say it has improved some gremlins here feels like getting a working and Usable WAN connection from the ISP is working reliably as before it was a mixed bag.
Will take a look, I don't believe in coincidental timing, but will take what I can get, haha.
Ironically...I was going to test that latest build...but your own post was why I didn't! I too have an Asus RT-AC68U (mine is a converted TM-AC1900).
Part of the reason I've resorted to posting vs trying new builds and failing forward myself is because of my current Wifi issues. Been on r45385 for almost a year, but lately my month Wifi loss has become daily. I suspect it's because I've been trying to get a guest wireless setup because my new job is fully remote and I don't want sniffing on my network from em...and I've been getting by hot-spotting my cell for meetings and VDI for work. Was hoping later builds might be stable on this front, as my 2nd AP exact same router has been on r48741 for 2 weeks stable...and now this and later builds just prevent me from the Internet entirely on my main router (although I've read hardware wise these suck for wireless stability).
An additional note, I send my DD-WRT logs to a splunk instance...so if anyone needs anything from any time...I've got the logs saved...provide I can splunk my way to em, haha.
Joined: 31 Jul 2021 Posts: 2146 Location: All over YOUR webs
Posted: Sun May 15, 2022 18:01 Post subject:
Thanks for the detailed screenshots and logs.
The issues I reported dont affect WiFi, Wifi here works very well on all bands and including VAPS. The other issues are not impeding normal functions, they are in the very least annoying even if they are bugs.
Running old builds, is the choice of the person on the other side, but note, per forum rules and guidelines they are NOT supported, so reporting issues only against the latest builds only, people are welcome to revert back to whatever.
Also old builds are unsafe due to the rise of exploits being taken advantage of, and all known reported CVE's are patched only in the latest builds.
Quote:
Sorry, it's a personal preference of mine to necro
Apology accepted. It is a disruptive and confusing practice (not limited to). The firmware changes a great deal in 6 months never mind 12 years. The acceptable alternative is creating a new thread and referring to old one.
Necroposts can be removed without comment at a moderators discretion, splitting is an alternative when there are justifiable reasons.
While I personally appreciate different opinions and schools of thought (none likes to be in an echo chamber), our community needs less confusion for one and cooperation of all towards that end is greatly appreciated and won't go unnoticed.
Joined: 08 May 2018 Posts: 14180 Location: Texas, USA
Posted: Sun May 15, 2022 18:06 Post subject:
I presume your Centurylink (Qwest) modem is in bridge / pass-thru mode; of course, full disclosure of all equipment and applicable settings will help us help you. _________________ "Life is but a fleeting moment, a vapor that vanishes quickly; All is vanity"
Contribute To DD-WRT Pogo - A minimal level of ability is expected and needed... DD-WRT Releases 2023 (PolitePol)
DD-WRT Releases 2023 (RSS Everything)
----------------------
Linux User #377467 counter.li.org / linuxcounter.net
Chain INPUT (policy ACCEPT 536 packets, 36336 bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 192 packets, 13410 bytes)
pkts bytes target prot opt in out source destination
Chain POSTROUTING (policy ACCEPT 212 packets, 15930 bytes)
pkts bytes target prot opt in out source destination
0 0 MASQUERADE all -- * vlan2 0.0.0.0/0 192.168.0.0/24
605 63714 SNAT all -- * ppp0 192.168.2.0/24 0.0.0.0/0 to:$WAN_IP
0 0 SNAT all -- * ppp0 192.168.20.0/24 0.0.0.0/0 to:$WAN_IP
0 0 SNAT all -- * ppp0 192.168.20.0/24 0.0.0.0/0 to:$WAN_IP
0 0 RETURN all -- * wl0.1 0.0.0.0/0 0.0.0.0/0 PKTTYPE = broadcast
0 0 MASQUERADE all -- * wl0.1 192.168.20.0/24 192.168.20.0/24
0 0 RETURN all -- * wl1.1 0.0.0.0/0 0.0.0.0/0 PKTTYPE = broadcast
0 0 MASQUERADE all -- * wl1.1 192.168.20.0/24 192.168.20.0/24
0 0 RETURN all -- * br0 0.0.0.0/0 0.0.0.0/0 PKTTYPE = broadcast
2 104 MASQUERADE all -- * br0 192.168.2.0/24 192.168.2.0/24
the-joker wrote:
Thanks for the detailed screenshots and logs.
The issues I reported dont affect WiFi, Wifi here works very well on all bands and including VAPS. The other issues are not impeding normal functions, they are in the very least annoying even if they are bugs.
Sorry, misread then!
the-joker wrote:
Running old builds, is the choice of the person on the other side, but note, per forum rules and guidelines they are NOT supported, so reporting issues only against the latest builds only, people are welcome to revert back to whatever.
Also old builds are unsafe due to the rise of exploits being taken advantage of, and all known reported CVE's are patched only in the latest builds.
Fully Understand, was not and would not advocate running old builds unless neccary. I only listed the builds to express how long of an issue this has been and what key points in the timeline are guaranteed to be impacted. Really, I just upgrade a few times a year depending on reports in the New Build thread specifically around the same model as mine.
Only reason I've not upgraded is because I am unable to fail forward, Internet simply does not work for me on the two newer builds I've tried.
kernel-panic69 wrote:
I presume your Centurylink (Qwest) modem is in bridge / pass-thru mode; of course, full disclosure of all equipment and applicable settings will help us help you.
Your assumptions are correct, I'm running my own purchased modem for Centurylink and it is configured as Transparent Bridging.
Here is some general additional information that might be useful. I can provide anything additional asked for (as noted, I pipe logs to Splunk if needed as well)
Router: Asus RT-AC68U (Convrted TM-AC1900)
- Firemware: DD-WRT v3.0-r45385 std (01/09/21)
- Connection Type: PPPoE (Other Setup Settings can be seen in the above screenshots)
- WAN Port Assignment: vlan2
- Dnsmasq: Enabled
- SPI Firewall: Enabled (See attachment for more details)
Joined: 08 May 2018 Posts: 14180 Location: Texas, USA
Posted: Wed May 18, 2022 16:05 Post subject:
You have no VLAN 201 configured on your DD-WRT router? Doing this now and expecting upgrade to latest to work may not be in your best interest. You should be on a post-swconfig build at the very least to make it worthwhile. _________________ "Life is but a fleeting moment, a vapor that vanishes quickly; All is vanity"
Contribute To DD-WRT Pogo - A minimal level of ability is expected and needed... DD-WRT Releases 2023 (PolitePol)
DD-WRT Releases 2023 (RSS Everything)
----------------------
Linux User #377467 counter.li.org / linuxcounter.net
You have no VLAN 201 configured on your DD-WRT router? Doing this now and expecting upgrade to latest to work may not be in your best interest. You should be on a post-swconfig build at the very least to make it worthwhile.
The VLAN 201 configuration for the modem was either default or suggested in the guide followed for maintaining access to the modem in transparent bridging. I know that I do not have such a vlan configured on my router.
I don't understand what you mean by "Doing this now...", doing what? Not expecting an upgra I don't know what upgrading and this have to do with each other? Sorry, but that and the following statements seem to be conflicting and I'm very confused by the wording. Please note, the two newer builds tried produce non functioning Internet access completely, as noted prior. So I'm not sure if you're suggesting I upgrade (which would break my Internet) or not upgrading (due to the random vlan tagging done at the modem)?
Either way, I'm not sure that this is related at all to the problem at hand? It wasn't an issue in older builds where this wasn't a problem.
Is there a way to know the exact commands run during the Apply Settings phase in Advanced Routing? If I knew that, I could just try each command one by one until I find what fixes the issue? In decades past threads, I've seen various suggestions, but nothing that appears in line...
Joined: 31 Jul 2021 Posts: 2146 Location: All over YOUR webs
Posted: Sat May 21, 2022 10:25 Post subject:
Note that upgrading to latest build, and as noted ad nauseam and info gleamed for various build threads and experience dictate that nvram reset and reconfiguration from scratch are required to oust any gremlins.
Anything else YMMV and will everyone chasing own tails.
Joined: 08 May 2018 Posts: 14180 Location: Texas, USA
Posted: Sat May 21, 2022 11:40 Post subject:
What I meant in my previous post was that if you configure for VLAN 201 on DD-WRT with your current build, it may likely break when you upgrade to current release due to changes made during DD-WRT development (i.e. addition of swconfig utility support on Broadcom).
AFAIK, you have to have the VLAN 201 configured on your WAN port for you to have connectivity to the internet, otherwise, it's not going to work. Was hoping that someone else would've already confirmed this. _________________ "Life is but a fleeting moment, a vapor that vanishes quickly; All is vanity"
Contribute To DD-WRT Pogo - A minimal level of ability is expected and needed... DD-WRT Releases 2023 (PolitePol)
DD-WRT Releases 2023 (RSS Everything)
----------------------
Linux User #377467 counter.li.org / linuxcounter.net
Note that upgrading to latest build, and as noted ad nauseam and info gleamed for various build threads and experience dictate that nvram reset and reconfiguration from scratch are required to oust any gremlins.
Anything else YMMV and will everyone chasing own tails.
This reply made me very dissuaded from posting again, because you were advising me to use the latest build, that was only a week ahead of mine, to solve a problem I've had for years and years.
Anyways, bumping this thread again with the hopes someone will be able to help. I've tried newer builds and all with the same results, forcing me to go back to r45385.
Just to restate the issue in simple terms...
Background:
r45385, loses connection over PPPoE for any reason, requires clicking "Apply Settings" from the Advanced Routing page to get Internet access. This is fine...but...
Future Builds:
I get no Internet, routes look fine. I can ping google indefinitely, no responses, but when I click Apply Settings on Advanced Routing like normal to fix this weird problem, I get maybe 3-4 successful pings, and back to failures. Routes do not change. Trace routes can be run, and when selecting Apply Settings, they will momentarily work to identify the next hop. I can ping from the router to the google fine.
Whatever my issue is, it's rooted in understanding what exactly happens when clicking Apply Settings from the Advanced Routing page. If someone could just help me figure that out, I could probably fumble my way through the rest. The problem is, I have no idea what is happening to fix the problem, just that a button results in a solution. Thanks to anyone who has insight into any of this.
Joined: 16 Nov 2015 Posts: 6426 Location: UK, London, just across the river..
Posted: Sun Apr 30, 2023 7:34 Post subject:
pppoe its working ok...try reset and reconfigure...from scratch...manually...
old builds are obsolete and not supported...as well those contain lots of missed binary updates and security holes..last build 52369
In your case..to me it sounds as misconfiguration...
do not use NTP time in resolve name format, but use IP instead...like google NTP time 216.239.35.4
some ISP providers are forcing their DNS servers via PPPoE and if you have yours preferred
us Ignore WAN DNS servers..
Do you have a modem in front..that provides the connection...sometimes those need a reboot..first than wait, than turn your router than wait..it could be clearly faulty modem too..(your modem must be in a bridge mode)
does your WAN need a tag number ? - (i read that you need it) on the new builds this is very easy..and its done via GUI..