from:"Sebastian Reitenbach"

Hi,

I switched my desktop from Linux to OpenBSD. My SB audigy card doesn't seem to 
be supported very well. I can move the sliders in the mixers, but the volume 
stays the same. But after reading Bugs section in the emu man page, I guess 
that is what I see there. Therefore I took the onboard card, and sound 
started to work, but only stereo. Is 5.1 sound working well with the cmpci 
based cards? I thought about buying one of those cheap cards.

The second thing is, I have a monitor, with a resolution 1920x1200. 
With the nvidia geforce based card I had in the agp slot, and nv driver in 
xorg, the best resolution that I got was 1280x1024. I removed that card, and 
took the onboard graphics card, its an intel 82865G. I also installed the 
915resolution port, and did define a resolution for 1920x1200, but that did 
not helped, xorgconfig did not catched this as a valid resolution that the 
card supports. I added the resolution manually to the xorg.conf file, but 
xorg refused to use it. The best resolution it was using now is: 1600x1200, 
better than with the nvidia card, but not yet the native resolution of the 
monitor.
I wonder whether the intel or nv driver are able to provide me the native 
resolution of the monitor?
Otherwise, anybody can recommend me a card that will be able to run my monitor 
in the high resolution?


cheers
Sebastian

Re: sound and graphics card recommendations?

On Tuesday 13 January 2009 14:38:01 Jacob Meuser wrote:
> On Tue, Jan 13, 2009 at 01:45:28PM +0100, Sebastian Reitenbach wrote:
> > Hi,
> >
> > I switched my desktop from Linux to OpenBSD. My SB audigy card doesn't
> > seem to be supported very well. I can move the sliders in the mixers, but
> > the volume stays the same. But after reading Bugs section in the emu man
> > page, I guess that is what I see there. Therefore I took the onboard
> > card, and sound started to work, but only stereo. Is 5.1 sound working
> > well with the cmpci based cards? I thought about buying one of those
> > cheap cards.
>
> what's your onboard card?
the card I use right now is a stereo only eap(4) based one.

>
> the cmpci support up to 7.1 channels.
sounds sufficient to me ;)

thanks 
Sebastian

Re: sound and graphics card recommendations?

On Tuesday 13 January 2009 17:39:12 Owain Ainsworth wrote:
> On Tue, Jan 13, 2009 at 01:45:28PM +0100, Sebastian Reitenbach wrote:
> > Hi,
> >
> > I switched my desktop from Linux to OpenBSD. My SB audigy card doesn't
> > seem to
> >
> > The second thing is, I have a monitor, with a resolution 1920x1200.
> > With the nvidia geforce based card I had in the agp slot, and nv driver
> > in xorg, the best resolution that I got was 1280x1024. I removed that
> > card, and took the onboard graphics card, its an intel 82865G. I also
> > installed the 915resolution port, and did define a resolution for
> > 1920x1200, but that did not helped, xorgconfig did not catched this as a
> > valid resolution that the card supports. I added the resolution manually
> > to the xorg.conf file, but xorg refused to use it. The best resolution it
> > was using now is: 1600x1200, better than with the nvidia card, but not
> > yet the native resolution of the monitor.
> > I wonder whether the intel or nv driver are able to provide me the native
> > resolution of the monitor?
> > Otherwise, anybody can recommend me a card that will be able to run my
> > monitor in the high resolution?
>
> Intel. or ATI (amd).
>
> Repeat after me:
> "I will not buy Nvidia"
> "I will not buy Nvidia"
> "I will not buy Nvidia"
> "I will not buy Nvidia"
>
> Trust me on this one,
>
> -0-
OK, then I'll take a look for Intel or ATI, thanks.
IIRC, you were working on 3D accellerartion, Any special chipset 
recommendation in case I want to enable 3D?

thanks
Sebastian

Re: sound and graphics card recommendations?

On Tuesday 13 January 2009 04:34:36 pm Stuart Henderson wrote:
> Try intel with xrandr to set the resolution.

I added a 1920x1200 mode in the xorg.conf file for the various color depths, 
and also added that resolution with 915resolution to the bios of the card. 
However, xrandr only offers 1600x1200 as the maximum resolution.

Sebastian


>
> On 2009-01-13, Sebastian Reitenbach  wrote:
> > Hi,
> >
> > I switched my desktop from Linux to OpenBSD. My SB audigy card doesn't
> > seem to be supported very well. I can move the sliders in the mixers, but
> > the volume stays the same. But after reading Bugs section in the emu man
> > page, I guess that is what I see there. Therefore I took the onboard
> > card, and sound started to work, but only stereo. Is 5.1 sound working
> > well with the cmpci based cards? I thought about buying one of those
> > cheap cards.
> >
> > The second thing is, I have a monitor, with a resolution 1920x1200.
> > With the nvidia geforce based card I had in the agp slot, and nv driver
> > in xorg, the best resolution that I got was 1280x1024. I removed that
> > card, and took the onboard graphics card, its an intel 82865G. I also
> > installed the 915resolution port, and did define a resolution for
> > 1920x1200, but that did not helped, xorgconfig did not catched this as a
> > valid resolution that the card supports. I added the resolution manually
> > to the xorg.conf file, but xorg refused to use it. The best resolution it
> > was using now is: 1600x1200, better than with the nvidia card, but not
> > yet the native resolution of the monitor.
> > I wonder whether the intel or nv driver are able to provide me the native
> > resolution of the monitor?
> > Otherwise, anybody can recommend me a card that will be able to run my
> > monitor in the high resolution?
> >
> >
> > cheers
> > Sebastian

Re: Qsynth midi latency not low enough... what to do?

2018-12-01 Thread Sebastian Reitenbach

Am Samstag, Dezember 01, 2018 20:19 CET, "Adam Thompson" 
 schrieb:

> PROBLEM STATEMENT: driving FluidSynth from a MIDI controller produces ~1/4sec 
> delay between keypress and sound.
>
> NARRATIVE:
>
> I finally got Qsynth working under Xfce (it freezes X under twm!) so I can 
> control fluidsynth in a reasonably-obvious way... but I am now experiencing 
> substantial latency.

good you like it, I added it only a few months ago to the ports/packages. I 
haven't heard of any trouble with it, I use it
under Windowmaker, where it's just flawlessly.

> The good news is that it feels just like playing an old pneumatic or tracker 
> organ, where there’s a ~0.25sec delay between keypress and sound.
> The bad news is that it feels just like playing an old pneumatic or tracker 
> organ...
>
> I’m not a good enough musician to handle the roughly quarter-second delay 
> when playing live.  I know from many musicians that near-zero-latency from 
> MIDI softsynths (even when using soundfonts) is possible... although no-one I 
> know of uses OpenBSD.
>
> Is sndio(4) suitable for real-time(-ish) performance?  Or do I need a (OS) 
> platform that does ASIO or JACK?  (I mostly play by ear so I'm targeting 
> <<0.1sec latency.)
>
> If sndio core or umidi(4) support isn’t the problem, the only obvious thing 
> to blame is FluidSynth... but the CPU in this laptop should be more than up 
> to the task, and – again – I know this particular piece of software handles 
> low-latency live performance in other configurations (i.e. on Linux, using 
> JACK).
> I don't suspect Qsynth at the moment, as it only controls how fluidsynth 
> launches, it doesn't put itself in the data path.
>
> Unsurprisingly, I’ve been unable to find any useful information on running 
> this kind of setup under OpenBSD.  But as mentioned before, I’m trying to 
> avoid the (to me) insanity that is JACK.

I also use qsynth/fluidsynth, and I use midish to connect my USB midi 
controller (FAME Digital KC61 I got el-cheapo on ebay)
and I also experienced bad delays as what you describe, or even worse.
However, when using fluidsynth/midish without qsynth, I see the same.
Additionally what I see, my controller has touch sensitive keys, and I can also 
configure the curve of sensitivity of the keys
in the controller, but it doesn't matter how hard I hit the keys, it's nearly 
impossible to get the velocity to 127.
I'm more or less absolute beginner with MIDI, and also can't compare to other 
OS or setups, so first was looking in the manual
of that midi controller, only where I can change curve of velocity.
So then I checked midish, after some experiments, I found when I disable the 
touch sensitivity, I can play
easily.
Also, when I disable the touch sensitivity in midish, the delay between 
keypress and sound got down considerably.
That's what I have in my .midishrc:

# Disable touch sensitivity of keys
fvcurve {} (63)

If there is a better way to get the delay down I'm all ears, also at some point 
in time, I'd love to get touch sensitivity
of the keys back ;)

cheers,
Sebastian
>
> Dmesg follows, just in case anyone spots anything useful in there…
>
> Hardware setup, broadly:
> * Dell Latitude E6430 laptop
>   - booting in EFI mode to work around a weird bootloader bug
> * onboard azalia(4) audio (for now) using onboard speakers (for now)
> * Roland A500PRO MIDI controller, connected via USB
> * M-audio Uno USB-MIDI, nothing connected to it yet
> * No-name USB 5.1ch Audio DAC from Amazon, nothing connected to it yet
>   - (leaving the M-audio umidi and the "ABC" uaudio devices disconnected 
> makes no difference)
>
>
> Advice / pointers gratefully accepted, including pointers to documentation or 
> threads I may have missed.
>
> Thanks,
> -Adam
>
>
> Dmesg << __EOF__ (so to speak)
>  OpenBSD 6.4 (GENERIC.MP) #1: Mon Nov 26 10:18:14 CET 2018
> 
> r...@syspatch-64-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 8471482368 (8079MB)
> avail mem = 8205459456 (7825MB)
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xebf40 (101 entries)
> bios0: vendor Dell Inc. version "A21" date 05/08/2017
> bios0: Dell Inc. Latitude E6430
> acpi0 at bios0: rev 2
> acpi0: sleep states S0 S3 S4 S5
> acpi0: tables DSDT FACP APIC FPDT MCFG SSDT HPET SSDT SSDT SSDT ASF! SLIC 
> BGRT SSDT
> acpi0: wakeup devices P0P1(S4) USB1(S3) USB2(S3) USB3(S3) USB5(S3) USB6(S3) 
> USB7(S3) PXSX(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP05(S4) PXSX(S4) 
> RP06(S4) PXSX(S4) [...]
> acpitimer0 at acpi0: 3579545 Hz, 24 bits
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: Intel(R) Core(TM) i7-3632QM CPU @ 2.20GHz, 2193.29 MHz, 06-3a-09
> cpu0: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT

Re: Qsynth midi latency not low enough... what to do?

2018-12-03 Thread Sebastian Reitenbach

Am Sonntag, Dezember 02, 2018 10:17 CET, Alexandre Ratchov  
schrieb:

> On Sat, Dec 01, 2018 at 01:19:00PM -0600, Adam Thompson wrote:
> > PROBLEM STATEMENT: driving FluidSynth from a MIDI controller produces 
> > ~1/4sec delay between keypress and sound.
> >
> [...]
>
> > Is sndio(4) suitable for real-time(-ish) performance?  Or do I need
> > a (OS) platform that does ASIO or JACK?  (I mostly play by ear so
> > I'm targeting <<0.1sec latency.)
>
> Yes, sndiod is usable (actually designed for) low-latency usage. You
> need to change the sndiod buffer size to whatever your system can
> handle (depends on CPU, audio interface). I'd recommend to set in
> /etc/rc.conf.local
>
> sndiod_flags=-z240
>
> Let us know how it works. If it works, you could try -z120, that's
> what I use on my machines.

-z120 is a bit too much for my box, but -z240 does the trick for me.

Thanks,
Sebastian

>
> -z240 sets the block size to 240 samples, at 48000Hz sample frequency,
> this corresponds to 48000Hz / 240 = 5ms block. The total end-to-end
> latency is typically 3 blocks, so I'd get 5ms * 3 = 15ms.
>
> FWIW, for music, you shouldn't exceed few tenths of ms of latency.
>
> >
> > Dmesg follows, just in case anyone spots anything useful in there…
> >
> > Hardware setup, broadly:
> > * Dell Latitude E6430 laptop
> >   - booting in EFI mode to work around a weird bootloader bug
> > * onboard azalia(4) audio (for now) using onboard speakers (for now)
> > * Roland A500PRO MIDI controller, connected via USB
> > * M-audio Uno USB-MIDI, nothing connected to it yet
> > * No-name USB 5.1ch Audio DAC from Amazon, nothing connected to it yet
> >   - (leaving the M-audio umidi and the "ABC" uaudio devices disconnected 
> > makes no difference)
> >
>
> The "ABC" USB devices are unlikely to work with small blocks, but
> there are fixes comming soon (hopefully).
>

Re: SPA112 VoIP with pf and NAT - States keeps open on address change

2019-02-06 Thread Sebastian Reitenbach

Am Mittwoch, Februar 06, 2019 10:57 CET, jum...@yahoo.de schrieb:

> Hello,
> I have a Cisco SPA112 VoIP to connect my analog phone to my provider SIP 
> system. Recently I replaced my Linux based (Fritzbox) with a OpenBSD 6.4 
> firewall. The firewall is connected to a vDSL modem and performs NAT for 
> outgoing IPv4 connection. The connection to the SIP server from the SPA112 is 
> a IPv4 with NAT via UDP port 5060. The connection works and I can see the NAT 
> in the state table. I have configured NAT-Keepalive on the SPA112 to keep the 
> state open. After 24 hours my provider terminate my connection and after 
> established a new connection the firewall has a new public IPv4 address. 
> After this change the SPA112 can't longer communicate to the SIP server 
> because it's still using the old state with the old public IPv4 address. If I 
> deleted the state manually on the firewall the force the SPA112 to register 
> again it works. The SPA112 has also an automatism to re-register after 60 
> minutes. But without deleting the state the SPA112 will use again the old 
> state/connection.
> From my point of view the SPA112 should use a new connection for the 
> re-register or at least a new connection, if it detects the lost of the 
> previous registration. But this problem doesn't exist with the old Linux 
> based firewall. I can also see a lot of other NAT entries in the state table 
> with the old public IPv4 address. Is there a feature of pf to delete all NAT 
> entries with the no longer existing public IPv4 on a address change? 
> Best Regards,Patrick

some lines of pf.conf would be helpful. Do you have parentheses around your 
interface name in the  nat-to rule, like nat-to ($ext_if)
that should update the rules when addresses change, but I don't think that will 
touch active states.
However, SIP and UDP might be problematic, since states are consulted first, 
before the rules are traversed. Since UDP is stateless, PF only seems 
sending/receiving IP and port, but with SIP the sending port always might be 
5060 as well, so it may match the existing state, even if the external IP 
changed.

Sebastian

athn0: bad ROM checksum 0x2c64

2019-02-09 Thread Sebastian Reitenbach

Hi,

got a cheap TP-Link TL-WN821N, which shows up as Atheros AR7015 under Windows 
10.

athn0 at uhub3 port 3 configuration 1 interface 0 "ATHEROS USB WLAN" rev 
2.00/2.02 addr 5
athn0: failed loadfirmware of file athn-open-ar7010 (error 2)
athn0: could not load firmware
athn0 at uhub3 port 3 configuration 1 interface 0 "ATHEROS USB WLAN" rev 
2.00/2.02 addr 5
athn0: bad ROM checksum 0x2c64
athn0: could not read ROM
athn0: could not attach chip

usbdevs -v:
addr 05: 0cf3:7015 ATHEROS, USB WLAN
 high speed, power 500 mA, config 1, rev 2.02, iSerial 12345
 driver: athn0

Just wanted to make sure I don't miss anything, don't see that chpset somehow
listed in athn(4) page, so guess this is just not supported yet?

cheers,
Sebastian

Re: athn0: bad ROM checksum 0x2c64

2019-02-09 Thread Sebastian Reitenbach




Sent from my iPhone

> On 9. Feb 2019, at 18:56, Sebastian Reitenbach 
>  wrote:
> 
> Hi,
> 
> got a cheap TP-Link TL-WN821N, which shows up as Atheros AR7015 under Windows 
> 10.
> 
> athn0 at uhub3 port 3 configuration 1 interface 0 "ATHEROS USB WLAN" rev 
> 2.00/2.02 addr 5
> athn0: failed loadfirmware of file athn-open-ar7010 (error 2)
> athn0: could not load firmware

Damn, forgot to mention that between above and below dmesg output I ran 
fw_update to fetch Athen firmware, then below on second insertion of the device 
i get the bad ROM checksum. That is on i386, amd64 and mips64el.

> athn0 at uhub3 port 3 configuration 1 interface 0 "ATHEROS USB WLAN" rev 
> 2.00/2.02 addr 5
> athn0: bad ROM checksum 0x2c64
> athn0: could not read ROM
> athn0: could not attach chip
> 
> usbdevs -v:
> addr 05: 0cf3:7015 ATHEROS, USB WLAN
> high speed, power 500 mA, config 1, rev 2.02, iSerial 12345
> driver: athn0
> 
> Just wanted to make sure I don't miss anything, don't see that chpset somehow
> listed in athn(4) page, so guess this is just not supported yet?
> 
> cheers,
> Sebastian
>

Re: athn0: bad ROM checksum 0x2c64

2019-02-10 Thread Sebastian Reitenbach

Hi Stefan,

Am Sonntag, Februar 10, 2019 11:06 CET, Stefan Sperling  
schrieb:

> On Sat, Feb 09, 2019 at 06:56:45PM +0100, Sebastian Reitenbach wrote:
> > Hi,
> >
> > got a cheap TP-Link TL-WN821N, which shows up as Atheros AR7015 under 
> > Windows 10.
> >
> > athn0 at uhub3 port 3 configuration 1 interface 0 "ATHEROS USB WLAN" rev 
> > 2.00/2.02 addr 5
> > athn0: failed loadfirmware of file athn-open-ar7010 (error 2)
> > athn0: could not load firmware
> > athn0 at uhub3 port 3 configuration 1 interface 0 "ATHEROS USB WLAN" rev 
> > 2.00/2.02 addr 5
> > athn0: bad ROM checksum 0x2c64
> > athn0: could not read ROM
> > athn0: could not attach chip
>
> >
> > usbdevs -v:
> > addr 05: 0cf3:7015 ATHEROS, USB WLAN
> >  high speed, power 500 mA, config 1, rev 2.02, iSerial 12345
> >  driver: athn0
> >
> > Just wanted to make sure I don't miss anything, don't see that chpset 
> > somehow
> > listed in athn(4) page, so guess this is just not supported yet?
>
> Please try this device on a another USB port and/or another machine.
> There's a long-standing bug where these devices don't work on some
> USB host controllers with our drivers, in particular ehci(4).
>
> Last I tried plugging an athn(4) behind a hub, it would not work at all.
>

 I tried that device on my amd64 desktop, as well as on a i386, and mips64el 
notebook.
It's the same bad ROM checksum error I get on all three of them.

I've another athn stick which works well on all three:
athn0 at uhub3 port 3 configuration 1 interface 0 "ATHEROS USB2.0 WLAN" rev 
2.00/1.08 addr 5
athn0: AR9271 rev 1 (1T1R), ROM rev 13, address e8:de:27:15:9e:5e

The non-working one shows up as AR7015 in Windows, but I don't see a AR7015 
chipset
mentioned in athn(4), therefore I wanted to verify, if that particular chipset 
is actually
supported by our athn(4) at all?

cheers,
Sebastian

Re: athn0: bad ROM checksum 0x2c64

2019-02-10 Thread Sebastian Reitenbach

Am Sonntag, Februar 10, 2019 14:19 CET, Stefan Sperling  
schrieb:

> On Sun, Feb 10, 2019 at 11:50:35AM +0100, Sebastian Reitenbach wrote:
> > The non-working one shows up as AR7015 in Windows, but I don't see a AR7015 
> > chipset
> > mentioned in athn(4), therefore I wanted to verify, if that particular 
> > chipset is actually
> > supported by our athn(4) at all?
>
> Indeed, it looks like our athn(4) driver does not support this device
> properly. My guess is that the driver should be using ar9287_attach()
> instead of ar9285_attach() for this device.
>
> What happens when you try this diff with the non-working device?
> (This diff will break devices which are already working, that is expected.)

I get the same bad ROM checksum message with the broken device,
and indeed, the device that worked before, now gives the same bad ROM checksum
message when I insert it. It only give a different checksum:
previously working device: 0x2243
non-working device: 0x2c64

cheers,
Sebastian

>
> Index: athn.c
> ===
> RCS file: /cvs/src/sys/dev/ic/athn.c,v
> retrieving revision 1.99
> diff -u -p -r1.99 athn.c
> --- athn.c26 Apr 2018 12:50:07 -  1.99
> +++ athn.c10 Feb 2019 13:15:28 -
> @@ -196,7 +196,7 @@ athn_attach(struct athn_softc *sc)
>   error = ar9285_attach(sc);
>  #if NATHN_USB > 0
>   else if (AR_SREV_9271(sc))
> - error = ar9285_attach(sc);
> + error = ar9287_attach(sc);
>  #endif
>   else if (AR_SREV_9287(sc))
>   error = ar9287_attach(sc);
>
>
>
>

Re: OpenBSD 6.0 amd64 Release --> pkg_add returns error when running as Virtualbox guest

2016-11-18 Thread Sebastian Reitenbach

On Thursday, November 17, 2016 18:11 CET, Andre Ruppert 
wrote:

> Hello to the list,
>
> this morning I stumbled about a "pkg_add" problem when running OpenBSD
> 6.0 amd64 Release on an actual Virtualbox release. Doesn't matter which
> host platform (I tried Mac OS Sierra and Windows 10 and 7).
>
> Virtualbox settings:
> 5GB hardisk
> 512 MB RAM
> tested two network card settings: virtio-net and Intel 1000 Pro desktop
> tested NATed and bridged settings.
>
> Version: OpenBSD 6.0 (GENERIC) #2148: Tue Jul 26 12:55:20 MDT 2016
>
> for example: (used a local mirror)
>
> # pkg_add wget
> quirks-2.241 signed on 2016-07-26T16:56:10Z
> wget-1.18:libunistring-0.9.6p0: ok
> Fatal error: Ustar
>
[http://ftp.halifax.rwth-aachen.de/openbsd/6.0/packages/amd64/libidn-1.32p1.t
> gz][share/emacs/site-lisp/idna.el]:
> Premature end of archive
> Adjusting sha for /usr/local/share/emacs/site-lisp/pkg.VkQ6RBfrzy from
> DF8Nwh8xhTWpgYsivuBL7K8CMpbPKojbQJsyD0Paplk= to
> 47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=
> Fatal error: Installation of libidn-1.32p1 failed, partial installation
> recorded as partial-libidn-1.32p1
>   at /usr/libdata/perl5/OpenBSD/PkgAdd.pm line 817.
>
> -- doesn't depend on mirror
> -- doesn't depend on guest RAM settings
> -- doesn't depend on guest network card settings
> -- doesn't depend on acceleration settings in Virtualbox (well, I think
> so...)
>
> ...and a little bit strange:
> _sometimes_ pkg_add works with small packages:
>
>
> example 2a (same as ex 1):
>
> # pkg_add ipcalc
> quirks-2.241 signed on 2016-07-26T16:56:10Z
> Fatal error: Ustar
>
[http://ftp.halifax.rwth-aachen.de/openbsd/6.0/packages/amd64/ipcalc-1.4p0.tg
> z][bin/ipcalc]:
> Premature end of archive
> Adjusting sha for /usr/local/bin/pkg.F5nNSjqcJf from
> Htiq8Hrei0yMn/IWm+Y9dXTq3pZeZyBrbbv98+o9eoA= to
> 47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=
> Fatal error: Installation of ipcalc-1.4p0 failed, partial installation
> recorded as partial-ipcalc-1.4p0
>   at /usr/libdata/perl5/OpenBSD/PkgAdd.pm line 817.
>

I see stuff like this when installing bigger packages i.e. boost, on a slow
box (i386 266 MHz/128MB RAM)
Manually fetching the packages, and running pkg_add against the downloaded
package
then always works fine.
I was always wondering if there is kind of a timeout in pkg_add or the like,
for the case where
the file retrieval via http is slow.

Sebastian

>
> example 2b:
>
> # rm -R /var/db/pk/partial-*
> # pkg_add ipcalc
> quirks-2.241 signed on 2016-07-26T16:56:10Z
> ipcalc-1.4p0: ok
>
>
>
> Building packages from ports works fine (apparently)
>
>
> Any hints to look further?
> Anyone who had similar problems?
>
> Every hint is welcome, I'm clueless... ;-)
>
> best regards
> Andre Ruppert
>
> [demime 1.01d removed an attachment of type application/pkcs7-signature
which had a name of smime.p7s]

Re: IPv6 Setup not working on Hetzner server

2016-12-05 Thread Sebastian Reitenbach

On Friday, December 2, 2016 13:39 CET, Leo Unglaub 
wrote:

> Hey,
>
> On 12/02/16 13:14, Reyk Floeter wrote:
> > This is a link-local address, you have to specify the interface scope id:
> >
> > $ cat /etc/mygate
> > 144.76.102.193
> > fe80::1%em0
>
> thanks for the hint. I fixed this but that alone still does not help me
> to send IPv6 data.
>
> > Hetzner also needs to know your link-local address on em0,
> > do they use the fe80::921b:eff:fe8b:f34%em0 derived from the MAC (I think
they do)
> > or do you have to configure something like fe80::2%em0 on your side?
>
> Thats a good question. Sadly they dont specify that in the docs and are
> also not willing to answer that via there support staff.
>
> All i could find in the documentation is the following line:
>
> > For IPv6 on dedicated servers and virtual servers from the CX line, the
gateway is fe80::1.
> > Since this is a link-local address, the explicit specification of the
network adapter (usually eth0) is necessary:
> > # ip route add default via fe80::1 dev eth0
>
> There answer is that it works on Linux without config and OpenBSD is not
> supported officially.
>
>
> I just found out that since i changed my mygate up to your suggestion
> that i now have to ping6 fe80::1%em0 first and then i am able to
> connecto to other hosts via IPv6. But not before i pinged the
> fe80::1%em0. WTF?
>
> Here are my rountes before the first ping to fe80::1 and then after the
> ping.

I have a 5.9 snapshot running @Hetzner, and ran into the very same problem.
That same setup worked fine for years, but a couple of months ago, they did
some
change in their network infrastructure, and since then, I also have to ping6
first,
to enable proper IPv6 connectivity.
Since that 5.9 box is quite old, I haven't repored it, since the many
networking changes since then.

Sebastian
>
> > Routing tables (before ping)
> >
> > Internet6:
> > DestinationGatewayFlags
Refs  Use   Mtu  Prio Iface
> > defaultfe80::1%em0UGS
0  579 - 8 em0
> > ::/96  ::1UGRS
00 32768 8 lo0
> > ::/104 ::1UGRS
00 32768 8 lo0
> > ::1::1UHl
14   14 32768 1 lo0
> > ::127.0.0.0/104::1UGRS
00 32768 8 lo0
> > ::224.0.0.0/100::1UGRS
00 32768 8 lo0
> > ::255.0.0.0/104::1UGRS
00 32768 8 lo0
> > :::0.0.0.0/96  ::1UGRS
00 32768 8 lo0
> > 2002::/24  ::1UGRS
00 32768 8 lo0
> > 2002:7f00::/24 ::1UGRS
00 32768 8 lo0
> > 2002:e000::/20 ::1UGRS
00 32768 8 lo0
> > 2002:ff00::/24 ::1UGRS
00 32768 8 lo0
> > 2a01:4f8:192:42d6::/64 2a01:4f8:192:42d6::10  UC
00 - 4 em0
> > 2a01:4f8:192:42d6::10  90:1b:0e:8b:0f:34  UHLl
0   18 - 1 em0
> > fe80::/10  ::1UGRS
01 32768 8 lo0
> > fec0::/10  ::1UGRS
00 32768 8 lo0
> > fe80::%em0/64  fe80::921b:eff:fe8b:f34%em0UC
00 - 4 em0
> > fe80::921b:eff:fe8b:f34%em090:1b:0e:8b:0f:34  UHLl
00 - 1 em0
> > fe80::1%lo0fe80::1%lo0UHl
00 32768 1 lo0
> > ff01::/16  ::1UGRS
01 32768 8 lo0
> > ff01::%em0/32  fe80::921b:eff:fe8b:f34%em0Um
01 - 4 em0
> > ff01::%lo0/32  ::1Um
01 32768 4 lo0
> > ff02::/16  ::1UGRS
01 32768 8 lo0
> > ff02::%em0/32  fe80::921b:eff:fe8b:f34%em0Um
01 - 4 em0
> > ff02::%lo0/32  ::1Um
01 32768 4 lo0
>
>
> > Routing tables (after ping)
> >
> > Internet6:
> > DestinationGatewayFlags
Refs  Use   Mtu  Prio Iface
> > defaultfe80::1%em0UGS
0  581 - 8 em0
> > ::/96  ::1UGRS
00 32768 8 lo0
> > ::/104 ::1UGRS
00 32768 8

Re: OpenBSD's binutils

2016-12-05 Thread Sebastian Reitenbach

On Monday, December 5, 2016 11:05 CET, Stuart Longland
 wrote:

> On 28/11/16 21:10, Stuart Henderson wrote:
> > You are right, gcc 4.9 generates some code using opcodes that need newer
gas.
> > Try building the port with clang (it would also help the case where the
port
> > itself has asm needing a newer assembler; clang has an integrated
assembler
> > which generally has better opcode support, it's needed e.g. for some
video
> > codecs in x86-land for this reason too).
> >
> > MODULES += lang/clang
> > MODCLANG_ARCHS = *
> >
> > gstreamer1 in -current already uses this but the currently available
mips64el
> > package snapshot pre-dates this change.
>
> A heads up, I'm in the process of giving this a try.
>
> I started it off yesterday afternoon and this evening I note that the
> llvm/clang build failed with an "out of memory" error.  I've re-started
> on the off-chance it was a temporary issue, but I doubt it.

The OOM can also be a limit in /etc/login.conf, maybe you have to bump
datasize there, and try again.

Sebastian

Re: Watch out for bad options in /var/run/rc.d/$daemon

2017-01-04 Thread Sebastian Reitenbach

On Wednesday, January 4, 2017 08:16 CET, Antoine Jacoutot
 wrote:

> On Tue, Jan 03, 2017 at 11:01:18PM -0700, Andy Bradford wrote:
> > Hello,
> >
> > Since I couldn't find any reference  to this anywhere, I thought I would
> > put out a description of the problem in the event that someone else runs
> > into it with other daemons.
> >
> > At one  point in time,  identd -l had a  different meaning than  it does
> > now. After upgrading,  I noticed that identd was not  running, thanks to
> > the following section in the daily output email:
> >
> > Services that should be running but aren't:
> > identd
> >
> > So I began investigating why it wasn't running and found the following
> > in /var/log/messages:
> >
> > Jan  3 22:46:56 obsd identd[80696]: h/auth: no address associated with
name
> > Jan  3 22:46:56 obsd identd[84721]: child has gone
> >
> > Looking at the output, it seemed  clear that something had changed, so I
> > looked at the man page for identd, and sure enough, -l is now different.
> > Previously, in /etc/rc.conf.local, I had:
> >
> > identd_flags="-elh"
> >
> > Which coincided  with the error message.  Clearly -lh meant that  it was
> > trying to look  up a host named h, which  doesn't exist, whereas before,
> > -l meant to log  to syslog. So, I removed the  -l from identd_flags, and
> > tried to  restart the daemon. Much  to my dismay, it  failed to restart,
> > even though I had corrected the problem in rc.conf.local.
> >
> > As  it turns  out, after  further investigation,  I discovered  that the
> > flags get cached in /var/run/rc.d/identd:
> >
> > $ cat /var/run/rc.d/identd
> > daemon_class=daemon
> > daemon_flags=-elh
> > daemon_rtable=0
> > daemon_timeout=30
> > daemon_user=root
> > pexp=identd: (listen|resolver)
> >
> > There's the offending -l that I thought I had removed!
> >
> > I can see why now:
> >
> >
http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/etc/rc.d/rc.subr?annotate=1.116
> >
> > On line 109, the options that are cached in the _RC_RUNFILE override any
> > that were provided before rc_cmd() was called.
> >
> > Not sure  if this is  a bug.  How often does  a command line  option get
> > repurposed for something else?
> >
> > At any rate, I wanted to give a heads up to anyone else who might end up
> > with a daemon which refuses to restart, even after the options have been
> > corrected.
>
> Nice catch, but the real issue comes from identd(8).
>
> # /usr/sbin/identd -elh
> # echo $?
> 0
> # pgrep identd
> #
>
> See, it's not running but the return code was 0 which made rc.d(8) believed
the
> daemon was properly started in which case the variable are cached (so that
we
> can still match the daemon in the process list if the flags are changed in
> rc.conf.local).
>
> Someone fix identd please :-)

I've also hit this in the past with other daemons from ports, i.e. logstash as
an
example. It starts up, and backgrounds, and then later, it parses its
argument,
figures it got a wrong parameter and exits.
Then trying to add debug parameter to rc.conf.local, and see it
not taking the debug parameter into account, because the cached
values from /var/run/rc.d/... are used.
It caused me a bit of head scratching before I found these cached values
there.

I guess there might be other daemons that might expose such behaviour
as well.
Wondering why the cached parameters take precedence?

