Re: hostapd

[Michael van Elst]

On Thu, Apr 04, 2024 at 11:28:41AM +0100, Patrick Welche wrote:
> 10:15:22.135344 IP (tos 0x0, ttl 64, id 12912, offset 0, flags [DF], proto 
> TCP (6), length 60)
> 192.168.100.3.60610 > 192.168.100.62.80: Flags [S], cksum 0x783f 
> (correct), seq 50981267, win 65535, options [mss 1460,sackOK,TS val 2022496 
> ecr 0,nop,wscale 6], length 0

> I assume
> 
> hostapd: urtwn0: interface state UNINITIALIZED->ENABLED
> hostapd: urtwn0: AP-ENABLED 
> 
> rules out a monitor mode? or ? The dhcpd response was fine...

dhcpd uses BPF to receive and transmit DHCP packets. So the symptoms would 
point to an issue in the ARP or IP layer.

-- 
Michael van Elst
Internet: mlel...@serpens.de
"A potential Snark may lurk in every tree."

Re: hostapd

[Patrick Welche]

On Wed, Apr 03, 2024 at 08:53:47AM -, Michael van Elst wrote:
> pr...@welche.eu (Patrick Welche) writes:
> 
> >The system httpd via inetd doesn't receive a web page request from the
> >device.
> >tcpdump shows the device requesting it, but no response.
> 
> If httpd wouldn't run, the request would be answered with
> a TCP RST.
> 
> If httpd does run, the request (SYN) is answered with a 
> TCP SYN/ACK.
> 
> Can you say what exactly is "no response" here?

I really mean nothing at all!

# tcpdump -nvi urtwn0 port 80
tcpdump: listening on urtwn0, link-type EN10MB (Ethernet), snapshot length 
262144 bytes
10:15:20.886823 IP (tos 0x0, ttl 64, id 41996, offset 0, flags [DF], proto TCP 
(6), length 60)
192.168.100.3.60609 > 192.168.100.62.80: Flags [S], cksum 0x8457 (correct), 
seq 1628667887, win 65535, options [mss 1460,sackOK,TS val 2022371 ecr 
0,nop,wscale 6], length 0
10:15:21.144835 IP (tos 0x0, ttl 64, id 12911, offset 0, flags [DF], proto TCP 
(6), length 60)
192.168.100.3.60610 > 192.168.100.62.80: Flags [S], cksum 0x78a3 (correct), 
seq 50981267, win 65535, options [mss 1460,sackOK,TS val 2022396 ecr 
0,nop,wscale 6], length 0
10:15:21.887188 IP (tos 0x0, ttl 64, id 41997, offset 0, flags [DF], proto TCP 
(6), length 60)
192.168.100.3.60609 > 192.168.100.62.80: Flags [S], cksum 0x83f3 (correct), 
seq 1628667887, win 65535, options [mss 1460,sackOK,TS val 2022471 ecr 
0,nop,wscale 6], length 0
10:15:22.135344 IP (tos 0x0, ttl 64, id 12912, offset 0, flags [DF], proto TCP 
(6), length 60)
192.168.100.3.60610 > 192.168.100.62.80: Flags [S], cksum 0x783f (correct), 
seq 50981267, win 65535, options [mss 1460,sackOK,TS val 2022496 ecr 
0,nop,wscale 6], length 0
...

> >on the server, telnet localhost 80, GET /, works
> 
> Did you configure (in /etc/inetd.conf) http for tcp or tcp6 ?
> A 'telnet localhost 80' would see either, but a pure IPv4 client
> only sees the 'tcp' one.

For tcp:

httpstream  tcp nowait:600  _httpd  /usr/libexec/httpd  
httpd -dnX /var/www


I tried nginx with the same result.

I assume

hostapd: urtwn0: interface state UNINITIALIZED->ENABLED
hostapd: urtwn0: AP-ENABLED 

rules out a monitor mode? or ? The dhcpd response was fine...


Cheers,

Patrick

GENERIC_KASLR Boot Page Fault in 10.0

[Isaac Peka]

Hi there,

There seems to be an issue with running the GENERIC_KASLR kernel in QEMU in the 
10.0 release. The following configuration works for the 9.3 release. Are there 
any additional hardware requirements or steps I need to take to get the 
GENERIC_KASLR kernel to boot in 10.0?

```
#!/bin/sh

qemu-img create disk.img 10G

qemu-system-x86_64 -drive file=disk.img,format=raw \
 -cdrom ~/Downloads/NetBSD-10.0-amd64.iso \
 -m 2048 -enable-kvm -smp 2 \
 -net user,hostfwd=tcp::5023-:22 -net nic

``` 

Whether I choose to install the GENERIC_KASLR kernel via the installation menu, 
or follow the steps at https://wiki.netbsd.org/security/kaslr/, the result is 
the same. The installation succeeds, but when booting the kernel it crashes 
during the "jumping to kernel" stage with a page fault. The GENERIC kernel 
works fine.

Many thanks,
Isaac