date:20170129

Fwd: netbooting OpenBSD (6.0) i386 and amd64 clients from one server

2017-01-29 Thread Sven-Volker Nowarra

>> ...
>>
>> $ ./tftpd_rewrite
>> $ doas chgrp _tftpd /tmp/tftpd_rewrite.sock ; doas chmod g+w
/tmp/tftpd_rewrite.sock
>> $ doas tftpd -v -r /tmp/tftpd_rewrite.sock /home/vm
>>
>> $ tftp 127.0.0.1
>> tftp> get /etc/boot.conf
>> Received 38 bytes in 0.0 seconds
>>
>> $ syslogc daemon | tail -n1
>> Jan 29 01:51:49 t440s tftpd[626]: 127.0.0.1: read request for
'/etc/boot.conf'
>> $ cat boot.conf
>> set tty com0
>> boot tftp:/bsd.rd.i386
>
> nice proof of concept :-)
> thx! works well with OpenBSD's tftpd.
> Same logic does not apply to in.tftpd or atftpd. I had copied the OpenBSD
"pxeboot" (amd64 and i386, they differ a bit) to my Linux box. As you can see
in the second line, the requested filename "boot.conf" has no additional IP
address or MAC to filter on:
>
>  in.tftpd[2131]: RRQ from 192.168.88.253 filename /i386/bsd60_i386_pxeboot
>> in.tftpd[2132]: remap: input: /etc/boot.conf
>  in.tftpd[2132]: remap: done
>  in.tftpd[2132]: RRQ from 192.168.88.253 filename /etc/boot.conf
>  in.tftpd[2133]: remap: input: /etc/random.seed
>  in.tftpd[2133]: remap: done
>  in.tftpd[2133]: RRQ from 192.168.88.253 filename /etc/random.seed
>  in.tftpd[2133]: sending NAK (1, File not found) to 192.168.88.253
>  in.tftpd[2134]: remap: input: /bsd
>  in.tftpd[2134]: remap: done
>  in.tftpd[2134]: RRQ from 192.168.88.253 filename /bsd
>  in.tftpd[2134]: sending NAK (1, File not found) to 192.168.88.253
>
> This way, when creating a remapping based on the raw filename, it would
apply to i386 and amd64.
> Anyhow, I will update my doc with the solution for OpenBSD. Already a good
step forwards.
> At the same time I will also update with Anton's remark for a dual server.
>

I am wrong! I have played around with in.tftpd. I could get my OpenBSD systems
to properly netboot i386 and amd64 in the same network segment. Here is all
the configs I used, to achieve OpenBSD clients booting from in.tftpd and it's
"filename remapping":

/etc/hosts:
192.168.88.253 mvbcxfw1.svn.localdomain mvbcxfw1
192.168.88.254 mvbcxfw2.svn.localdomain mvbcxfw2

/etc/tftp.remap:
r /etc/boot.conf /etc/boot.conf.\i

This translates into: for all requests [r] that come with a filename
“/etc/boot.conf” replace it with the filename “/etc/boot.conf” and
attach a dot and the IP address of the tftpd requesting client [\i]. (man
in.tftpd)

/etc/dhcpd.conf
...
group {
  filename "/pxeboot";
  next-server 192.168.88.8;
  host mvbcxfw1 {
option host-name "mvbcxfw1";
hardware ethernet 00:47:11:12:01:27;
fixed-address mvbcxfw1;
  }
  host mvbcxfw2 {
option host-name "mvbcxfw2";
hardware ethernet 00:47:11:12:01:28;
fixed-address mvbcxfw2;
  }
}

I created two files in the /srv/tftpboot/etc/ directory:

/srv/tftpboot/etc/boot.conf.192.168.88.253:
echo #
echo # in.tftpd greetings to client 192.168.88.253
echo #
boot /i386/bsd60_i386_bsd.rd

/srv/tftpboot/etc/boot.conf.192.168.88.254:
echo #
echo # in.tftpd greetings to client 192.168.88.254
echo #
boot /amd64/bsd60_amd64_bsd.rd

