[Bug 203630] [Hyper-V] [nat] [tcp] 10.2 NAT bug in TCP stack or hyperv netsvc driver

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203630

--- Comment #3 from Alexandr Krivulya  ---
Sorry for my mistake. You are right - vm that I mean is running on KVM. I have
some vm's running on Hyper-V but without nat. I can test it some later.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 203653] FreeBSD VM images don't default to dhcp

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203653

David Chisnall  changed:

   What|Removed |Added

   Assignee|freebsd-bugs@FreeBSD.org|r...@freebsd.org

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 203653] FreeBSD VM images don't default to dhcp

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203653

Bug ID: 203653
   Summary: FreeBSD VM images don't default to dhcp
   Product: Base System
   Version: 11.0-CURRENT
  Hardware: Any
OS: Any
Status: New
  Severity: Affects Some People
  Priority: ---
 Component: misc
  Assignee: freebsd-bugs@FreeBSD.org
  Reporter: thera...@freebsd.org

To make the VM images work out of the box, they should default to DHCP (and
IPv6 autoconfiguration).  People are either going to try them in a VM that does
DHCP or one that doesn't.  If it does DHCP, then they now don't need to
manually configure the network.  If it doesn't, then they're going to need
manual autoconfiguration irrespective of whether the VM tries to use DHCP.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 203656] unzip(1) utility fails to unzip some archives

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203656

--- Comment #5 from Dmitry Sivachenko  ---
Yes, libarchive from github's master does correctly unpack this file.
Any chance you can merge fresh libarchive to FreeBSD please?

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 203656] unzip(1) utility fails to unzip some archives

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203656

Bug ID: 203656
   Summary: unzip(1) utility fails to unzip some archives
   Product: Base System
   Version: 10.2-STABLE
  Hardware: Any
OS: Any
Status: New
  Severity: Affects Only Me
  Priority: ---
 Component: bin
  Assignee: freebsd-bugs@FreeBSD.org
  Reporter: de...@freebsd.org
CC: d...@freebsd.org, kient...@freebsd.org

Consider this archive:
http://people.freebsd.org/~demon/en-tr.txt.zip

% unzip en-tr.txt.zip 
Archive:  en-tr.txt.zip
unzip: Invalid central directory signature
%

unzip utility from Linux:
UnZip 6.00 of 20 April 2009, by Debian. Original by Info-ZIP.

works fine with this file.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 203656] unzip(1) utility fails to unzip some archives

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203656

--- Comment #1 from Dmitry Sivachenko  ---
I tried ports/archivers/unzip and it works fine with this file.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 203656] unzip(1) utility fails to unzip some archives

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203656

--- Comment #3 from Dmitry Sivachenko  ---
Most likely, I added Tim Kientzle to CC for this PR.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 187315] unzip(1): base unzip does not recognize *.zip archives from dropbox.com

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=187315

Dag-Erling Smørgrav  changed:

   What|Removed |Added

 CC||d...@freebsd.org

--- Comment #5 from Dag-Erling Smørgrav  ---
This is an issue in libarchive, see https://github.com/libarchive/libarchive

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 197017] segfault in unzip (libarchive) with malformed zip

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197017

Dag-Erling Smørgrav  changed:

   What|Removed |Added

 CC||d...@freebsd.org

--- Comment #1 from Dag-Erling Smørgrav  ---
This is an issue in libarchive, see https://github.com/libarchive/libarchive

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 203656] unzip(1) utility fails to unzip some archives

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203656

--- Comment #2 from Dag-Erling Smørgrav  ---
This is an issue in libarchive, see https://github.com/libarchive/libarchive

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 203662] tail -F misbehaves with stdin closed

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203662

Bug ID: 203662
   Summary: tail -F  misbehaves with stdin closed
   Product: Base System
   Version: 10.1-RELEASE
  Hardware: Any
OS: Any
Status: New
  Severity: Affects Some People
  Priority: ---
 Component: bin
  Assignee: freebsd-bugs@FreeBSD.org
  Reporter: fstd.l...@gmail.com

Created attachment 161859
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=161859=edit
tail: Don't assume fd 0 is standard input, because it might not be. Use the
`stdin`FILE pointer instead.

I have fixed a bug in NetBSD's tail(1), it turns out FreeBSD also has it.
Below is the original Problem Report incl. steps to reproduce; attached is a
patch adapted to FreeBSD's tail.


