I'm working on a Go program that receives packets and wants to see receipt timestamps.
In C this would be done by setting the SO_TIMESTAMP/SO_TIMETAMPNS socket option and then using the CMSG macros to extract data from a control message buffer structure,
I have searched the Go documentation for a way to do this, in vain. Can anyone point me art a working example?
You can get them from UDPConn::ReadMsgUDP, the ancillary data was named "oob" for some weird reason, but it is the ancillary channel with the control messages.
You can parse the []byte with the control message data using x/sys/unix::Cmsghdr (https://pkg.go.dev/golang.org/x/sys/unix#Cmsghdr)
There should be a better way, but at least this is not behind "internal"...
Related
I am trying to make a snmp trap receiver, that can capture all the incoming snmp trap from UDP 162 port and translate them into meaningful alarms. The image I attached is a sample trap that I captured using wireshark.
My script can capture and parse all different parts of the packet, but I got stuck in the variable binding section. Im not sure how I can re-present this section into some user friendly information (that I can show in the user interface). How do I know these sequences are sending something alarming or just some general information regarding the agent node? are these sequences independent information each or together they are forming one piece of information?
As with any incoming data, it is important to know what kind of info you are getting. The variable bindings of an SNMP trap is basically a hierarchical piece of data. Every object or element represents it's own data. If you take the first element (1.3.6.1.2.1.1.3.0) you will find that this contains the sysUpTime (see link), which is pretty general.
Most of the other elements seem to start with 1.3.6.1.4.1.4421 which appears to be object from a specific vendor; Santera systems (see link). You might want to try and contact them in order to obtain their MIB (Management Information Base), which should have details on what kind of data is shown in these fields.
It might be possible to find info like this online, have a look at the XML-files on this link.
I have a
struct ip ipHeader;
that I want to attach in front of the actual data, which is
string data;
so that I can send it in one packet via the send function, which takes in a char* buffer. How would I go about trying to concatenate these? I need to attach this ipHeader because it's a custom header that's different from the UDP header that's automatically attached when sending messages.
edit* A clarification is that I need to attach this header along with the UDP header that's attached when sending. Hence, SOCK_RAW is not necessarily what I need/want.
In order to send two pieces of data as a single packet, you have two main choices:
Copy them both into a new buffer, and send that.
Use writev() (WSASend() on Windows).
The second approach is appealing because it seems to be designed for exactly what you're doing: sending two (or more) buffers at once. But in my own testing, it was not actually faster (on Linux) than the first approach.
The fastest and simplest solution is often to simply embed the header in your data from the start. So whenever you allocate a message, add space for the header at the start. You can then use "placement new" to invoke the header constructor if there is one, or simply assign its fields.
I'am developing a server for a GPS Tracker that can send pictures taken by a camera connected to it, inside a vehicle.
The problem is that I follow every step in the manual and I can't still decode the bytes sent by the tracker into a picture:
I receive the picture in packages separated by the headers and "tails", each one. When I receive the bytes I convert them into hexadecimals as the manual expecifies, then I have to remove the headers and "tails" and apparently after joinned the remain data and saved as a .jpeg, the image should appear, but it doesn't.
the company name is "Toplovo" from China. Have anyone else solve something similar?
Are the line feeds part of your actual data? Because if so I doubt that's supposed to happen.
Otherwise, make sure you're writing the file in binary mode. In some languages this matters. You didn't really specify, but make sure you're not in text mode. Also make sure you're not using any datatypes unsuited for hexidecimal values (again, we don't even know what language you're using, so, it's kind of hard to give specific suggestions.)
I want to develop a p2p app which communicates via UDPSockets. I'm just starting to read the docs for that and I couldn't understand that piece of ruby's socket management.
Specifically it's possible to add those "flags", as ruby-doc calls them, to every send call. (http://www.ruby-doc.org/stdlib-1.9.3/libdoc/socket/rdoc/UDPSocket.html#method-i-send)
But when do I use those and how?
You'll probably know if you need to use them as you'll have an example or some documentation that refers to them.
Some of the more common options used with recvfrom are: MSG_OOB to process out-of-band data, MSG_PEEK to peek at the incoming message without de-queueing it, and MSG_WAITALL to wait for the receive buffer to fill up.
These are really quite edge-case so you probably won't ever see one used.
Those flags come from the low-level recv call on which Socket is based.
I would like to use Boost's shared memory services to do the following. I have been begun studying the documentation but as a aid to that was hoping someone could provide an example that is close to what I want to do.
Here it is:
Process A will write messages to a buffer area. It will also maintain a map, mapping message ID to information regarding the start location and size of the message in the buffer. Some locking mechanism, possibly a scoped lock, will control access to the map and buffer area.
Process B will read these messages based upon message ID.
Thanks in advance for any constructive suggestions.
Have you looked at the Interprocess - message queue documentation?
It doesn't do exactly what you're asking for, as far as making each message have an ID and such, but you don't go into detail as to why that is necessary. Since there's only two processes, will it work to simply copy the data over to process B?