Building DHCP packet ( DHCPDISCOVER ) , packet structure - tcp

I'm trying to build DHCP packet in then send it via UDP ( "0xff.0xff.0xff.0xff", 67 port ).
I have sucessfully connected to my DHCP server, but I have problems with first packet structure ( DHCPDISCOVER ) as I see, but I have built it from RFC && Wiki, and have checked all fields/size in bytes of these fields.
Here is the code in C# ( don't argue , this code is only for testing purpose to check the work of DHCP protocal and structures of packet ): http://pastebin.com/9NXuHyrw
I have initialized the body of discover dhcp-packet in class and you can check the struct of it ( size, right fields ).
So, what's wrong?
Thanks,
Best Regards

Using a BinaryFormatter will not give you what you are expecting. It will produce a sequence of bytes in an unspecified format. The only guarantee you have about that sequence of bytes is that you can deserialize it into an object that resembles the original. It is highly likely it doesn't look at all like a DHCP packet.
To get an array of bytes with the correct packet structure you will have to use a BinaryWriter over a MemoryStream and write each field manually.

Related

does dev_queue_xmit depends on dst_entry in skb

I am working on a network module and need to send out packet to specific destinations (think as software router).
I want to send a sk_buff to some IP address, passing it to dev_queue_xmit().
However, I am feeling complex with dst_entry concept.
Can dev_queue_xmit send a skb, without a valid dst_entry, when the skb has necessary link layer info ?
After some testing, I eventually concluded that skb need not have a valid dst_entry for successfully transmitting a packet. All that it needs is a valid buffer, with skb->data pointing to correct mac_header location.

How to monitor a network program in the linux ? What aspects need to consider and monitor?

I develop a network program that is used to transfer files , it works . But I just know it can works , and I don't know how to monitor and evaluate it . So I want to know what aspects a network program usually need to consider and monitor and how to monitor .
First make sure which protocol you have been used to send files (either TCP or UDP).
1.If you are using TCP at transport layer ,at the receiving end you can use TCPDUMP
packet analyzer to analyze all packets receiving on TCP port and its content.
2.If you want to analyze packets irrespective of protocols used at different layers, you can use wireshark packet analyzer to analyze all packets received on different networks like ethernet,PPP, loop back ,frame relay. you can use IP address of sender host as a reference to extract packets ( you need some reference to extract packets because wire shark will return all the packets received on the NIC interface). Once you extract the packets received from your sender host, you can analyze the packet payload to check whether files content has been received properly or not.
3.you can redirect data ( payload) of all received packets into some file. Once your program is done with receiving packets, you can check with that file to check data has been properly received or not. ( you can use this method only to test your client/server programs within a system)

Command to transmit Data over wlan

I am doing some experiment for which I need to collect Data from wlan driver.
I am interested in transmitting IEEE 802.11b Packets with more flexibility in terms of Data Rate, Packet Size etc.
Basically, I will have the laptop as the transmitter and I have built a custom receiver for IEEE 802.11b which would read the packets ( IEEE 802.11b 1/2/5.5 or 11Mbps) .
So, I am looking at some Linux tool which gives the option of setting these parameters while transmitting data.
I am thinking at commands like iwpriv to set the parameters for the wireless driver, and iperf commands to generate Traffic.
I am not sure, how to use them to achieve a Data traffic, say 1Mbps / and 1024 Bytes PSDU (Packet Size).
The receiver is a dedicated hardware ( not a Computer). Any suggestion or idea in this direction would be helpful.
Thanks
Use wireshark or pcap (via perl,python etc) to capture what you want.
You may be better off asking this on Server Fault. I found a couple of packet generators that look like they could do what you need but I'm by no means an expert.
packETH:
you can create and send any ethernet packet [...]
sending sequence of packets
delay between packets, number of packets to send
sending with max speed, approaching the teoretical boundary
change parameters while sending (change IP & mac address, UDP payload, 2 user defined bytes, etc.)
Ostantino:
Modify any field of any protocol (some protocols allow changing packet fields with every packet at run time e.g. changing IP/MAC addresses)
[...]
Configure stream rates, bursts, no. of packets
I found these in the Wireshare Wiki where there are a number of other tools that may help.

TCP Null Scan using Scapy