I then start the xinetd, with the in.tftpd activated. The config file
/etc/xinetd.d/tftp:
service tftp
{
socket_type = dgram
protocol = udp
wait = yes
user = root
group = tftp
server = /usr/sbin/in.tftpd
server_args = -m /etc/tftpd.remap -vvv -s /srv/tftpboot
}

Alternativly, one can also do a manual start:
/usr/sbin/in.tftpd -l -m /etc/tftpd.remap -vvv -s /srv/tftpboot

I boot my first i386 client, and see this in journalctl -f
/usr/sbin/in.tftpd:
  Jan 30 02:04:33 mleap42ix in.tftpd[4125]: remap: input: /pxeboot
  Jan 30 02:04:33 mleap42ix in.tftpd[4125]: remap: done
  Jan 30 02:04:33 mleap42ix in.tftpd[4125]: RRQ from 192.168.88.253 filename
/pxeboot
  Jan 30 02:04:33 mleap42ix in.tftpd[4126]: remap: input: /etc/boot.conf
  Jan 30 02:04:33 mleap42ix in.tftpd[4126]: remap: rule 0: rewrite:
/etc/boot.conf.192.168.88.253
  Jan 30 02:04:33 mleap42ix in.tftpd[4126]: remap: done
  Jan 30 02:04:33 mleap42ix in.tftpd[4126]: RRQ from 192.168.88.253 filename
/etc/boot.conf remapped to /etc/boot.conf.192.168.88.253
...
  Jan 30 02:04:33 mleap42ix in.tftpd[4128]: remap: input:
/i386/bsd60_i386_bsd.rd
  Jan 30 02:04:33 mleap42ix in.tftpd[4128]: remap: done
  Jan 30 02:04:33 mleap42ix in.tftpd[4128]: RRQ from 192.168.88.253 filename
/i386/bsd60_i386_bsd.rd

Line number 5 and line number 7 show the change. So with this one can define a
per IP address config file, and define in the boot.conf . whichever kernel
we want to boot. The equivalent result for the amd64 client would show the
remapping, and boot the amd64 kernel.

rgds,
Volker

Re: Copy files to usb (slow)

2017-01-29 Thread G

Thanks.
I used a 3.0 usb stick(msdos) and i get 6.6mb/sec.
I guess its ok.
thanks for your answer.


On 01/29/17 23:31, edward wandasiewicz wrote:
> From your dmesg, your machine has USB 3.0 hardware ports
> 
> usb0 at xhci0: USB revision 3.0
> 
> and you're using a USB 2.0 flash drive - rev 2.00/1.10
> 
> umass0 at uhub0 port 2 configuration 1 interface 0 "Kingston
> DataTraveler 2.0" rev 2.00/1.10 addr 6
> 
> You could upgrade to a USB 3.0 flash drive.
> 
> On USB 3.0 hardware port with a USB 3.0 flash drive ( not an SSD ), with a
> 
> MSDOS file system, I get about 2.5 MB/s
> 
> 4.2BSD file system, I get about 7 MB/s
> 
> with rsync --info=progress2 ./SOURCE/ /DEST transferring a single 1GB file.
> 
> Attempting to dd an image, I get about 20 MB/s
> 
> # dd if=img bs=1m | pv -s 16GB | dd of=/dev/rsd1c bs=1m
> 
> On Sun, Jan 29, 2017 at 6:57 PM, Ali Farzanrad  wrote:
>> G  wrotes:
>>> Hello.
>>> Im trying to copy files from my laptop to a usb stick.
>>> The speed varies between 300kB/sec and 400kB/sec. Its really slow.
>>
>> I also have the same problem.
>> It seems that block files are slow and it is not possible to mount raw
>> files.
>> I tested it with dd(1) and found that fastest way to transfer data is
>> using raw devices:
>>
>> # dd if=/dev/rsd1c of=temp.fs bs=1m
>> # vnconfig vnd0 temp.fs
>> # mount /dev/vnd0i /mnt/usb
>> # ... do copy ...
>> # umount /mnt/usb
>> # vnconfig -u vnd0
>> # dd if=temp.fs of=/dev/rsd1c bs=1m

Re: Copy files to usb (slow)

