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}
Related
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!
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'm using the basic socket functions in C language, the line below:
int res = connect(sock_fd, (struct sockaddr *)&addr, sizeof(struct sockaddr_in));
1. when my laptop is can access the internet, connect will return immediately,connection is built as expected.
2. when my laptop is offline, connect will return immediately, the errno is "network is unreachable.
3. when my laptop is connected to a wifi network that cannot access internet directly(need login opration or sth else), connect will block about 20 seconds before return, the errno is "connection refused"
It can be solved by set the sock_fd nonblocking, I want to know why it takes such a long time before connect return a connection mistake in the third situation?
In the 2nd case (network offline), the operating system knows it is offline and so the network libraries can immediately signal a failure.
In the 3rd case (network online, but unable to reach internet) the operating system thinks it is online, but has no way to tell that in advance that the connection won't succeed. The actual failure mode depends on the nature of the network you are connected to:
In the case you are experiencing, the network simply isn't responding at all to to your connection attempt. Your packets are simply being ignored. Eventually you experience a connection timeout, when the connect function gives up waiting for a response. It is normal for it to wait some period of time before giving up, since not all connections on the internet happen instantly (network is slow or congested, or the server on the other end is slow to respond)
In another case, a firewall might be configured to actively reject connections that are not allowed. This means that it will send a packet back in response that says the connection was rejected. If this happens you would quickly get an error back from connect().
There is a third possibility... this is a situation where you are connected to a network that requires you to enter a password on a web page, or click to acknowledge that you acknowledge the policies for using the internet at that business. No matter what internet site you are trying to access with your browser, you first see this page. This is called a captive portal and is implemented by responding to port 80 traffic at any IP address and sending the login page instead. If you were trying to connect a socket to port 80 (the http port) at any IP address, the connection would succeed (even though you are not actually connected to the remote server you expect). If you are using a port other than port 80, it would instead ignore or block the connection. I mention this in case you are trying to write a program that determines if you are connected to the internet or not. Using port 80 wouldn't work well in this case.
Am just beginner of this socket programming ...
i tried to make a UDP client_server program using SOCK_RAW .I can send message from the server part.But in client part am getting garbage values. And the receiving message packet size also different.Can U help me to do this client server program using SOCK_RAW.
I tried this client -server with eth0 & eht1,i tried to send 1 packet from eth0 to eth1 sending side is showing "OK" message.. but received data is garbage..
before i done normal client server program using UDP protocol.I got correct output from normal udp client server .When i tried with SOCK_ROW its showing error in sending part.
Make your life simpler and use SOCK_DGRAM - Kernel will take care of datagram headers, you only need to provide valid IP address and data. It is user's responsibility to append (before transmitting) and parse (upon reception) UDP headers using SOCK_RAW.
Most likely you are seeing IP and UDP headers and calling them "garbage". That is what SOCK_ROW does. You should parse and skip protocol headers if you want to get to your message content while using SOCK_ROW.
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.