The manpage packet(7) currently states that:
"When you send packets it is enough to specify sll_family, sll_addr,
sll_halen, sll_ifindex."
This is incorrect: you also need to specify sll_protocol.
(The protocol specified when the socket is created is used for
filtering inbound packets, but not for constructing outbound
packets.)
I encountered this while researching a page for my website:
http://www.microhowto.info/howto/send_an_arbitrary_ethernet_frame_using_an_af_packet_socket_in_c.html
To empirically verify the behaviour I took my test code from the
above page then changed it to use different values for the third
argument to socket() and the sll_protocol field:
- socket created with ETH_P_ARP, packet sent with ETH_P_ARP:
packet sent with EtherType of ETH_P_ARP
- socket created with ETH_P_ARP, sll_protocol==0:
packet sent with EtherType of 0
- socket created with 0x88b5, sll_protocol==htons(ETH_P_ARP):
packet sent with EtherType of ETH_P_ARP
- socket created with ETH_P_ARP, sll_protocol==htons(0x88b5):
packet sent with EtherType of 0x88b5
This shows that leaving sll_protocol set to zero does not have
the desired effect and that it needs to be set to the desired
link-layer protocol.
There is code in the relevant kernel source file
(net/packet/af_packet.c) which appears to inspect the value of the
sll_protocol field and use it as the link-layer protocol number,
however I am not sufficiently familiar with this subsystem to be
fully confident of what is happening. The line in question is:
proto = saddr->sll_protocol;
In version 3.4 of the kernel this can be found in the functions
packet_snd and tpacket_snd. In version 2.6.26 it is in packet_sendmsg.
Below is a patch that adds sll_protocol to the list of required fields.
This may not be the whole truth, since it is not clear what role if any
sll_protocol, sll_halen or sll_addr would play when the socket type is
SOCK_RAW, however I'm confident it is more accurate than the page as it
stands at present.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
This kernel constant is not exposed to user space.
Reported-by: Christophe Lohr <Christophe.Lohr@telecom-bretagne.eu>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
[Part of a general change to remove cruft from this page.]
Much of the detail on hardware specifics in this page dates
from the 20th century. (The last major update to this page was in
man-pages-1.14!) It's hugely out of date now (many of these
devices disappeared from the kernel years ago.)
Here, we remove some ancient x86 options.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
[Part of a general change to remove cruft from this page.]
Much of the detail on device-driver specifics in this page dates
from the 20th century. (The last major update to this page was in
man-pages-1.14!) It's hugely out of date now (many of these
devices disappeared from the kernel years ago.) Arguably, this
kind of detail should never have been placed in a man page to
begin with, since devices come and go. Remove such text, and
where appropriate and possible add pointers to files in the
kernel Documentation/ directory.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The information here relates to ancient systems
Some (possibly more up to date) info can be found
in Documentation/kernel-parameters.txt.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
[Part of a general change to remove cruft from this page.]
Much of the detail on device-driver specifics in this page dates
from the 20th century. (The last major update to this page was in
man-pages-1.14!) It's hugely out of date now (many of these
devices disappeared from the kernel years ago.) Arguably, this
kind of detail should never have been placed in a man page to
begin with, since devices come and go. Remove such text, and
where appropriate and possible add pointers to files in the
kernel Documentation/ directory.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
[Part of a general change to remove cruft from this page.]
Much of the detail on device-driver specifics in this page dates
from the 20th century. (The last major update to this page was in
man-pages-1.14!) It's hugely out of date now (many of these
devices disappeared from the kernel years ago.) Arguably, this
kind of detail should never have been placed in a man page to
begin with, since devices come and go. Remove such text, and
where appropriate and possible add pointers to files in the
kernel Documentation/ directory.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
[Part of a general change to remove cruft from this page.]
Much of the detail on device-driver specifics in this page dates
from the 20th century. (The last major update to this page was in
man-pages-1.14!) It's hugely out of date now (many of these
devices disappeared from the kernel years ago.) Arguably, this
kind of detail should never have been placed in a man page to
begin with, since devices come and go. Remove such text, and
where appropriate and possible add pointers to files in the
kernel Documentation/ directory.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
[Part of a general change to remove cruft from this page.]
Much of the detail on device-driver specifics in this page dates
from the 20th century. (The last major update to this page was in
man-pages-1.14!) It's hugely out of date now (many of these
devices disappeared from the kernel years ago.) Arguably, this
kind of detail should never have been placed in a man page to
begin with, since devices come and go. Remove such text, and
where appropriate and possible add pointers to files in the
kernel Documentation/ directory.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
[Part of a general change to remove cruft from this page.]
Much of the detail on device-driver specifics in this page dates
from the 20th century. (The last major update to this page was in
man-pages-1.14!) It's hugely out of date now (many of these
devices disappeared from the kernel years ago.) Arguably, this
kind of detail should never have been placed in a man page to
begin with, since devices come and go. Remove such text, and
where appropriate and possible add pointers to files in the
kernel Documentation/ directory.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
[Part of a general change to remove cruft from this page.]
Much of the detail on device-driver specifics in this page dates
from the 20th century. (The last major update to this page was in
man-pages-1.14!) It's hugely out of date now (many of these
devices disappeared from the kernel years ago.) Arguably, this
kind of detail should never have been placed in a man page to
begin with, since devices come and go. Remove such text, and
where appropriate and possible add pointers to files in the
kernel Documentation/ directory.
In the specific case of floppy drives: the drivers still
exist, but it's been a while since most of saw these devices
in the wild. So, just refer the reader to the kernel source
file for details. (The detail in this man page was after all
originally drawn from that file.)
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
See kernel commit a88dc06cd515b3bb9dfa18606e88d0be9a5b6ddd
[Part of a general change to remove cruft from this page.]
Much of the detail on device-driver specifics in this page dates
from the 20th century. (The last major update to this page was in
man-pages-1.14!) It's hugely out of date now (many of these
devices disappeared from the kernel years ago.) Arguably, this
kind of detail should never have been placed in a man page to
begin with, since devices come and go. Remove such text, and
where appropriate and possible add pointers to files in the
kernel Documentation/ directory.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
[Part of a general change to remove cruft from this page.]
Much of the detail on device-driver specifics in this page dates
from the 20th century. (The last major update to this page was in
man-pages-1.14!) It's hugely out of date now (many of these
devices disappeared from the kernel years ago.) Arguably, this
kind of detail should never have been placed in a man page to
begin with, since devices come and go. Remove such text, and
where appropriate and possible add pointers to files in the
kernel Documentation/ directory.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
"xattr" is a more meaningful name than "attr" (it resonates
with the names of the system calls), so as long as we are
moving the page to a new section, we'll change the name as well,
and retain an acl(5) link so that old references remain valid.
Reported-by: Christoph Hellwig <hch@infradead.org>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
From experimentation, I found a 16kB limit on name + value +
overhead bytes. Digger deeper, I see that
https://btrfs.wiki.kernel.org/index.php/Project_ideas#Unlimited_extended_attributes
says:
Unlimited extended attributes
Not claimed — no patches yet — Not in kernel yet
Currently size of value of an extended attribute must fit into
inline space (~3900 on 4k leaf size), while other filesystems
do not limit the size. Add a new b-tree item to hold the xattr
value in extents.
And reading mkfs.btrfs(8) reveals that the default node (AKA leaf)
size is 16kB.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
After discussions with Andreas Gruenbacher, it makes sense to
move this page into man-pages, since it mostly relates to
kernel details.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Graham Shaw