2017-01-29 Thread edward wandasiewicz

>From your dmesg, your machine has USB 3.0 hardware ports

usb0 at xhci0: USB revision 3.0

and you're using a USB 2.0 flash drive - rev 2.00/1.10

umass0 at uhub0 port 2 configuration 1 interface 0 "Kingston
DataTraveler 2.0" rev 2.00/1.10 addr 6

You could upgrade to a USB 3.0 flash drive.

On USB 3.0 hardware port with a USB 3.0 flash drive ( not an SSD ), with a

MSDOS file system, I get about 2.5 MB/s

4.2BSD file system, I get about 7 MB/s

with rsync --info=progress2 ./SOURCE/ /DEST transferring a single 1GB file.

Attempting to dd an image, I get about 20 MB/s

# dd if=img bs=1m | pv -s 16GB | dd of=/dev/rsd1c bs=1m

On Sun, Jan 29, 2017 at 6:57 PM, Ali Farzanrad  wrote:
> G  wrotes:
>>Hello.
>>Im trying to copy files from my laptop to a usb stick.
>>The speed varies between 300kB/sec and 400kB/sec. Its really slow.
>
> I also have the same problem.
> It seems that block files are slow and it is not possible to mount raw
> files.
> I tested it with dd(1) and found that fastest way to transfer data is
> using raw devices:
>
> # dd if=/dev/rsd1c of=temp.fs bs=1m
> # vnconfig vnd0 temp.fs
> # mount /dev/vnd0i /mnt/usb
> # ... do copy ...
> # umount /mnt/usb
> # vnconfig -u vnd0
> # dd if=temp.fs of=/dev/rsd1c bs=1m

Re: netbooting OpenBSD (6.0) i386 and amd64 clients from one server

2017-01-29 Thread Sven-Volker Nowarra

> Am 29.01.2017 um 14:23 schrieb Jiri B :
>
>>> Isn't better to use rewrite/file remapping instead of hacking pxeboot?
>>> If an i386 machine would request /etc/boot.conf via tftp you could
rewrite
>>> it to (based on fact you know that that machine is i386 - during
provisioning)
>>> /etc/i386/boot.conf. For the client I suppose it would still think it
gets
>>> /etc/boot.conf.
>
> A POC...
>
> j.
>
> ~~~
> #!/usr/bin/perl -w
>
> use IO::Socket::UNIX;
>
> my $socket_path = '/tmp/tftpd_rewrite.sock';
> unlink $socket_path if -e $socket_path;
> my $socket = IO::Socket::UNIX->new(
>Local  => $socket_path,
>Type   => SOCK_STREAM,
>Listen => SOMAXCONN,
> );
> die "Can't create socket: $!" unless $socket;
>
> while (1) {
>next unless my $connection = $socket->accept;
>$connection->autoflush(1);
>while (my $line = <$connection>) {
>chomp($line);
># XXX
># conditionals here
>if ($line =~ /^127.0.0.1 read \/etc\/boot.conf$/) {
>print $connection "/etc/boot.conf.i386\n";
>} elsif ($line =~ /^\S+ read \/etc\/boot.conf$/) {
>print $connection "/etc/boot.conf\n";
>}
>}
> }
> ~~~
>
> $ ./tftpd_rewrite
> $ doas chgrp _tftpd /tmp/tftpd_rewrite.sock ; doas chmod g+w
/tmp/tftpd_rewrite.sock
> $ doas tftpd -v -r /tmp/tftpd_rewrite.sock /home/vm
>
> $ tftp 127.0.0.1
> tftp> get /etc/boot.conf
> Received 38 bytes in 0.0 seconds
>
> $ syslogc daemon | tail -n1
> Jan 29 01:51:49 t440s tftpd[626]: 127.0.0.1: read request for
'/etc/boot.conf'
> $ cat boot.conf
> set tty com0
> boot tftp:/bsd.rd.i386

nice proof of concept :-)
thx! works well with OpenBSD's tftpd.
Same logic does not apply to in.tftpd or atftpd. I had copied the OpenBSD
"pxeboot" (amd64 and i386, they differ a bit) to my Linux box. As you can see
in the second line, the requested filename "boot.conf" has no additional IP
address or MAC to filter on:

  in.tftpd[2131]: RRQ from 192.168.88.253 filename /i386/bsd60_i386_pxeboot
