I have linux kernel 3.14.28. i enabled multicasting to that kernel(config_ip_multicast=y,config_ip_router=y,config_ip_mroute=y, config_ip_ipip=y). finally my new kernel was build successfully and the kernel was UP. now how can i check multicasting on my imx6Q wandboard.
thanks for your comments
The question is not clear enough.
I'll try my best any way.
Sending multicast messages is used by the usual UTP datagram API just to a certain range of IP's.
For receiving multicast, you need to join a multicast group using IGMP join message and wait on the socket.
BTW -
The kernel doesn't handle multicast routing on it's own. a user space daemon must support it. check for mrouted, pimd or smcroute.
Related
I have two programs.
Program 1. This program creates one socket per network interface, sets the default multicast interface ID for this socket and bind it to the "interface_addr:some_port". Program listens its sockets and process received data.
Program 1 was tested and it receives multicasts from network devices.
Program 2. This program creates one socket per network interface and sends multicast requests and process replies.
Program 2 was tested - it receives replies for multicast requests from network devices.
The problem is that when both programs runned on the one host program 1 not see requests from program 2, but Wireshark shows the packets from program 2.
OS: Windows 7.
What I'm doing wrong?
You don't need multiple sockets. Bind a single socket to INADDR_ANY, and join the group via each interface in turn.
The problem was solved. There is only need to turn on option MULTICAST_LOOP both on the client and server
I'm writing an IPsec implementation for a microcontroller and I want to test it using a standard Linux box running Debian Lenny. Both devices should secure the communication between them using IPsec ESP in tunnel mode. The keys are setup manually using setkey. There's no (or at least should be no) user space program involved in processing an IPsec packet. Now I want to see how my created packets are processed by the Linux kernel. To see the raw packets I capture them using tcpdump and analyze them using wireshark.
What's the best way to obtain debug information about IPsec processing?
How can I figure out whether the packet is accepted by the kernel?
How can I view the reason for a packet to be dropped?
You can instrument the XFRM (or perhaps ipv4/esp.c) kernel code to print out debug messages at the right spots.
For example, in net/ipv4/esp.c there exists a function esp_input() which has some error cases, but you'll see most the interesting stuff is in the xfrm/*.c code.
That said, I didn't have a problem interoperating a custom IPSec with Linux. Following the 43xx specs and verifying the packets came out correctly via wireshark seemed to do well. If you're having issues and don't want to instrument the kernel then you can setup iptables rules and count the number of (various type of) packets at each point.
Finally, be sure you've actually added a security policy (SP) as well as a security association (SA) and setup firewall rules properly.
I am trying to write an application that listens to a number of multicast groups using Windows sockets.
The problem I'm running in to is that when I go to bind the socket, if I try to bind to the multicast group address and port this fails with WSAEADDRNOTAVAIL. If I instead bind to INADDR_ANY and the port, then I can still receive other unrelated traffic destined for the same port.
When I implemented the same thing in Linux, I didn't have any issues binding to the multicast address (in fact, I saw it recommended several places to avoid getting unrelated traffic for the port).
Is this just not available with Windows sockets? I assume I could filter traffic myself by using WSARecvFrom and peeking at the headers, but I'd rather a simple solution if one exists.
Also, this is running on Windows Server 2008.
While the doc for bind() does not say that this unsupported, it does say in the remarks:
For multicast operations, the
preferred method is to call the bind
function to associate a socket with a
local IP address and then join the
multicast group....
Maybe this scheme will yield better results?
I'm writing a network application in ruby which should use UDP multicasting.
My problem is that I want to run multiple instances for testing purposes on localhost, but multicasting only works if I bind the socket to the real network interface.
Is there some way to enable multicasting for the loopback interface, so that all the 127.0.0.x get the message I send?
Currently I enable multicasting with:
ip = IPAddr.new('234.56.78.9').hton + IPAddr.new('0.0.0.0').hton
socket.setsockopt(Socket::IPPROTO_IP, Socket::IP_ADD_MEMBERSHIP,ip)
#socket.bind '127.0.0.1',1234 ##does not receive multicast :(
socket.bind '0.0.0.0',1234
Also, I noticed that if I e.g. bind the socket to 127.0.0.4 and send a message, in the packet the source ip is 127.0.0.1 anyway... is there a way to set the source IP so it shows the same IP I bound the socket to?
Solaris allows you to use multicast on the loopback device. For other operating systems you can enable IP_MULTICAST_LOOP on the sender (Unix) or the receiver (Windows) for similar effect.
i have rule set up to drop udp/tcp packets with matching strings. however, my program which captures packet using libpcap, is still able to see this packet.
Why is this/, what should be the iptable rules to drop packets before it is seen by libpcap?
Is there anyway,perhaps other than iptables rules, to drop this packet before it is seen by libpcap/tcpdump?
Yes, libpcap sees all the packets..
They are being captured before being processed by the netfilter.
Did you try to change the priority of the netfilter hook you use? if you try hooking with the highest priority for incoming packets, it will get the packet before the packet socket kernel code, which is the way libpcap uses to capture packets.
* I assume you are using linux *
EDIT:
Libpcap uses different ways to capture packets - according to the OS. on linux it uses packet socket which is implemented in kernel code using the netfilter framework.
Theres no way for libpcap to see the packets before netfilter, netfilter is a kernel module, and processes all packets before they hit user mode, it can even see the packets before the kernel sees it.
Could you explain further explain ?
Its possible that libpcap is also setting hooks on netfilter that overwrite the one in iptables. The real issue is that looking and what hooks are set on netfilter is far from trivial, and can only be done in kernel mode. Investigate how libpcap gets the packets.