A couple months ago a new RFC destination was configured in SAP to allow IDOCs to be sent to another program, ADAPTRIS.
We have since changed the server that hosts ADAPTRIS and the IDOCs no longer send successfully.
Checking SWU2 shows the following error 'Error when opening an RFC connection'.
How do I change the IP Address of the RFC destination in SAP?
Thank you.
You can use SM59 tcode for editing RFC-connections.
Depending on connection type its destination can be changed, for example, like this:
Related
I am trying to implement a monitoring system using ONOS. I am able to collect the port delta statistics from them using port_stat_changed listener.
In the flow statistics, I get the flow entry, which has selection criterion. This criterion only has only Ethernet information. Is there any way to identify the Source and Destination IP address and Port using ONOS. Any suggestion would be very helpful.
The source and destination IP and MAC if they are not in the Switch's rules can be accessed by the application by taking this information from the packets. If your application does not have access to the packages, I do not think the Switches store this kind of information. In case, then, you're going to have to develop a solution by putting a rule in the Switch to pick up that data.
I am working with pcap in an OS X application to understand packet analysis.
I am working with a app https://github.com/jpiccari/MacAlyzer
but I am getting only raw data but I want to differentiate every domain request into separate and clear way to read request and response value. Please guide me the way to how to develop an application with pcap.
I have tried some code but they translate data into hex format. How do I convert that data into meaningful request and response objects like Charles and Fiddler show?
MacAlyzer wasn't developed for your needs. I know because I'm the author. As already stated, Charles and Fiddler are web proxies and work entirely different (and serve different purposes).
Diving a bit deeper into your question, communication between client and server happens IP-to-IP and not domain-to-domain. Domain information is not contained in the packets at the either the IP or TCP level. Instead computers request domain-to-IP lookup information which is then stored and communication is carried out using the client and server IP addresses.
MacAlyzer, and really libpcap, don't have sophisticated packet dissection (like say Wireshark) and cannot display packet information as verbosely as other programs. Before I lost interest in the project I was planning a library that would allow much richer packet dissection and analysis, but free time became very limited.
As for adding domain information to MacAlyzer, I'll explain at a high-level since it seems you know what you're doing. To include domain information instead of IP address in the Source and Destination columns you could edit function ip_host_string() in ip.m. This function controls how the client and server addresses are displayed. Modifying it to lookup the hostname from IP address and returning the resulting string would cause the domains to be displayed instead of IP addresses.
If you come up with some nice updates, consider submitting a pull request.
Here is the food for thoughts:
http://www.binarytides.com/packet-sniffer-code-c-linux/
Anyway, you will need to use C. Therefore, check the codes of the includes, for example:
http://www.eg.bucknell.edu/~cs363/2014-spring/code/tcp.h
Here is the documentation of "pcap":
http://www-01.ibm.com/support/knowledgecenter/#!/ssw_aix_71/com.ibm.aix.basetrf1/pcap_close.htm
I'm using NServiceBus with MSMQ and I'm trying to send a message from a computer in one domain to another computer in a different domain. A trust exists between the two domains.
The two computers can ping each other, but only if they use the fully-qualified name of the computer, e.g. pc01.mydomain.net.
In the config file on the computer that sends the message, I've ensured my MessageEndpointMappings are correct by setting the Endpoint attribute to be "Endpoint#pc01.mydomain.net". If I try to send a message then it arrives OK at the pc01 endpoint.
However, when the pc01 endpoint tries to send the reply back to the sender (let's say that computer's name is sender01.anotherdomain.net) it fails to deliver the message. When I check Bus.CurrentMessageContext.ReplyToAddress it returns "queuename#sender01". I believe (although I can't prove it) that if the ReplyToAddress was "queuename#sender01.anotherdomain.net" then the reply would arrive in the correct queue as desired.
So I just need a way to ensure the ReplyToAddress has the fully-quailfied name of the computer (sender01.anotherdomain.net) rather than just the computer name (sender01).
Does anyone know how to do this?
Create an outgoing transport message mutator on the sender that updates the ReplyToAddress accordingly.
In v4 you can override the way we resolve machine names by changing the RuntimeEnvironment.MachineNameAction func.
What are the essential differences between publishing a message using Bus.Publish and sending a message using Bus.Send? I am looking to understand how they differ and also when I should choose to use one over the other.
Publishing is used to notify multiple Subscribers of a particular event. A Publishing endpoint will have subscription storage to identify where to send messages to. Sending is typically used to issue a command to an endpoint. A command is telling the endpoint to do something and should not expect a reply(although you sometimes do want a reply and NSB supports this).
The reason you do not see a destination for Send() is that you specify the destination via configuration. In your app.config you will map message types(a whole assembly or a class) to a destination. When you do so, you do not have to provide the destination.
Bus.Publish: used when you don't know where the message is going (0 to many subscribers).
Bus.Send: when you are sending a message to a specific handler (client to server).
ususally Context.Publish() is for publishing Event Type and Context.Send() is for Command Type
What does the POP3 CAPA UIDL command do?
It checks if the pop3 server understands (has the CAPAbility) the UIDL command.
The response should be "+OK" or "-ERR" depending on wether the server supports the UIDL command.
The UIDL command returns (if supported) an uniqe identify for each message, so a client can identify messages reliably.
See also: rfc2449(CAPA) and rfc1939(POP3).
CAPA is one command. UIDL is another command. You can try them out using telnet to port 110 of the POP server ( telnet:pop.example.com:110 ). After telnet establishes the TCP connection the POP server should send something like "+OK The Microsoft Exchange POP3 service is ready." You can type "CAPA" and hit return, then the POP server should respond with a list of capabilities that it supports (in that state of the session, that is prior to logging in). You can log in by sending "user #name# and hit return, where #name# would be changed to your POP account name. You then type "pass #pw#" and hit return, where #pw# is your password. This sends you password over the network in the clear so someone sniffing the link could easily see your password. Your POP server may require other more secure login. (Don't type in the double quotes in the example above).
Assuming that went well, you can try "CAPA" again now that the session has been established and is in a different state. The list of capabilities may be the same or different depending on the server configuration. At this point you can type "STAT" and hit return. The POP server should return "+OK #x# #y#" where #x# is the number of messages and #y# is the length in bytes of all the messages. Now you can try typing "UIDL" and hit return. the POP server will return a list with "#n# #uid#" where #n# is the message number and #uid# is a unique identifier assigned by the POP server.
Type QUIT and hit return to end the session and close the TCP connection.
The UIDL capability indicates that the optional UIDL command is supported.
POP3 servers may assign a unique number to each incoming mail message. This allows mail to be left on the server after it has been downloaded to the user. Both the mail client and the POP server must support this feature.
According to the POP3 RFC the UIDL command will give you a Unique ID for a message.
The RFC goes on to say:
The unique-id of a message is an arbitrary server-determined string, consisting of one to 70 characters in the range 0x21 to 0x7E, which uniquely identifies a message within a maildrop and which persists across sessions.
The POP3 Exensions RFC says that the CAPA command allows you to query the capabilities of the server.
So the CAPA UIDL command is used to see if a server supports unique IDs.
UIDL is the Unique ID listing capability described in RFC 1939. It means the server supports generating unique IDs for each message to make it easier for the client to handle messages left on the server.
Gives the unique identifier for a message on the POP3 server.
Possible responses: +OK or -ERR