You are not logged in.
Pages: 1
I am Trying to send VLAN Information to application using the socket of attributes (PF_PACKET, SOCK_RAW, htons(ETH_P_IP)). when I am sending a VLAN Tagged Packet from another Machine ; My application is receiving (using recvfrom function) only 342 bytes (Excluding the VLAN Header) instead the original 346 bytes (including VLAN Header). Kernel is removing the VLAN information of 4 bytes. How can I get the VLAN information to uspace application without using the libpcap library? Any Suggestions are really helpful at this point of time. Thanks in Advance !!!
Offline
I think you should take a step back and think about what you're actually trying to achieve.
What is your goal?
If you just want to tell what VLAN is being used, for whatever reason, why not send a
normal UDP packet saying just that?
VLANs show up as virtual interfaces in the OS, so if you just want to know how to
communicate over a certain VLAN, just figure out which interface it is. If you
receive a packet, just check out from what interface it came, or, alternatively,
have a separate listening socket on each (VLAN) interface.
I thought the whole point of VLAN was to be transparent to upper layers, so
trying to get directly at it from a socket level seems exactly the wrong thing
to do.
Edit: If the VLAN is configured on a switch, your host may not even get any VLAN
info at all anyway. Many switches can configure the VLAN per port.
Offline
@i3839/RobSeace:
Goal was to give IPAddress to Clients based on their VLAN-ID. I am trying to write a Customized DHCP Server using RAW Sockets listening to all IPPROTO_UDP Packets. That's how I am receiving the DHCP-DISCOVER Packets (UDP). But once after parsing the packet at uspace; the Main deciding Factor - VLANID was not there. Entire 4 bytes are missing at application level. To explain more about topology; all vlan associated packets (DISCOVER) are expected to arrive on only one Single Physical Interface.
Why getting the VLAN-ID to upper layers was a Wrong thing ?? There are cases where at Application Layer ; we need the MAC Address of the Peer Machine. (Ex: DHCP OFFER Packet is to be filled with the MAC Address of the Client Machine who sent the DISCOVER Packet.In this Case; Mac-Address being a Layer-2 Literature is still needed at Application Layer). I strongly believe ; there is no wrong at the upper layers (specifically Application Layer) showing interest in Lower Layers information. That too when the Application was designed using RAW Sockets. ETH_P_IP/ETH_P_ALL doesn't make much difference in this case. Becoz; I am interested in UDP packets which anyway using the IP at Network Layer in my Network. If there is a Confirmation that ; we can NOT do with Normal RAW Sockets then only I want to go for Third Party Library (libpcap).
Please let me know if my understanding went wrong anywhere !!
Offline
I tried with both ETH_P_IP & ETH_P_ALL. In both the cases;I am seeing only 342 bytes at application's recvfrom function.when I print all the bytes it is clear that 4 bytes related to vlan are missing. Coming to ETH_P_8021Q; Application is NOT able to get even a single byte surprisingly. By the way; just want to remind U that incoming vlan tagged packets are Broadcast in Nature & My Application is not binded to any IP/Device.It's a simple combo of PF_PACKET & SOCK_RAW.Running out of ideas as well as options !!! Any More suggestions plz ??
Offline
Well, then, if ETH_P_ALL can't see it, then I think you'll find that libpcap can't see it, either... And, that presumably means it's simply not there to see at all... *shrug*
Offline
JFYI & what I have Finally done for my Issue ?
After started using the libpcap ; things became very easy. Not sure what they are doing internally; Can see all the Complete 346 bytes at application with out 4 bytes getting stripped. Thnx God !!
Offline
It wouldn't surprise me if you can only get the VLAN tag if you bind to a specific interface.
So perhaps that's what libpcap does and your code doesn't. You can see what libpcap does
with Strace.
Offline
Or, you could just read the damn code to see what it's doing! ;-)
Yes, it does bind to a device, if you give a specific one... That may indeed be what's needed... *shrug*
But, yeah, I see no reason not to just use libpcap, anyway... Then, you also have easy access to BPF filtering with a relatively easy to use syntax, rather than fighting to directly use the kernel packet filtering system, too...
Offline
I agree using libpcap is pretty easy than fighting with Kernel when it is First time. Now another query !! While sending the reply back; was it better to use (packet_inject/packet_sendto) of libpcap library ORR going for some Socket (RAW) was best Option ?? I need again fill the link layer (Ethernet) Header also with VLAN ID :) !!
Offline
Reading the libpcap, the reason seems that the vlan tags are stored externally the packet buffer in recent Linux, which have PACKET_AUXDATA in linux/if_packet.h. In this case, SOCK_RAW is not really raw on the wire, but raw on the socket buffer. To get the packet with vlan header, we must reassemble.
You will definitely get vlan tagged frames from the RAW socket. For that we need to create a vlan interface(eg eth0.50) and associated it the the physical port and bind the raw socket to the vlan interface (eth0.50 )and not to the physical port(eg eth0).
eg code.. interface = eth0.50
..
..
s = socket(PF_PACKET, SOCK_RAW, htons(ETH_P_ALL));
if (s < 0) {
printf("socket failed: %m");
return -1;
}
soc = s;
if (setsockopt(s, SOL_SOCKET, SO_ATTACH_FILTER, &prog, sizeof(prog)) < 0)
printf("setsockopt packet filter failed: %m");
printf("setsockopt packet filter");
memset(&ifr, 0, sizeof(ifr));
strcpy(ifr.ifr_name, interface);
if (ioctl(soc, SIOCGIFINDEX, &ifr) < 0) {
printf("EthRawSockStart(): ioctl() SIOCGIFINDEX failed! error: %d (NIC: %s)",errno,ifr.ifr_name);
return ;
}
/* Bind to eth0.50 interface only - this is a private VLAN */
if (( setsockopt(s, SOL_SOCKET, SO_BINDTODEVICE, (void *)&ifr, sizeof(ifr))) < 0)
{
perror("Server-setsockopt() error for SO_BINDTODEVICE");
printf("%s\n", strerror(errno));
close(s);
exit(-1);
}
printf("\n Bind to eth0.... \n");
...
I would like to add
1. If you want to get the vlan tagged frames only then you should bind the raw socket to the vlan interface.
2. if you want to get the all the frames with vlan tag, which the physical interface is a member of the you raw socket should bind to the physical interface (eg eth0). In this case you will be able to see the 4 bye vlan info in the frames received.
I have a RAW socket bound to the virtual interface (Eg: eth0.50). When VLAN tagged frames are sent on this interface, I get two identical frames. Its the exact same payload, when I used tcpdump I found one normal frame was received on eth0.50 and one VLAN tagged frame was received on eth0. How can I eliminate the duplicate frame ?
Pages: 1