Re: IPFW on CURRENT: NAT forwarding exposes internal IP!

It looks like your httpd server is doing a redirect to your internal IP address, which it thinks is it’s ServerName. Don’t think NAT has anything to do with it. Daniel > On 29.09.2016 г., at 15:47, O. Hartmann wrote: > > -BEGIN PGP SIGNED MESSAGE- > Hash:

Re: IPFW on CURRENT: NAT forwarding exposes internal IP!

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Am Thu, 29 Sep 2016 16:00:10 +0300 Daniel Kalchev schrieb: Yes, your are right :-) Yes, I'm wrong, it is not NAT :-( Thanks a lot, Oliver > It looks like your httpd server is doing a redirect to your internal IP > address,

Jenkins build is back to normal : FreeBSD_HEAD #730

https://jenkins.FreeBSD.org/job/FreeBSD_HEAD/730/ ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: /dev/dsp got more sensitive about writes?

On 09/30/16 01:01, Benjamin Kaduk wrote: Hi all, I've updated from r302211 (June 26) to r306427 (yesterday), and the behavior of audio/sox (in its play(1) alias) seems to have changed. I used to be able to suspend play(1) for an arbitrary period of time and have the output continue when it was

kernel panic with ipnat/dummynet

Hi, I have problems with panics since 2 years. Diffrent machines, diffrent versions of FreeBSD (9+). Nothing has changed even in 12-CURRENT. FreeBSD is used as router/nat(ipnat)/ipfw/dummynet for over 400 desktops. I have 2 panics in 3h. Previous with only screen photo:

Re: zpool (online|replace|labelclear) issues, -f option also failing

This patch looks good its too bad the core hasn't looked at it yet. Ill do some testing and report any issues found. Some points you bring up in the bug are quite valid. Thanks for working on this! =] Ultima On Thu, Sep 29, 2016 at 8:25 AM, Ganael LAPLANCHE wrote: > On

Callout subsystem doesn't cancel interrupts for canceled callouts

At $WORK, we're working on adding support for high-precision RTT calculations in TCP. The goal is reduce the retransmission timeout significantly to help mitigate the impact of TCP incast. This means that the retransmit callout for TCP sockets gets scheduled significantly more often with a

Re: kernel panic with ipnat/dummynet

___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Destroy GPT partition scheme absolutely, how?

On Thursday, September 29, 2016 01:01:44 AM Andriy Gapon wrote: > On 28/09/2016 21:08, Andrey V. Elsukov wrote: > > This is very strange problem, how did you created MBR if you have not > > destroyed GPT? :) > > Using a tool that's not aware of GPT at all? I think the drive's arrived with some

IPFW: shape and status in CURRENT

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Since a couple of months now, I use IPFW on several projects. I use IPFW again after a long term hiatus since ~ 2003. Before I used pf. The reasons are mannyfold and one reason is very dogmatic - it is the FreeBSD's native firewall and several

/dev/dsp got more sensitive about writes?

Hi all, I've updated from r302211 (June 26) to r306427 (yesterday), and the behavior of audio/sox (in its play(1) alias) seems to have changed. I used to be able to suspend play(1) for an arbitrary period of time and have the output continue when it was foregrounded again. Now, it seems that I

Jenkins build is back to normal : FreeBSD_HEAD #729

https://jenkins.FreeBSD.org/job/FreeBSD_HEAD/729/ ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

IPFW on CURRENT: NAT forwarding exposes internal IP!

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Despite other problems with IPFW and its documentation regarding NAT, I face a serious and disturbing problem. I run a NanoBSD based router/firewall project of my own, running CURRENT (FreeBSD 12.0-CURRENT #1 r306333: Mon Sep 26 08:36:02 CEST

Build failed in Jenkins: FreeBSD_HEAD #727

See -- [...truncated 97466 lines...] --- DeclTemplate.o --- c++ -target x86_64-unknown-freebsd12.0 --sysroot=/builds/workspace/FreeBSD_HEAD/obj/builds/workspace/FreeBSD_HEAD/src/tmp

Re: arm64 server

Dear Colleagues, I am offering ARM64 server for builds and tests. It has 8 core and a spare 256GB SSD disk to install the OS and to boot from it. My knowledge and technical capacities are extremely modest, but I am also offering my time. Currently the server runs poor man's OS (namely - Linux)

Re: zpool (online|replace|labelclear) issues, -f option also failing

On Wed, 28 Sep 2016 19:00:42 -0400, Ultima wrote Hi Ultima, > I really think the force (-f) flag needs a bump in power (for both > replace and labelclear) [...]. In case you are interested, I have posted a patch to improve the 'zpool labelclear' command here :