Re: Proxy server, mode intercept on NetBSD 7.0.1

[Rodolfo Edgar]

2016-08-03 2:16 GMT-05:00, Christos Zoulas :
> In article
> <1470085391.2331984.683025593.376ee...@webmail.messagingengine.com>,
>   wrote:
>>Me butthurt?  That's comical.  You just wrote the most butthurt email
>>I've ever seen on the mailing lists, and that's saying something.
>>
>>My point, and I think it was pretty clear, is that NetBSD has long been
>>stable for me but suddenly requires an uncharacteristic amount of fixing
>>for a stable release.  I have the crash dumps to prove it.  If this
>>thread is any suggestion, I'm not the only one with ipfilter woes.
>>
>>You seem to take personal offense to this revelation and went full-on
>>Internet Tough Guy(TM).  That's the definition of butthurt.   Why do you
>>find this so personally insulting?  Perhaps you should talk it through
>>with a therapist.  It may help you.
>
> Well, I have been trying to fix some of the ipf issues on 7 with some
> success.

Thanks you!

> I think that the problem is that most of us have switched to npf, and so
> ipf

In my case I will try to use the npf to do my router, firewall and
proxy in my LANs networks

> is not getting a lot of testing. Perhaps you can try switching too? I
> prefer
> that you switch, and we are willing to help you do so, rather than spending
> time to fix ipf.

Thanks again, I think that some users need examples, similar to The
NetBSD Network FAQ. to use npf, currently I am reading the
https://www.netbsd.org/~rmind/npf/#_network_address_translation, I
hope to understand all, and use in my scenary.

>
> christos
>
>

Re: Proxy server, mode intercept on NetBSD 7.0.1

[Stephen Borrill]

On Wed, 3 Aug 2016, Christos Zoulas wrote:

In article ,
Stephen Borrill   wrote:

On Mon, 1 Aug 2016, metalli...@fastmail.fm wrote:

I've been very disappointed with the quality of NetBSD 7.0.1 since I
upgraded from 6.1.5 a few weeks ago.  I've been running pretty much the
same system config as my home router/NAT/firewall/server since NetBSD
1.5.  I believe that's almost 15 years of ipfilter/ipnat.  It has always
worked well for me... until I moved to NetBSD 7.   I've had several
issues with various parts of the OS, but ipf is the one that causes
random kernel panics.


I've got to agree with you. I've been using NetBSD for commercial products
since 1996 and NetBSD 7 is the first upgrade that's got me nervous.
Kudos to developers who've helped out with USB failing to work, squid
interception, etc. The random lockups and panics with IPfilter are the
most worrying for me though:

http://gnats.netbsd.org/50168

I believe that the bugs are triggered by external packets which is why
they are random (disconnecting from the Internet stops the problems).
Machines which have been solid for months have just started locking. I
count this as a remote DoS vulnerability, but haven't yet tracked down
the triggers.

We need to support an installed base of a mix of netbsd-5 and
netbsd-7 machines. Until we complete the upgrade to netbsd-7, npf will
increase that workload because of duplication of effort. Even so as the
firewall rules are autogenerated and have been developed over a number of
years, it is not a small change to go into production systems.




---


bash-4.3# crash -M netbsd.0.core -N netbsd.0
Crash version 7.0.1, image version 7.0.1.
System panicked: trap
Backtrace from time of crash is available.
crash> bt
_KERNEL_OPT_NARCNET() at 0
_KERNEL_OPT_ACPI_SCANPCI() at _KERNEL_OPT_ACPI_SCANPCI+0x1
vpanic() at vpanic+0x145
snprintf() at snprintf
startlwp() at startlwp
calltrap() at calltrap+0x11
ipf_frag_expire() at ipf_frag_expire+0x76
ipf_slowtimer() at ipf_slowtimer+0x15
ipf_timer_func() at ipf_timer_func+0x2d
callout_softclock() at callout_softclock+0x248
softint_dispatch() at softint_dispatch+0x7d
DDB lost frame for Xsoftintr+0x4f, trying 0xfe80cefcaff0
Xsoftintr() at Xsoftintr+0x4f
--- interrupt ---
0:
crash> q
bash-4.3# crash -M netbsd.1.core -N netbsd.1
Crash version 7.0.1, image version 7.0.1.
System panicked: trap
Backtrace from time of crash is available.
crash> bt
_KERNEL_OPT_NARCNET() at 0
_KERNEL_OPT_ACPI_SCANPCI() at _KERNEL_OPT_ACPI_SCANPCI+0x7
vpanic() at vpanic+0x145
snprintf() at snprintf
startlwp() at startlwp
calltrap() at calltrap+0x11
ipf_frag_delete() at ipf_frag_delete+0x74


This seems to be dying at:

static void
ipf_frag_free(ipf_frag_softc_t *softf, ipfr_t *fra)
{
   KFREE(fra);
->FBUMP(ifs_expire);
   softf->ipfr_stats.ifs_inuse--;
}

I would comment the last 2 lines and see if I get something better.
There seems to be some memory corruption (surprise)


That backtrace looks very different from mine, but memory corruption will 
reveal itself in strange ways. I wish I were getting more panics and 
coredumps as at least that would allow analysis, but for me, it's mainly 
just complete system freeze.


--
Stephen

Boot, write info to file, shutdown

[Raymond Phillips]

I'd like to install NetBSD (amd64 in this case) onto a USB key so the portable 
system will:

- boot as quickly as possible
- run a shell script automatically as soon as it boots
- print some information about the machine's hardware to a file
- print a message to the console
- shut down automatically

