Thread Info
  • State Verified Answer
  • Locked Locked
  • Replies 11 replies
  • Subscribers 1 subscriber
  • Views 21044 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Client not getting certificate via RMS "Caught CORBA system exception"

asester

Hey all,

I've got multiple clients that are getting this error in the router log.....and I used the same install package that some of my other clients are using and ARE reporting to the SEC via the message relay.  I am able to telnet to the message relay from the client using 8192 (which returns the IOR with a sequence of numbers) and 8194 (returns a blank screen with a cursor).  I am aware that the Auto Update and RMS services run separate, but I thought I should mention that all of the clients update just fine from the message relay.

I have been reading multiple cases but haven't really seen any concrete resolutions to this issue...and since my problem is sporatic I'm making a new thread.  The 'netstat -n' command I ran on the message relay shows the 8192 ports with the client IP's that I'm having issues with in TIME_WAIT status.

Here is an insert from the router log on the client I'm having issues with.

16.07.2013 15:29:13 050C I Successfully validated parent router's IOR
16.07.2013 15:29:13 050C I Accessing parent
16.07.2013 15:29:18 09A4 I Logged on Agent for certification
16.07.2013 15:29:18 0A30 I Routing to parent: id=03E5AD1E, origin=Router$rv20009056:27138.Agent, dest=CM, type=Certification.CertRequest
16.07.2013 15:30:58 050C E ParentLogon::RegisterParent: Caught CORBA system exception, ID 'IDL:omg.org/CORBA/TRANSIENT:1.0'
OMG minor code (2), described as '*unknown description*', completed = NO
 
16.07.2013 15:31:28 050C I Getting parent router IOR from 165.201.22.33:8192
16.07.2013 15:31:28 050C I Received parent router's IOR: (number way too long to paste...and shouldn't matter since it matches)

16.07.2013 15:31:28 050C I Successfully validated parent router's IOR
16.07.2013 15:31:28 050C I Accessing parent
16.07.2013 15:31:50 050C E ParentLogon::RegisterParent: Caught CORBA system exception, ID 'IDL:omg.org/CORBA/TRANSIENT:1.0'
OMG minor code (2), described as '*unknown description*', completed = NO

etc etc....The log repeats those steps and never obtains the certification request.

Any suggestions?

Thanks,

Adam

:41705


This thread was automatically locked due to age.
Parents
  • 0

    Hi,

    There are potentially a few ways to fix it and 576 isn't the only value that would work.  It's probably not optimum for you I just wasn't sure what the "path" was like between the client and server so went for the lowest just to ensure that was the problem.

    To work out a more sensible MTU for your path (client to relay) I would suggest pinging the server from the client, setting the Don't Fragment (DF) bit and changing the packet length as you go  If you get a reply you're good, if you get packet needs to be fragmented you need to reduce the packet size to squeeze it through the path available.

    So I would start with:

    ping rvhalo3.kdor.ks.gov -f -l 1472

    if you get a packet needs to be fragmented messages then decrease it to say 1460 and try again.

    ping rvhalo3.kdor.ks.gov -f -l 1460

    If you get a reply, then increase it to 1465 for example.  You're essentially trying to figure out the max value that doesn't require the packets to be fragmented, it may take 6 of 7 tries with different values

    Say you find 1460 responds ok 1461 tells you the packet needs to be fragmented then 1460 is the maximum packet size along the path.  In which case I'd probably just set the MTU to 1400.  

    If the value is too low, e.g. 567, you're going to be sending data in smaller chunks than really needed which is quite an overhead and slower and almost 3 times as many packets as you would typically need on a LAN.

    This article is worth a look:

    http://support.microsoft.com/kb/900926

    as is something like:

    http://www.cisco.com/en/US/tech/tk827/tk369/technologies_white_paper09186a00800d6979.shtml

    There are a few ways to fix this, maybe a firewall just needs to allow ICMP traffic for example but hardcoding the MTU is certianly one but may not be the best option for you.  If you don't have control over the full path, i.e. if the traffic is going over the internet setting at source may be your best bet.

    Regards,

    Jak

    :41833
Reply
  • 0

    Hi,

    There are potentially a few ways to fix it and 576 isn't the only value that would work.  It's probably not optimum for you I just wasn't sure what the "path" was like between the client and server so went for the lowest just to ensure that was the problem.

    To work out a more sensible MTU for your path (client to relay) I would suggest pinging the server from the client, setting the Don't Fragment (DF) bit and changing the packet length as you go  If you get a reply you're good, if you get packet needs to be fragmented you need to reduce the packet size to squeeze it through the path available.

    So I would start with:

    ping rvhalo3.kdor.ks.gov -f -l 1472

    if you get a packet needs to be fragmented messages then decrease it to say 1460 and try again.

    ping rvhalo3.kdor.ks.gov -f -l 1460

    If you get a reply, then increase it to 1465 for example.  You're essentially trying to figure out the max value that doesn't require the packets to be fragmented, it may take 6 of 7 tries with different values

    Say you find 1460 responds ok 1461 tells you the packet needs to be fragmented then 1460 is the maximum packet size along the path.  In which case I'd probably just set the MTU to 1400.  

    If the value is too low, e.g. 567, you're going to be sending data in smaller chunks than really needed which is quite an overhead and slower and almost 3 times as many packets as you would typically need on a LAN.

    This article is worth a look:

    http://support.microsoft.com/kb/900926

    as is something like:

    http://www.cisco.com/en/US/tech/tk827/tk369/technologies_white_paper09186a00800d6979.shtml

    There are a few ways to fix this, maybe a firewall just needs to allow ICMP traffic for example but hardcoding the MTU is certianly one but may not be the best option for you.  If you don't have control over the full path, i.e. if the traffic is going over the internet setting at source may be your best bet.

    Regards,

    Jak

    :41833
Children
No Data