ATT Uverse + Tomato firmware = connection timeouts & reset every 10min (Fix inside)

[DigitalChaos]

This took me a bit to figure out and the google results are very lacking. I am posting this here for anyone who may have this issue and to utilize the genmay page rank to get the answer up to the top for anyone searching

This problem applies to Tomato firmware and various versions of the DD-WRT firmwares.


Problem:
Attaching a router with the Tomato firmware (currently running 1.25) to an ATT Uverse (U-Verse) connection causes issues where connections just drop. Youtube videos will stop loading, large downloads will stop loading, various download apps will report that every one of its connections has timed out.

Upon checking the logs I noticed the following occuring every 10 minutes on the dot:

Nov 10 20:34:12 ? daemon.info dnsmasq[20484]: exiting on receipt of SIGTERM
Nov 10 20:34:12 ? daemon.info dnsmasq[21112]: started, version 2.47 cachesize 150
Nov 10 20:34:12 ? daemon.info dnsmasq[21112]: compile time options: no-IPv6 GNU-getopt no-RTC no-DBus no-I18N no-TFTP
Nov 10 20:34:12 ? daemon.info dnsmasq[21112]: DHCP, IP range 192.168.1.100 -- 192.168.1.149, lease time 1d
Nov 10 20:34:12 ? daemon.info dnsmasq[21112]: reading /etc/resolv.dnsmasq

In short, the WAN interface was doing a full restart every 10 min. If you enable Connection Logging on the Inbound traffic ("If Blocked by Firewall") you can see exactly what is going on:

Nov 10 20:53:37 ? user.warn kernel: DROP IN=vlan1 OUT= MAC=00:...:4d SRC=73.140.116.1 DST=73.140.116.55 LEN=333 TOS=0x00 PREC=0x00 TTL=255 ID=22234 DF PROTO=UDP SPT=67 DPT=68 LEN=313 
Nov 10 20:53:55 ? user.warn kernel: DROP IN=vlan1 OUT= MAC=00:...:4d SRC=73.140.116.1 DST=73.140.116.55 LEN=333 TOS=0x00 PREC=0x00 TTL=255 ID=58917 DF PROTO=UDP SPT=67 DPT=68 LEN=313 
Nov 10 20:54:04 ? user.warn kernel: DROP IN=vlan1 OUT= MAC=00:...:4d SRC=73.140.116.1 DST=73.140.116.55 LEN=333 TOS=0x00 PREC=0x00 TTL=255 ID=2949 DF PROTO=UDP SPT=67 DPT=68 LEN=313 
Nov 10 20:54:09 ? user.warn kernel: DROP IN=vlan1 OUT= MAC=00:...:4d SRC=73.140.116.1 DST=73.140.116.55 LEN=333 TOS=0x00 PREC=0x00 TTL=255 ID=21930 DF PROTO=UDP SPT=67 DPT=68 LEN=313 
Nov 10 20:54:10 ? user.warn kernel: DROP IN=vlan1 OUT= MAC=00:...:4d SRC=73.140.116.1 DST=73.140.116.55 LEN=333 TOS=0x00 PREC=0x00 TTL=255 ID=6801 DF PROTO=UDP SPT=67 DPT=68 LEN=313
Nov 10 20:54:12 ? daemon.info dnsmasq[21885]: exiting on receipt of SIGTERM
Nov 10 20:54:12 ? daemon.info dnsmasq[22442]: started, version 2.47 cachesize 150
Nov 10 20:54:12 ? daemon.info dnsmasq[22442]: compile time options: no-IPv6 GNU-getopt no-RTC no-DBus no-I18N no-TFTP
Nov 10 20:54:12 ? daemon.info dnsmasq[22442]: DHCP, IP range 192.168.1.100 -- 192.168.1.149, lease time 1d
Nov 10 20:54:12 ? daemon.info dnsmasq[22442]: reading /etc/resolv.dnsmasq

What you see there is the router blocking the incoming DHCP lease renewal (destination port 68 and source port 67 indicate it to be DHCP traffc) . The blocking happens because of a mismatch of addresses in the DHCP process and the SPI freaking out about it.


The fix for this is easy. Just SSH in and poke a hole in the firewall for this traffic coming from the DHCP server by running this:
iptables -I INPUT -p UDP -i vlan1 --dport 68 --sport 67 --source 73.140.116.1 -j ACCEPT
substituting your DHCP server of course


