Re: Allow libpcap to read files with some additional link-layer type values
Thanks. (By the way, when testing this on a 7.3 virtual machine, I saw the problem that I suspect this change to sys/net/if_loop.c: revision 1.97 date: 2023/07/21 22:24:41; author: bluhm; state: Exp; lines: +10 -1; commitid: zlUMTFeyu4Tpey4p; Do not dump corrupted packets on loopback bpf. lo(4) used to dump to bpf only for output. It seems that when if_bpf_mtap() was introduced, this changed and lo(4) dumps an additional truncated packet. The default bpf_mtap_ether() is not suitable for lo(4). Install a dummy lo_bpf_mtap() to suppress bpf on input. OK mvs@ fixes - the captures I did on lo0 had two copies of each packet, the first of which has no DLT_LOOP header, the second of which does. That change should perhaps be backported to the 7.x branch if a 7.4 release is likely to happen. Given that a link-layer type value of 12 means DLT_RAW on macOS and on BSDs other then OpenBSD, reading the capture file with tcpdump on those OSes means that the *first* packet is correctly dissected and the *second* packet is reported as damaged; DLT_ collisions such as that are the reason why I introduced the notion of LINKTYPE_ values, to be used in pcap and now pcapng files, and changed libpcap so that it writes DLT_RAW captures with a link-layer type value of 101 and, when reading captures, maps a link-layer type value of 101 in the file to DLT_RAW.)
Re: Allow libpcap to read files with some additional link-layer type values
On 2023/08/02 13:12, Guy Harris wrote: > Thanks. > > (By the way, when testing this on a 7.3 virtual machine, I saw the problem > that I suspect this change to sys/net/if_loop.c: > > revision 1.97 > date: 2023/07/21 22:24:41; author: bluhm; state: Exp; lines: +10 -1; > commitid: zlUMTFeyu4Tpey4p; > Do not dump corrupted packets on loopback bpf. > > lo(4) used to dump to bpf only for output. It seems that when > if_bpf_mtap() was introduced, this changed and lo(4) dumps an > additional truncated packet. The default bpf_mtap_ether() is not > suitable for lo(4). > > Install a dummy lo_bpf_mtap() to suppress bpf on input. > > OK mvs@ > > fixes - the captures I did on lo0 had two copies of each packet, the first of > which has no DLT_LOOP header, the second of which does. That change should > perhaps be backported to the 7.x branch if a 7.4 release is likely to happen. Thanks for the confirmation on that. That fix will be in 7.4; other than post-release patch branches (7.2-stable, 7.3-stable, etc; mainly used for fairly serious or widely seen issues) we just have a single repo branch and version numbering is a simple +0.1 each time, nothing special about an x.0 release. > Given that a link-layer type value of 12 means DLT_RAW on macOS and on BSDs > other then OpenBSD, reading the capture file with tcpdump on those OSes means > that the *first* packet is correctly dissected and the *second* packet is > reported as damaged; DLT_ collisions such as that are the reason why I > introduced the notion of LINKTYPE_ values, to be used in pcap and now pcapng > files, and changed libpcap so that it writes DLT_RAW captures with a > link-layer type value of 101 and, when reading captures, maps a link-layer > type value of 101 in the file to DLT_RAW.)
vi(1) move forward count paragraphs with 'para' options
Running latest snapshot.
Acording to vi(1):
[count] }
Move forward count paragraphs.
[...]
paragraphs, para [IPLPPPQPP LIpplpipbpBlBdPpLpIt]
vi only. Define additional paragraph boundaries for the { and }
commands.
The bug:
Using the move forward with paragraphs separated by tags (those in
'para' options) as in the example below doesn't move the cursor to the
right place.
Example:
Open with vi(1) a file conaining the following lines. Put your cursor
at the '1' or in the empty line right above, and try using '}' (move to
next paragraph) with different number prefixes (placing again the cursor
at "1" each time).
1
2
3
4
5
6
There it works as expected. Now repeat the same on this lines (keeping
paragraphs option untouched):
.PP
1
.PP
2
.PP
3
.PP
4
.PP
5
.PP
6
The prefixes in this case will move your cursor to "prefix + prefix - 1"
paragraphs. This is:
- 2 will move your cursor to 3
- 3 will move your cursor to 5
- 4 to 7
- 5 to 9
and so on.
Finally, repeat the same steps on this lines:
.PP 1
.PP 2
.PP 3
.PP 4
.PP 5
.PP 6
.PP 7
.PP 8
Now the cursor will go "prefix *= 2"
It behaves in the same fashion moving to previous paragraphs.
I took a look to this file:
/usr/src/usr.bin/vi/vi/v_paragraph.c
But I wasn't able to understand what it does. Especially this part:
/*
* If we start in text, we want to switch states
* (2 * N - 1) times, in non-text, (2 * N) times.
*/
cnt = F_ISSET(vp, VC_C1SET) ? vp->count : 1;
cnt *= 2;
if (len == 0 || v_isempty(p, len))
pstate = P_INBLANK;
else {
--cnt;
pstate = P_INTEXT;
}
--
Walter
Re: Allow libpcap to read files with some additional link-layer type values
On 2023/08/02 10:12, Alexandr Nedvedicky wrote: > Hello, > > thank you for detailed explanation and diff. I went through it > and agree with your change. > > I also gave it a quick try to see if OpenBSD's tcpdump linked > with patched libpcap is able to read captured packets > which come from earlier capture, the one which was saved > by OpenBSD's tcpdump _without_ patched libpcap. I was using lo0 > for test. Everything worked as expected. I could test with > loopback only. > > this change is OK sashan@ > > thanks and > regards > sashan > I think it's reasonable to do this too, OK sthen@
Re: taskq_next_work: page fault trap when staring Xfce
> Date: Wed, 2 Aug 2023 14:11:36 +1000
> From: Jonathan Gray
>
> On Mon, Jul 31, 2023 at 10:48:12PM +1000, Jonathan Gray wrote:
> > On Sun, Jul 30, 2023 at 03:21:47PM +0900, YASUOKA Masahiko wrote:
> > > Hello,
> > >
> > > I got new vaio last week, the machine seems to have the same graphic
> > >
> > > inteldrm0 at pci0 dev 2 function 0 "Intel Graphics" rev 0x04
> > > drm0 at inteldrm0
> > > inteldrm0: msi, ALDERLAKE_P, gen 12
> > >
> > > and has the same problem. I found having Option "PageFlip" "off" in
> > > /etc/X11/xorg.conf can workaround the problem.
> > >
> > > Section "Device"
> > > Identifier "Card0"
> > > Driver "modesetting"
> > > BusID "PCI:0:2:0"
> > > Option "PageFlip" "off"
> > > EndSection
> >
> > running GENERIC I got the following with xfce.
> >
> > matches the trace in an earlier report from sthen@
> > https://marc.info/?l=openbsd-bugs=168234057913478=2
> >
> > dpt_insert_entries+0xbc: movl 0x34(%r8),%r10d
> > r8 0x81938fe0
> > r10 0x1000
> >
> >0x81ab0bc3 <+179>: mov%r8,%rcx
> >0x81ab0bc6 <+182>: add$0x20,%rcx
> >0x81ab0bca <+186>: je 0x81ab0be8
> >
> >0x81ab0bcc <+188>: mov0x34(%r8),%r10d
> >0x81ab0bd0 <+192>: test %r10d,%r10d
> >0x81ab0bd3 <+195>: je 0x81ab0be8
> >
> >
> > (gdb) info line *0x81ab0bcc
> > Line 34 of "/sys/dev/pci/drm/i915/i915_scatterlist.h"
> >starts at address 0x81ab0bc1
> >and ends at 0x81ab0bd5 .
> >
> > if (dma && s.sgp && sg_dma_len(s.sgp) == 0) {
> >
> > dpt_insert_entries+0xbc
> > dpt_bind_vma+0x64
> > i915_vma_bind+0x317
> > i915_vma_pin_ww+0x44b
> > intel_plane_pin_fb+0x25c
> > intel_prepare_plane_pin_fb+0x12c
> > drm_atomic_helper_prepare_planes+0x5b
> > intel_atomic_commit+0xda
> > drm_atomic_helper_page_flip+0x77
> > drm_mode_page_flip_ioctl+0x466
> > drm_do_ioctl+0x285
> > drmioctl+0xdc
> > VOP_IOCTL+0x57
> > vn_ioctl+0x6c
>
> The fix is to not reset the end of list marker when
> assigning a page.
The Linux version retains the end marker, so this fix appears to be correct.
ok kettenis@
> Index: sys/dev/pci/drm/include/linux/scatterlist.h
> ===
> RCS file: /cvs/src/sys/dev/pci/drm/include/linux/scatterlist.h,v
> retrieving revision 1.5
> diff -u -p -r1.5 scatterlist.h
> --- sys/dev/pci/drm/include/linux/scatterlist.h 1 Jan 2023 01:34:58
> - 1.5
> +++ sys/dev/pci/drm/include/linux/scatterlist.h 2 Aug 2023 04:02:02
> -
> @@ -119,7 +119,6 @@ sg_set_page(struct scatterlist *sgl, str
> sgl->dma_address = page ? VM_PAGE_TO_PHYS(page) : 0;
> sgl->offset = offset;
> sgl->length = length;
> - sgl->end = false;
> }
>
> #define sg_dma_address(sg) ((sg)->dma_address)
>
>
Re: taskq_next_work: page fault trap when staring Xfce
02.08.2023 07:11, Jonathan Gray пишет: > The fix is to not reset the end of list marker when > assigning a page. This alone without the xorg.conf snippet is stable, no hangs or glitches in Xfce or 0.A.D., which so far instanstly triggered corruptions. Thanks a lot! FWIW, OK kn > > Index: sys/dev/pci/drm/include/linux/scatterlist.h > === > RCS file: /cvs/src/sys/dev/pci/drm/include/linux/scatterlist.h,v > retrieving revision 1.5 > diff -u -p -r1.5 scatterlist.h > --- sys/dev/pci/drm/include/linux/scatterlist.h 1 Jan 2023 01:34:58 > - 1.5 > +++ sys/dev/pci/drm/include/linux/scatterlist.h 2 Aug 2023 04:02:02 > - > @@ -119,7 +119,6 @@ sg_set_page(struct scatterlist *sgl, str > sgl->dma_address = page ? VM_PAGE_TO_PHYS(page) : 0; > sgl->offset = offset; > sgl->length = length; > - sgl->end = false; > } > > #define sg_dma_address(sg) ((sg)->dma_address) >
Re: Allow libpcap to read files with some additional link-layer type values
Hello, thank you for detailed explanation and diff. I went through it and agree with your change. I also gave it a quick try to see if OpenBSD's tcpdump linked with patched libpcap is able to read captured packets which come from earlier capture, the one which was saved by OpenBSD's tcpdump _without_ patched libpcap. I was using lo0 for test. Everything worked as expected. I could test with loopback only. this change is OK sashan@ thanks and regards sashan
Allow libpcap to read files with some additional link-layer type values
>Synopsis: Allow libpcap to read files with some additional link-layer
>type values
>Category: library
>Environment:
System : OpenBSD 7.3
Details : OpenBSD 7.3 (GENERIC.MP) #1125: Sat Mar 25 10:36:29 MDT
2023
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
Architecture: OpenBSD.amd64
Machine : amd64
>Description:
Some DLT_s have values on one operating system that collide with
values for different DLT_s on other operating systems.
If those DLT_ values are used in pcap files as the link-layer
header type, that means that the packets in captures with that
link-layer type will be interpreted incorrectly on other
operating systems.
To resolve this, a different set of values for use as link-layer
header types in files, the LINKTYPE_ values, was created:
https://www.tcpdump.org/linktypes.html
Most LINKTYPE_ values are numerically equal to the corresponding
DLT_ values, so code that reads pcap files and that uses DLT_
values in its APIs can just pass the link-layer type value on to
the caller as a DLT_ value.
However, for the LINKTYPE_ values that are not equal to the
corresponding DLT_ value on some platform, because that
platform's value collides with the value for a different DLT_ on
another platform or platforms, the LINKTYPE_ value must be
mapped to the corresponding DLT_ value before being provided to
the caller.
OpenBSD's libpcap does not do that, so captures for certain
link-layer types will, if written using the LINKTYPE_ value, not
be readable by programs using libpcap, such as tcpdump.
>How-To-Repeat:
Build tcpdump.org's version of libpcap from the tip of the main
branch, and then use that to build tcpdump.org's version of
tcpdump.
Capture on the loopback device with that version of tcpdump,
saving the packets to a file using -w.
Attempt to read that file with the tcpdump that comes with
OpenBSD.
>Fix:
Make this change to libpcap's savefile.c:
Index: savefile.c
===
RCS file: /cvs/src/lib/libpcap/savefile.c,v
retrieving revision 1.17
diff -u -r1.17 savefile.c
--- savefile.c 27 May 2020 04:24:01 - 1.17
+++ savefile.c 2 Aug 2023 05:36:57 -
@@ -160,7 +160,65 @@
}
p->tzoff = hdr.thiszone;
p->snapshot = hdr.snaplen;
- p->linktype = hdr.linktype;
+ /*
+* Handle some LINKTYPE_ values in pcap headers that aren't
+* the same as the corresponding OpenBSD DLT_ values.
+*
+* Those LINKTYPE_ values were assigned for DLT_s whose
+* numerical values differ between platforms, so that
+* the link-layer type value in pcap file headers can
+* be platform-independent. This means that code reading
+* a pcap file doesn't have to know on which platform a
+* file was written in order to read it correctly.
+*
+* See
+*
+* https://www.tcpdump.org/linktypes.html
+*
+* for the current list of LINKTYPE_ values and the corresponding
+* DLT_ values.
+*/
+ switch (hdr.linktype) {
+
+ case 100:
+ /* LINKTYPE_ATM_RFC1483 */
+ p->linktype = DLT_ATM_RFC1483;
+ break;
+
+ case 101:
+ /* LINKTYPE_RAW */
+ p->linktype = DLT_RAW;
+ break;
+
+ case 102:
+ /* LINKTYPE_SLIP_BSDOS */
+ p->linktype = DLT_SLIP_BSDOS;
+ break;
+
+ case 103:
+ /* LINKTYPE_PPP_BSDOS */
+ p->linktype = DLT_PPP_BSDOS;
+ break;
+
+ case 108:
+ /* LINKTYPE_LOOP */
+ p->linktype = DLT_LOOP;
+ break;
+
+ case 109:
+ /* LINKTYPE_ENC */
+ p->linktype = DLT_ENC;
+ break;
+
+ case 256:
+ /* LINKTYPE_PFSYNC */
+ p->linktype = DLT_PFSYNC;
+ break;
+
+ default:
+ p->linktype = hdr.linktype;
+ break;
+ }
p->sf.rfile = fp;
p->bufsize = hdr.snaplen;