Sebastian

>
> --
> Antoine

Re: isakmpd quits out after running ipsec on CURRENT

2014-12-03 Thread Sebastian Reitenbach

I run this kernel from beginning of November:

OpenBSD 5.6-current (GENERIC) #492: Fri Nov  7 10:21:36 MST 2014
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: Geode(TM) Integrated Processor by National Semi ("Geode by NSC" 
586-class) 267 MHz
cpu0: FPU,TSC,MSR,CX8,CMOV,MMX

on my soekris box. Isakmpd is just started with: "-4 -K"
my ipsec.conf looks similar to this one (only IP addresses changed):

localip="1.1.1.1"
peerip="2.2.2.2"
ike esp from 3.3.3.0/24 to 4.4.0.0/16 \
local $localip peer $peerip \
main auth hmac-sha1 enc aes-128 group modp1024 \
quick auth hmac-sha1 enc aes-128 group modp1024 \
psk "top secret"
 

and it "just works".

does a higher debug level i.e. -D A=90 show something, or logging the 
packets isakmpd sees with -L give more hints?

cheers,
Sebastian

On Wednesday, December 3, 2014 15:53 CET, Zé Loff  wrote: 
 
> On Wed, Dec 03, 2014 at 02:00:59PM +, Kaya Saman wrote:
> > Hi,
> > 
> > for some reason, this seems to have been for a while now; isakmpd will 
> > simply quit running after initiating: ipsecctl -f /etc/ipsec.conf
> > 
> > Starting isakmpd manually with flags -Kdv doesn't give any indication as 
> > to what might be causing the service to crash or segfault and nothing is 
> > reported in the logs - I checked both daemon and messages.
> > 
> > ipsec.conf consists of standard config:
> > 
> > ike passive esp transport \
> >  proto udp from 212.159.80.17 to any port 1701 \
> >  main auth "hmac-sha" enc "aes" group modp1024 \
> >  quick auth "hmac-sha" enc "aes" \
> >  psk "Sclr11XP99"
> > 
> > ike passive esp transport \
> >  proto udp from  to any port 1701 \
> >  main auth "hmac-sha" enc "aes" group modp1024 \
> >  quick auth "hmac-sha" enc "aes" \
> >  psk ""
> > 
> > Basically the setup used to work fine a few upgrades ago while I was on 
> > 5.5 but then something seems to have changed and it stopped.
> > 
> > Along with the above I'm running npppd for ipsec/l2tp so I can run the 
> > native Android VPN client. I do run OpenVPN in addition but their seems 
> > to be some issue with routing on some apps so to get round that the 
> > choice is either: add default route manually when using OpenVPN / or use 
> > native client.
> > 
> > 
> > I managed to find this thread from the list:
> > 
> > http://comments.gmane.org/gmane.os.openbsd.misc/209636
> > 
> > and managed to pretty much validate my config in comparison but for some 
> > reason I cannot work this one out.
> > 
> > System is up to date as per last night and build is:
> > 
> > 5.6 GENERIC.MP#633 amd64
> > 
> > 5.6 GENERIC.MP#633 amd64
> > 
> > 
> > Would anyone be able to suggest anything?
> > 
> > 
> > Thanks.
> > 
> > 
> > Kaya
> > 
> 
> 
> I am seeing the same behaviour (apparently a clean exit, no message
> whatsoever nor core file) on -current, with an ipsec.conf as simple as
> this:
> 
> ike dynamic esp from 10.17.19.3 (egress) to 10.17.16.0/22 \
> peer vpn.foo.bar \
>   srcid peer1.foo.bar dstid vpn.foo.bar
> 
> 
> I have upgraded -current several times since I last used IPSec, so I
> can't tell for sure when it started...
> 
> 
> 
> OpenBSD 5.6-current (GENERIC.MP) #634: Mon Dec  1 10:11:11 MST 2014
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 8357658624 (7970MB)
> avail mem = 8131330048 (7754MB)
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xe0010 (78 entries)
> bios0: vendor LENOVO version "6QET70WW (1.40 )" date 10/11/2012
> bios0: LENOVO 3680WE9
> acpi0 at bios0: rev 2
> acpi0: sleep states S0 S3 S4 S5
> acpi0: tables DSDT FACP SSDT ECDT APIC MCFG HPET ASF! BOOT SSDT TCPA DMAR 
> SSDT SSDT SSDT
> acpi0: wakeup devices LID_(S3) SLPB(S3) IGBE(S4) EXP1(S4) EXP2(S4) EXP3(S4) 
> EXP4(S4) EXP5(S4) EHC1(S3) EHC2(S3) HDEF(S4)
> acpitimer0 at acpi0: 3579545 Hz, 24 bits
> acpiec0 at acpi0
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: Intel(R) Core(TM) i5 CPU M 520 @ 2.40GHz, 2660.43 MHz
> cpu0: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,AES,NXE,LONG,LAHF,PERF,ITSC
> cpu0: 256KB 64b/line 8-way L2 cache
> cpu0: smt 0, core 0, package 0
> mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
> cpu0: apic clock running at 133MHz
> cpu1 at mainbus0: apid 1 (application processor)
> cpu1: Intel(R) Core(TM) i5 CPU M 520 @ 2.40GHz, 2660.01 MHz
> cpu1: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,AES,NXE,LONG,LAHF,PERF,ITSC
> cpu1: 256KB 64b/line 8-way L2 cache
> cpu1: smt 1, core 0,

Re: ntpd.drift values?

2015-01-13 Thread Sebastian Reitenbach

On Tuesday, January 13, 2015 11:58 CET, Stuart Henderson  
wrote: 
 
> On 2015-01-12, Christian Weisgerber  wrote:
> > I'm interested in what values people have in their /var/db/ntpd.drift
> > files.
> >
> > To prevent a deluge: Looking over my own machines, I see that most
> > values are Xe-05, with a few Xe-04 and Xe-06.  So that's the common
> > range, I don't care about that.  But if you have machines with a
> > frequency accuracy outside that range, I'd like to hear about it.
> >
> > E.g., my Sun Blade 100 has 1.180462e-03.
> >

Here a few numbers that were easily collectable:

Dell Inc. Latitude D630 cpu0: Intel(R) Core(TM)2 Duo CPU T7250 @ 2.00GHz 
(amd64) 
   
2.166568e-05

VIA Eden Processor 1200MHz ("CentaurHauls" 686-class) 1.21 GHz (i386)
-2.109627e-04

Acer, inc. Aspire 3630 1.61GHz (i386)
-4.995503e-05

Soekris Geode(TM) 267Mhz (i386)
-2.438824e-05

Soekris Geode(TM) 500MHz (i386)
1.062687e-05

Re: Crashes at boot on Xen virtual machine

2015-01-29 Thread Sebastian Reitenbach

Hi, 
On Thursday, January 29, 2015 13:05 CET, Clément Hertling (Wxcafé) 
 wrote: 
 
> Hi
> 
> I'm trying to run an OpenBSD virtual machine in Xen 4.4.
> The install procedure worked fine, but when I boot the VM I get a kernel 
> crash.
> Linux VMs on this host work perfectly fine, and as I said the installer runs 
> ok
> too, so I'm not sure what's causing this.
> 

I also get crashes when running OpenBSD on MP kernel in XEN,
however, SP kernels work fine. On the boot> prompt, try boot /bsd.sp.

Don't know, if just reconfiguring the VM, and booting a MP kernel
with a single CPU helps/works too.

I haven't had time or necessity yet, to look into it a bit closer, maybe
playing with XEN config option i.e. noapic, or noacpi etc. in the
xen config file might or might not help. 
I currently only need "small" machines, where one CPU core is 
enough.


cheers,
Sebastian


> Following is the dmesg output :
> 
> OpenBSD 5.6 (GENERIC.MP) #333: Fri Aug  8 00:20:21 MDT 2014
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 109047808 (103MB)
> avail mem = 97517568 (93 MB)
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xfc001000 (12 entries)
> bios0: vendor Xen version "4.4.1" date 12/11/2014
> bios0: Xen HVM domU
> acpi at bios0 not configured
> mpbios0 at bios0: Intel MP Specification 1.4
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: Intel(R) Celeron(R) CPU G1610 @ 2.60GHz, 2594.52 MHz
> cpu0: 
> FPU,VMC,DE,PSE,TSC,MSR,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CFLUSH,MMX,
> FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,SSSE3,CX16,PCID,SSE4.1,SSE3.2,x2APIC,POPCNT,DEADL
> INE,XSAVE,FSGSBASE,SMEP,ERMS
> cpu0: 256KB 64b/line 8-way L2 cache
> cpu0: smt 0, core 0, package 0
> mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
> cpu0: apic clock running at 100MHz
> cpu1 at mainbus0: apid 2 (application processor)
> cpu1: Intel(R) Celeron(R) CPU G1610 @ 2.60GHz, 2594.36 MHz
> cpu1: 
> FPU,VMC,DE,PSE,TSC,MSR,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CFLUSH,MMX,
> FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,SSSE3,CX16,PCID,SSE4.1,SSE3.2,x2APIC,POPCNT,DEADL
> INE,XSAVE,FSGSBASE,SMEP,ERMS
> cpu1: 256KB 64b/line 8-way L2 cache
> cpu1: smt 0, core 1, package 0
> mpbios0: bus 0 is type ISA
> ioapic0 at mainbus0: apid 1 pa 0xfec0, version 11, 48 pins
> ioapic0: misconfigured as apic0, remapped to apid 1
> pci0 at mainbus bus 0
> pchb0 at pci0 dev 0 function 0 "Intel 82441FX" rev 0x02
> pcib0 at pci0 dev 1 function 0 "Intel 82371SB ISA" rev 0x00
> pciide0 at pci0 dev 1 function 1 "Intel 82371SB IDE" rev 0x00: DMA, channel 0 
> w
> ired to compatibility, channel 1 wired to compatibility
> wd0 at pciide0 channel 0 drive 0: 
> wd0: 16-sector PIO, LBA48, 51200MB, 104857600 sectors
> wdi1 at pciide0 channel 0 drive 1: 
> wd1: 16-sector PIO, LBA48, 128MB, 262144 sectors
> wd0(pciide0:0:0): using PIO mode 4, DMA mode 2
> wd1(pciide0:0:1): using PIO mode 4, DMA mode 2
> atapiscsi0 at pciide0 channel 1 drive 0
> scsibus1 at atapiscsi0: 2 targets
> cd0 at scsibus1 targ 0 lun 0:  ATAPI 5/cdrom 
> removabl
> e
> cd0(pciide0:1:0): using PIO mode 4, DMA mode 2
> "XenSource Platform Device" rev 0x01 at pci0 dev 2 function 0 not configured
> vga1 at pci0 dev 3 function 0 "Cirrus Logic CL-GD5446" rev 0x00
> wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
> wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
> re0 at pci0 dev 4 function 0 "Realtek 8139" rev 0x20: RTL8139C+ (0x7480), 
> apic 1
>  int 5, address 00:16:3e:b4:5a:29
> rlphy0 at re0 phy 0: RTL internal PHY
> isa0 at pcib0
> isadma0 at isa0
> com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
> com0: probed fifo depth: 0 bytes
> pckbc0 at isa0 port 0x60/5
> pckbd0 at pckbc0 (kbd slot)
> pckbc0: using irq 1 for kbd slot
> wskbd0 at pckbd0: console keyboard, using wsdisplay0
> pms0 at pckbc0 (aux slot)
> pckbc0: using irq 12 for aux slot
> wsmouse0 at pms0 mux 0
> pcppi0 at isa0 port 0x61
> spkr0 at pcppi0
> fdc0 at isa0 port 0x3f0/6 irq 6 drq 2
> fd0 at fdc0 drive 1: density unknown
> nvram: invalid checksum
> vscsi0 at root
> scsibus2 at vscsi0: 256 targets
> softraid0 at root
> scsibus3 at softraid0: 256 targets
> root on wd0a (dbd5aff2bf9a7bb0.a), swap on wd0b dump on wd0b
> clock: unknown CMOS layout
> kernel: double fault trap, code=0
> Stopped at  0:  kernel: page fault trap, code=0
> Stopped at  db_read_bytes+0x22: movzbl  0(%rdi,%rcx,1),%eax
> 
> Following is the trace:
> 
> ddb{1}> trace
> db_read_bytes() at db_read_bytes+0x22
> db_get_value() at db_get_value+0x34
> db_disasm() at db_disasm+0x42
> db_trap() at db_trap+0x90
> kdb_trap() at kdb_trap+0xf0
> trap() at trap+0x15d
> --- trap (number 13) ---
> mpidle() at 0
> cpu_spinup_trampoline_end() at cpu_spinup_trampoline_end+0x67
> end trace frame: 0x0, count = -8
> 
> I don't know if I should provide anything else, if you need something please
> tell me.
> 
> Thank you for any help

Re: Alternative way to get sources, CVS slow

2015-02-21 Thread Sebastian Reitenbach

On Saturday, February 21, 2015 19:06 CET, Henrique Lengler 
 wrote: 
 
> Hi,
> 
> I'm trying to keep and maintain a copy of -stable source code in my system.
> The problem is that I can't work with CVS.
> It is too slow to download. My internet can download things at 500kb/s - 
> 1MB/s,
> but when I am doing a checkout, the download stay too slow, I already tried 
> with a
> bunch of mirrors, and it is almost the same thing. I don't know if the 
> problem is that
> all CVS mirrors are slow. 
> I let my computer all the last day doing a checkout for src ports and 
> xenocara. After 
> 10 hours it was in ports yet. 
> 
> Also, the worst problem is that my internet connections sometimes drop, and 
> so in an 
> attempt to continue the interrupted checkout I run the command again, the 
> problem is 
> that it takes about a half hour to start to continue getting the code, this 
> when it 
> works, because sometimes after all this time I get:
> Write failed: Broken pipe
> Also sometimes looks like it is getting everything again, because it says
> cvs server: Updating foo
> to every file already in the folder.
> 
> I'm looking to a way to get this sources, there is a long time I'm trying and 
> it 
> ever happens some problem like this, and I can't continue to get the sources, 
> so I 
> need to delete everything a start again.
> 
> CVS looks too complicated and confuse.
> I would like to be able to get from http, git, ftp or anything sipler and 
> faster.
> Is there any alternative?

If you don't do it already, you may want to use compression on CVS checkout. 
I.e. 

cvs -z9 co src

Sebastian

> -- 
> Regards
> 
> Henrique Lengler

Re: Xen PV DomU with OpenBSD?

2015-02-25 Thread Sebastian Reitenbach

On Wednesday, February 25, 2015 22:17 CET, Andrew Daugherity 
 wrote: 
 
> On Sat, Feb 21, 2015 at 3:52 PM, Raimundo Santos  wrote:
> 
> > On 21 February 2015 at 10:31, Markus Kolb  wrote:
> > >
> > > there isn't any support for Xen PV DomU in OpenBSD, isn't it?
> >
> > No, there is not such support.
> >
> > But you can run it in HVM mode without effort. Well, may be some effort in
> > XenServer, where there is no easy way to chose the type of emulated
> > hardware.
> >
> That's rather stupid, but apparently true[1].
> 
> I've only used Xen on Linux hosts (primarily SUSE) where it's easy to edit
> the VM config files. I did have to use model=e1000 for OpenBSD, as the
> rtl8139 (re0 on openbsd) didn't work properly; I just now tested
> model=virtio and that seems to work too, showing up as vio0.  I also have
> to use bsd.sp as bsd.mp crashes on boot.

That's how i run it too, also on SLES XEN dom0, with virtio network card 
model, and bsd.sp, due to the crashers on bsd.mp.
I tried a whole lot of combinations of options in the VM config files, but 
nothing
helped so far to get around the crashers observed with bsd.mp.

> 
> Another "problem" when using Xen: the shutdown. Every OS that can not
> > communicate with xenstore will suffer from that. You will have to edit some
> > scripts in your environment to make it work with ACPI.
> >
> Thanks for the info.  I hadn't run into this since on Xen I mostly run PV
> Linux guests, with the occasional HVM guest w/PV drivers (Linux, FreeBSD,
> Windows), and my OpenBSD usage has mostly been on physical hardware, but it
> bears noting:
> 
> On HVM guests without PV drivers, 'xm shutdown ' will instantly kill
> the VM, without syncing, and similarly, 'xm reboot ' will instantly
> reset it.  The newer 'xl' tool is more graceful and will refuse an 'xl
> {shutdown, reboot}' when there isn't guest PV support (you can still 'xl
> destroy', of course, or 'xl {shutdown, reboot} -F ' to send an ACPI
> power button/reset button event).
> 
> To trigger an orderly shutdown on an OpenBSD guest, send an ACPI power
> button event:
> xm trigger  power
> 
> I discovered this solution via [2].
> 
> Also, when a serial console is configured on the OpenBSD guest, it shows up
> on the 'xm console'/virt-manager "Serial 1" view, which is nice, since you
> can copy/paste from that, unlike the emulated VGA console.  This apparently
> requires 'serial=pty' in the VM config, but that's already the default in
> my setup.

yep, serial console works well that way.

Sebastian

> 
> -Andrew
> 
> [1]
> http://www.netservers.co.uk/articles/open-source-howtos/citrix_e1000_gigabit
> [2] https://github.com/ClusterLabs/resource-agents/commit/306dccb

HP Ethernet 1Gb 4-port 331FLR card supported?

2012-11-13 Thread Sebastian Reitenbach

Hi,

we have a HP Proliant Server Gen8, where we want to run OpenBSD on it. 
The card mentioned has to go into the FlexibleLOM port on the server, therefore
there is not that much choice of a card.
As far as I have seen, this card is not listed in any of the drivers, but I 
found that
link here:
http://partnerweb.vmware.com/comp_guide1/detail.php?device_cat=io&device_id=21446
which tells me that the card has a BroadCom NetXtreme BCM5719 chipset, and 
bge(4) at least tells me, that this chipset is supported.

But to be sure, I thought trying to ask if anyone has such a card in use with 
OpenBSD?

thanks,
Sebastian

Re: HP Ethernet 1Gb 4-port 331FLR card supported?

2012-11-14 Thread Sebastian Reitenbach

On Wednesday, November 14, 2012 21:27 CET, Stuart Henderson 
 wrote: 
 
> On 2012-11-14, Sebastian Reitenbach  wrote:
> > Hi,
> >
> > we have a HP Proliant Server Gen8, where we want to run OpenBSD on it. 
> > The card mentioned has to go into the FlexibleLOM port on the server, 
> > therefore
> > there is not that much choice of a card.
> > As far as I have seen, this card is not listed in any of the drivers, but I 
> > found that
> > link here:
> > http://partnerweb.vmware.com/comp_guide1/detail.php?device_cat=io&device_id=21446
> > which tells me that the card has a BroadCom NetXtreme BCM5719 chipset, and 
> > bge(4) at least tells me, that this chipset is supported.
> >
> > But to be sure, I thought trying to ask if anyone has such a card in use 
> > with OpenBSD?
> >
> > thanks,
> > Sebastian
> >
> >
> 
> BCM5719 is not yet supported, I understand there are problems
> getting the phy to work.

Thanks Stuart, Instead of searching for the HP name of the card, I now 
searching for 
the chipset, I  found the patch for BCM5719 from dlg@ on tech@ and it seems 
that 
patch didn't made it into CVS yet.

Sebastian

Re: PRIMERGY RX200 S2 installation problems

2012-12-03 Thread Sebastian Reitenbach

Am Montag, 03. Dezember 2012 17:57 CET, Tony Berth  
schrieb: 
 
> it is the current one (2012-12-02)


> > OpenBSD 5.2 (RAMDISK_CD) #287: Wed Aug 1 10:19:00 MDT 2012
> > der...@i386.openbsd.org:/usr/src/sys/sys/arch/i386/compile/RAMDISK_CD

but dmesg says its not so current like you think it is.

Sebastian

> 
> Thanks
> 
> On Mon, Dec 3, 2012 at 6:52 PM, Kenneth R Westerback  > wrote:
> 
> > On Mon, Dec 03, 2012 at 06:08:34PM +0200, Tony Berth wrote:
> > > here is the installation dmesg when trying to install the 5.2 i386
> > snapshot:
> >
> > And the installation dmesg from a -current snapshot would be even
> > more useful.
> >
> >  Ken
> >
> > >
> > > -
> > > LSI Logic Corp. MPT IME  BIOS
> > > Copyright 1995-2005 LSI Logic Corp.
> > > MPTBIOS-IME-5.13.08
> > >
> > > CD-ROM: 9F
> > > Loading /5.2/I386/CDBOOT
> > > probing: pc0 apm pci mem[616K 2046M a20=on]
> > > disk: hd0+* cd0
> > > >> OpenBSD/i386 CDBOOT 3.17
> > > boot>
> > > booting cd0a:/5.2/i386/bsd.rd: 5973772+958284 [52+229744+218028]=0x709d1c
> > > entry point at 0x200128
> > > Copyright (c) 1982, 1986, 1989, 1991, 1993
> > > The Regents of the University of California. All rights reserved.
> > > Copyright (c) 19995-2012 OpenBSD. All rights reserved.
> > > http://www.OpenBSD.org
> > > OpenBSD 5.2 (RAMDISK_CD) #287: Wed Aug 1 10:19:00 MDT 2012
> > > der...@i386.openbsd.org:/usr/src/sys/sys/arch/i386/compile/RAMDISK_CD
> > > cpu0: Intel(R) Xeon(TM) CPU 3.00 GHz ("GenuineIntel" 686-class)
> > > cpu0: FPU, V86, DE, PSE, TSC, MSR, PAE, MCE, CX8, APIC, SEP, MTRR,
> > PGE,MCA,
> > > CMOV, PAT, PSE36, CF
> > >
> > LUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM.SBF,NXE,LONG,SSE3,MWAIT,DS-CPL,CNXT-
> > > ID,
> > > CX16,xTPR
> > > real mem = 2146414592 (2046MB)
> > > avail mem = 2183640064 (2006MB)
> > > mainbus0 at root
> > > bios0 at mainbus0: AT/286+ BIOS, date 09/16/85, BIOS32 rev. 0 @ 0xfd418,
> > > SMBIOS
> > > rev. 2.33 @ 0xdc010 (58 entries)
> > > bios0: vendor FSC version "6.8 Rev. R04A5F1.1790" date 09/16/2005
> > > bios0: FUJITSU SIEMENES PRIMERGY RX200S2
> > > acpi0 at bios0: rev 0
> > > acpi0: sleep states S0 S1 S4 S5
> > > acpi0: tables DSDT FACP MCFC SPCR APIC BOOY SSDT
> > > acpimadt0 at acpi0 addt 0xfee0: PC-AT compat
> > > cpu0 at mainbus0: apid 0 (boot processor)
> > > cpu0: apic clock running at 200MHz
> > > cpu at mainbus0: not configured
> > > cpu at mainbus0: not configured
> > > cpu at mainbus0: not configured
> > > ioacpi0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins
> > > ioacpi1 at mainbus0: apid 3 pa 0xfec8, version 20, 24 pins
> > > ioacpi2 at mainbus0: apid 4 pa 0xfec80400, version 20, 24 pins
> > > acpiprt0 at acpi0: bus 2 (P2P3)
> > > acpiprt1 at acpi0: bus 3 (P2P4)
> > > acpiprt2 at acpi0: bus 0 (PCI0)
> > > acpiprt3 at acpi0: bus 4 (PCIB)
> > > bios0: ROM list: 0xc/0x8000 0xc8000/0x4000 0xdc000/0x4000!
> > > pci0 at mainbus0 bus 0: configuration mode 1 (bios)
> > > pchb0 at pci0 dev 0 function 0 "Intel E7520 Host" rev 0x09
> > > "Intel E7520 Error Reporting" rev 0x09 at pci0 dev 0 function 1 not
> > > configured
> > > ppb0 at pci0 dev 2 function 0 "Intel E7520 PCIE" rev 0x09
> > > pci1 at ppb0 bus 1
> > > ppb1 at pci1 dev 0 function 0 "Intel 6700PXH PCIE-PCIX" rev 0x09
> > > pci2 at ppb1 bus 2
> > > "Intel IOxAPIC" rev 0x09 at pci1 dev 0 function 1 not configured
> > > ppb2 at pci1 dev 0 function 2 "Intel 6700PXH PCIE-PCIX" rev 0x09
> > > pci3 at ppb2 bus 3
> > > em0 at pci3 dev 3 function 0 "Intel PRO/1000MT (82545CM)" rev 0x04: apic
> > 2
> > > int1
> > > 6, address 00:04:23:c4:01:16
> > > mpi0 at pci3 dev 5 function 0 "Symbios Logic 53c1030" rev 0x07: msi
> > > scsibus0 at mpi0: 16 targets, initiator 7
> > > sd0 at scsibus0 targ 1 lun 0:  SCSI2 0/direct
> > fixed
> > > sd0: 34700MB, 512 bytes/sector, 71065600 sectors
> > > mpi0: timeout
> > > mpi0: timeout
> > > mpi0: timeout
> > > mpi0: timeout
> > > mpi0: timeout
> > > mpi0: timeout
> > > mpi0: phys disk Async at 0 MHz width 8bit offset 0 QAS 0 DT 0 IU 0
> > > em1 at pci3 dev 6 function 0 "Intel PRO/100MT (82546GB)" rev 0x03: apic 2
> > > int 1
> > > 6uvm_fault (0xd07f31d8, 0x0, 0, 1) -> e
> > > fatal page fault (6) in supervisor mode
> > > trap type 6 code 0 eip 0 cs 50 eflags 10282 cr2 0 cpl 50
> > > panic: trap type 6, code=0, pc=0
> > > The operating system has halted
> > > Please press any key to reboot
> > > ---
> > >
> > > Thanks
> > >
> > > On Thu, Nov 29, 2012 at 2:25 PM, Nick Holland
> > > wrote:
> > >
> > > > On 11/29/12 06:42, Tony Berth wrote:
> > > > > Thanks
> > > > >
> > > > > Both i386 and amd64 fail! But, are that many differences between
> > stable
> > > > and
> > > > > current?
> > > >
> > > > You caught us, nothing has changed in OpenBSD since 1995, we just drink
> > > > beer and increment the version number every six months.
> > > > 
> > > >
> > > > The most significant changes tend to take place just AFTER unlocking of
> > > > a new version of OpenBSD -- i.e., BEFORE the CDs ship.  So yes,
> > -current
> >

Re: An L2TP client for OpenBSD?

2013-03-02 Thread Sebastian Reitenbach

On Saturday, March 2, 2013 03:15 CET, Matt  wrote: 
 
> I love the L2TP functionality of npppd!  In fact, the entire setup is
> elegant.  It would also be great for OpenBSD to be able to function as an
> L2TP client.  Is there any program out there or in development that
> implements the client side of L2TP?

In -current ports tree there is net/xl2tpd, but nothing in base 
what I'm aware of.

Sebastian

> 
> Thanks much,
> Matt

KGDB with sparc as target

2013-03-31 Thread Sebastian Reitenbach

Hi,

following man kgdb, 
I tested the cable on the first serial port (on the notebook) with the 
system console using cu -l /dev/tty05 -s 9600.
And it works just fine.

I built a sparc Kernel with KGDB enabled:
option  KGDB# support for kernel gdb
option  KGDBDEV=0xc01   # kgdb device number (dev_t)
option  KGDBRATE=9600   # baud rate
makeoptions DEBUG="-g"

and in config/GENERIC I have DDB disabled:

#option DDB # in-kernel debugger
#option DDB_SAFE_CONSOLE # allow break into ddb during boot

The kernel built fine so far, I run it on the target system, which
is a Tadpole SPARCbook, see the dmesg.

For the remote gdb, I connected the serial cable to the 
second serial port of the notebook.

then in gdb on my debugging host I run:
# gdb /home/sebastia/bsd.gdb
...
(gdb) set remotebaud 9600


When the notebook is booting the system, then I run in gdb:
(gdb) target remote /dev/tty05


And see on the console of the notebook:
zstty1:  kgdb interrupt
kgdb waiting...

and in gdb I see:
(gdb) target remote /dev/cua05
Remote debugging using /dev/cua05
Ignoring packet error, continuing...
Ignoring packet error, continuing...
Ignoring packet error, continuing...
Couldn't establish connection to remote target
Malformed response to offset query, timeout
(gdb)

And then, that's it. The notebook doesn't seem to
react on any keyboard input anymore, but gdb also
doesn't seem to be able to connect to it via the
serial line.

The system running gdb is a i386.

For kgdb to work, do I need to connect from a 
machine of the same architecture?

I tried from my SS5, connected the serial cable
to its second serial port, but I wasn't even able
to get a serial console.
# cu -l /dev/tty01 -s 9600  
 
cu: open("/dev/tty01"): Device not configured
Also tried cua01. I don't know which would be the right device.

any hint what I may be doing wrong?
The kernel on the Notebook is a bit modified, since
I'm trying to port the dbri audio driver from NetBSD.

Sebastian


>From the notebook:
$ cat /tmp/dmesg.kgdb  
OpenBSD 5.3-current (GENERIC.kgdb) #0: Sun Mar 31 17:57:23 CEST 2013
sebastia@warbird.ds9:/usr/src/sys/arch/sparc/compile/GENERIC.kgdb
real mem = 66732032 (63MB)
avail mem = 61648896 (58MB)
mainbus0 at root: Tadpole_S3GX
cpu0 at mainbus0: MB86904 @ 110 MHz, on-chip FPU
cpu0: 16K instruction (32 b/l), 8K data (16 b/l) cache enabled
obio0 at mainbus0
clock0 at obio0 addr 0x71202000: mk48t08 (eeprom)
timer0 at obio0 addr 0x71d0: delay constant 52, frequency 200 Hz
zs0 at obio0 addr 0x7110 pri 12, softpri 6
zstty0 at zs0 channel 0
zstty1 at zs0 channel 1 (kgdb)
zs1 at obio0 addr 0x7100 pri 12, softpri 6
zskbd0 at zs1 channel 0: keyboard, type 5, layout 0x21
wskbd0 at zskbd0: console keyboard
zsms0 at zs1 channel 1
wsmouse0 at zsms0 mux 0
slavioconfig at obio0 addr 0x7180 not configured
auxreg0 at obio0 addr 0x7190
auxreg1 at obio0 addr 0x7191
tctrl0 at obio0 addr 0x4220 pri 11
tctrl0: main power available
clk-ctrl at obio0 addr 0x713c not configured
com0 at obio0 addr 0x713a pri 13: ns16550a, 16 byte fifo
com0: probed fifo depth: 0 bytes
iommu0 at mainbus0 addr 0x1000: version 0x4/0x0, page-size 4096, range 64MB
sbus0 at iommu0: 22 MHz
pnozz0 at sbus0 slot 0 offset 0x800 pri 2: rev 4, 800x600
wsdisplay0 at pnozz0 mux 1: console (std, sun emulation), using wskbd0
dma0 at sbus0 slot 4 offset 0x840: rev 2
esp0 at dma0 offset 0x880 pri 4: ESP200, 40MHz
scsibus0 at esp0: 8 targets, initiator 7
sd0 at scsibus0 targ 3 lun 0:  SCSI2 0/direct fixed 
serial.IBM_DPRS-21215_!_7L4V6079_
sd0: 1160MB, 512 bytes/sector, 2376864 sectors
bpp0 at sbus0 slot 4 offset 0xc80: DMA2
ledma0 at sbus0 slot 4 offset 0x8400010: rev 2
le0 at ledma0 offset 0x8c0 pri 6: address 00:00:83:ae:11:44
le0: 16 receive buffers, 4 transmit buffers
tslot0 at sbus0 slot 1 offset 0x200 pri 11: 2 slots
pcmcia0 at tslot0 socket 0
ep0 at pcmcia0 function 0 "3Com, 3C574-TX Fast EtherLink PC Card, A" port 
0x0/32: address 00:60:08:b3:f5:61
tqphy0 at ep0 phy 0: 78Q2120 10/100 PHY, rev. 3
pcmcia1 at tslot0 socket 1
dbri0 at sbus0 slot 2 offset 0x40 pri 9
vscsi0 at root
scsibus1 at vscsi0: 256 targets
softraid0 at root
scsibus2 at softraid0: 256 targets
bootpath: 
/iommu@0,1000/sbus@0,10001000/espdma@4,840/esp@4,880/sd@3,0
root on sd0a (15849b035c6ca151.a) swap on sd0b dump on sd0b
WARNING: preposterous time in file system
WARNING: clock lost 10257 days -- CHECK AND RESET THE DATE!


from the SS5:
OpenBSD 5.3-current (GENERIC) #21: Sat Mar 23 17:23:36 MDT 2013
dera...@sparc.openbsd.org:/usr/src/sys/arch/sparc/compile/GENERIC
real mem = 200933376 (191MB)
avail mem = 192954368 (184MB)
mainbus0 at root: SUNW,SPARCstation-5
cpu0 at mainbus0: MB86907 @ 170 MHz, on-chi

Re: KGDB with sparc as target

2013-04-01 Thread Sebastian Reitenbach

On Sunday, March 31, 2013 20:10 CEST, "Sebastian Reitenbach" 
 wrote: 
 
