Can I send non-IP packets using Winsock? - sockets

I'm trying to create a small PPPoE Access Concentrator to learn the inner workings of PPPoE.
This requires me to send non-IP packets, I need to be able to set the ETHER_TYPE and eventualy the destination mac fields in the ethernet frame header, but as far as I can tell, raw WinSock sockets give me the ability to supply my own IP header, but not the ethernet header.
Is this true? And if so, is there any way of circumventing this?
I am well aware of WinPcap, and will use it ONLY as a last resort.

I believe that you are correct. Winsock will allow a raw IP socket but does not allow you to get beneath layer 3 and send non-IP packets. For this I believe you would need to pursue the WinPcap / TDI option . More information.

Related

Modify TCP/IP packets live

I wish to be able to be able to make a small modification to all the packets that are being sent from my computer - specifically, TCP packets (though just IP would also be fine, as I'll do the parsing myself).
I've tried looking for existing tools but couldn't find any that would allow me to modify the packets in real-time.
I've thought that a tool that would allow me to create a "fake" adapter so i'll be able to connect to it and it will act as a transparent proxy, but couldn't find any tool that might work for me and allow me to actually change the packets live.
Thanks in advance!

SO_BINDTODEVICE option support for FreeBSD

I am implemneting a code based on Raw sockets. In order to receive coming Ethernet frames I have to bind the socket I created to an Ethernet interface. The only way to do that, as far as I am concerned, is via setsockopt() function with the option SO_BINDTODEVICE.
The problem is that I am using FreeBSD which does not support such option. Is there any patch to use in order to enable this feature or any other trusted alternative?
You can use sendto if you are working with IPv6, see this example.
Unfortunately this doesn't work with IPv4.
As antiduh said, you can use libpcap to capture packets, provided you have access to /dev/bpf (which is usually restricted to root).

Is it possible filtering (dropping) packets with Winpcap?

I want to filter (drop) incoming and outgoing packets with Winpcap library.
Is it possible filtering packets with Winpcap?
EDIT: You seem to mean that you want to block incoming or outgoing packets from the hosts's TCP/IP stack using WinPcap. That it cannot do;
WinPcap receives and sends the packets independently from the host protocols, like TCP-IP. This means that it isn't able to block, filter or manipulate the traffic generated by other programs on the same machine: it simply "sniffs" the packets that transit on the wire. Therefore, it does not provide the appropriate support for applications like traffic shapers, QoS schedulers and personal firewalls.
When it comes to just filtering which traffic you want to capture/listen to, then yes, the tutorial has a page on that.

Sockets VS WinPcap

Does anyone know why should I use Winpcap and not just .Net sockets to sniff packets on my local pc?
TY
Sockets (.NET, Winsock, etc.) normally collect at layer 7, the Application layer. That is, whatever is sent by the sender is what is received by the receiver. All of the various headers that are added automatically on the sending side are stripped off by the time the receiver reads the data from the socket.
It is possible to configure a socket to be a raw socket, in which case, you can see all of the headers down to layer 3, the Network layer. Further still, you can put the raw socket in promiscuous mode, which allows you to see all of the traffic on the network, not just the packets destined for your machine. But even this is limited. For example, when you configure the raw socket, you specify the protocol type to use, e.g., IP, ICMP, etc. This limits the socket to "seeing" packets that adhere to that protocol. I have been unable to figure out how to make the socket see all packets at layer 3 regardless of protocol.
Winpcap operates as a device driver at layer 2, the Data Link layer. In this case, you see literally all of the packets on the network with full headers down to layer 2. Winpcap also offers filtering capability so you can narrow down the packets that are reported to you based on whatever criteria you provide.
As far as choosing between them, it really boils down to the requirements of your specific task. If you are trying to implement any kind of realistic network analysis capability, you'll be hardpressed to do that with just sockets. Winpcap makes more sense in that case. However, if you are only interested in IP packets, for example, then sockets will work fine for that.
As far as I understanf .Net sockets are an IPC to communicate between 2 processes. While winpcap is a library that help you to access the data link layer an sniff pacquets going through your network hardware (or virtual) devices on your machine. Data link layer allow to get the data on any socket (.Net or not) created on your system.

How i can access original data from the ethernet?

I wanted to access the original value from the ethernet, actully by some hardware programming i am sending a value to system via ethernet ,but it's not possible to access what exactly i'm going to send
You could use a packet sniffer like Wireshark, running on either source or destination system. This will let you examine packets as they leave or enter, respectively.
It sounds like what you need is a protocol analyzer. On Windows, look at Microsoft's Network Monitor.