BUG on autosupport on 8.1RC2. When it will be fixed?

[gmilazzoitag]

As most of you already know there are a lot of bugs that prevent to send 8.1RC2 autosupport using an Exchange relay (2007 and 2010 but also 2003 as tested by myself).

And always as you know the 2240 FAS is shipped only with this DOT release!

This causes a lot embarrassment for us, ASP company, that have to say to the customer that us and them will not be able to receive their autosupport unlesse they install...a Sendmail (or some other Linux machine with STMP relays other than Exchange)...This is unacceptable and, let me say it, ridiculous in that environment where Exchange reigns...

Other source of embarrassment is due to the fact that to send an autosupport has always been a very easy action and now has become a nightmare due this silly bug that DOT does not end the message with CRLF.CRLF but LF (where's the programmer that forgot CR?!?)

To avoid any misunderstanding every fix and/or action has been done on the SMTP relays as from instructions...looking at its log the cause of bug appear clear...timeout on transmission for errors on format.

So: briefly. RC2 is supported and on the market since months...how much time do we have to wait again for a fix?

Thanks

https://communities.netapp.com/message/71152

https://now.netapp.com/NOW/cgi-bin/bol?Type=Detail&Display=549239

https://kb.netapp.com/support/index?page=content&id=1011888

[RODRIGO_SERVIX]

Is there some news about this?

I am facing the same problem into 2 Customers.

[gmilazzoitag]

Not a bit of it!

A collegue of mine wrote also directly to NetApp representatives...no answer at all.

It's really ashamed

[RODRIGO_SERVIX]

Thank´s.

I also opened a case right now.

If I have any news I will post it here.

[admchtxpl]

like to know too, cause receiving a 2240 soon and the customer has exchange only...

[WillFulmer]

Same issue here. Would like to know!

[radek_kubka]

Hi,

As per this thread - https://communities.netapp.com/thread/19507 - apparently 8.1RC2D6 addresses the issue.

Regards,

Radek

[madden]

I can understand the frustration; FAS2240 requires 8.1, and 8.1 has not yet reached GA.  Until a release hits GA no patch ("P") releases are created for it.  So if you have a problem on an RC release you generally have to wait for the next RC release, or the GA release, to get the fix.  You can also request a debug release ("D") if the problem needs to be fixed on an urgent basis. See the release model (http://now.netapp.com/NOW/products/ontap_releasemodel/PostJul2010.shtml) for more information.

This problem is tracked as bug ID 549239.  According to to the Bug release tool (http://now.netapp.com/NOW/cgi-bin/bugrellist?bugno=549239) it is not yet fixed in any general release, although this tool does not include "D" releases that are provided on an as-needed basis only.  You could inquire with support if a "D" release is available for your specific deployment, or you could wait for 8.1RC3 which is targeted to include this fix.  Once 8.1RC3 is released I would verify in the same tool that it indeed fixed in that release.

Regarding workarounds it seems that ASUP via HTTP/HTTPS avoids this issue, as well as a host of other potential issues like email servers rejecting messages due to sender, size, antivirus gateways blocking attachments, etc.  So if you have the ability to use HTTP/HTTPS it would be preferred anyway.

Hope that helps.

[WillFulmer]

Can confirm

8.1RC2D6 does fix this....

http://now.netapp.com/NOW/download/software/ontap/8.1RC2D6/

Burt ID | Burt Severity | Title

549239 | 3 | SMTP encoding issues cause ASUP transmissions fail to MS Exchange mail servers

[klemen_bregar]

Hi!

We have clients with 8.1RC2 (2x2240,2x3240) in production and asup is not working.

For testing purposes i have upgraded one FAS2040 from 7.3.6 to 8.1RC2D6.

I have triggered ASUP before upgrade and after upgrade to 8.1RC2D6. ASUP options and settings were the same in both cases.

I have found out that ASUP in version 7.3.6 is working OK (complete and minimal message), but in the upgraded filer with this patch, we got only minimal ASUP (note.to).

So no difference in this patch vs. 8.1RC2.

Can someone confirm me, that this works in their 8.1RC2D6 systems?

I dont want to lose any more time with this basic thing that should work and explaining to customer that this is bug and it will work in next version .

Thank you!

with regards,

Klemen

[RODRIGO_SERVIX]

Klemen,

         We are running DoT 8.1.2RC2 in a V3070A filer. It will be updated this weekend to 8.1.2RC2D6.

         I will give you my feedback.

Regards,

[gmilazzoitag]

There's a D7 too.

After 7 fixes we expect to have soon an RC3. Maybe it could be better to wait again

[klemen_bregar]

Hi!

I have updated also to D7 version.

It's the same .....

br,

Klemen

[madden]

Debug ("D") releases are meant to be used on an exception basis only upon agreement with the support center.  These releases can contain code that may not be in any other release (for example to enable some normally unsupported v-series backend array, or provide more verbose logging in some subsystem, or to test the fix of a specific bug in a specific customer environment).  As such they are not cumulative either, so D7 does not necessarily include any fixes from D6.  Please see the release model link I provided earlier for a full description.  To reiterate, I would not load a"D" release without support center agreement.

If you think you have a release where this bug is fixed, and you still observe problems, please work with support to troubleshoot.

Hope that helps.

[klemen_bregar]

Hi!

I have an open case for production system and there is some progress with netapp support engineers. We try to find a solution for this problem as soon as possible.

About D-versions - I have tested those patches in our demo lab, because i can upgrade/downgrade the system. I did not open a case for this, i just want to get some ideas from other communities users.

with regards,

Klemen

[gmilazzoitag]

Hi,

thank you for detailed answer but I would explain the main reason of disappointment and frustration

I can accept all the issues that can came from whater RC releas of any software. The things that I cannot accept is that in a "new" release adding "new" features the perfectly running old ones stop to do it...

Sending autosupport or (other bug) licensing some feature is a consolidated thing since 6.x DOT and I cannot accept to waste time supporting or explaining to customers the reasons of this failures.

About the shipping of 2240 without a GA release (also if supported) is all another stuff. In place of NetApp people I would wait before do it and I would put 8.02 on that filer.

Regards,

[gmilazzoitag]

As already klemen did it the D6/D7 DON'T FIX THE ISSUE nevertheless what's in the release notes! Just wasted time (filer is a 2240)

For the more sophisticated technicians here's attached the trace file generated during packet tracing between host and exchange server.

As well shown there's the same timeout that causes the bug.

[lcoppitelli]

Here's the comunication between a FAS2240-4 using 8.1RC2D6 and a MS Exchange 2010

220 pdrpo1.pdr.net Microsoft ESMTP MAIL Service ready at Thu, 16 Feb 2012 17:29:19 +0100
HELO pdrpo1.pdr.net
250 pdrpo1.pdr.net Hello [10.100.101.10]
MAIL FROM:<NetApp-DR@xxx.xx>
250 2.1.0 Sender OK
RCPT TO:<autosupport@netapp.com>
250 2.1.5 Recipient OK
RCPT TO:<netapp@xxx.xx>
250 2.1.5 Recipient OK
DATA
354 Start mail input; end with <CRLF>.<CRLF>
From: NetApp-DR@xxx.xx
To: autosupport@netapp.com, netapp@xxx.xx
Date: Thu Feb 16 14:33:54 CET 2012
Subject: HA Group Notification from NetApp-DR (PERFORMANCE SNAPSHOT) INFO
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="netapp mime boundary"
X-Mailer: Ontap
X-Netapp-asup-version: 3
X-Netapp-asup-content: complete
X-Netapp-asup-subject: HA Group Notification from NetApp-DR (PERFORMANCE SNAPSHOT) INFO
X-Netapp-asup-system-id: 1787*****
X-Netapp-asup-os-version: NetApp Release 8.1RC2D7 7-Mode: Sun Jan 15 23:18:44 PST 2012
X-Netapp-asup-hostname: NetApp-DR
X-Netapp-asup-generated-on: Thu Feb 16 14:33:54 CET 2012
X-Netapp-asup-serial-num: 7000******
X-Netapp-asup-partner-serial-num: <unknown>
X-Netapp-asup-partner-system-id: <unknown>
X-Netapp-asup-partner-hostname: <unknown>
X-Netapp-asup-model-name: FAS2240-4
X-Netapp-asup-conf-version: 8.0.0
X-Netapp-asup-conf-checksum: sOZByZjMPq5vovhybZjN3Q==
X-Netapp-asup-from: NetApp-DR@xxx.xx
X-Netapp-asup-clustered: false
X-Netapp-asup-sequence: 69
X-Netapp-asup-payload-checksum: e00295c10beca22de9b2869c33f1523
--netapp mime boundary
Content-Type: text/plain
GENERATED_ON=Thu Feb 16 14:33:54 CET 2012
VERSION=NetApp Release 8.1RC2D7 7-Mode: Sun Jan 15 23:18:44 PST 2012
SYSTEM_ID=1787*****
SERIAL_NUM=7000***********
HOSTNAME=NetApp-DR
SEQUENCE=69
SNMP_LOCATION=**********
PARTNER_SYSTEM_ID=<unknown>
PARTNER_SERIAL_NUM=<unknown>
PARTNER_HOSTNAME=<unknown>
BOOT_CLUSTERED=
--netapp mime boundary
Content-Type: application/x-compressed
Content-Disposition: attachment; filename="body.tgz"
Content-Transfer-Encoding: base64
[CUT...]
8SQEaaVI/lhlJ+ekZOVkJGQmJiO5mQnZuWlZeYIyIQMW0jc/0uamHLzaA4vCg0u8pJt04oCa
oAH8UnbKgtvNFhh4tsDlE+n6AZfbi6D55L9cVreLwlTgB+TXEHS5ucjjcQXYB1hlRp1Bj4rU
W26mHRykDmoGIyrSAtJJOnC7ivYWTAStVZFWhGbWmElrCNZZ5DFbcQ8eIKBkv4CxQXgoRPTi
 I13A3nESblUADboNtNNgmgR3CytCievCK+wUbjXb4IokJJyncJJE1YSbATktBNtshleSsjLz
 lMH9006qk6AASVlJC9BU5jIS2HZlCFYkgXUTHncFYGuvn6kxnSyShCHBUmAeIIjWIYEMYWfJ
 lgZa7KbKK2SHI4D0esxeN3h9YESZYQE9cMSCZ7EJ4H62Vzg2/p+BweQ8HBysQaqUG3fSjOyF
 rCvbPKZp8BJpHg7vuSlrrAtMrFhMhTK/wAYLKvMUuSmPhyMIJOkXwsoulY3ELRa8FAgpiicK
 osPxLxhUErAX4DGykPRAOUG4PaSNtIB7/BYU4JZir0slrmJ4SIvVZRVVQwySK2QZZBFlt0J5
 LURiRlSA5LAh7+KJeItNVUiWErC5KthTlQXOIbuKcpoBMcood7HZBuSc1y3oX2g5qB/AC4FM
 AsSAognmKiDBmSJWyErY8QoVsIQpp5VGNCgqg+WSiE8WITLYigKycCJVQ451 4.7.0 Timeout waiting for client input

Dosen't seem fixed to me...

[ern]

Thanks for the tracing attachments.

The high level SMTP failure symptoms are the same. It gets an SMTP "Timeout" reply during the DATA exchange.

The problem shows up at the start of sending the Email message not at the end.

The small little SMTP exchanges like "HELO xxx", "DATA", etc. are working but when it sends the first big write over the TCP connection, it doesn't get through. The TCP layer is retransmitting for some reason.

Eventually, the SMTP "Timeout" reply happens.

-Rudy

[djayanathan]

I was running into this issue as well and had previously been stumped as to what the problem was until finding this post. My cluster is also running 8.1RC2D7 and wasn't working until I switched the mailhost to a sendmail server.

Our current implementation is using Cisco Ironports as our primary mail ingesters, not exchange, but the problem was still persistent.

[RODRIGO_SERVIX]

Dear all,

         I upgraded a V-3270 to DoT 8.1RC2D6 and the autosupport integration with an Exchange 2007 is working properly.

Regards,