- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Mailbus 400 trace
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-30-2011 06:56 AM
08-30-2011 06:56 AM
Mailbus 400 trace
We have a problem setting up proper X.400 communications with one of our X.400 provider's systems.
This is what I can see using NCL.
NCL>SHOW NODE xxxx MTA PEER MTA [TYPE = MANUALLY CONFIGURED, NAME = "YYY"] ACTIV
ITY * INTERRUPTION REASON, -
_NCL>WITH STATE = INTERRUPTED
Node xxxx MTA Peer MTA
[
Type = Manually Configured ,
Name = "YYY"
] Activity 48
at 2011-08-28-00:37:08.766+02:00Iinf
with State = Interrupted
Status
Interruption Reason =
[
RTSE Entity that Initiate = This MTA ,
Abort Reason Code = Protocol Violation ,
Local Diagnostic = Not Applicable
]
NCL>
I then try to turn trace on but I get
SET NODE xxxx MTA PEER MTA [TYPE = MANUALLY CONFIGURED, NAME = "YYY"] TRACE ON
Node xxxx MTA Peer MTA
[
Type = Manually Configured ,
Name = "YYY"
]
command failed due to:
access denied
Why is that? I can't see in the Mailbus 400 guide that I should have to enter anything else before trying to turn trace on. Do I have to authenticate in some way to be able to turn trace on?
I have tried this even using the SYSTEM account but with the same result.
Any ideas welcome.
OpenVMS 7.3-2.
NCL>SHOW NODE xxxx MTA version
Node xxxx MTA
at 2011-08-30-15:52:07.932+02:00Iinf
Status
Version = X3.0.9
NCL>
DEC AXPVMS X25 V1.6-3
Kind regards,
Hans
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-30-2011 07:44 AM
08-30-2011 07:44 AM
Re: Mailbus 400 trace
Hans,
I noticed from one of your previous entries that you're using XOT. Why don't you use tcpdump to create the trace and analyse it offline using wireshark.
eg.
$ tcpdump -s 1496 -w mta_trace.trc port 102and host ??.??.??.?? (where ?? is the IP address of your partner)
(assuming you have a TCPIP version where tcpdump is available).
BTW. Your MTA version is ancient. We're using X3.2.17.
Good Luck.
John
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-30-2011 11:06 PM
08-30-2011 11:06 PM
Re: Mailbus 400 trace
John,
Thanks for the tip.
However we're using X.25 for transport so tcpdump would not tell us anything, I'm afraid. I know, that's ancient, too.
But I would like to know more about running Mailbus 400 over TCP/IP.
Do you happen to know if that is possible with our version of MTA?
Thanks in advance.
Kind regards,
Hans
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-31-2011 04:33 AM
08-31-2011 04:33 AM
Re: Mailbus 400 trace
Tjena Hans,
if I'm not mistaken in a previous note you referred to the following definitions:
create x25 access reachable address GXS addre prefi 36:xxxxxxxxxx1234:
set x25 access reachable address "gxs" dte class "xot-class-0"
set x25 access reachable address "gxs" mapping Manual
set x25 access reachable address "gxs" destination xxxxxxxxxx1234
set x25 access reachable address "gxs" address extensions False
enable x25 access
A DTE Class of "xot-class-0" would suggest that the Data Link Provider is based on XOT (X.25 over TCPIP).
If you do a
ncl>show x25 access dte class xot-class-0 all
and publish the results then we can investigate further. If indeed it is XOT then my suggestion still holds.
If you were still running X.25, then it would be either over a X.25 service provider over a leased line or possibly over ISDN.
In all these cases you will discover more if you investigate your underlying X.25 configuartion.
ncl>show x25 protocol dte * all
ncl>show x25 access dte class * all
etc.
As far as the MTA being able to support communication over RFC1006, that has been around for yonks (years). Most of this is usually done via VPNs. One of our customers has practically all his PEER MTAs connected via RFC1006. A few definitions still exist for X.25 (either native or over ISDN) but these are usually backup definitions in case anything happens to the IP connectivity.
As far as your version of the MTA is concerned, what would the problem be upgrading to the latest version?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-31-2011 01:45 PM
08-31-2011 01:45 PM
Re: Mailbus 400 trace
John,
I studied the MTA manual a bit more today.
I understand now that I only have to change the presentation address to make the communication go over tcpip. But as you say, we would need a VPN for that, so that we don't send everything in clear text.
Here are some more information:
NCL>show x25 access dte class xot-class-0 all
Node 0 X25 Access DTE Class xot-class-0
command failed due to:
access denied
NCL>
NCL>show x25 protocol dte * all
Node 0 X25 Protocol DTE *
command failed due to:
access denied
NCL>show x25 access dte class * all
Node 0 X25 Access DTE Class *
command failed due to:
access denied
NCL>
Notice that I get access denied also here even though I run from a SYSTEM equiv account wiht all privileges.
Kind regards,
Hans
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
09-02-2011 12:50 AM
09-02-2011 12:50 AM
Re: Mailbus 400 trace
Tjena Hans,
it seems to me that your account does not have certain rights identifers to allow you to do what you want to do.
Give your account NET$MANAGE and NET$EXAMINE and after you login again things will be good (hopefully).
Can I point you to Chapter 7 "Managing Network Security" in the infamous manual
HP DECnet-Plus forOpenVMS Network Management
Order Number: BA406-90006
January 2005
this should also be available electronically.
John
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
09-02-2011 01:00 AM
09-02-2011 01:00 AM
Re: Mailbus 400 trace
Tjena Hans,
forgot to mention this in my last note, but I was at a customer yesterday that was also still running OpenVMS 7.3-2 and he had the following MTA versions running:
SYS$COMMON:[MTA]MTA$SERVER_V7.EXE "MTA X3.2-10" 30-MAY-2006 13:32:34.46 SYS$COMMON:[MTA]MTA$SERVER_V7.EXE "MTA X3.2-14" 15-FEB-2007 08:24:48.67
I think "MTA X3.2-14" was a diagnostic image that he was given to collect more information due to a problem that he had on ALPHA 4100 that then disappeared when they upgraded to ES47.
Another customer in Austria is also running MTA X3.2-10.
John