Re: how to correctly distinguish broadcast udp packets vs unicast (socket, pcap or bpf)?
Tnx!
Worked like a charm, with skipped init and other checks, just the
control point parts:
...
int optval=1;
setsockopt(root_socket, IPPROTO_IP, IP_RECVDSTADDR,
optval, sizeof(optval))
...
char t[200];
unsigned int sender_len;
struct msghdr msg;
struct iovec iov;
struct sockaddr_in from;
sender_len = sizeof(from);
msg.msg_name = from;
msg.msg_namelen = sender_len;
msg.msg_iov = iov;
msg.msg_iovlen = 1;
msg.msg_iov-iov_base = u;
msg.msg_iov-iov_len = sizeof(packet_container);
msg.msg_control = t;
msg.msg_controllen = sizeof(t);
msg.msg_flags = 0;
...
result = recvmsg(root_socket,msg,0);
...
struct cmsghdr *cmsg=NULL;
uint32_t* dst_ip=NULL;
for (cmsg = CMSG_FIRSTHDR(msg); cmsg != NULL; cmsg =
CMSG_NXTHDR(msg,cmsg)) {
if (cmsg-cmsg_level == IPPROTO_IP cmsg-cmsg_type
== IP_RECVDSTADDR) {
dst_ip=(uint32_t*)CMSG_DATA(cmsg);
break;
}
}
...
And at that point we have destination ip in dst_ip var:)
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
how to correctly distinguish broadcast udp packets vs unicast (socket, pcap or bpf)?
Good day to all. What is the correct way to distinguish udp packets that obtained by application and were send on 255.255.255.255 ip addr from those that were send to unicast ip? Seems it is impossible with read/recvfrom so we'v made that with libpcap. It coul be done with directly bpf api without pcap wrapper but i'm not sure about how big pcap overhead is. The questions is if we have about 1Gb incoming traffic and using pcap filter for specific port how big is impact of using pcap in such situation? Is it possbile to estimate? Target traffic is about 1Mbit and while testing CPU is about 1-2% but i'm not sure about all the conditions. recfrom recieves all the data without loss in such condition, is it possible that pcap because of its filtering nature(i dont know in details how bpf is realized deep in kernel:( ) will add big overhead while listening? ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: how to correctly distinguish broadcast udp packets vs unicast (socket, pcap or bpf)?
On Jul 4, 2012, at 6:08 PM, Budnev Vladimir wrote: Good day to all. What is the correct way to distinguish udp packets that obtained by application and were send on 255.255.255.255 ip addr from those that were send to unicast ip? Seems it is impossible with read/recvfrom so we'v made that with libpcap. It coul be done with directly bpf api without pcap wrapper but i'm not sure about how big pcap overhead is. The questions is if we have about 1Gb incoming traffic and using pcap filter for specific port how big is impact of using pcap in such situation? Is it possbile to estimate? Target traffic is about 1Mbit and while testing CPU is about 1-2% but i'm not sure about all the conditions. recfrom recieves all the data without loss in such condition, is it possible that pcap because of its filtering nature(i dont know in details how bpf is realized deep in kernel:( ) will add big overhead while listening? ___ freebsd-...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org If I'm understanding your question correctly you can lookup the ip(4) manual page : If the IP_RECVDSTADDR option is enabled on a SOCK_DGRAM socket, the recvmsg call will return the destination IP address for a UDP datagram. The msg_control field in the msghdr structure points to a buffer that contains a cmsghdr structure followed by the IP address. The cmsghdr fields have the following values: You can use this in you application and get the destination address of the packets be it unicast IP or the broadcast address.___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: how to correctly distinguish broadcast udp packets vs unicast (socket, pcap or bpf)?
07/04/12 19:37, Nikolay Denev пишет: On Jul 4, 2012, at 6:08 PM, Budnev Vladimir wrote: Good day to all. What is the correct way to distinguish udp packets that obtained by application and were send on 255.255.255.255 ip addr from those that were send to unicast ip? Seems it is impossible with read/recvfrom so we'v made that with libpcap. It coul be done with directly bpf api without pcap wrapper but i'm not sure about how big pcap overhead is. The questions is if we have about 1Gb incoming traffic and using pcap filter for specific port how big is impact of using pcap in such situation? Is it possbile to estimate? Target traffic is about 1Mbit and while testing CPU is about 1-2% but i'm not sure about all the conditions. recfrom recieves all the data without loss in such condition, is it possible that pcap because of its filtering nature(i dont know in details how bpf is realized deep in kernel:( ) will add big overhead while listening? ___ freebsd-...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org If I'm understanding your question correctly you can lookup the ip(4) manual page : If the IP_RECVDSTADDR option is enabled on a SOCK_DGRAM socket, the recvmsg call will return the destination IP address for a UDP datagram. The msg_control field in the msghdr structure points to a buffer that contains a cmsghdr structure followed by the IP address. The cmsghdr fields have the following values: You can use this in you application and get the destination address of the packets be it unicast IP or the broadcast address. Tnx for fast response! Hm... seems if it will work it will help. I'll test that as soon as possbile! ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