> Hi,
> 
> following man kgdb, 
> I tested the cable on the first serial port (on the notebook) with the 
> system console using cu -l /dev/tty05 -s 9600.
> And it works just fine.
> 
> I built a sparc Kernel with KGDB enabled:
> option  KGDB# support for kernel gdb
> option  KGDBDEV=0xc01   # kgdb device number (dev_t)
> option  KGDBRATE=9600   # baud rate
> makeoptions DEBUG="-g"
> 
> and in config/GENERIC I have DDB disabled:
> 
> #option DDB # in-kernel debugger
> #option DDB_SAFE_CONSOLE # allow break into ddb during boot
> 
> The kernel built fine so far, I run it on the target system, which
> is a Tadpole SPARCbook, see the dmesg.
> 
> For the remote gdb, I connected the serial cable to the 
> second serial port of the notebook.
> 
> then in gdb on my debugging host I run:
> # gdb /home/sebastia/bsd.gdb
> ...
> (gdb) set remotebaud 9600
> 
> 
> When the notebook is booting the system, then I run in gdb:
> (gdb) target remote /dev/tty05
> 
> 
> And see on the console of the notebook:
> zstty1:  kgdb interrupt
> kgdb waiting...
> 
> and in gdb I see:
> (gdb) target remote /dev/cua05
> Remote debugging using /dev/cua05
> Ignoring packet error, continuing...
> Ignoring packet error, continuing...
> Ignoring packet error, continuing...
> Couldn't establish connection to remote target
> Malformed response to offset query, timeout
> (gdb)
> 
> And then, that's it. The notebook doesn't seem to
> react on any keyboard input anymore, but gdb also
> doesn't seem to be able to connect to it via the
> serial line.
> 
> The system running gdb is a i386.
> 
> For kgdb to work, do I need to connect from a 
> machine of the same architecture?

Meanwhile I installed egdb on the i386, just to see if 
it makes a difference, but it doesn't.

While at the topic, I installed KGDB kernel on 
amd64 notebook.

Starting gdb on the i386 with the amd64 kernel I get:
This GDB was configured as 
"i386-unknown-openbsd5.2"..."/home/sebastia/bsd.amd64": not in executable 
format: File format not recognized
(egdb from ports tells me the same)
However, I can set the "target remote ...", and 
it breaks into the system.

But with the sparc kernel, I don't have that problem.

Copying over the kernel to my amd64 desktop. Starting
up gdb from there, I don't get the warning about the
executable format. Also connecting with gdb to
the remote system works.


# file /home/sebastia/bsd.*
/home/sebastia/bsd.amd64: ELF 64-bit LSB executable, x86-64, version 1, 
statically linked, not stripped
/home/sebastia/bsd.gdb:   ELF 32-bit MSB executable, SPARC, version 1, 
statically linked, not stripped

To make the story short: between two amd64 boxen, KGDB works as expected
i386 to amd64: gdb doesn't recognize the kernel file format but connects to the 
remote target
i386 to sparc: gdb recognizes the file format, but doesn't break into the 
remote target

Can it be that there is a 32/64 bit dependency on gdb, what types of kernels it 
can read?


> 
> I tried from my SS5, connected the serial cable
> to its second serial port, but I wasn't even able
> to get a serial console.
> # cu -l /dev/tty01 -s 9600
>
> cu: open("/dev/tty01"): Device not configured
> Also tried cua01. I don't know which would be the right device.

got an answer off list, that the right device for the second tty would be 
/dev/ttyb
Still need to investigate here.

Sebastian


> 
> any hint what I may be doing wrong?
> The kernel on the Notebook is a bit modified, since
> I'm trying to port the dbri audio driver from NetBSD.
> 
> Sebastian
> 
> 
> From the notebook:
> $ cat /tmp/dmesg.kgdb 
>  
> OpenBSD 5.3-current (GENERIC.kgdb) #0: Sun Mar 31 17:57:23 CEST 2013
> sebastia@warbird.ds9:/usr/src/sys/arch/sparc/compile/GENERIC.kgdb
> real mem = 66732032 (63MB)
> avail mem = 61648896 (58MB)
> mainbus0 at root: Tadpole_S3GX
> cpu0 at mainbus0: MB86904 @ 110 MHz, on-chip FPU
> cpu0: 16K instruction (32 b/l), 8K data (16 b/l) cache enabled
> obio0 at mainbus0
> clock0 at obio0 addr 0x71202000: mk48t08 (eeprom)
> timer0 at obio0 addr 0x71d0: delay constant 52, frequency 200 Hz
> zs0 at obio0 addr 0x7110 pri 12, softpri 6
> zstty0 at zs0 channel 0
> zstty1 at zs0 channel 1 (kgdb)
> zs1 at obio0 addr 0x7100 pri 12, softpri 6
> zskbd0 at zs1 channel 0: keyboard, t

Re: Xwindows Startup without user login

2013-04-02 Thread Sebastian Reitenbach

On Tuesday, April 2, 2013 05:02 CEST, Duncan Patton a Campbell 
 wrote: 
 
> On Mon, 1 Apr 2013 20:54:58 -0600
> Duncan Patton a Campbell  wrote:
> 
> > 
> > Howdy Ryan?  
> > 
> > Thanks, this looks to be the sort of thing I'm after... hopefully I can get 
> > it to run on OBSD now ;)
> > 
> 
> Needs libpam :-/

there is security/openpam in the ports tree.

Sebastian

> 
> 
> > Dhu
> > 
> > On Mon, 1 Apr 2013 22:43:14 -0400
> > Ryan Kavanagh  wrote:
> > 
> > > On Mon, Apr 01, 2013 at 08:14:20PM -0600, Duncan Patton a Campbell
> > > wrote:
> > > > I'm looking for the "right" way to start X on boot and run a default
> > > > display program, much like xdm but with no login.
> > > 
> > > I don't know about the "right" way, but I use nodm on my Debian boxes. I
> > > don't see it in the ports tree and I don't know if it will work on
> > > OpenBSD, but it's worth a try.
> > > 
> > > The homepage[0] is out of date, but you can get the latest version
> > > here[1].
> > > 
> > > Best wishes,
> > > Ryan
> > > 
> > > [0] http://www.enricozini.org/sw/nodm/
> > > [1] http://ftp.de.debian.org/debian/pool/main/n/nodm/nodm_0.11.orig.tar.gz
> > > 
> > > -- 
> > > |_)|_/Ryan Kavanagh   | Debian Developer
> > > | \| \http://ryanak.ca/   | GPG Key 4A11C97A
> > > 
> > 
> > 
> > -- 
> > Ne obliviscaris, vix ea nostra voco.
> 
> 
> -- 
> Ne obliviscaris, vix ea nostra voco.

Re: Ethernet card not working

2013-04-11 Thread Sebastian Reitenbach

On Wednesday, April 10, 2013 23:57 CEST, Riccardo Mottola 
 wrote: 

> Hi,
> 
> I bought a new PCMCIA card for my ol' Thinkpad since I managed to break 
> the old one.
> 
> This is what I see in dmesg when I insert it, but then no device shows 
> up in ifconfig.
> 
> ne4 at pcmcia0 function 0 "D-Link, DFE-670TXD, PC Card" port 0xa040/32: 
> can't match ethernet vendor code
> 
> The card is perfectly recognized as such, but ifconfig shows no "ne4".
> 
> I'm running a stock 5.2 kernel.

A quick search in the sources I found this:

{ PCMCIA_VENDOR_LINKSYS, PCMCIA_PRODUCT_NETGEAR_FA410TXC,
  PCMCIA_CIS_DLINK_DFE670TXD,
  0, -1, { 0x00, 0x05, 0x5d } },

in dev/pcmcia/if_ne_pcmcia.c
check the const struct ne2000dev ...

I'm not sure if pcidump -v will print out information about the PCMCIA card too,
but there you should find vendor and product ID of the card.

also found this:
http://openbsd.7691.n7.nabble.com/Socket-10-100-Ethernet-CF-Card-td206491.html
Maybe your MAC address is not matching?

cheers,
Sebastian

> 
> Riccardo

Re: faxing

2013-04-22 Thread Sebastian Reitenbach

On Monday, April 22, 2013 19:30 CEST, Peter Fraser  wrote: 
 
> Several years ago I put an OpenBSD system in as a firewall and mail server at 
> a small charity that I volunteer at (kwaccessablility.ca)
> that fixed nearly all the problems that they had with viruses, spam etc.
> 
> Last year I talked them in to switching to VOIP (on the OpenBSD server using 
> Asterisk). Their phone costs dropped from over $250
> per month to less than $30 per month (I used the service from unlimitel.ca). 
> The change is costs per month made up for the costs 
> of the new telephone equipment within the year.
> 
> Nearly all their communication that was done by fax is now done by email, 
> except for one organization. That organization which is 
> run by the city supplies transportation for physically handicapped. That 
> organization is insisting on faxes. They will not take email.
> The charity currently has an analog fax just for the purpose of arranging 
> transportation, and that line is costing over $60 per month.
> 
> I looked at email to fax services, but I believe those queue the faxes up and 
> send them as time is available.  The charity and
> the transportation organization need immediate sending and receiving.  They 
> carry out a conversation with hand written
> notes (requiring the charity to type the responses would not be a problem).
> 
> Asterisk has a fax service, so I thought I could use that. But the Asterisk 
> fax sending service requires TIFF in a directory
> and receiving service puts a TIFF file in a directory. 
> 
>  The charity operates in a Windows environment. To the problem is: how does a 
> person (probably a volunteer)
>  on a Windows machine put a TIFF file into a directory on an OpenBSD, and in 
> addition send the information 
> as to where send the fax and get back a status on success or failure of 
> sending a fax.
> 
>  I don't think receiving the fax will be that much of a problem; it should be 
> easy to take the fax out the directory 
> and send it as an email to a group mailbox. 
> 
> What I don't have is a good to solution for is how the person sitting at the 
> Windows machine is to send a fax.
>  There are some commercial solutions for Linux, but I have no idea if they 
> operate OpenBSD. 
>  The commercial solutions are generally of the format that an email gets sent 
> and fax is extracted from the text of the message.
> 
> I would like to know if anyone has done something similar or any good 
> suggestions on what I should do to
> get faxing to work
> 

I haven't had a need for FAX yet, but maybe give hylafax together with iaxmodem 
a try. 
Both are in ports.
Or maybe read up here: http://www.voip-info.org/wiki/view/Asterisk+fax

cheers,
Sebastian

Re: Fax -- IAXModem and hylafax

2013-04-23 Thread Sebastian Reitenbach

On Monday, April 22, 2013 21:08 CEST, Peter Fraser  wrote: 
 
> I looked at IAX modem, and most I know about it is from 
> http://iaxmodem.sourceforge.net/faq.php
> 
> and as far as I can tell  IAXmodem doesn't do T.38 which 
> I believe is the correct solution.
> 
> But I did get pointed to t38modem at SourceForge.net
> which is not in ports. Again I have not tried it, 
> and it may do the job to work with hylafax+.
> 
> I would like to know if any one had done this.

Haven't done that, but as others already pointed out as an option,
that I forgot about: at work we are using multiple ATA boxes
(e.g. GrandStream HandyTone 286), which just work perfectly 
with the faxes behind them.

cheers,
Sebastian

> 
> -Original Message-
> From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On Behalf Of 
> Sebastian Reitenbach
> Sent: Monday, April 22, 2013 1:51 PM
> To: misc@openbsd.org
> Subject: Re: faxing
> 
> On Monday, April 22, 2013 19:30 CEST, Peter Fraser  wrote: 
>  
> > Several years ago I put an OpenBSD system in as a firewall and mail 
> > server at a small charity that I volunteer at (kwaccessablility.ca) that 
> > fixed nearly all the problems that they had with viruses, spam etc.
> > 
> > Last year I talked them in to switching to VOIP (on the OpenBSD server 
> > using Asterisk). Their phone costs dropped from over $250 per month to 
> > less than $30 per month (I used the service from unlimitel.ca). The change 
> > is costs per month made up for the costs of the new telephone equipment 
> > within the year.
> > 
> > Nearly all their communication that was done by fax is now done by 
> > email, except for one organization. That organization which is run by the 
> > city supplies transportation for physically handicapped. That organization 
> > is insisting on faxes. They will not take email.
> > The charity currently has an analog fax just for the purpose of arranging 
> > transportation, and that line is costing over $60 per month.
> > 
> > I looked at email to fax services, but I believe those queue the faxes 
> > up and send them as time is available.  The charity and the 
> > transportation organization need immediate sending and receiving.  They 
> > carry out a conversation with hand written notes (requiring the charity to 
> > type the responses would not be a problem).
> > 
> > Asterisk has a fax service, so I thought I could use that. But the 
> > Asterisk fax sending service requires TIFF in a directory and receiving 
> > service puts a TIFF file in a directory.
> > 
> >  The charity operates in a Windows environment. To the problem is: how 
> > does a person (probably a volunteer)  on a Windows machine put a TIFF 
> > file into a directory on an OpenBSD, and in addition send the information 
> > as to where send the fax and get back a status on success or failure of 
> > sending a fax.
> > 
> >  I don't think receiving the fax will be that much of a problem; it 
> > should be easy to take the fax out the directory and send it as an email to 
> > a group mailbox.
> > 
> > What I don't have is a good to solution for is how the person sitting at 
> > the Windows machine is to send a fax.
> >  There are some commercial solutions for Linux, but I have no idea if they 
> > operate OpenBSD. 
> >  The commercial solutions are generally of the format that an email gets 
> > sent and fax is extracted from the text of the message.
> > 
> > I would like to know if anyone has done something similar or any good 
> > suggestions on what I should do to get faxing to work
> > 
> 
> I haven't had a need for FAX yet, but maybe give hylafax together with 
> iaxmodem a try. 
> Both are in ports.
> Or maybe read up here: http://www.voip-info.org/wiki/view/Asterisk+fax
> 
> cheers,
> Sebastian

Re: Puppet and OpenBSD. Any examples/experience for unattended provisioning?

2015-06-22 Thread Sebastian Reitenbach


Am 6/21/2015 um 3:00 PM schrieb Kirill Peskov:

Hi All,

Looks like there is no comprehensive guide/howto in the Net for $subj...
Googling gives some discussions and presentations regarding running
puppet server on OpenBSD, which is not so interesting. My task is to
automate provisioning of bunch of OpenBSD servers across several LANs
and puppet would be a good helper here (OK, maybe Saltstack could be an
alternative solution, but there is even less info about such a
combination out there).


I'm running Puppetmaster behind nginx, with puppetdb and puppetboard on 
OpenBSD.
I combined initial provisioning with autoinstall(8) that takes care of 
initially installing puppet
via site.script and then firing it up. The puppetmaster configures 
itself with a bunch of
puppet appy commands in standalone, all my other boxen just run puppet 
agent --test

and connect to the puppetmaster for further bootstrapping.
For Puppet module management, r10k is used.

I have a bunch of puppet modules for OpenBSD here:
https://github.com/buzzdeee

In short: puppet works like a charm for me.

Note: I run -current on all of my gear, and that has some fixes for the 
service and package providers, that

unfortunately didn't made it into 5.7.


cheers,
Sebastian




Thanx in advance,
Kirill

problem with carp on 5.9, MAC address of carp interface?

2016-04-25 Thread Sebastian Reitenbach

Hi,

I'm trying to upgrade a HA carped firewall cluster to 5.9 but run into
issues.
The current cluster runs old 5.2, so it's more than time to do so.

I've done a couple of carp setups so far, but don't seem to get this one
right.

I reinstalled the backup node of the cluster with OpenBSD 5.9.

I have two em interfaces, that have a few VLANs on them, with
carp on top, and two ix interfaces, that are bundled in a trunk with
vlans and carp on top of the trunk. In total I have 19 carp interfaces.
All carp interfaces have the same vhid.

All the carp interfaces see the traffic from the MASTER node, and
when started up, they stay in BACKUP MODE.

A few of the VLAN interfaces have IP addresses, most of them don't.

This is /etc/sysctl.conf:
kern.bufcachepercent=80
net.inet6.ip6.forwarding=0
net.inet.ip.forwarding=1
net.inet.carp.preempt=1
net.inet.carp.allow=1

below I just show hostname.if of the stack of the interface that
has the default route. This sits on the ix -> trunk -> vlan -> carp:

cat /etc/hostname.ix0
description "PHYS_INT_TRK"
up

cat /etc/hostname.ix1
description "PHYS_INT_TRK"
up


cat /etc/hostname.trunk0
description "INTERNAL_TRUNK"
trunkproto lacp trunkport ix0 trunkport ix1
inet 192.168.9.252 255.255.255.0 NONE
up

cat /etc/hostname.vlan90
description "NKE_IPB_VLAN"
vlan 90 vlandev trunk0
up

cat /etc/hostname.carp90
description "NKE_IPB"
vhid 1 pass mypassword carpdev vlan90 advskew 100
inet 172.16.99.1 255.255.255.0 NONE
up


ifconfig ix0
ix0:
flags=18b43
mtu 1500
lladdr 90:e2:ba:2c:b5:08
description: PHYS_INT_TRK
priority: 0
trunk: trunkdev trunk0
media: Ethernet autoselect
status: no carrier

ifconfig ix1
ix1:
flags=18b43
mtu 1500
lladdr 90:e2:ba:2c:b5:08
description: PHYS_INT_TRK
priority: 0
trunk: trunkdev trunk0
media: Ethernet autoselect (10GSFP+Cu full-duplex)
status: active

ifconfig trunk0
trunk0: flags=8943 mtu 1500
lladdr 90:e2:ba:2c:b5:08
description: INTERNAL_TRUNK
priority: 0
trunk: trunkproto lacp
trunk id: [(8000,90:e2:ba:2c:b5:08,404D,,),
 (,00:00:00:00:00:00,,,)]
trunkport ix1 active,collecting,distributing
trunkport ix0
groups: trunk
media: Ethernet autoselect
status: active
inet 192.168.9.252 netmask 0xff00 broadcast 192.168.9.255

ifconfig vlan90
vlan90: flags=8943 mtu 1500
lladdr 90:e2:ba:2c:b5:08
description: NKE_IPB_VLAN
priority: 0
vlan: 90 parent interface: trunk0
groups: vlan egress

ifconfig carp90
carp90: flags=8843 mtu 1500
lladdr 00:00:5e:00:01:01
description: NKE_IPB
priority: 15
carp: BACKUP carpdev vlan90 vhid 1 advbase 1 advskew 100
groups: carp
status: backup
inet 172.16.99.1 netmask 0xff00 broadcast 172.16.99.255


I first tried to run on the master:

ifconfig -g carp carpdemote XX

to demote the carp on the master, but that then kicked me off from the
network. With keyboard/monitor I saw, that only some of the interfaces
changes state on the MASTER/BACKUP server. Both were in kind of mixed
mode. That explained me, why I got kicked out.
Then I just switched off the old master.
The new backup node switched all interfaces into MASTER mode.

however, after the switch, I was not able to ping my default
gateway, the 172.16.99.2. On the default gateway itself, an OpenBSD
HA carp firewall cluster running 5.8, I saw in dmesg at the time I was
trying to switch the cluster:

Apr 25 05:05:19 srv93 /bsd: arp info overwritten for 172.16.99.1 by
90:e2:ba:2c:b5:08 on trunk0
Apr 25 05:05:26 srv93 /bsd: arp info overwritten for 172.16.99.1 by
00:00:5e:00:01:01 on trunk0
Apr 25 05:19:20 srv93 /bsd: arp info overwritten for 172.16.99.1 by
90:e2:ba:2c:b5:08 on trunk0
Apr 25 05:19:21 srv93 /bsd: arp info overwritten for 172.16.99.1 by
00:00:5e:00:01:01 on trunk0
Apr 25 05:27:40 srv93 /bsd: arp info overwritten for 172.16.99.1 by
90:e2:ba:2c:b5:08 on trunk0
Apr 25 05:27:40 srv93 /bsd: arp info overwritten for 172.16.99.1 by
00:00:5e:00:01:01 on trunk0

The MAC 90:e2:ba:2c:b5:08 is from the BACKUP node, that is apparently the MAC
of the vlan90
interface underlying the carp90 interface. The 00:00:5e:00:01:01 is coming
from the old 5.2
cluster node that is the master. Actually I did not expected to see these
switched, shouldn't
the BACKUP use also the carp MAC address?

On networks, where the carp parent interfaces have IPs assigned in the given
networks, I
was able to ping other nodes in the network, on carp interfaces where the
parent doesn't have
IPs assigned, trying to ping in these networks failed.

As shown with hostname.if and ifconfig output, the parent of the carp
interface with the default route attached, doesn't have an IP address
assigned.
There I was not able to ping the default gateway. I made a test and assigning
a free IP i

Re: problem with carp on 5.9, MAC address of carp interface?

2016-04-25 Thread Sebastian Reitenbach

On Monday, April 25, 2016 11:12 CEST, Martin Pieuchot 
wrote:

> On 25/04/16(Mon) 10:47, Kim Zeitler wrote:
> > Hello Martin, hello Sebastian
> >
> > On 04/25/16 10:15, Martin Pieuchot wrote:
> > >On 25/04/16(Mon) 09:48, Sebastian Reitenbach wrote:
> > >>I'm trying to upgrade a HA carped firewall cluster to 5.9 but run into
> > >>issues.
> > >
> > >Which issues?  After reading your whole email I still don't understand
> > >your problem(s).  What does not work?
> > He is running a carp interface on top of a vlan interface. In this
scenario
> > the carp interface can not be pinged but the vlan interfaces can.
>
> Do you mean the CARP node does not answer to ping with a destination
> address on the carp(4) interfaces?  Is it for MASTER, BACKUP or both?

I have the old node shutdown so that the cluster is only one node. with
advskew 100, but all carp interfaces in master.

I have

ix0 ---
\
   trunk0 -- vlanXX (i.e. vlan90) -- carpXX (i.e. carp90)
/
ix1 ---


from there, I tried to ping the default

The routing table, now with the machine in BACKUP mode:

 netstat -rn -f inet
Routing tables

Internet:
DestinationGatewayFlags   Refs  Use   Mtu  Prio Iface
default172.16.99.2GS 02 -23
carp90
10.1.0/24  10.1.0.1   C  0 1666 - 4 carp8
10.1.0.1   00:00:5e:00:01:01  UHLl   0 1480 - 1 carp8
10.1.0.255 10.1.0.1   Hb 0 1704 - 1 carp8
10.10.0/24 10.10.0.1  C  0  120 - 4 carp7
10.10.0.1  00:00:5e:00:01:01  UHLl   0   68 - 1 carp7
10.10.0.25510.10.0.1  Hb 0 1804 - 1 carp7
10.10.1/24 10.100.2.1 GS 00 -23
carp901
10.10.2/24 10.100.2.1 GS 00 -23
carp901
10.10.3/24 10.100.2.1 GS 00 -23
carp901
10.10.4/24 10.100.2.1 GS 00 -23
carp901
10.10.5/24 10.100.2.1 GS 00 -23
carp901
10.10.8/24 10.100.2.1 GS 00 -23
carp901
10.10.9/24 10.100.2.1 GS 00 -23
carp901
10.12.1/24 10.100.2.1 GS 00 -23
carp901
10.12.3/24 10.100.2.1 GS 00 -23
carp901
10.12.6/24 10.100.2.1 GS 00 -23
carp901
10.13.1/24 10.100.2.1 GS 00 -23
carp901
10.15.1/24 10.100.2.1 GS 00 -23
carp901
10.20.30/2410.100.2.1 GS 00 -23
carp901
10.20.40/2410.100.2.1 GS 00 -23
carp901
10.20.50/2410.100.2.1 GS 00 -23
carp901
10.20.60/2410.20.60.1 C  0   56 - 4 carp2
10.20.60.1 00:00:5e:00:01:01  UHLl   01 - 1 carp2
10.20.60.255   10.20.60.1 Hb 00 - 1 carp2
10.20.70/2410.20.70.1 C  0  348 - 4 carp3
10.20.70.1 00:00:5e:00:01:01  UHLl   0   50 - 1 carp3
10.20.70.255   10.20.70.1 Hb 00 - 1 carp3
10.20.80/2410.20.80.1 C  00 - 4 carp4
10.20.80.1 00:00:5e:00:01:01  UHLl   00 - 1 carp4
10.20.80.255   10.20.80.1 Hb 00 - 1 carp4
10.90/16   10.20.70.33GS 00 -23 carp3
10.91/16   10.20.70.33GS 00 -23 carp3
10.100.2/2410.100.2.2 C  0 4016 - 4
carp901
10.100.2.2 00:00:5e:00:01:01  UHLl   0   24 - 1
carp901
10.100.2.255   10.100.2.2 Hb 00 - 1
carp901
10.100.3/2410.100.2.1 GS 00 -23
carp901
10.100.100/24  10.100.100.2   UC 00 - 4 axe0
10.100.100.2   00:60:6e:d5:a1:eb  UHLl   00 - 1 axe0
10.100.100.255 10.100.100.2   UHb00 - 1 axe0
10.103.204/24  192.168.253.1  GS 00 -23
carp31
10.148.192/22  10.148.192.1   C  0 1630 - 4
carp11
10.148.192.1   00:00:5e:00:01:01  UHLl   0  329 - 1
carp11
10.148.195.255 10.148.192.1   Hb 00 - 1
carp11
10.148.224/23  10.148.224.1   C  0  112 - 4
carp10
10.148.224.1   00:00:5e:00:01:01  UHLl   04 - 1
carp10
10.148.225.255 10.148.224.1

Re: problem with carp on 5.9, MAC address of carp interface?

2016-04-25 Thread Sebastian Reitenbach

Hi,

On Monday, April 25, 2016 14:02 CEST, Kim Zeitler 
wrote:

> Hello Martin
>
> before I go further - I just run a ping test with the tcpdump as you
> requested and it did work. The only thing that was changed was an
> upgrade from GENERIC.MP#1983 -> GENERIC.MP#1997.

the only thing I did for such test was running the 5.9 userland with a
GENERIC.MP#1996 amd64, but I haven't seen any difference.

Sebastian


>
> On 04/25/16 11:56, Martin Pieuchot wrote:
> >>
>  He is running a carp interface on top of a vlan interface. In this
scenario
>  the carp interface can not be pinged but the vlan interfaces can.
> >>>
> >>> Do you mean the CARP node does not answer to ping with a destination
> >>> address on the carp(4) interfaces?  Is it for MASTER, BACKUP or both?
> >>>
> >> em2 (no ip) ---> vlan100 (192.168.150.200) ---> carp2 (192.168.150.1)
> >>  \
> >>   --> vlan101 (192.168.151.200) ---> carp3 (192.168.151.1)
> >>
> >> This is my setup
> >> if I ping either address assigned to carp2 or carp3 from a host on the
> >> network I do not get an answer, pinging the vlan address answers.
> >
> > When doing so, please use "# tcpdump -nvei carp2 icmp" to see if the
> > echo request/reply reach/leave the interface.
>
> >
> >> One node is clearly in MASTER, the other in BACKUP, demote works.
> >
> > The routing table correspond to which node?  MASTER or BACKUP?  There's
> > something really weird in it, the RTF_CLONING routes are done.
> The table was from the MASTER.
>
> What do you mean exactly by 'the RTF_CLONING routes are done.'? I read
> route(4) and if I understand it correctly a wildcard route such as
> defaults is marked with it and new routes are created as soon as they
> are used and marked as RTF)CLONED.
> >
> > Could you include your whole routing table?  Do you have an entry for
> > the machine initiating the ping?
> >
> >> The host also has two further carp interfaces sitting directly on a
physical
> >> interface which work as expected.
> >
> > Then why excluding this information from the table?
> >
> Here is the entire routing table (be warned it is 'long')
> # route -n show -inet
> Routing tables
>
> Internet:
> DestinationGatewayFlags   Refs  Use   Mtu  Prio
> Iface
> default192.168.3.1UGS0   171986 - 8
> em1
> 224/4  127.0.0.1  URS149977 32768 8
> lo0
> 10.0.0/24  10.0.0.2   UC 10 - 4
> em3
> 10.0.0.1   90:e2:ba:c3:df:7f  UHLc   097189 - 4
> em3
> 10.0.0.2   90:e2:ba:c3:df:7b  UHLl   085607 - 1
> em3
> 10.0.0.255 10.0.0.2   UHb00 - 1
> em3
> 127/8  127.0.0.1  UGRS   03 32768 8
> lo0
> 127.0.0.1  127.0.0.1  UHl11 32768 1
> lo0
> 172.16/16  172.16.0.198   UC89   295390 - 4
> em0
> 172.16/16  172.16.0.200   CP 00 - 4
> carp0
> 172.16/16  172.16.0.197   CP 00 - 4
> carp0
> 172.16.0.1 52:54:00:a9:8e:ab  UHLc   0   143368 - 4
> em0
> 172.16.0.5 8a:2f:e3:6e:00:64  UHLc   0   141541 - 4
> em0
> 172.16.0.6 00:0c:29:71:10:bd  UHLc   0   238784 - 4
> em0
> 172.16.0.8 52:54:00:9f:d4:df  UHLc   0   151386 - 4
> em0
> ...
> 172.16.0.196   fe:b6:96:ee:53:5a  UHLc   0   125966 - 4
> em0
> 172.16.0.197   00:00:5e:00:01:c8  UHLl   0 5417 - 1
> carp0
> 172.16.0.198   90:e2:ba:c3:df:78  UHLl   0 8220 - 1
> em0
> 172.16.0.199   90:e2:ba:c3:df:7c  UHLc   0 4705 - 4
> em0
> 172.16.0.200   00:00:5e:00:01:c8  UHLl   012612 - 1
> carp0
> 172.16.0.202   52:54:00:c8:0f:d2  UHLc   0   27 - 4
> em0  172.16.254.99  78:48:59:d6:77:1c  UHLc   0   289643 -
> 4 em0
> 172.16.255.255 172.16.0.198   UHb00 - 1
> em0
> 172.16.255.255 172.16.0.200   HPb00 - 1
> carp0
> 172.16.255.255 172.16.0.197   HPb00 - 1
> carp0
> 172.17/16  192.168.3.11   UGS0   820865 - 8
> em1
> 172.18/16  192.168.3.11   UGS0  555 - 8
> em1
> 172.19/16  192.168.3.11   UGS0   150326 - 8
> em1
> 172.20/16  192.168.3.11   UGS061888 - 8
> em1
> 172.30.0/24192.168.3.11   UGS00 - 8
> em1
> 172.31/16  192.168.3.10   UGS00 - 8
> em1
> 192.168.2/24   192.168.2.229  UC 2  506 - 4
> em1
> 192.168.2/24   192.168.2.3C  00 - 4
> carp1
> 192.168.2.1c0:25:06:2a:eb:38  UHLc   0  759 - 4

Re: problem with carp on 5.9, MAC address of carp interface?

2016-04-26 Thread Sebastian Reitenbach

On Monday, April 25, 2016 11:56 CEST, Martin Pieuchot 
wrote:

> On 25/04/16(Mon) 11:35, Kim Zeitler wrote:
> > Hello Martin
> >
> >
> > On 04/25/16 11:12, Martin Pieuchot wrote:
> > >On 25/04/16(Mon) 10:47, Kim Zeitler wrote:
> >
> > >>He is running a carp interface on top of a vlan interface. In this
scenario
> > >>the carp interface can not be pinged but the vlan interfaces can.
> > >
> > >Do you mean the CARP node does not answer to ping with a destination
> > >address on the carp(4) interfaces?  Is it for MASTER, BACKUP or both?
> > >
> > em2 (no ip) ---> vlan100 (192.168.150.200) ---> carp2 (192.168.150.1)
> > \
> >  --> vlan101 (192.168.151.200) ---> carp3 (192.168.151.1)
> >
> > This is my setup
> > if I ping either address assigned to carp2 or carp3 from a host on the
> > network I do not get an answer, pinging the vlan address answers.
>
> When doing so, please use "# tcpdump -nvei carp2 icmp" to see if the
> echo request/reply reach/leave the interface.

