We have a camel application that reads in a file and then sends HL7 using https://camel.apache.org/components/3.11.x/mllp-component.html#_mllp_producer. The issue is the rules of the server/networking insist we send FROM a certain port.
Looking at the tcpdump -i any -c5 -nn host x.x.x.x
13:58:24.144736 IP x.x.x.x.37212 > x.x.x.x.5010
13:58:24.650264 IP x.x.x.x.37214 > x.x.x.x.5010
It is picking a different port each time we attempt to send data.
Thanks!
Related
I'm trying to use the JsonTypeAdapter in a modem to transmit some data from a remote source.
The adapter is enabled through the modems startup script (JsonAdapter.enable()), and a TCP connection is established
to the modem at port 1100. I follow the "Hello world" example in the Fjåge documentation and send the following JSON to the modem:
{"action":"send","message":{"clazz":"org.arl.unet.DatagramReq","data":{"data":{"clazz":"[B","data":"aGVsbG8gd29ybGQh"},"msgID":"8152310b-155d-4303-9621-c610e036b373","perf":"REQUEST","recipient":"phy","sender":"MyCustomInterface"}}}
I've set the logLevel to 'ALL' and can see that I get an incoming TCP connection in the log, but no data is being transmitted by the modem.
I'm subscribing to the physical agent but am not getting any notifications in the WebShell (using UnetSocket works fine though).
I'm guessing that either the JsonAdapter isn't active on this TCP connection, the JSON string is faulty or not being sent properly by my application, or something else that I've missed.
I copied any pasted your JSON message, and it worked perfectly fine for me. Steps I took:
I used unet audio SDOAM to test:
$ bin/unet -c audio
Modem web: http://localhost:8080/
> iface
tcp://192.168.1.8:1100 [API]
ws://192.168.1.8:8080/ws [API]
tcp:///192.168.1.8:1100//127.0.0.1.55832 [API]
unetsh: console://- [GroovyScriptEngine]
websh: ws://192.168.1.8:8080/fjage/shell/ws [GroovyScriptEngine]
The 192.168.1.8:1100 API interface tells me which port the modem is listening on (port 1100). So, I connect to it:
$ nc 192.168.1.8 1100
{"alive": true}
The {"alive": true} tells me that I'm connected to the right port, and the modem is saying "hello" :-)
Now, I copy'n'paste your JSON message:
{"action":"send","message":{"clazz":"org.arl.unet.DatagramReq","data":{"data":{"clazz":"[B","data":"aGVsbG8gd29ybGQh"},"msgID":"8152310b-155d-4303-9621-c610e036b373","perf":"REQUEST","recipient":"phy","sender":"MyCustomInterface"}}}
I get a response back:
{"action":"send","message":{"clazz":"org.arl.fjage.Message","data":{"msgID":"41b8264c-be98-4bbe-8b72-8986606513ae","perf":"AGREE","recipient":"MyCustomInterface","sender":"phy","inReplyTo":"8152310b-155d-4303-9621-c610e036b373","sentAt":1586233766542}},"relay":false}
confirming that the message was received, and is being relayed to other slave containers. This is shortly followed by a "buzz" sound that my SDOAM makes to send the frame over the sound card, and the two messages (TxFrameStartNtf and TxFrameNtf) to confirm that the transmission was successfully completed:
{"action":"send","message":{"clazz":"org.arl.unet.phy.TxFrameStartNtf","data":{"txTime":15784016,"txDuration":1511416,"type":2,"msgID":"0a5bae1e-b16c-4bbb-8fcf-36ad55ffc64e","perf":"INFORM","recipient":"#phy__ntf","sender":"phy","inReplyTo":"8152310b-155d-4303-9621-c610e036b373","sentAt":1586233767349}},"relay":false}
{"action":"send","message":{"clazz":"org.arl.unet.phy.TxFrameNtf","data":{"txTime":15759432,"type":2,"location":{"clazz":"[D","data":""},"msgID":"f6e1dee6-ed31-4850-9d90-7b591a740971","perf":"INFORM","recipient":"MyCustomInterface","sender":"phy","inReplyTo":"8152310b-155d-4303-9621-c610e036b373","sentAt":1586233768761}},"relay":false}
What are the different ports used by consul? What is the purpose of each port? Is there any way to configure consul to run using different ports?
When reading the consul documentation you will find following information.
Ports Used
Consul requires up to 4 different ports to work properly, some on TCP, UDP, or both protocols. Below we document the requirements for each port.
Server RPC (Default 8300). This is used by servers to handle incoming
requests from other agents. TCP only.
Serf LAN (Default 8301). This is used to handle gossip in the LAN.
Required by all agents. TCP and UDP.
Serf WAN (Default 8302). This is used by servers to gossip over the
WAN to other servers. TCP and UDP.
HTTP API (Default 8500). This is used by clients to talk to the HTTP
API. TCP only.
DNS Interface (Default 8600). Used to resolve DNS queries. TCP and
UDP.
You can configure consul services to run on different ports by editing the config file. For example setting the dns interface on port 53 and the HTTP API on port 80. More details on port configuration is here.
{
"ports": {
"dns": 53,
"http": 80
}
}
Minor update to the response from #Brrrr:
https://github.com/hashicorp/consul/blob/master/CHANGELOG.md#080-april-5-2017
All CLI commands that used RPC and the -rpc-addr flag to communicate with Consul have been converted to use the HTTP API and the appropriate flags for it, and the rpc field has been removed from the port and address binding configs.
So now the CLI uses TCP on 8500 like other clients.
I have done rpl-border-router.c as router on sky mote and 1 udp-server.c mote on sky in cooja. I connect router using tunslip utility.
I can ping my server as well as router.
I want to send udp data to server via my linux as host via tun0, but i cant manage to send on it. I have notice that by ping from terminal it works , by opening in firefox router shows routes, How to send packet to my server via border router from linux as host.
Use netcat!
netcat -u [node ip] [port]
this opens up a connection to the UDP server on the node and allows you to send UDP messages from the console.
I have two devices connected to a network, but I am trying to create my own little network. I want to route my icmp traffic of client, say 10.10.10.99 through 10.10.10.50 and all the other traffic of 10.10.10.99 should remain unaffected and pass via default gateway.
I was able to route the whole traffic by changing the default gateway, but I no longer want that.
This should be possible in Linux through the usage of ip route add for adding a new table with the new gateway and iptables to mark certain packets destined for a specific port. The new table can then act on the marked packets.
There is a good example for how to achieve this at this link on tldp
For example you can do the following for marking/routing ICMP traffic :
iptables -A PREROUTING -i eth0 -t mangle -p icmp -j MARK --set-mark 1
# create a table icmp.out to handle all icmp traffic
echo 201 icmp.out >> /etc/iproute2/rt_tables
ip rule add fwmark 1 table icmp.out
ip route add default via <gateway> dev <dev> table icmp.out
I'm new to this forum (at least at asking questions), so please be patient. I'm trying to write simple client-server applications to communicate using datagram (UDP) sockets, with C and Windows.
The scenario is very simple, I want to be able to send/receive data from a machine in some local network (behind a GATEWAY/NAT) to some host having public IP. I can send the data, but it seems impossible to receive any data back, because the remote server can't see the client's local IP.
I don't want the user to perform manual port forwarding on the GATEWAY, and I also don't want to use UPnP because of security issues (though it also should be enabled by the user).
I think it is possible because applications like Skype or Browsers can do it, but how ?
Are there some automatically forwarded ports or things like that ? I'm exhausted of searching the web ... PLEASE HELP !
For UDP connections, most home NAT gateways will automatically create a temporary reverse mapping for each outbound packet.
Consider a scenario where your client is running on the internal machine with IP address 192.168.4.5, sending a UDP packet from port 65000 to the external address 64.34.119.12:6789, via a gateway with external IP address 192.0.43.10. When the gateway sees your internal client send a UDP packet from 192.168.4.5:65000 to the external address, it will NAT it to an external address and port, like 192.0.43.10:5500. Your server will see a packet with a source address of 192.0.43.10:5500 and destination address 64.34.119.12:6789. The router also sets up a reverse mapping, so that if it sees a packet arrive on the external interface with a source of 64.34.119.12:6789 and a destination of 192.0.43.10:5500, it will redirect it back to 192.168.4.5:65000. This mapping typically times out after a short while.
This means that in simple cases, all you need to do is:
On the client, use the same port to send to the server and listen for responses;
On the server, respond to the client at the address and port that the client's packet was receieved from, using the same server port that recieved the packet;
Have the client send the initial packet in the conversation;
Don't leave the "connection" idle for more than a few minutes at a time.