tpacket_rcv() does
if (sk->sk_type == SOCK_DGRAM) {
macoff = netoff = TPACKET_ALIGN(po->tp_hdrlen) + 16 +
po->tp_reserve;
} else {
unsigned int maclen = skb_network_offset(skb);
netoff = TPACKET_ALIGN
On May 2, 2017, at 10:16 AM, chetan loke wrote:
> Commit that caused it:
>
> https://github.com/torvalds/linux/commit/41a50d621a321b4c15273cc1b5ed41437f4acdfb
>
> Reverting that change is what we need.
As long as you do *not* revert
https://github.com/torvalds/linux/commit/da413eec72
On May 2, 2017, at 10:54 AM, Guy Harris wrote:
> Yes, there's a case where user space wasn't being woken up.
See also this thread from almost 3 years ago, beginning with
http://marc.info/?l=linux-netdev&m=140633612828824&w=2
and this patch thread from a
On May 2, 2017, at 8:04 AM, chetan loke wrote:
> On Sat, Apr 15, 2017 at 7:41 PM, Guy Harris wrote:
>> On Apr 15, 2017, at 7:10 PM, Andrew Lunn wrote:
>>
>>> Do you think this is a kernel problem, libpcap problem, or an
>>> application problem?
>>
On Apr 15, 2017, at 7:10 PM, Andrew Lunn wrote:
> Do you think this is a kernel problem, libpcap problem, or an
> application problem?
An application problem. See my response on netdev; the timeout (which is
provided by the kernel's capture mechanism, in most cases) is to make sure
packets do
On Apr 15, 2017, at 4:44 PM, Andrew Lunn wrote:
> Yet i'm debugging an application which expects a timeout even when
> there are 0 packets.
Well, you've already found a bug - it expects a timeout where there are no
packets.
To quote the pcap man page (this is the latest version, which calls it
On May 14, 2016, at 1:26 PM, Richard Cochran wrote:
> On Sat, May 14, 2016 at 11:47:22AM -0700, Guy Harris wrote:
>> So if you have a GUI application for packet capture, with a combo box to
>> select the type of time stamping, should it:
>>
>> 1) regardless of
On May 14, 2016, at 12:41 AM, Jeff Kirsher wrote:
> Are you planning to produce a patch or are you wanting us to do the work to
> fix the issue? Just asking so that work is not duplicated.
I'm willing to produce the patches, although
1) I don't currently have a platform set up to test
On May 14, 2016, at 12:30 AM, Richard Cochran wrote:
> On Fri, May 13, 2016 at 04:12:52PM -0700, Guy Harris wrote:
>> The Linux implementation currently implements the inquiry by doing a
>> ETHTOOL_GET_TS_INFO SIOETHTOOL ioctl and looking at the
>> so_timestamping bits, i
On May 13, 2016, at 4:12 PM, Guy Harris wrote:
> drivers/net/ethernet/freescale/gianfar*.c
>
> reports HWTSTAMP_FILTER_ALL even if the device doesn't have
> FSL_GIANFAR_DEV_HAS_TIMER set so that it claims that devices without a timer
> can do hardware timestampin
libpcap offers the ability to request hardware time stamping for packets and to
inquire which forms of hardware time stamping, if any, are supported for an
interface.
The Linux implementation currently implements the inquiry by doing a
ETHTOOL_GET_TS_INFO SIOETHTOOL ioctl and looking at the so_
On Mar 3, 2016, at 3:23 AM, Ed Schouten wrote:
> While comparing the behavior of the Berkeley sockets API different
> operating systems, I noticed that in some places we return different
> errno's as what POSIX requires and how other systems work, but also what
> we document in our own man pages.
On Nov 4, 2015, at 9:04 PM, David Miller wrote:
> As part of fixing y2038 problems, Arnd is going to have to make a new
> version fo the AF_PACKET mmap() tpacker descriptors in order to extend
> the time values to 64-bit.
>
> So I want everyone to think about whether there are any other changes
On Nov 3, 2015, at 3:43 PM, Guy Harris wrote:
> To which particular PA-RISC processor are you referring? It might not be the
> same on all processors.
Chapter 3 "Addressing and Access Control" of PA-RISC 2.0 Architecture:
http://h21007.www2.hp.com/portal/downl
On Nov 3, 2015, at 3:03 PM, Helge Deller wrote:
> Sadly it's nowhere clearly documented how big the L1 cacheline of parisc
> really is.
To which particular PA-RISC processor are you referring? It might not be the
same on all processors.
If openpa.net is to be believed, then:
The 7100LC has
On Oct 6, 2015, at 8:02 AM, Andrew Lunn wrote:
>> Sure just throwing out an idea. I suspect whatever interface you have
>> will include the vendor-id or some other identifier and a set of
>> parsers in user space to pretty print the msg.
>
> If you are going to use wireshark, in this case, all
16 matches
Mail list logo