I tried again this morning, but I unfortunately messed up with the tcpdump,
the produced file has 0 size :(

I did shut down the "old" 5.2 master node, and restarted the "backup" node,
just to be sure to have a clean state.

I did this on carp90, and then pinging my default gateway.

again like yesterday, I saw this in the dmesg of the default gateway:

Apr 26 05:02:00 srv93 /bsd: arp info overwritten for 172.16.99.1 by
90:e2:ba:2c:b5:08 on trunk0
Apr 26 05:05:43 srv93 /bsd: arp info overwritten for 172.16.99.1 by
00:00:5e:00:01:01 on trunk0
Apr 26 05:06:27 srv93 /bsd: arp info overwritten for 172.16.99.1 by
90:e2:ba:2c:b5:08 on trunk0
Apr 26 05:06:28 srv93 /bsd: arp info overwritten for 172.16.99.1 by
00:00:5e:00:01:01 on trunk0
Apr 26 05:23:32 srv93 /bsd: arp info overwritten for 172.16.99.1 by
90:e2:ba:2c:b5:08 on trunk0
Apr 26 05:23:32 srv93 /bsd: arp info overwritten for 172.16.99.1 by
00:00:5e:00:01:01 on trunk0
Apr 26 05:27:38 srv93 /bsd: arp info overwritten for 172.16.99.1 by
90:e2:ba:2c:b5:08 on trunk0
Apr 26 05:27:42 srv93 /bsd: arp info overwritten for 172.16.99.1 by
00:00:5e:00:01:01 on trunk0

On the problematic firewall, I see this arp entry for the upstream firewall:
172.16.99.2  00:00:5e:00:01:03 carp90 13m55s

which looks good to me.

Unfortunately the tcpdump is missing, seeing the MAC addresses that go out :(

anyways, attached netstat -rn -f inet directly after startup of the firewall,
before the ping
to the default gateway, as well as after pinging the default gateway.

However, what I did from a desktop to the firewall:

Desktop IP: 10.10.0.31/24
FW IP: 10.10.0.1/24

arp on the Carp Firewall:
10.10.0.31   88:51:fb:56:30:3b  carp7 19m55s

arp on the desktop (a windows box):

  Internet Address  Physical Address  Type
  10.10.0.1 00-00-5e-00-01-01 dynamic

That seems to be fine, and arp resolution should work.

Then I pinged from the desktop the 10.10.0.1, but did not receieved any answer
packet.

On the firewall, at least that I rememver, I ran tcpdump on carp7, as well as
on vlan7,
but I did not saw any packets flying by. I messed a bit with tcpdump on the
underlying trunk,
only ran tcpdump -n -i trunk0 -e -v icmp, so I missed the vlan packets and
cannot say if
these showed up there.

here the ifconfig output again:

default gateway stack:
ix0 and ix1 -> trunk0 -> vlan90 -> carp90

stack to the desktop:
ix0 and ix1 -> trunk0 -> vlan7 -> carp7

ix0:
flags=18b43
mtu 1500
lladdr 90:e2:ba:2c:b5:08
description: PHYS_INT_TRK
priority: 0
trunk: trunkdev trunk0
media: Ethernet autoselect
status: no carrier
root@srv80:~# ifconfig ix1
ix1:
flags=18b43
mtu 1500
lladdr 90:e2:ba:2c:b5:08
description: PHYS_INT_TRK
priority: 0
trunk: trunkdev trunk0
media: Ethernet autoselect (10GSFP+Cu full-duplex)
status: active
root@srv80:~# ifconfig trunk0
trunk0: flags=8943 mtu 1500
lladdr 90:e2:ba:2c:b5:08
description: INTERNAL_TRUNK
priority: 0
trunk: trunkproto lacp
trunk id: [(8000,90:e2:ba:2c:b5:08,4045,,),
 (,00:00:00:00:00:00,,,)]
trunkport ix1 active,collecting,distributing
trunkport ix0
groups: trunk
media: Ethernet autoselect
status: active
inet 192.168.9.252 netmask 0xff00 broadcast 192.168.9.255
root@srv80:~# ifconfig vlan90
vlan90: flags=8943 mtu 1500
lladdr 90:e2:ba:2c:b5:08
description: NKE_IPB_VLAN
priority: 0
vlan: 90 parent interface: trunk0
groups: vlan
root@srv80:~# ifconfig carp90
carp90: flags=8843 mtu 1500
lladdr 00:00:5e:00:01:01
description: NKE_IPB
priority: 15
carp: BACKUP carpdev vlan90 vhid 1 advbase 1 advskew 100
groups: carp
status: backup
inet 172.16.99.1 netmask 0xff00 broadcast 172.16

pf prio queue not setting vlan prio value?

2016-05-30 Thread Sebastian Reitenbach

Hi,


I tried to get priority queueing set up to prioritize some
VoIP traffic. I'm on 5.9, a carp clustered firewall.

Just some testing so far, but I got a bit confused, about
whether it is really doing what it is supposed to do.

pf.conf(5) tells me about 'set prio':
 If the packet is transmitted on a vlan(4) interface, the queueing
 priority will also be written as the priority code point in the 802.1Q VLAN
header.


The network 10.1.0.0/24 is where the asterisk is around, VLAN 8,
VLAN 90 is going upstream to the Internet.

I've these very basic testing rules added to the
front of my pf.conf:
match log from 10.1.0.0/24 to any set prio 5
match log to 10.1.0.0/24 set prio 5
pass log quick from 10.1.0.0/24 to any set prio 5
pass log quick to 10.1.0.0/24 set prio 5

otherwise, no scrub rules,

pfctl -sr shows these as:

match log inet from <__automatic_611bb878_0> to any set ( prio 5 )
match log inet from any to <__automatic_611bb878_1> set ( prio 5 )
pass log quick inet from <__automatic_611bb878_2> to any flags S/SA set ( prio
5 )
pass log quick inet from any to <__automatic_611bb878_3> flags S/SA set ( prio
5 )

I know the rules are a bit overly redundant, but only first tried
match rules, since the example in pf.conf(5) is only using pass
rules.

Ping from the firewall host 10.1.0.1 to one of the nodes in the
10.1.0.2 network I see with tcpdump on pflog0:

May 30 11:18:13.132330 rule 22/(match) [uid 0, pid 22065] match out on vlan8:
10.1.0.1 > 10.1.0.2: icmp: echo request (id:6221 seq:0) (ttl 255, id 34775,
len 84, bad ip cksum 56c! -> 1fcd)
May 30 11:18:13.132337 rule 23/(match) [uid 0, pid 22065] match out on vlan8:
10.1.0.1 > 10.1.0.2: icmp: echo request (id:6221 seq:0) (ttl 255, id 34775,
len 84, bad ip cksum 56c! -> 1fcd)
May 30 11:18:13.132342 rule 24/(match) [uid 0, pid 22065] pass out on vlan8:
10.1.0.1 > 10.1.0.2: icmp: echo request (id:6221 seq:0) (ttl 255, id 34775,
len 84, bad ip cksum 56c! -> 1fcd)

since they match/pass, prio should be applied, right?
Is there a way to see how/if the prio got applied?

With tcpdump, I see 'pri 0' on all the packets captured:

tcpdump -n -i trunk0 -vvv vlan 8 and net 10.1.0.0/24
11:18:13.132570 802.1Q vid 8 pri 0 10.1.0.2 > 10.1.0.1: icmp: echo reply
(id:6221 seq:0) [icmp cksum ok] (ttl 64, id 11179, len 84)
11:18:14.138835 802.1Q vid 8 pri 0 10.1.0.2 > 10.1.0.1: icmp: echo reply
(id:6221 seq:1) [icmp cksum ok] (ttl 64, id 11180, len 84)
11:18:15.129273 802.1Q vid 8 pri 0 10.1.0.2 > 10.1.0.1: icmp: echo reply
(id:6221 seq:2) [icmp cksum ok] (ttl 64, id 11181, len 84)


Just wondering whether I shouldn't see the pri set to 5, or is that to be
expected what I see?

Maybe I'm just missing something stupid?

thanks,
Sebastian

Re: pf prio queue not setting vlan prio value?

2016-05-31 Thread Sebastian Reitenbach

On Monday, May 30, 2016 16:45 CEST, Alexey Suslikov
 wrote:

> Sebastian Reitenbach  l00-bugdead-prods.de> writes:
>
> > With tcpdump, I see 'pri 0' on all the packets captured:
> >
> > tcpdump -n -i trunk0 -vvv vlan 8 and net 10.1.0.0/24
> > 11:18:13.132570 802.1Q vid 8 pri 0 10.1.0.2 > 10.1.0.1: icmp: echo reply
> > (id:6221 seq:0) [icmp cksum ok] (ttl 64, id 11179, len 84)
> > 11:18:14.138835 802.1Q vid 8 pri 0 10.1.0.2 > 10.1.0.1: icmp: echo reply
> > (id:6221 seq:1) [icmp cksum ok] (ttl 64, id 11180, len 84)
> > 11:18:15.129273 802.1Q vid 8 pri 0 10.1.0.2 > 10.1.0.1: icmp: echo reply
> > (id:6221 seq:2) [icmp cksum ok] (ttl 64, id 11181, len 84)
>
> You are not showing *all* packets captured, but only incoming ones
> (I assume you are pinging *from* the box, so echo replies are incoming).
>
> prio to vlan pri translation only applies to outgoing packets. Incoming
> packets will have vlan pri values set by a transmitter (or intermediate
> equipment, like switches).
>

crap, I got bitten by that tcpdump too often already, I pinged from the
firewal againl, saw
the rules fire:

May 31 06:58:46.445728 rule 22/(match) match out on vlan8: 10.1.0.1 >
10.1.0.166: icmp: echo request
May 31 06:58:46.445734 rule 23/(match) match out on vlan8: 10.1.0.1 >
10.1.0.166: icmp: echo request
May 31 06:58:46.445739 rule 24/(match) pass out on vlan8: 10.1.0.1 >
10.1.0.166: icmp: echo request

to another host, that has the VLAN, where I did the packet capture:

08:57:34.041856 802.1Q vid 8 pri 0 10.1.0.1 > 10.1.0.166: icmp: echo request
(id:0a65 seq:50) (ttl 255, id 10942, len 84)
08:57:34.041876 802.1Q vid 8 pri 0 10.1.0.166 > 10.1.0.1: icmp: echo reply
(id:0a65 seq:50) (ttl 255, id 14515, len 84)
08:57:35.041809 802.1Q vid 8 pri 0 10.1.0.1 > 10.1.0.166: icmp: echo request
(id:0a65 seq:51) (ttl 255, id 2179, len 84)
08:57:35.041829 802.1Q vid 8 pri 0 10.1.0.166 > 10.1.0.1: icmp: echo reply
(id:0a65 seq:51) (ttl 255, id 28359, len 84)

The 10.1.0.1 is a CARP IP, on a VLAN interface. The VLAN interface sits on top
of a trunk(0), which
sits on top of two ix(4)

Sebastian

xenocara crash with NVIDIA Quadro NVS 285 on snapshot

2014-05-29 Thread Sebastian Reitenbach

Hi,

yesterday I updated my desktop from a 5.2 or 5.3, to a current snapshot, now to 
find
the X server dying on me. See Xorg.0.log, xdm.log and dmesg below.

So I went back, installed a 5.5 release, where starting X just worked.

Afterward again, back to the snapshot.

I built, xenocara with debug symbols, following instructions
in the README, giving me the following backtrace:

(gdb) bt
#0  0x133e268f0fea in kill () at :2
#1  0x133e26953239 in abort () at /usr/src/lib/libc/stdlib/abort.c:53
#2  0x133c21c42a6b in OsAbort () at /home/xenocara/xserver/os/utils.c:1372
#3  0x133c21ab802c in ddxGiveUp (error=EXIT_ERR_ABORT) at 
/home/xenocara/xserver/hw/xfree86/common/xf86Init.c:1078
#4  0x133c21ab8155 in AbortDDX (error=EXIT_ERR_ABORT) at 
/home/xenocara/xserver/hw/xfree86/common/xf86Init.c:1122
#5  0x133c21c4c4d4 in AbortServer () at /home/xenocara/xserver/os/log.c:770
#6  0x133c21c4ca9f in FatalError (f=0x133c21d7f5c8 "Caught signal %d (%s). 
Server aborting\n")
at /home/xenocara/xserver/os/log.c:911
#7  0x133c21c3fc46 in OsSigHandler (signo=11, sip=0x7f7bea30, 
unused=0x7f7be950)
at /home/xenocara/xserver/os/osinit.c:147
#8  
#9  0x133e2ede2ee2 in ?? ()
#10 0x133e2f806952 in _dl_bind (object=0x7f7bee30, index=Variable 
"index" is not available.
) at /usr/src/libexec/ld.so/amd64/rtld_machine.c:404
#11 0x133e2f802811 in _dl_bind_start () at 
/usr/src/libexec/ld.so/amd64/ldasm.S:143
#12 0x00010160 in ?? ()
#13 0x133e4000 in ?? ()
#14 0x0ff0 in ?? ()
#15 0x133e3188b800 in ?? ()
#16 0x259d54a0 in ?? ()
#17 0x in ?? ()
Current language:  auto; currently asm


Due to the xdm.log and seen the GLX extension being loaded as the last
thing before the segfault, I changed the xorg.conf, adding:

Section "Module"
  Disable "glx"
EndSection

on a restart of xdm, the x server again segfaulted, but without the line
about loading GLX extension.

When I use the vesa driver instead of the nv driver, my X starts up, but
with lousy resolution :(

any hint what I should try next?

Sebastian

[19.858] 
X.Org X Server 1.15.1
Release Date: 2014-04-13
[19.859] X Protocol Version 11, Revision 0
[19.859] Build Operating System: OpenBSD 5.5 amd64 
[19.859] Current Operating System: OpenBSD communicator.ds9 5.5 
GENERIC.MP#151 amd64
[19.859] Build Date: 29 May 2014  08:01:20AM
[19.859]  
[19.859] Current version of pixman: 0.32.4
[19.859]Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[19.859] Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[19.859] (==) Log file: "/var/log/Xorg.0.log", Time: Thu May 29 08:20:33 
2014
[19.869] (==) Using config file: "/etc/X11/xorg.conf"
[19.869] (==) Using system config directory 
"/usr/X11R6/share/X11/xorg.conf.d"
[19.888] (==) No Layout section.  Using the first Screen section.
[19.888] (==) No screen section available. Using defaults.
[19.888] (**) |-->Screen "Default Screen Section" (0)
[19.888] (**) |   |-->Monitor ""
[19.888] (==) No monitor specified for screen "Default Screen Section".
Using a default monitor configuration.
[19.889] (**) Option "NoTrapSignals" "true"
[19.889] (==) Disabling SIGIO handlers for input devices
[19.889] (==) Automatically adding devices
[19.889] (==) Automatically enabling devices
[19.889] (==) Not automatically adding GPU devices
[19.977] (==) FontPath set to:
/usr/X11R6/lib/X11/fonts/misc/,
/usr/X11R6/lib/X11/fonts/TTF/,
/usr/X11R6/lib/X11/fonts/OTF/,
/usr/X11R6/lib/X11/fonts/Type1/,
/usr/X11R6/lib/X11/fonts/100dpi/,
/usr/X11R6/lib/X11/fonts/75dpi/
[19.977] (==) ModulePath set to "/usr/X11R6/lib/modules"
[19.977] (II) The server relies on wscons to provide the list of input 
devices.
If no devices become available, reconfigure wscons or disable 
AutoAddDevices.
[19.988] (II) Loader magic: 0x32b2e890420
[19.988] (II) Module ABI versions:
[19.988]X.Org ANSI C Emulation: 0.4
[19.988]X.Org Video Driver: 15.0
[19.988]X.Org XInput driver : 20.0
[19.988]X.Org Server Extension : 8.0
[20.009] (--) checkDevMem: using aperture driver /dev/xf86
[20.009] (--) PCI:*(0:1:0:0) 10de:0165:10de:0334 rev 161, Mem @ 
0xee00/16777216, 0xd000/268435456, 0xef00/16777216, BIOS @ 
0x/131072
[20.009] (--) PCI: (0:5:2:0) 109e:036e:0070:13eb rev 17, Mem @ 
0xe0001000/4096
[20.009] Initializing built-in extension Generic Event Extension
[20.009] Initializing built-in extension SHAPE
[20.009] Initializing built-in extension MIT-SHM
[20.009] Initializing built-in extension XInputExtension
[20.009] Initializing

Re: xenocara crash with NVIDIA Quadro NVS 285 on snapshot

2014-05-29 Thread Sebastian Reitenbach

On Thursday, May 29, 2014 10:19 CEST, Matthieu Herrb  wrote: 
 
> On 29/5/14 9:09 , Sebastian Reitenbach wrote:
> > Hi,
> > 
> > yesterday I updated my desktop from a 5.2 or 5.3, to a current snapshot, 
> > now to find
> > the X server dying on me. See Xorg.0.log, xdm.log and dmesg below.
> > 
> > So I went back, installed a 5.5 release, where starting X just worked.
> > 
> > Afterward again, back to the snapshot.
> > 
> > I built, xenocara with debug symbols, following instructions
> > in the README, giving me the following backtrace:
> > 
> > (gdb) bt
> > #0  0x133e268f0fea in kill () at :2
> > #1  0x133e26953239 in abort () at /usr/src/lib/libc/stdlib/abort.c:53
> > #2  0x133c21c42a6b in OsAbort () at 
> > /home/xenocara/xserver/os/utils.c:1372
> > #3  0x133c21ab802c in ddxGiveUp (error=EXIT_ERR_ABORT) at 
> > /home/xenocara/xserver/hw/xfree86/common/xf86Init.c:1078
> > #4  0x133c21ab8155 in AbortDDX (error=EXIT_ERR_ABORT) at 
> > /home/xenocara/xserver/hw/xfree86/common/xf86Init.c:1122
> > #5  0x133c21c4c4d4 in AbortServer () at 
> > /home/xenocara/xserver/os/log.c:770
> > #6  0x133c21c4ca9f in FatalError (f=0x133c21d7f5c8 "Caught signal %d 
> > (%s). Server aborting\n")
> > at /home/xenocara/xserver/os/log.c:911
> > #7  0x133c21c3fc46 in OsSigHandler (signo=11, sip=0x7f7bea30, 
> > unused=0x7f7be950)
> > at /home/xenocara/xserver/os/osinit.c:147
> > #8  
> > #9  0x133e2ede2ee2 in ?? ()
> > #10 0x133e2f806952 in _dl_bind (object=0x7f7bee30, index=Variable 
> > "index" is not available.
> > ) at /usr/src/libexec/ld.so/amd64/rtld_machine.c:404
> > #11 0x133e2f802811 in _dl_bind_start () at 
> > /usr/src/libexec/ld.so/amd64/ldasm.S:143
> > #12 0x00010160 in ?? ()
> > #13 0x133e4000 in ?? ()
> > #14 0x0ff0 in ?? ()
> > #15 0x133e3188b800 in ?? ()
> > #16 0x259d54a0 in ?? ()
> > #17 0x in ?? ()
> > Current language:  auto; currently asm
> > 
> > 
> > Due to the xdm.log and seen the GLX extension being loaded as the last
> > thing before the segfault, I changed the xorg.conf, adding:
> > 
> > Section "Module"
> >   Disable "glx"
> > EndSection
> > 
> > on a restart of xdm, the x server again segfaulted, but without the line
> > about loading GLX extension.
> > 
> > When I use the vesa driver instead of the nv driver, my X starts up, but
> > with lousy resolution :(
> > 
> > any hint what I should try next?
> > 
> 
> Can you disable xdm, run the failing server and capture stdout and
> stderr. The fact that the backtrace goes through dl_* stuff seem to
> indicate a failure while loading a shared object. ld.so writes its
> errors to stderr and this doesn't get captured in Xorg.0.log
> 
> There may be something intesting to read here.
> 
> Otherwise build the xf86-video-nv with debugging symbols too and get a
> backtrace, if possible by running Xorg directly under gdb, rather than
> from a core file. From a remote login run sudo gdb Xorg and then 'r' ...

OK, running in gdb, it stopped here:

Program received signal SIGSEGV, Segmentation fault.
0x03bc18f1feea in NVPreInit (pScrn=0x3bc16035800, flags=0)
at /home/xenocara/driver/xf86-video-nv/src/nv_driver.c:1929
1929Mode->type = M_T_DRIVER;
(gdb) list
1924/* If DFP, add a modeline corresponding to its panel size */
1925if (pNv->FlatPanel && !pNv->Television && pNv->fpWidth && 
pNv->fpHeight) {
1926DisplayModePtr Mode;
1927
1928Mode = xf86CVTMode(pNv->fpWidth, pNv->fpHeight, 60.00, TRUE, 
FALSE);
1929Mode->type = M_T_DRIVER;
1930pScrn->monitor->Modes = NVModesAdd(pScrn->monitor->Modes, Mode);
1931
1932if (!config_mon_rates) {
1933if (!Mode->HSync)
(gdb) bt
#0  0x03bc18f1feea in NVPreInit (pScrn=0x3bc16035800, flags=0)
at /home/xenocara/driver/xf86-video-nv/src/nv_driver.c:1929
#1  0x03ba112b6991 in InitOutput (pScreenInfo=0x3ba118e0660, argc=1, 
argv=0x7f7de6e8)
at /home/xenocara/xserver/hw/xfree86/common/xf86Init.c:597
#2  0x03ba112603da in dix_main (argc=1, argv=0x7f7de6e8, 
envp=0x7f7de6f8)
at /home/xenocara/xserver/dix/main.c:200
#3  0x03ba112414e7 in main (argc=1, argv=0x7f7de6e8, 
envp=0x7f7de6f8)
at /home/xenocara/xserver/dix/stubmain.c:34


after setting a breakpoint on xf86CVTMode, I stepped through it, and
at the end, Mode was:

(gdb) 
295 r

Re: xenocara crash with NVIDIA Quadro NVS 285 on snapshot

2014-05-29 Thread Sebastian Reitenbach

On Thursday, May 29, 2014 18:04 CEST, Philip Guenther  
wrote: 
 
> On Thu, May 29, 2014 at 3:35 AM, Sebastian Reitenbach <
> sebas...@l00-bugdead-prods.de> wrote:
> 
> > On Thursday, May 29, 2014 10:19 CEST, Matthieu Herrb 
> > wrote:
> >
> ...
> 
> > after setting a breakpoint on xf86CVTMode, I stepped through it, and
> > at the end, Mode was:
> >
> > (gdb)
> > 295 return Mode;
> > (gdb) print Mode
> > $3 = (DisplayModeRec *) 0x3bc16033800
> >
> 
> Full 64bit pointer there...
> 
> 
> NVPreInit (pScrn=0x3bc16035800, flags=0) at
> > /home/xenocara/driver/xf86-video-nv/src/nv_driver.c:1929
> > 1929Mode->type = M_T_DRIVER;
> > (gdb) print Mode
> > $5 = 0x16033800
> >
> 
> But just a 32bit value here.  That's almost certainly a sign that
> nv_driver.c isn't pulling in the header where xf86CVTMode() is declared,
> resulting it being treated as returning an int.  Perhaps compile with
> -Wmissing-prototypes to confirm and see whether there are other cases...

Doh! I compared  both values, and didn't saw the second one
is shorter :(
Anyways, with -Wmissing-prototypes I got warning as you suspected,
and I also checked the savage driver, where I got the same warning.

patch below fixes NV for me, and gets rid of the same warning in the
savage driver.

Either OK? or take it as inspiration for a better fix ;)

thanks for the help,
Sebastian


Index: xf86-video-nv/src/nv_driver.c
===
RCS file: /cvs/xenocara/driver/xf86-video-nv/src/nv_driver.c,v
retrieving revision 1.16
diff -u -p -u -r1.16 nv_driver.c
--- xf86-video-nv/src/nv_driver.c   18 Nov 2013 19:45:41 -  1.16
+++ xf86-video-nv/src/nv_driver.c   29 May 2014 17:17:16 -
@@ -32,6 +32,7 @@
 
 #include "xf86int10.h"
 #include "vbeModes.h"
+#include "xf86Modes.h"
 
 const   OptionInfoRec * RivaAvailableOptions(int chipid, int busid);
 BoolRivaGetScrnInfoRec(PciChipsets *chips, int chip);
Index: xf86-video-savage/src/savage_driver.c
===
RCS file: /cvs/xenocara/driver/xf86-video-savage/src/savage_driver.c,v
retrieving revision 1.9
diff -u -p -u -r1.9 savage_driver.c
--- xf86-video-savage/src/savage_driver.c   12 May 2013 13:06:25 -  
1.9
+++ xf86-video-savage/src/savage_driver.c   29 May 2014 17:18:14 -
@@ -54,6 +54,7 @@
 
 
 #include "xf86xv.h"
+#include "xf86Modes.h"
 
 #include "savage_driver.h"
 #include "savage_pciids.h"

problem with IPSec between OpenBSD 5.5 and Cisco 2901

2014-06-17 Thread Sebastian Reitenbach

Hi,

I'm trying to establish an IPSec tunnel between an OpenBSD 5.5 (amd64)
box and a Cisco 2901, the whole day, but doesn't seem to
get it to work. I think I have something wrong with the 
crypto transforms for phase two, since this NO_PROPOSAL_CHOSEN
I get in the logs, which I think is in phase two.


Network looks similar to this one:


Host behind OBSD (192.168.13.12/24)
 |
 |
OBSD (XXX.191.219.14)  
 |
 |
Internet
 |
 |
NAT FW (XXX.217.33.11)
 |
 |
Internal Network
 |
 |
Cisco 2901 (192.168.14.126)
 |
 |
Host behind Cisco (192.168.13.19/24)



Yes, they have both the same network behind each VPN Endpoints.
Something, more or less the same we have up and running between 
two Cisco 2901. 


OpenBSD configuration:


rem_gw="XXX.217.33.11"
bb_gw="XXX.191.219.14"

ike active esp from { 192.168.13.12 } to { 192.168.13.19 } \
local $bb_gw peer $rem_gw \
main auth hmac-sha1 enc aes-128 group modp1024 \
quick auth hmac-md5 enc 3des group none \
psk "SuperTopSecret"



crypto isakmp policy 1
 encr aes
 authentication pre-share
 group 2
crypto isakmp key SuperTopSecret address XXX.191.219.14  no-xauth
crypto isakmp keepalive 30 5

crypto ipsec transform-set ESP-3DES-MD5 esp-3des esp-md5-hmac

crypto map TO_BB 1 ipsec-isakmp 
 set peer XXX.191.219.14
 set transform-set ESP-3DES-MD5 
 match address 101


interface GigabitEthernet0/1
 description outside-interface
 ip address 192.168.14.126 255.255.255.0
 duplex auto
 speed auto
 crypto map TO_BB


access-list 101 permit ip host 192.168.13.12 host 192.168.13.19


I think from the logs, see below, Phase one gets established, but then
it runs into trouble with Phase 2, at least how I would interpret the logs:

On the Cisco, status looks like:


# show crypto isakmp sa 
IPv4 Crypto ISAKMP SA
dst src state  conn-id status
192.168.14.126  XXX.191.219.14  QM_IDLE   1442 ACTIVE

IPv6 Crypto ISAKMP SA

#show crypto ipsec sa 

interface: GigabitEthernet0/1
Crypto map tag: TO_BBN, local addr 192.168.14.126

   protected vrf: (none)
   local  ident (addr/mask/prot/port): (192.168.13.12/255.255.255.255/0/0)
   remote ident (addr/mask/prot/port): (192.168.13.19/255.255.255.255/0/0)
   current_peer XXX.191.219.14 port 500
 PERMIT, flags={origin_is_acl,}
#pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0
#pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#send errors 0, #recv errors 0

 local crypto endpt.: 192.168.14.126, remote crypto endpt.: XXX.191.219.14
 path mtu 1500, ip mtu 1500, ip mtu idb GigabitEthernet0/1
 current outbound spi: 0x0(0)
 PFS (Y/N): N, DH group: none

 inbound esp sas:

 inbound ah sas:

 inbound pcp sas:

 outbound esp sas:

 outbound ah sas:

 outbound pcp sas:

On the OpenBSD box it looks like:
ipsecctl -s all 

 
FLOWS:
No flows

SAD:
No entries


isakmpd with isakmpd -d -D A=75 -K,
after loading the configuration, trying to connect to the remote
endpoint:

171646.650413 Timr 10 timer_handle_expirations: event ui_conn_reinit(0x0)
171646.650515 Misc 30 connection_reinit: reinitializing connection list
171646.650592 Timr 10 timer_add_event: event connection_checker(0x20f87dac0) 
added last, expiration in 0s
171646.650722 Misc 60 connection_record_passive: passive connection 
"from-192.168.13.12-to-192.168.13.19" added
171646.650811 Timr 10 timer_handle_expirations: event 
connection_checker(0x20f87dac0)
171646.650884 Timr 10 timer_add_event: event connection_checker(0x20f87dac0) 
added last, expiration in 60s
171646.650943 Sdep 70 pf_key_v2_connection_check: SA for 
from-192.168.13.12-to-192.168.13.19 missing
171646.651021 Trpt 70 transport_setup: added 0x2018f7680 to transport list
171646.651092 Trpt 70 transport_setup: added 0x2018f7280 to transport list
171646.651150 Trpt 70 transport_setup: virtual transport 0x2018f7b00
171646.651227 Timr 10 timer_add_event: event exchange_free_aux(0x2018f6e00) 
added last, expiration in 120s
171646.651288 Cryp 60 hash_get: requested algorithm 1
171646.651356 Exch 10 exchange_establish_p1: 0x2018f6e00 
peer-XXX.217.33.11-local-XXX.191.219.14 
phase1-peer-XXX.217.33.11-local-XXX.191.219.14 policy initiator phase 1 doi 1 
exchange 2 step 0
171646.651429 Exch 10 exchange_establish_p1: icookie 7128cf36d74c89f1 rcookie 

171646.651492 Exch 10 exchange_establish_p1: msgid  
171646.651554 SA   70 sa_enter: SA 0x2018f6800 added to SA list
171646.651606 SA   60 sa_create: sa 0x2018f6800 phase 1 added to exchange 
0x2018f6e00 (peer-XXX.217.33.11-local-XXX.191.219.14)
171646.651704 Misc 70 attribute_set_constant: no PRF in the 
ph

Re: problem with IPSec between OpenBSD 5.5 and Cisco 2901

2014-06-18 Thread Sebastian Reitenbach

On Wednesday, June 18, 2014 08:49 CEST, Remi Locherer  
wrote: 

> On Tue, Jun 17, 2014 at 05:34:27PM +0200, Sebastian Reitenbach wrote:
> > Hi,
> > 
> > I'm trying to establish an IPSec tunnel between an OpenBSD 5.5 (amd64)
> > box and a Cisco 2901, the whole day, but doesn't seem to
> > get it to work. I think I have something wrong with the 
> > crypto transforms for phase two, since this NO_PROPOSAL_CHOSEN
> > I get in the logs, which I think is in phase two.
> > 
> > 
> > Network looks similar to this one:
> > 
> > 
> > Host behind OBSD (192.168.13.12/24)
> >  |
> >  |
> > OBSD (XXX.191.219.14)  
> >  |
> >  |
> > Internet
> >  |
> >  |
> > NAT FW (XXX.217.33.11)
> >  |
> >  |
> > Internal Network
> >  |
> >  |
> > Cisco 2901 (192.168.14.126)
> >  |
> >  |
> > Host behind Cisco (192.168.13.19/24)
> > 
> > 
> > 
> > Yes, they have both the same network behind each VPN Endpoints.
> > Something, more or less the same we have up and running between 
> > two Cisco 2901. 
> 
> How is this supposed to work with the same subnet on each site?
> Do you add special routes on the hosts behind the VPN gateways?

Yes, the hosts have host routes to the other side set via the VPN hosts.

> 
> The -L option from isakmpd helped me often to see what's happening.

Thanks for pointing me to the -L option.

I started afresh, on OpenBSD side:
rem_gw="XXX.217.33.11"
my_gw="XXX.191.219.14"

ike active esp tunnel from { 192.168.13.12 } to { 192.168.13.19 } \
local $my_gw peer $rem_gw \
main auth hmac-md5 enc 3des group modp1024 \
quick auth hmac-md5 enc 3des group none \
psk "MYSECRETKEY"

and in /etc/isakmpd/isakmpd.conf I've defined lifetimes:
[General]
Listen-on=XXX.191.219.14
Default-phase-1-lifetime=   28800,60:86400
Default-phase-2-lifetime=   1200,60:86400

On the cisco side it looks like:

crypto isakmp policy 1
 encr 3des
 hash md5
 authentication pre-share
 group 2
 lifetime 28800
crypto isakmp key MYSECRETKEY address XXX.191.219.14 
crypto isakmp nat keepalive 500
!
crypto ipsec security-association lifetime kilobytes disable
crypto ipsec security-association lifetime seconds 1200
!
crypto ipsec transform-set ESP-3DES-MD5 esp-3des esp-md5-hmac 
!
 set security-association lifetime kilobytes 4608000
 set security-association lifetime seconds 3600
!
!
crypto map TO_BB 1 ipsec-isakmp 
 set peer XXX.191.219.14
 set security-association lifetime kilobytes disable
 set transform-set ESP-3DES-MD5 
 match address 101

looking at the captured packets from isakmpd
tcpdump -vvv -r /var/run/isakmpd.pcap -n

I think, phase 1, looks all fine, phase 2, TRANSFORM ID, 
LIFE_TYPE, LIFE_DURATION, AUTHENTICATION_ALGORITHM, and 
the Payloads with the IPV4_ADDR matches between both.

The only difference I see, but I'm unsure if this is OK or not, is that
the OpenBSD box sends ENCAPSULATION_MODE = TUNNEL, and the
Cisco box sends ENCAPSULATION_MODE = UDP_ENCAP_TUNNEL.
I'm not sure if that is expected, since the Cisco is behind a NAT
gateway.

In the debug output from isakmpd, more below, I see those
packets that came from the cisco:
102303.210480 Mesg 70 DOI: IPSEC
102303.210491 Mesg 70 PROTO: 
102303.210501 Mesg 70 SPI_SZ: 4
102303.210510 Mesg 70 MSG_TYPE: STATUS_DOI_MIN

Is the "Unknown 3" referring to isakmpd/ipsec_num.cst 
UDP_ENCAP_TUNNEL which is 3?

