i'm still kind of newbie to ruby, but i became used on using ruby sockets, cause i used the 'Socket' class many times, and so i having full control to my sockets and their options.
the thing is i'm trying to make it a little easy for me, so i'm trying to use the 'TCPSocket' class ,witch (i guess) doesn't give u much control as the 'Socket' class.
my script looks like this:
require 'socket'
client = TCPSocket.open('5.5.5.5', '5555')
client.send("msg", 0) # 0 means standard packet
client.close
the question is, what is suppose to be instead of the '0' on the send line ?? and if '0' means standard packet, what other than standard can exist there, is it some control over the TCP packet ?? if so, then it will be much easier for me than writing the whole socket by hand using the 'Socket' class.
The second parameter to send is the flags parameter. It gets passed onto the the send system call. You'll normally want to leave this at 0.
On my system, according to the man page, the other possible flags are:
#define MSG_OOB 0x1 /* process out-of-band data */
#define MSG_DONTROUTE 0x4 /* bypass routing, use direct interface */
Related
Apologies for such a generic title but couldn't think of any better.
I am trying to understand where in drivers/i2c/ is the protocol sequence of sending START, ADDR, DATA, STOP bit sequence implemented, as per the protocol. I want to verify the protocol for send/receive in the driver code, that's all the objective here.
I am using Hikey 620 as a reference which has DesignWare's I2C controller. Below is the registration code I can see (elixir):
static const struct i2c_algorithm i2c_dw_algo = {
.master_xfer = i2c_dw_xfer,
.functionality = i2c_dw_func,
};
If I trace the i2c_dw_xfer function recursively, the last call I could see are readl_relaxed, writel_relaxed in i2c_dw_xfer_init() (elixir).
Beyond this is all assembly. Are these readl/writel the actual sequence of start/data/stop byte sequences? Or am I understanding it totally wrong?
In that case, please help and point me to the correct flow. If what I got is correct, is there some simpler controller code which has a cleaner implementation and can be used as reference.
The protocol itself is not part of the driver code. What the dw_{readl/writel} functions do by calling readl/writel is write to the registers of the I2C peripheral of the concerned SoC. It is the job of the I2C controller on the SoC to then generate the correct I2C signalling. You can see by going through the datasheet that something like DW_IC_CON is a register offset in the I2C peripheral memory map.
I would like to do 2 things.
Recognize when someone is calling - In terminal will appear RING and to answer I have to send command ATA. But How can I recognize it when I am doing something else. Should I use new thread and read port until send RING? Is there any beter solution?
What is a symbol of end of response? I'm reading char using for(), but I do not know number of signs. Example below doesn't work properly
while(readCharUART()!=10) {};
while(readCharUART()!=13)
{
getchar() = ..
}
You are on the right track.
For RING then yes, the correct way to do it is to have one thread just read modem responses until you get the Unsolicited result code RING. If you from time to time want to run AT commands (say ATA), then you should let this thread do that as well, e.g. you have one thread that takes care of both issuing AT commands and monitor for UR codes.
Regarding formatting of responses from the modem, this is well described in chapter 5.7.1 Responses in the ITU V.250 standard. Short summary (reading the spec is highly recommended!):
<header>RING<trailer>
where header and trailer is both "\r\n" (unless the modem is configured strangely).
While trying to learn more about linux kernel networking ... I have a kernel module that contains a protocol which runs on top of TCP. Its almost an application layer protocol I'm experimenting with. The calls are passed in via the normal system call interface as executed from userspace.
So network calls from within my (layer above TCP) module generally look like this ...
ret = sock->ops->connect(sock, (struct sockaddr *) &myprot.daddr,
sizeof(myprot.daddr), flags);
I've used sendmsg/recvmsg successfully within my KM to send and receive data from a client to a server (from two separate kernel instances). The calls within the KM generally looks as follows:
ret = sock->ops->sendmsg(iocb, myprot.skt, &msg, sizeof(struct msghdr));
ret = sock->ops->recvmsg(iocb, sock, msg, total_len, flags);
What I'm trying to understand now is how and when to use sk_buff to do the same thing. I.e. when to use system calls such as what I use above, and when to directly access the network stack via sk_buff to send and receive data.
I've found many examples of how to send and receive data from within transport layers using sk_buff, but nothing from a layer above the transport that is also contained in a kernel module and using sk_buff.
Update for clarification.
I've overridden struct proto_ops and replaced the member methods for my own protocols use which do correspond to system calls from user space. I do understand that sk_buff is the buffer system for the kernel and is where packets are enqueued. However. I don't see any reason why I can't use the protocol-specific functions of struct proto_ops which also handles sockets and the data enqueued on them (though at a higher level). So it seems to me there are two ways to access sk_buffs depending upon where one wants to access them.
If I'm working in the transport layer and want to access data anywheres within the network stack (e.g. transport, ip, mac), I could directly access sk_buffs, but if I am working above the transport layer, I would use the abstracted protocol specific member functions that correspond to system calls. After all, they both eventually work on sk_buffs.
I guess my confusion, or what I'm trying to confirm that I'm doing right or wrong by knowing the difference in these two ways to access sk_buffs and from where, is ... if I'm sending data over a transport from TCP within the kernel, than I can just make use of the proto_ops system calls that relate to TCP unless I need more control in which I would then make use of the lower level skb functions to manage the queues.
Not sure to understand because you want to use to different things for the same purpose. The proto_ops in sock->ops are operations invoked during the correspondent system call. The sk_buff is the socket buffer system of the kernel; it is the place where packet are enqueued.
There is not the possibility to do the same thing of proto_ops with sk_buff, if it should be possible one of these structures is useless.
I'm writing a TFTP server in Ruby and I don't understand a couple things.
First, I read through the entire RFC and I understand the TFTP part of the packet (2 bytes opcode, etc), but I don't know where the TID's go. Also, I've never done anything in Ruby at a byte level. I don't know how to create a variable that's 2 bytes this and then 1 byte that and then whatever.
If someone could show me an example of how to construct a read request packet in ruby, that'd be sweet. Say I'm on the client side and I select port #20000 (for my local TID) and I want to read the file named /Users/pachun/documents/hello.txt on the server which has a TID of 69 right now because it's the first request. How would I construct that packet in Ruby?
Check out this project:
https://github.com/spiceworks/net-tftp
The code there should answer your questions regarding how to construct byte sequences for communicating with tftp protocol.
I have to write a vpn module. First of all, I have wrote a kernel module that modifies all the incoming and outgoing TCP packets. It uses netfilter hooks. For the incoming packets, I have modified the bytes between (struct sk_buff)->data and (struct sk_buff)->tail pointers by incrementing them by one. For the outgoing packets, I have modified the bytes between (struct sk_buff)->data and (struct sk_buff)->tail pointers by decrementing them by one.
However, I tried to establish a TCP connection between localhost and localhost (by means of netcat) and I had not succeeded. Can you tell me what I am doing wrong? Need I modify some other fields from the struct sk_buff structure?
Is it possible to implement my simple vpn module only from kernel space?(thus without using special libraies such as libnetfilter_queue)?
Thank you.
Yes, you can do this without using libnetfilter. But given the limited information that you've provided about your project it's hard to give a good recommendation as to how to go about fixing your issue. Here's some references that should help.
1) I would recommend you take a look at the TUN/TAP interface driver APIs. This will allow you to implement your code in application space rather than kernel. See openvpn for a great example of this type of VPN.
If you're interested in doing more advanced kernel space hooking...
2) Check this article out on hooking into netfilter netfilter kernel hooks