> in.tftpd[2132]: remap: input: /etc/boot.conf
  in.tftpd[2132]: remap: done
  in.tftpd[2132]: RRQ from 192.168.88.253 filename /etc/boot.conf
  in.tftpd[2133]: remap: input: /etc/random.seed
  in.tftpd[2133]: remap: done
  in.tftpd[2133]: RRQ from 192.168.88.253 filename /etc/random.seed
  in.tftpd[2133]: sending NAK (1, File not found) to 192.168.88.253
  in.tftpd[2134]: remap: input: /bsd
  in.tftpd[2134]: remap: done
  in.tftpd[2134]: RRQ from 192.168.88.253 filename /bsd
  in.tftpd[2134]: sending NAK (1, File not found) to 192.168.88.253

This way, when creating a remapping based on the raw filename, it would apply
to i386 and amd64.
Anyhow, I will update my doc with the solution for OpenBSD. Already a good
step forwards.
At the same time I will also update with Anton's remark for a dual server.

thx, rgds,
Volker

Re: Copy files to usb (slow)

2017-01-29 Thread Ali Farzanrad

G  wrotes:
>Hello.
>Im trying to copy files from my laptop to a usb stick.
>The speed varies between 300kB/sec and 400kB/sec. Its really slow.

I also have the same problem.
It seems that block files are slow and it is not possible to mount raw
files.
I tested it with dd(1) and found that fastest way to transfer data is
using raw devices:

# dd if=/dev/rsd1c of=temp.fs bs=1m
# vnconfig vnd0 temp.fs
# mount /dev/vnd0i /mnt/usb
# ... do copy ...
# umount /mnt/usb
# vnconfig -u vnd0
# dd if=temp.fs of=/dev/rsd1c bs=1m

Copy files to usb (slow)

2017-01-29 Thread G

Hello.
Im trying to copy files from my laptop to a usb stick.
The speed varies between 300kB/sec and 400kB/sec. Its really slow.
my fstab is

ef1bca26af91f0cd.b none swap sw
ef1bca26af91f0cd.a / ffs rw,softdep 1 1
ef1bca26af91f0cd.k /home ffs rw,softdep,nodev,nosuid 1 2
ef1bca26af91f0cd.d /tmp ffs rw,softdep,nodev,nosuid 1 2
ef1bca26af91f0cd.f /usr ffs rw,softdep,nodev 1 2
ef1bca26af91f0cd.g /usr/X11R6 ffs rw,softdep,nodev 1 2
ef1bca26af91f0cd.h /usr/local ffs rw,softdep,wxallowed,nodev 1 2
ef1bca26af91f0cd.j /usr/obj ffs rw,softdep,nodev,nosuid 1 2
ef1bca26af91f0cd.i /usr/src ffs rw,softdep,nodev,nosuid 1 2
ef1bca26af91f0cd.e /var ffs rw,softdep,nodev,nosuid 1 2
/dev/sd2i /mnt/usb msdos rw,noauto 0 0
/dev/cd0a /mnt/cdrom  cd9660 ro,noauto 0 0

dmesg is