While looking into it, I figured that the cisco was about 15 minutes
behind in time, but setting the clock correctly, didn't helped anything.

So, is the different ENCAPSULATION_MODE now a problem?

Sebastian

10:22:32.494155 XXX.191.219.14.500 > XXX.217.33.11.500: [udp sum ok] isakmp 
v1.0 exchange ID_PROT
cookie: c46e426b216a4511-> msgid:  len: 180
payload: SA len: 52 DOI: 1(IPSEC) situation: IDENTITY_ONLY 
payload: PROPOSAL len: 40 proposal: 1 proto: ISAKMP spisz: 0 
xforms: 1
payload: TRANSFORM len: 32
transform: 0 ID: ISAKMP
attribute ENCRYPTION_ALGORITHM = 3DES_CBC
attribute HASH_ALGORITHM = MD5
attribute AUTHENTICATION_METHOD = PRE_SHARED
attribute GROUP_DESCRIPTION = MODP_1024
attribute LIFE_TYPE = SECONDS
attribute LIFE_DURATION = 28800
payload: VENDOR len: 20
payload: VENDOR len: 20 (supports v2 NAT-T, 
draft-ietf-ipsec-nat-t-ike-02)
payload: VENDOR len: 20 (supports v3 NAT-T, 
draft-ietf-ipsec-nat-t-ike-03)
payload: VENDOR len: 20 (supports NAT-T, RFC 3947)
payload: VENDOR len: 20 (supports DPD v1.0) [ttl 0] (id 1, len 208)
10:22:32.659144 XXX.217.33.11

Re: problem with IPSec between OpenBSD 5.5 and Cisco 2901

2014-06-18 Thread Sebastian Reitenbach

On Wednesday, June 18, 2014 15:27 CEST, Stuart Henderson  
wrote: 
 
> On 2014-06-18, Sebastian Reitenbach  wrote:
> > The only difference I see, but I'm unsure if this is OK or not, is that
> > the OpenBSD box sends ENCAPSULATION_MODE = TUNNEL, and the
> > Cisco box sends ENCAPSULATION_MODE = UDP_ENCAP_TUNNEL.
> > I'm not sure if that is expected, since the Cisco is behind a NAT
> > gateway.
> 
> Try 
> http://packetmischief.ca/files/openbsd/patches/isakmpd-nat-t-encap-mode.diff
> 
> For the configuration where I had problems with nat-t interop with cisco, I 
> had
> to just get it working so I replaced the isakmpd box with an asa5505.
> 

yay, applied the patch, restarted isakmpd, loaded the ipsec configuration, and 
voila,
flows and SAs got established.

So the patch, even it if it looks a bit hackish, was able to "fix" the problem.


many thanks,
Sebastian

cheers,
Sebastian

Re: automatic installation with site.tgz

2014-07-24 Thread Sebastian Reitenbach

On Wednesday, July 23, 2014 21:09 CEST, Peter Hessler  
wrote: 
 
> I just set this up on some systems at $work, and here is what I have
> 
> ...
> Set name(s) = +site*

or just "site*", or "all" works for me.

> Unverified sets: site55.tgz. Continue without verification = yes
> ...
> 

and you need this line too:
Checksum test for site55.tgz failed. Continue anyway? = yes

> and make sure you add it to install.txt

I've a script preparing my siteXX.txt, that adds this line to index.txt:

VERSION=55
echo "-rw-r--r--  1 1001  04478607 Apr  9 10:34:09 2014 site${VERSION}.tgz" 
>> index.txt




> 
> 
> 
> On 2014 Jul 23 (Wed) at 20:07:49 +0200 (+0200), Waldemar Brodkorb wrote:
> :Hi OpenBSD Hackers,
> :
> :what is the correct way to set a variable in install.conf
> :to automatically extract siteXX.tgz while doing automatic
> :installations?
> :We tried "Set Name = all", but this did not work.
> :All sets excluding site.tgz are installed.
> :
> :Thanks
> : Waldemar
> :
> 
> -- 
> I think pop music has done more for oral intercourse than anything else
> that has ever happened, and vice versa.
>   -- Frank Zappa

Re: unbound on ~ last 2-3 snapshots - i386

2014-07-26 Thread Sebastian Reitenbach

On Saturday, July 26, 2014 10:04 CEST, Todd Zimmermann 
 wrote: 

