I want to implement pbft algorithm(3f+1 systems;f=1) in python. But what is the channel should use for sending and receiving from replicas. I have tried python multicast but it seems something going wrong while receiving. So please suggest any solution that can put me forward.
Thanks in Advance.
You need to use authenticated point-to-point communication channel to implement any sorts of BFT algorithm. Because PBFT assumes all participant's identity are established in prior, you don't need to assume multicast communication primitive. Even though broadcast is executed in PBFT protocol, each message is encrypted by its private key. So you don't need to use multicast or broadcast.
Related
Ok, I realize this situation is somewhat unusual, but I need to establish a TCP connection (the 3-way handshake) using only raw sockets (in C, in linux) -- i.e. I need to construct the IP headers and TCP headers myself. I'm writing a server (so I have to first respond to the incoming SYN packet), and for whatever reason I can't seem to get it right. Yes, I realize that a SOCK_STREAM will handle this for me, but for reasons I don't want to go into that isn't an option.
The tutorials I've found online on using raw sockets all describe how to build a SYN flooder, but this is somewhat easier than actually establishing a TCP connection, since you don't have to construct a response based on the original packet. I've gotten the SYN flooder examples working, and I can read the incoming SYN packet just fine from the raw socket, but I'm still having trouble creating a valid SYN/ACK response to an incoming SYN from the client.
So, does anyone know a good tutorial on using raw sockets that goes beyond creating a SYN flooder, or does anyone have some code that could do this (using SOCK_RAW, and not SOCK_STREAM)? I would be very grateful.
MarkR is absolutely right -- the problem is that the kernel is sending reset packets in response to the initial packet because it thinks the port is closed. The kernel is beating me to the response and the connection dies. I was using tcpdump to monitor the connection already -- I should have been more observant and noticed that there were TWO replies one of which was a reset that was screwing things up, as well as the response my program created. D'OH!
The solution that seems to work best is to use an iptables rule, as suggested by MarkR, to block the outbound packets. However, there's an easier way to do it than using the mark option, as suggested. I just match whether the reset TCP flag is set. During the course of a normal connection this is unlikely to be needed, and it doesn't really matter to my application if I block all outbound reset packets from the port being used. This effectively blocks the kernel's unwanted response, but not my own packets. If the port my program is listening on is 9999 then the iptables rule looks like this:
iptables -t filter -I OUTPUT -p tcp --sport 9999 --tcp-flags RST RST -j DROP
You want to implement part of a TCP stack in userspace... this is ok, some other apps do this.
One problem you will come across is that the kernel will be sending out (generally negative, unhelpful) replies to incoming packets. This is going to screw up any communication you attempt to initiate.
One way to avoid this is to use an IP address and interface that the kernel does not have its own IP stack using- which is fine but you will need to deal with link-layer stuff (specifically, arp) yourself. That would require a socket lower than IPPROTO_IP, SOCK_RAW - you need a packet socket (I think).
It may also be possible to block the kernel's responses using an iptables rule- but I rather suspect that the rules will apply to your own packets as well somehow, unless you can manage to get them treated differently (perhaps applying a netfilter "mark" to your own packets?)
Read the man pages
socket(7)
ip(7)
packet(7)
Which explain about various options and ioctls which apply to types of sockets.
Of course you'll need a tool like Wireshark to inspect what's going on. You will need several machines to test this, I recommend using vmware (or similar) to reduce the amount of hardware required.
Sorry I can't recommend a specific tutorial.
Good luck.
I realise that this is an old thread, but here's a tutorial that goes beyond the normal SYN flooders: http://www.enderunix.org/docs/en/rawipspoof/
Hope it might be of help to someone.
I can't help you out on any tutorials.
But I can give you some advice on the tools that you could use to assist in debugging.
First off, as bmdhacks has suggested, get yourself a copy of wireshark (or tcpdump - but wireshark is easier to use). Capture a good handshake. Make sure that you save this.
Capture one of your handshakes that fails. Wireshark has quite good packet parsing and error checking, so if there's a straightforward error it will probably tell you.
Next, get yourself a copy of tcpreplay. This should also include a tool called "tcprewrite".
tcprewrite will allow you to split your previously saved capture files into two - one for each side of the handshake.
You can then use tcpreplay to play back one side of the handshake so you have a consistent set of packets to play with.
Then you use wireshark (again) to check your responses.
I don't have a tutorial, but I recently used Wireshark to good effect to debug some raw sockets programming I was doing. If you capture the packets you're sending, wireshark will do a good job of showing you if they're malformed or not. It's useful for comparing to a normal connection too.
There are structures for IP and TCP headers declared in netinet/ip.h & netinet/tcp.h respectively. You may want to look at the other headers in this directory for extra macros & stuff that may be of use.
You send a packet with the SYN flag set and a random sequence number (x). You should receive a SYN+ACK from the other side. This packet will have an acknowledgement number (y) that indicates the next sequence number the other side is expecting to receive as well as another sequence number (z). You send back an ACK packet that has sequence number x+1 and ack number z+1 to complete the connection.
You also need to make sure you calculate appropriate TCP/IP checksums & fill out the remainder of the header for the packets you send. Also, don't forget about things like host & network byte order.
TCP is defined in RFC 793, available here: http://www.faqs.org/rfcs/rfc793.html
Depending on what you're trying to do it may be easier to get existing software to handle the TCP handshaking for you.
One open source IP stack is lwIP (http://savannah.nongnu.org/projects/lwip/) which provides a full tcp/ip stack. It is very possible to get it running in user mode using either SOCK_RAW or pcap.
if you are using raw sockets, if you send using different source mac address to the actual one, linux will ignore the response packet and not send an rst.
I'm planning to design a server that receives data from multiple clients, the server don't need to send anything back to the client, though STATUS_OK is still cool but not necessary.
I know the basics of Python socket module, twisted framework but my question is, should i use UDP or TCP? The client that need to stay connected at all.
I hope you guys understand my question, thank you for your wonderful help here
You should always use TCP until you have a performance problem that you know can be mitigated with UDP. TCP is easier to understand when it fails.
Can you afford to lose messages? If yes, use UDP. Otherwise use TCP. It's what they're designed for.
I would use TCP in your situation, but it's hard to tell what the specifics of your needs are. TCP is in most cases a better protocol because it's much more reliable. Data is very rarely lost in TCP, however this does slow it down a bit. Since you're not sending anything back to the client, the fact that TCP is a streaming protocol shouldn't really matter too much.
So I'd just go with TCP.
For how long will one client be connected to the server? How many concurrent connections are you planning to handle? If there will be very short bursts of data for a lot of clients, then you should go with UDP. But chances are, TCP will do just fine initially.
I want to figure out whether my computer is somehow causing a UDP flood that is originating from my network. So that's my underlying problem, and what follows is simply my non-network-person attempt to hypothesize a solution using python. I'm extrapolating from recipe 13.1 ("Passing Messages with Socket Datagrams") from the python cookbook (also here).
Would it possible/sensible/not insane to try somehow writing an outgoing UDP proxy in python, so that outgoing packets could be logged before being sent on their merry way? If so, how would one go about it? Based on my quick research, perhaps I could start a server process listening on suspect UDP ports and log anything that gets sent, then forward it on, such as:
import socket
s =socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
s.bind(("", MYPORT))
while True:
packet = dict(zip('data', 'addr'), s.recvfrom(1,024))
log.info("Recieved {data} from {addr}.".format(**packet))
But what about doing this for a large number of ports simultaneously? Impractical? Are there drawbacks or other reasons not to bother with this? Is there a better way to solve this problem (please be gentle).
It might be easier just to install Wireshark, instead of rolling your own in Python.
Sometimes I have to send a message to a specific IP and sometimes I have to broadcast the message to all the IP's in my network. At the other end I have to distinguish between a broadcast and a normal one, but recvfrom() just returns the address the message came from;
there is no difference between them. Can anyone help me distinguish them?
UDP is the protocol.
I don't think it's possible with Python's socket module. UDP is a very minimalistic protocol, and the only way to distinguish between a broadcast and a non-broadcast UDP packet is by looking at the destination address. However, you cannot inspect that part of the packet with the BSD socket API (if I remember it correctly), and the socket module exposes the BSD socket API only. Your best bet would probably be to use the first byte of the message to denote whether it is a broadcast or a unicast message.
I browsed the python socket docs and google for two days but I did not find any answer. Yeah I am a network programming newbie :)
I would like to implement some LAN chatting system with specific function for our needs. I am at the very beginning. I was able to implement a client-server model where the client connects to the server (socket.SOCK_STREAM) and they are able to change messages. I want to step forward. I want the client to discover the LAN with a broadcast how many other clients are available.
I failed. Is it possible that a socket.SOCK_STREAM type socket could not be used for this task?
If so, what are my opportunities? using udp packets? How I have to listen for brodcast messages/packets?
The broadcast is defined by the destination address.
For example if your own ip is 192.168.1.2, the broadcast address would be 192.168.1.255 (in most cases)
It is not related directly to python and will probably not be in its documentation. You are searching for network "general" knowledge, to a level much higher than sockets programming
*EDIT
Yes you are right, you cannot use SOCK_STREAM. SOCK_STREAM defines TCP communication. You should use UDP for broadcasting with socket.SOCK_DGRAM