Re: IPv6 link-local not working on gre(4) since 5.9

[Masao Uebayashi]

On Wed, Jun 22, 2016 at 02:00:25AM +0200, Michael Lechtermann wrote:
> > Try "route -n get -inet6 fe80::20d:b9ff:fe12:730c%gre0" and what do you see?
> > 
> > IPv6 link-local routing implementation is tricky.  The route entries toward
> > fe80::20d:b9ff:fe12:730c are stored as "fe80:::20d:b9ff:fe12:730c" where
> >  is a scope ID; in OpenBSD, "interface index" (if_index) is used.
> > 
> > If you don't have a routing entry to fe80::20d:b9ff:fe12:730c%gre0 (see
> > netstat -nrf inet6), you end up with "no route to host”.
> 
> Result from one of the affected production hosts (Host 1):
> 
> # route -n get -inet6 fe80::29c:2ff:fe9d:6042%gre2
>route to: fe80::29c:2ff:fe9d:6042%gre2
> destination: fe80::
>mask: ffc0::
> gateway: ::1
>   interface: lo0
>  if address: ::1
>priority: 8 (static)
>   flags: 
>  use   mtuexpire
>   247623  1400 0
> 
> The command "netstat -nrf inet6 | grep fe80::29c:2ff:fe9d:6042” comes up 
> empty.
> 
> Host 1:
> # ifconfig gre2
> gre2: flags=9011 mtu 1400
> priority: 0
> groups: gre
> tunnel: net  -> 
> inet6 fe80::2b4:acff:fe1f:6a70%gre2 ->  prefixlen 64 scopeid 0xa
> inet6 fd70:6e76:706e:1694:124::2 ->  prefixlen 126
> inet 172.16.94.126 --> 172.16.94.125 netmask 0xfffc

I wonder how these link-local SLAAC addresses are assigned (decided), when,
and by whom.

(If gre(4) doesn't have a MAC address, how can you decide?)

Re: IPv6 link-local not working on gre(4) since 5.9

[Michael Lechtermann]

> Try "route -n get -inet6 fe80::20d:b9ff:fe12:730c%gre0" and what do you see?
> 
> IPv6 link-local routing implementation is tricky.  The route entries toward
> fe80::20d:b9ff:fe12:730c are stored as "fe80:::20d:b9ff:fe12:730c" where
>  is a scope ID; in OpenBSD, "interface index" (if_index) is used.
> 
> If you don't have a routing entry to fe80::20d:b9ff:fe12:730c%gre0 (see
> netstat -nrf inet6), you end up with "no route to host”.

Result from one of the affected production hosts (Host 1):

# route -n get -inet6 fe80::29c:2ff:fe9d:6042%gre2
   route to: fe80::29c:2ff:fe9d:6042%gre2
destination: fe80::
   mask: ffc0::
gateway: ::1
  interface: lo0
 if address: ::1
   priority: 8 (static)
  flags: 
 use   mtuexpire
  247623  1400 0

The command "netstat -nrf inet6 | grep fe80::29c:2ff:fe9d:6042” comes up empty.

Host 1:
# ifconfig gre2
gre2: flags=9011 mtu 1400
priority: 0
groups: gre
tunnel: net  -> 
inet6 fe80::2b4:acff:fe1f:6a70%gre2 ->  prefixlen 64 scopeid 0xa
inet6 fd70:6e76:706e:1694:124::2 ->  prefixlen 126
inet 172.16.94.126 --> 172.16.94.125 netmask 0xfffc

Host 2:
# ifconfig gre1
gre1: flags=9011 mtu 1400
priority: 0
groups: gre
tunnel: net  -> 
inet6 fe80::29c:2ff:fe9d:6042%gre1 ->  prefixlen 64 scopeid 0x9
inet6 fd70:6e76:706e:1694:124::1 ->  prefixlen 126
inet 172.16.94.125 --> 172.16.94.126 netmask 0xfffc


IPv4 as well as the following ping6 command work, it seems that just link-local 
is affected since 5.9, which breaks OSPF (bird).
# ping6 fd70:6e76:706e:1694:124::1

Re: Relayd TLS bug, CA file, relay doesn't start

[Lampshade]