> Have name resolution failure after an upgrade ( rebooting into the the
> new system) on my crusty i386 server. A # kill -9 'unbound pid' plus
> starting unbound from rc.d after and everything is fine. Might have
> been going on for awhile, but usually it works itself out.
> 
> -- Z
> 

 I had sent message about unbound (subject unbound reverse DNS problem to local 
stub zone) 
on May 17, also on i386.
But I have only problems with reverse DNS lookups on a local zone, hosted by
nsd on the same host. Restarting unbound, makes the lookup work again for a 
given
IP, but then might make reverse lookup fail for others :(

This is still the case for me with more recent snapshots, the last I have 
running 
on that box is from June 15.

Sebastian

Re: unbound reverse DNS problem to local stub zone

2014-07-26 Thread Sebastian Reitenbach

On Saturday, July 26, 2014 17:35 CEST, Sonic  wrote: 

> On Sat, Jul 26, 2014 at 11:21 AM, Sonic  wrote:
> > If you're just using a /24 as your access-control seems to indicate
> > try replacing the above with (this works great for me):
> > local-zone: "0.0.10.in-addr.arpa." transparent
> >
> > and update the stub-zone name to read:
> > name: "0.0.10.in-addr.arpa."
> 
> And, of course you NSD zone name must be:
> zone:
> name: "0.0.10.in-addr.arpa"
> zonefile: "10.0.0.zone"
> 
> (although the zonefile doesn't have to strictly be named as such)

I indeed only use a /24, so I changed as you suggested, and it seems to help. 
But the problem was not apparrent all the time, will monitor it, if it comes 
back with this new configuration, hope not. 
Anyways, I still find it odd, that it worked only halfway with the other
configuration I had before, and a simple restart of unbound fixed it. 

thanks,
Sebastian

Re: unbound reverse DNS problem to local stub zone

2014-07-27 Thread Sebastian Reitenbach

On Sunday, July 27, 2014 11:20 CEST, Patrik Lundin 
 wrote: 
 
> On Sat, Jul 26, 2014 at 07:34:16PM +0200, Sebastian Reitenbach wrote:
> > On Saturday, July 26, 2014 17:35 CEST, Sonic  wrote: 
> >  
> > > On Sat, Jul 26, 2014 at 11:21 AM, Sonic  wrote:
> > > > If you're just using a /24 as your access-control seems to indicate
> > > > try replacing the above with (this works great for me):
> > > > local-zone: "0.0.10.in-addr.arpa." transparent
> > > >
> > > > and update the stub-zone name to read:
> > > > name: "0.0.10.in-addr.arpa."
> > > 
> > > And, of course you NSD zone name must be:
> > > zone:
> > > name: "0.0.10.in-addr.arpa"
> > > zonefile: "10.0.0.zone"
> > > 
> > > (although the zonefile doesn't have to strictly be named as such)
> >  
> > I indeed only use a /24, so I changed as you suggested, and it seems to 
> > help. 
> > But the problem was not apparrent all the time, will monitor it, if it 
> > comes 
> > back with this new configuration, hope not. 
> > Anyways, I still find it odd, that it worked only halfway with the other
> > configuration I had before, and a simple restart of unbound fixed it. 
> >  
> 
> My understanding is that "transparent" is used when you want to override
> certain records in a zone with local-data configured in unbound.conf.
> Given that you have no such things in the pasted configuration
> "nodefault" is probably a better choice.
> 
> How is/was the reverse zone configured in nsd? I am currently trying to
> debug an issue i've seen when the stub-zone in unbound is wider ("name:
> "10.in-addr.arpa") than the zone in nsd (name: "0.0.10.in-addr.arpa").
> 
> To me the following is seen:
> # dig @127.0.0.1 -x 10.0.0.1 <-- works
> # dig @127.0.0.1 -x 10.0.0.2 <-- fails
> # dig @127.0.0.1 -x 10.0.0.3 <-- works
> # dig @127.0.0.1 -x 10.0.0.4 <-- works
> 
> Basically the first lookup works, the second ends up at IANA (as if the
> stub-zone configuration did not exist), and any
> following lookups work again.
> 
> It might be considered bad to tell unbound a server is authorative for a
> wider zone than it actually is though, can this be the same problem you
> saw?

Yes, I think that's how I had it too, but with "nodefault" instead of 
"transparent".
For the requests that failed, I've seen requests going out to the root DNS 
servers trying to resolve my private IPs.

In unbound, I only had the 10.in-addr.arpa and in nsd I have 
0.0.10.in-addr.arpa.
I only had to change unbound configuration as suggested, which up to now
seems to work reliable.

And when you restart unbound, then dig for 10.0.0.2 might start working, 
and digging others may fail. IIRC, after a restart, the first one or two 
reverse 
records I looked up, then worked as expected, others then started to fail, 
that worked before. Only very seldomly, all reverse lookups worked
after a restart of unbound.

Sebastian
> 
> Regards,
> Patrik Lundin

Re: unbound on ~ last 2-3 snapshots - i386

2014-07-28 Thread Sebastian Reitenbach

On Monday, July 28, 2014 12:46 CEST, Stuart Henderson  
wrote: 
 
> On 2014-07-26, Sebastian Reitenbach  wrote:
> > On Saturday, July 26, 2014 10:04 CEST, Todd Zimmermann 
> >  wrote: 
> >  
> >> Have name resolution failure after an upgrade ( rebooting into the the
> >> new system) on my crusty i386 server. A # kill -9 'unbound pid' plus
> >> starting unbound from rc.d after and everything is fine. Might have
> >> been going on for awhile, but usually it works itself out.
> >> 
> >> -- Z
> >> 
> >  
> >  
> >  I had sent message about unbound (subject unbound reverse DNS problem to 
> > local stub zone) 
> > on May 17, also on i386.
> > But I have only problems with reverse DNS lookups on a local zone, hosted by
> > nsd on the same host. Restarting unbound, makes the lookup work again for a 
> > given
> > IP, but then might make reverse lookup fail for others :(
> >
> > This is still the case for me with more recent snapshots, the last I have 
> > running 
> > on that box is from June 15.
> 
> Didn't this go away when you changed to the correct zone names?
> 
>"In unbound, I only had the 10.in-addr.arpa and in nsd I have
>0.0.10.in-addr.arpa. I only had to change unbound configuration as
>suggested, which up to now seems to work reliable.""
> 
 
 That comment was from me, with the problem I had.

Sebastian

Re: unbound reverse DNS problem to local stub zone

2014-09-01 Thread Sebastian Reitenbach

On Monday, September 1, 2014 17:58 CEST, Arthur Mesh  
wrote: 
 
> On Sun, Jul 27, 2014 at 11:20:43AM +0200, Patrik Lundin wrote:
> > How is/was the reverse zone configured in nsd? I am currently trying to
> > debug an issue i've seen when the stub-zone in unbound is wider ("name:
> > "10.in-addr.arpa") than the zone in nsd (name: "0.0.10.in-addr.arpa").
> > 
> > To me the following is seen:
> > # dig @127.0.0.1 -x 10.0.0.1 <-- works
> > # dig @127.0.0.1 -x 10.0.0.2 <-- fails
> > # dig @127.0.0.1 -x 10.0.0.3 <-- works
> > # dig @127.0.0.1 -x 10.0.0.4 <-- works
> > 
> > Basically the first lookup works, the second ends up at IANA (as if the
> > stub-zone configuration did not exist), and any
> > following lookups work again.
> 
> I have the same exact symptom, unbound.conf:
> 
> server:
> interface: 127.0.0.1@53
> interface: 10.10.10.1@53
> verbosity: 1
> do-not-query-localhost: no
> do-ip6: no
> auto-trust-anchor-file: "/var/unbound/etc/root.key"
> 
> access-control: 0.0.0.0/0 refuse
> access-control: 127.0.0.0/8 allow
> access-control: 10.10.0.0/16 allow
> access-control: ::0/0 refuse
> access-control: ::1 allow
> 
> hide-identity: yes
> hide-version: yes
> 
> local-zone: "10.in-addr.arpa." nodefault
> 
> stub-zone:
> name: "10.in-addr.arpa."
> stub-addr: 127.0.0.1@5353
> 
> 
> # dig -p53 @127.0.0.1 -x 10.10.10.2 +short # works
> # dig -p53 @127.0.0.1 -x 10.10.10.1 +short # doesnt
> 
> If I dig directly to nsd, via -p5353
> # dig -p5353 @127.0.0.1 -x 10.10.10.2 +short # works
> # dig -p5353 @127.0.0.1 -x 10.10.10.1 +short # works
> 
> I have no good explanation as to what's going on. I've tried this on current
> (as opposed to 5.5), and issue does NOT go away.
> 
> On the NSD side, I have two zones
> 
> zone:
> name: 10.10.10.in-addr.arpa.
> zonefile: "db.10.10.10"
> 
> zone:
> name: 11.10.10.in-addr.arpa.
> zonefile: "db.10.10.11"
> 
 
 Not that I can explain it, but for me it helped on the unbound side to:

1. switch the local-zone from nondefault to transparent
2. make the stub-zone: name: match the zone names in nsd, for you
means, create two stub zones, for each of your zones you have in nsd.

Sebastian

Re: Libretto 70CT

2014-10-24 Thread Sebastian Reitenbach

On Thursday, October 23, 2014 22:59 CEST, Fred  wrote: 
 
> Hi Sebastian,
> 
> I've just installed -current on my Libretto 70CT - as you can see from 
> the output below it stoped with:
> 
> kernel: integer divide fault trap, code=0
> 
> Rebooted it and disable it, schsio and softraid and it has now made it 
> to the end of boot - but it has not yet made it to a login prompt.
> 
> Last time I tried this I left it running for about a week - and still 
> did not make it to a login prompt.

As I wrote on ports@, my Libretto 60 with 32 MB RAM, and disabled
"it" and "schsio" works, slow but, flawlessly. However no X, since ISA cards
are not supported by xorg anymore.

Sebastian
> 
> hth
> 
> Fred
> 
> PS I've CC misc@ for the archives rather than clog up ports@
> 
> Script started on Thu Oct 23 21:10:34 2014
> port:fred ~> cu -l /dev/cuaU0
> Connected to /dev/cuaU0 (speed 9600)
>  >> OpenBSD/i386 BOOT 3.26
> boot>
> \|/-\|/booting hd0a:/bsd: 
> -\|/-9699132\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\+1067500
>  
> [72+403280|/-\|/-\|/-\|/-\|/-\|/-\+397651|/-\|/-\|/-\|/-\|/-\|/-\|]=0xb083b0
> entry point at 0x200120
> 
> [ using 801416 bytes of bsd ELF symbol table ]
> Copyright (c) 1982, 1986, 1989, 1991, 1993
>   The Regents of the University of California.  All rights reserved.
> Copyright (c) 1995-2014 OpenBSD. All rights reserved. 
> http://www.OpenBSD.org
> 
> OpenBSD 5.6-current (GENERIC) #415: Wed Oct 22 11:33:32 MDT 2014
>  dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
> cpu0: Intel Pentium/MMX ("GenuineIntel" 586-class) 121 MHz
> cpu0: FPU,V86,DE,PSE,TSC,MSR,MCE,CX8,MMX
> real mem  = 16412672 (15MB)
> avail mem = 3915776 (3MB)
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: AT/286+ BIOS, date 11/11/97
> apm0 at bios0: Power Management spec V1.2
> pcibios at bios0 function 0x1a not configured
> bios0: ROM list: 0xe4000/0xc000
> cpu0 at mainbus0: (uniprocessor)
> cpu0: F00F bug workaround installed
> isa0 at mainbus0
> isadma0 at isa0
> com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
> com0: console
> com1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo
> pckbc0 at isa0 port 0x60/5
> pckbd0 at pckbc0 (kbd slot)
> pckbc0: using irq 1 for kbd slot
> wskbd0 at pckbd0: console keyboard
> pms0 at pckbc0 (aux slot)
> pckbc0: using irq 12 for aux slot
> wsmouse0 at pms0 mux 0
> vga0 at isa0 port 0x3b0/48 iomem 0xa/131072
> wsdisplay0 at vga0 mux 1: console (80x25, vt100 emulation), using wskbd0
> wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
> wdc0 at isa0 port 0x1f0/8 irq 14
> wd0 at wdc0 channel 0 drive 0: 
> wd0: 16-sector PIO, LBA, 1551MB, 3177216 sectors
> wd0(wdc0:0:0): using BIOS timings
> sb0 at isa0 port 0x220/24 irq 5 drq 1: dsp v3.01
> midi0 at sb0: 
> audio0 at sb0
> opl at sb0 not configured
> wss0 at isa0 port 0x530/8 irq 10 drq 0: CS4231 or AD1845 (vers 4)
> audio1 at wss0
> pcppi0 at isa0 port 0x61
> spkr0 at pcppi0
> lpt0 at isa0 port 0x378/4 irq 7
> npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16
> pcic0 at isa0 port 0x3e0/2 iomem 0xd/65536
> pcic0 controller 0:  has sockets A and B
> pcmcia0 at pcic0 controller 0 socket 0
> xe0 at pcmcia0 function 0 "Xircom, CreditCard 10Base-T, PS-CE2-10" port 
> 0x340/16, irq 9: address 00:80:c7:42:37:d9
> pcmcia1 at pcic0 controller 0 socket 1
> pcic0: irq 11, polling enabled
> vscsi0 at root
> scsibus1 at vscsi0: 256 targets
> softraid0 at root
> scsibus2 at softraid0: 256 targets
> kernel: integer divide fault trap, code=0
> Stopped at  cpu_switchto+0x64:  popl%ebx
> ddb> ps
> PID   PPID   PGRPUID  S   FLAGS  WAIT  COMMAND
>   13605  0  0  0  2 0x14200crypto
>   21232  0  0  0  2 0x14200pfpurge
>   18646  0  0  0  2 0x14200pcic0,0,1
>   14390  0  0  0  2 0x14200pcic0,0,0
>   28330  0  0  0  2 0x14200apm0
>1636  0  0  0  2 0x14200systqmp
>   12593  0  0  0  2 0x14200systq
>9503  0  0  0  2 0x14200syswq
>   25602  0  0  0  1 0x14200idle0
>2351  0  0  0  2 0x14200kmthread
> *1  0  0  0  7   0swapper
>   0

VAX donation request for package builds

2014-01-10 Thread Sebastian Reitenbach

Hi,

the VAXstation for the release builds died and the last one that got used 
up to now for package builds is now used for the release builds. 
That means, there is no VAX left for "regular" package builds, and release
package builds.

The VAXstation used so far was a VAXstation 4000/100, something with
eqivalent "speed" would be needed in Calgary for the package building again.



cheers,
Sebastian

urtw0 wpa2 working on Lemote?

2014-02-05 Thread Sebastian Reitenbach

Hi,

with my lemote, I tried to connect to WPA2 secured network at work.
Now I'm back at home, where I can connect without issues to 
my unsecured network.

When scanning for WLAN networks using my amd64 notebook, 
I usually see different dB values, but here, every network is 
143 dB signal strength. Is this a known limitation to the urtw driver?

# ifconfig urtw0 scan   
 
urtw0: flags=8802 mtu 1500
lladdr 00:17:c4:5a:1f:d4
priority: 4
groups: wlan
media: IEEE802.11 autoselect
status: no network
ieee80211: nwid "" 100dBm
nwid brb.freifunk.net chan 1 bssid 00:11:09:9a:9a:7e 143dB 11M 
short_preamble 
nwid "FRITZ!Box Fon WLAN 7170" chan 6 bssid 00:1c:4a:d5:eb:16 
143dB 54M privacy,short_slottime 
nwid "FRITZ!Box Fon WLAN 7240" chan 1 bssid 00:1f:3f:d1:48:d2 
143dB 54M privacy,short_preamble,short_slottime 
nwid WLAN-6E1076 chan 6 bssid 88:25:2c:6e:10:91 143dB 54M 
privacy,short_preamble,short_slottime 
nwid "FRITZ!Box Fon WLAN 7320" chan 11 bssid bc:05:43:f8:e9:49 
143dB 54M privacy,short_preamble,short_slottime 
nwid "Triple X" chan 11 bssid c0:25:06:2e:d6:7e 143dB 54M 
privacy,short_slottime 
nwid Demiurge chan 11 bssid e8:40:f2:16:5c:23 143dB 54M 
privacy,short_slottime 

Anyways, at work I specify the nwid and the wpakey like this:

ifconfig urtw0 nwid MYID wpakey SECRETKEY up

but status keeps telling me: no network
however, the manual page tells me that WPA and WPA2 should work.

any ideas?

Sebastian


# dmesg
[ using 489112 bytes of bsd ELF symbol table ]
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California.  All rights reserved.
Copyright (c) 1995-2014 OpenBSD. All rights reserved.  http://www.OpenBSD.org

OpenBSD 5.5-beta (GENERIC) #2: Tue Feb  4 11:37:08 CET 2014
root@loong.ds9:/usr/src/sys/arch/loongson/compile/GENERIC
real mem = 1073741824 (1024MB)
avail mem = 1058816000 (1009MB)
mainbus0 at root: Lemote Yeeloong
cpu0 at mainbus0: STC Loongson2F CPU 797 MHz, STC Loongson2F FPU
cpu0: cache L1-I 64KB D 64KB 4 way, L2 512KB 4 way
bonito0 at mainbus0: memory and PCI-X controller, rev 1
pci0 at bonito0 bus 0
rl0 at pci0 dev 7 function 0 "Realtek 8139" rev 0x10: irq 5, address 
00:23:8b:b5:37:62
rlphy0 at rl0 phy 0: RTL internal PHY
smfb0 at pci0 dev 8 function 0 "Silicon Motion LynxEM+" rev 0xb0
wsdisplay0 at smfb0 mux 1: console (std, vt100 emulation)
ohci0 at pci0 dev 9 function 0 "NEC USB" rev 0x44: irq 7, version 1.0
ehci0 at pci0 dev 9 function 1 "NEC USB" rev 0x05: irq 7
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 "NEC EHCI root hub" rev 2.00/1.00 addr 1
glxpcib0 at pci0 dev 14 function 0 "AMD CS5536 ISA" rev 0x03: rev 3, 32-bit 
3579545Hz timer, watchdog, gpio, i2c
isa0 at glxpcib0
pckbc0 at isa0 port 0x60/5
pckbd0 at pckbc0 (kbd slot)
pckbc0: using irq 1 for kbd slot
wskbd0 at pckbd0: console keyboard, using wsdisplay0
pms0 at pckbc0 (aux slot)
pckbc0: using irq 12 for aux slot
wsmouse0 at pms0 mux 0
mcclock0 at isa0 port 0x70/2: mc146818 or compatible
ykbec0 at isa0 port 0x381/3
gpio1 at glxpcib0: 32 pins
iic at glxpcib0 not configured
glxclk0 at glxpcib0: clock, prof
pciide0 at pci0 dev 14 function 2 "AMD CS5536 IDE" rev 0x01: DMA, channel 0 
wired to compatibility, channel 1 wired to compatibility
wd0 at pciide0 channel 0 drive 0: 
wd0: 4-sector PIO, LBA, 7815MB, 16007040 sectors
wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 2
pciide0: channel 1 ignored (disabled)
auglx0 at pci0 dev 14 function 3 "AMD CS5536 Audio" rev 0x01: isa irq 9, CS5536 
AC97
ac97: codec id 0x414c4760 (Avance Logic ALC655 rev 0)
audio0 at auglx0
ohci1 at pci0 dev 14 function 4 "AMD CS5536 USB" rev 0x02: isa irq 11, version 
1.0, legacy support
ehci1 at pci0 dev 14 function 5 "AMD CS5536 USB" rev 0x02: isa irq 11
usb1 at ehci1: USB revision 2.0
uhub1 at usb1 "AMD EHCI root hub" rev 2.00/1.00 addr 1
usb2 at ohci0: USB revision 1.0
uhub2 at usb2 "NEC OHCI root hub" rev 1.00/1.00 addr 1
usb3 at ohci1: USB revision 1.0
uhub3 at usb3 "AMD OHCI root hub" rev 1.00/1.00 addr 1
apm0 at mainbus0
umass0 at uhub1 port 1 configuration 1 interface 0 "Generic USB2.0-CRW" rev 
2.00/58.87 addr 2
umass0: using SCSI over Bulk-Only
scsibus0 at umass0: 2 targets, initiator 0
sd0 at scsibus0 targ 1 lun 0:  SCSI0 0/direct 
removable serial.0bda015811417340
urtw0 at uhub1 port 4 "Realtek RTL8187B" rev 2.00/2.00 addr 3
urtw0: RTL8187B rev E, address 00:17:c4:5a:1f:d4
vscsi0 at root
scsibus1 at vscsi0: 256 targets
softraid0 at root
scsibus2 at softraid0: 256 targets
pmon bootpath: /dev/disk/wd0
boot device: wd0
root on wd0a (4ce70288f4ecaf0f.a) swap on wd0b dump on wd0b

Re: urtw0 wpa2 working on Lemote?

2014-02-06 Thread Sebastian Reitenbach

On Wednesday, February 5, 2014 22:15 CET, Alexey Suslikov 
 wrote: 
 
> Sebastian Reitenbach  l00-bugdead-prods.de> writes:
> > Anyways, at work I specify the nwid and the wpakey like this:
> > 
> > ifconfig urtw0 nwid MYID wpakey SECRETKEY up
> > 
> > but status keeps telling me: no network
> > however, the manual page tells me that WPA and WPA2 should work.
> 
> from ifconfig(8):
> 
> wpakey passphrase | hexkey
>Set the WPA key and enable WPA.  The key can be given using
>either a passphrase or a full length hex key, starting with 0x.
>If a passphrase is used the nwid option must be set prior to
>specifying the wpakey option, since ifconfig will hash the nwid
>along with the passphrase to create the key.
> 

stupid /me. I was fairly sure that I also tried it manually, setting the
different values with different commands. I tried it now with a clean boot
in the correct order and it just works.
Thanks for cluebatting ;)

The only thing I still wonder is why all networks I see from a scan
show 143 dB network strength.

Sebastian

autoinstall on SGI Indigo

2014-03-28 Thread Sebastian Reitenbach

Hi,

reading the INSTALL.sgi with regard to autoinstall, and also the manpage 
I find that:

The "filename" DHCP
parameter specifies the installer mode, e.g. "auto_install".  On
architectures where this parameter is used for netbooting, create
a symbolic link named "auto_install" pointing to the boot program.

due to the old PROM it has, I have to retrieve two files from the
next-server like this:
bootp()bootecoff bootp()bsd.rd.IP22

example host entry for the Indigo:
host excelsior {
# SGI Irix Indigo (Indy)
next-server 10.0.0.27;
# filename "auto_install";
hardware ethernet 08:00:69:06:cc:6f;
fixed-address 10.0.0.31;
option host-name "excelsior";
}

then creating a symlink from bootecoff to auto_install, it fails retrieving 
bsd.rd.IP22,
...
arg 7: OSLoadFilename=/bsd
Boot: bootp()bsd.rd.IP22
cannot open /etc/random.seed: Device not configured
Setting $netaddr to 10.0.0.31 (from server )
Obtaining bsd.rd.IP22 from server 
bootp()bsd.rd.IP22: Inappropriate file type or format
Boot FAILED!

or vice versa, creating a symlink from bsd.rd.IP22 to auto_install, it fails to 
retrieve 
bootecoff:

>> bootp()bootecoff bootp()bsd.rd.IP22
Setting $netaddr to 10.0.0.31 (from server )
Obtaining bootecoff from server 

Cannot load bootp()bootecoff.
Unable to execute bootp()bootecoff

Basically to get both files from the TFTP server, I have to have the
filename parameter for that host commented out in dhcpd.conf file.
When then the bsd.rd.IP22 finished booting, and asks me what to do, 
i.e. install, upgrade, autoinstall etc. then I edit the dhcpd.conf uncommenting
the filename parameter, and select (A)utoinstall. 

Then it successfully retrieves my autoinstall script file from httpd and goes on
with the unattended installation. This then fails since the root disk is just 
too small
and, as far as I researched, there is no real way yet to edit the disklabel 
automatically.
But that's a different story.

So, re-using the next-server parameter to point to the httpd server that hosts
the installation configuration file, works for me, I have it set up on the same 
host
as the TFTP server. But with this host, the "filename" parameter definitely 
conflicts
with booting the kernel from the net.
Further, I have many different architectures, and this requirement to symlink 
the
auto_install file name to the boot file name needed for each architecture also
prevents to boot different architectures at the same time.

So, instead of re-using the filename dhcp option to define if to do an 
unattended
upgrade or installation, maybe a different option could be chosen that is not
conflicting with other common functionality.

Looking at some options here [1], option 150 (GRUB config path name), 
209 (Configuration file), or 129 (Kernel options) comes to mind.
But as far as I can see, the dhcpd doesn't support those custom options (yet)?

cheers,
Sebastian

[1] 
https://www.iana.org/assignments/bootp-dhcp-parameters/bootp-dhcp-parameters.xhtml

Re: autoinstall on SGI Indigo

2014-03-28 Thread Sebastian Reitenbach

On Friday, March 28, 2014 21:01 CET, "Sebastian Reitenbach" 
 wrote: 
 
> Hi,
> 
> reading the INSTALL.sgi with regard to autoinstall, and also the manpage 
> I find that:
> 
> The "filename" DHCP
> parameter specifies the installer mode, e.g. "auto_install".  On
> architectures where this parameter is used for netbooting, create
> a symbolic link named "auto_install" pointing to the boot program.
> 
> due to the old PROM it has, I have to retrieve two files from the
> next-server like this:
> bootp()bootecoff bootp()bsd.rd.IP22
> 
> example host entry for the Indigo:
> host excelsior {
> # SGI Irix Indigo (Indy)
> next-server 10.0.0.27;
> # filename "auto_install";
> hardware ethernet 08:00:69:06:cc:6f;
> fixed-address 10.0.0.31;
> option host-name "excelsior";
> }
> 
> then creating a symlink from bootecoff to auto_install, it fails retrieving 
> bsd.rd.IP22,
> ...
> arg 7: OSLoadFilename=/bsd
> Boot: bootp()bsd.rd.IP22
> cannot open /etc/random.seed: Device not configured
> Setting $netaddr to 10.0.0.31 (from server )
> Obtaining bsd.rd.IP22 from server 
> bootp()bsd.rd.IP22: Inappropriate file type or format
> Boot FAILED!
> 
> or vice versa, creating a symlink from bsd.rd.IP22 to auto_install, it fails 
> to retrieve 
> bootecoff:
> 
> >> bootp()bootecoff bootp()bsd.rd.IP22
> Setting $netaddr to 10.0.0.31 (from server )
> Obtaining bootecoff from server 
> 
> Cannot load bootp()bootecoff.
> Unable to execute bootp()bootecoff
> 
> Basically to get both files from the TFTP server, I have to have the
> filename parameter for that host commented out in dhcpd.conf file.
> When then the bsd.rd.IP22 finished booting, and asks me what to do, 
> i.e. install, upgrade, autoinstall etc. then I edit the dhcpd.conf 
> uncommenting
> the filename parameter, and select (A)utoinstall. 
> 
> Then it successfully retrieves my autoinstall script file from httpd and goes 
> on
> with the unattended installation. This then fails since the root disk is just 
> too small
> and, as far as I researched, there is no real way yet to edit the disklabel 
> automatically.
> But that's a different story.
> 
> So, re-using the next-server parameter to point to the httpd server that hosts
> the installation configuration file, works for me, I have it set up on the 
> same host
> as the TFTP server. But with this host, the "filename" parameter definitely 
> conflicts
> with booting the kernel from the net.
> Further, I have many different architectures, and this requirement to symlink 
> the
> auto_install file name to the boot file name needed for each architecture also
> prevents to boot different architectures at the same time.
> 
> So, instead of re-using the filename dhcp option to define if to do an 
> unattended
> upgrade or installation, maybe a different option could be chosen that is not
> conflicting with other common functionality.
> 
> Looking at some options here [1], option 150 (GRUB config path name), 
> 209 (Configuration file), or 129 (Kernel options) comes to mind.
> But as far as I can see, the dhcpd doesn't support those custom options (yet)?

just after sending it out, I figured dhcpd seems to support those options, at 
least
specifying them correctly in dhcpd.conf, dhcpd starts up without whining.

> 
> cheers,
> Sebastian
> 
> [1] 
> https://www.iana.org/assignments/bootp-dhcp-parameters/bootp-dhcp-parameters.xhtml

something fishy with portmapper on i386 snapshot?

2014-05-13 Thread Sebastian Reitenbach

Hi,

I've installed a i386 soekris box (10.0.0.27, called wormhole) from current 
snapshot, 
and trying to netboot a vax and a sparc, but I guess, they don't get to the 
bootparamd.

Here what I see from the vax (10.0.0.30), which loads the boot.mop from mopd 
running on the same
server fine, then in the boot prompt of the boot loader I get:

> boot
Trying BOOTPARAMS
boot: client IP address: 10.0.0.30
boot: client name: daedalus
nfs_open: must mount first.
open bsd: Invalid argument
bsd: boot failed: Invalid argument

This is the configuration on my soekris box with regard to rarpd, bootparamd, 
and nfs server with regard
to the vax (called daedalus) netboot configuration:

# cat /etc/bootparams
daedalusroot=wormhole:/export/vax
# cat /etc/ethers
08:00:2B:2D:33:2C   daedalus
# cat /etc/exports
/export/vax -maproot=root:wheel 10.0.0.30
# rpcinfo -p localhost
   program vers proto   port
102   tcp111  portmapper
102   udp111  portmapper
151   udp663  mountd
153   udp663  mountd
151   tcp702  mountd
153   tcp702  mountd
132   udp   2049  nfs
133   udp   2049  nfs
132   tcp   2049  nfs
133   tcp   2049  nfs
1000261   udp805  bootparam
# showmount -e localhost
Exports list on localhost:
/export/vax10.0.0.30
# ls -l /export/vax/
total 5024
-rw-r--r--  1 sebastia  wheel  2547676 May 11 01:43 bsd
~# ping daedalus
PING daedalus.ds9 (10.0.0.30): 56 data bytes
--- daedalus.ds9 ping statistics ---
2 packets transmitted, 0 packets received, 100.0% packet loss

With tcpdump I've seen, what I guess its getting rarp information correctly, 
then
broadcasting to try to find the bootparamd, the portmapper on my box answers,
and then its what I guess trying to contact the bootparamd, but this fails.
As I guess, its trying to contact the bootparamd on UDP port 639, but there
is nothing listen, bootparamd is listening on UDP 805. 
Does the portmapper give out the wrong port?

root@wormhole:~# tcpdump -n -i vr0 -e -ttt -vvv -s 2000 -X host 10.0.0.30
tcpdump: listening on vr0, link-type EN10MB
May 13 09:01:54.903204 00:00:24:c9:d4:98 08:00:2b:2d:33:2c 8035 42: rarp reply 
08:00:2b:2d:33:2c at 10.0.0.30
  : 0800 2b2d 332c  24c9 d498 8035 0001  ..+-3,..$5..
  0010: 0800 0604 0004  24c9 d498 0a00 001b  $...
  0020: 0800 2b2d 332c 0a00 001e ..+-3,

May 13 09:01:54.941453 08:00:2b:2d:33:2c ff:ff:ff:ff:ff:ff 0800 138: 
10.0.0.30.986 > 255.255.255.255.111: [udp sum ok] udp 96 (ttl 4, id 0, len 124)
  :    0800 2b2d 332c 0800 4500  +-3,..E.
  0010: 007c   0411 ac54 0a00 001e   .|...T..
  0020:  03da 006f 0068 e2d6  0027   .o.h.'..
  0030:   0002 0001 86a0  0002   
  0040: 0005  0001  0014     
  0050:          
  0060:    0001 86ba  0001   
  0070: 0001  0014  0001  000a   
  0080:     001e ..


the broadcast to the portmapper

May 13 09:01:54.949153 00:00:24:c9:d4:98 08:00:2b:2d:33:2c 0800 110: 
10.0.0.27.111 > 10.0.0.30.986: [bad udp cksum 9f2d!] udp 68 (ttl 64, id 49240, 
len 96, bad cksum 0! differs by a5fc)
  : 0800 2b2d 332c  24c9 d498 0800 4500  ..+-3,..$.E.
  0010: 0060 c058  4011  0a00 001b 0a00  .`.X..@.
  0020: 001e 006f 03da 004c 1496  0027   ...o...L.'..
  0030: 0001         
  0040:   0325  0024  0008 6461  .%...$da
  0050: 6564 616c 7573    0001   edalus..
  0060: 007f      0001   ..

the answer

May 13 09:01:54.980649 08:00:2b:2d:33:2c 00:00:24:c9:d4:98 0800 122: 
10.0.0.30.985 > 10.0.0.27.639: [udp sum ok] udp 80 (ttl 4, id 0, len 108)
  :  24c9 d498 0800 2b2d 332c 0800 4500  ..$.+-3,..E.
  0010: 006c   0411 a249 0a00 001e 0a00  .l...I..
  0020: 001b 03d9 027f 0058 db1a  0028   ...X.(..
  0030:   0002 0001 86ba  0001   
  0040: 0002  0001  0014     
  0050:          
  0060:     0008 6461 6564 616c  ..daedal
  0070: 7573  0004 726f 6f74 usroot

and here I think its trying to contact the bootparamd on the wrong port asking 
for the root device??

May 13 09:01:54.980829 00:00:24:c9:d4:98 08:00:2b:2d:33:2c 0800 70: 10.0.0.27 > 
10.0.0.30: icmp: 10.0.0.27 udp port 639 unreachable [icmp cksum ok] for 
10.0.0.30.985 > 10.0.0.27.639: udp 80 (ttl 4, id 0, len 108) (ttl 255, id 
16199, len 56, bad cksum 0! differs by 68

unbound reverse DNS problem to local stub zone

2014-05-17 Thread Sebastian Reitenbach

Hi,

I'm new to nsd/unbound, and maybe I did something wrong, however:

I run i386 snapshot, with nsd/unbound on the same host.
NSD listening on port 5353 is authoritative for 1 forward zone, and two
reverse zones, one IPv4 private addresses, and another IPv6 zone.

The forward zone, and the reverse IPv6 zone, there is no problem.

My unbound config, with the IPv6 zone removed, looks like this:

server:
#interface: 127.0.0.1
#interface: 127.0.0.1@5353  # listen on alternative port
#interface: ::1
# want to listen on all interfaces
interface: 0.0.0.0
interface: ::0
#do-ip6: no

# needed to query nsd on localhost for authoritative answers
do-not-query-localhost: no

# want to allow queries from local subnet and localhost
access-control: 0.0.0.0/0 refuse
access-control: 127.0.0.0/8 allow
access-control: 10.0.0.0/24 allow
access-control: ::0/0 refuse
access-control: ::1 allow

hide-identity: yes
hide-version: yes

# Uncomment to enable DNSSEC validation.
#
#auto-trust-anchor-file: "/var/unbound/db/root.key"

# Serve zones authoritatively from Unbound to resolver clients.
# Not for external service.
#
#local-zone: "local." static
#local-data: "mycomputer.local. IN A 192.0.2.51"
# needed to allow resolving of private IP addresses
local-zone: "10.in-addr.arpa." nodefault
#local-data-ptr: "192.0.2.51 mycomputer.local"

# UDP EDNS reassembly buffer advertised to peers. Default 4096.
# May need lowering on broken networks with fragmentation/MTU issues,
# particularly if validating DNSSEC.
#
#edns-buffer-size: 1480

# Use TCP for "forward-zone" requests. Useful if you are making
# DNS requests over an SSH port forwarding.
#
#tcp-upstream: yes

# the stub zones I want to resolve via nsd on localhost
stub-zone:
name: "ds9"
stub-addr: 127.0.0.1@5353

stub-zone:
name: "10.in-addr.arpa."
stub-addr: 127.0.0.1@5353


However, after a reboot of the box, reverse lookup
of any of the configured 10.0.0.X addresses fails. When I
restart unbound, then it just works as expected.

sebastia@wormhole:~/bin> nslookup 10.0.0.27 
  
Server: 127.0.0.1
Address:127.0.0.1#53

** server can't find 27.0.0.10.in-addr.arpa.: NXDOMAIN

sebastia@wormhole:~/bin> sudo /etc/rc.d/unbound restart 
  
unbound(ok)
unbound(ok)
sebastia@wormhole:~/bin> nslookup 10.0.0.27 
Server: 127.0.0.1
Address:127.0.0.1#53

Non-authoritative answer:
27.0.0.10.in-addr.arpa  name = wormhole.ds9.

Authoritative answers can be found from:
0.0.10.in-addr.arpa nameserver = wormhole.ds9.

sebastia@wormhole:~> nslookup 10.0.0.37 
Server: 127.0.0.1
Address:127.0.0.1#53

** server can't find 37.0.0.10.in-addr.arpa.: NXDOMAIN

sebastia@wormhole:~> nslookup 10.0.0.27 
sebastia@wormhole:~> sudo /etc/rc.d/unbound restart 
  
unbound(ok)
unbound(ok)
sebastia@wormhole:~> nslookup 10.0.0.37 
Server: 127.0.0.1
Address:127.0.0.1#53

Non-authoritative answer:
37.0.0.10.in-addr.arpa  name = communicator.ds9.

Authoritative answers can be found from:
0.0.10.in-addr.arpa nameserver = wormhole.ds9.

sebastia@wormhole:~>

I have about 30 hosts in that reverse zone configured. The more
often I restart unbound, the better it gets with returning results.

However, when I reboot the machine, then other lookups that
worked before might fail, and vice versa, others may work, I cannot
see a pattern. 

Looking at the unbound logs, I see a large amounts of trying
to connect to NSD, and it also gets answers of type THROWAWAY,
until unbound then decides to ask the root servers.

Is maybe my box (soekris net5501) too slow, so that NSD doesn't answer fast 
enough? Then, after some restarts of unbound, and queries to NSD, then
NSD has all in memory and then it just works? But then I don't understand
why it works without flaws for the forward zone, and also the IPv6 zone?

Someone has an idea?

Sebastian


OpenBSD 5.5-current (GENERIC) #112: Fri May 16 17:59:07 MDT 2014
t...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: Geode(TM) Integrated Processor by AMD PCS ("AuthenticAMD" 586-class) 500 
MHz
cpu0: FPU,DE,PSE,TSC,MSR,CX8,SEP,PGE,CMOV,CFLUSH,MMX,MMXX,3DNOW2,3DNOW
real mem  = 536375296 (511MB)
avail mem = 515190784 (491MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 20/80/26, BIOS32 rev. 0 @ 0xfac40
pcibios0 at bios0: rev 2.0 @ 0xf/0x1
pcibios0: pcib

network tuning for high bandwith and high latency

Hi,

I'm trying to tune the network speed of OpenBSD box for high bandwidht, and
high latency.
The box is connected to a 155MBit Internet uplink.

Hosts I have here next to me:
An old OpenBSD 4.4 box, used as server firewall, in front of a Linux http
server.
A new OpenBSD 5.0 box, used as http server.
A Linux OpenSUSE 11.2 box, used as http server.

Further I have:
A Linux based VM in Canada, which I use as client.
and using OpenBSD mirror artifiles.org as reference host.

First tests with the OpenBSD 4.4 firewall:

ping roundtrip times:

from the Linux VM in Canada to artfiles.org: about time=150 ms
from the Linux VM in Canada to my server/firewall: about time=155 ms
from my server to artifles.org: about 8/9 ms

Downloading src.tar.gz from the reference box artfiles.org from the Linux VM in
Canada:
I get about 7.9 MB/s

Downloading a file on the Linux VM from the Linux server behind the 4.4
Firewall I get about 2MB/s.
While downloading the src.tar.gz, the speed goes a bit up and down, i.e. up to
3.5 MB, and down to 700Kb.
I asked already a couple of years ago, and got an answer about the Bandwith *
Delay product from Otto. I calculated what to use for the tcp send and receive
buffers, but whatever I put there, it doesn't seem to matter much. Speed stays
at around 2MB/s.
Trying to download the file multiple times, then the speed of about 2MB/s is
divided to the amount of streams.

Then I took the OpenSUSE 11.2 box, and put it on the Internet link.
On that box, I downloaded again the src.tar.gz from artfiles.org, and got about
15/16 MB/s. So more or less the full 155MBit.

I installed apache2 on that box, and put the src.tar.gz in the htdocs, and
downloaded from the Linux VM in Canada. There I got
download speeds of average 2.6 MB/s.

Then I put a second harddisk in the PC and installled OpenBSD 5.0 amd64 on it.
Trying to download src.tar.gz from artfiles.org I got around 10MB/s, so about
5/6 MB/s fewer than with the Linux host.
Looking a bit closer on the ifconfig em0 output, I recognized, its running with
100MBit full duplex speed, but the box is connected to a Gigabit switch, and
can handle GigaBit. Under Linux it auto-negotiates 100MB/s full duplex.
So at least that explains me here, why I don't get the full 155MBit/s, but
still wondering, why the card doesn't support/use gigabit.
man em0 doesn't seem to mention the card I have, but also only states that the
82562V chipset only supports 10/100MBit.
A dmesg is attached.

Then I started apache, and put the src.tar.gz in its htdocs directory.
Downloading this src.tar.gz from the Linux VM in Canada, I get 1.45MB/s.
But this speed seems to be constant. When I downloaded from the Canadian VM
from the OpenSUSE 11.2 Linux host, or from the Linxu server behind the OpenBSD
4.4 Firewall, the speed was not stable, going up and down between 0.5 MBit and
3.X MBit.
But downloading directly from the 5.0 host, the speed goes up to 1.5MB/s, and
then more or less stays constantly at this speed.

In 5.0, the net.inet.tcp.recvspace, and net.inet.tcp.sendspace seem to be gone.
I was looking at
https://calomel.org/network_performance.html
what I can potentially do to speed up connection, but if I understand that
right, this article mostly focuses on speed up local LAN connections. Anyways,
I tried to raise the kern.bufcachepercent, and the net.inet.tcl.mssdflt, but
without noticeable difference.

In the FAQ I also don't find much help:
http://openbsd.das.ufsc.br/faq/faq6.html#Tuning

So, why I don't get the 155MBit I know when downloading from a near server, is
kind of understandable for me, but I still wonder whether there is a way to get
at least the same speed when downloading on the Canadian Linux VM, from the
OpenBSD 5.0 host here in Germany, so getting 2.6 MB/s instead of 1.45MB/s.

If someone could point me to the right RTFM, or has a hint at hand what might
be worth to try to tweak, please let me know.

Sebastian

OpenBSD 5.0 (GENERIC.MP) #63: Wed Aug 17 10:14:30 MDT 2011
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
RTC BIOS diagnostic error 80
real mem = 3209342976 (3060MB)
avail mem = 3109855232 (2965MB)
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xe3d70 (36 entries)
bios0: vendor Intel Corp. version "CO96510J.86A.5882.2007.0413.0100" date
04/13/2007
bios0: wortmann DQ965CO
acpi0 at bios0: rev 0
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC WDDT MCFG ASF! SSDT SSDT SSDT SSDT SSDT TCPA
acpi0: wakeup devices SLPB(S4) P32_(S4) UAR1(S4) UAR2(S4) ILAN(S4) PEGP(S4)
PEX0(S4) PEX1(S4) PEX2(S4) PEX3(S4) PEX4(S4) PEX5(S4) UHC1(S3) UHC2(S3)
UHC3(S3) UHC4(S3) EHCI(S3) EHC2(S3) UH42(S3) UHC5(S3) AZAL(S3)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM)2 CPU 6300 @ 1.86GHz, 1866.97 MHz
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FX

Re: network tuning for high bandwith and high latency

On Friday, December 2, 2011 15:04 CET, Kenneth R Westerback 
 wrote: 

> On Fri, Dec 02, 2011 at 02:08:57PM +0100, Sebastian Reitenbach wrote:
> > Hi,
> > 
> > I'm trying to tune the network speed of OpenBSD box for high bandwidht, and 
> > high latency.
> > The box is connected to a 155MBit Internet uplink.
> > 
> > Hosts I have here next to me:
> > An old OpenBSD 4.4 box, used as server firewall, in front of a Linux http 
> > server.
> > A new OpenBSD 5.0 box, used as http server.
> > A Linux OpenSUSE 11.2 box, used as http server.
> > 
> > Further I have:
> > A Linux based VM in Canada, which I use as client.
> > and using OpenBSD mirror artifiles.org as reference host.
> > 
> > First tests with the OpenBSD 4.4 firewall:
> 
> I got lost in the subsequent description of events, and came away with the
> impression that while you shuffled the clients and http servers around you
> did not change the firewall. Is this correct? If so, upgrading the firewall
> to 5.0 or -current is the easiest action likely to improve performance.

thanks for your answer, and sorry if my writing were not clear enough as I 
hoped it to be, I try to clarify:

One test was with a Linux Web Server behind the OpenBSD 4.4 firewall here in 
Germany.
When I download from the Linux VM in Canada, then I get about 2MB/s.

The other test is with a desktop, not behind the OpenBSD 4.4 Firewall, with two 
harddisks.
One with Linux OpenSUSE 11.2, one with OpenBSD 5.0. This desktop is directly 
connected to the 155MBit Internet line, parallel to the firewall.
Downloading on the Linux VM in Canada from the OpenSUSE 11.2 box, I get around 
2.6MB/s, just switching the Harddisk on the desktop
and downloading from the OpenBSD 5.0 I only get around 1.5MB/s.
So in this case, the 4.4 Firewall is not involved at all.
I'd at least hoped to get the same speed with the OpenBSD 5.0 like I get using 
Linux, so about 2.6MB/s.

hope its more clear now.

Sebastian

> 
>  Ken

Re: network tuning for high bandwith and high latency

On Friday, December 2, 2011 15:30 CET, Henning Brauer  
wrote: 

> * Sebastian Reitenbach  [2011-12-02 15:22]:
> > On Friday, December 2, 2011 15:04 CET, Kenneth R Westerback 
> >  wrote: 
> >  
> > > On Fri, Dec 02, 2011 at 02:08:57PM +0100, Sebastian Reitenbach wrote:
> > > > Hi,
> > > > 
> > > > I'm trying to tune the network speed of OpenBSD box for high bandwidht, 
> > > > and high latency.
> > > > The box is connected to a 155MBit Internet uplink.
> > > > 
> > > > Hosts I have here next to me:
> > > > An old OpenBSD 4.4 box, used as server firewall, in front of a Linux 
> > > > http server.
> > > > A new OpenBSD 5.0 box, used as http server.
> > > > A Linux OpenSUSE 11.2 box, used as http server.
> > > > 
> > > > Further I have:
> > > > A Linux based VM in Canada, which I use as client.
> > > > and using OpenBSD mirror artifiles.org as reference host.
> > > > 
> > > > First tests with the OpenBSD 4.4 firewall:
> > > 
> > > I got lost in the subsequent description of events, and came away with the
> > > impression that while you shuffled the clients and http servers around you
> > > did not change the firewall. Is this correct? If so, upgrading the 
> > > firewall
> > > to 5.0 or -current is the easiest action likely to improve performance.
> > 
> > thanks for your answer, and sorry if my writing were not clear enough as I 
> > hoped it to be, I try to clarify:
> > 
> > One test was with a Linux Web Server behind the OpenBSD 4.4 firewall here 
> > in Germany.
> > When I download from the Linux VM in Canada, then I get about 2MB/s.
> > 
> > The other test is with a desktop, not behind the OpenBSD 4.4 Firewall, with 
> > two harddisks.
> > One with Linux OpenSUSE 11.2, one with OpenBSD 5.0. This desktop is 
> > directly connected to the 155MBit Internet line, parallel to the firewall.
> > Downloading on the Linux VM in Canada from the OpenSUSE 11.2 box, I get 
> > around 2.6MB/s, just switching the Harddisk on the desktop
> > and downloading from the OpenBSD 5.0 I only get around 1.5MB/s.
> > So in this case, the 4.4 Firewall is not involved at all.
> > I'd at least hoped to get the same speed with the OpenBSD 5.0 like I get 
> > using Linux, so about 2.6MB/s.
> > 
> > hope its more clear now.
> 
> well, you actually found the answer yourself. if your em is running at
> 100M the 10MByte/s download is superb. Why it isn't going to gig - dunno.

Yes, Its also not my main concern, I guess, with a different card, I'd also get 
the full 155MBit like I get with Linux in this case.
I was just curious if someone knows why this card doesn't make GigaBit on 
OpenBSD, therefore appended dmesg... 
But as said, its not my main problem.

> 
> your other issue is wasting time, electrons, energy and whatnot with
> calomel.org garbage.
> 
> if someone feels like he could do the broader community a favor, track
> down whoever runs that site and at least ask him to remove that
> network tuning on openbsd page. or better all pages he has about
> openbsd - all garbage, bad advice, plain wrong, you get the idea.

OK, I got it, forgetting about calomel.org.
At least with older OpenBSD releases, there were the recvspace, and sendspace 
to tune the buffers used for the networking. Especially for the high bandwith 
and high latency case, they improved things for me in the past.

So when I understand you right, there are no knobs anymore I can tune?
Also the FAQ: http://www.openbsd.org/faq/faq6.html#Tuning says, it should not 
be necessary for most of the cases, as it states:
VERY FEW people will need to adjust any networking parameters!

But since with Linux, I get about 1MB/s more throughput on the overseas 
connection. Since the FAQ did not stated, there are no knobs, 
I was hoping there might be something I can tune for my use case?
If someone can say for sure, there is no knob I can tune, then I'll take it as 
is.
If there is someone who could explain, why its slower on OpenBSD, so that I 
could understand what the problem is, then I'd like to hear about it, and I'd 
be happy.
Well, not as happy as if I would be able to get the same throughput from the 
OpenBSD box ;)

thanks,
Sebastian

> 
> -- 
> Henning Brauer, h...@bsws.de, henn...@openbsd.org
> BS Web Services, http://bsws.de, Full-Service ISP
> Secure Hosting, Mail and DNS Services. Dedicated Servers, Root to Fully 
> Managed
> Henning Brauer Consulting, http://henningbrauer.com/

Re: network tuning for high bandwith and high latency

Hi,
On Friday, December 2, 2011 19:41 CET, Henning Brauer  
wrote: 

> * Sebastian Reitenbach  [2011-12-02 16:16]:
> > On Friday, December 2, 2011 15:30 CET, Henning Brauer 
> >  wrote: 
> > > well, you actually found the answer yourself. if your em is running at
> > > 100M the 10MByte/s download is superb. Why it isn't going to gig - dunno.
> > 
> > Yes, Its also not my main concern, I guess, with a different card, I'd also 
> > get the full 155MBit like I get with Linux in this case.
> > I was just curious if someone knows why this card doesn't make GigaBit on 
> > OpenBSD, therefore appended dmesg... 
> 
> i have never seen an em misnegotiating - but this might also have to
> do with the choice of switches.
> 
> > But as said, its not my main problem.
> 
> hmm, then i missed it.
> 
> > > your other issue is wasting time, electrons, energy and whatnot with
> > > calomel.org garbage.
> > > 
> > > if someone feels like he could do the broader community a favor, track
> > > down whoever runs that site and at least ask him to remove that
> > > network tuning on openbsd page. or better all pages he has about
> > > openbsd - all garbage, bad advice, plain wrong, you get the idea.
> > 
> > OK, I got it, forgetting about calomel.org.
> > At least with older OpenBSD releases, there were the recvspace, and 
> > sendspace to tune the buffers used for the networking. Especially for the 
> > high bandwith and high latency case, they improved things for me in the 
> > past.
> 
> the socket buffers are autosized these days. no more manual twiddling
> needed.
> 
> > So when I understand you right, there are no knobs anymore I can tune?
> 
> well, I usually touch ifq.len and the icmp err pps limit on higher
> bandwidth routers.
> 
> > Also the FAQ: http://www.openbsd.org/faq/faq6.html#Tuning says, it should 
> > not be necessary for most of the cases, as it states:
> > VERY FEW people will need to adjust any networking parameters!
> 
> that statement is true.
> 
> > But since with Linux, I get about 1MB/s more throughput on the
> > overseas connection. Since the FAQ did not stated, there are no
> > knobs, I was hoping there might be something I can tune for my use case?
> 
> the socket buffer autosizing algorithm might not raise enough in your
> case... and if that is indeed the culprit we need to adjust it.
> 
> > If someone can say for sure, there is no knob I can tune, then I'll
> > take it as is. 
> > If there is someone who could explain, why its slower on OpenBSD, so
> > that I could understand what the problem is, then I'd like to hear
> > about it, and I'd be happy. 
> 
> tracking that down isn't trivial.
> 
> at that point, I'd start to read the code and experiment.

Thanks to your pointers on icb, I found the autosizing algorithm at the end of 
netinet/tcp_userreg.c.
There I saw its comparing the actual value of fill level of the buffer, and how 
much got transferred against a 
maximum defined in sys/socketvar.h:

#define SB_MAX  (256*1024)

With the default value of 256*1024, I got the maximum transfer rate of about 
1.5MB/s.
This speed there was fairly constant, when the maximum was reached.
Then I doubled the value to 512*1024, and got constant transfer rates of about 
2.7MB/s, which is about the same speed like I got with the Linux host.
Then I again doubled the value to 1024*1024, and got speeds of about 5MB/s. 
This was not so constant anymore. Here I got spikes of up to 7MB/s, and in the 
middle it dropped down to 2-3 MB/s.
Then again doubled the value to 2048*1024, and then I got transfer speeds of 
about 8MB/s. So about 2.5 times faster than with Linux as the server. Also 
here, the transfer rates are not constant over the download, they are varying 
from 3MB/s and going up to over 9MB/s, nearly to the maximum the network card 
in the server provides (100MBit).

Since my knowledge to the network stack is next to zero, I don't really know 
what side effects it would have, to raise the default to a higher value, and if 
it would acceptable to have those varying transfer speeds, instead of the 
constant rates with the lower values.
Maybe a problem for machines with lower memory?

cheers,
Sebastian

> 
> -- 
> Henning Brauer, h...@bsws.de, henn...@openbsd.org
> BS Web Services, http://bsws.de, Full-Service ISP
> Secure Hosting, Mail and DNS Services. Dedicated Servers, Root to Fully 
> Managed
> Henning Brauer Consulting, http://henningbrauer.com/

Re: network tuning for high bandwith and high latency

2011-12-03 Thread Sebastian Reitenbach

 Hi,
On Saturday, December 3, 2011 14:24 CET, Henning Brauer  
wrote: 
 
> * Sebastian Reitenbach  [2011-12-03 01:12]:
> > Thanks to your pointers on icb, I found the autosizing algorithm at the end 
> > of netinet/tcp_userreg.c.
> > There I saw its comparing the actual value of fill level of the buffer, and 
> > how much got transferred against a 
> > maximum defined in sys/socketvar.h:
> > 
> > #define SB_MAX  (256*1024)
> > 
> > With the default value of 256*1024, I got the maximum transfer rate of 
> > about 1.5MB/s.
> > This speed there was fairly constant, when the maximum was reached.
> > Then I doubled the value to 512*1024, and got constant transfer rates of 
> > about 2.7MB/s, which is about the same speed like I got with the Linux host.
> > Then I again doubled the value to 1024*1024, and got speeds of about 5MB/s. 
> > This was not so constant anymore. Here I got spikes of up to 7MB/s, and in 
> > the middle it dropped down to 2-3 MB/s.
> > Then again doubled the value to 2048*1024, and then I got transfer speeds 
> > of about 8MB/s. So about 2.5 times faster than with Linux as the server. 
> > Also here, the transfer rates are not constant over the download, they are 
> > varying from 3MB/s and going up to over 9MB/s, nearly to the maximum the 
> > network card in the server provides (100MBit).
> 
> ok, so we're dealing with a high-latency high-bandwidth connection.

yep, as it states in the subject ;)

> there bigger buffers and thus seqnr windows help a lot - due to the
> latency.
> 
> > Since my knowledge to the network stack is next to zero, I don't really 
> > know what side effects it would have, to raise the default to a higher 
> > value, and if it would acceptable to have those varying transfer speeds, 
> > instead of the constant rates with the lower values.
> > Maybe a problem for machines with lower memory?
> 
> "low memory" is a bit misleading, we're talking about pretty special
> memory here - but yes, hundreds or thousands of sockets with 2MB buffers
> in use each would be a problem. there is a backpressure mechanism in
> the autosizing algorithm to (try to) avoid this; we might very well
> want to increase SB_MAX a bit.

Didn't had time today, I'll do some more testing, also even trying to find a 
gigabit card that  I can put into the box, just to see if I can get even more 
speed...

I'll then send a followup patch to tech@

thanks,
Sebastian


> 
> -- 
> Henning Brauer, h...@bsws.de, henn...@openbsd.org
> BS Web Services, http://bsws.de, Full-Service ISP
> Secure Hosting, Mail and DNS Services. Dedicated Servers, Root to Fully 
> Managed
> Henning Brauer Consulting, http://henningbrauer.com/

strange em network speeds and auto-negotiation

2011-12-04 Thread Sebastian Reitenbach

Hi,

With em0 and em1, both cards auto-negotiate GigaBit full-duplex on Linux on the 
same host. With OpenBSD, em0, the onboard network interface, only 
auto-negotiates 100MBit full duplex. Man em tells me, there are some chipsets 
that only make 100Mbit with OpenBSD, but this card is not in the list there, 
well its also not in the list of supported devices at all. So it might just 
miss the right support.

em1, negotiates also under OpenBSD gigabit, full-duplex, and on a Gigabit LAN 
connection, I get reasonable transfer rates of about 60MB/s.

Now the thing I'm courious about, which is with regard to high-bandwidht, high 
latency connections.

With em0, and SB_MAX tweaked to (2048*1024) see the other thread (network 
tuning for high bandwith and high latency)
I get transfer rates on such a link of about 8MB/s.
Swiching to use em0, even with the SB_MAX tweaked, I get only get transfer 
speeds of about 1.5MB/s, which is about the same speed with em0, without 
tweaking SB_MAX.

The card seems to be fine, since it does get about 60MB/s. on a LAN, so I 
wonder why I don't see the same or even better speeds with the high bandwidth 
high latency connection.

Sebastian


OpenBSD 5.0-current (GENERIC) #9: Sun Dec  4 12:24:15 CET 2011
r...@test.test.intern:/usr/src/sys/arch/amd64/compile/GENERIC
RTC BIOS diagnostic error 80
real mem = 3209342976 (3060MB)
avail mem = 3109867520 (2965MB)
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xe3d70 (36 entries)
bios0: vendor Intel Corp. version "CO96510J.86A.5882.2007.0413.0100" date 
04/13/2007
bios0: wortmann DQ965CO
acpi0 at bios0: rev 0
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC WDDT MCFG ASF! SSDT SSDT SSDT SSDT SSDT TCPA
acpi0: wakeup devices SLPB(S4) P32_(S4) UAR1(S4) UAR2(S4) ILAN(S4) PEGP(S4) 
PEX0(S4) PEX1(S4) PEX2(S4) PEX3(S4) PEX4(S4) PEX5(S4) UHC1(S3) UHC2(S3) 
UHC3(S3) UHC4(S3) EHCI(S3) EHC2(S3) UH42(S3) UHC5(S3) AZAL(S3)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM)2 CPU 6300 @ 1.86GHz, 1866.99 MHz
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,NXE,LONG
cpu0: 2MB 64b/line 8-way L2 cache
cpu0: apic clock running at 266MHz
cpu at mainbus0: not configured
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins
ioapic0: misconfigured as apic 0, remapped to apid 2
acpimcfg0 at acpi0 addr 0xf000, bus 0-127
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 7 (P32_)
acpiprt2 at acpi0: bus 2 (PEX0)
acpiprt3 at acpi0: bus 3 (PEX1)
acpiprt4 at acpi0: bus 4 (PEX2)
acpiprt5 at acpi0: bus 5 (PEX3)
acpiprt6 at acpi0: bus 6 (PEX4)
acpiprt7 at acpi0: bus -1 (PEX5)
acpicpu0 at acpi0: PSS
acpibtn0 at acpi0: SLPB
cpu0: Enhanced SpeedStep 1866 MHz: speeds: 1862, 1596 MHz
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel 82Q965 Host" rev 0x02
ppb0 at pci0 dev 1 function 0 "Intel 82Q965 PCIE" rev 0x02: msi
pci1 at ppb0 bus 1
vga1 at pci1 dev 0 function 0 "ATI Radeon X1300/X1550" rev 0x00
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
radeondrm0 at vga1: apic 2 int 16
drm0 at radeondrm0
"ATI Radeon X1300/X1550 Sec" rev 0x00 at pci1 dev 0 function 1 not configured
"Intel 82Q965 HECI" rev 0x02 at pci0 dev 3 function 0 not configured
pciide0 at pci0 dev 3 function 2 "Intel 82Q965 PT IDER" rev 0x02: DMA 
(unsupported), channel 0 wired to native-PCI, channel 1 wired to native-PCI
pciide0: using apic 2 int 18 for native-PCI interrupt
pciide0: channel 0 ignored (not responding; disabled or no drives?)
pciide0: channel 1 ignored (not responding; disabled or no drives?)
"Intel 82Q965 KT" rev 0x02 at pci0 dev 3 function 3 not configured
em0 at pci0 dev 25 function 0 "Intel ICH8 IGP AMT" rev 0x02: msi, address 
00:19:d1:72:eb:f1
uhci0 at pci0 dev 26 function 0 "Intel 82801H USB" rev 0x02: apic 2 int 16
uhci1 at pci0 dev 26 function 1 "Intel 82801H USB" rev 0x02: apic 2 int 21
ehci0 at pci0 dev 26 function 7 "Intel 82801H USB" rev 0x02: apic 2 int 18
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 "Intel EHCI root hub" rev 2.00/1.00 addr 1
azalia0 at pci0 dev 27 function 0 "Intel 82801H HD Audio" rev 0x02: msi
azalia0: codecs: Sigmatel STAC9227X
audio0 at azalia0
ppb1 at pci0 dev 28 function 0 "Intel 82801H PCIE" rev 0x02: msi
pci2 at ppb1 bus 2
ppb2 at pci0 dev 28 function 1 "Intel 82801H PCIE" rev 0x02: msi
pci3 at ppb2 bus 3
pciide1 at pci3 dev 0 function 0 "Marvell 88SE6101 IDE" rev 0xb1: DMA 
(unsupported), channel 0 configured to native-PCI, channel 1 configured to 
native-PCI
pciide1: using apic 2 int 17 for native-PCI interrupt
pciide1: channel 0 ignored (not responding; disabled or no drives?)
pciide1: channel 1 ignored (not responding; disabled or no drives?)
ppb3 at pci0 dev 28 function 2 "Intel 82801H PCIE" rev 0x02: msi
pci4 a

problem with puc(4) on -current

Hi,

I have a Soekris box equipped with an 8 port serial card I use to manage all my 
hardware using cu. 
Right now I'm running 4.6 on it, and thought, its time to upgrade, so installed 
-current from today ;)
Luckily I did the new installation on a separate CF card, to easily go back. 

When I now try to a serial console using a port tty04 or above, then I only get 
garbage. For example I call

cu -l /dev/tty0a -s 9600 
to get to my sparc, and I just get garbage back when I enter smth. 

When I try to connect to my procurve switch, 

cu -l /dev/tty09 -s 9600

then, the switch has speed autonegotiation, and connects fine with 1200 baud, 
but not the desired 9600 baud.

When I use /dev/tty03 (the first port of the PUC), then it takes the speed 
values I give with cu -s correctly, and I can connect fine to the sparc, when 
its there connected.
The problems start with tty04, and up to tty0a, I guess all those ports just 
only take 1200 bauds.

When I change back the CF card with the 4.6 installed, then all ports are fine 
again, so I did not damaged anything while updating.

anyone can help, dmesg below, and ls -l /dev/tty0*

Sebastian

OpenBSD 5.0-current (GENERIC) #118: Tue Dec 20 11:09:21 MST 2011
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: Geode(TM) Integrated Processor by AMD PCS ("AuthenticAMD" 586-class) 500 
MHz
cpu0: FPU,DE,PSE,TSC,MSR,CX8,SEP,PGE,CMOV,CFLUSH,MMX,MMXX,3DNOW2,3DNOW
real mem  = 536408064 (511MB)
avail mem = 517550080 (493MB)
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 20/80/26, BIOS32 rev. 0 @ 0xfac40
pcibios0 at bios0: rev 2.0 @ 0xf/0x1
pcibios0: pcibios_get_intr_routing - function not supported
pcibios0: PCI IRQ Routing information unavailable.
pcibios0: PCI bus #0 is the last bus
bios0: ROM list: 0xc8000/0xa800
cpu0 at mainbus0: (uniprocessor)
amdmsr0 at mainbus0
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
io address conflict 0x6100/0x100
io address conflict 0x6200/0x200
pchb0 at pci0 dev 1 function 0 "AMD Geode LX" rev 0x31
glxsb0 at pci0 dev 1 function 2 "AMD Geode LX Crypto" rev 0x00: RNG AES
vr0 at pci0 dev 6 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 11, address 
00:00:24:c9:d4:98
ukphy0 at vr0 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 0x004063, 
model 0x0034
vr1 at pci0 dev 7 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 5, address 
00:00:24:c9:d4:99
ukphy1 at vr1 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 0x004063, 
model 0x0034
vr2 at pci0 dev 8 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 9, address 
00:00:24:c9:d4:9a
ukphy2 at vr2 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 0x004063, 
model 0x0034
vr3 at pci0 dev 9 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 12, address 
00:00:24:c9:d4:9b
ukphy3 at vr3 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 0x004063, 
model 0x0034
puc0 at pci0 dev 14 function 0 "Sunix 40XX" rev 0x01: ports: 8 com
com3 at puc0 port 0 irq 10: ti16750, 64 byte fifo
com3: probed fifo depth: 32 bytes
com4 at puc0 port 1 irq 10: ti16750, 64 byte fifo
com4: probed fifo depth: 32 bytes
com5 at puc0 port 2 irq 10: ti16750, 64 byte fifo
com5: probed fifo depth: 32 bytes
com6 at puc0 port 3 irq 10: ti16750, 64 byte fifo
com6: probed fifo depth: 32 bytes
com7 at puc0 port 4 irq 10: ti16750, 64 byte fifo
com7: probed fifo depth: 32 bytes
com8 at puc0 port 5 irq 10: ti16750, 64 byte fifo
com8: probed fifo depth: 32 bytes
com9 at puc0 port 6 irq 10: ti16750, 64 byte fifo
com9: probed fifo depth: 32 bytes
com10 at puc0 port 7 irq 10: ti16750, 64 byte fifo
com10: probed fifo depth: 32 bytes
glxpcib0 at pci0 dev 20 function 0 "AMD CS5536 ISA" rev 0x03: rev 3, 32-bit 
3579545Hz timer, watchdog, gpio
gpio0 at glxpcib0: 32 pins
pciide0 at pci0 dev 20 function 2 "AMD CS5536 IDE" rev 0x01: DMA, channel 0 
wired to compatibility, channel 1 wired to compatibility
wd0 at pciide0 channel 0 drive 0: 
wd0: 1-sector PIO, LBA, 1918MB, 3928176 sectors
wd0(pciide0:0:0): using PIO mode 4, DMA mode 2
pciide0: channel 1 ignored (disabled)
ohci0 at pci0 dev 21 function 0 "AMD CS5536 USB" rev 0x02: irq 15, version 1.0, 
legacy support
ehci0 at pci0 dev 21 function 1 "AMD CS5536 USB" rev 0x02: irq 15
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 "AMD EHCI root hub" rev 2.00/1.00 addr 1
isa0 at glxpcib0
isadma0 at isa0
com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
com0: console
com1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo
pckbc0 at isa0 port 0x60/5
pckbd0 at pckbc0 (kbd slot)
pckbc0: using irq 1 for kbd slot
wskbd0 at pckbd0: console keyboard
pcppi0 at isa0 port 0x61
spkr0 at pcppi0
nsclpcsio0 at isa0 port 0x2e/2: NSC PC87366 rev 10: GPIO VLM TMS
gpio1 at nsclpcsio0: 29 pins
npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16
usb1 at ohci0: USB revision 1.0
uhub1 at usb1 "AMD OHCI root hub" rev 1.00/1.00 addr 1
mtrr: K6-family MTRR support (2 registers)
vscsi0 at root
scsibus0 at vscsi0: 256 targets
softraid0 at root
scsibus1 at softraid

Re: problem with puc(4) on -current

On Saturday, December 31, 2011 10:58 CET, "Sebastian Reitenbach" 
 wrote: 
 
> Hi,
> 
> I have a Soekris box equipped with an 8 port serial card I use to manage all 
> my hardware using cu. 
> Right now I'm running 4.6 on it, and thought, its time to upgrade, so 
> installed -current from today ;)
> Luckily I did the new installation on a separate CF card, to easily go back. 
> 
> When I now try to a serial console using a port tty04 or above, then I only 
> get garbage. For example I call
> 
> cu -l /dev/tty0a -s 9600 
> to get to my sparc, and I just get garbage back when I enter smth. 
> 
> When I try to connect to my procurve switch, 
> 
> cu -l /dev/tty09 -s 9600
> 
> then, the switch has speed autonegotiation, and connects fine with 1200 baud, 
> but not the desired 9600 baud.
> 
> When I use /dev/tty03 (the first port of the PUC), then it takes the speed 
> values I give with cu -s correctly, and I can connect fine to the sparc, when 
> its there connected.
> The problems start with tty04, and up to tty0a, I guess all those ports just 
> only take 1200 bauds.
> 
> When I change back the CF card with the 4.6 installed, then all ports are 
> fine again, so I did not damaged anything while updating.

got an off-list reply (thanks), suggesting to try cua(4) instead of tty(4), but 
the problem persists.

Sebastian



> 
> anyone can help, dmesg below, and ls -l /dev/tty0*
> 
> Sebastian
> 
> OpenBSD 5.0-current (GENERIC) #118: Tue Dec 20 11:09:21 MST 2011
> dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
> cpu0: Geode(TM) Integrated Processor by AMD PCS ("AuthenticAMD" 586-class) 
> 500 MHz
> cpu0: FPU,DE,PSE,TSC,MSR,CX8,SEP,PGE,CMOV,CFLUSH,MMX,MMXX,3DNOW2,3DNOW
> real mem  = 536408064 (511MB)
> avail mem = 517550080 (493MB)
> mainbus0 at root
> bios0 at mainbus0: AT/286+ BIOS, date 20/80/26, BIOS32 rev. 0 @ 0xfac40
> pcibios0 at bios0: rev 2.0 @ 0xf/0x1
> pcibios0: pcibios_get_intr_routing - function not supported
> pcibios0: PCI IRQ Routing information unavailable.
> pcibios0: PCI bus #0 is the last bus
> bios0: ROM list: 0xc8000/0xa800
> cpu0 at mainbus0: (uniprocessor)
> amdmsr0 at mainbus0
> pci0 at mainbus0 bus 0: configuration mode 1 (bios)
> io address conflict 0x6100/0x100
> io address conflict 0x6200/0x200
> pchb0 at pci0 dev 1 function 0 "AMD Geode LX" rev 0x31
> glxsb0 at pci0 dev 1 function 2 "AMD Geode LX Crypto" rev 0x00: RNG AES
> vr0 at pci0 dev 6 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 11, address 
> 00:00:24:c9:d4:98
> ukphy0 at vr0 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 
> 0x004063, model 0x0034
> vr1 at pci0 dev 7 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 5, address 
> 00:00:24:c9:d4:99
> ukphy1 at vr1 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 
> 0x004063, model 0x0034
> vr2 at pci0 dev 8 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 9, address 
> 00:00:24:c9:d4:9a
> ukphy2 at vr2 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 
> 0x004063, model 0x0034
> vr3 at pci0 dev 9 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 12, address 
> 00:00:24:c9:d4:9b
> ukphy3 at vr3 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 
> 0x004063, model 0x0034
> puc0 at pci0 dev 14 function 0 "Sunix 40XX" rev 0x01: ports: 8 com
> com3 at puc0 port 0 irq 10: ti16750, 64 byte fifo
> com3: probed fifo depth: 32 bytes
> com4 at puc0 port 1 irq 10: ti16750, 64 byte fifo
> com4: probed fifo depth: 32 bytes
> com5 at puc0 port 2 irq 10: ti16750, 64 byte fifo
> com5: probed fifo depth: 32 bytes
> com6 at puc0 port 3 irq 10: ti16750, 64 byte fifo
> com6: probed fifo depth: 32 bytes
> com7 at puc0 port 4 irq 10: ti16750, 64 byte fifo
> com7: probed fifo depth: 32 bytes
> com8 at puc0 port 5 irq 10: ti16750, 64 byte fifo
> com8: probed fifo depth: 32 bytes
> com9 at puc0 port 6 irq 10: ti16750, 64 byte fifo
> com9: probed fifo depth: 32 bytes
> com10 at puc0 port 7 irq 10: ti16750, 64 byte fifo
> com10: probed fifo depth: 32 bytes
> glxpcib0 at pci0 dev 20 function 0 "AMD CS5536 ISA" rev 0x03: rev 3, 32-bit 
> 3579545Hz timer, watchdog, gpio
> gpio0 at glxpcib0: 32 pins
> pciide0 at pci0 dev 20 function 2 "AMD CS5536 IDE" rev 0x01: DMA, channel 0 
> wired to compatibility, channel 1 wired to compatibility
> wd0 at pciide0 channel 0 drive 0: 
> wd0: 1-sector PIO, LBA, 1918MB, 3928176 sectors
> wd0(pciide0:0:0): using PIO mode 4, DMA mode 2
> pciide0: channel 1 ignored (disabled)
> ohci0 at pci0 dev 21 function 0 "AMD CS5536 USB" rev 0x02: irq 15, version 
> 1.0, legacy support
> ehci0 at pci0 dev 21 f

Re: problem with puc(4) on -current

On Saturday, December 31, 2011 11:47 CET, "Sebastian Reitenbach" 
 wrote: 
 
> On Saturday, December 31, 2011 10:58 CET, "Sebastian Reitenbach" 
>  wrote: 
>  
> > Hi,
> > 
> > I have a Soekris box equipped with an 8 port serial card I use to manage 
> > all my hardware using cu. 
> > Right now I'm running 4.6 on it, and thought, its time to upgrade, so 
> > installed -current from today ;)
> > Luckily I did the new installation on a separate CF card, to easily go 
> > back. 
> > 
> > When I now try to a serial console using a port tty04 or above, then I only 
> > get garbage. For example I call
> > 
> > cu -l /dev/tty0a -s 9600 
> > to get to my sparc, and I just get garbage back when I enter smth. 
> > 
> > When I try to connect to my procurve switch, 
> > 
> > cu -l /dev/tty09 -s 9600
> > 
> > then, the switch has speed autonegotiation, and connects fine with 1200 
> > baud, but not the desired 9600 baud.
> > 
> > When I use /dev/tty03 (the first port of the PUC), then it takes the speed 
> > values I give with cu -s correctly, and I can connect fine to the sparc, 
> > when its there connected.
> > The problems start with tty04, and up to tty0a, I guess all those ports 
> > just only take 1200 bauds.
> > 
> > When I change back the CF card with the 4.6 installed, then all ports are 
> > fine again, so I did not damaged anything while updating.
> 
> got an off-list reply (thanks), suggesting to try cua(4) instead of tty(4), 
> but the problem persists.

and here is a pcidump -v


 0:14:0: Sunix 40XX
0x: Vendor ID: 1409 Product ID: 7168
0x0004: Command: 0181 Status ID: 0280
0x0008: Class: 07 Subclass: 00 Interface: 02 Revision: 01
0x000c: BIST: 00 Header Type: 00 Latency Timer: 00 Cache Line Size: 00
0x0010: BAR io addr: 0xe500/0x0020
0x0014: BAR io addr: 0xe520/0x0010
0x0018: BAR io addr: 0xe530/0x0008
0x001c: BAR io addr: 0xe538/0x0008
0x0020: BAR io addr: 0xe540/0x0008
0x0024: BAR io addr: 0xe548/0x0008
0x0028: Cardbus CIS: 
0x002c: Subsystem Vendor ID: 1409 Product ID: 5066
0x0030: Expansion ROM Base Address: 
0x0038: 
0x003c: Interrupt Pin: 01 Line: 0a Min Gnt: 00 Max Lat: 00



> 
> Sebastian
> 
> 
> 
> > 
> > anyone can help, dmesg below, and ls -l /dev/tty0*
> > 
> > Sebastian
> > 
> > OpenBSD 5.0-current (GENERIC) #118: Tue Dec 20 11:09:21 MST 2011
> > dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
> > cpu0: Geode(TM) Integrated Processor by AMD PCS ("AuthenticAMD" 586-class) 
> > 500 MHz
> > cpu0: FPU,DE,PSE,TSC,MSR,CX8,SEP,PGE,CMOV,CFLUSH,MMX,MMXX,3DNOW2,3DNOW
> > real mem  = 536408064 (511MB)
> > avail mem = 517550080 (493MB)
> > mainbus0 at root
> > bios0 at mainbus0: AT/286+ BIOS, date 20/80/26, BIOS32 rev. 0 @ 0xfac40
> > pcibios0 at bios0: rev 2.0 @ 0xf/0x1
> > pcibios0: pcibios_get_intr_routing - function not supported
> > pcibios0: PCI IRQ Routing information unavailable.
> > pcibios0: PCI bus #0 is the last bus
> > bios0: ROM list: 0xc8000/0xa800
> > cpu0 at mainbus0: (uniprocessor)
> > amdmsr0 at mainbus0
> > pci0 at mainbus0 bus 0: configuration mode 1 (bios)
> > io address conflict 0x6100/0x100
> > io address conflict 0x6200/0x200
> > pchb0 at pci0 dev 1 function 0 "AMD Geode LX" rev 0x31
> > glxsb0 at pci0 dev 1 function 2 "AMD Geode LX Crypto" rev 0x00: RNG AES
> > vr0 at pci0 dev 6 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 11, 
> > address 00:00:24:c9:d4:98
> > ukphy0 at vr0 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 
> > 0x004063, model 0x0034
> > vr1 at pci0 dev 7 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 5, 
> > address 00:00:24:c9:d4:99
> > ukphy1 at vr1 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 
> > 0x004063, model 0x0034
> > vr2 at pci0 dev 8 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 9, 
> > address 00:00:24:c9:d4:9a
> > ukphy2 at vr2 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 
> > 0x004063, model 0x0034
> > vr3 at pci0 dev 9 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 12, 
> > address 00:00:24:c9:d4:9b
> > ukphy3 at vr3 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 
> > 0x004063, model 0x0034
> > puc0 at pci0 dev 14 function 0 "Sunix 40XX" rev 0x01: ports: 8 com
> > com3 at puc0 port 0 irq 10: ti16750, 64 byte fifo
> > com3: p

Re: problem with puc(4) on -current

On Saturday, December 31, 2011 11:55 CET, "Sebastian Reitenbach" 
 wrote: 
 
> On Saturday, December 31, 2011 11:47 CET, "Sebastian Reitenbach" 
>  wrote: 
>  
> > On Saturday, December 31, 2011 10:58 CET, "Sebastian Reitenbach" 
> >  wrote: 
> >  
> > > Hi,
> > > 
> > > I have a Soekris box equipped with an 8 port serial card I use to manage 
> > > all my hardware using cu. 
> > > Right now I'm running 4.6 on it, and thought, its time to upgrade, so 
> > > installed -current from today ;)
> > > Luckily I did the new installation on a separate CF card, to easily go 
> > > back. 
> > > 
> > > When I now try to a serial console using a port tty04 or above, then I 
> > > only get garbage. For example I call
> > > 
> > > cu -l /dev/tty0a -s 9600 
> > > to get to my sparc, and I just get garbage back when I enter smth. 
> > > 
> > > When I try to connect to my procurve switch, 
> > > 
> > > cu -l /dev/tty09 -s 9600
> > > 
> > > then, the switch has speed autonegotiation, and connects fine with 1200 
> > > baud, but not the desired 9600 baud.
> > > 
> > > When I use /dev/tty03 (the first port of the PUC), then it takes the 
> > > speed values I give with cu -s correctly, and I can connect fine to the 
> > > sparc, when its there connected.
> > > The problems start with tty04, and up to tty0a, I guess all those ports 
> > > just only take 1200 bauds.
> > > 
> > > When I change back the CF card with the 4.6 installed, then all ports are 
> > > fine again, so I did not damaged anything while updating.

got another off-list request for a 4.6 dmesg:

OpenBSD 4.6 (GENERIC) #58: Thu Jul  9 21:24:42 MDT 2009
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: Geode(TM) Integrated Processor by AMD PCS ("AuthenticAMD" 586-class) 500 
MHz
cpu0: FPU,DE,PSE,TSC,MSR,CX8,SEP,PGE,CMOV,CFLUSH,MMX
real mem  = 536440832 (511MB)
avail mem = 509902848 (486MB)
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 20/80/26, BIOS32 rev. 0 @ 0xfac40
pcibios0 at bios0: rev 2.0 @ 0xf/0x1
pcibios0: pcibios_get_intr_routing - function not supported
pcibios0: PCI IRQ Routing information unavailable.
pcibios0: PCI bus #0 is the last bus
bios0: ROM list: 0xc8000/0xa800
cpu0 at mainbus0: (uniprocessor)
amdmsr0 at mainbus0
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
io address conflict 0x6100/0x100
io address conflict 0x6200/0x200
pchb0 at pci0 dev 1 function 0 "AMD Geode LX" rev 0x31
glxsb0 at pci0 dev 1 function 2 "AMD Geode LX Crypto" rev 0x00: RNG AES
vr0 at pci0 dev 6 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 11, address 
00:00:24:c9:d4:98
ukphy0 at vr0 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 0x004063, 
model 0x0034
vr1 at pci0 dev 7 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 5, address 
00:00:24:c9:d4:99
ukphy1 at vr1 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 0x004063, 
model 0x0034
vr2 at pci0 dev 8 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 9, address 
00:00:24:c9:d4:9a
ukphy2 at vr2 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 0x004063, 
model 0x0034
vr3 at pci0 dev 9 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 12, address 
00:00:24:c9:d4:9b
ukphy3 at vr3 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 0x004063, 
model 0x0034
puc0 at pci0 dev 14 function 0 "Sunix 40XX" rev 0x01: ports: 8 com
com3 at puc0 port 0 irq 10: ti16750, 64 byte fifo
com3: probed fifo depth: 32 bytes
com4 at puc0 port 1 irq 10: ti16750, 64 byte fifo
com4: probed fifo depth: 32 bytes
com5 at puc0 port 2 irq 10: ti16750, 64 byte fifo
com5: probed fifo depth: 32 bytes
com6 at puc0 port 3 irq 10: ti16750, 64 byte fifo
com6: probed fifo depth: 32 bytes
com7 at puc0 port 4 irq 10: ti16750, 64 byte fifo
com7: probed fifo depth: 32 bytes
com8 at puc0 port 5 irq 10: ti16750, 64 byte fifo
com8: probed fifo depth: 32 bytes
com9 at puc0 port 6 irq 10: ti16750, 64 byte fifo
com9: probed fifo depth: 32 bytes
com10 at puc0 port 7 irq 10: ti16750, 64 byte fifo
com10: probed fifo depth: 32 bytes
glxpcib0 at pci0 dev 20 function 0 "AMD CS5536 ISA" rev 0x03: rev 0, 32-bit 
3579545Hz timer, watchdog, gpio
gpio0 at glxpcib0: 32 pins
pciide0 at pci0 dev 20 function 2 "AMD CS5536 IDE" rev 0x01: DMA, channel 0 
wired to compatibility, channel 1 wired to compatibility
wd0 at pciide0 channel 0 drive 0: 
wd0: 1-sector PIO, LBA, 1918MB, 3928176 sectors
wd0(pciide0:0:0): using PIO mode 4, DMA mode 2
pciide0: channel 1 ignored (disabled)
ohci0 at pci0 dev 21 function 0 "AMD CS5536 USB" rev 0x02: irq 15, version 1.0, 
legacy support
ehci0 at pci0 dev

Re: problem with puc(4) on -current

Hi, 

On Saturday, December 31, 2011 13:13 CET, Stuart Henderson 
 wrote: 
 
> On 2011-12-31, Sebastian Reitenbach  wrote:
> >> > Right now I'm running 4.6 on it, and thought, its time to upgrade, so 
> >> > installed -current from today ;)
> ..
> >> > When I use /dev/tty03 (the first port of the PUC), then it takes the 
> >> > speed values I give with cu -s correctly, and I can connect fine to the 
> >> > sparc, when its there connected.
> >> > The problems start with tty04, and up to tty0a, I guess all those ports 
> >> > just only take 1200 bauds.
> 
> >  0:14:0: Sunix 40XX
> > 0x: Vendor ID: 1409 Product ID: 7168
> > 0x0004: Command: 0181 Status ID: 0280
> > 0x0008: Class: 07 Subclass: 00 Interface: 02 Revision: 01
> > 0x000c: BIST: 00 Header Type: 00 Latency Timer: 00 Cache Line Size: 
> > 00
> > 0x0010: BAR io addr: 0xe500/0x0020
> > 0x0014: BAR io addr: 0xe520/0x0010
> > 0x0018: BAR io addr: 0xe530/0x0008
> > 0x001c: BAR io addr: 0xe538/0x0008
> > 0x0020: BAR io addr: 0xe540/0x0008
> > 0x0024: BAR io addr: 0xe548/0x0008
> > 0x0028: Cardbus CIS: 
> > 0x002c: Subsystem Vendor ID: 1409 Product ID: 5066
> > 0x0030: Expansion ROM Base Address: 
> > 0x0038: 
> > 0x003c: Interrupt Pin: 01 Line: 0a Min Gnt: 00 Max Lat: 00
> 
> This was changed in pucdata.c r1.65 so we could get more exact matching on
> the various devices using the same PCI vendor/product ID as your device.
> 
> Diff below should put things back how they were for your card, but
> it doesn't quite tie in with what you say as the first *2* ports
> on the puc should have worked, not the first 1.

also naddy pointed me to pucdata.c. Your patch alone did not helped, trying it, 
I had the same garbage as without.
Then I removed the SUNIX entry before the chunk that your patch added, and it 
suddenly started to work like it did on the 4.6.

The patch to make it work for me would look like the one below.

thanks,
Sebastian


Index: pucdata.c
===
RCS file: /cvs/src/sys/dev/pci/pucdata.c,v
retrieving revision 1.78
diff -u -r1.78 pucdata.c
--- pucdata.c   26 Oct 2011 14:20:25 -  1.78
+++ pucdata.c   31 Dec 2011 15:47:25 -
@@ -1441,17 +1441,17 @@
},
 
{   /* SUNIX 406X 8S */
-   {   PCI_VENDOR_SUNIX, PCI_PRODUCT_SUNIX_40XX, 0x1409, 0x4060 },
-   {   0x, 0x, 0x, 0xe0f0 },
+   {   PCI_VENDOR_SUNIX, PCI_PRODUCT_SUNIX_40XX, 0x1409, 0x5066 },
+   {   0x, 0x, 0x, 0x },
{
{ PUC_COM_POW2(3), 0x10, 0x },
{ PUC_COM_POW2(3), 0x10, 0x0008 },
-   { PUC_COM_POW2(3), 0x14, 0x },
-   { PUC_COM_POW2(3), 0x14, 0x0008 },
-   { PUC_COM_POW2(3), 0x18, 0x },
-   { PUC_COM_POW2(3), 0x1c, 0x },
-   { PUC_COM_POW2(3), 0x20, 0x },
-   { PUC_COM_POW2(3), 0x24, 0x },
+   { PUC_COM_POW2(0), 0x14, 0x },
+   { PUC_COM_POW2(0), 0x14, 0x0008 },
+   { PUC_COM_POW2(0), 0x18, 0x },
+   { PUC_COM_POW2(0), 0x1c, 0x },
+   { PUC_COM_POW2(0), 0x20, 0x },
+   { PUC_COM_POW2(0), 0x24, 0x },
},
},
 





> 
> Index: pucdata.c
> ===
> RCS file: /cvs/src/sys/dev/pci/pucdata.c,v
> retrieving revision 1.78
> diff -u -p -r1.78 pucdata.c
> --- pucdata.c 26 Oct 2011 14:20:25 -  1.78
> +++ pucdata.c 31 Dec 2011 12:09:21 -
> @@ -1455,6 +1455,21 @@ const struct puc_device_description puc_
>   },
>   },
>  
> + {   /* SUNIX 406X 8S */
> + {   PCI_VENDOR_SUNIX, PCI_PRODUCT_SUNIX_40XX, 0x1409, 0x5066 },
> + {   0x, 0x, 0x, 0x },
> + {
> + { PUC_COM_POW2(3), 0x10, 0x },
> + { PUC_COM_POW2(3), 0x10, 0x0008 },
> + { PUC_COM_POW2(0), 0x14, 0x },
> + { PUC_COM_POW2(0), 0x14, 0x0008 },
> + { PUC_COM_POW2(0), 0x18, 0x },
> + { PUC_COM_POW2(0), 0x1c, 0x },
> + { PUC_COM_POW2(0), 0x20, 0x },
> + { PUC_COM_POW2(0), 0x24, 0x },
> + },
> + },
> +
>   {   /* SUNIX 407X 2S/1P */
>   {   PCI_VENDOR_SUNIX, PCI_PRODUCT_SUNIX_40XX, 0x1409, 0x4070 },
>   {   0x, 0x, 0x, 0xeff0 },

problem with ral in hopstap mode on -current

2012-01-12 Thread Sebastian Reitenbach

Hi,

I ran a soekris box as AP, and recently upgraded it from a very old 4.2, to 5.0 
-current. It was running the old 4.2 for such a long time, since I only had a 
32MB CF card in it, and just recently bought a new 2GB card, to install a full 
system on it.

I have a ral wireless device in the box, configured as hostap:

# cat /etc/hostname.ral0

inet 10.23.4.56 255.255.0.0
nwid brb.freifunk.net chan 1 mediaopt hostap

The clients are OpenBSD notebooks. Now after the upgrade it happens after some 
time (don't know what the timeframe is, maybe a day maybe longer or shorter, 
the wireless is not that much used), that the ral device is not responding, 
when a client tries to connect to the WLAN. On the client I see the status on 
the WLAN device as status: no network

on the access point, all seems to be fine:

# ifconfig ral0
ral0: flags=8943 mtu 1500
lladdr 00:11:09:9a:9a:7e
priority: 4
groups: wlan
media: IEEE802.11 autoselect hostap (autoselect mode 11b hostap)
status: active
ieee80211: nwid brb.freifunk.net chan 1 bssid 00:11:09:9a:9a:7e 100dBm
inet6 fe80::211:9ff:fe9a:9a7e%ral0 prefixlen 64 scopeid 0x4
inet 10.23.4.56 netmask 0x broadcast 10.23.255.255

To get it to work again, I have to login to the AP, and issue a 
sh /etc/netstart ral0

that's all, afterwards, the client can happily connect.

When I have the problem, I watched with tcpdump what happens when the client 
tries to connect to the network:
tcpdump -n -i ral0 -y IEEE802_11_RADIO -vvv

See the tcpdump output and dmesg below.

Suggestion to debug this problem?

Sebastian

# ifconfig ral0
ral0: flags=8943 mtu 1500
lladdr 00:11:09:9a:9a:7e
priority: 4
groups: wlan
media: IEEE802.11 autoselect hostap (autoselect mode 11b hostap)
status: active
ieee80211: nwid brb.freifunk.net chan 1 bssid 00:11:09:9a:9a:7e 100dBm
inet6 fe80::211:9ff:fe9a:9a7e%ral0 prefixlen 64 scopeid 0x4
inet 10.23.4.56 netmask 0x broadcast 10.23.255.255

OpenBSD 5.0-current (GENERIC) #118: Tue Dec 20 11:09:21 MST 2011
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: Geode(TM) Integrated Processor by National Semi ("Geode by NSC" 586-class)
 267 MHz
cpu0: FPU,TSC,MSR,CX8,CMOV,MMX
real mem  = 133754880 (127MB)
avail mem = 121548800 (115MB)
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 20/40/21, BIOS32 rev. 0 @ 0xf7840
pcibios0 at bios0: rev 2.0 @ 0xf/0x1
pcibios0: pcibios_get_intr_routing - function not supported
pcibios0: PCI IRQ Routing information unavailable.
pcibios0: PCI bus #0 is the last bus
bios0: ROM list: 0xc8000/0x9000
cpu0 at mainbus0: (uniprocessor)
cpu0: TSC disabled
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 0 function 0 "Cyrix GXm PCI" rev 0x00
sis0 at pci0 dev 6 function 0 "NS DP83815 10/100" rev 0x00, DP83816A: irq 10, ad
dress 00:00:24:c3:89:1c
nsphyter0 at sis0 phy 0: DP83815 10/100 PHY, rev. 1
sis1 at pci0 dev 7 function 0 "NS DP83815 10/100" rev 0x00, DP83816A: irq 10, ad
dress 00:00:24:c3:89:1d
nsphyter1 at sis1 phy 0: DP83815 10/100 PHY, rev. 1
sis2 at pci0 dev 8 function 0 "NS DP83815 10/100" rev 0x00, DP83816A: irq 10, ad
dress 00:00:24:c3:89:1e
nsphyter2 at sis2 phy 0: DP83815 10/100 PHY, rev. 1
ral0 at pci0 dev 10 function 0 "Ralink RT2560" rev 0x01: irq 11, address 00:11:0
9:9a:9a:7e
ral0: MAC/BBP RT2560 (rev 0x04), RF RT2525
gscpcib0 at pci0 dev 18 function 0 "NS SC1100 ISA" rev 0x00
gpio0 at gscpcib0: 64 pins
"NS SC1100 SMI" rev 0x00 at pci0 dev 18 function 1 not configured
pciide0 at pci0 dev 18 function 2 "NS SCx200 IDE" rev 0x01: DMA, channel 0 wired
 to compatibility, channel 1 wired to compatibility
wd0 at pciide0 channel 0 drive 0: 
wd0: 1-sector PIO, LBA, 1918MB, 3928176 sectors
wd0(pciide0:0:0): using PIO mode 4, DMA mode 2
geodesc0 at pci0 dev 18 function 5 "NS SC1100 X-Bus" rev 0x00: iid 6 revision 3 
wdstatus 0
ohci0 at pci0 dev 19 function 0 "Compaq USB OpenHost" rev 0x08: irq 5, version 1
.0, legacy support
isa0 at gscpcib0
isadma0 at isa0
com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
com0: console
com1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo
pckbc0 at isa0 port 0x60/5
pckbd0 at pckbc0 (kbd slot)
pckbc0: using irq 1 for kbd slot
wskbd0 at pckbd0: console keyboard
pcppi0 at isa0 port 0x61
spkr0 at pcppi0
nsclpcsio0 at isa0 port 0x2e/2: NSC PC87366 rev 9: GPIO VLM TMS
gpio1 at nsclpcsio0: 29 pins
gscsio0 at isa0 port 0x15c/2: SC1100 SIO rev 1:
npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16
usb0 at ohci0: USB revision 1.0
uhub0 at usb0 "Compaq OHCI root hub" rev 1.00/1.00 addr 1
vscsi0 at root
scsibus0 at vscsi0: 256 targets
softraid0 at root
scsibus1 at softraid0: 256 targets
root on wd0a (a0d20985cad8f41c.a) swap on wd0b

linux stronswan/xl2tpd client to IPSec/npppd

2012-01-17 Thread Sebastian Reitenbach

Hi,

This is a long story, the 2 little questions, one regarding a clarifictaion I'd 
like to 
have, and another followup question are at the end.

my final goal is to connect mobile phones via IPSec/L2TP to OpenBSD vpn servers.
Since I don't have a capable smart phone around, I thought about trying it with 
a Linux client first. On the linux client I use strongswan-4.4.0-4.1.1, and 
xl2tpd-1.2.4-2.7

I try to follow the instructions in the 
/usr/src/usr.sbin/npppd/HOWTO_PIPEX_NPPPD.txt

This is my npppd.conf:
$ grep -v "^#" /etc/npppd/npppd.conf


  
interface_list: tun0
interface.tun0.ip4addr: 10.66.66.1
pool.dyna_pool: 10.66.66.0/25
pool.pool:  10.66.66.128/25
auth.local.realm_list:  local
auth.local.realm.acctlist:  /etc/npppd/npppd-users.csv
realm.local.concentrate:tun0
lcp.mru:1400
auth.method:mschapv2 chap
pptpd.enabled:  true
pptpd.ip4_allow:0.0.0.0/0
l2tpd.enabled:  true
l2tpd.ip4_allow:0.0.0.0/0
l2tpd.require_ipsec:false

and my npppd-users.csv:
Username,Password,Framed-IP-Address,Framed-IP-Netmask,Description,Calling-Id
user1,top-secret-password-for-user1,10.66.66.129,,memo for user1

So first I tried "normal" pptp, on the client side, for that, I loosely 
followed this howto:
http://www.cyberciti.biz/tips/howto-configure-ubuntu-fedora-linux-pptp-client.html

so I have this in my /etc/ppp/chap-secrets file:
user1 PPTP top-secret-password-for-user1 *

and this in my /etc/ppp/peers/blah file:
pty "pptp 10.0.0.81 --nolaunchpppd"
name user1
remotename PPTP
require-mppe-128
file /etc/ppp/options.pptp
ipparam delhi-idc-01

and this is my /etc/ppp/options.pptp:
sre:~ # cat /etc/ppp/options.pptp 
#
# Lock the port
#
lock
#
# We don't need the tunnel server to authenticate itself
#
noauth
#
# Turn off transmission protocols we know won't be used
#
nobsdcomp
nodeflate
#
# We want MPPE
#
require-mppe
#
# We want a sane mtu/mru
#
mtu 1000
mru 1000
#
# Time this thing out of it goes poof
#
lcp-echo-failure 10
lcp-echo-interval 10

Now starting the client to connect to the server:

on the client side, it looks like this:
Using interface ppp0
Connect: ppp0 <--> /dev/pts/10
CHAP authentication succeeded
MPPE 128-bit stateless compression enabled
local  IP address 10.66.66.129
remote IP address 10.66.66.1
Script /etc/ppp/ip-up finished (pid 14576), status = 0x0

and on the server I get the following output from npppd:
2012-01-17 09:42:16:INFO: pptpd ctrl=0 Starting peer=10.0.0.31:43050/tcp 
sock=10.0.0.81:1723/tcp
2012-01-17 09:42:16:INFO: pptpd ctrl=0 RecvSCCRQ protocol_version=1.0 
framing=async,sync bearer=analog,digital max_channels=65535 
firmware_revision=1(0x0001) host_name="local" vendor_string="cananian"
2012-01-17 09:42:16:INFO: pptpd ctrl=0 SendSCCRP protocol_version=1.0 result=1 
error=0 framing=sync bearer=digital max_channels=4 
firmware_revision=1282(0x0502) host_name="" vendor_string=""
2012-01-17 09:42:17:INFO: pptpd ctrl=0 call=0 RecvOCRQ call_id=0 
call_serial_number=0 max_bps=2400 min_bps=1000 bearer=analog,digital 
framing=async,sync recv_winsz=3 packet_proccessing_delay=0 phone_nunmber= 
subaddress=
2012-01-17 09:42:17:INFO: pptpd ctrl=0 call=48978 SendOCRP call_id=48978 
peers_call_id=0 result=1 error=0 cause=0 conn_speed=1000 recv_winsz=64 
packet_proccessing_delay=0 physical_channel_id=48978
2012-01-17 09:42:17:NOTICE: pptpd ctrl=0 call=48978 logtype=PPPBind ppp=0
2012-01-17 09:42:17:INFO: ppp id=0 layer=base logtype=Started 
tunnel=PPTP(10.0.0.31:43050)
2012-01-17 09:42:17:INFO: ppp id=0 layer=lcp logtype=Opened mru=1400/1000 
auth=MS-CHAP-V2 magic=62d614bb/5a299c53
2012-01-17 09:42:17:INFO: ppp id=0 layer=chap proto=mschap_v2 logtype=Success 
username="user1" realm=local
2012-01-17 09:42:17:INFO: ppp id=0 layer=mppe mismatch our=128bit,stateless 
peer=40bit,128bit,stateless
2012-01-17 09:42:17:INFO: ppp id=0 layer=mppe logtype=Opened 
our=128bit,stateless peer=128bit,stateless
2012-01-17 09:42:17:DEBUG: ppp id=0 layer=ipcp Unhandled Option 02 6
2012-01-17 09:42:17:INFO: ppp id=0 layer=ipcp IP Address peer=0.0.0.0 
our=10.66.66.129.
2012-01-17 09:42:20:INFO: ppp id=0 layer=ipcp logtype=Opened ip=10.66.66.129 
assignType=static
2012-01-17 09:42:20:NOTICE: ppp id=0 layer=base logtype=TUNNELSTART 
user="user1" duration=3sec layer2=PPTP layer2from=10.0.0.31:43050 
auth=MS-CHAP-V2  ip=10.66.66.129 iface=tun0
2012-01-17 09:42:20:NOTICE: ppp id=0 layer=base Using pipex=yes


So far,so good, this all works.

Then I did setup ipsec on the server loosely following the 
H

Re: VoIP Sophtphones

On Thursday, January 19, 2012 06:44 CET, Tomas Bodzar  
wrote: 
 
> On Wed, Jan 18, 2012 at 9:10 PM,   wrote:
> > pjsua from the packages works very good. I tryied to compile
> > linphone-3.5.0 and twinkle-1.4.2 in OpenBSD4.8 without
> > success. Did someone managed to do it?
> 
> From http://www.openbsd.org/security.html
> 
> OpenBSD 4.8 and earlier releases are not supported anymore. The
> following paragraphs only list advisories issued while they were
> maintained; these releases are likely to be affected by the advisories
> for more recent releases.
> 
> So do upgrade to 5.0 or current and simply install packages and you
> will be fine.

In case IAX protocol is fine for you, you can take a look at net/coccinella. 
Its mostly an
xmpp client, but also an IAX softphone that you can connect to Asterisk.

But I think on 4.8, the VoIP part was not yet enabled, so as already mentioned, 
you should upgrade.

cheers,
Sebastian

> 
> 
> >
> > Thanks
> > Rodrigo.

Re: linux stronswan/xl2tpd client to IPSec/npppd

On Thursday, January 19, 2012 02:23 CET, YASUOKA Masahiko  
wrote: 
 
> Hi,
> 
> On Thu, 19 Jan 2012 02:14:48 +0900 (JST)
> YASUOKA Masahiko  wrote:
> > On Tue, 17 Jan 2012 11:57:07 +0100
> > "Sebastian Reitenbach"  wrote:
> > If you don't like this limitation, you can use 'pppx mode'.  In 'pppx
> > mode' npppd will create a pppx interface for each PPP session.  You
> > can add any routes to the interface.
> 
> Unfortunately the ingress filter of `pipex' drops all these packets.
> It's always on by default and not configurable.  It should be
> configurable, but it is not implemented yet.

Since the pppx mode doesn't seem to work for me with the xl2tpd client 
I could not test this here.


besides having routes on the server, I wonder whether I can push routes to the 
client automatically.
So the client just starts up the l2tpd client and connects, then its getting 
told from the server, which routes
to which networks behind the VPN endpoint it should set into the tunnel.
But as I recognized now, the xl2tp client on the Linux host called 
/etc/ppp/ip-up script. So I guess the client 
has to take care on its own which extra routes it will set up.

So if I understand it now: 
 * on the OpenBSD VPN Server, I can just use the tun0 interface
   * enable packet forwarding
   * have normal routes defined to the extra networks
* maybe protecting things with PF
 * on the client I have an ip-up script that runs when the tunnel gets 
established, 
* this sets routes to the networks behind the VPN Server into the tunnel

This I actually tried, and seems to work.

But on the mobile phone, Android 2.2 what I tried now, I haven't yet seen a 
hook where I could 
setup extra routes. maybe someone on the list may give me a hint here?


> 
> > To enable 'pppx mode', add
> > 
> >   pppx_mode: true
> > 
> > to /etc/npppd/npppd.conf. 
> 
> Sorry, above example was wrong.  To test `pppx mode'
> 
> (1) create /dev/pppx0
> % cd /dev
> % sudo sh MAKEDEV pppx
> (2) replace from `tun0' to `pppx0' in /etc/npppd/npppd.conf
> (3) add "interface.pppx0.pppx_mode: true" to /etc/npppd/npppd.conf

I tried this pppx mode on my OBSD VM, together with the Linux client, but it 
doesn't establish the connection:

- I created the pppx device as explained above
- edited npppd.conf:

#interface_list: tun0
#interface.tun0.ip4addr: 10.66.66.1
interface_list: pppx0
interface.pppx0.ip4addr: 10.66.66.1
interface.pppx0.pppx_mode:   true
...

then start, and try the client to connect:

$ sudo /usr/sbin/npppd -d 
2012-01-19 13:32:37:NOTICE: Starting npppd pid=7082 version=5.0.0
2012-01-19 13:32:37:NOTICE: Load configuration from='/etc/npppd/npppd.conf' 
successfully.
2012-01-19 13:32:37:INFO: pppx0 Started pppx
2012-01-19 13:32:37:INFO: Listening /var/run/npppd_ctl (npppd_ctl)
2012-01-19 13:32:37:INFO: pool name=default dyn_pool=[10.66.66.0/25] 
pool=[10.66.66.0/24]
2012-01-19 13:32:37:INFO: Loading pool config successfully.
2012-01-19 13:32:37:INFO: realm name=local(local) Loaded users 
from='/etc/npppd/npppd-users.csv' successfully.  1 users
2012-01-19 13:32:37:INFO: l2tpd Listening 0.0.0.0:1701/udp (L2TP LNS) [L2TP]
2012-01-19 13:32:37:INFO: l2tpd Listening [::]:1701/udp (L2TP LNS) [L2TP]
2012-01-19 13:32:37:INFO: pptpd Listening 0.0.0.0:1723/tcp (PPTP PAC) [PPTP]
2012-01-19 13:32:37:INFO: pptpd Listening 0.0.0.0:gre (PPTP PAC)
2012-01-19 13:32:37:INFO: pppx0 is using ipcp=default(1 pools).

here I connected the client:
2012-01-19 13:39:02:NOTICE: l2tpd ctrl=1 logtype=Started RecvSCCRQ 
from=10.0.0.31:1701/udp tunnel_id=1/29795 protocol=1.0 winsize=4 hostname=sre 
vendor=xelerance.com firm=0690
2012-01-19 13:39:02:INFO: l2tpd ctrl=1 SendSCCRP
2012-01-19 13:39:02:INFO: l2tpd ctrl=1 RecvSCCN
2012-01-19 13:39:02:INFO: l2tpd ctrl=1 SendZLB
2012-01-19 13:39:02:INFO: l2tpd ctrl=1 call=30483 RecvICRQ session_id=2737
2012-01-19 13:39:02:INFO: l2tpd ctrl=1 call=30483 SendICRP session_id=30483
2012-01-19 13:39:02:WARNING: l2tpd ctrl=1 call=30483 AVP (RX_CONNECT_SPEED/38) 
is not supported, but it's mandatory
2012-01-19 13:39:02:INFO: l2tpd ctrl=1 call=30483 RecvICCN session_id=2737 
calling_number= tx_conn_speed=1000 framing=sync
2012-01-19 13:39:02:NOTICE: l2tpd ctrl=1 call=30483 logtype=PPPBind ppp=0
2012-01-19 13:39:02:INFO: ppp id=0 layer=base logtype=Started 
tunnel=L2TP(10.0.0.31:1701)
2012-01-19 13:39:02:INFO: l2tpd ctrl=1 call=30483 SendZLB
2012-01-19 13:39:03:INFO: ppp id=0 layer=lcp logtype=Opened mru=1400/1410 
auth=MS-CHAP-V2 magic=399562f0/187d146d
2012-01-19 13:39:03:INFO: ppp id=0 layer=chap proto=mschap_v2 logtype=Success 
username="user1" realm=local
2012-01-19 13:39:03:WARNING: ppp id=0 layer=base

Re: linux stronswan/xl2tpd client to IPSec/npppd

On Thursday, January 19, 2012 14:10 CET, "Sebastian Reitenbach" 
 wrote: 
 
> On Thursday, January 19, 2012 02:23 CET, YASUOKA Masahiko 
>  wrote: 
>  
> > Hi,
> > 
> > On Thu, 19 Jan 2012 02:14:48 +0900 (JST)
> > YASUOKA Masahiko  wrote:
> > > On Tue, 17 Jan 2012 11:57:07 +0100
> > > "Sebastian Reitenbach"  wrote:
> > > If you don't like this limitation, you can use 'pppx mode'.  In 'pppx
> > > mode' npppd will create a pppx interface for each PPP session.  You
> > > can add any routes to the interface.
> > 
> > Unfortunately the ingress filter of `pipex' drops all these packets.
> > It's always on by default and not configurable.  It should be
> > configurable, but it is not implemented yet.
> 
> Since the pppx mode doesn't seem to work for me with the xl2tpd client 
> I could not test this here.
> 
> 
> besides having routes on the server, I wonder whether I can push routes to 
> the client automatically.
> So the client just starts up the l2tpd client and connects, then its getting 
> told from the server, which routes
> to which networks behind the VPN endpoint it should set into the tunnel.
> But as I recognized now, the xl2tp client on the Linux host called 
> /etc/ppp/ip-up script. So I guess the client 
> has to take care on its own which extra routes it will set up.
> 
> So if I understand it now: 
>  * on the OpenBSD VPN Server, I can just use the tun0 interface
>* enable packet forwarding
>* have normal routes defined to the extra networks
> * maybe protecting things with PF
>  * on the client I have an ip-up script that runs when the tunnel gets 
> established, 
> * this sets routes to the networks behind the VPN Server into the tunnel
> 
> This I actually tried, and seems to work.
> 
> But on the mobile phone, Android 2.2 what I tried now, I haven't yet seen a 
> hook where I could 
> setup extra routes. maybe someone on the list may give me a hint here?

After some more tests  I can answer this myself. The Android just puts the 
default route into the tunnel.

Sebastian

> 
> 
> > 
> > > To enable 'pppx mode', add
> > > 
> > >   pppx_mode: true
> > > 
> > > to /etc/npppd/npppd.conf. 
> > 
> > Sorry, above example was wrong.  To test `pppx mode'
> > 
> > (1) create /dev/pppx0
> > % cd /dev
> > % sudo sh MAKEDEV pppx
> > (2) replace from `tun0' to `pppx0' in /etc/npppd/npppd.conf
> > (3) add "interface.pppx0.pppx_mode: true" to /etc/npppd/npppd.conf
> 
> I tried this pppx mode on my OBSD VM, together with the Linux client, but it 
> doesn't establish the connection:
> 
> - I created the pppx device as explained above
> - edited npppd.conf:
> 
> #interface_list: tun0
> #interface.tun0.ip4addr: 10.66.66.1
> interface_list: pppx0
> interface.pppx0.ip4addr: 10.66.66.1
> interface.pppx0.pppx_mode:   true
> ...
> 
> then start, and try the client to connect:
> 
> $ sudo /usr/sbin/npppd -d 
> 2012-01-19 13:32:37:NOTICE: Starting npppd pid=7082 version=5.0.0
> 2012-01-19 13:32:37:NOTICE: Load configuration from='/etc/npppd/npppd.conf' 
> successfully.
> 2012-01-19 13:32:37:INFO: pppx0 Started pppx
> 2012-01-19 13:32:37:INFO: Listening /var/run/npppd_ctl (npppd_ctl)
> 2012-01-19 13:32:37:INFO: pool name=default dyn_pool=[10.66.66.0/25] 
> pool=[10.66.66.0/24]
> 2012-01-19 13:32:37:INFO: Loading pool config successfully.
> 2012-01-19 13:32:37:INFO: realm name=local(local) Loaded users 
> from='/etc/npppd/npppd-users.csv' successfully.  1 users
> 2012-01-19 13:32:37:INFO: l2tpd Listening 0.0.0.0:1701/udp (L2TP LNS) [L2TP]
> 2012-01-19 13:32:37:INFO: l2tpd Listening [::]:1701/udp (L2TP LNS) [L2TP]
> 2012-01-19 13:32:37:INFO: pptpd Listening 0.0.0.0:1723/tcp (PPTP PAC) [PPTP]
> 2012-01-19 13:32:37:INFO: pptpd Listening 0.0.0.0:gre (PPTP PAC)
> 2012-01-19 13:32:37:INFO: pppx0 is using ipcp=default(1 pools).
> 
> here I connected the client:
> 2012-01-19 13:39:02:NOTICE: l2tpd ctrl=1 logtype=Started RecvSCCRQ 
> from=10.0.0.31:1701/udp tunnel_id=1/29795 protocol=1.0 winsize=4 hostname=sre 
> vendor=xelerance.com firm=0690
> 2012-01-19 13:39:02:INFO: l2tpd ctrl=1 SendSCCRP
> 2012-01-19 13:39:02:INFO: l2tpd ctrl=1 RecvSCCN
> 2012-01-19 13:39:02:INFO: l2tpd ctrl=1 SendZLB
> 2012-01-19 13:39:02:INFO: l2tpd ctrl=1 call=30483 RecvICRQ session_id=2737
> 2012-01-19 13:39:02:INFO: l2tpd ctrl=1 call=30483 SendICRP session_id=30483
> 2012-01-19 13:39:02:WARNING: l2

Re: linux stronswan/xl2tpd client to IPSec/npppd

On Thursday, January 19, 2012 23:35 CET, YASUOKA Masahiko  
wrote: 
 
> 
> On Thu, 19 Jan 2012 14:10:03 +0100
> "Sebastian Reitenbach"  wrote:
> > On Thursday, January 19, 2012 02:23 CET, YASUOKA Masahiko 
> >  wrote: 
> >> On Thu, 19 Jan 2012 02:14:48 +0900 (JST)
> >> YASUOKA Masahiko  wrote:
> >> > To enable 'pppx mode', add
> >> > 
> >> >   pppx_mode: true
> >> > 
> >> > to /etc/npppd/npppd.conf. 
> >> 
> >> Sorry, above example was wrong.  To test `pppx mode'
> >> 
> >> (1) create /dev/pppx0
> >> % cd /dev
> >> % sudo sh MAKEDEV pppx
> >> (2) replace from `tun0' to `pppx0' in /etc/npppd/npppd.conf
> >> (3) add "interface.pppx0.pppx_mode: true" to /etc/npppd/npppd.conf
> > 
> > I tried this pppx mode on my OBSD VM, together with the Linux client, but 
> > it doesn't establish the connection:
> > 
> > - I created the pppx device as explained above
> > - edited npppd.conf:
> > 
> > #interface_list: tun0
> > #interface.tun0.ip4addr: 10.66.66.1
> > interface_list: pppx0
> > interface.pppx0.ip4addr: 10.66.66.1
> > interface.pppx0.pppx_mode:   true
> > ...
> 
> Do you have
> 
>   realm.local.concentrate:pppx0

no, I still had tun0 there. 
Next time I should use grep instead of trying to trust my eyes to catch 
everything.


> 
> line correctly?
> 
> > 2012-01-19 13:39:03:INFO: ppp id=0 layer=chap proto=mschap_v2
> >   logtype=Success username="user1" realm=local
> > 2012-01-19 13:39:03:WARNING: ppp id=0 layer=base No interface binding.
> 
> npppd failed to find a interface for the user of the realm.

so changing to pppx0 makes it work as it should be.

sorry for the noise
Sebastian

> 
> --yasuoka

Re: L2TP/IPSEC with 4.9 and Ipad - fails to complete

2012-02-11 Thread Sebastian Reitenbach

On Saturday, February 11, 2012 02:37 CET, Stuart Henderson 
 wrote: 

> On 2012-02-10, Ted Wynnychenko  wrote:
> > I am hoping someone can point me in some sort of direction.
> > I have been trying to connect an iPad (ios 5.0.1) to an openbsd 4.9 server
> > using L2TP/IPSEC.
> 
> Looks like nat is involved, try -current, there have been changes which may 
> well help
> 

I didn't tried with iPad, but with Android mobile phone. With -current, it 
worked fairly well. You should 
also apply the patch to fix LCP keepalice failures with L2TP (was at least 
needed to keep the tunnel
from my Android stable). Yasuoka@ sent it to tech@ (Thread: diff: fix LCP 
keepalive failures on L2TP.)

There is still this unsolved problem with multiple clients behind the same NAT 
gateway, which still doesn't work. 
A single client behind a NAT is OK, but not multiple behind the same.

Sebastian

npppd with EAP-TLS for PPTP

2012-02-29 Thread Sebastian Reitenbach

Hi,

since there is the limitation in npppd that it doesn't support multiple clients 
behind the same NAT host for IPSec/L2TP, I'm looking 
into using PPTP with EAP-TLS authentication. But I'm wondering, whether this is 
supported by npppd.
The examples in the HOWTO_PIPEX_NPPPD.txt only use mschapv2 and chap with the 
local authentication.
When I'd use radius authentication, would it be possible to use EAP-TLS then?

I want to know, whether its generally supposed to work, before I setup a radius 
server and everything to test EAP-TLS at all.

If its not possible this way, would it be possible to use poptop from ports to 
get EAP-TLS working with PPTP?
Googling, I only found refrerences to Linux, where poptop works in conjunction 
with ppd, but I did not found anything 
with regard to OpenBSD.

So is there any way to setup a PPTP server with EAP-TLS authentication on 
OpenBSD?

any cluestick is appreciated.

cheers,
Sebastian

Re: npppd with EAP-TLS for PPTP

2012-03-01 Thread Sebastian Reitenbach

Hi,
 
On Thursday, March 1, 2012 11:34 CET, YASUOKA Masahiko  
wrote: 
 
> Hi,
> 
> On Wed, 29 Feb 2012 12:52:40 +0100
> "Sebastian Reitenbach"  wrote:
> > since there is the limitation in npppd that it doesn't support multiple 
> > clients behind the same NAT host for IPSec/L2TP, I'm looking 
> > into using PPTP with EAP-TLS authentication. But I'm wondering, whether 
> > this is supported by npppd.
> > The examples in the HOWTO_PIPEX_NPPPD.txt only use mschapv2 and chap with 
> > the local authentication.
> > When I'd use radius authentication, would it be possible to use EAP-TLS 
> > then?
>  
> EAP support of npppd was deleted.
> 
>   http://www.openbsd.org/cgi-bin/cvsweb/src/usr.sbin/npppd/npppd/Attic/eap.c
> 
> I want to write eap.c again, but it is a later item in my TODOs.

thank you for you answer. Then I don't need to bang my head against the wall 
after setting up all this testing environment,
jut to find out its not (yet ;) working.

Sebastian

> 
> --yasuoka

Re: Hardware (firewall) recommendation

On Tuesday, April 17, 2012 09:35 CEST, Henning Brauer  
wrote: 

> * Marcin  [2012-04-17 08:59]:
> > I am looking for a hardware recommendation for a new OpenBSD based
> > firewalls. So far I have been using IBM x336s, but they are slowly
> > approaching end of life.
> > 
> > What I am after:
> > * 1U i386/amd64 server,
> > * 2 sockets,
> 
> what for? unless you run extremely heavy userland proxies, you don't
> get much (any) benefit, especially given that the one-socket machines
> are all 4core now.
> 
> > * RAID 1 SAS/SATA controller (2 hard drives are enough)
> 
> what for? that increases complexity and thus chance to fail with no
> benefit. you have no precious data on those disks and have two
> machines.
> 
> I'm very happy with Supermicro X9SC* based systems, with Xeon E3-1220
> and an Intel SSD. Check with your local supplier for exact model
> options. Superior performance, 35W idle, no trouble whatsoever, fair
> pricing.

Sorry for hijacking the thread, but I was going to ask a very similar question 
later today.
I've seen, some of those boards have IPMI interface, which would be one of my 
requirements.

The processor with its 4 cores should probably be fine handling a few ftp-proxy 
and relayd.

I'd like to put in two 10GB ethernet adapters, CX or fibre is still to be 
decided. Looking 
at the amd64.html page, I found the ixgb, ix, xge and tht supported. Looking at 
the manual
pages, I'd probably go for the xge based cards, since they support checksum 
offload and 
VLAN tag insertion and stripping, to move some load from the CPU on to the 
network cards. 

I'd like to know if my assumption to the cards are right, and whether this box 
would be able
to handle that kind of bandwidth the cards provide. It actually only needs to 
handle about 3GB/s,
but don't want to start trunking GigaBit interfaces. Or if I'm wrong with my 
assumptions,
if someone has good experience with other 10GbE adapters.

cheers,
Sebastian

> 
> -- 
> Henning Brauer, h...@bsws.de, henn...@openbsd.org
> BS Web Services, http://bsws.de, Full-Service ISP
> Secure Hosting, Mail and DNS Services. Dedicated Servers, Root to Fully 
> Managed
> Henning Brauer Consulting, http://henningbrauer.com/

Re: Hardware (firewall) recommendation

On Tuesday, April 17, 2012 10:47 CEST, Henning Brauer  
wrote: 
 
> * Sebastian Reitenbach  [2012-04-17 10:40]:
> > On Tuesday, April 17, 2012 09:35 CEST, Henning Brauer 
> >  wrote: 
> >  
> > > * Marcin  [2012-04-17 08:59]:
> > > > I am looking for a hardware recommendation for a new OpenBSD based
> > > > firewalls. So far I have been using IBM x336s, but they are slowly
> > > > approaching end of life.
> > > > 
> > > > What I am after:
> > > > * 1U i386/amd64 server,
> > > > * 2 sockets,
> > > 
> > > what for? unless you run extremely heavy userland proxies, you don't
> > > get much (any) benefit, especially given that the one-socket machines
> > > are all 4core now.
> > > 
> > > > * RAID 1 SAS/SATA controller (2 hard drives are enough)
> > > 
> > > what for? that increases complexity and thus chance to fail with no
> > > benefit. you have no precious data on those disks and have two
> > > machines.
> > > 
> > > I'm very happy with Supermicro X9SC* based systems, with Xeon E3-1220
> > > and an Intel SSD. Check with your local supplier for exact model
> > > options. Superior performance, 35W idle, no trouble whatsoever, fair
> > > pricing.
> > 
> > Sorry for hijacking the thread, but I was going to ask a very similar 
> > question later today.
> > I've seen, some of those boards have IPMI interface, which would be one of 
> > my requirements.
> 
> I don't use their ipmi, all hail cereal consoles.

I thought about being able to power cycle the machine when it freezes that 
hard, when it 
may not drop into ddb. Otherwise yes, serial console would suffice, even 
rebooting from
within ddb. I hope it may not happen at all, but who knows, hardware may be 
faulty, and
weird things may happen ;)