all without human intervention.

Initially I thought it wouldn't be necessary to boot into multi-user mode, but 
the only way I know to run a script automatically at startup is to use cron's 
@reboot time, and cron doesn't start in single-user mode.  Is there a way to 
launch a script automatically in single-user mode?

Even when using @reboot it was necessary to use the full path to one of the 
programs that extracts hardware information (dmidecode, which is installed in 
/usr/local/sbin) in the script.  It seems that the path isn't setup at that 
stage?

In an effort to reduce the boot time I moved many files, such as ones related 
to networking, from /etc/rc.d to another directory.  That caused rcorder to 
generate lots of errors.  What's the best way of stopping daemons starting?

What's the best way of printing a message (spread over several lines) to the 
console?


Ray

Re: Proxy server, mode intercept on NetBSD 7.0.1

[Christos Zoulas]

In article <1470085391.2331984.683025593.376ee...@webmail.messagingengine.com>,
  wrote:
>Me butthurt?  That's comical.  You just wrote the most butthurt email
>I've ever seen on the mailing lists, and that's saying something.
>
>My point, and I think it was pretty clear, is that NetBSD has long been
>stable for me but suddenly requires an uncharacteristic amount of fixing
>for a stable release.  I have the crash dumps to prove it.  If this
>thread is any suggestion, I'm not the only one with ipfilter woes.
>
>You seem to take personal offense to this revelation and went full-on
>Internet Tough Guy(TM).  That's the definition of butthurt.   Why do you
>find this so personally insulting?  Perhaps you should talk it through
>with a therapist.  It may help you.

Well, I have been trying to fix some of the ipf issues on 7 with some success.
I think that the problem is that most of us have switched to npf, and so ipf
is not getting a lot of testing. Perhaps you can try switching too? I prefer
that you switch, and we are willing to help you do so, rather than spending
time to fix ipf.

christos

Re: Proxy server, mode intercept on NetBSD 7.0.1

[Christos Zoulas]

In article ,
Stephen Borrill   wrote:
>On Mon, 1 Aug 2016, metalli...@fastmail.fm wrote:
>> I've been very disappointed with the quality of NetBSD 7.0.1 since I
>> upgraded from 6.1.5 a few weeks ago.  I've been running pretty much the
>> same system config as my home router/NAT/firewall/server since NetBSD
>> 1.5.  I believe that's almost 15 years of ipfilter/ipnat.  It has always
>> worked well for me... until I moved to NetBSD 7.   I've had several
>> issues with various parts of the OS, but ipf is the one that causes
>> random kernel panics.
>
>I've got to agree with you. I've been using NetBSD for commercial products 
>since 1996 and NetBSD 7 is the first upgrade that's got me nervous. 
>Kudos to developers who've helped out with USB failing to work, squid 
>interception, etc. The random lockups and panics with IPfilter are the 
>most worrying for me though:
>
>http://gnats.netbsd.org/50168
>
>I believe that the bugs are triggered by external packets which is why 
>they are random (disconnecting from the Internet stops the problems). 
>Machines which have been solid for months have just started locking. I
>count this as a remote DoS vulnerability, but haven't yet tracked down 
>the triggers.
>
>We need to support an installed base of a mix of netbsd-5 and 
>netbsd-7 machines. Until we complete the upgrade to netbsd-7, npf will 
>increase that workload because of duplication of effort. Even so as the 
>firewall rules are autogenerated and have been developed over a number of 
>years, it is not a small change to go into production systems.
>
>>
>---
>>
>> bash-4.3# crash -M netbsd.0.core -N netbsd.0
>> Crash version 7.0.1, image version 7.0.1.
>> System panicked: trap
>> Backtrace from time of crash is available.
>> crash> bt
>> _KERNEL_OPT_NARCNET() at 0
>> _KERNEL_OPT_ACPI_SCANPCI() at _KERNEL_OPT_ACPI_SCANPCI+0x1
>> vpanic() at vpanic+0x145
>> snprintf() at snprintf
>> startlwp() at startlwp
>> calltrap() at calltrap+0x11
>> ipf_frag_expire() at ipf_frag_expire+0x76
>> ipf_slowtimer() at ipf_slowtimer+0x15
>> ipf_timer_func() at ipf_timer_func+0x2d
>> callout_softclock() at callout_softclock+0x248
>> softint_dispatch() at softint_dispatch+0x7d
>> DDB lost frame for Xsoftintr+0x4f, trying 0xfe80cefcaff0
>> Xsoftintr() at Xsoftintr+0x4f
>> --- interrupt ---
>> 0:
>> crash> q
>> bash-4.3# crash -M netbsd.1.core -N netbsd.1
>> Crash version 7.0.1, image version 7.0.1.
>> System panicked: trap
>> Backtrace from time of crash is available.
>> crash> bt
>> _KERNEL_OPT_NARCNET() at 0
>> _KERNEL_OPT_ACPI_SCANPCI() at _KERNEL_OPT_ACPI_SCANPCI+0x7
>> vpanic() at vpanic+0x145
>> snprintf() at snprintf
>> startlwp() at startlwp
>> calltrap() at calltrap+0x11
>> ipf_frag_delete() at ipf_frag_delete+0x74

This seems to be dying at:

static void 
ipf_frag_free(ipf_frag_softc_t *softf, ipfr_t *fra)
{
KFREE(fra);
->FBUMP(ifs_expire);
softf->ipfr_stats.ifs_inuse--; 
}

I would comment the last 2 lines and see if I get something better.
There seems to be some memory corruption (surprise)

christos