> It doesn't seem unreasonable to be able to snoop a specific
> protocol in both directions rather than snooping everything
> and having to filter it in the application. Is there some
> standard we are following here?
The reason not to make it is efficiency.
dev_queue_xmit_nit sits in fast path, and it is protected
by netdev_nit counter. (BTW it was bug in your patch:
if you did it, you should increment netdev_nit count in dev_add_pack())
When you bind a socket to ETH_P_ALL,
you sign sort of contract, that you agreed to lose these ticks in fast path 8)
Sure, you are right, such facility must exist,
especially taking into account that BPF does not look
at skb->protocol. New sockopt?
> Unfortunately with the snoop bound to ETH_P_ALL nothing seems
> to go out of the real interface while with the snoop bound to
> ETH_P_IP it works. There is some wierd interaction going on
> here somewhere (I've sent Alexey some traces that I find dubious).
Set protocol field in sll->sll_protocol in sendto() to
htons(ETH_P_IP).
> Something else is that diald really wants to know whether
> a packet is being received or transmitted on the interface,
> regardless of whether it orginated locally or is being forwarded
> for someone else.
sll->sll_pkttype is PACKET_OUTGOING for transmitted packets
and it is PACKET_{HOST,BROADCAST,MULTICAST} for received
frames.
> Taken with the above it sounds as though we
> could have some socket options on packet sockets which would
> allow processing of received/transmitted packets to be enabled
> and disabled. These could default to the current behaviour
> unless changed with setsockopt. Is that at all reasonable?
Yes, it is very good idea. Have you some idea on name for
this sockopt? 8)8)
Alexey
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html