3

I'm working with a switch. Packets come into the kernel via a special gigabit port where each packet is preceded by a header that tells you what switch port the packet originally came in on.

I'm working on a protocol that requires me to know the port in order to respond to a packet--you can imagine power allocation, OAM, 802.1X, etc all have this issue.

I store the switch port number in the sk_buff in a new field. No problem.

But in user space I'm receiving the packets using recvfrom and don't have access to the sk_buff. I have access to the sll_ifindex so I can tell what interface, even VLAN, the packet came in on (say eth0.2), but since all packets come in the special gigabit port this isn't what I need. I need the original port.

Is there some way to trace back from the sockaddr to the sk_buff? Since the packet is being copied along the way, I lose access to the bytes in front of it. And at least right now I don't have access to the skbuff either. I could come up with something flaky like maintaining a separate queue of this info and communicating that thru a separate channel or something but that seems problematic.

Ideas?

fanfoot
  • 31
  • 1
  • Can you get to the header by using a `socket()` with `SOCK_RAW`? – EOF Sep 16 '15 at 22:18
  • Not that I'm aware of. – fanfoot Sep 17 '15 at 23:35
  • In the end I abandoned this and used a different approach. Since the packet has already updated the MAC address table, looking up the MAC address in the table gives me the port it *must* have come in on. – fanfoot Sep 23 '15 at 18:32

0 Answers0