Re: Making tftp download large files from tftpd
your diff got stripped when sending to this list. i did a fix which has now been committed to the tree as src/usr.bin/tftp/tftp.c r1.24. thanks for the report :) dlg On 21 Oct 2014, at 10:28, Justin Mayes jma...@careered.com wrote: I could. My original problem was with cisco rommon tftpdnld command as client failing talking to tftpd. I just notice the tftp client problem while testing locally. After this I intend to go back and make tftpd work with whatever cisco client is doing. Since that’s a two byte field in the rfc there is no way I know of that tftpd or any other server can get more than 65536 in there so all they can do is rollover. The only thing I can think is maybe cisco client starts at 1 rather than 0. A tcpdump will tell me in a little while. This is more of a learning experience for me. I want to go through motions of getting source, debugging some issue with gdb, updating the code, build and all that. I've done that many times in windows world but not in any unix like Oses. So far the exercise is a success in that I learned a ton and if that diff was worth anything to anyone, even better. Thanks for the tip tho James, its good advice. J -Original Message- From: James A. Peltier [mailto:jpelt...@sfu.ca] Sent: Monday, October 20, 2014 5:34 PM To: Justin Mayes Cc: misc@openbsd.org Subject: Re: Making tftp download large files from tftpd - Original Message - | I will spare you all the backstory but I found that tftp could not | download files over 32 mb by default from tftpd. I know you can pass | blocksize to tftpd to handle much larger files but I was originally | working with a client where this wasn't possible. Tftp protocol has 2 | bytes for block number which put a | 65535 limit on that. tftpd data doesn't care and will just roll that | over back to 0 and keep sending data. Tftp client fails when there is | block number roll over because it is tracking all the blocks with an | int so ends up comparing its block counter which is now at 65536 to | what comes off the network, 0 and quits. I updated the tftp client | code to use same data type as the network side structs are using - | u_int16_t. Now tftp counter rolls along with server and can send file | of any size with or without a blocksize change. I feel like this is | mostly pointless but doesn't hurt anything. Will gladly provide the | actuall diffs. I have to look into that process for openbsd but just | wanted to check with the group first in case there was a reason an int | was used that I do not understand. | | J Or you could chainload iPXE to allow for the downloading of your file over HTTP which is much faster than TFTP to begin with. This is indeed what we do. -- James A. Peltier IT Services - Research Computing Group Simon Fraser University - Burnaby Campus Phone : 778-782-6573 Fax : 778-782-3045 E-Mail : jpelt...@sfu.ca Website : http://www.sfu.ca/itservices Twitter : @sfu_rcg Powering Engagement Through Technology
Re: Staus of stacked softraid root (RAID1C for root)?
I asked a similar question on the list a few days ago and seems I'll be using a hardware RAID controller with softraid CRYPTO on top after all. It may be an option for you too I guess. Best, Vladislav On Tue, Oct 21, 2014 at 3:39 AM, John Merriam j...@johnmerriam.net wrote: On 10/20/2014 4:42 PM, Ted Unangst wrote: Short answer: It doesn't work yet, and no idea when it will work. Thanks for the replies. I will keep my eye out as to what is brewing. If I find the time maybe I'll read the code and see what needs doing with respect to RAID1C for root. For now I'll forgo the RAID1 and just use the crypto. I _really_ like the fact that OpenBSD encrypts as much as possible with softraid and doesn't leave a /boot hanging out there like other systems do with an encrypted root partition. It's been a while since I've used OpenBSD. Like what I'm seeing, keep up the great work! As you can see in my sig, I'm migrating away from one of those other operating systems... -- John Merriam - refugee from the land of systemd
Re: tcpdump: WARNING: compensating for unaligned libpcap packets
On 2014-10-20, Stefan Wollny stefan.wol...@web.de wrote: Hi there! I use a Lenovo T60 with amd64-5.6-current / #452 from Oct. 20th. Looking at what 'tcpdump -nettti pflog0 inbound and action block' reports I noticed the following: ~ ~ $ sudo tcpdump -nettti pflog0 inbound and action block tcpdump: WARNING: snaplen raised from 116 to 160 tcpdump: listening on pflog0, link-type PFLOG Oct 20 16:48:38.881272 rule 3/(match) block in on trunk0: \ 192.168.178.11.24196 239.255.0.1.9303: udp 169 tcpdump: WARNING: compensating for unaligned libpcap packets ~ Google came up with an old thread from 2010 that was of no help to me. Is this WARNING expected behaviour or s.th. to be taken care of? Kind-of expected. The comment in tcpdump's source code does actually say This will never happen with BPF, but it can happen with encapsulated packets.
Re: multicast packets on tun interface
On 2014-10-20, Nicolas Haller nico...@boiteameuh.org wrote: So, where are the OpenBSD HELLO packets? I don't know. A tcpdump on the FreeBSD's tun interface shows nothing is received. A tcpdump on the OpenBSD tun interface shows the packet seems to be sent. Using ktrace/kdump on the OpenVPN daemon on the OpenBSD server, it seems the daemon does nothing to send the HELLO packet, like it's not aware it has to send these packets. Don't rule out bugs in the OpenVPN port on OpenBSD. Despite user requests for version updates and tweaks to the port there has been an almost complete lack of feedback when updates have been sent out for testing, so it's possible problems may have crept in, especially in less frequently used areas. I'm not sure how to remove OpenVPN from the equation whilst still using tun to test things (ssh has tun-forwarding, but it doesn't set the multicast flag on the interface, and might not handle multicast at all even if you did force the flag e.g. by running OpenVPN on the interface first to set IFF_MULTICAST). I'd probably start by bumping up verbosity in OpenVPN config and try and track things down from that side.. I did the test with pf disabled on both server. I tried to remove the 224/4 and ::224.0.0.0/100 routes from the OpenBSD routing table. btw, the standard method for this is multicast_host=YES in rc.conf.local.
Re: Realtek RTL8192SE wireless card support in OpenBSD 5.5
On Mon, Oct 20, 2014 at 11:15:21PM -0300, Javier Bassi wrote: If someone has one of those USB chipsets that works well email me the model. run(4) devices are working very well for me. Much better range than urtwn(4) and more stable link. The man page has a list of models some of which you should be able to find at retailers. They exist both in tiny form factor and as larger USB keys. The relatively more expensive ones have are dual-band (2.4 and 5ghz). I broke some older run(4) models in 5.6 release but a kernel from 5.6-stable CVS source should fix that.
Re: Publishing SSH public key fingerprints bit length?
On 2014-10-20 Mon 21:37 PM |, Christian Weisgerber wrote: On 2014-10-20, Craig R. Skinner skin...@britvault.co.uk wrote: I noticed OpenBSD anon CVS SSH fingerprints have the bit length published with the algorithm type: http://www.openbsd.org/anoncvs.html That seems useless. Is it important to have the bit length published with the fingerprint? No. I dinnae ken if this diff helps a bit. Running 'make anoncvs' builds the page without the bit lengths (below). Index: mirrors.dat === RCS file: /cvs/www/build/mirrors.dat,v retrieving revision 1.413 diff -u -p -r1.413 mirrors.dat --- mirrors.dat 15 Oct 2014 01:42:10 - 1.413 +++ mirrors.dat 21 Oct 2014 09:34:10 - @@ -30,9 +30,9 @@ #AHanoncvs.openbsd.org.ar #AR/cvs #APssh -#SD1024 d5:b3:21:45:71:27:9b:60:0a:34:21:75:9e:fb:c6:08 -#SE256 2d:3c:fb:18:f7:a6:a5:63:f3:af:db:b1:78:76:cd:21 -#SR2048 70:87:64:84:65:9e:45:4e:25:fa:c4:52:71:af:78:28 +#SDd5:b3:21:45:71:27:9b:60:0a:34:21:75:9e:fb:c6:08 +#SE2d:3c:fb:18:f7:a6:a5:63:f3:af:db:b1:78:76:cd:21 +#SR70:87:64:84:65:9e:45:4e:25:fa:c4:52:71:af:78:28 ## Start of Australia @@ -73,9 +73,9 @@ AUanoncvs AH anoncvs.au.openbsd.org AR /cvs AP ssh -SR 2048 19:4c:e2:a8:9e:42:b2:91:f3:d5:04:cf:b5:61:5e:ea -SD 1024 80:ff:d2:46:70:51:7d:09:a5:71:83:bb:89:98:44:b1 -SE 256 fa:57:1c:55:7c:aa:d0:bc:4c:e2:05:3d:9b:bb:83:2d +SR 19:4c:e2:a8:9e:42:b2:91:f3:d5:04:cf:b5:61:5e:ea +SD 80:ff:d2:46:70:51:7d:09:a5:71:83:bb:89:98:44:b1 +SE fa:57:1c:55:7c:aa:d0:bc:4c:e2:05:3d:9b:bb:83:2d ## Start of Austria @@ -96,10 +96,10 @@ AH ftp5.eu.openbsd.org AR /cvs AP ssh VH ftp5.eu.openbsd.org -SR 2048 e4:a7:3a:ab:e1:a7:c8:eb:5c:f4:ff:38:95:6f:81:f2 -SD 2048 66:03:a3:bc:46:85:f3:6c:4b:6b:e3:d4:f5:5f:a6:c4 -SE 256 47:07:69:c4:6c:1f:09:ed:f5:2c:02:af:a0:e9:67:85 -S2 256 32:0b:33:5f:81:77:5c:3b:0c:f6:85:fe:f0:7c:10:ea +SR e4:a7:3a:ab:e1:a7:c8:eb:5c:f4:ff:38:95:6f:81:f2 +SD 66:03:a3:bc:46:85:f3:6c:4b:6b:e3:d4:f5:5f:a6:c4 +SE 47:07:69:c4:6c:1f:09:ed:f5:2c:02:af:a0:e9:67:85 +S2 32:0b:33:5f:81:77:5c:3b:0c:f6:85:fe:f0:7c:10:ea 0 GC Austria @@ -167,10 +167,10 @@ AHanoncvs.comstyle.com AR /cvs AP ssh, ssh port 2022 VH anoncvs.comstyle.com -SD 1024 66:a1:f9:47:26:d9:15:3c:62:2b:b5:e8:0d:89:4a:6f -SE 256 62:28:13:ea:cd:ba:68:e6:e9:82:94:ac:10:7f:80:d5 -SR 2048 43:30:9a:c6:c4:19:80:ad:7d:58:3e:7a:a0:39:57:53 -S2 256 65:34:d5:69:47:38:58:01:47:5d:bd:09:9d:69:be:6b +SD 66:a1:f9:47:26:d9:15:3c:62:2b:b5:e8:0d:89:4a:6f +SE 62:28:13:ea:cd:ba:68:e6:e9:82:94:ac:10:7f:80:d5 +SR 43:30:9a:c6:c4:19:80:ad:7d:58:3e:7a:a0:39:57:53 +S2 65:34:d5:69:47:38:58:01:47:5d:bd:09:9d:69:be:6b 0 GC Canada @@ -295,10 +295,10 @@ AUanoncvs AH anoncvs.estpak.ee AR /OpenBSD AP ssh -SD 1024 bb:5c:44:f4:d9:12:3b:22:08:a9:12:c5:0c:e7:db:49 -SR 1024 e1:12:fb:6b:e5:c0:6a:b3:f8:ca:b1:4c:20:fb:5e:07 -SE 256 d7:46:c9:1e:43:e8:23:7b:4c:cb:5c:75:21:77:f9:bd -S2 256 a7:f6:ff:1a:31:cb:11:0c:84:d5:6b:28:b7:05:c6:7c +SD bb:5c:44:f4:d9:12:3b:22:08:a9:12:c5:0c:e7:db:49 +SR e1:12:fb:6b:e5:c0:6a:b3:f8:ca:b1:4c:20:fb:5e:07 +SE d7:46:c9:1e:43:e8:23:7b:4c:cb:5c:75:21:77:f9:bd +S2 a7:f6:ff:1a:31:cb:11:0c:84:d5:6b:28:b7:05:c6:7c VH anoncvs.estpak.ee ## Start of France: @@ -322,10 +322,10 @@ AHanoncvs.fr.openbsd.org AU anoncvs AR /cvs AP ssh -SR 2048 af:53:c8:ea:98:20:a2:81:e1:e3:c9:cb:06:d3:56:d7 -SD 1024 5e:3a:78:5f:ef:0a:53:b4:b9:2c:91:84:4f:3e:52:dd -SE 256 61:e1:2b:97:a4:65:4d:70:cd:23:3b:83:04:f1:2e:87 -S2 256 10:80:7f:b7:76:03:7a:51:10:23:fb:1e:05:5b:93:74 +SR af:53:c8:ea:98:20:a2:81:e1:e3:c9:cb:06:d3:56:d7 +SD 5e:3a:78:5f:ef:0a:53:b4:b9:2c:91:84:4f:3e:52:dd +SE 61:e1:2b:97:a4:65:4d:70:cd:23:3b:83:04:f1:2e:87 +S2 10:80:7f:b7:76:03:7a:51:10:23:fb:1e:05:5b:93:74 0 GC France @@ -380,9 +380,9 @@ AU anoncvs AH openbsd.cs.fau.de AR /cvs AP ssh, ssh port 2022 -SD 1024 9f:a1:78:0b:d4:76:68:bf:3e:83:d0:41:c8:1e:33:8b -SE 256 f0:d1:64:e6:6b:2f:9e:1e:85:aa:75:e3:a0:52:d3:5a -SR 2048 d0:f2:0c:a3:bf:28:ba:18:50:5f:04:dc:13:ed:63:42 +SD 9f:a1:78:0b:d4:76:68:bf:3e:83:d0:41:c8:1e:33:8b +SE f0:d1:64:e6:6b:2f:9e:1e:85:aa:75:e3:a0:52:d3:5a +SR d0:f2:0c:a3:bf:28:ba:18:50:5f:04:dc:13:ed:63:42 # stsp@ 0 @@ -417,8 +417,8 @@ AR /cvs AP ssh VH mirror.osn.de VU http://mirror.osn.de/ -SD 1024 fb:33:05:62:96:20:cf:88:7e:10:cb:8d:91:72:57:32 -SR 1024 f2:73:d2:f6:e3:01:ef:ca:3b:e7:6c:80:b6:bd:bb:84 +SD fb:33:05:62:96:20:cf:88:7e:10:cb:8d:91:72:57:32 +SR f2:73:d2:f6:e3:01:ef:ca:3b:e7:6c:80:b6:bd:bb:84 0 GC Germany @@ -473,10 +473,10 @@ AHftp.hostserver.de AU anoncvs AR /cvs AP ssh -SR 2048
Re: Fan control not working as intended
I'm experiencing the same issues with an x220 and the latest bios (1.39). Another x220 with an older bios (1.20) works fine. The fan runs at ~2000rpm.
Re: Publishing SSH public key fingerprints bit length?
Giancarlo Razzolini: I noticed OpenBSD anon CVS SSH fingerprints have the bit length published with the algorithm type: http://www.openbsd.org/anoncvs.html That seems useless. That's not useless. SSHFP records have the algorithm type, and the fingerprint type. But they don't have the key length the question was about. And the fingerprints on that page, from ssh-keygen -l, are in a different format than SSHFP records. You can use this: https://github.com/xelerance/sshfp to generate the dns records for a given host. Or just use ssh-keygen -R. -- Christian naddy Weisgerber na...@mips.inka.de
Re: Staus of stacked softraid root (RAID1C for root)?
On Tue, 21 Oct 2014, Vladislav Manchev wrote: I asked a similar question on the list a few days ago and seems I'll be using a hardware RAID controller with softraid CRYPTO on top after all. It may be an option for you too I guess. Yeah, I probably should do hardware RAID for my server at home. At work it doesn't matter since there is no FDE and most if not all machines have hardware RAID controllers. In the past I've always liked doing software RAID for RAID1 since the OS can see the actual drives and start complaining if there is a problem with one of them. With hardware RAID you have to rely on the controller figuring it out and some utility to probe the controller. RAID5 and 6 are obviously always best on a hardware RAID controller for performance reasons. My main issue at home is my firewall which is a Mini-ITX machine with only one expansion slot which has a network card in it so hardware RAID won't be happening there. Now that I'm thinking about it though, I should probably skip the crypto for the firewall and just use non-sensitive passwords. My only real worry if the firewall is stolen is that they could possibly decrypt the passwords on it since there isn't any other possibly interesting infomation on it. Not like I have much interesting information on my server either but I still don't want to worry if my machines are stolen or something. Hmmm. Thanks again for helping me think through my options! -- John Merriam - refugee from the land of systemd
Re: relayd question - from the man page
Anyone?
Anyone?
Buehler?
On Fri, Oct 17, 2014 at 9:41 AM, Alan McKay alan.mc...@gmail.com wrote:
Hi folks,
The manpage for relayd.conf has this basic construct in it a couple of times :
table service { 192.168.1.1, 192.168.1.2, 192.168.2.3 }
table fallback disable { 10.1.5.1 retry 2 }
redirect www {
listen on www.example.com port 80
forward to service check http / code 200
forward to fallback check http / code 200
}
And also has this to say about the disable attribute.
disable
The redirection is initially disabled. It can be later enabled
through relayctl(8).
What I don't understand from the given examples is how fallback
above is getting re-enabled. It starts out with the table disabled -
I get that. But then within the redirect we are basically saying
(correct me if I am wrong) always use service unless it is not
availble, in which case use fallback
But I don't see anywhere that fallback was re-enabled so how can it
be used? And I search through the manpage and don't see any mention
of this. Does it automatically get re-enabled within the redirect -
forward? And if that is the case, what was the point of starting it
disabled in the first place?
thanks,
-Alan
--
Don't eat anything you've ever seen advertised on TV
- Michael Pollan, author of In Defense of Food
--
Don't eat anything you've ever seen advertised on TV
- Michael Pollan, author of In Defense of Food
Re: multicast packets on tun interface
On 21-10-2014 06:53, Stuart Henderson wrote: Don't rule out bugs in the OpenVPN port on OpenBSD. Despite user requests for version updates and tweaks to the port there has been an almost complete lack of feedback when updates have been sent out for testing, so it's possible problems may have crept in, especially in less frequently used areas. I'm not sure how to remove OpenVPN from the equation whilst still using tun to test things (ssh has tun-forwarding, but it doesn't set the multicast flag on the interface, and might not handle multicast at all even if you did force the flag e.g. by running OpenVPN on the interface first to set IFF_MULTICAST). I successfully managed to get broadcast and multicast packets to work on a bridged openvpn tunnel. But that was on OpenBSD 5.4. I didn't needed it anymore, so I can't speak if the latest version works. I'd probably start by bumping up verbosity in OpenVPN config and try and track things down from that side.. This will help. I suggest the OP start with 5 and see if he can track the issue. btw, the standard method for this is multicast_host=YES in rc.conf.local. Nice, didn't knew this one. Thanks. Cheers [demime 1.01d removed an attachment of type application/pkcs7-signature which had a name of smime.p7s]
Re: relayd question - from the man page
The answer to your question is right there in the very manpage
paragraph you quoted below.
On 21 Oct 2014 at 10:24, Alan McKay wrote:
Anyone?
Anyone?
Buehler?
On Fri, Oct 17, 2014 at 9:41 AM, Alan McKay alan.mc...@gmail.com
wrote:
Hi folks,
The manpage for relayd.conf has this basic construct in it a couple
of times :
table service { 192.168.1.1, 192.168.1.2, 192.168.2.3
}
table fallback disable { 10.1.5.1 retry 2 }
redirect www {
listen on www.example.com port 80
forward to service check http / code 200
forward to fallback check http / code 200
}
And also has this to say about the disable attribute.
disable
The redirection is initially disabled. It can be later
enabled through relayctl(8).
What I don't understand from the given examples is how
fallback
above is getting re-enabled. It starts out with the table disabled
-
I get that. But then within the redirect we are basically saying
(correct me if I am wrong) always use service unless it is not
availble, in which case use fallback
But I don't see anywhere that fallback was re-enabled so how can
it
be used? And I search through the manpage and don't see any
mention
of this. Does it automatically get re-enabled within the redirect
-
forward? And if that is the case, what was the point of starting
it
disabled in the first place?
thanks,
-Alan
--
Don't eat anything you've ever seen advertised on TV
- Michael Pollan, author of In Defense of Food
--
Don't eat anything you've ever seen advertised on TV
- Michael Pollan, author of In Defense of Food
Re: relayd question - from the man page
On Tue, Oct 21, 2014 at 1:25 PM, System Administrator ad...@bitwise.net wrote: The answer to your question is right there in the very manpage paragraph you quoted below. Yes, I should have clarified that I did see that. (That is why I quoted it) It just does not seem to make a lot of sense that one would have to manually intervene in order to cut over to the fallback. So I guess that is my question behind my question. Why start the fallback table as disabled? Would it not make a lot more sense to start it enabled so if service was down it would automatically cut over to fallback without manual intervention? Or is there somehow a danger that it will go to fallback when service is not down? Is that why fallback is started disabled? -- Don't eat anything you've ever seen advertised on TV - Michael Pollan, author of In Defense of Food
messed up SHA256.sig for yesterdays snapshot
Hi, I assume you are all already aware of this and I am just the last guy to get this - the SHA256, SHA256.sig and the INSTALL.amd64 files in http://ftp.openbsd.org/pub/OpenBSD/snapshots/amd64/ have strange timestamps and do not match the files in index.txt (2 hours later than the rest of the files). They also contain wrong checksums so signify fails on the sets. I think the correct answer to this is - Yes, that's old crap - wait for the next snapshot, right? Regards Lars
OpenSSH 6.7 on OpenBSD 5.5 with OPENSSL=no
Hi, I'm trying out OpenSSH 6.7 on OpenBSD 5.5 compiled with OPENSSL=no. I'm having some trouble sshing in to the server though, even just locally, so both the client and server are 6.7 with no ssl. It seems like I get authenticated, but then the session closes: previous output removed debug1: Authentication succeeded (publickey). Authenticated to 192.168.33.88 ([192.168.33.88]:22). debug2: fd 6 setting O_NONBLOCK debug3: fd 7 is O_NONBLOCK debug1: channel 0: new [client-session] debug3: ssh_session2_open: channel_new: 0 debug2: channel 0: send open debug1: Requesting no-more-sessi...@openssh.com debug1: Entering interactive session. debug1: channel 0: free: client-session, nchannels 1 debug3: channel 0: status: The following connections are open: #0 client-session (t3 r-1 i0/0 o0/0 fd 5/6 cc -1) debug1: fd 1 clearing O_NONBLOCK debug3: fd 2 is not O_NONBLOCK Connection to 192.168.33.88 closed by remote host. Connection to 192.168.33.88 closed. Transferred: sent 1388, received 1120 bytes, in 0.0 seconds Bytes per second: sent 274414.0, received 221429.2 debug1: Exit status -1 Anyone have any ideas? I'm assuming I have something misconfigured but I'm not sure what or where to look, so any ideas would be appreciated. Thanks for any help, Curtis. PS. Full client debug: https://clbin.com/AaWkp Full server debug: https://clbin.com/ktKXN
aliases and website-level 301s in OpenBSD httpd
Howdy gang,
Two questions...
1. Is there a way in the new / 5.6 httpd to have a server answer for
multiple names similar to apache ServerAlias ?
This is great in httpd:
server www.example.com {
listen on egress port 80
location *.php {
fastcgi socket /run/php-fpm.sock
directory { index index.html }
}
...but after dozens of tries with parens, commas, etc., it seems like each
domain.com requires its own complete entry whereas it was done like this in
apache:
VirtualHost *:80
ServerName www.example.com
ServerAliaswww.example2.com
...
/VirtualHost
2. And for the next item up for bid: website-level 301s.
With apache we did 301s thusly:
VirtualHost *:80
ServerName example.com
Redirect301 / http://www.example.com/
/VirtualHost
What's the right way to do that now?
Thanks,
Kevin