I should post this message under this subject,
not Re: Relayd TLS client mode CA verification.
#
Unfortunately relayd still has this bug.

I have:
sysctl kern.version
 
kern.version=OpenBSD 6.0-beta (GENERIC.MP) #2198: Sun Jun 19 11:58:45 MDT
2016
r...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP

As was said: if destination can be predicted at config writing time,
then there is workaround. However I use relayd also for MitM on
my browser to enhance my privacy using privoxy. This lack of
certificate check makes me vulnerable for MitM attack by
someone outside my computer.

Re: IPv6 link-local not working on gre(4) since 5.9

[Michael Lechtermann]

Forgot to mention login credentials for the test VMs:

User: root
Pass: r00t


> On 21Juni, 2016, at 19:26, Michael Lechtermann  
> wrote:
> 
> Hi,
> 
> I’ve uploaded the two Virtualbox test VMs I created to replicate the issue.
> 
> http://openbsd.lechtermann.net/pub/OpenBSD_59_gre_issue.zip
> 
> I originally installed them with 5.8 were I knew IPV6 link-local over gre was 
> still working and upgraded to 5.9 and snapshot later to replicate the issue I 
> have in production.
> 
> Any feedback would be great.
> 
> Thanks,
> Michael

Re: IPv6 link-local not working on gre(4) since 5.9

[Michael Lechtermann]

Hi,

I’ve uploaded the two Virtualbox test VMs I created to replicate the issue.

http://openbsd.lechtermann.net/pub/OpenBSD_59_gre_issue.zip

I originally installed them with 5.8 were I knew IPV6 link-local over gre was 
still working and upgraded to 5.9 and snapshot later to replicate the issue I 
have in production.

Any feedback would be great.

Thanks,
Michael


