Re: Intel E823-L Ethernet interfaces not detected
Hi Jonathan, This at least confirms the behavior is expected, thanks for the clarity. In the mean time, I've got plenty of new things to explore on the 7.3 release - with a pair of two perfectly good X550 Ethernet interfaces to do it with! For now I'll leave a standing offer: Any time into the future, if somebody at the project is thinking "Gee, wish I had an Intel E800 platform to evaluate" - reach out to me and I'd be happy to lend mine, and cover costs too. :) Thanks to you and all other contributors for the stellar software! -Andrew
Intel E823-L Ethernet interfaces not detected
Hi @misc, I just installed OpenBSD 7.3-release on a new amd64 system to replace an old one that had been on OpenBSD 5.5 (it was set it and forget it till the CPU fried!). I've found that some of the Ethernet interfaces aren't seen in ifconfig, so I suspect there's no driver/support yet. dmesg also reflects unknown ethernet devices (full output attached at the bottom of this message). I searched @misc and @tech archives and didn't succeed in finding any discussions, so starting one here (apology if I missed something). The non-working interfaces are using an Intel E823-L controller, while the working interfaces are using an Intel X550 controller. The mainboard is an Intel Xeon-D 1700 SoC platform (Supermicro X12SDV-4C-SPT4F). Of course I'd love some easy solution but hey, it is what it is if the support just isn't there. :) Searching online, I did find an Intel driver link for this controller that supports FreeBSD: https://www.intel.com/content/www/us/en/download/18332/ intel-network-adapter-freebsd-virtual-function-driver-for-intel-ethernet -controller-700-and-e810-series.html I also found a verbose lspci dump for the controller: https://www.servethehome.com/supermicro-x12sdv-4c-sp6f-review-25gbe-and- intel-xeon-d-1718t/supermicro-intel-e823-l-lspci-vvv/ ^ I think that's probably from Linux though. If my message in any way comes off as urgent - please know, it is not. I know the OpenBSD devs are busy. No expectations on my part at all. Although, I am willing to help any way I can. If somebody would like the use of the system, happy to lend it out, etc. Cheers, Andrew Full dmesg follows: OpenBSD 7.3 (GENERIC.MP) #1125: Sat Mar 25 10:36:29 MDT 2023 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 33909121024 (32338MB) avail mem = 32862027776 (31339MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 3.4 @ 0x6c252000 (48 entries) bios0: vendor American Megatrends International, LLC. version "1.1" date 10/05/2022 bios0: Supermicro Super Server efi0 at bios0: UEFI 2.8 efi0: American Megatrends rev 0x50018 acpi0 at bios0: ACPI 6.4 acpi0: sleep states S0 S5 acpi0: tables DSDT FACP SPMI FIDT SSDT TCPA SSDT ERST BERT SSDT MCFG BDAT HMAT HPET WDDT APIC SLIT SRAT OEM4 OEM1 SSDT HEST DMAR TPM2 SSDT SSDT WSMT acpi0: wakeup devices RP01(S0) PXSX(S0) RP02(S0) PXSX(S0) RP03(S0) PXSX(S0) RP04(S0) PXSX(S0) RP05(S0) PXSX(S0) RP06(S0) PXSX(S0) RP07(S0) PXSX(S0) RP08(S0) PXSX(S0) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimcfg0 at acpi0 acpimcfg0: addr 0x8000, bus 0-255 acpihpet0 at acpi0: 2399 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Xeon(R) D-1718T CPU @ 2.60GHz, 2594.08 MHz, 06-6c-01 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,SDBG,FMA3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,PQM,AVX512F,AVX512DQ,RDSEED,ADX,SMAP,AVX512IFMA,CLFLUSHOPT,CLWB,PT,AVX512CD,SHA,AVX512BW,AVX512VL,AVX512VBMI,UMIP,PKU,WAITPKG,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu0: 48KB 64b/line 12-way D-cache, 32KB 64b/line 8-way I-cache, 1MB 64b/line 20-way L2 cache, 10MB 64b/line 20-way L3 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 25MHz cpu0: mwait min=64, max=64, C-substates=0.2.0.1, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Xeon(R) D-1718T CPU @ 2.60GHz, 2594.08 MHz, 06-6c-01 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,SDBG,FMA3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,PQM,AVX512F,AVX512DQ,RDSEED,ADX,SMAP,AVX512IFMA,CLFLUSHOPT,CLWB,PT,AVX512CD,SHA,AVX512BW,AVX512VL,AVX512VBMI,UMIP,PKU,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu1: 48KB 64b/line 12-way D-cache, 32KB 64b/line 8-way I-cache, 1MB 64b/line 20-way L2 cache, 10MB 64b/line 20-way L3 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 4 (application processor) cpu2: Intel(R) Xeon(R) D-1718T CPU @ 2.60GHz, 2594.08 MHz, 06-6c-01 cpu2: 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,SDBG,FMA3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,
isakmpd peculiarities, ipsec.conf manpage inaccuracy
Hi all, I'm running OpenBSD 5.8-stable. The ipsec.conf manpage indicates that if no srcid is present in an automatic keying IKE statement, then the value in the identification should be the host IP address, and be an IP address type. I've found this to be incorrect; if no srcid is specified, my system makes the type in the identification payload an FQDN, and sets the value to the machine's hostname. In order to pass just the IP address (and be an IP address type), I had to explicity set srcid to the IP address in the ike statement. Moving on, I am troubleshooting an issue where I'm able to connect a Macbook running OS X to a remote access VPN service (L2TP + IPsec) I pay for, but my seemingly identically-configured OpenBSD 5.8-stable workstation cannot connect. Specifically the IPsec negotiation fails. The failure occurs in the very beginning of the phase 2 negotiation, when the OpenBSD system sends the first Quick Mode message with its ID payloads. The remote peer always responds to this message with an "INVALID ID RECEIVED" notification, despite the ID payloads being identical to what my OS X system sends. After decrypting the IKE exchange from both my OpenBSD system and my OS X system, while I find the identification payload in the first quick mode message to be the same, I actually discovered a difference in the final segment of the main mode Identity Protection phase: In 3rd and final exchange in IKE phase 1 (Identity protection, main mode): *isakmpd appends an "INITIAL-CONTACT" Notification payload to the end of its message *The Identification payload contains zero-values for the port and protocol ID This is in contrast to my Mac OS X system which does not include the notification payload, and in the ID payload, it indicates a protocol of UDP and port 500. To be fair, the IETF IPSec DoI for ISAKMP actually does indicate that both the behavior of my Mac and of OpenBSD are acceptable. That being the case, these are the only meaningful differences I've been able to identify between OS X and OpenBSD, and ultimately I'd really like to be able to connect to the VPN. Does anybody know if there are any settings I can use to modify the behavior of isakmpd to be in line with what OS X does? I would greatly value any input. I have to say, decrypting the IKE exchange from OS X was a fairly annoying and tedius process. I love how with isakmpd I can just pass it the -L parameter and it will automatically dump a capture of the decrypted exchange. Warm regards, Andrew
IKE phase 2 failing, but don't see any obvious problem
Hi all, I'm working on bringing up a remote-access L2TP + IPSec VPN on an OpenBSD 5.8 workstation. Note that this system is the client side L2TP LAC, not a server-side L2TP LNS. Therefore I am using xl2tpd instead of npppd, which will only handle server-side configurations. My issue actually seems unrelated to the underlying tunneling protocol. I'm running into an IKE phase 2 failure, specifically when first moving into quick mode. My OpenBSD system sends the first quick mode message that contains its advertised remote and local network information. In this case, it's very simple as it's simply the traffic between what will become the L2TP endpoints, so: proto usb from 1.1.1.1 to 2.2.2.2 port 1701 1.1.1.1 is my local IP and 2.2.2.2 is the remote endpoint. When my system sends this as the ID information in the quick mode message however, the remote endpoint responds with: INVALID ID INFORMATION. I've tried a variety of things, but I can't determine what's wrong here. Phase 1 completes without issue. Below is the isakmpd.pcap output showing the failure: 08:32:37.154146 1.1.1.1.4500 > 2.2.2.2.4500: [bad udp cksum e7bc! -> 3d4d] udpencap: isakmp v1.0 exchange QUICK_MODE cookie: -> msgid: d8e18d0e len: 148 payload: HASH len: 24 payload: SA len: 52 DOI: 1(IPSEC) situation: IDENTITY_ONLY payload: PROPOSAL len: 40 proposal: 1 proto: IPSEC_ESP spisz: 4 xforms: 1 SPI: 0xdad40d72 payload: TRANSFORM len: 28 transform: 1 ID: AES attribute LIFE_TYPE = SECONDS attribute LIFE_DURATION = 3600 attribute ENCAPSULATION_MODE = TUNNEL attribute AUTHENTICATION_ALGORITHM = HMAC_SHA attribute KEY_LENGTH = 128 payload: NONCE len: 20 payload: ID len: 12 proto: 17 port: 0 type: IPV4_ADDR = 1.1.1.1 payload: ID len: 12 proto: 17 port: 1701 type: IPV4_ADDR = 2.2.2.2 [ttl 0] (id 1, len 180) 08:32:37.167755 2.2.2.2.4500 > 1.1.1.1.500: [bad udp cksum a74b! -> a767] udpencap: isakmp v1.0 exchange INFO cookie: -> msgid: 16fb376e len: 76 payload: HASH len: 24 payload: NOTIFICATION len: 16 notification: INVALID ID INFORMATION [ttl 0] (id 1, len 108) Perhaps another set of eyes might catch what I have not. Any input would be greatly appreciated. :) Warm regards, Andrew
Remote access VPN on OpenBSD workstation...
Hi all, Allow me to apologize in advance if I've overlooked something here. I am using an OpenBSD workstation and have a need to establish a remote access VPN by authenticating to an IPsec-protected L2TP LNS endpoint. The desired operation is for the workstation to use the far-end ppp interface as its default gateway. My question is whether npppd can be configured in this manner. Reading through the npppd and npppd.conf manpages, the configurations mainly appear to pertain to configuring an L2TP server that remote users can then connect to, and in fact I've only been able to find guides for such configurations online as well. I'm trying to achieve the opposite of this. Am I simply overlooking something? For simplicity sake I'm not yet concerned about getting the IPSec layer operational, which seems slightly more straightforward. Is there a way to configure npppd as a LAC client or does it only function as an LNS? If the latter, is there other software available that can act as a native LAC client on OpenBSD? This is in reference to OpenBSD 5.8 stable. Thank you, Andrew Lester
Trouble applying patch 003 to OpenBSD 5.8-stable
Hi all, I'm setting up OpenBSD 5.8-stable and installing the patches for the known errata. I'm buying the CD set but installed with the install58.iso from a mirror. As such I don't think the bad src.tar.gz on the CD will affect me; I've used src.tar.gz from the mirror. I'm having problems installing the patch for errata #003. This the uvm patch. It appears that the file attempted to be patch is /usr/src/sys/uvm/uvm_km.c. When attempting to patch, it stalls and asked me to provide the path to the file to patch, because the previously mentioned file actually seems to not exist. Is this an optional patch or am I missing something? This is an amd64 platform and I installed all the sets. Patch 001 and 002 had no problem. Warm regards, Andrew Lester
Patch 009 fails on BASE-5.6 amd64
Hi All, I’ve just performed a fresh install of OpenBSD 5.6-BASE (not an upgrade) using the purchased disc set, and have been applying the patches in order, and all have been successful. However, the httpd patch (#009) has failed, and I ended up with several “rej” files. This system could not be more vanilla, no additional software was installed. The X packages and games were not installed. I have taken the output of the signify command which provides information about the specific failures, as well as the four rej files that were generated and put them into a tar archive if anybody would like to see the specifics of the failure. Here is a shared link from Dropbox: https://www.dropbox.com/s/yk9olnqdeeru7m6/009_httpd_failures.tar?dl=0 Has anybody else encountered this issue? I am holding off on applying the additional patches in the mean time. Please let me know if there is any additional information I can provide. Kind regards, Andrew Lester
Patching X in BASE without X
Hi All, This should be a very easy question. A while back I had questioned when running a system with BASE whether it is fine to skip applying patches not applicable to my system’s uses, and whether they can be done out of order. The response I got was mixed, but it seems the safest bet is to apply patches in order, and apply all patches. This being the case, will it in any way harm or cause problems on a system if I apply patches for X, if I do not have X installed? Kind regards, Andrew Lester
Clarification on patching 5.5-release...
Hello misc, I've got some simple questions on the patch process which I couldn't find answers to on my own. Currently I am running 5.5-RELEASE, and sitting on my 5.6 disc set waiting to upgrade. I want to make sure I've been patching my 5.5 system correctly first, though. :) 1) Can patches be applied selectively and out of order? 2) Is it necessary to reboot the system between each patch, or can a batch be applied, and then a reboot performed? 3) Early on I made what I hope is an inconsequential mistake. One of the first patches that I applied, I ran the signify command not from root, but using sudo, and didn't put sudo in the second part of the piped command. I didn't catch this until after going through the make obj, make and make install process (with sudo). When I realized the second part of the original signify command didn't work successfully as it was not run with root privileges, I just went through the process again, from the root account. Doing this seemed to be successful. Does anybody know if this would have failed for any reason? My next question is regarding patching the kernel, as is the case with the 013, 016 and 017 patches for OpenBSD 5.5-RELEASE. Unlike the other patches, kernel patches don't have explicit instructions on rebuilding the kernel. I believe I've found a correct procedure, and would like to confirm it will work. My system uses the AMD64 GENERIC.MP kernel. Is the below process correct? 1) Download the patch file and run the associated piped signify command 2) Then, run the following commands: cd /usr/src/sys/arch/amd64/conf config GENERIC.MP && cd ../compile/GENERIC.MP make depend && make && make install reboot If this process is incorrect, what would I do instead? How would I back up the old kernel? Finally, I arrive at my last question, and it relates to another careless mistake on my part. :( I downloaded the sig files, and ran the associated signify commands for patch 013 and 016 before realizing they were kernel patches and I didn't know how to recompile the kernel yet. I caught 017 luckily (fool me thrice?). Is it a problem that the source patches for 013 and 016 have both been applied, without going through the make process between? If so, is there a way I can revert the 016 source patch so I can first make and install the 013 patch? If not, is it safe to recompile the kernel with both source patches in place? If yes, I assume it would also be safe to throw in 017 as well so I can get all three patches in with a single compile, correct? Many thanks to anybody who can assist me! :) Warm regards, Andrew Lester
Ordering OpenBSD 5.6 in the US?
Hey all, I notice the Softpro books seller, the only one for the US, indicates that they will no longer sell OpenBSD as distribution is moving to Europe. That being the case, what would the best place to order the disc set for OpenBSD 5.6 in the US be? Any word on when a preorder will be available? Warm regards, Andrew
Re: OpenBSD 5.5: question regarding pf syntax
Thanks all! My actual issue was using braces more than once. To the last person
that replied -- that was precisely what I am trying to avoid, having a rule
defined for each set of ports!
Warm regards,
Andrew
Sent from my iPhone
> On Sep 27, 2014, at 9:00 PM, System Administrator wrote:
>
>> On 27 Sep 2014 at 18:50, Andrew Lester wrote:
>>
>> Hey guys,
>>
>> I have what I hope is a simple syntax question for pf rules. I have not
>> been able to find any example of this online or in the man pages. I
>> suspect it is perhaps not possible. Basically I want to allow out
>> certain web services, with a simple rule like below:
>>
>> pass out on em0 proto tcp from 192.168.1.0/24 port $ports to any
>>
>> My trouble is with the $ports macro. Here's what I am trying to do:
>>
>> $common= '"{80,443,465,587,993}"'
>> $games= '"{5222,7778,28900}"'
>>
>> $ports= "{" $common $games "}"
>>
>> NOTE: In my real config the macros are above the rule, and I have tried
>> with and without enclosing the top two macros in the single quotes.
>
> Your problem is not with the quotes but with the braces -- only one set
> of braces is needed and accepted when defining a list.
>
>> This way when I need to allow specific applications out, instead of
>> having a huge single macro where I will forget what the ports are for, I
>> can have smaller macros that I just add into the single macro which I
>> use in the pf rule. Instead of making a new rule for each application, I
>> can just add to the $ports macro.
>>
>> pf however indicates that the $ports macro is not valid syntax.
>>
>> Is this a syntax error on my part, or is this something pf cannot do?
>> Totally fine if the latter, I just want to make sure I am not missing
>> something silly with the syntax. :)
>>
>>
>> Warm regards,
>> Andrew
OpenBSD 5.5: question regarding pf syntax
Hey guys,
I have what I hope is a simple syntax question for pf rules. I have not been
able to
find any example of this online or in the man pages. I suspect it is perhaps
not possible.
Basically I want to allow out certain web services, with a simple rule like
below:
pass out on em0 proto tcp from 192.168.1.0/24 port $ports to any
My trouble is with the $ports macro. Here's what I am trying to do:
$common= '"{80,443,465,587,993}"'
$games= '"{5222,7778,28900}"'
$ports= "{" $common $games "}"
NOTE: In my real config the macros are above the rule, and I have tried with and
without enclosing the top two macros in the single quotes.
This way when I need to allow specific applications out, instead of having a
huge single
macro where I will forget what the ports are for, I can have smaller macros
that I just
add into the single macro which I use in the pf rule. Instead of making a new
rule for
each application, I can just add to the $ports macro.
pf however indicates that the $ports macro is not valid syntax.
Is this a syntax error on my part, or is this something pf cannot do? Totally
fine if
the latter, I just want to make sure I am not missing something silly with the
syntax. :)
Warm regards,
Andrew
Re: Thanks for ksh
Would the /bin/sh shell in OpenBSD, which is a "reimplementation of bash" be affected by either of these exploits? So happy to learn no action is needed on my part for my OpenBSD sever :) Sent from my iPhone > On Sep 25, 2014, at 9:10 AM, sven falempin wrote: > > On Thu, Sep 25, 2014 at 8:11 AM, Christian Weisgerber > wrote: >> On 2014-09-25, Craig R. Skinner wrote: >> >>> All the highly skilled work invested in the project, keeping ordinary >>> users secure, is appreciated. >> >> If this is a reference to the "ShellShock" bash bugs (CVE-2014-6271 >> CVE-2014-7169), I'd like to point out that, like many "bash features", >> exported functions originated in Korn shell and the fact that >> OpenBSD's /bin/ksh doesn't implement them is a documented shortcoming >> of pdksh (see src/bin/ksh/NOTES). >> >> -- >> Christian "naddy" Weisgerber na...@mips.inka.de > > Why just focusing on one little piece of the awesomeness ? > > Thanks for all the openBSD related projects and the core project ! > > -- > - > () ascii ribbon campaign - against html e-mail > /\
Re: OpenBSD 5.5: BIND lacks permission to create/modify journal...
Hey Steve, Thanks for the response. I actually found the solution. It turns out that the .jnl files are not the only ones that get modified when using DDNS. Performing a chown -R for named:named on /var/named/master fixed the problem. The actual zone data file, db.home.lan, also gets reformatted in the process, with the new entries. That seems a bit odd to me, I would have thought the whole point of the journal file is preventing the main datafile from being reformatted or changed. Thanks so much, Andrew On Sep 20, 2014, at 5:18 PM, Steve Shockley wrote: > On 9/20/2014 1:46 PM, Andrew Lester wrote: >> Does anybody know what I can do to make the zone journal file be accessible >> by named? > > It's been a while since I set it up, but I gave up and made /var/named/master > owned by named. I also had to set managed-keys-directory "/master" in the > config so managed-keys.bind and managed-keys.bind.jnl were writable. I found > ktrace to be helpful for debugging as well. I probably should have > documented everything I did...
OpenBSD 5.5: BIND lacks permission to create/modify journal...
Hi all,
I am running OpenBSD 5.5-STABLE, and I am experiencing some frustration with
BIND. I use
it for my internal DNS which works great. However, I now need to do some work
with Active
Directory and create a domain controller. I do not want to use the Microsoft
DNS server,
I am trying to use my BIND server and keep things "simple".
Problem:
The domain controller needs to perform dynamic DNS updates. Despite my best
efforts,
the dynamic update sent from the domain controller to my BIND server always
results in the
BIND server responding with a "server failure" (code 2) message.
Upon inspecting my named logs, this is the problem:
general: info: journal file master/db.home.lan.jnl does not exist, creating it
general: error: master/db.home.lan.jnl: create: permission denied
The zone journal file can't be created, presumably because the chrooted
location BIND is
attempting to create the file (/var/named/master) only has permissions for
root:wheel, not
the named user/group which the process runs as.
I thought I would be smart and do:
# touch /var/named/master/db.home.lan.jnl
# chmod 666 /var/named/master/db.home.jnl
This however also fails (even 777). I would see log entries for the dynamic
updates now, but
then those are followed up with these errors:
update: info: client 192.168.1.250#51951: updating zone 'home.lan/IN': error:
journal open failed: no more
This is my zone configuration in named.conf:
zone "home.lan" in {
type master;
file "master/db.home.lan";
allow-update { 192.168.1.250; };
};
192.168.1.250 is the IP address of the domain controller. Note I am not using
DNSSEC or
keys here. I am aware this is not particularly secure, but this is my personal
network
and I just need to test some basic functionality with Active Directory.
Does anybody know what I can do to make the zone journal file be accessible by
named?
Warm regards,
Andrew
OpenBSD 5.5: ICMP port unreachable to DHCP relay agent...
Hi All, Previously I sent out a very long e-mail about this and I didn't get any responses, so this is my second attempt which will be much shorter. Basically, I am having a problem with the included version of dhcpd in OpenBSD 5.5 stable, and I'm not sure if it's an issue with OpenBSD, or my configuration. I suspect the latter. I have OpenBSD acting as the DHCP server for my private LAN. I have two subnets declared in dhcpd.conf. The first subnet is for a network directly served by the OpenBSD server (clients and OpenBSD server in same L3 broadcast domain). The subnet has fixed assignments for all the clients based on their MAC address, and this is no problem. The second subnet is for a network that is not directly connected to the OpenBSD box, instead there is a static route to reach it. Routing between the two networks works perfectly, and in fact the OpenBSD box is the DNS server for the clients in this remote network. I cannot, however, get DHCP working for those clients. Only when I give a client a static IP address does it work. The L3 switch which serves the clients (it is their default gateway) is configured to act as a DHCP relay, and forwards the DHCP traffic from the clients to the OpenBSD box. Here's the failure: 1. Client broadcasts DHCP Discover 2. L3 switch relays the DHCP discover to the OpenBSD box as a unicast to UDP port 67. 3. OpenBSD box receives the relayed unicast DHCP Discover, and responds with an ICMP unreachable message for UDP port 67, which is received by the L3 switch. It's as if port 67 is not listening on the OpenBSD system. I have verified dhcpd is set to listen on all interfaces. I found that netstat never displays an open socket for port 67, but I have since come to learn dhcpd does not use sockets, but BPF which apparently there is no way I can find to see open connections. This is not a firewall issue, I have tried with pf totally disabled, and in fact I also learned pf can't restrict traffic from a BPF connection to begin with. But port 67 is clearly open. The clients in the same broadcast domain which send their UDP DHCP Discovers to 255.255.255.255 port 67 work perfectly. Does anybody know why the OpenBSD system would be sending ICMP port unreachable messages to the DHCP relay agent in response to its relayed DHCP discovers? The DNS queries from these clients to the OpenBSD system (same IP as the dhcp server) on port 53 all work perfectly. Unlike dhcpd, I can verify with netstat that BIND is listening on port 53 for DNS queries. Warm regards, Andrew
ICMP unreachable in response to relayed DHCP requests
Hi All, I am experiencing an issue with dhcpd on OpenBSD 5.5-stable. I’ve been searching extensively and can’t seem to find any solution. I am using OpenBSD as a default gateway for two VLANs, and for one of the VLANs, dhcpd is handing out IP addresses. In this VLAN, DHCP works perfectly. The other VLAN does not have DHCP enabled. However, I have a second subnet set up in /etc/dhcpd.conf for a remote network on my private LAN. Clients in that remote network have another L3 switch as their default gateway, and in turn, the L3 switch uses the OpenBSD system as its default gateway. The OpenBSD system has a static route for the remote network. Routing between the networks works perfectly. If I statically assign an IP address to a client in the remote network, I have full network access to my private LAN and out to the Internet. But when I configure the L3 switch to act as a DHCP relay agent, and forward DHCP requests to the OpenBSD DHCP server, DHCP does not work. Clients on the remote network do not get replies from the DHCP server, and get a self assigned IP address (169.x.x.x). The relay agent on the L3 switch sends the DHCP requests to the same IP address and interface on the OpenBSD system that the clients in the directly-connected VLAN use. If I perform a packet capture on that interface on the OpenBSD system to see the relayed DHCP requests, what I see is the request being successfully relayed to the DHCP server, and it is a unicast packet since it was relayed. The source IP is the IP of the routed interface on the L3 switch for the remote network, and the destination IP is the IP address of the DHCP server. The source and destination port is 67. What I would expect to see is the DHCP server reply with a unicast offer to the IP of the routed interface on the L3 switch. Instead, the server replies with an ICMP unreachable packet, indicating that the destination UDP port 67 was unreachable. This ICMP unreachable message is seen on the L3 switch. Again, routing here works as expected. I can ping both the L3 switch interface and clients with a static IP in the remote network from the OpenBSD system just fine. And the L3 switch and remote clients can ping the OpenBSD system just fine as well. What is even more perplexing about the ICMP unreachable for destination port 67 is when I perform the same packet capture of the DHCP process for clients on the local VLAN, the system replies with the very same source IP and port for which the ICMP unreachable packets get generated when remote clients try to use DHCP! This is not a firewall issue either. My only firewall is PF and I've tested with it configured to pass all traffic, and with it completely disabled. The ONLY difference I can see in the packet captures is that for the local clients, the process is initiated by a broadcast packet to port 67, while a unicast packet to port 67 is seen for the remote clients. But again, replies to the local clients will end up coming from the DHCP server IP and port 67 just fine. I apologize for the long winded message. And thank you to anybody who can provide any input! :) Warm regards, Andrew
OpenBSD 5.5 + FreeRADIUS 2.2: PID directory deleted on reboot?
Hi all, This is probably a very simple question, but for the life of me I have not been able to locate a solution. I am running a RADIUS server on OpenBSD 5.5 stable (+ openssl patches) using FreeRADIUS 2.2.0p2 from the ports tree. When I first installed FreeRADIUS, it worked great. However, when I rebooted the system, radiusd would no longer start. I discovered the run_dir of /var/lrun/radiusd, which houses the PID file and socket, was missing. I re-created the directory and changed its ownership to _freeradius. After that, it started working again. But whenever the system reboots, the entire /var/run/radiusd directory gets deleted somehow. The only references I could find regarding this happening with OpenBSD was on a blog, where the recommendation was simply to manually re-create the directory. There must be something I am missing here, and I feel like it’s probably quite simple. Does anybody know what I need to do in order to prevent the run dir from being deleted, or know if there is a better location for it where it won’t be automatically deleted when the system reboots? Thanks in advance for any help, it is much appreciated and OpenBSD rocks! Warm regards, Andrew
Question regarding hearbleed patch (002) for OpenBSD 5.5...
Hi All, I am relatively new to BSD, and by extension, OpenBSD. I am using it on a small Atom-based server to act as a router, firewall and DNS server. In the future, I may use it for web hosting as well. I bought the three disc set to acquire the source code, and then I applied the patch to remedy the issue based on the provided instructions (I am running the amd64 variant). The patch instructions indicated that binaries that are statically linked with libssl also need to be recompiled. The only additional program that I installed (using pkg_add) was vim-7.4.135p0-no_x11-perl-python3-ruby. However, this also installed some additional dependencies, as follows: bzip2-1.0.6p0 gettext-0.18.2p4 libffi-3.0.9p6 libiconv-1.14p1 python-3.3.2p1 quirks-1.113 ruby-1.8.7.374p0 xz-5.0.5p0 How would I determine whether or not any of these include binaries that are statically linked with libssl? Any help is much appreciated! Best regards, Andrew
Re: Support for Intel i354 Quad GbE network adapter?
Jonathan,
Thanks for the reply (I also saw the update you sent). How would I make use
of that?
Simply use the install files from /pub/OpenBSD/snapshots/amd64 versus
/pub/OpenBSD/5.4/amd64? Could you elaborate what you mean by not handling
some of the special casing? Sorry, this is my first run with any sort of
BSD!
Thanks,
Andrew
-Original Message-
From: Jonathan Gray [mailto:j...@jsg.id.au]
Sent: Friday, February 14, 2014 12:00 AM
To: Andrew Lester
Cc: misc@openbsd.org
Subject: Re: Support for Intel i354 Quad GbE network adapter?
On Thu, Feb 13, 2014 at 11:30:14PM -0600, Andrew Lester wrote:
> Hi All,
>
>
>
> I tried to install OpenBSD 5.4 (amd64) on a PC using a Supermicro
>
> A1SRi-2758F motherboard which is based on the Intel Atom C2000
>
> (Rangeley) platform, and has an integrated i354 Quad-port GbE
>
> network adapter. The installation was unable to detect any of the
>
> network interfaces. Is anybody aware of some sort of workaround for
>
> this problem? I tried to do a PXE install which is ironic because it
>
> was over one of the interfaces. At the network configuration part of
>
> the installation, it detected a "vlan0" interface which I was unable
>
> to configure.
Here is a diff against -current that may work but doesn't handle some of the
i354 special casing:
Index: if_em.c
===
RCS file: /cvs/src/sys/dev/pci/if_em.c,v retrieving revision 1.275 diff -u
-p -r1.275 if_em.c
--- if_em.c 28 Dec 2013 03:34:54 - 1.275
+++ if_em.c 14 Feb 2014 05:55:27 -
@@ -144,6 +144,9 @@ const struct pci_matchid em_devices[] =
{ PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_I350_FIBER },
{ PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_I350_SERDES },
{ PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_I350_SGMII },
+ { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_I354_BP_1GBPS },
+ { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_I354_BP_2_5GBPS },
+ { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_I354_SGMII },
{ PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_ICH8_82567V_3 },
{ PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_ICH8_IFE },
{ PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_ICH8_IFE_G },
Index: if_em_hw.c
===
RCS file: /cvs/src/sys/dev/pci/if_em_hw.c,v retrieving revision 1.75 diff -u
-p -r1.75 if_em_hw.c
--- if_em_hw.c 27 Nov 2013 01:13:10 - 1.75
+++ if_em_hw.c 14 Feb 2014 05:54:27 -
@@ -523,6 +523,9 @@ em_set_mac_type(struct em_hw *hw)
case E1000_DEV_ID_I350_SERDES:
case E1000_DEV_ID_I350_SGMII:
case E1000_DEV_ID_I350_DA4:
+ case E1000_DEV_ID_I354_BACKPLANE_1GBPS:
+ case E1000_DEV_ID_I354_SGMII:
+ case E1000_DEV_ID_I354_BACKPLANE_2_5GBPS:
hw->mac_type = em_i350;
hw->initialize_hw_bits_disable = 1;
hw->eee_enable = 1;
Index: if_em_hw.h
===
RCS file: /cvs/src/sys/dev/pci/if_em_hw.h,v retrieving revision 1.56 diff -u
-p -r1.56 if_em_hw.h
--- if_em_hw.h 27 Nov 2013 01:13:10 - 1.56
+++ if_em_hw.h 14 Feb 2014 05:55:22 -
@@ -571,6 +571,9 @@ int32_t em_check_phy_reset_block(struct
#define E1000_DEV_ID_I350_SGMII 0x1524
#define E1000_DEV_ID_82576_QUAD_CU_ET2 0x1526
#define E1000_DEV_ID_I350_DA40x1546
+#define E1000_DEV_ID_I354_BACKPLANE_1GBPS 0x1F40
+#define E1000_DEV_ID_I354_SGMII 0x1F41
+#define E1000_DEV_ID_I354_BACKPLANE_2_5GBPS 0x1F45
#define E1000_DEV_ID_82574L 0x10D3
#define E1000_DEV_ID_EP80579_LAN_1 0x5040
#define E1000_DEV_ID_EP80579_LAN_2 0x5044
Support for Intel i354 Quad GbE network adapter?
Hi All, I tried to install OpenBSD 5.4 (amd64) on a PC using a Supermicro A1SRi-2758F motherboard which is based on the Intel Atom C2000 (Rangeley) platform, and has an integrated i354 Quad-port GbE network adapter. The installation was unable to detect any of the network interfaces. Is anybody aware of some sort of workaround for this problem? I tried to do a PXE install which is ironic because it was over one of the interfaces. At the network configuration part of the installation, it detected a "vlan0" interface which I was unable to configure. Thanks, Andrew