Can someone guide me on how to send packets in Scapy to an ip address, with all flags in the TCP header set to null ? I have so far tried sending packets without specifying which flags to set, but it seems to set the Syn flag everytime I send the packet.
I would like to know it so that I can learn more about TCP Null Scans. Would be grateful for ur help and guidance.
I haven't used Scapy, but from a quick scan of the documentation there is an example of creating a TCP packet while specifying which flags to set, on this page of the docs:
http://www.secdev.org/projects/scapy/doc/usage.html#simple-one-liners
sr( IP(dst="192.168.1.*")/TCP(dport=80,flags="S") )
Perhaps you could try a command like that, with an empty string ""? i.e. TCP(dport=80,flags="") ?
If you don't want to actually send a TCP header, you'd be better off just setting the protocol of the IP packet and gluing a string of zeros on top of it.
sr( IP(dst="192.168.1.", proto="TCP")/"\0"*50)
Edit: I'm not actually positive on the syntax, you might have to use the protocol number instead of "TCP"
Thank you Andy and Jdizzle for the suggestions.
I tried out what Andy Recommended earlier itself, but the packet somehow seemed to have the Syn Flag set, when i checked it on wireshark.
The good news is, i solved the problem, the flags can be set to null, at the instance when you create the packet to be sent.
create a packet --> a=TCP() and then setting the flag to zero by --> a.flags=0
there are many other attributes that you can preset in this manner before preparing the packet to be sent over the network. You can view these attributes by --> ls(a)
where a=the name of the packet.
This worked successfully !

How to tell which interface the socket received the message from?

If a socket is bound to IN6ADDR_ANY or INADDR_ANY and you use a call such as recvfrom() to receive messages on the socket. Is there a way to find out which interface the message came from?
In the case of IPv6 link-scope messages, I was hoping that the from argument of recvfrom() would have the scope_id field initialized to the interface Id. Unfortunately it is set to 0 in my test program.
Anybody know of a way to find out this information?
dwc is right, IPV6_PKTINFO will work for IPv6 on Linux.
Moreover, IP_PKTINFO will work for IPv4 — you can see details in manpage ip(7)
I've constructed an example that extracts the source, destination and interface addresses. For brevity, no error checking is provided. See this duplicate: Get destination address of a received UDP packet.
// sock is bound AF_INET socket, usually SOCK_DGRAM
// include struct in_pktinfo in the message "ancilliary" control data
setsockopt(sock, IPPROTO_IP, IP_PKTINFO, &opt, sizeof(opt));
// the control data is dumped here
char cmbuf[0x100];
// the remote/source sockaddr is put here
struct sockaddr_in peeraddr;
// if you want access to the data you need to init the msg_iovec fields
struct msghdr mh = {
.msg_name = &peeraddr,
.msg_namelen = sizeof(peeraddr),
.msg_control = cmbuf,
.msg_controllen = sizeof(cmbuf),
};
recvmsg(sock, &mh, 0);
for ( // iterate through all the control headers
struct cmsghdr *cmsg = CMSG_FIRSTHDR(&mh);
cmsg != NULL;
cmsg = CMSG_NXTHDR(&mh, cmsg))
{
// ignore the control headers that don't match what we want
if (cmsg->cmsg_level != IPPROTO_IP ||
cmsg->cmsg_type != IP_PKTINFO)
{
continue;
}
struct in_pktinfo *pi = CMSG_DATA(cmsg);
// at this point, peeraddr is the source sockaddr
// pi->ipi_spec_dst is the destination in_addr
// pi->ipi_addr is the receiving interface in_addr
}
Apart from binding to each interface, I'm not aware of a way with IPv4, per se.
IPv6 has added the IPV6_PKTINFO socket option to address this shortcoming. With that option in effect, a struct in6_pktinfo will be returned as ancillary data.
Its been a while since I've been doing C/C++ TCP/IP coding but as far as I remember on every message (or derived socket) you can get into the IP headers information. These headers should include the receiving address which will be the IP of the interface you are asking about.
Outside of opening a separate socket on each interface as Glomek suggested, the only way I know to do this definitively on Windows is to use a raw socket, e.g.,
SOCKET s = socket(AF_INET, SOCK_RAW, IPPROTO_IP);
Each receive from this socket will be an IP packet, which contains both the source and destination addresses. The program I work on requires me to put the socket in promiscuous mode using the SIO_RCVALL option. Doing this means I get every IP packet the interface "sees" on the network. To extract packets expressly for my application requires me to filter the data using the addresses and ports in the IP and TCP/UDP headers. Obviously, that's probably more overhead than you're interested in. I only mention it to say this - I've never used a raw socket without putting it in promiscuous mode. So I'm not sure if you can bind it to INADDR_ANY and just use it as a regular socket from that point forward or not. It would seem to me that you can; I've just never tried it.
EDIT: Read this article for limitations regarding raw sockets on Windows. This biggest hurdle I faced on my project was that one has to be a member of the Administrators group to open a raw socket on Windows 2000 and later.

Resources