> On 16Juni, 2016, at 16:24, mich...@lechtermann.net wrote:
> 
>> Synopsis:ping6 fe80::29c:2ff:fe9d:6042%gre0 (example) fails with 5.9 and 
>> -current
>> Category:kernel
>> Environment:
>   System  : OpenBSD 5.9
>   Details : OpenBSD 5.9-stable (GENERIC.MP) #2: Mon Jun  6 13:29:56 
> UTC 2016
>
> r...@leaseweb.0x13a.net:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> 
>   Architecture: OpenBSD.amd64
>   Machine : amd64
>> Description:
> IPv6 link-local connections do not work on gre(4) interfaces. I tested this 
> with 5.8 (works), 5.9 (doesn't work) and -current (also doesn't work). It 
> doesn't matter if the gre(4) traffic is tunneled through IPsec or not.
> 
>> How-To-Repeat:
> 
> On host 1:
> 
> # sysctl net.inet.gre.allow=1
> # echo "inet6 eui64
> inet 10.0.0.1 255.255.255.252
> dest 10.0.0.2
> tunnel 192.168.0.1 192.168.0.2
> up" > /etc/hostname.gre0
> sh /etc/netstart gre0
> 
> 
> On host 2:
> 
> # sysctl net.inet.gre.allow=1
> # echo "inet6 eui64
> inet 10.0.0.2 255.255.255.252
> dest 10.0.0.1
> tunnel 192.168.0.2 192.168.0.1
> up" > /etc/hostname.gre0
> sh /etc/netstart gre0
> 
> 
> On any host (example link-local address and output):
> 
> # ping6 -c 1 fe80::20d:b9ff:fe12:730c%gre0
> PING6 fe80::20d:b9ff:fe12:730c%gre0 (fe80::20d:b9ff:fe12:730c%gre0): 24 data 
> bytes
> ping6: sendmsg: Network is unreachable
> ping6: wrote fe80::20d:b9ff:fe12:730c%gre0 32 chars, ret=-1
> --- fe80::20d:b9ff:fe12:730c%gre0 ping6 statistics ---
> 1 packets transmitted, 0 packets received, 100.0% packet loss
> 
> 
> Expected behavior (this still works with tap):
> 
> # ping6 -c 1 fe80::1408:b5ff:feae:7554%tap1
> PING6 fe80::1408:b5ff:feae:7554%tap1 (fe80::1408:b5ff:feae:7554%tap1): 24 
> data bytes
> 32 bytes from fe80::1408:b5ff:feae:7554%tap1, icmp_seq=0 hlim=64 time=108.879 
> ms
> --- fe80::1408:b5ff:feae:7554%tap1 ping6 statistics ---
> 1 packets transmitted, 1 packets received, 0.0% packet loss
> round-trip min/avg/max/std-dev = 108.879/108.879/108.879/0.000 ms
> 
> 
>> Fix:
>   
> 
> 
> dmesg:
> OpenBSD 5.9-stable (GENERIC.MP) #2: Mon Jun  6 13:29:56 UTC 2016
>r...@leaseweb.0x13a.net:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 4242747392 (4046MB)
> avail mem = 4109963264 (3919MB)
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xbfffc000 (75 entries)
> bios0: vendor HP version "J01" date 07/01/2013
> bios0: HP ProLiant DL120 G7
> acpi0 at bios0: rev 2
> acpi0: sleep states S0 S4 S5
> acpi0: tables DSDT FACP SPCR MCFG HPET  SPMI ERST APIC  BERT HEST 
> DMAR SSDT SSDT SSDT SSDT
> acpi0: wakeup devices PCI0(S4)
> acpitimer0 at acpi0: 3579545 Hz, 24 bits
> acpimcfg0 at acpi0 addr 0xc000, bus 0-63
> acpihpet0 at acpi0: 14318179 Hz
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: Intel(R) Pentium(R) CPU G850 @ 2.90GHz, 2893.82 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,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,DEADLINE,XSAVE,NXE,LONG,LAHF,PERF,ITSC,SENSOR,ARAT
> cpu0: 256KB 64b/line 8-way L2 cache
> cpu0: smt 0, core 0, package 0
> mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
> cpu0: apic clock running at 99MHz
> cpu0: mwait min=64, max=64, C-substates=0.2.1.1, IBE
> cpu1 at mainbus0: apid 2 (application processor)
> cpu1: Intel(R) Pentium(R) CPU G850 @ 2.90GHz, 2893.43 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,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,DEADLINE,XSAVE,NXE,LONG,LAHF,PERF,ITSC,SENSOR,ARAT
> cpu1: 256KB 64b/line 8-way L2 cache
> cpu1: smt 0, core 1, package 0
> ioapic0 at mainbus0: apid 8 pa 0xfec0, version 20, 24 pins
> ioapic0: misconfigured as apic 0, remapped to apid 8
> acpiprt0 at acpi0: bus 10 (IPT1)
> acpiprt1 at acpi0: bus -1 (IPT2)
> acpiprt2 at acpi0: bus -1 (IPT3)
> acpiprt3 at acpi0: bus -1 (IPT4)
> acpiprt4 at acpi0: bus 2 (IPT5)
> acpiprt5 at acpi0: bus 3 (IPT6)
> acpiprt6 at acpi0: bus 13 (IPT7)
> acpiprt7 at acpi0: bus 1 (IPT8)
> acpiprt8 at acpi0: bus 4 (PT02)
> acpiprt9 at acpi0: bus 7 (PT05)
> acpiprt10 at acpi0: bus 0 (PCI0)
> acpicpu0 at acpi0: C3(350@96 mwait.1@0x20), C2(500@64 mwait.1@0x10), 
> C1(1000@1 mwait.1)
> acpicpu1 at acpi0: C3(350@96 mwait.1@0x20), C2(500@64 mwait.1@0x10), 
> C1(1000@1 mwait.1)
> acpitz0 at 

Re: apache-httpd rc script not working properly

[Michael Lechtermann]

Hi,

> On 21Juni, 2016, at 17:03, Antoine Jacoutot  wrote:
> 
> Sorry but I cannot reproduce your issue with a default configuration.
> So you'll have to provide us with more info.

thanks for checking, this is the behavior I get with 5.9:

# time /etc/rc.d/apache2 start
apache2(failed)
0m35.09s real 0m00.27s user 0m02.40s system
[…starts OK, but fails to check, times out…]

# ps ax | grep [h]ttpd2
14568 ??  Ss  0:00.38 httpd2: /usr/local/sbin/httpd2
19759 ??  S   0:00.02 httpd2: /usr/local/sbin/httpd2
 7983 ??  S   0:00.14 httpd2: /usr/local/sbin/httpd2
 8262 ??  S   0:00.06 httpd2: /usr/local/sbin/httpd2