$ dmesg
OpenBSD 6.0-stable (GENERIC.MP) #1: Sun Jan 29 16:16:31 EET 2017
g...@openlaptop.my.domain:/usr/src/sys/arch/amd64/compile/GENERIC.MP
RTC BIOS diagnostic error 80
real mem = 8474267648 (8081MB)
avail mem = 8212963328 (7832MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xe6dc0 (71 entries)
bios0: vendor LENOVO version "0XCN23WW" date 03/21/2016
bios0: LENOVO 80SR
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP TCPA UEFI UEFI SSDT SSDT TPM2 MSDM SSDT DBGP
DBG2 ASF! ASPT BOOT DBGP HPET LPIT APIC MCFG SSDT SSDT SSDT SSDT DMAR FPDT
acpi0: wakeup devices GLAN(S3) XHC_(S3) XDCI(S4) HDAS(S3) PXSX(S3)
RP01(S3) PXSX(S3) RP02(S3) PXSX(S3) RP03(S3) PXSX(S3) RP04(S3) PXSX(S3)
RP05(S3) PXSX(S3) RP06(S3) [...]
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpihpet0 at acpi0: 2399 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i7-6500U CPU @ 2.50GHz, 2395.19 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,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,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 24MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Core(TM) i7-6500U CPU @ 2.50GHz, 2394.44 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,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SENSOR,ARAT
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 1 (application processor)
cpu2: Intel(R) Core(TM) i7-6500U CPU @ 2.50GHz, 2394.44 MHz
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,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SENSOR,ARAT
cpu2: 256KB 64b/line 8-way L2 cache
cpu2: smt 1, core 0, package 0
cpu3 at mainbus0: apid 3 (application processor)
cpu3: Intel(R) Core(TM) i7-6500U CPU @ 2.50GHz, 2394.44 MHz
cpu3:
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,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SENSOR,ARAT
cpu3: 256KB 64b/line 8-way L2 cache
cpu3: smt 1, core 1, package 0
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 120 pins
acpimcfg0 at acpi0 addr 0xe000, bus 0-255
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (RP01)
acpiprt2 at acpi0: bus -1 (RP02)
acpiprt3 at acpi0: bus -1 (RP03)
acpiprt4 at acpi0: bus -1 (RP04)
acpiprt5 at acpi0: bus 1 (RP05)
acpiprt6 at acpi0: bus 2 (RP06)
acpiprt7 at acpi0: bus -1 (RP07)
acpiprt8 at acpi0: bus -1 (RP08)
acpiprt9 at acpi0: bus -1 (RP09)
acpiprt10 at acpi0: bus -1 (RP10)
acpiprt11 at acpi0: bus -1 (RP11)
acpiprt12 at acpi0: bus -1 (RP12)
acpiprt13 at acpi0: bus -1 (RP13)
acpiprt14 at acpi0: bus -1 (RP14)
acpiprt15 at acpi0: bus -1 (RP15)
acpiprt16 at acpi0: bus -1 (RP16)
acpiprt17 at acpi0: bus -1 (RP17)
acpiprt18 at acpi0: bus -1 (RP18)
acpiprt19 at acpi0: bus -1 (RP19)
acpiprt20 at acpi0: bus -1 (RP20)
acpiec0 at acpi0

FTP proxy not listing certain directories?

2017-01-29 Thread Kaya Saman


Hi,


as I have now managed to get back into my OBSD system I have tested ftp 
again from clients yet still even with the recent upgrade I seem to be 
unable to list certain directories??



I have checked the option flags for ftpproxy (man ftpproxy) however, 
couldn't find anything of help.



An example is the Shrubbery ftp site:


this directory lists fine: ftp://ftp.shrubbery.net/pub/astraceroute/


while this one doesn't list at all?? ftp://ftp.shrubbery.net/pub/rancid/


tcpdump -eni doesn't show anythng specific:


16:01:40.755991 10:0b:a9:5c:a4:2c 00:25:90:d0:ba:00 0800 66: <***>.54958 
> 129.250.47.99.21: . ack 2344340832 win 229  (DF)
16:01:40.756004 00:25:90:d0:ba:00 10:0b:a9:5c:a4:2c 0800 66: 
129.250.47.99.21 > <***>.54958: . ack 1 win 271 
16:01:42.938689 10:0b:a9:5c:a4:2c 00:25:90:d0:ba:00 0800 74: <***>.54962 
> 129.250.47.99.21: S 3566867037:3566867037(0) win 29200 1460,sackOK,timestamp 1071558 0,nop,wscale 7> (DF)
16:01:42.938725 00:25:90:d0:ba:00 10:0b:a9:5c:a4:2c 0800 78: 
129.250.47.99.21 > <***>.54962: S 3753545844:3753545844(0) ack 
3566867038 win 16384 6,nop,nop,timestamp 2390749407 1071558>




16:02:04.356644 00:25:90:d0:ba:00 10:0b:a9:5c:a4:2c 0800 120: 
129.250.47.99.21 > <***>.54974: P 401:455(54) ack 112 win 271 

16:02:04.357548 10:0b:a9:5c:a4:2c 00:25:90:d0:ba:00 0800 66: <***>.54974 
> 129.250.47.99.21: . ack 455 win 229  (DF)



--> then the report waits


I'm just wondering as the last statement is (DF) - the Do Not Fragment 
flag, could this be an MTU issue??



Though the odd thing is that this was working fine until two upgrades 
ago which are still quite recent 2017 dated.



In PF I have the standard rule:


# Proxy rules

anchor "ftp-proxy/*"

pass in quick on $int_if inet proto tcp to any port ftp \
divert-to 127.0.0.1 port 8021


And as I'm on a VDSL2 line I have:


net.inet.tcp.mssdflt=1452


in sysctl.conf


and the MTU set on the PPPoE interface as: mtu 1492


All other web based traffic operates fine apart from certain ftp 
transactions??



Would anyone be able to suggest anything?


Many Thanks.


Kaya

Re: netbooting OpenBSD (6.0) i386 and amd64 clients from one server

2017-01-29 Thread Jiri B

> > Isn't better to use rewrite/file remapping instead of hacking pxeboot?
> > If an i386 machine would request /etc/boot.conf via tftp you could rewrite
> > it to (based on fact you know that that machine is i386 - during 
> > provisioning)
> > /etc/i386/boot.conf. For the client I suppose it would still think it gets
> > /etc/boot.conf.

A POC...

j.

~~~
#!/usr/bin/perl -w

use IO::Socket::UNIX;

my $socket_path = '/tmp/tftpd_rewrite.sock';
unlink $socket_path if -e $socket_path;
my $socket = IO::Socket::UNIX->new(
Local  => $socket_path,
Type   => SOCK_STREAM,
Listen => SOMAXCONN,
);
die "Can't create socket: $!" unless $socket;

while (1) {
next unless my $connection = $socket->accept;
$connection->autoflush(1);
while (my $line = <$connection>) {
chomp($line);
# XXX
# conditionals here
if ($line =~ /^127.0.0.1 read \/etc\/boot.conf$/) {
print $connection "/etc/boot.conf.i386\n";
} elsif ($line =~ /^\S+ read \/etc\/boot.conf$/) {
print $connection "/etc/boot.conf\n";
}
}
}
~~~

$ ./tftpd_rewrite
$ doas chgrp _tftpd /tmp/tftpd_rewrite.sock ; doas chmod g+w 
/tmp/tftpd_rewrite.sock
$ doas tftpd -v -r /tmp/tftpd_rewrite.sock /home/vm

$ tftp 127.0.0.1 
tftp> get /etc/boot.conf
Received 38 bytes in 0.0 seconds

$ syslogc daemon | tail -n1
Jan 29 01:51:49 t440s tftpd[626]: 127.0.0.1: read request for '/etc/boot.conf'
$ cat boot.conf
set tty com0
boot tftp:/bsd.rd.i386

Re: installXX.fs build

2017-01-29 Thread Thuban

* Jiri B  le [27-01-2017 17:01:17 -0500]:
> On Fri, Jan 27, 2017 at 08:29:08PM +0100, Thuban wrote:
> > Hi,
> >
> > Just by curiosity, I was wondering how installXX.fs file is build?
>
> https://github.com/openbsd/src/blob/master/distrib/amd64/iso/Makefile#L9
>
> j.

Thanks.

[demime 1.01d removed an attachment of type application/pgp-signature which had 
a name of signature.asc]

Fwd: netbooting OpenBSD (6.0) i386 and amd64 clients from one server

Re: Copy files to usb (slow)

Re: Copy files to usb (slow)

Re: netbooting OpenBSD (6.0) i386 and amd64 clients from one server

Re: Copy files to usb (slow)

Copy files to usb (slow)

FTP proxy not listing certain directories?

Re: netbooting OpenBSD (6.0) i386 and amd64 clients from one server

Re: installXX.fs build

9 matches

Site Navigation

Mail list logo

Footer information