Re: Intel I210 ethernet card support
On Aug 10, 2013, at 6:10, Jonathan Gray wrote: > The i210/i211 chips aren't supported yet. The i217/pch_lpt found > in the Lynx Point/Haswell PCH isn't either. I don't think any of > the usual suspects have hardware yet. Do those that need the hardware have it yet? If not, what's needed? The Supermicro X10SLL-S would be a good choice since it has both i217LM & i210AT Ethernet. That board along with a Pentium G3220 and 4GB of ECC RAM could get a developer the required hardware for Haswell. Bryan
Re: uaudio0: audio descriptors make no sense, with Schiit Bifrost USB DAC
Martijn Rijkeboer wrote: >>> I have a Schiit Bifrost USB DAC that includes an uaudio device for audio >>> playback. When I plug the device in I'm getting "uaudio0: audio >>> descriptors make no sense, error=4". Any suggestions on how to make this >>> work? >>> >>> Here are the relevant lines from usbdevs -v (debugging enabled for >>> uaudio): >> >> Looks like the audio descriptor of your device doesn't match what >> uaudio(4) expects. A quirk might be needed. Could you please >> install the usbutils package and post the output of "lsusb -v" for >> your device? > > Below are the relevant lines of "lsusb -v". Before I ran lsusb I've > re-installed the system with current (i386). > > Bus 000 Device 002: ID 0d8c:0319 C-Media Electronics, Inc. ... > Interface Descriptor: > bLength 9 > bDescriptorType 4 > bInterfaceNumber0 > bAlternateSetting 0 > bNumEndpoints 1 > bInterfaceClass 1 Audio > bInterfaceSubClass 1 Control Device > bInterfaceProtocol 32 > iInterface 2 Schiit USB Audio Device > AudioControl Interface Descriptor: > bLength 9 > bDescriptorType36 > bDescriptorSubtype 1 (HEADER) > --> bcdADC 2.00 <-- If I'm interpreting this correctly your device is an USB Audio 2.0 device. AFAICT there's currently no support for such a device in OpenBSD.
Re: yubikey offline login
On 09/09/13 16:48, alex wrote: Hi! Is anybody know about possibility local (offline) login to OpenBSD? I found this article http://www.h-ein.de/projekte/yubikey-login-auth-module-openbsd.html (i know about yubikey for ssh auth : http://undeadly.org/cgi?action=article&sid=20130616112437 Thanks, Alex Popov All our base are belong to you. man login_yubikey man login.conf /Alexander
Re: pflow packets before state expires
The manual say the information is extracted from the state table. So you should have seen the info. First: are you sure the information wasnt in the udp pflow packets ? maybe the collector was wrong. Second: man says <> + On Mon, Sep 9, 2013 at 11:55 AM, Matt Hamilton wrote: > Hi All, > We use pflow with pf to export packets to a collector for > billing/monitoring > purposes. The problem we have is that someone at the weekend had a very > long running scp connection over several days that transferred a TB > of data. The data was not logged via pflow until the state expired, so > then showed a massive spike when the state expired. > > Anyone know any way around this? Is it possible to get pf/pflow to > export more regularly? Or set some timeout? I'm guessing not due > to the architecture, and unless I force pf states to timeout then I'm > stuck? But thought I'd ask in case anyone knew of a way. > > Thanks > -Matt > > -- - () ascii ribbon campaign - against html e-mail /\
pflow packets before state expires
Hi All, We use pflow with pf to export packets to a collector for billing/monitoring purposes. The problem we have is that someone at the weekend had a very long running scp connection over several days that transferred a TB of data. The data was not logged via pflow until the state expired, so then showed a massive spike when the state expired. Anyone know any way around this? Is it possible to get pf/pflow to export more regularly? Or set some timeout? I'm guessing not due to the architecture, and unless I force pf states to timeout then I'm stuck? But thought I'd ask in case anyone knew of a way. Thanks -Matt
yubikey offline login
Hi! Is anybody know about possibility local (offline) login to OpenBSD? I found this article http://www.h-ein.de/projekte/yubikey-login-auth-module-openbsd.html (i know about yubikey for ssh auth : http://undeadly.org/cgi?action=article&sid=20130616112437 Thanks, Alex Popov
Re: Strange vlan interface behavior/crash
* Wiesław Kielas [04.09.2013. @15:44:05 +0200]: > Hi misc@, > > I have a Dell PowerEdge M600 machine running OpenBSD 5.3 which causes > frequent problems - once about every few days vlan interfaces stop > working. > > Ifconfig reports them being up the whole time, but when trying to ping > anything in the given vlan, the ping fails (this also applies to the > loopback address on the interface - it doesn't reply as well), as if no > packets were transmitted on it. This applies to all packets on the > interface, not just ICMP ones. > > This doesn't seem to be a PF issue, since disabling it doesn't help, and > non-vlan interfaces (like trunk0 with trunkproto failover) continue to > work. > > Putting the interface down and up, destroying and creating it or running > /etc/netstart doesn't help - a reboot is required, after which the > machine works correctly again for some time. > > I checked the logs and dmesg and found there nothing of any value - no > new messages around the time of the crash. > > As this is a blade machine, most hardware issues (like memory problems) > would be reported by the chassis, and it reports none. > > I have a couple other M600 machines running OpenBSD, with the same > network cards, and only once this problem did occur on another machine - > a slave for the problematic one, running pfsync, sasync and acting as a > carp backup. > > Could anyone provide me with some tips on how to debug the problem > further? Turn on some kernel debug mode, make use of the kernel > debugger? I'm at my wits end here. > > If there is any information that I could provide to help solve the > problem, please don't hesitate to ask. > > The dmesg is attached below: > > I'm currently testing a diff which disables hw vlan tag processing, which I recieved off-list. Aside from that, after increasing isakmpd verbosity, I started getting messages like this before every vlan freeze: > isakmpd[6940]: dropped message from 193.xxx.xxx.xxx port 500 due to > notification type INVALID_FLAGS Could they be somehow related? -- regards, Wiesław Kielas
Re: Help with ISAKMP Nat Traversal Problem needed
Here is another debug output and tcpdump for the same problem. Following the advice from Stuart Henderson I change the debug levels to isakmpd -D0=29 -D1=49 -D2=10 -D3=30 -D6=99 -D7=99 -D8=99 -D9=30 -D10=20 -K -L Here again the tcpdump and the new debug output 16:08:35.114550 0.0.0.0.500 > 217.86.184.8.500: [udp sum ok] isakmp v1.0 exchange ID_PROT cookie: 1a0208d771df46ef-> msgid: len: 184 payload: SA len: 56 DOI: 1(IPSEC) situation: IDENTITY_ONLY payload: PROPOSAL len: 44 proposal: 1 proto: ISAKMP spisz: 0 xforms: 1 payload: TRANSFORM len: 36 transform: 0 ID: ISAKMP attribute ENCRYPTION_ALGORITHM = AES_CBC attribute HASH_ALGORITHM = MD5 attribute AUTHENTICATION_METHOD = PRE_SHARED attribute GROUP_DESCRIPTION = MODP_1024 attribute LIFE_TYPE = SECONDS attribute LIFE_DURATION = 3600 attribute KEY_LENGTH = 128 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 212) 16:08:35.184157 217.86.184.8.500 > 217.110.66.79.500: [udp sum ok] isakmp v1.0 exchange ID_PROT cookie: 1a0208d771df46ef->be3ad6b901947e8e msgid: len: 116 payload: SA len: 56 DOI: 1(IPSEC) situation: IDENTITY_ONLY payload: PROPOSAL len: 44 proposal: 1 proto: ISAKMP spisz: 0 xforms: 1 payload: TRANSFORM len: 36 transform: 1 ID: ISAKMP attribute ENCRYPTION_ALGORITHM = AES_CBC attribute KEY_LENGTH = 128 attribute HASH_ALGORITHM = MD5 attribute GROUP_DESCRIPTION = MODP_1024 attribute AUTHENTICATION_METHOD = PRE_SHARED attribute LIFE_TYPE = SECONDS attribute LIFE_DURATION = 3600 payload: VENDOR len: 12 payload: VENDOR len: 20 (supports NAT-T, RFC 3947) [ttl 0] (id 1, len 144) 16:08:35.275577 217.110.66.79.500 > 217.86.184.8.500: [udp sum ok] isakmp v1.0 exchange ID_PROT cookie: 1a0208d771df46ef->be3ad6b901947e8e msgid: len: 220 payload: KEY_EXCH len: 132 payload: NONCE len: 20 payload: NAT-D len: 20 payload: NAT-D len: 20 [ttl 0] (id 1, len 248) 16:08:35.363848 217.86.184.8.500 > 217.110.66.79.500: [udp sum ok] isakmp v1.0 exchange ID_PROT cookie: 1a0208d771df46ef->be3ad6b901947e8e msgid: len: 268 payload: KEY_EXCH len: 132 payload: NAT-D len: 20 payload: NAT-D len: 20 payload: NONCE len: 24 payload: VENDOR len: 12 payload: VENDOR len: 12 (supports draft-ietf-ipsra-isakmp-xauth-06.txt) payload: VENDOR len: 20 (supports DPD v1.0) [ttl 0] (id 1, len 296) 16:08:35.454563 217.110.66.79.4500 > 217.86.184.8.4500: [bad udp cksum c9d0!] udpencap: isakmp v1.0 exchange ID_PROT cookie: 1a0208d771df46ef->be3ad6b901947e8e msgid: len: 88 payload: ID len: 12 type: IPV4_ADDR = 217.110.66.79 payload: HASH len: 20 payload: NOTIFICATION len: 28 notification: INITIAL CONTACT (1a0208d771df46ef->be3ad6b901947e8e) [ttl 0] (id 1, len 120) 16:08:35.523331 217.86.184.8.4500 > 217.110.66.79.4500: [bad udp cksum 1c00!] udpencap: isakmp v1.0 exchange ID_PROT cookie: 1a0208d771df46ef->be3ad6b901947e8e msgid: len: 60 payload: ID len: 12 type: IPV4_ADDR = 192.168.50.253 payload: HASH len: 20 [ttl 0] (id 1, len 92) 16:08:35.615285 217.110.66.79.4500 > 217.86.184.8.4500: [udp sum ok] udpencap: isakmp v1.0 exchange QUICK_MODE cookie: 1a0208d771df46ef->be3ad6b901947e8e msgid: ceee06b6 len: 288 payload: HASH len: 20 payload: SA len: 56 DOI: 1(IPSEC) situation: IDENTITY_ONLY payload: PROPOSAL len: 44 proposal: 1 proto: IPSEC_ESP spisz: 4 xforms: 1 SPI: 0x4dc1e13b payload: TRANSFORM len: 32 transform: 1 ID: AES attribute LIFE_TYPE = SECONDS attribute LIFE_DURATION = 1200 attribute ENCAPSULATION_MODE = TUNNEL attribute AUTHENTICATION_ALGORITHM = HMAC_MD5 attribute GROUP_DESCRIPTION = 2 attribute KEY_LENGTH = 128 payload: NONCE len: 20 payload: KEY_EXCH len: 132 payload: ID len: 16 type: IPV4_ADDR_SUBNET = 129.143.250.128/255.255.255.128 payload: ID len: 16 type: IPV4_ADDR_SUBNET = 192.168.199.0/255.255.255.0 [ttl 0] (id 1, len 320)
Re: uaudio0: audio descriptors make no sense, with Schiit Bifrost USB DAC
>> I have a Schiit Bifrost USB DAC that includes an uaudio device for audio >> playback. When I plug the device in I'm getting "uaudio0: audio >> descriptors make no sense, error=4". Any suggestions on how to make this >> work? >> >> Here are the relevant lines from usbdevs -v (debugging enabled for >> uaudio): > > Looks like the audio descriptor of your device doesn't match what > uaudio(4) expects. A quirk might be needed. Could you please > install the usbutils package and post the output of "lsusb -v" for > your device? Below are the relevant lines of "lsusb -v". Before I ran lsusb I've re-installed the system with current (i386). Bus 000 Device 002: ID 0d8c:0319 C-Media Electronics, Inc. Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 239 Miscellaneous Device bDeviceSubClass 2 ? bDeviceProtocol 1 Interface Association bMaxPacketSize064 idVendor 0x0d8c C-Media Electronics, Inc. idProduct 0x0319 bcdDevice1.02 iManufacturer 1 Schiit iProduct2 Schiit USB Audio Device iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 298 bNumInterfaces 3 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xc0 Self Powered MaxPower 100mA Interface Association: bLength 8 bDescriptorType11 bFirstInterface 0 bInterfaceCount 2 bFunctionClass 1 Audio bFunctionSubClass 0 bFunctionProtocol 32 iFunction 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 1 Audio bInterfaceSubClass 1 Control Device bInterfaceProtocol 32 iInterface 2 Schiit USB Audio Device AudioControl Interface Descriptor: bLength 9 bDescriptorType36 bDescriptorSubtype 1 (HEADER) bcdADC 2.00 bCategory 10 wTotalLength 256 bmControl0x00 AudioControl Interface Descriptor: bLength17 bDescriptorType36 bDescriptorSubtype 2 (INPUT_TERMINAL) bTerminalID 1 wTerminalType 0x0101 USB Streaming bAssocTerminal 0 bCSourceID 18 bNrChannels 0 bmChannelConfig 0x bmControls0x0040 Cluster Control (read-only) iChannelNames 0 iTerminal 0 AudioControl Interface Descriptor: bLength12 bDescriptorType36 bDescriptorSubtype 3 (OUTPUT_TERMINAL) bTerminalID 7 wTerminalType 0x0301 Speaker bAssocTerminal 0 bSourceID 13 bCSourceID 18 bmControls 0x iTerminal 0 AudioControl Interface Descriptor: bLength18 bDescriptorType36 bDescriptorSubtype 6 (FEATURE_UNIT) bUnitID13 bSourceID 1 bmaControls( 0) 0x0003 Mute Control (read/write) bmaControls( 1) 0x bmaControls( 2) 0x iFeature0 AudioControl Interface Descriptor: bLength 8 bDescriptorType36 bDescriptorSubtype 10 (CLOCK_SOURCE) bClockID 18 bmAttributes 0x03 Internal programmable Clock bmControls 0x07 Clock Frequency Control (read/write) Clock Validity Control (read-only) bAssocTerminal 0 iClockSource0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x8f EP 15 IN bmAttributes3 Transfer TypeInterrupt Synch Type None Usage Type Data wMaxPacketSize 0x0006 1x 6 bytes bInterval 4 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber1 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 1 Audio bInterfaceSubClass 2 Streaming bInterfaceProtocol 32 iInterface 4 Speaker-Schiit USB Audio Device Interface Descriptor:
Re: how to set framebuffer resolution
On 2013-09-09, remy couture wrote: > Hi, > > i'm looking for infos on how to play with the screen resolution on intel > framebuffer. > > Other OSes have some kind of "mode setting" at the boot loader level, what > about OpenBSD ? > > Thank you very much > > At the moment, all you can do is disable kernel modesetting completely (I had to do this on one server where the attached monitor doesn't support the newly chosen resolution). at the bootloader: boot -c disable inteldrm (or radeondrm) quit or similar via config(8).
Re: nat-to static-port chooses random ports
On 2013-09-07, Christopher Zimmermann wrote: > Hi, > > as far as I understand pf, the following rules should behave exactly > the same: > > pass out log on pppoe0 inet proto udp from mortimer-ipsec port 5061 nat-to > (pppoe0) static-port > and > pass out log on pppoe0 inet proto udp from mortimer-ipsec port 5061 nat-to > (pppoe0) port 5061 > > but they don't: > > rule 98/(match) pass out on pppoe0: 217.190.89.90.56487 > 88.215.213.26.5748: > udp 2048 > resp. > rule 98/(match) pass out on pppoe0: 217.190.89.90.5061 > 62.138.116.3.5748: > udp 2048 > > this is on an OPENBSD_5_4 kernel. > > -- > http://gmerlin.de > OpenPGP: http://gmerlin.de/christopher.pub > 1917 680A 723C BF3D 2CA3 0E44 7E24 D19F 34B8 2A2A > > [demime 1.01d removed an attachment of type application/pgp-signature] > > The most likely reason for this failing is if you have tried to translate to a port which is already in-use. If "translate" in "pfctl -si" is non-zero, then this has happened.
Re: A suggestion for snapshots
On 2013-09-07, Lars Engblom wrote: > I think the issue is more about space than bandwidth. No, it's about bandwidth, first from the build machines to the main distribution site (fanout), and then from the fanout to mirrors. Between them, amd64 and i386 packages take ~40GB, then there are the other slower arch which are pushed out a bit less often. Feeding this out across the mirroring infrastructure takes time. > From: Theo de Raadt > Date: 07/09/2013 06:13 (GMT+02:00) > > Anyone want to pay for a faster network link? > > Step up -- then we can solve this problem easily. Of course this is only easy now that Theo and a few others have recently put significant effort into improving the internet infrastructure in Alberta.
Re: ISAKMPD NAT/Traversal
On 2013-09-07, Christoph Leser wrote: >>Von: owner-m...@openbsd.org [owner-m...@openbsd.org]" im Auftrag von >>"Stuart Henderson >[s...@spacehopper.org] >>Gesendet: Samstag, 7. September 2013 00:11 >>An: misc@openbsd.org >>Betreff: Re: ISAKMPD NAT/Traversal > >>>On 2013-09-06, Christoph Leser wrote: >>> Hello, list, >>> >>> from a remark by Stuart Henderson on an older thread >>> http://marc.info/?l=openbsd-misc&m=134849 788026722&w=2 back in September >>> 2012,I understood that NAT-T support in openBSD was not complete at that >>> time, >>> especially the handling of the 'ENCAPSULATION_MODE' attribute in the phase 2 >>> 'TRANSFORM'. Sometimes this gets set to a value incompatible with other >>> equipment ( cisco ). >>> >>> Can someone please point me to where I can find more information on this >>> matter. Has anything changed in openBSD with regard to this, will openBSD >>> follow RFC3947 with regard to the encapsulation modes ( or is RFC3947 deas, >>> it >>> seems to be a standard proposal since 2005 ). >>> >>> Mit freundlichen Gr��en >>> >>> Christoph Leser >>> >>> S&P Computersysteme GmbH >>> Zettachring 4 >>> 70567 Stuttgart Fasanenhof >>> >>> EMail: le...@sup-logistik.de >>> > > >>You misunderstand. OpenBSD uses the proper assigned encapsulation mode >>values from the newer internet-drafts and the published RFC: > >>http://tools.ietf.org/html/draft-ietf-ipsec-nat-t-ike-04#section-5.1 >>http://tools.ietf.org/html/rfc3947#section-5.1 > >>It is Cisco who use the old encapsulation mode values from the early >>versions of the internet-draft (marked "XXX CHANGE" here): > >>http://tools.ietf.org/html/draft-ietf-ipsec-nat-t-ike-03#section-5.1 > > > thanks for the clarification. Does that mean that openBSD sends > UDP-Encapsulated-Tunnel (=3) mode when it detects NAT? But the > isakmpd.pcap still shows "attribute ENCAPSULATION_MODE = TUNNEL" in the > TRANSFORM payload? IIRC that is the case. > I ask because I have problems with a SonicWall behind a Nat on the > remote site, which claims that my openBSD "TUNNEL(=1) instead of > Encapsulated Tunnel(=3). At this point I think you probably need to break out the debug logs to try and work out what's going on. My general-use logging setup for isakmpd is "-v -D0=29 -D1=49 -D2=10 -D3=30 -D5=20 -D6=30 -D8=30 -D9=30 -D10=20" though sometimes certain areas need tweaking.
Re: Exploits
Andy writes: > On first look I couldn't see the exploit in that old PDF being listed on > the errata's. Maybe I'm being blind ;) Or maybe you need to take a second look (010). The security problem is described, a workaround and a patch are available. Publishing an exact how-to-reproduce-and-expoit-a-bug isn't one of the the responsibilities of the OpenBSD project, afaik. > On Sat 07 Sep 2013 19:45:38 BST, Greg Thomas wrote: >> "Does this document still hold any truth with current OpenBSD;" >> >> Come on, really? >> >> http://www.openbsd.org/errata40.html >> >> >> On Sat, Sep 7, 2013 at 8:13 AM, andy wrote: >> >>> Hi everyone, >>> >>> I have a feeling that I may get some strong opinions on this question, so >>> please don't flame me or anything, I'm asking because I don't know. >>> >>> Does this document still hold any truth with current OpenBSD; >>> >>> https://www.blackhat.com/presentations/bh-usa-07/Ortega/Whitepaper/bh-usa-07-ortega-WP.pdf >>> >>> Cheers, Andy. Ciao, -- jca | PGP: 0x06A11494 / 61DB D9A0 00A4 67CF 2A90 8961 6191 8FBF 06A1 1494
Re: Exploits
On first look I couldn't see the exploit in that old PDF being listed on the errata's. Maybe I'm being blind ;) On Sat 07 Sep 2013 19:45:38 BST, Greg Thomas wrote: "Does this document still hold any truth with current OpenBSD;" Come on, really? http://www.openbsd.org/errata40.html On Sat, Sep 7, 2013 at 8:13 AM, andy wrote: Hi everyone, I have a feeling that I may get some strong opinions on this question, so please don't flame me or anything, I'm asking because I don't know. Does this document still hold any truth with current OpenBSD; https://www.blackhat.com/presentations/bh-usa-07/Ortega/Whitepaper/bh-usa-07-ortega-WP.pdf Cheers, Andy.
Re: uaudio0: audio descriptors make no sense, with Schiit Bifrost USB DAC
!-- On Sat 7.Sep'13 at 11:17:56 BST, Martijn Rijkeboer (mart...@bunix.org), wrote: > Hi, > > I have a Schiit Bifrost USB DAC that includes an uaudio device for audio > playback. When I plug the device in I'm getting "uaudio0: audio > descriptors make no sense, error=4". Any suggestions on how to make this > work? This is the error I have seen when my USB webcam is plugged in. It has a built-in microphone, it's that component that generates the message. I posted the information to misc@ a couple of months back, using a current snapshot. To-date, I have not been able to find a fix for it. [ ... ] -- James Griffin: jmz at kontrol.kode5.net A4B9 E875 A18C 6E11 F46D B788 BEE6 1251 1D31 DC38
Help with ISAKMP Nat Traversal Problem needed
Hello misc, My openBSD Gateway seems to have a problem with ISAKMP Nat Traversal to a remote Sonicwall. The ISAKMP Exchange fails in pase 2. The remote Sonicwall is behind a NAT device. Before I blame one side or the other for misbehavior, I would like you to take a look at the traces I will provide here and help me with the proper interpretation. The setup is simple: openBSD has direct access to the internet with IP address 217.110.66.79 SonicWall is behind IP address 217.86.184.8 My /etc/ipsec.conf is ike active esp tunnel from 129.143.250.128/25 to 192.168.199.0/24 peer 217.86.184.8 main auth hmac-md5 enc aes-128 group modp1024 quick auth hmac-md5 enc aes-128 group modp1024 psk 'xyz' What I think happens here is that openBSD recognizes that a NAT device is between Sonicwall and itself. And switches to NAT encapsulation. And Sonciwall only proposes NAT-T with RFC3947. ( Also see the NAT related messages in the debug output below ) But in the phase 2 transform proposal openBSD requests 'TUNNEL' encapsulation mode instead of 'UDP-encapsulated-TUNNEL' as required by RFC-3947. ( See bytes 78-7b in the hexdump of the first quick mode packet, it reads 80040001 instead of 80040003 ). Here is tcpdump output from /var/run/isakmpd.pcap ( I have removed the hexdump part from all but the last packet for brevity ) 10:36:51.578451 0.0.0.0.500 > 217.86.184.8.500: [udp sum ok] isakmp v1.0 exchange ID_PROT cookie: daf885a1cd119c2d-> msgid: len: 184 payload: SA len: 56 DOI: 1(IPSEC) situation: IDENTITY_ONLY payload: PROPOSAL len: 44 proposal: 1 proto: ISAKMP spisz: 0 xforms: 1 payload: TRANSFORM len: 36 transform: 0 ID: ISAKMP attribute ENCRYPTION_ALGORITHM = AES_CBC attribute HASH_ALGORITHM = MD5 attribute AUTHENTICATION_METHOD = PRE_SHARED attribute GROUP_DESCRIPTION = MODP_1024 attribute LIFE_TYPE = SECONDS attribute LIFE_DURATION = 3600 attribute KEY_LENGTH = 128 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 212) 10:36:51.651586 217.86.184.8.500 > 217.110.66.79.500: [udp sum ok] isakmp v1.0 exchange ID_PROT cookie: daf885a1cd119c2d->3264ac29e5082e4c msgid: len: 116 payload: SA len: 56 DOI: 1(IPSEC) situation: IDENTITY_ONLY payload: PROPOSAL len: 44 proposal: 1 proto: ISAKMP spisz: 0 xforms: 1 payload: TRANSFORM len: 36 transform: 1 ID: ISAKMP attribute ENCRYPTION_ALGORITHM = AES_CBC attribute KEY_LENGTH = 128 attribute HASH_ALGORITHM = MD5 attribute GROUP_DESCRIPTION = MODP_1024 attribute AUTHENTICATION_METHOD = PRE_SHARED attribute LIFE_TYPE = SECONDS attribute LIFE_DURATION = 3600 payload: VENDOR len: 12 payload: VENDOR len: 20 (supports NAT-T, RFC 3947) [ttl 0] (id 1, len 144) 10:36:51.745502 217.110.66.79.500 > 217.86.184.8.500: [udp sum ok] isakmp v1.0 exchange ID_PROT cookie: daf885a1cd119c2d->3264ac29e5082e4c msgid: len: 220 payload: KEY_EXCH len: 132 payload: NONCE len: 20 payload: NAT-D len: 20 payload: NAT-D len: 20 [ttl 0] (id 1, len 248) 10:36:51.833947 217.86.184.8.500 > 217.110.66.79.500: [udp sum ok] isakmp v1.0 exchange ID_PROT cookie: daf885a1cd119c2d->3264ac29e5082e4c msgid: len: 268 payload: KEY_EXCH len: 132 payload: NAT-D len: 20 payload: NAT-D len: 20 payload: NONCE len: 24 payload: VENDOR len: 12 payload: VENDOR len: 12 (supports draft-ietf-ipsra-isakmp-xauth-06.txt) payload: VENDOR len: 20 (supports DPD v1.0) [ttl 0] (id 1, len 296) 10:36:51.927437 217.110.66.79.4500 > 217.86.184.8.4500: [bad udp cksum aaf3!] udpencap: isakmp v1.0 exchange ID_PROT cookie: daf885a1cd119c2d->3264ac29e5082e4c msgid: len: 88 payload: ID len: 12 type: IPV4_ADDR = 217.110.66.79 payload: HASH len: 20 payload: NOTIFICATION len: 28 notification: INITIAL CONTACT (daf885a1cd119c2d->3264ac29e5082e4c) [ttl 0] (id 1, len 120) 10:36:51.998066 217.86.184.8.4500 > 217.110.66.79.4500: [bad udp cksum 1c00!] udpencap: isakmp v1.0 exchange ID_PROT cookie: daf885a1cd119c2d->3264ac29e5082e4c msgid: len: 60 payload: ID len: 12 type: IPV4_ADDR = 192.168.50.253 payload: HASH len: 20 [ttl 0] (id 1, l
Re: uaudio0: audio descriptors make no sense, with Schiit Bifrost USB DAC
On 07/09/13(Sat) 12:17, Martijn Rijkeboer wrote: > Hi, > > I have a Schiit Bifrost USB DAC that includes an uaudio device for audio > playback. When I plug the device in I'm getting "uaudio0: audio > descriptors make no sense, error=4". Any suggestions on how to make this > work? > > Here are the relevant lines from usbdevs -v (debugging enabled for uaudio): Looks like the audio descriptor of your device doesn't match what uaudio(4) expects. A quirk might be needed. Could you please install the usbutils package and post the output of "lsusb -v" for your device? Martin
Re: spamd(8) more persistent greytrapping
Op Thu, 29 Aug 2013 14:04:59 +0200 schreef Boudewijn Dijkstra
:
Here's a suggested improvement to spamlogd(8) which keeps greytrap
entries tarpitted while they keep trying. [...]
Because at least one person expressed an interest in my modification, find
below an updated patch that fixes a subtle bug. The previous version could
accidentally trap hosts that were just whitelisted but not yet added in
the pf table . The version below leaves these entries alone.
--- spamlogd.c.54 Fri Mar 18 23:37:06 2011
+++ spamlogd.c Mon Sep 9 10:52:51 2013
@@ -21,7 +21,7 @@
* OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
*/
-/* watch pf log for mail connections, update whitelist entries. */
+/* watch pf log for mail connections, update spamdb entries. */
#include
#include
@@ -33,6 +33,7 @@
#include
#include
#include
+#include
#include
#include
@@ -64,6 +65,7 @@
int greylist = 1;
FILE *grey = NULL;
+u_short spamd_port;
u_short sync_port;
int syncsend;
u_int8_tflag_debug = 0;
@@ -74,13 +76,14 @@
pcap_t *hpcap = NULL;
struct syslog_data sdata = SYSLOG_DATA_INIT;
time_t whiteexp = WHITEEXP;
+time_t trapexp = TRAPEXP;
extern char*__progname;
void logmsg(int , const char *, ...);
void sighandler_close(int);
intinit_pcap(void);
void logpkt_handler(u_char *, const struct pcap_pkthdr *, const u_char *);
-intdbupdate(char *, char *);
+intdbupdate(char *, char *, int);
void usage(void);
void
@@ -110,9 +113,11 @@
init_pcap(void)
{
struct bpf_program bpfp;
- charfilter[PCAPFSIZ] = "ip and port 25 and action pass "
- "and tcp[13]&0x12=0x2";
+ charfilter[PCAPFSIZ];
+ snprintf(filter, PCAPFSIZ, "ip and (port 25 or %d) and action pass "
+ "and tcp[13]&0x12=0x2", spamd_port);
+
if ((hpcap = pcap_open_live(pflogif, PCAPSNAP, 1, PCAPTIMO,
errbuf)) == NULL) {
logmsg(LOG_ERR, "Failed to initialize: %s", errbuf);
@@ -157,6 +162,11 @@
const struct ip *ip = NULL;
const struct pfloghdr *hdr;
char ipstraddr[40] = { '\0' };
+ int white = 1;
+ unsigned int off;
+ const struct tcphdr *tcp;
+ unsigned int iplen;
+ unsigned int port;
hdr = (const struct pfloghdr *)sp;
if (hdr->length < MIN_PFLOG_HDRLEN) {
@@ -185,26 +195,34 @@
else if (hdr->dir == PF_OUT && !flag_inbound)
inet_ntop(af, &ip->ip_dst, ipstraddr,
sizeof(ipstraddr));
+ off = ntohs(ip->ip_off);
+ if ((off & 0x1fff) == 0) {
+ iplen = ip->ip_hl * 4;
+ tcp = (const struct tcphdr *)(sp + hdrlen + iplen);
+ port = ntohs(tcp->th_dport);
+ if (port == spamd_port)
+ white = 0;
+ }
}
if (ipstraddr[0] != '\0') {
- if (hdr->dir == PF_IN)
- logmsg(LOG_DEBUG,"inbound %s", ipstraddr);
- else
- logmsg(LOG_DEBUG,"outbound %s", ipstraddr);
- dbupdate(PATH_SPAMD_DB, ipstraddr);
+ logmsg(LOG_DEBUG, "%s %s %s",
+ hdr->dir == PF_IN ? "inbound" : "outbound",
+ white ? "white" : "spamd",
+ ipstraddr);
+ dbupdate(PATH_SPAMD_DB, ipstraddr, white);
}
}
int
-dbupdate(char *dbname, char *ip)
+dbupdate(char *dbname, char *ip, int white)
{
HASHINFOhashinfo;
DBT dbk, dbd;
DB *db;
struct gdatagd;
time_t now;
- int r;
+ int r, mod;
struct in_addr ia;
now = time(NULL);
@@ -224,7 +242,7 @@
dbk.data = ip;
memset(&dbd, 0, sizeof(dbd));
- /* add or update whitelist entry */
+ /* add or update entry */
r = db->get(db, &dbk, &dbd, 0);
if (r == -1) {
logmsg(LOG_NOTICE, "db->get failed (%m)");
@@ -237,18 +255,11 @@
gd.first = now;
gd.bcount = 1;
gd.pass = now;
- gd.expire = now + whiteexp;
- memset(&dbk, 0, sizeof(dbk));
- dbk.size = strlen(ip);
- dbk.data = ip;
- memset(&dbd, 0, sizeof(dbd));
- dbd.size = sizeof(gd);
- dbd.data = &gd;
- r = db->put(db, &dbk, &dbd, 0);
- if (r) {
- logmsg(LOG_NOTICE, "db->put failed (%m)");
- goto bad;
- }
+ if (white) {
+ gd.expire = now + whiteexp;
+ mo
Re: how to set framebuffer resolution
The FAQ has some info on making the text console have more lines on x86-y machines, if that is what you are after. 2013/9/9 remy couture > Hi, > > i'm looking for infos on how to play with the screen resolution on intel > framebuffer. > > Other OSes have some kind of "mode setting" at the boot loader level, what > about OpenBSD ? > > Thank you very much > > -- May the most significant bit of your life be positive.
ipsec with ipcomp configuration challange.
Hello Configuration challenge for ipsec.conf with ipcomp. the reason for doing this is an attempt to speed up the connection to a site in singapore from norway. The Singapore site has OpenBSD 5.3 but is not used in the config test. What I have been using and is working in the test(ipsec.conf): ike esp from $lan_Dalen2 to $lan_Maffy \ local $FW_Dalen2 peer $FW_Maffy \ main auth hmac-sha1 enc aes-128 group modp1024 life 3600 \ quick auth hmac-sha1 enc aes-128 group modp1024 life 3600 \ psk $psk_Maffy tag ipsec This works fine. Then I tried to add after: flow ipcomp from $lan_Dalen2 to $lan_Maffy peer $FW_Maffy The second line is accepted by ipsecctl but has no impact. ipcomp is enabled: # sysctl |grep ipcomp net.inet.ipcomp.enable=1 Test boxes: # uname -a OpenBSD dalen 5.0 GENERIC#43 i386 # uname -a OpenBSD worf 5.1 GENERIC.MP#188 i386 >From the man ipsec.conf MANUAL SECURITY ASSOCIATIONS might be needed? I have been searching before posting but I can't seem to find the answer. does a working example exist that could be made public? Regards Gaute Lundal