23839 ??  S   0:00.26 httpd2: /usr/local/sbin/httpd2
24914 ??  S   0:00.11 httpd2: /usr/local/sbin/httpd2
19513 ??  S   0:00.20 httpd2: /usr/local/sbin/httpd2
 3778 ??  S   0:00.25 httpd2: /usr/local/sbin/httpd2
 8778 ??  S   0:00.23 httpd2: /usr/local/sbin/httpd2
17706 ??  S   0:00.13 httpd2: /usr/local/sbin/httpd2
 8920 ??  S   0:00.12 httpd2: /usr/local/sbin/httpd2
21764 ??  S   0:00.18 httpd2: /usr/local/sbin/httpd2
23359 ??  S   0:00.12 httpd2: /usr/local/sbin/httpd2
15642 ??  S   0:00.20 httpd2: /usr/local/sbin/httpd2
32692 ??  S   0:00.18 httpd2: /usr/local/sbin/httpd2
19331 ??  S   0:00.10 httpd2: /usr/local/sbin/httpd2
  348 ??  S   0:00.07 httpd2: /usr/local/sbin/httpd2
 1547 ??  S   0:00.28 httpd2: /usr/local/sbin/httpd2
28917 ??  S   0:00.01 httpd2: /usr/local/sbin/httpd2

# /etc/rc.d/apache2 stop
[…no output…]

# ps ax | grep [h]ttpd2
14568 ??  Ss  0:00.38 httpd2: /usr/local/sbin/httpd2
19759 ??  S   0:00.02 httpd2: /usr/local/sbin/httpd2
 8262 ??  S   0:00.06 httpd2: /usr/local/sbin/httpd2
19513 ??  S   0:00.21 httpd2: /usr/local/sbin/httpd2
 7983 ??  S   0:00.14 httpd2: /usr/local/sbin/httpd2
23839 ??  S   0:00.26 httpd2: /usr/local/sbin/httpd2
24914 ??  S   0:00.12 httpd2: /usr/local/sbin/httpd2
 3778 ??  S   0:00.33 httpd2: /usr/local/sbin/httpd2
 8778 ??  S   0:00.23 httpd2: /usr/local/sbin/httpd2
 8920 ??  S   0:00.14 httpd2: /usr/local/sbin/httpd2
17706 ??  S   0:00.15 httpd2: /usr/local/sbin/httpd2
21764 ??  S   0:00.18 httpd2: /usr/local/sbin/httpd2
  348 ??  S   0:00.08 httpd2: /usr/local/sbin/httpd2
32692 ??  S   0:00.22 httpd2: /usr/local/sbin/httpd2
23359 ??  S   0:00.13 httpd2: /usr/local/sbin/httpd2
19331 ??  S   0:00.10 httpd2: /usr/local/sbin/httpd2
15642 ??  S   0:00.20 httpd2: /usr/local/sbin/httpd2
 1547 ??  S   0:00.29 httpd2: /usr/local/sbin/httpd2
28917 ??  S   0:00.01 httpd2: /usr/local/sbin/httpd2

# /etc/rc.d/apache2 reload
apache2(failed)

# ps ax | grep [h]ttpd2
14568 ??  Ss  0:00.41 httpd2: /usr/local/sbin/httpd2
19759 ??  S   0:00.02 httpd2: /usr/local/sbin/httpd2
 8262 ??  S   0:00.07 httpd2: /usr/local/sbin/httpd2
 7983 ??  S   0:00.14 httpd2: /usr/local/sbin/httpd2
24914 ??  S   0:00.12 httpd2: /usr/local/sbin/httpd2
19513 ??  S   0:00.24 httpd2: /usr/local/sbin/httpd2
23839 ??  S   0:00.26 httpd2: /usr/local/sbin/httpd2
 3778 ??  S   0:00.37 httpd2: /usr/local/sbin/httpd2
 8778 ??  S   0:00.23 httpd2: /usr/local/sbin/httpd2