This config will be lost upon reboot. In the Tomato firmware you can simply add that exact command to the firewall script in the Web UI (Administration>Scripts>Firewall) and save it. The script will start working after you next reboot the router.


Thats it!


You can verify that this command is functioning by seeing if any additional log entries show up where the SPT=67. You can do that via the web UI and manually search or simply SSH into the router and run: tail -f /var/log/messages | grep SPT=67
Let it sit there for at least 10 minutes. If anything starts showing up in the next 10min you didn't do it right!



edit: If you want to be really lazy and insecure you can just accept DHCP traffic from all addresses(not smart) by using:
iptables -I INPUT -p UDP -i vlan1 --dport 68 --sport 67 -j ACCEPT
This is good for testing if you are having trouble figuring out what your DHCP server's IP should be though.You can remove this by simply rebooting the router (Make sure to pull it from the scripts if you put it there before rebooting).

[:ninja:]

Originally Posted by DigitalChaos

edit: If you want to be really lazy and insecure you can just accept DHCP traffic from all addresses(not smart) by using:
iptables -I INPUT -p UDP -i vlan1 --dport 68 --sport 67 -j ACCEPT
This is good for testing if you are having trouble figuring out what your DHCP server's IP should be though.You can remove this by simply rebooting the router (Make sure to pull it from the scripts if you put it there before rebooting).

So... what is "not smart" about this? It's not like you're going to be getting DHCP offers from your neighbor.

[DigitalChaos]

Originally Posted by :ninja:

So... what is "not smart" about this? It's not like you're going to be getting DHCP offers from your neighbor.

Are you going to tell us how semantics allow for your opinion to be correct in a parallel world where firewall management 101 does not apply? Cmon, I know you had it all ready to go. That is usually how you troll this forum.

[:ninja:]

Originally Posted by DigitalChaos

Are you going to tell us how semantics allow for your opinion to be correct in a parallel world where firewall management 101 does not apply? Cmon, I know you had it all ready to go. That is usually how you troll this forum.

If I had it all ready to go, I would have posted it. This is how I troll threads where I have no experience or knowledge of the subject material.

[DigitalChaos]

Originally Posted by :ninja:

If I had it all ready to go, I would have posted it. This is how I troll threads where I have no experience or knowledge of the subject material.

I figured you were about to go into a derail like you usually do
If you are honestly curious then the answer is:
With firewalls you always poke the smallest hole. That is just security best practices. Someone could certainly send you a false DHCP lease and screw things up for you. It is even possible that there is some exploit that could be sent via DHCP. There is a reason this stuff is blocked by default.

[VanFanel]

Ooooh! That's good to know; I am planning to acquire U-Verse when I swap residences and I currently have a router with Tomato firmware =D

[smallfrys]

I registered for this site just to thank you. I've been having this problem for the whole month since I've gotten u-verse and previous google searches hadn't turned up much, just like you said. In addition, the only relevant thing I could find (which turns out was similar to your solution but wasn't well explained) was on the u-talk (AT&T official u-verse) forums. There, the idiot responses said the guy was wrong for claiming that the fact the RG was sending stuff on different source vs. destination ports could be throwing off his router; they claimed that he hadn't set his network up correctly. I've been having RS links fail over and over again for the past month, not to mention interrupted hulu streams and crazy ping/disconnects on vent and WoW.

So, thank you! I'll be sure to look around these forums more and see what's up when I have some time.

Here are the threads so you can post the link to your solution here if you like. I'm not registered there (since I could tell their advice seemed pretty worthless), but it may help drive your page ranks up.

http://utalk.att.com/utalk/board/mes...thread.id=9836
http://utalk.att.com/utalk/board/mes...thread.id=4098

Also, this thread is older, but seems they were having the same problem:

http://utalk.att.com/utalk/board/mes...cending&page=2

[DigitalChaos]

^ Nice! I will go and give those threads the fix when I get a chance to register. The real root of the problem is with the 2WIRE gateway's DMZ. Any SPI firewall is going to have issues out of the box in this situation. It just so happens that Tomato and other WRT variants are the most common SPI firewalls that people drop in there.

I actually contacted ATT about this. A few days later I told them I found the fix. They told me that they would "pass the problem to their engineers" even though they knew nothing about what the issue was or what the fix was. I passed on the details of the fix and what the actual problem was and she would post it on their forums knowledge base. Haven't seen that yet...