> 
> > The processor with its 4 cores should probably be fine handling a few 
> > ftp-proxy and relayd.
> 
> easily.
> 
> > I'd like to put in two 10GB ethernet adapters, CX or fibre is still to be 
> > decided. Looking 
> > at the amd64.html page, I found the ixgb, ix, xge and tht supported. 
> > Looking at the manual
> > pages, I'd probably go for the xge based cards, since they support checksum 
> > offload and 
> > VLAN tag insertion and stripping, to move some load from the CPU on to the 
> > network cards. 
> 
> CPU cycles are not your problem really. memory bandwidth is another story.
OK good point, thanks.

> 
> > I'd like to know if my assumption to the cards are right, and whether this 
> > box would be able
> > to handle that kind of bandwidth the cards provide. It actually only needs 
> > to handle about 3GB/s,
> > but don't want to start trunking GigaBit interfaces. Or if I'm wrong with 
> > my assumptions,
> > if someone has good experience with other 10GbE adapters.
> 
> it should, I think, but this is always a bit hard to predict.

Also here, thanks. I didn't expected to get around of a test, just wanted to 
get a little bit 
of confidence, I don't move into a totally wrong direction with my assumptions.

Sebastian


> 
> -- 
> Henning Brauer, h...@bsws.de, henn...@openbsd.org
> BS Web Services, http://bsws.de, Full-Service ISP
> Secure Hosting, Mail and DNS Services. Dedicated Servers, Root to Fully 
> Managed
> Henning Brauer Consulting, http://henningbrauer.com/

