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).
Related
I am currently working with STM32F103C8T6 and Quectel M66 module. I need to send some command from STM32's UART port for creating a socket connection in M66 and to send some data via that socket to a server in Quectel M66. Is there any way to do that? And I am using FreeRTOS for this.
And what kind of data are possible to send via UART port of STM32?
Any help would be greatly appreciated...Thanks in Advance
There's two ways you can achieve this:
Using AT commands and TCP/IP stack built into the module. In this mode you send AT commands to connect/listen/send/receive/close sockets.
Using PPP and TCP/IP stack inside the microcontroller. In this mode you initially configure the modem using AT commands (which you have to do in both approaches anyway), then you switch the modem to data mode, at which point it starts communicating with you using PPP protocol. You use this to integrate it with the TCP/IP stack in your microcontroller. That way you use all the functionality of the stack you choose (socket API, DNS etc.) and you're not limited to what API quectel provided. You can also take advantage of having multiple network interfaces connected to your microcontroller, for example to perform routing.
How you approach it is totally up to you. If you want just the basic socket functionality, first approach will probably be better for you as it's easier to get it to work. Second approach takes quite a bit more effort but yields better results / more flexible product for the future.
For AT commands documentation check out this link (especially the TCP/IP application note): https://www.quectel.com/product/m66.htm
I'd like to be able to intercept/ modify data in tcp flow, on the side of tcp client. Examples for pcap show how to parse tcp packet header/ payload.
But suppose, i want to modify packet payload before tcp client reads it, or drop the packet entirely. How can i do that with pcap capure?
As above, you can't do interception/modification with pcap. For this you need one of the following OS-dependent techniques:
Linux: libnetfilter_queue + iptables
MacOS, FreeBSD: divert sockets + ipfw
Windows: WinPkFilter (commercial), WinDivert (LGPL), or write your own NDIS IM or WFP call-out driver.
(usual disclosure: WinDivert is my project).
Scapy used in conjunction with python is a very good tool cum library.
You can do all sorts of packet monitoring and editing via command line
Also you can build applications on top of scapy to do a specific task.
Scapy
You can't do that with libpcap or WinPcap; libpcap is built atop OS mechanisms that do not support that (those mechanisms exist to support passive packet capture and low-level packet capture and injection, not to support packet modification in the packet input and output path), and WinPcap's driver is built atop an OS mechanism of that sort.
You would have to find some mechanism, in whatever OS you're using, that supports tapping into the networking stack in a way that allows the tapping program to modify packets as they pass through the networking stack. Such a mechanism might not exist on some OSes; on OSes where it does exist, if there are any, it's probably very OS-dependent. (The mechanisms libpcap uses are also OS-dependent; libpcap exists, in part, to hide those differences from applications, to the maximum extend possible.)
In a nutshell, I am trying to write a C++ XPCOM component which listens on a UDP port and calls a callback function (a javascript function) every time a UDP packet arrives.
Sorry if the answer is too obvious but I was wondering what are the ways to listen on a UDP port with Mozilla (Preferably something easy to do)?
I know that there is an interface called nsIServerSocket which allows some listeners to be attached to it, but this is only for opening TCP ports. Is there any UDP equivalent of this (where I can attach a listener which is notified every time a UDP packet arrives)?
I also know that I could probably use PR_OpenUDPSocket and such. Is there a way of using this without dealing with threads? (As far as I understand I have to return to the calling javascript function after opening the port).
Thanks.
Why do you need to restrict yourself to Mozilla's API if you are writing C++ code? You can use the POSIX socket API directly, see How to set up a Winsock UDP socket? for a WinSock example (the only difference for Linux and OS X should be that WSAStartup() call is unnecessary). nsIServerSocket is mainly useful for JavaScript code that doesn't have the option to use the system libraries directly.
If you prefer a straight answer to your question: no, there is no XPCOM API to create UDP sockets. You already found the NSPR API (PR_OpenUDPSocket()) but it is probably designed with DNS communication in mind since that's pretty much the only UDP communication a browser would do. Don't expect much here.
And a side-note: you might want to avoid binary XPCOM components and create a native library that can be called via js-ctypes instead. See here for the details.
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.
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.