21764 ??  S   0:00.19 httpd2: /usr/local/sbin/httpd2
 8920 ??  S   0:00.15 httpd2: /usr/local/sbin/httpd2
17706 ??  S   0:00.15 httpd2: /usr/local/sbin/httpd2
  348 ??  S   0:00.08 httpd2: /usr/local/sbin/httpd2
15642 ??  S   0:00.20 httpd2: /usr/local/sbin/httpd2
32692 ??  S   0:00.22 httpd2: /usr/local/sbin/httpd2
23359 ??  S   0:00.13 httpd2: /usr/local/sbin/httpd2
19331 ??  S   0:00.10 httpd2: /usr/local/sbin/httpd2
 1547 ??  S   0:00.29 httpd2: /usr/local/sbin/httpd2
28917 ??  S   0:00.03 httpd2: /usr/local/sbin/httpd2

# /etc/rc.d/apache2 check
apache2(failed)

# ps ax | grep [h]ttpd2
14568 ??  Ss  0:00.46 httpd2: /usr/local/sbin/httpd2
19759 ??  S   0:00.02 httpd2: /usr/local/sbin/httpd2
 8262 ??  S   0:00.08 httpd2: /usr/local/sbin/httpd2
 7983 ??  S   0:00.14 httpd2: /usr/local/sbin/httpd2
24914 ??  S   0:00.13 httpd2: /usr/local/sbin/httpd2
19513 ??  S   0:00.24 httpd2: /usr/local/sbin/httpd2
23839 ??  S   0:00.26 httpd2: /usr/local/sbin/httpd2
 3778 ??  S   0:00.37 httpd2: /usr/local/sbin/httpd2
 8778 ??  S   0:00.23 httpd2: /usr/local/sbin/httpd2
21764 ??  S   0:00.19 httpd2: /usr/local/sbin/httpd2
 8920 ??  S   0:00.15 httpd2: /usr/local/sbin/httpd2
17706 ??  S   0:00.15 httpd2: /usr/local/sbin/httpd2
  348 ??  S   0:00.08 httpd2: /usr/local/sbin/httpd2
15642 ??  S   0:00.21 httpd2: /usr/local/sbin/httpd2
32692 ??  S   0:00.29 httpd2: /usr/local/sbin/httpd2
23359 ??  S   0:00.13 httpd2: /usr/local/sbin/httpd2
19331 ??  S   0:00.10 httpd2: /usr/local/sbin/httpd2
 1547 ??  S   0:00.29 httpd2: /usr/local/sbin/httpd2
28917 ??  S   0:00.03 httpd2: /usr/local/sbin/httpd2


Now with my patched rc 

Re: apache-httpd rc script not working properly

[Antoine Jacoutot]

On Tue, Jun 21, 2016 at 12:49:49AM +0200, Antoine Jacoutot wrote:
> On Mon, Jun 20, 2016 at 11:16:53PM +0200, Michael Lechtermann wrote:
> > Hi,
> > 
> > the current apache2 rc.d script isn’t working properly as it is. The script 
> > doesn’t detect if the process was started successfully and can neither 
> > stop, reload or even check it. The following patch fixes it for me:
> 
> Thanks, I'll have a look at it.

Sorry but I cannot reproduce your issue with a default configuration.
So you'll have to provide us with more info.


> 
> > --- apache2.rc.orig Mon Jun 20 21:07:37 2016
> > +++ apache2.rc  Mon Jun 20 21:11:56 2016
> > @@ -6,4 +6,10 @@
> > 
> > . /etc/rc.d/rc.subr
> > 
> > +pexp="httpd2:.*${daemon}"
> > +
> > +rc_reload() {
> > +   pkill -HUP -oxf "${pexp}"
> > +}
> > +
> > rc_cmd $1
> > 
> > 
> > 
> > Best regards,
> > Michael
> > 
> 
> -- 
> Antoine

-- 
Antoine

Re: -Wl,--gc-sections broken on powerpc

[Jérémie Courrèges-Anglas]

Landry Breuil  writes:

