Re: crypto vnd(4) question
On Mon, 24 Mar 2014, Chris Cappuccio wrote: Keep in mind, vnd emulates 512 byte sectors because that's the default disklabel that it uses (You probably mean a disktab, not a disklabel.) I am aware of it. As vnd(4) is a descendant of svnd(4), mixing different sector sizes should not be a big problem. I think that the danger of hidden bugs is higher in the crypto code when used together with emulated 4k-byte sectors, which is used (read: tested) much less. I will try both variants, nonethless. Thank you. Regards, David
Re: 5.4 hanging when used as hostap
On Mon, Mar 24, 2014 at 06:35:29PM -0700, andy wrote:
hello -
i've been using a soekris net5501 as a home gateway since early 2008,
starting w/openbsd 4.2 and upgrading through 5.4. for most of that time
it's also been serving as a wireless access point. the wireless card is
a SparkLAN WMIR-168AG WLAN 802.11a/b/g Mini PCI Module with the Ralink
RT2561T chipset (ral driver; dmesg.boot attached). the system has been
working reliably for years.
however, the box started to hang within days of upgrading to 5.4. it
stays responsive for a variable length of time after reboot, ranging
from minutes to a week or more (but not much more). and unfortunately,
it hangs w/o writing anything to syslog or serial console. i enabled
ddb.console in sysctl.conf but found it to be completely unresponsive
when hung (i successfully tested sending a break in normal operation).
The diff below backs out my changes for ral from 5.3-5.4.
Can you test this? I doubt it will have any effect but if it does
I'd very much like to know about it.
i've merged the patches from the 5.4 release errata patch list and
rebuilt the os to no effect. there was some correlation between the
hangs and increased wireless usage; i tried disabling pf and squid but
the hangs continued. eventually i ran `ifconfig ral0 down` and hooked
the laptops up to a switch. rock-solid for weeks. brought ral0 back up
and within days of usage the box hung again. i see at least one person
w/similar symptoms from 2011[1] but nothing more recent.
It is possible that your power supply is having issues.
With my net5501 I was seeing hard lockups until I upgraded to a stronger
power supply (same voltage, more ampere). The default power supply couldn't
power the board, a hard disk, and a wireless minipci card (also a ral rt2661
in my case). You seem to be using a hard disk instead of a CF card, correct?
If you like I can look up the exact specs of the power supply I'm using tonight.
Diff to back out the 'tx interrupt race' fix:
Index: rt2661.c
===
RCS file: /cvs/src/sys/dev/ic/rt2661.c,v
retrieving revision 1.68
retrieving revision 1.67
diff -u -p -r1.68 -r1.67
--- rt2661.c23 Aug 2012 10:34:25 - 1.68
+++ rt2661.c17 Jul 2012 14:43:12 - 1.67
@@ -34,7 +34,6 @@
#include sys/timeout.h
#include sys/conf.h
#include sys/device.h
-#include sys/queue.h
#include machine/bus.h
#include machine/endian.h
@@ -58,7 +57,6 @@
#include net80211/ieee80211_var.h
#include net80211/ieee80211_amrr.h
#include net80211/ieee80211_radiotap.h
-#include net80211/ieee80211_node.h
#include dev/ic/rt2661var.h
#include dev/ic/rt2661reg.h
@@ -90,8 +88,6 @@ void rt2661_reset_rx_ring(struct rt2661
void rt2661_free_rx_ring(struct rt2661_softc *,
struct rt2661_rx_ring *);
struct ieee80211_node *rt2661_node_alloc(struct ieee80211com *);
-void rt2661_node_free(struct ieee80211com *,
- struct ieee80211_node *);
intrt2661_media_change(struct ifnet *);
void rt2661_next_scan(void *);
void rt2661_iter_func(void *, struct ieee80211_node *);
@@ -119,7 +115,7 @@ uint16_trt2661_txtime(int, int, uint32_
uint8_trt2661_plcp_signal(int);
void rt2661_setup_tx_desc(struct rt2661_softc *,
struct rt2661_tx_desc *, uint32_t, uint16_t, int, int,
- const bus_dma_segment_t *, int, int, u_int8_t);
+ const bus_dma_segment_t *, int, int);
intrt2661_tx_mgt(struct rt2661_softc *, struct mbuf *,
struct ieee80211_node *);
intrt2661_tx_data(struct rt2661_softc *, struct mbuf *,
@@ -160,14 +156,6 @@ intrt2661_prepare_beacon(struct rt2661
#endif
void rt2661_enable_tsf_sync(struct rt2661_softc *);
intrt2661_get_rssi(struct rt2661_softc *, uint8_t);
-struct rt2661_amrr_node *rt2661_amrr_node_alloc(struct ieee80211com *,
- struct rt2661_node *);
-void rt2661_amrr_node_free(struct rt2661_softc *,
- struct rt2661_amrr_node *);
-void rt2661_amrr_node_free_all(struct rt2661_softc *);
-void rt2661_amrr_node_free_unused(struct rt2661_softc *);
-struct rt2661_amrr_node *rt2661_amrr_node_find(struct
rt2661_softc *,
- u_int8_t);
static const struct {
uint32_treg;
@@ -207,8 +195,6 @@ rt2661_attach(void *xsc, int id)
timeout_set(sc-amrr_to, rt2661_updatestats, sc);
timeout_set(sc-scan_to, rt2661_next_scan, sc);
- TAILQ_INIT(sc-amn);
-
/* wait for NIC to initialize */
for (ntries = 0; ntries 1000; ntries++) {
if ((val = RAL_READ(sc, RT2661_MAC_CSR0)) != 0)
@@ -358,8 +344,6 @@ rt2661_attachhook(void *xsc)
if_attach(ifp);
Building libav/ffmpeg x264 on 5.4
Greetings!
This is my first question here, please be gentle! ;)
So, as the subject line says, I am currently attempting to compile, install and
run
either the libav or ffmpeg media codec suite and then x264 on OpenBSD 5.4,
where x264
is then linked against either libav or ffmpeg. All of this on the x86_64/AMD64
architecture. x264 itself is a H.264/AVC video trans-/encoder.
So far so good.
The first big problem was the lack of a new enough GNU assembler (as/gas),
as x264
features SSSE3 inline assembly, that gas from binutils 2.15 cannot build. So I
went ahead
and compiled myself my own gas from binutils 2.24, which supposedly worked fine.
But the real bummer is what follows, and this error even shows up, if I disable
all
assembly optimizations in libav/ffmpeg as well as x264 (then it even compiles
on a stock
5.4 without my new gas 2.24, but won't run).
So, I start my video transcoding, and I get this (leaving out the [info] lines):
x264 [error]: malloc of size 8856384 failed
x264 [error]: x264_encoder_encode failed
aborted at input frame 13, output frame 0
I suspect x264 and not the libav/ffmpeg it was linked against, because 13 input
frames
were seemingly decoded by libav/ffmpeg, but not a single output frame was
encoded by x264.
Using older versions of x264/libav (up to 1 year old I tried) results in the
same problem,
only the malloc() size number is different. Like 31736 instead of the
8856384 above.
Just in case you'd wanna know, this is a sample command line like the one I
called:
x264 --preset veryslow --tune film --b-adapt 2 --b-pyramid normal -r 3 -f -2:0 --bitrate
1 --aq-mode 1 -p 1 --slow-firstpass --stats framestats.stats -t 2 --no-fast-pskip
--cqm flat input.264 -o pass1output.264
I tried compiling this with and without assembly, and with both GCC 4.2.1 as
well as GCC
4.8.1. The error is always the same.
To learn more, I thought I'd take a look at the x264 port of OpenBSD 5.4, but
found this
in its Makefile, disabling all linking against both libav and ffmpeg as well as
disabling
all assembly (likely due to the binutils/gas issue):
CONFIGURE_ARGS+=--disable-asm \
--disable-ffms \
--disable-gpac \
--disable-lavf \
--disable-swscale \
--enable-static \
--prefix=${PREFIX}
The ffms thing disables linking against ffmpeg, the lavf+swscale stuff disables
linking
against libav. asm is self-explanatory.
So the x264 port (as well as the precompiled package) are completely crippled.
Not only is
the assembly missing, costing tons of performance, but you can't even feed
anything but
raw video to it! What I need is the capability to feed stuff like H.264/AVC,
MPEG2, VC-1
videostreams etc. to x264, so I need libav or ffmpeg.
Now, the main issue is the malloc() failure here. My home-brewn gas shouldn't
be the
problem, because it happens even when compiling from pure C/C++.
My assumption would be, that maybe OpenBSDs libc implementation of malloc()
behaves in
ways that x264 can't handle properly?! I've tried looking at the x264 source
coude, but
this stuff is just way beyond me, I don't understand any of the code really.
I have so far managed to do this on NetBSD, FreeBSD/PC-BSD, MidnightBSD,
Dragonfly BSD,
OpenSolaris, Linux, Windows (CygWin and MinGW/MSYS), MacOS X and even Haiku OS
with
varying degrees of modifications to the build scripts and in one case a header
file.
It drives me crazy I can't figure this out on OpenBSD! ;) I've been trying this
for
months already!
Does anybody have any idea on how I could proceed? I am no developer.. So yeah.
If anybody
would want to take a look at the actual source code, the latest x264 version is
available
here:
ftp://ftp.videolan.org/pub/x264/snapshots/last_x264.tar.bz2
libav and ffmpeg can be obtained here (I prefer libav, but that's more a taste
thing),
one of them needs to be built first, as x264 needs to be linked against either
of the two:
http://git.libav.org/?p=libav.git;a=snapshot;h=HEAD;sf=tgz
http://www.ffmpeg.org/releases/ffmpeg-2.2.tar.bz2
The x264 trouble seems to originate in one of either x264.c,
encoder/encoder.c or
maybe common/common.c.
Sorry for this very lengthy post, but I've tried and tried and tried and failed
every
time. When I finally got past the gas problem, I was sooo happy to get it
built, only to
hit this issue at runtime.
I need help here, so if anyone has any idea on how to solve this, it'd be
greatly
appreciated!
Not sure if it would make sense to contact the x264 port maintainer, as that
person seems
to have decided not to try and get it to work properly or maybe he hit the
same brick
wall I did and couldn't get past it? Is the issue maybe really not solvable at
all?
If so, I'd like to know and understand why at least.
Well, thanks a lot for any help you might be able to provide, and for reading
my wall of
text!
--
Michael Lackner
Lehrstuhl für Informationstechnologie (CiT)
Montanuniversität Leoben
Tel.: +43 (0)3842/402-1505 | Mail:
dhclient
Hello, Dealing with the removal of user script for dhclient is ok. On the other where's the PID file of this daemon This soft answer HUP,INT.QUIT,USR1 et 2 yet i dont find a way to get the pid (listing process is dirty) Is there a reason for dhclient to not have a --pid-file or at least a default one in /var/run/dhclient.$if.pid ? best regards -- - () ascii ribbon campaign - against html e-mail /\
Re: Building libav/ffmpeg x264 on 5.4
Hi Michael,
Maybe it's not because of this, but did you try raising the data segment
size limit for your user? ulimit -a should help.
Best,
Andrei Vrincianu
On Tue, Mar 25, 2014 at 3:35 PM, Michael Lackner
michael.lack...@unileoben.ac.at wrote:
Greetings!
This is my first question here, please be gentle! ;)
So, as the subject line says, I am currently attempting to compile,
install and run
either the libav or ffmpeg media codec suite and then x264 on OpenBSD 5.4,
where x264
is then linked against either libav or ffmpeg. All of this on the
x86_64/AMD64
architecture. x264 itself is a H.264/AVC video trans-/encoder.
So far so good.
The first big problem was the lack of a new enough GNU assembler
(as/gas), as x264
features SSSE3 inline assembly, that gas from binutils 2.15 cannot build.
So I went ahead
and compiled myself my own gas from binutils 2.24, which supposedly worked
fine.
But the real bummer is what follows, and this error even shows up, if I
disable all
assembly optimizations in libav/ffmpeg as well as x264 (then it even
compiles on a stock
5.4 without my new gas 2.24, but won't run).
So, I start my video transcoding, and I get this (leaving out the [info]
lines):
x264 [error]: malloc of size 8856384 failed
x264 [error]: x264_encoder_encode failed
aborted at input frame 13, output frame 0
I suspect x264 and not the libav/ffmpeg it was linked against, because 13
input frames
were seemingly decoded by libav/ffmpeg, but not a single output frame was
encoded by x264.
Using older versions of x264/libav (up to 1 year old I tried) results in
the same problem,
only the malloc() size number is different. Like 31736 instead of the
8856384 above.
Just in case you'd wanna know, this is a sample command line like the one
I called:
x264 --preset veryslow --tune film --b-adapt 2 --b-pyramid normal -r 3 -f
-2:0 --bitrate 1 --aq-mode 1 -p 1 --slow-firstpass --stats
framestats.stats -t 2 --no-fast-pskip --cqm flat input.264 -o
pass1output.264
I tried compiling this with and without assembly, and with both GCC 4.2.1
as well as GCC
4.8.1. The error is always the same.
To learn more, I thought I'd take a look at the x264 port of OpenBSD 5.4,
but found this
in its Makefile, disabling all linking against both libav and ffmpeg as
well as disabling
all assembly (likely due to the binutils/gas issue):
CONFIGURE_ARGS+=--disable-asm \
--disable-ffms \
--disable-gpac \
--disable-lavf \
--disable-swscale \
--enable-static \
--prefix=${PREFIX}
The ffms thing disables linking against ffmpeg, the lavf+swscale stuff
disables linking
against libav. asm is self-explanatory.
So the x264 port (as well as the precompiled package) are completely
crippled. Not only is
the assembly missing, costing tons of performance, but you can't even feed
anything but
raw video to it! What I need is the capability to feed stuff like
H.264/AVC, MPEG2, VC-1
videostreams etc. to x264, so I need libav or ffmpeg.
Now, the main issue is the malloc() failure here. My home-brewn gas
shouldn't be the
problem, because it happens even when compiling from pure C/C++.
My assumption would be, that maybe OpenBSDs libc implementation of
malloc() behaves in
ways that x264 can't handle properly?! I've tried looking at the x264
source coude, but
this stuff is just way beyond me, I don't understand any of the code
really.
I have so far managed to do this on NetBSD, FreeBSD/PC-BSD, MidnightBSD,
Dragonfly BSD,
OpenSolaris, Linux, Windows (CygWin and MinGW/MSYS), MacOS X and even
Haiku OS with
varying degrees of modifications to the build scripts and in one case a
header file.
It drives me crazy I can't figure this out on OpenBSD! ;) I've been trying
this for
months already!
Does anybody have any idea on how I could proceed? I am no developer.. So
yeah. If anybody
would want to take a look at the actual source code, the latest x264
version is available
here:
ftp://ftp.videolan.org/pub/x264/snapshots/last_x264.tar.bz2
libav and ffmpeg can be obtained here (I prefer libav, but that's more a
taste thing),
one of them needs to be built first, as x264 needs to be linked against
either of the two:
http://git.libav.org/?p=libav.git;a=snapshot;h=HEAD;sf=tgz
http://www.ffmpeg.org/releases/ffmpeg-2.2.tar.bz2
The x264 trouble seems to originate in one of either x264.c,
encoder/encoder.c or
maybe common/common.c.
Sorry for this very lengthy post, but I've tried and tried and tried and
failed every
time. When I finally got past the gas problem, I was sooo happy to get it
built, only to
hit this issue at runtime.
I need help here, so if anyone has any idea on how to solve this, it'd be
greatly
appreciated!
Not sure if it would make sense to contact the x264 port maintainer, as
that person seems
to have decided not to try and get it to work properly or maybe he hit
the same brick
wall I did and couldn't get past it? Is the issue
Re: OpenBSD email provider
On Tue, Mar 18, 2014 at 04:54:55PM -0300, Giancarlo Razzolini wrote: Em 18-03-2014 15:56, Kevin Chadwick escreveu: On Tue, 18 Mar 2014 11:23:12 -0300 Giancarlo Razzolini wrote: It's perfectly useful, mail is only dropped by some idiotic systems (already mentioned) that don't understand or care about more effective anti spam methods or the little guy and when the big guys cause almost all of the spam. But there are still these idiotic systems that won't deliver you mail if you do not have reverse dns name. They deliver, but to SPAM folder. Google work like this. But e.g. yandex.ru, mail.ru work ok with no rDNS Except that if whoever has just been using that ip address is part of a botnet or likes mass mailing then you may well get blocked as you have no trackable reputation. There are things like DKIM but they aren't universally checked yet and serve more as assurance than combating spam. DKIM should be coupled with spf too. Yes, that is why I use amazon ses for the sending part. And I also use spf, of course. -- Giancarlo Razzolini GPG: 4096R/77B981BC
Re: crypto vnd(4) question
David Vasek [va...@fido.cz] wrote: On Mon, 24 Mar 2014, Chris Cappuccio wrote: Keep in mind, vnd emulates 512 byte sectors because that's the default disklabel that it uses (You probably mean a disktab, not a disklabel.) I am aware of it. As vnd(4) is a descendant of svnd(4), mixing different sector sizes should not be a big problem. I think that the danger of hidden bugs is higher in the crypto code when used together with emulated 4k-byte sectors, which is used (read: tested) much less. I will try both variants, nonethless. Thank you. Yeah you have to edit the disktab file to specify the block size to vnd. I believe this is enough: 4k:\ :se#4096: vnconfig -t 4k vnd0 /xyz/blah Then the on-disk label can take over to describe your partitions and the disk size. vnconfig won't load the partition offset/sizes anyways, you would have to use disklabel -w or disklabel -R to write the partition info to the disk.
Re: Building libav/ffmpeg x264 on 5.4
On Tue, Mar 25, 2014 at 6:35 AM, Michael Lackner michael.lack...@unileoben.ac.at wrote: So, as the subject line says, I am currently attempting to compile, install and run either the libav or ffmpeg media codec suite and then x264 on OpenBSD 5.4, where x264 is then linked against either libav or ffmpeg. All of this on the x86_64/AMD64 architecture. x264 itself is a H.264/AVC video trans-/encoder. The good news is that the ports team has already done the work to make these compile and run on OpenBSD. Take a look at http://www.openbsd.org/faq/faq15.html You should be able to just set the PKG_PATH environment variable to point to a packages ftp site for version 5.4 and do pkg_add ffmpeg, for example. If you have some reason to redo that work, then you should at least review the patches in the ports tree to see how they did the porting. Philip Guenther
Re: dhclient
On Mar 25 11:19:12, sven.falem...@gmail.com wrote: Dealing with the removal of user script for dhclient is ok. On the other where's the PID file of this daemon This soft answer HUP,INT.QUIT,USR1 et 2 yet i dont find a way to get the pid (listing process is dirty) No it's not: pkill(1), pgrep(1). Is there a reason for dhclient to not have a --pid-file or at least a default one in /var/run/dhclient.$if.pid ? Yes.
Re: {r,s}mkx entries in terminfo db missing
I solved it (for the moment) by patching st, as patching st
is something you most likely do anyways. The patch, including
a description, can be found on the suckless wiki [1].
There's just one issue left: when using the new termname
(st-git), i hit this bug [2] in perls Term::Cap.pm (e.g. when
using pkg_add), which is not fixed yet apparently. The code
for Term::Cap is now on github [3], so i could send a merge
request, but this needs testing first.
Here is the diff i'm rebuilding -current with right now:
Index: Cap.pm
===
RCS file: /cvs/src/gnu/usr.bin/perl/cpan/Term-Cap/Cap.pm,v
retrieving revision 1.1.1.2
diff -u -r1.1.1.2 Cap.pm
--- Cap.pm 25 Mar 2013 20:08:13 - 1.1.1.2
+++ Cap.pm 25 Mar 2014 17:23:41 -
@@ -275,7 +275,7 @@
my @termcap_path = termcap_path();
-unless ( @termcap_path || $entry )
+if ( !@termcap_path || !$entry )
{
# last resort--fake up a termcap from terminfo
Please test, the last time this was mentioned there was not much
progress.
Best,
Nils
[1]: http://st.suckless.org/patches/st_on_openbsd
[2]: http://marc.info/?l=openbsd-techm=131728639327606w=2
[3]: https://github.com/jonathanstowe/Term-Cap/blob/master/Cap.pm
Re: pf and nat
Em 24-03-2014 19:28, Alexander Hall escreveu: On 03/24/14 15:44, Giancarlo Razzolini wrote: Secondly, the proper way of doing nat, is using match rules, not pass. Why would you say that? 'pass ... nat-to ...' makes perfect sense to me. Using match was an easy transition from the old nat rules, but being *the* proper way, no way. /Alexander Yes, you are right. You can condense everything in one rule. But, I prefer using match, because I can decouple the nat part from the filter part. I can have a broader match rule that allow nat for the entire network and all the protocols and ports, and I can filter individually things with pass rules. One of the things that I love the most about unix is that there are many ways to do things. And you can do things the way you taste better. Sorry if I was too strong in my opinion. Cheers, -- Giancarlo Razzolini GPG: 4096R/77B981BC
Re: dhclient
On Tue, Mar 25, 2014 at 1:11 PM, Jan Stary h...@stare.cz wrote: On Mar 25 11:19:12, sven.falem...@gmail.com wrote: Dealing with the removal of user script for dhclient is ok. On the other where's the PID file of this daemon This soft answer HUP,INT.QUIT,USR1 et 2 yet i dont find a way to get the pid (listing process is dirty) No it's not: pkill(1), pgrep(1). # ps auxww | grep dhclient root 21826 0.0 0.1 776 396 ?? Is 3:33PM0:00.01 dhclient: vr0 [priv] (dhclient) _dhcp12556 0.0 0.1 928 500 ?? Is 3:33PM0:00.01 dhclient: vr0 (dhclient) # pgrep -f dhclient: vr0 [priv] (dhclient) # pgrep -f dhclient: vr0 [priv] # pgrep -f dhclient: vr0 12556 21826 Where do I kill ? (there is also a few other dhclient running) Is there a reason for dhclient to not have a --pid-file or at least a default one in /var/run/dhclient.$if.pid ? Yes. Would you please gives at least one reason ? -- - () ascii ribbon campaign - against html e-mail /\
Re: dhclient
On 2014-03-25 14:49, sven falempin wrote: # pgrep -f dhclient: vr0 [priv] (dhclient) # pgrep -f dhclient: vr0 [priv] # pgrep -f dhclient: vr0 12556 21826 Where do I kill ? (there is also a few other dhclient running) kill(1) isn't actually required. Try: # ifconfig vr0 down
Re: dhclient
On Tue, Mar 25, 2014 at 3:08 PM, Josh Grosse j...@jggimi.homeip.net wrote: On 2014-03-25 14:49, sven falempin wrote: # pgrep -f dhclient: vr0 [priv] (dhclient) # pgrep -f dhclient: vr0 [priv] # pgrep -f dhclient: vr0 12556 21826 Where do I kill ? (there is also a few other dhclient running) kill(1) isn't actually required. Try: # ifconfig vr0 down i would like to throw HUP, kill -HUP -- - () ascii ribbon campaign - against html e-mail /\
Re: FOSS Open Hardware Documentation
What was the long term fall out of this? Sell out to Oracle, etc. On 2007-08-28 Tue 10:43 AM |, Theo de Raadt wrote: On Tue, Aug 28, 2007 at 04:08:02PM +0100, Edd Barrett wrote: On 28/08/07, Craig Skinner - Sun Microsystems - Linlithgow - Scotland Yay! Action at last. Wow! This is great news. Better late than never, but damn is it late. Indeed, that is the correct sentiment regarding Sun's action here. The facts of the industry are simply this: Approximately 95% of machine parts are documented (whether they are documented well or not is a totally seperate question). Starting roughly around 1990, Sun put themselves on the path of supplying only the absolute minimum documentation for their machine parts. Meanwhile, the PC really took off, and all the documentation for PC parts has always been out there (minus a few special cases that we have had to fight for). DEC released pretty much all the documentation for the Alpha right from the start, and later a few people pressured HP to release pretty much all the HPPA documentation. That left the largest straggler in the industry: Sun. And the case is that Sun has always had the documentation in-house; because of solid engineering principles in-house they document everything, perhaps because their hardware and software groups are seperated so much. Apple also has done a poor job of documenting their hardware, but looking at the quality of their hardware (with entirely pointless divergences between models that come out 3 months apart) we can guess that maybe we don't want to see them. Finally, there are a few American chip makers that resist the status quo, like Marvell and (to a lesser degree) Broadcom. Even Intel tries to play the open game now. Then there are a handful of (increasingly irrelevant) American wireless chipset manufacturers. But in general there are fewer and fewer closed vendors. But Sun had no excuse for this behaviour in 1990, and it is incredible that only now they will try to redeem it. So I don't say bravo, but I say about time. They don't get any points from me, because they are so late. I give the most credit to Craig Skinner who started the conversation at Sun with us (he found the right place to push Sun -- right at the top), and David Gwynne for continuing the soft pressure through the last couple of months. My biggest hope is that Sun's cleanup process does not delete too much information from the pages... like descriptions of hardware bugs and the workarounds needed for best effort operation. Because we already know that some revisions of Sun hardware have brutally bad bugs that ... even sometimes cannot be worked around.
Re: dhclient
On Tue 25 Mar 2014 02:08:17 PM CDT, Josh Grosse wrote:
On 2014-03-25 14:49, sven falempin wrote:
# pgrep -f dhclient: vr0 [priv] (dhclient)
# pgrep -f dhclient: vr0 [priv]
# pgrep -f dhclient: vr0
12556
21826
Where do I kill ? (there is also a few other dhclient running)
kill(1) isn't actually required. Try:
# ifconfig vr0 down
===
TL;DR version: it doesn't appear to matter which one gets signaled with
HUP, but I can see that it might make a difference for the other
signals.
===
That actually causes problems if you need the link to stay up while
changing from DHCP to static assignment; my cable modem does weird
things every time it loses carrier on the ethernet side.
Besides, the OP was asking which process to send a signal to when he
wants to control dhclient's behaviour, not just how to terminate the
process outright.
As it happens, I agree that having a PID file is an easy solution for
daemons (like this) that fork and/or modify their proctitle. It's not
entirely clean, as there's no 100%-standard place to put pidfiles, and
they don't always get cleaned up correctly.
The flip side is that correct usage of pkill in the face of proctitle
alterations is far from obvious. Requiring that skill just to signal a
daemon seems to me about as sensible as requiring intimate knowledge of
find(1) just to view a directory listing.
(...says the guy who still occasionally kills entire systems by
accident when he tries to use pkill for anything complicated. I'm good
with find(1), thanks!)
On the other hand, dhclient hasn't written a pidfile since 2004 and a
missing pidfile is not exactly a common complaint.
There are two answers:
1. you can figure out which is the parent/child fairly easily
through ps(1) output. Admittedly this is not trivial to do in a
script, but certainly possible. Also, you only have to figure it out
once, then apply that pattern to grep. e.g. PID=$(ps alxww|awk
'$3==1 $13~/^dhclient: vr0/ {print $2}')
2. use dhcpcd from ports/packages if you want all the bells and
whistles.
Oh. Actually, now I see sven's point - there are always at least two
processes with PPID=1 and the docs don't specify which one responds to
signals. That's a bug in the manpage, at the very least.
Sven: you should probably file a bugreport against dhclient for that,
the docs should be clear. Preferably by including a patch, but even
just suggested wording that would make sense to you is good.
--
-Adam Thompson
athom...@athompso.net
Re: dhclient
On Mar 25 14:49:23, sven.falem...@gmail.com wrote: On Tue, Mar 25, 2014 at 1:11 PM, Jan Stary h...@stare.cz wrote: On Mar 25 11:19:12, sven.falem...@gmail.com wrote: Dealing with the removal of user script for dhclient is ok. On the other where's the PID file of this daemon This soft answer HUP,INT.QUIT,USR1 et 2 yet i dont find a way to get the pid (listing process is dirty) No it's not: pkill(1), pgrep(1). # ps auxww | grep dhclient root 21826 0.0 0.1 776 396 ?? Is 3:33PM0:00.01 dhclient: vr0 [priv] (dhclient) _dhcp12556 0.0 0.1 928 500 ?? Is 3:33PM0:00.01 dhclient: vr0 (dhclient) # pgrep -f dhclient: vr0 [priv] (dhclient) # pgrep -f dhclient: vr0 [priv] # pgrep -f dhclient: vr0 12556 21826 Where do I kill ? (there is also a few other dhclient running) Have you actually read pill(1)? Is there a reason for dhclient to not have a --pid-file or at least a default one in /var/run/dhclient.$if.pid ? Yes. Would you please gives at least one reason ? Think hard. Think harder.
Re: 5.4 hanging when used as hostap
On 25/03/14 11:46, Stefan Sperling wrote: It is possible that your power supply is having issues. With my net5501 I was seeing hard lockups until I upgraded to a stronger power supply (same voltage, more ampere). The default power supply couldn't power the board, a hard disk, and a wireless minipci card (also a ral rt2661 in my case). You seem to be using a hard disk instead of a CF card, correct? If you like I can look up the exact specs of the power supply I'm using tonight. I fully agree, I had exactly the same issues with my Soerkis 4801 when I used a power supply that was too weak. I upgraded mine to a supply that could do 15W, and have been happy ever since. Bernd
Re: dhclient
On Tue, Mar 25, 2014 at 1:11 PM, Jan Stary h...@stare.cz wrote: On Mar 25 11:19:12, sven.falem...@gmail.com wrote: Dealing with the removal of user script for dhclient is ok. On the other where's the PID file of this daemon This soft answer HUP,INT.QUIT,USR1 et 2 yet i dont find a way to get the pid (listing process is dirty) No it's not: pkill(1), pgrep(1). # ps auxww | grep dhclient root 21826 0.0 0.1 776 396 ?? Is 3:33PM0:00.01 dhclient: vr0 [priv] (dhclient) _dhcp12556 0.0 0.1 928 500 ?? Is 3:33PM0:00.01 dhclient: vr0 (dhclient) # pgrep -f dhclient: vr0 [priv] (dhclient) # pgrep -f dhclient: vr0 [priv] # pgrep -f dhclient: vr0 12556 21826 Where do I kill ? (there is also a few other dhclient running) All of our privsep daemons are specifically designed to accept all signals at any process, and then handle things properly. (Unless there are bugs.. hopefully not)
Re: dhclient
On Tue, Mar 25, 2014 at 3:44 PM, Adam Thompson athom...@athompso.net wrote:
On Tue 25 Mar 2014 02:08:17 PM CDT, Josh Grosse wrote:
On 2014-03-25 14:49, sven falempin wrote:
# pgrep -f dhclient: vr0 [priv] (dhclient)
# pgrep -f dhclient: vr0 [priv]
# pgrep -f dhclient: vr0
12556
21826
Where do I kill ? (there is also a few other dhclient running)
kill(1) isn't actually required. Try:
# ifconfig vr0 down
===
TL;DR version: it doesn't appear to matter which one gets signaled with HUP,
but I can see that it might make a difference for the other signals.
===
That actually causes problems if you need the link to stay up while changing
from DHCP to static assignment; my cable modem does weird things every time
it loses carrier on the ethernet side.
Besides, the OP was asking which process to send a signal to when he wants
to control dhclient's behaviour, not just how to terminate the process
outright.
As it happens, I agree that having a PID file is an easy solution for
daemons (like this) that fork and/or modify their proctitle. It's not
entirely clean, as there's no 100%-standard place to put pidfiles, and they
don't always get cleaned up correctly.
well openBSD is so neat it provides a nice call:
http://www.openbsd.org/cgi-bin/man.cgi?query=pidfileapropos=0sektion=0manpath=OpenBSD+Currentarch=i386format=html
but i failed to patch :'( this make the dhclient quit instead of
going background, the fact there is two process may also explain why
there is no pidfile. One is root he other dropped privilege, all of
this is just giving me a headache at the moment.
Index: dhclient.c
===
RCS file: /cvs/src/sbin/dhclient/dhclient.c,v
retrieving revision 1.260
diff -u -p -r1.260 dhclient.c
--- dhclient.c 15 Jul 2013 14:03:01 - 1.260
+++ dhclient.c 25 Mar 2014 19:50:10 -
@@ -61,6 +61,7 @@
#include poll.h
#include pwd.h
#include resolv.h
+#include util.h
#defineCLIENT_PATH PATH=/usr/bin:/usr/sbin:/bin:/sbin
#define DEFAULT_LEASE_TIME 43200 /* 12 hours. */
@@ -1742,6 +1743,7 @@ void
go_daemon(void)
{
static int state = 0;
+char* pidname = NULL;
if (no_daemon || state)
return;
@@ -1762,6 +1764,12 @@ go_daemon(void)
close(nullfd);
nullfd = -1;
}
+
+if (!asprintf(pidname, dhclient.%s, ifi-name))
+error(pidname);
+if (pidfile(pidname))
+error(pidfile);
+free(pidname);
/* Catch stuff that might be trying to terminate the program. */
signal(SIGHUP, sighdlr);
The flip side is that correct usage of pkill in the face of proctitle
alterations is far from obvious. Requiring that skill just to signal a
daemon seems to me about as sensible as requiring intimate knowledge of
find(1) just to view a directory listing.
(...says the guy who still occasionally kills entire systems by accident
when he tries to use pkill for anything complicated. I'm good with find(1),
thanks!)
On the other hand, dhclient hasn't written a pidfile since 2004 and a
missing pidfile is not exactly a common complaint.
There are two answers:
1. you can figure out which is the parent/child fairly easily through
ps(1) output. Admittedly this is not trivial to do in a script, but
certainly possible. Also, you only have to figure it out once, then apply
that pattern to grep. e.g. PID=$(ps alxww|awk '$3==1 $13~/^dhclient:
vr0/ {print $2}')
2. use dhcpcd from ports/packages if you want all the bells and whistles.
Oh. Actually, now I see sven's point - there are always at least two
processes with PPID=1 and the docs don't specify which one responds to
signals. That's a bug in the manpage, at the very least.
Sven: you should probably file a bugreport against dhclient for that, the
docs should be clear. Preferably by including a patch, but even just
suggested wording that would make sense to you is good.
--
-Adam Thompson
athom...@athompso.net
--
-
() ascii ribbon campaign - against html e-mail
/\
Re: dhclient
well openBSD is so neat it provides a nice call: http://www.openbsd.org/cgi-bin/man.cgi?query=pidfileapropos=0sektion=0manpath=OpenBSD+Currentarch=i386format=html but i failed to patch :'( this make the dhclient quit instead of going background, the fact there is two process may also explain why there is no pidfile. One is root he other dropped privilege, all of this is just giving me a headache at the moment. pidfile() is a dangerous subsystem. The files stay around long after the process has died. There is no interlock. If you signal a process lists in a pidfile, who knows what you are sending a signal to. Since the signals are often termination related, this can have dangerous effects. We don't add more pidfile use, we actually remove them where we can. This mechanism has applicability in some situations, but in the big picture it is sloppy practice.
Re: dhclient
On Tue 25 Mar 2014 03:02:19 PM CDT, Theo de Raadt wrote: [...] the fact there is two process may also explain why there is no pidfile. One is root he other dropped privilege, all of this is just giving me a headache at the moment. Based on 5.4-RELEASE, then, since I agree the situation is confusing: --- dhclient.8 Sun Jul 21 11:43:44 2013 +++ dhclient.8.new Tue Mar 25 15:07:52 2014 @@ -255,7 +255,9 @@ .Sh SIGNALS While running, .Nm -reacts to a few different signals: +uses a privilege-separation model, so there will be two processes (one with +[priv] in its process title and one without), +either of which will react to a few different signals: .Bl -tag -width USR1, USR2XXX .It Dv HUP On receiving (I can't find an mdoc(7) equivalent to PRE for formatting the [priv] token. Suggestions welcome.) -- -Adam Thompson athom...@athompso.net
Re: Building libav/ffmpeg x264 on 5.4
On 2014-03-25, Michael Lackner michael.lack...@unileoben.ac.at wrote: The first big problem was the lack of a new enough GNU assembler (as/gas), as x264 features SSSE3 inline assembly, that gas from binutils 2.15 cannot build. So I went ahead and compiled myself my own gas from binutils 2.24, which supposedly worked fine. OpenBSD -current (and the already-tagged but not-yet-released 5.5) builds x264 with Clang's assembler to enable the assembly code. To learn more, I thought I'd take a look at the x264 port of OpenBSD 5.4, but found this in its Makefile, disabling all linking against both libav and ffmpeg as well as disabling all assembly (likely due to the binutils/gas issue): The FFmpeg port is built against x264, so building x264 against FFmpeg would give a circular build dependency. It could potentially be done differently by adding a bootstrap flavour of the x264 port, but that's a lot of complication for something which I don't recall seeing any requests on-list for before.
Oerrs on vlan interfaces
I'm trying to track down the source of what is causing output errors on vlan interfaces for 2 separate physical systems. For example when looking at netstat between 2 different runs the values are always incrementing: # netstat -s -f inet -I vlan800 echo sleep 5 netstat -s -f inet -I vlan800 Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Colls vlan800 1500 Link 00:1c:23:e1:cf:48 187689428 0 148043392 262767 0 Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Colls vlan800 1500 Link 00:1c:23:e1:cf:48 187691085 0 148044677 262770 0 Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Colls vlan200 1500 Link 00:1c:23:e1:cf:48 18139570 0 18645286 40217 0 vlan300 1500 Link 00:1c:23:e1:cf:48 2562460 0 3460373 2720 0 vlan500 1500 Link 00:1c:23:e1:cf:48 112356993 0 141163651 158443 0 The hardware is 2 Dell PowerEdge 860 servers using the onboard Broadcom BCM5721 NICs. Each system is attached to a different Procurve switch with the 2 onboard NICs in a LACP trunk configuration. The 2 systems are setup in an HA configuration using carp/pf that runs very well. When looking for any type of issues on the switch ports they come back clean for all uplinks to the Dells: Errors (Since boot or last clear) : FCS Rx : 0 Drops Rx : 0 Alignment Rx : 0 Collisions Tx : 0 Runts Rx : 0 Late Colln Tx : 0 Giants Rx : 0 Excessive Colln : 0 Total Rx Errors : 0 Deferred Tx : 0 The same behavior is mimicked on both systems as the counters start incrementing when failing over the carp interfaces between the peers. Another oddity that is the physical interfaces show no output errors just input errors: # netstat -ni Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Colls bge0 1500 Link 00:1c:23:e1:cf:48 284587839 103261 120699706 0 0 bge0 1500 fe80::%bge0 fe80::21c:23ff:fe 284587839 103261 120699706 0 0 bge1 1500 Link 00:1c:23:e1:cf:48 61755734 193 233219963 0 0 bge1 1500 fe80::%bge1 fe80::21c:23ff:fe 61755734 193 233219963 0 0 ... trunk0 1500 Link 00:1c:23:e1:cf:48 346220631 0 353798619 167 0 trunk0 1500 192.168.201 192.168.201.23 346220631 0 353798619 167 0 trunk0 1500 fe80::%trun fe80::21c:23ff:fe 346220631 0 353798619 167 0 ... Any advice would be appreciated on what else to look for that is causing these errors. Regards, Matt Additional info if it helps: # netstat -sn ip: 461996032 total packets received 21 bad header checksums 0 with size smaller than minimum 0 with data size data length 0 with header length data size 0 with data length header length 0 with bad options 0 with incorrect version number 0 fragments received 0 fragments dropped (duplicates or out of space) 0 malformed fragments dropped 0 fragments dropped after timeout 0 packets reassembled ok 136026433 packets for this host 0 packets for unknown/unsupported protocol 324667376 packets forwarded 550005 packets not forwardable 0 redirects sent 11050218 packets sent from this host 192 packets sent with fabricated ip header 0 output packets dropped due to no bufs, etc. 0 output packets discarded due to no route 187636 output datagrams fragmented 187734 fragments created 17589 datagrams that can't be fragmented 0 fragment floods 0 packets with ip length max ip packet size 0 tunneling packets that can't find gif 0 datagrams with bad address in header 347724405 input datagrams checksum-processed by hardware 356771381 output datagrams checksum-processed by hardware 410308 multicast packets which we don't join icmp: 1171928 calls to icmp_error 0 errors not generated because old message was icmp Output packet histogram: echo reply: 295802 destination unreachable: 1143260 time exceeded: 4 0 messages with bad code fields 0 messages minimum length 46 bad checksums 4 messages with bad length 64 echo requests to broadcast/multicast rejected Input packet histogram: echo reply: 22496 destination unreachable: 22342 source quench: 17 routing redirect: 172 echo: 295866 time exceeded: 1172 295802 message responses generated igmp: 0 messages received
Re: dhclient
Hi Adam, Adam Thompson wrote on Tue, Mar 25, 2014 at 03:11:49PM -0500: .Sh SIGNALS While running, .Nm uses a privilege-separation model, so there will be two processes (one with [priv] in its process title and one without), either of which will react to a few different signals: (I can't find an mdoc(7) equivalent to PRE The mdoc(7) equivalent of pre is .Bd -literal However, you cannot use that here because pre (and .Bd) are for block displays, while you want an in-line element. In HTML, you might use samp. In mdoc(7), there is no semantic markup for program output, so you'd fall back to physical formatting, probably with .Li for formatting the [priv] token. Suggestions welcome.) In mdoc(7), you could also choose to not mark it up at all. I'm not commenting on your (mangled) diff itself. It looks a bit like documenting a general principle in a special place, but i'm not sure what to think. Yours, Ingo
DTMF tones over IP
Hello, Is there a way to generate DTMF tones using the tools in base? I am trying to open a live audio path over IP from one node to another. The audio path is fed into a controlling device which interfaces with a VHF radio. In order to key-up the radio, the controlling device needs to see a DTMF code (1 to key, 0 to unkey). Any audio sent to the device between keying and unkeying, is sent to the radio and over air. I'm guessing an ssh-tunnel will server as the path, just not sure which framework can be used to record and play audio, let alone generate DTMF. Any pointers? -- Byron Klippert byronklipp...@ml1.net c. 867-336-1306
Re: DTMF tones over IP
Not sure about playing remotely, but if you add the sox package, you get tools to generate files or directly to audio out. The following play the tones to your audio output: DTMF 1: play -n synth 0.5 sine 697 sine 1209 channels 1 DTMF 0: play -n synth 0.5 sine 941 sine 1336 channels 1 On Tue, Mar 25, 2014 at 3:24 PM, Byron Klippert byronklipp...@ml1.net wrote: Hello, Is there a way to generate DTMF tones using the tools in base? I am trying to open a live audio path over IP from one node to another. The audio path is fed into a controlling device which interfaces with a VHF radio. In order to key-up the radio, the controlling device needs to see a DTMF code (1 to key, 0 to unkey). Any audio sent to the device between keying and unkeying, is sent to the radio and over air. I'm guessing an ssh-tunnel will server as the path, just not sure which framework can be used to record and play audio, let alone generate DTMF. Any pointers? -- Byron Klippert byronklipp...@ml1.net c. 867-336-1306
upgrades no longer allow ftp for sets
Since the 23 March snapshot I've no longer been able to get the sets via ftp during upgrade, is this intentional or is this an error on my end? This worked on the snapshot form 19 March and earlier using the amd64-snapshot bsd.rd indirectly from ftp3.usa.openbsd.org (Local ftp mirror with rsync daily pull from ftp3).
Re: upgrades no longer allow ftp for sets
On Tue, Mar 25, 2014, at 06:58 PM, n...@leviacomm.net wrote: Since the 23 March snapshot I've no longer been able to get the sets via ftp during upgrade, is this intentional or is this an error on my end? This worked on the snapshot form 19 March and earlier using the amd64-snapshot bsd.rd indirectly from ftp3.usa.openbsd.org (Local ftp mirror with rsync daily pull from ftp3). I would guess it's intentional as there's no real reason to pick FTP over HTTP anymore. -- Shawn K. Quinn skqu...@rushpost.com
Re: upgrades no longer allow ftp for sets
Since the 23 March snapshot I've no longer been able to get the sets via ftp during upgrade, is this intentional or is this an error on my end? This worked on the snapshot form 19 March and earlier using the amd64-snapshot bsd.rd indirectly from ftp3.usa.openbsd.org (Local ftp mirror with rsync daily pull from ftp3). The 5.5 release will support FTP releases, but after that we are disabling FTP and thus pushing people to use HTTP installs. In this day and age, it is somewhat irresponsible for us to put people into a situation where they might install new FTP servers on the internet. We've known it is a dangerous protocol for over 20 years. Use a HTTP server to serve the sets, please.
Re: upgrades no longer allow ftp for sets
Thanks and I understand the reasoning. The current ftp server won't be able to do http and use of siteXX files prevents using an external source. Will nfs be supported or am I going to need more hardware? Original Message Subject: Re: upgrades no longer allow ftp for sets From: Theo de Raadt dera...@cvs.openbsd.org Date: Tue, March 25, 2014 5:34 pm To: misc@openbsd.org, n...@leviacomm.net Since the 23 March snapshot I've no longer been able to get the sets via ftp during upgrade, is this intentional or is this an error on my end? This worked on the snapshot form 19 March and earlier using the amd64-snapshot bsd.rd indirectly from ftp3.usa.openbsd.org (Local ftp mirror with rsync daily pull from ftp3). The 5.5 release will support FTP releases, but after that we are disabling FTP and thus pushing people to use HTTP installs. In this day and age, it is somewhat irresponsible for us to put people into a situation where they might install new FTP servers on the internet. We've known it is a dangerous protocol for over 20 years. Use a HTTP server to serve the sets, please.
Re: upgrades no longer allow ftp for sets
On Tue, Mar 25, 2014, at 08:10 PM, n...@leviacomm.net wrote: Thanks and I understand the reasoning. The current ftp server won't be able to do http and use of siteXX files prevents using an external source. Will nfs be supported or am I going to need more hardware? What is preventing you from using, say, a USB thumb drive as the install media? Also note you can install from multiple sources (http for everything else, then a local disk for the siteXX files). -- Shawn K. Quinn skqu...@rushpost.com
Re: upgrades no longer allow ftp for sets
On Tue, Mar 25, 2014, at 08:10 PM, n...@leviacomm.net wrote: Thanks and I understand the reasoning. The current ftp server won't be able to do http and use of siteXX files prevents using an external source. Will nfs be supported or am I going to need more hardware? What is preventing you from using, say, a USB thumb drive as the install media? Also note you can install from multiple sources (http for everything else, then a local disk for the siteXX files). I also have some large concerns about how the siteXX files interact with the new signing mechanism. Obviously, they are not signed. But furthermore, it is inconvenient how they affect the install code, by following the same path. I would like to see this improve, but don't think anyone has a clear idea yet.
Re: upgrades no longer allow ftp for sets
On Wed, Mar 26, 2014 at 2:10 AM, n...@leviacomm.net wrote: Thanks and I understand the reasoning. The current ftp server won't be able to do http and use of siteXX files prevents using an external source. Will nfs be supported or am I going to need more hardware? For more than 7 years, I have been using installation file sets as well as siteXX files on USB thumbdrives for installing and testing snapshots. So you don't need a lot of extra hardware at all. Adriaan
Re: upgrades no longer allow ftp for sets
Thanks and I understand the reasoning. The current ftp server won't be able to do http and use of siteXX files prevents using an external source. Will nfs be supported or am I going to need more hardware? For more than 7 years, I have been using installation file sets as well as siteXX files on USB thumbdrives for installing and testing snapshots. So you don't need a lot of extra hardware at all. Another reason for doing this is so that in the future we can gut the fetching program to not have the totally enormous FTP code path.
Re: upgrades no longer allow ftp for sets
I am upgrading hundreds of boxes a day with only have serial access to them. Installing from an external source would bring any server I use to its knees (I end up using 4-5 Gbps of bandwidth during upgrades. I assume packages will still be able to grabbed over ftp, although I suspect I should be planning for that to go away too at some point. Original Message Subject: Re: upgrades no longer allow ftp for sets From: Shawn K. Quinn skqu...@rushpost.com Date: Tue, March 25, 2014 6:38 pm To: misc@openbsd.org On Tue, Mar 25, 2014, at 08:10 PM, n...@leviacomm.net wrote: Thanks and I understand the reasoning. The current ftp server won't be able to do http and use of siteXX files prevents using an external source. Will nfs be supported or am I going to need more hardware? What is preventing you from using, say, a USB thumb drive as the install media? Also note you can install from multiple sources (http for everything else, then a local disk for the siteXX files). -- Shawn K. Quinn skqu...@rushpost.com
Re: upgrades no longer allow ftp for sets
Whatever you're doing, it is wrong. You think you cannot properly filter HTTP. But you can properly filter FTP. Right. Sre. Keep believing that. I am upgrading hundreds of boxes a day with only have serial access to them. Installing from an external source would bring any server I use to its knees (I end up using 4-5 Gbps of bandwidth during upgrades. I assume packages will still be able to grabbed over ftp, although I suspect I should be planning for that to go away too at some point. Original Message Subject: Re: upgrades no longer allow ftp for sets From: Shawn K. Quinn skqu...@rushpost.com Date: Tue, March 25, 2014 6:38 pm To: misc@openbsd.org On Tue, Mar 25, 2014, at 08:10 PM, n...@leviacomm.net wrote: Thanks and I understand the reasoning. The current ftp server won't be able to do http and use of siteXX files prevents using an external source. Will nfs be supported or am I going to need more hardware? What is preventing you from using, say, a USB thumb drive as the install media? Also note you can install from multiple sources (http for everything else, then a local disk for the siteXX files). -- Shawn K. Quinn skqu...@rushpost.com
Openbsd Routing/NAT Internet Issues
Hello to all, I had try to set up openbsd as home router but eventually it fail to function properly. External Interface (vr0) 192.168.1.2 255.255.255.0 none Internal Interface (rl0) 172.16.10.1 255.255.255.0 none Wireless Interface (ath0) 192.168.5.1 255.255.255.0 none External interface connects to a modem with ip address of 192.168.1.254. *Routing Table* (route show | more) Destination Gateway Flags Interface default 175.13.8.127.254 UGS tun0 175.130.127.254 175.135.116.213 (PPPOE IP address) UH tun0 loopback loopback UGRS lo0 loopback loopback UH lo0 172.16.10/24 link#2 UC rl0 172.16.10.3 inet6 UHLC rl0 192.168.1/24 link#1 UC vr0 192.168.5/24 link#3 UC ath0 My wireless interface light is keep on blinking rather stay on stable mode. *Packet Filter Rules* (pfcrt -sr) nat on vr0 from !(vr0) to any - (vr0) round-robin scrub on vr0 all no-df fragment reassemble scrub on vr0 all reassemble tcp block drop in log on vr0 all pass out quick on ath0/rl0 keep state. Problem: I can ping Google DNS(8.8.8.8) from openbsd machine. or browsing internet. I cannot ping Google DNS(8.8.8.8) from LAN PC. I can ping my external modem(192.168.1.254) which return echo reply. I have no idea why ping the modem does reply but ping external network with no reply. Please help. -- Linux
Re: upgrades no longer allow ftp for sets
On Tue, Mar 25, 2014 at 18:10, n...@leviacomm.net wrote: Thanks and I understand the reasoning. The current ftp server won't be able to do http and use of siteXX files prevents using an external source. Will nfs be supported or am I going to need more hardware? nfs is supported, though finding a way to install an http server on your ftp server is still the better option.
Anyone tried new PC-Engines apu1c board yet?
I've been thinking about upgrading my Alix 2d3 board to the new apu1c/apu1c4 (http://www.pcengines.ch/apu1c.htm) - I think there was some availability a few weeks ago but now the site says they are out of stock until April 5, 2014 (http://www.pcengines.ch/order1.php?c=4). Anyway, I was wondering if anyone has had a chance to test one of these boards yet with OpenBSD? If so, what are your thoughts? Any issues with the Realtek RTL8111E? Thanks in advance. -- Chess Griffin
Re: Anyone tried new PC-Engines apu1c board yet?
I've been thinking about upgrading my Alix 2d3 board to the new apu1c/apu1c4 (http://www.pcengines.ch/apu1c.htm) - I think there was some availability a few weeks ago but now the site says they are out of stock until April 5, 2014 (http://www.pcengines.ch/order1.php?c=4). Anyway, I was wondering if anyone has had a chance to test one of these boards yet with OpenBSD? If so, what are your thoughts? Any issues with the Realtek RTL8111E? Some of these machines are in the group. They are nice machines.. we've been able to play with them using some workarounds. The BIOS is not ready yet, it has a variety of problems. We are working with PC-Engines to get them fixed. It isn't just OpenBSD that is affected. I don't think it will take long. A new BIOS can be flashed, but the process is a little bit annoying in this state (once OpenBSD works natively, it will be easier to load the tools and do it). So perhaps wait just a little while longer, so that you can get a machine with the right BIOS.
