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

This was the error code I was getting with Windows update.

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, 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.

VDSL modem had the same IP address as my gateway address on LAN.

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.

Wireshark recording erroneous network traffic.

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.

Verifying the culprit setting was the actual one to cause the problems.

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.

Finally the Windows Update was working fine 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.

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

  1. I got here by searching for “windows update 80072ee2 destination unreachable fragmentation needed” – which effectively means that I’m experiencing exactly the same problem!

    ethtool --offload eth4 rx off tx off
    A single line on the VM-host machine probably saved me some weeks of frustrating investigations!

    Now I gotta find out what this setting actually does and if there are any notable downsides. I’m using a business class Intel Network Card on a Debian stable and it would have been the last place for me to look for the cause!

    Thank you (and the IRC guys!) a lot for your efforts and the detailed description!!

    Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet Controller (rev 06)
    Intel Corporation PRO/1000 PT Quad Port Server Adapter
    Kernel driver in use: e1000e

Leave a Reply

Your email address will not be published. Required fields are marked *