Window update error 80072EE2 or: How I Learned to Stop Firewalling and Love the IRC

Recently I switched from Fiber Internet connection to VSDL. As a geek I of course have my own Linux gateway machine (I’m using Fit-PC2i from CompuLab). I had everything working fine before the switchover. I foolishly thought I would be fine by just disconnecting the cable from ISP Ethernet socket and plugging it in to VDSL modem in bridged mode. Things didn’t quite go that way.

I noticed soon that almost everything worked. Except few things. Some webcams were not showing anything, speedtest.net was barfing out, as were some web-based TV channel videos via flash delivery. Most notably, however, Windows Update was giving the less widely known 80072EE2 error. I’m running Windows 7 on my PC and Debian Stable on the gateway machine. I’m naturally not using any Microsoft WSUS technologies in the middle or anything.

I dismantled everything else on my network until I had only my PC, Linux gateway and VDSL modem installed. Error remained. Being a bit laggy for first hop when doing tracerouting, I thought maybe somehow the VDSL modem is advertizing wrong routes or something like that. After fiddling out a bit I nailed it, I thought.

The modem was having the same IP address as LAN gateway. Not a good thing! I thought I caught it this time and changed the modem IP address settings. I fired Windows Update again. And again I was greeted with the 80072EE2 error. I was getting very desperate.

I took a look with Wireshark next. The capture showed a lot of Destination unreachable (fragmentation needed) messages with TCP Retransmission entries. I thought I was doing something wrong in firewalling, so I plugged in an old Buffalo Wlan router with Tomato Firmware. To my surprise the update started to work. My next logical conclusion was that maybe, just maybe the MTU discovery was somehow broken. I saw an interesting iptables rule about matching invalid mtu value and using TCPMSS target on Buffalo and proceeded to make an exact copy of all the rules to my gateway box. Did it work? No.

I was seriously losing it at this point. I reinstalled the gateway Linux from the latest Debian Stable 7.5 .iso. No luck. I had spent week in diagnosing this . I spend few more hours making the iptables rules again. As you guessed, a big fat no go still.

Then, as a final desperate push I logged on to FreeNode IRC network. I asked on #help about where to go for network issues. They said I was best off at ##networking. I went there and asked my question with pastebin info of anything relevant. They checked out my iptables rules and basically they were not fatal. Everything should work. Then. Somebody said it.

2014-07-13 19:42 < xxx> usvi: so somewhere there is most likely tcp offloading issues
2014-07-13 19:43 < xxx> usvi: disable offloading on the linux gw machine

I was absolutely dumbfounded at this point and completely unable to read relevant manpages or anything else for that matter. With shaky fingers I googled the relevant syntax.

ethtool --offload eth0 rx off tx off
ethtool --offload eth1 rx off tx off

I tried it and. It. Worked. Everything started working. Everything. Because I wanted to be absolutely sure this was the specific setting causing all the harm, I run the reverse command to cause the offloading go back again.

Boom there it was. So, offloading was causing the issue. Interestingly, it was also causing a similar connection issue with my Eye-Fi picture uploads on my virtual Windows 7 ESXi 5.5.0 guest. After reading the relevant Wikipedia article, I thought I can live without the offloading. I don’t know the speed penalties for this, but I get 90 Mbps downloads and 12.3 Mbps uploads through the router and that is enough for me.

Without the knowledge of the people on FreeNode ##networking I might still be in the dark. So kudos for them. I have no idea why the offloading is an issue. Maybe there are some driver bugs as the integrated NICs are cheap-ass r8169 Realtek ones. They are being listed as:

02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 02)
03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 02

I will update this post if I manage to get more relevant information about offloading issues.