[Quoting from http://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=50322]

>Description:
The point of tail -F /some/file is to follow the contents in /some/file, even
if /some/file is occasionally replaced with a different file, e.g. due to
newsyslog(8) running.  In this mode of operation, standard input is ignored, as
it should be.

Now, if standard input happens to be closed, for example by running
tail -F /some/file <&-
or by it being used inside a script that has its standard input closed
(possibly as a result of daemonizing the script), tail's attempt to fopen(3)
/some/file will open the file at fd 0 - the typical fd for stdin.

However, later on, tail effectively uses fd == 0 to determine whether it is
reading from stdin or not.  If /some/file was opened at fd 0, tail will hence
consider itself to be reading from stdin and omit adding the vnode filters to
kqueue/kevent.

The result is that it will not follow the file after newsyslog(8) rotated the
file away; it will instead forever be stuck in kevent(2).

I've been hit by this for a long time, only yesterday managed to finally find
this (Heisen)bug.

The root cause of the problem is that tail assumes fd 0 is standard input.  It
does this in two places by comparing `fileno(fp)` to `STDIN_FILENO`.  (`fp`
being a FILE * as returned by fopen(3) or freopen(3)).
It should instead compare `fp` to `stdin`.

>How-To-Repeat:
Terminal 1:
$ touch /tmp/foo
$ tail -F /tmp/foo <&-

Terminal 2:
$ echo foo >>/tmp/foo  # Outputs 'foo' on Terminal 1
$ rm /tmp/foo
$ echo bar >>/tmp/foo  # SHOULD output 'bar' on Terminal 1, but does not.


Cheers,
Timo Buhrmester

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 203663] [tcp] Incorrect dupack processing to detect loss

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203663

Hiren Panchasara  changed:

   What|Removed |Added

   Assignee|freebsd-bugs@FreeBSD.org|hi...@freebsd.org
 CC||r...@freebsd.org

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 203663] [tcp] Incorrect dupack processing to detect loss

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203663

Bug ID: 203663
   Summary: [tcp] Incorrect dupack processing to detect loss
   Product: Base System
   Version: 11.0-CURRENT
  Hardware: Any
OS: Any
Status: New
  Severity: Affects Many People
  Priority: ---
 Component: kern
  Assignee: freebsd-bugs@FreeBSD.org
  Reporter: hi...@freebsd.org

Quoting Randall:
"When we recognize a dup-ack we *will not* recognize it if for example if the
rwnd changes even if new SACK information is reported in the sack blocks. This
is due to the fact that in non-SACK you don't (on purpose) recognize ACK?s
where the window changed (since you can?t really tell if its a plain window
update or a dup-ack).. This means we occasionally miss out on stroking the
dup-ack counter and getting out of recovery"

Another report of the same/similar problem:
https://lists.freebsd.org/pipermail/freebsd-net/2015-September/043387.html

This bug leads to us detecting loss later than we should have. And that leads
to suboptimal loss recovery as a whole.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 187081] swapoff runs too early during shutdown

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=187081

c.kw...@gmail.com changed:

   What|Removed |Added

 CC||c.kw...@gmail.com

--- Comment #1 from c.kw...@gmail.com ---
Created attachment 161855
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=161855=edit
fix "swaplate" to deal only with "late" swap devices

Hi. I like to join this heated conversation. :)

It seems to me you are bitten with /etc/rc.d/swaplate which should remove swap
partitions that are not directly available. Yet due to bug in the
swapon/swapoff logic it rather removes all swap partitions. I'm bored with this
too as on my machine swap is used constantly and when rebooting for some weird
reason I need to wait while the system gets all my sleepy daemons from swap
back to the memory instead of just stopping them.

The key problem is "-a" and "-L" options to swapon/swapoff as they give only
two choices:

1. Single "-a" selects only not "late" "auto" devices (the ones without
"noauto" and "late") from /etc/fstab.
2. Both options ("-aL") select whole range of "auto" devices (only skipping
"noauto" ones) from /etc/fstab.

This two choices doesn't give us a possibility to turn off only "late" devices,
that can really be dependent on some daemons with higher priorities so they MAY
fail further down "shutdown" sequence and as such they SHOULD be turned off
early during "shutdown".

The fix I propose actually breaks compatibility but I don't think this would be
an issue as:

 * there's not that much consumers of mentioned options in the scripts;
 * the fix brings clarity and usability.

In this fix:

 * single "-a" still select only not "late" "auto" devices;
 * option "-L" inverts "-a" meaning and selects only "late" "auto" devices;
 * documentation and starting script are fixed.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 203656] unzip(1) utility fails to unzip some archives

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203656

kient...@acm.org changed:

   What|Removed |Added

 CC||kient...@acm.org

--- Comment #4 from kient...@acm.org ---
Please try with libarchive master from github.  (You can test by using the
bsdtar command-line interface from there.)

Unzip support in libarchive has been considerably overhauled recently.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"