> On Thu, Mar 17, 2016 at 10:46:04PM +0100, Jeremie Courreges-Anglas wrote:
>> Landry Breuil  writes:
>> 
>> > Hi,
>> >
>> > mpi@ already fixed some ports (audio/mpd at least) by removing
>> > -Wl,--gc-sections from the linking flags, but 'lots' of other ports
>> > using this construct fail on powerpc. Maybe we should make it a noop on
>> > this arch ?
>> 
>> Unless someone comes up with a proper fix, here's a diff to
>> disable --gc-sections. You should get the following warning:
>
> Well, given the insane amount of replies my mail got, i doubt anyone's
> coming with a proper fix... Mark, Martin, since you're the macppc port
> maintainers, any opinion ?
>
> Landry

No test report / no opinion regarding this diff?

>> Index: bfd/elf32-ppc.c
>> ===
>> RCS file: /cvs/src/gnu/usr.bin/binutils-2.17/bfd/elf32-ppc.c,v
>> retrieving revision 1.3
>> diff -u -p -r1.3 elf32-ppc.c
>> --- bfd/elf32-ppc.c  3 Aug 2015 18:03:04 -   1.3
>> +++ bfd/elf32-ppc.c  17 Mar 2016 21:44:41 -
>> @@ -7447,7 +7447,7 @@ ppc_elf_finish_dynamic_sections (bfd *ou
>>  #endif
>>  
>>  #define elf_backend_plt_not_loaded  1
>> -#define elf_backend_can_gc_sections 1
>> +#define elf_backend_can_gc_sections 0
>>  #define elf_backend_can_refcount1
>>  #define elf_backend_rela_normal 1
>>  
>> 
>> 
>> -- 
>> jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE
>> 
>

-- 
jca | PGP: 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE

Re: Relayd TLS client mode CA verification

[Lampshade]

Unfortunately relayd still has this bug.

I have:
sysctl kern.version  
kern.version=OpenBSD 6.0-beta (GENERIC.MP) #2198: Sun Jun 19 11:58:45 MDT 2016
r...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP

As was said: if destination can be predicted at config writing time,
then there is workaround. However I use relayd also for MitM on
my browser to enhance my privacy using privoxy and this makes
me vulnerable for MitM attack by someone outside my computer.

Re: bsd.rd from May 31 fails to load the firmware for iwm-7265-16

[Stefan Sperling]

On Tue, Jun 21, 2016 at 08:13:25AM +0200, Remi Locherer wrote:
> I noticed that this is allready commited. So I did cvs up and built a
> new release (with r 1.89 of if_iwm.c). iwm0 now works fine in bsd.rd.
> Thanks!
> 
> Remi

Great. Thanks for confirming!

Re: bsd.rd from May 31 fails to load the firmware for iwm-7265-16

[Remi Locherer]

On Mon, Jun 20, 2016 at 12:18:30AM +0200, Stefan Sperling wrote:
> On Tue, Jun 07, 2016 at 01:10:34AM +0200, Theo Buehler wrote:
> > On Mon, Jun 06, 2016 at 03:09:34PM +0200, Stefan Sperling wrote:
> > > On Mon, Jun 06, 2016 at 02:15:35PM +0200, Remi Locherer wrote:
> > > > Today I built a bsd.rd with IWM_DEBUG. Now the iwm0 works as expected.
> > > 
> > > This indicates there is a race condition bug which is avoided
> > > by the additional time spent on printing data to the console.
> > > 
> > 
> > I could not get my 
> > 
> > iwm0 at pci2 dev 0 function 0 "Intel Dual Band Wireless AC 7265" rev 0x59, 
> > msi
> > 
> > to find a network, let alone associate with one at all (from bsd.rd).
> > 
> > Contrary to what kettenis@ reports, repeated up/down/up/scan/scan/scan
> > doesn't help.
> > 
> > As Remi reports, things work just fine when IWM_DEBUG is enabled.
> > 
> > I did some bisecting and it turns out that the last version that works
> > on bsd.rd is if_iwm.c -r1.81 (with the old firmware), -r1.82 which
> > made the transition to the new firmware stops working.
> > 
> > No problems whatsoever with GENERIC and GENERIC.MP
> 
> Remi, Mark, can you confirm that this diff fixes the problem for you?

I noticed that this is allready commited. So I did cvs up and built a
new release (with r 1.89 of if_iwm.c). iwm0 now works fine in bsd.rd.
Thanks!

Remi