Re: Hardware (firewall) recommendation

On Tuesday, April 17, 2012 12:15 CEST, Sebastian Benoit  
wrote: 
 
> Henning Brauer(lists-open...@bsws.de) on 2012.04.17 11:52:49 +0200:
> > > I thought about being able to power cycle the machine when it freezes 
> > > that hard, when it 
> > > may not drop into ddb. Otherwise yes, serial console would suffice, even 
> > > rebooting from
> > > within ddb. I hope it may not happen at all, but who knows, hardware may 
> > > be faulty, and
> > > weird things may happen ;)
> > 
> > I use seperate power controllers.
> 
> i use the ipmi to reboot/power-cycle and monitoring PSUs. The IPMI SOL
> console on the supermicros has problems here with loosing/not displaying
> characters when pasting larger chunks of text, so i still use the serial
> console.
>   
> > > > > I'd like to know if my assumption to the cards are right, and whether 
> > > > > this box would be able
> > > > > to handle that kind of bandwidth the cards provide. It actually only 
> > > > > needs to handle about 3GB/s,
> > > > > but don't want to start trunking GigaBit interfaces. Or if I'm wrong 
> > > > > with my assumptions,
> > > > > if someone has good experience with other 10GbE adapters.
> > > > it should, I think, but this is always a bit hard to predict.
> > > Also here, thanks. I didn't expected to get around of a test, just wanted 
> > > to get a little bit 
> > > of confidence, I don't move into a totally wrong direction with my 
> > > assumptions.
> > 
> > looks like you're right on track :)
> > 
> > let us know how it goes.
> 
> yes please.
> 

First some other questions also need to get resolved, before even ordering the 
HW.
So an answer may take a month or two. But I'll keep reporting back on my TODO 
list.

cheers,
Sebastian

Re: Compiling non-ports application from source

On Tuesday, April 17, 2012 12:42 CEST, Laurence Rochfort 
 wrote: 

> Thank you everyone for the kind advice.
> 
> I think I have a correct understanding of packges/ports and shall
> double check if what I need isn't already there.
> 
> I'm meant to be working right now, ahem, so I'll investigate further
> when I get home and try to work this out myself.
> 
> Is this the correct mailing list to ask questions should I have
> problems linking required libraries?

You are probably better suited then on the ports@ mailing list.

When I find a software which is not as package or in the ports tree available,
the first thing is to try to leverage the ports infrastructure to get me 
started.

I usually take a port directory where I think it might be similar, copy that 
over,
and start working from there. 
If you don't know about how the ports infrastructure works, you should take a
look here: http://www.openbsd.org/faq/ports/
Also consult other ports as examples.

Starting with a port, instead of just trying to compile things from source in 
e.g. 
your home directory might sound like a huge task. But starting with the right
thing in the beginning, will pay out at the end. 

cheers,
Sebastian

> 
> On 17 April 2012 11:33, Marc Espie  wrote:
> > On Tue, Apr 17, 2012 at 12:30:18PM +0200, Marc Espie wrote:
> >> If you really want to look at things, compiling the port is very easy,
> though
> >> it will usually take longer (sometimes much longer for monsters like
> >> libreoffice). It's as stupid as cd /usr/ports/lang/swi-prolog && make
> install
> >>
> >> Most software compiles just fine on OpenBSD. It's just that if you want
> >> to do it by hand, you have to hunt for the dependencies, and give the
> right
> >> environment/options to configure.
> >
> > Another way to look at things is that the ports system is mostly
> "Automated"
> > hand builds.
> >
> > It was designed to be as transparent as possible.  Apart from the
> paraphernalia
> > needed to version packages, handle lists of files, and track dependencies,
> > it's  just fetch/extract/patch/configure/build/install (obvious
> > oversimplification), but it's not something arcane and impossible
> > to understand.

Re: Hardware (firewall) recommendation