[Voodoo]

I would also like to say thank you!

I noticed this problem after I upgraded to Tomato 1.25 (I believe) a while ago. I foolishly thought it was a problem with the firmware, so I downgraded back to 1.23 and left it. The problem reappeared when I recently upgraded to 1.27, so I thought I would search to see if anyone else was having the same problem.

However, I haven't been able to resolve the problem yet. I enabled logging of incoming connections if blocked by the firewall like you said. I am not seeing any of the user.warn kernel: DROP entries. Here is an excerpt from my log:

Nov 30 18:59:59 ? daemon.info dnsmasq[1288]: exiting on receipt of SIGTERM
Nov 30 19:00:00 ? daemon.info dnsmasq[1497]: started, version 2.51 cachesize 150
Nov 30 19:00:00 ? daemon.info dnsmasq[1497]: compile time options: no-IPv6 GNU-getopt no-RTC no-DBus no-I18N DHCP no-scripts no-TFTP
Nov 30 19:00:00 ? daemon.info dnsmasq-dhcp[1497]: DHCP, IP range 192.168.0.50 -- 192.168.0.99, lease time 1d
Nov 30 19:00:00 ? daemon.info dnsmasq[1497]: reading /etc/resolv.dnsmasq
Nov 30 19:00:00 ? daemon.info dnsmasq[1497]: using nameserver 192.168.1.254#53
Nov 30 19:00:00 ? daemon.info dnsmasq[1497]: read /etc/hosts - 0 addresses
Nov 30 19:00:00 ? daemon.info dnsmasq[1497]: read /etc/hosts.dnsmasq - 8 addresses

After accessing my 2WIRE modem, I saw that it is connecting to my AT&T DSL via PPPoE. I am hesitant to change this for fear of losing my connection completely. Could this be why I'm not seeing any dropped DHCP connections? Any idea of how to troubleshoot/fix this?

[DigitalChaos]

Can you post more of the log? At least 20min worth of logging please.

All you have there is the general startup sequence. If there is nothing more then it is not properly logging or it is not blocking. If you don't have *any* drop entries over the course of a few hours then your logging is very likely not working (or you somehow bypassed the firewall)

Additionally, you could try adding the "iptables -I INPUT -p UDP -i vlan1 --dport 68 --sport 67 -j ACCEPT " to the firewall temporarily to see if the issue goes away.


The PPPoE thing should matter as far as I know. If you have the same issue it is because your Tomato device first gets the DHCP lease from the 2WIRE, then an outside IP is doing the renewal.

[Voodoo]

No luck with the "iptables -I INPUT -p UDP -i vlan1 --dport 68 --sport 67 -j ACCEPT" command, still dropping every 10 minutes on the dot. Log file sent to your PM

[DigitalChaos]

Ok. So you are definitely having the DHCP issues. 10min on the dot corresponds to the 10min DHCP lease. You also have some DHCP stuff going on right before it restarts the interfaces each time.

I need some info about your setup.
- Is the Tomato device acting as the DHCP server for your LAN?
- Is the WAN interface on the Tomato getting a public IP or is it a nonroutable (192.168... etc)?
- I assume that the only thing plugged into the 2WIRE is the tomato?

[Voodoo]

1) Yes. I configured my 2WIRE to use the DMZPlus mode to direct all traffic to my router (WRT54G v2), then disabled DHCP on the 2WIRE. I access the modem at 192.168.1.254 and my router at 192.168.0.1

2) The WAN interface on Tomato is getting a public IP via DHCP.
IP: 76.210.69.x
Subnet: 255.255.255.252
Gateway: 76.210.69.(x-1) ... is this a coincidence?
DNS: 192.168.1.254:53

3) Yes. Wireless is also disabled on the 2WIRE

[DigitalChaos]

Let me know what you find out with the various tests we talked about over IM. Really seems like the logging is not functioning properly and there may be some network , config, or firmware version weirdness at play.

[KpaBap]

Why is any of this necessary? I have had Uverse for a long time now (over a year) without the need for any of this shit. You can't directly attach a Tomato/DD-WRT router to the VDSL2 line anyway.

Throw the router in the AT&T home gateway DMZ and be done with it, without having to do any of this shit. More importantly, what's the need to have Tomato/DD-WRT be your default gateway? The residential gateway crap works just fine.

A fine example of doing things the hard way here.