Re: how to forward port 2222 of pf box to port 22 of internel webserver
On 05/02/14 05:34, Indunil Jayasooriya wrote: Dear ALL, I want to do ssh to a internel webserver from the outside world. ssh port 22 is running in that web server. SSH port 22 is also ruuning my Openbsd 5.4 ( 32 bit ) firewall to which I do ssh from the outside world. So I want to add a rule to access internel webserver So I decided to forward port of pf box to port 22 of internel webserver So, I added a rules like these. I Still can't access. pass in log on $wan_if inet proto tcp from any to $wan_if port \ rdr-to $webserver port 22 pass out log on $int_if inet proto tcp from any to $webserver port 22 modulate state But, I can't access Why? Not sure but what does: sysctl net.inet.ip.forwarding show? and if you are using ipv6: sysctl net.inet6.ip6.forwarding What does pfctl -sr show? Using: match in on $wan_if proto tcp to ($wan_if) port rdr-to \ $webserver port ssh and pass in on $wan_if proto tcp to ($wan_if) port flags S/SA synproxy state work for me on: OpenBSD atom.crowsons.com 5.4 GENERIC.MP#44 i386 If the above does not help run tcpdump on both interfaces and see what is / is not being passed... hth Fred
Re: how to forward port 2222 of pf box to port 22 of internel webserver
Thanks for the support. I changed the port from to 2224. Now it works. This PF box is behind a ADSL router. I assume this ADSL router has reserved port . I have no access to this ADSL router. These are the rules. pass in log on $wan_if inet proto tcp from any to $wan_if port 2224 \ rdr-to $webserver port 22 synproxy state pass out log on $int_if inet proto tcp from any to $webserver port 22 modulate state sysctl net.inet.ip.forwarding I have already set it to = 1 net.inet.ip.forwarding=1 Thanks for the below rules Using: match in on $wan_if proto tcp to ($wan_if) port rdr-to \ $webserver port ssh and pass in on $wan_if proto tcp to ($wan_if) port flags S/SA synproxy state work for me on: OpenBSD atom.crowsons.com 5.4 GENERIC.MP#44 i386 If the above does not help run tcpdump on both interfaces and see what is / is not being passed... hth Fred Not sure but what does: -- Thank you Indunil Jayasooriya http://www.theravadanet.net/ http://www.siyabas.lk/sinhala_how_to_install.html - Download Sinhala Fonts
upgrade 5.4 - 5.5 -- openldap bdb database
Hi! I've recently upgraded one of my systems to 55 from 54 (btw, for me, the most painful upgrade since ~3.9; I don't know what happened but everything was against me), and one of the obstacles was the openldap upgrade. I was using openldap-2.4 with bdb on 5.4 also, so I thought it would be a clean cut. After trying to start slapd, it barked about the bdb's consistency: __db.001: unable to find environment txn_checkpoint interface requires an environment configured for the transaction subsystem ... etc ... (the precise error message would require the restore of the old db files, but what's important is there) db4_verify of course told me the same, and db4_recover, or slapcat and the likes were futile. So I just shrugged and went about to restore my backups, but even the one week old backup did seem to be corrupt :-/ Long story short, I had to install a 5.4 OpenBSD, pkg_add openldap-server, copy over the openldap-data directory, slapcat to an ldif file then slapadd on the server to a clean and fresh openldap data directory. The logic is the same as for the rrdtool upgrade, but that is at least mentioned in the upgrade faq ;-P So if it seems this is a real upgrade issue for someone else also, and not a PEBKAC, then I think it would be fair to mention this on upgrade55.html. I could cook up a diff, if it turns out I was not hallucinating. Daniel -- LÉVAI Dániel PGP key ID = 0x83B63A8F Key fingerprint = DBEC C66B A47A DFA2 792D 650C C69B BE4C 83B6 3A8F
Dual connections not Load Balancing
Hi, I'm trying to handle dual wan connections on OpenBSD. I see the official PF load balancing example at main site, clearly. But my aim is not load balancing. I'm just trying to use first wan connection for our labs and use second wan connection for wireless users. Also NAT is needed cause i use private ip networks. # cat /etc/hostname.re0 inet 172.16.67.2 255.255.255.0 NONE description ADSL WAN 1 # cat /etc/hostname.re1 inet 172.16.68.2 255.255.255.0 NONE description ADSL WAN 2 # cat /etc/hostname.re3 inet 192.168.8.1 255.255.248.0 NONE description Wireless LAN # cat /etc/hostname.re4 inet 192.168.1.254 255.255.255.0 NONE description LAB Network # cat /etc/mygate 172.16.67.1 I could not know where to start how to do it? I've just stucked. Thanks for your help. -- Theron
Hearbleed and OpenSSL 1.0.1c
Just want to make sure if I get this right. Patches 007 and 008 (OpenSSL-fix) for 5.4 has been run. OpenBSD 5.5 install source code patch branch run and compiled. On both setup I get this: # openssl version -a OpenSSL 1.0.1c 10 May 2012 built on: date not available platform: information not available options: bn(64,32) rc4(8x,mmx) des(ptr,risc1,16,long) idea(int) blowfish(idx) compiler: information not available OPENSSLDIR: /etc/ssl As far as I understand, OpenSSL 1.0.1g is needed in order to be home same reg. heartbleed. I know that OpenBSD's OpenSSL is a fork, and this is maybe where the confussion comes in... but can someone clarify for me the above? Regards, Lars.
Re: Hearbleed and OpenSSL 1.0.1c
Lars Bonnesen lars.bonne...@gmail.com writes: Just want to make sure if I get this right. Patches 007 and 008 (OpenSSL-fix) for 5.4 has been run. OpenBSD 5.5 install source code patch branch run and compiled. On both setup I get this: # openssl version -a OpenSSL 1.0.1c 10 May 2012 built on: date not available platform: information not available options: bn(64,32) rc4(8x,mmx) des(ptr,risc1,16,long) idea(int) blowfish(idx) compiler: information not available OPENSSLDIR: /etc/ssl As far as I understand, OpenSSL 1.0.1g is needed in order to be home same reg. heartbleed. I know that OpenBSD's OpenSSL is a fork, and this is maybe where the confussion comes in... but can someone clarify for me the above? The patches you applied are just that, patches that fix the problem they're supposed to fix. There is no reason to change the OpenSSL version in such a patch, it would be a lie. This is not related to the fork, which happened in -current and does not affect 5.5. -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: receive error 54 from NetApp NFS server
On Tue, 29 Apr 2014, Philip Guenther wrote: On Tue, Apr 29, 2014 at 8:17 AM, Donovan Watteau tso...@gmail.com wrote: I have various mountpoints from a NetApp NFS server with I use on OpenBSD/amd64 5.5. $ grep nfs /etc/fstab server:/vol/foobar /vol/foobar nfs noauto,rw,nodev,nosuid,noatime,noexec,nfsv3,tcp,soft,intr,noac,-x=300,-t=1000,acregmin=3,acregmax=5,-r=65536,-w=65536 0 0 (and some other mountpoints with the same options) That's a lot of knob turning. What documentation or testing led to you adding the tcp, noac, ac*, -x, -t, -r, and -w options? Indeed, I don't like turning knobs either, but this problem still appears with a much simpler fstab (see below). My documentation is mount_nfs(8), and Managing NFS and NIS (recommended by books.html). Basically: * tcp: better suited our use case, with a noticeable speed improvement and a better reliability regarding the files we need to go through NFS. * noac: a leftover, but removing it doesn't fix the problem. * ac: required for our use case. * -x/-t: we needed a faster timeout/retry rate, but it may be too high. * -r/-w: gave a noticeable speed improvement for the typical size of the files going through NFS. But anyway, this much simpler configuration on a clean installation still exposes the problem: $ grep nfs /etc/fstab server:/vol/foobar /vol/foobar nfs noauto,rw,tcp 0 0 However, when I do a simple ls /vol/foobar after an hour without anything else using this mountpoint, this appears in the logs: Apr 29 13:53:46 puffy /bsd: receive error 54 from nfs server server:/vol/foobar Apr 29 13:53:48 puffy last message repeated 833 times $ grep 54 /usr/include/sys/errno.h #define ECONNRESET 54 /* Connection reset by peer */ Is there an idle timeout on the server or flaky network (NAT?) between this client and the server? There is no NAT, but there's a dedicated VLAN running on top of a LACP trunk(4). As for the server: I'm not aware of any idle timeout being set there, but it's running Data ONTAP, whose documentation doesn't match OpenBSD's one... ls(1) gets slowed down a bit, but works. The next ls(1) invocations work fine, unless I stop using the mountpoint for about an hour. This also happens when security(8) is called during the night (when /vol/foobar isn't used for hours). Is it harmless or is there a real problem? Debian on the same machine doesn't have this, but maybe OpenBSD is just a bit verbose about it? TCP connection is being dropped for some reason and then it takes a moment to be reopened when you try to use it again. Yes, I was wondering whether there is something left to be configured on the OpenBSD side to prevent that (since the problem doesn't show up on Debian running on the same machine), or should I look for a problem on the NFS server or Cisco side? Thank you.
Re: Hearbleed and OpenSSL 1.0.1c
Hi, I've seen some typos of Heartbleed but Hearbleed is a good one :) On Fri, May 02, 2014 at 12:20:55PM +0200, Lars Bonnesen wrote: As far as I understand, OpenSSL 1.0.1g is needed in order to be home same reg. heartbleed. I know that OpenBSD's OpenSSL is a fork, and this is maybe where the confussion comes in... but can someone clarify for me the above? Anyway, the common process in -stable is to fix bugs and not to upgrade to newer versions. We try to keep the patches as small as possible in there to avoid any side-effects, API, configuration or ABI changes. (You can even see this happened elsewhere like in Debian-stable where they fixed Heartbleed in 1.0.1e instead of upgrading to 1.0.1g) Reyk
BGPd parse.y typo
Hi,
A small typo in parse.y :
--- parse.y.origSat Apr 26 10:12:32 2014
+++ parse.y Sat Apr 26 10:13:55 2014
@@ -228,7 +228,7 @@
asnumber : NUMBER{
/*
-* Accroding to iana 65535 and 4294967295 are
reserved
+* According to iana 65535 and 4294967295 are
reserved
* but enforcing this is not duty of the parser.
*/
if ($1 0 || $1 UINT_MAX) {
Regards,
Denis
Problems with PPPoE, VLAN, 5.5 (amd64)
Under 5.4-stable, following configuration sets up a working connection for me: /etc/hostname.pppoe0: inet 0.0.0.0 255.255.255.255 NONE \ pppoedev vlan10 authproto pap \ authname 'XXX' authkey 'YYY' up dest 0.0.0.1 !/sbin/route add default -ifp pppoe0 0.0.0.1 #eof /etc/hostname.vlan10: vlan 10 vlandev rl0 up #eof /etc/hostname.rl0: up lladdr 12:34:56:78:90:ab #needed for assignment of 'static' IP #eof Having installed OpenBSD-5.5 amd64 the exact same configuration does not succeed in setting up a working network connection. I set the 'debug' flag for pppoe0 so I could see what happened: pppoe(8863) state=1, session=0x0 output - ff:ff:ff:ff:ff:ff, len=18 pppoe(8863) state=2, session=0x0 output - aa:aa:aa:aa:aa:aa, len=42 pppoe0: timeout [...] aa:aa:aa:aa:aa:aa is a MAC I do not know. To further check for errors, I booted a working 5.4 installation and used tcpdump on vlan10 before restarting the pppoe interface. As expected, I get only one PADO after sending the PADI. This PADO is received from a well known MAC. From here on, everything just works using the 5.4 installation. On 5.5, until this point (PADI sent/PADO received) there is no difference. For 5.4, the PADR is sent to MAC which sent PADO. For 5.5, the PADR is sent to some other MAC I do not know. There was neither a PADO sent from that MAC nor is there any other occurence of that MAC in the tcpdump besides being target of PADR. In both installations, the PADO is sent from the same MAC. Service-Name, AC-Cookie and Host-Uniq do match. Interestingly, the PADR to the unknown MAC includes the same AC-Cookie. I do not know how to proceed from here on, so I would be glad to get some advice. Best Regards, Thorsten Bonck
SIP client on OpenBSD
Hello, What SIP clients are you using day by day in OpenBSD? I tried pjsua and works fine with voice only. I am interested in another clients, possibly with video option. Thank you.
5.5 upgrade and wpi Firmware
Hi, after upgrading to 5.5 I noticed that the firmware package for my wireless card has no equivalent. Luckily, the instructions are crareful not to have you remove firmware packages. However I wonder what happened to it, has it become obsoleted by another package? Specifically: wpi-firmware-3.2p1 firmware binary images for wpi(4) driver I checked in the ports and there appears to be none! ftp://ftp.openbsd.org/pub/OpenBSD/5.5/packages/i386/ Riccardo
Re: 5.5 upgrade and wpi Firmware
after upgrading to 5.5 I noticed that the firmware package for my wireless card has no equivalent. Luckily, the instructions are crareful not to have you remove firmware packages. However I wonder what happened to it, has it become obsoleted by another package? Specifically: wpi-firmware-3.2p1 firmware binary images for wpi(4) driver I checked in the ports and there appears to be none! ftp://ftp.openbsd.org/pub/OpenBSD/5.5/packages/i386/ You should use fw_update This fetches firmware packages from a different place. That is why you don't see them.
question about pppoe(4) and IPv6
Hi, I supposedly have an IPv6 capable connection but it doesn't negotiate IPv6 for some reason. I'm inquiring if I need to turn on any sysctl's or something... #net.inet6.ip6.accept_rtadv=1 # 1=Permit IPv6 autoconf (forwarding must be 0) This one seems logical but my gateway is a soekris and has forwarding enabled in order to NAT, so I'm really confused by that comment. Right now as it is this is what my pppoe0 looks like: - # ifconfig pppoe0 pppoe0: flags=8851UP,POINTOPOINT,RUNNING,SIMPLEX,MULTICAST mtu 1492 priority: 0 dev: em0 state: session sid: 0x2b3 PADI retries: 1 PADR retries: 0 time: 11:43:44 sppp: phase network authproto pap groups: pppoe egress status: active inet6 fe80::200:24ff:fed0:1ea4%pppoe0 - prefixlen 64 scopeid 0x8 inet 188.174.205.151 -- 82.135.16.28 netmask 0x - The soekris I have running OpenBSD 5.5-stable, does not seem to negotiate IPv6, unlike the AVM FritzBox! router that it replaced. The AVM router was able to negotiate IPv6 for some reason. Since I cycle my connection in the morning times per crontab I haven't tried to get a debug yet, do you think I should do that, would it help any? My provider is M-Net in Germany. Regards, -peter
Re: question about pppoe(4) and IPv6
On Fri, May 02, 2014 at 03:51:50PM +0200, Peter J. Philipp wrote: Hi, I supposedly have an IPv6 capable connection but it doesn't negotiate IPv6 for some reason. I'm inquiring if I need to turn on any sysctl's or something... #net.inet6.ip6.accept_rtadv=1 # 1=Permit IPv6 autoconf (forwarding must be 0) This one seems logical but my gateway is a soekris and has forwarding enabled in order to NAT, so I'm really confused by that comment. Forwarding is not the same as NAT. Right now as it is this is what my pppoe0 looks like: - # ifconfig pppoe0 pppoe0: flags=8851UP,POINTOPOINT,RUNNING,SIMPLEX,MULTICAST mtu 1492 priority: 0 dev: em0 state: session sid: 0x2b3 PADI retries: 1 PADR retries: 0 time: 11:43:44 sppp: phase network authproto pap groups: pppoe egress status: active inet6 fe80::200:24ff:fed0:1ea4%pppoe0 - prefixlen 64 scopeid 0x8 There's a link-local address, so you have IPv6. inet 188.174.205.151 -- 82.135.16.28 netmask 0x - The soekris I have running OpenBSD 5.5-stable, does not seem to negotiate IPv6, unlike the AVM FritzBox! router that it replaced. The AVM router was able to negotiate IPv6 for some reason. Since I cycle my connection in the morning times per crontab I haven't tried to get a debug yet, do you think I should do that, would it help any? My provider is M-Net in Germany. Regards, -peter OpenBSD doesn't support IPv6 autoconf on routers (i.e if forwarding is enabled). Some ISPs have started using autoconf to assign a global prefix for use on the WAN link. This violates early IPv6 RFCs which said that a router cannot do autoconf. There is a newer RFC which clears this up but OpenBSD doesn't support it yet: http://tools.ietf.org/html/rfc6204 However, using a global prefix on your WAN link is usually not a hard requirement since link-local addresses are sufficient for this. Try setting a default route that points to pppoe0: !/sbin/route add -inet6 default -ifp pppoe0 fe80:: Your router should now be able to reach the IPv6 internet. Once this works you need to get your LAN connected, too. Did you get a static IPv6 prefix from your ISP for your LAN?
Re: question about pppoe(4) and IPv6
On 05/02/14 16:13, Stefan Sperling wrote: OpenBSD doesn't support IPv6 autoconf on routers (i.e if forwarding is enabled). Some ISPs have started using autoconf to assign a global prefix for use on the WAN link. This violates early IPv6 RFCs which said that a router cannot do autoconf. There is a newer RFC which clears this up but OpenBSD doesn't support it yet: http://tools.ietf.org/html/rfc6204 However, using a global prefix on your WAN link is usually not a hard requirement since link-local addresses are sufficient for this. Try setting a default route that points to pppoe0: !/sbin/route add -inet6 default -ifp pppoe0 fe80:: Your router should now be able to reach the IPv6 internet. Thanks Stefan for the good explanation and the setting! I'll try it out in a bit. Once this works you need to get your LAN connected, too. Did you get a static IPv6 prefix from your ISP for your LAN? Unfortunately it's all dynamic. M-Net used to be a friend about static IP addresses (which allowed me a tunnel to sixxs before), but they have turned against giving out static, whether v4 or v6. If I remember right they assign a /64 for the link, and give out a /48 somehow which is dynamic too. Regards, -peter
Re: question about pppoe(4) and IPv6
On 02/05/14 10:24 AM, Peter J. Philipp wrote: On 05/02/14 16:13, Stefan Sperling wrote: OpenBSD doesn't support IPv6 autoconf on routers (i.e if forwarding is enabled). Some ISPs have started using autoconf to assign a global prefix for use on the WAN link. This violates early IPv6 RFCs which said that a router cannot do autoconf. There is a newer RFC which clears this up but OpenBSD doesn't support it yet: http://tools.ietf.org/html/rfc6204 However, using a global prefix on your WAN link is usually not a hard requirement since link-local addresses are sufficient for this. Try setting a default route that points to pppoe0: !/sbin/route add -inet6 default -ifp pppoe0 fe80:: Your router should now be able to reach the IPv6 internet. Thanks Stefan for the good explanation and the setting! I'll try it out in a bit. Once this works you need to get your LAN connected, too. Did you get a static IPv6 prefix from your ISP for your LAN? Unfortunately it's all dynamic. M-Net used to be a friend about static IP addresses (which allowed me a tunnel to sixxs before), but they have turned against giving out static, whether v4 or v6. If I remember right they assign a /64 for the link, and give out a /48 somehow which is dynamic too. You would need a DHCPv6-PD capable DHCPv6 client such as wide-dhcpv6. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Re: 5.5 upgrade and wpi Firmware
On Fri, May 2, 2014 at 4:44 PM, Riccardo Mottola riccardo.mott...@libero.it wrote: Hi, after upgrading to 5.5 I noticed that the firmware package for my wireless card has no equivalent. Luckily, the instructions are crareful not to have you remove firmware packages. However I wonder what happened to it, has it become obsoleted by another package? Specifically: wpi-firmware-3.2p1 firmware binary images for wpi(4) driver I checked in the ports and there appears to be none! ftp://ftp.openbsd.org/pub/OpenBSD/5.5/packages/i386/ Riccardo Hi Ricardo, Have you checked here : http://firmware.openbsd.org/firmware/5.5/ ? I can find this file: wpi-firmware-3.2p1.tgz Kind regards, Axel
Re: how to forward port 2222 of pf box to port 22 of internel webserver
On Fri, May 02, 2014 at 12:53:05PM +0530, Indunil Jayasooriya wrote: Thanks for the support. I changed the port from to 2224. Now it works. This PF box is behind a ADSL router. I assume this ADSL router has reserved port . I have no access to this ADSL router. is used by a few LAN client services, and is often a backdoor for trojans. So it is either blocked, or reserved for some Rockwell services. -- John D. Verne j...@clevermonkey.org
Re: 5.5 upgrade and wpi Firmware
Hi, Axel wrote: Have you checked here : http://firmware.openbsd.org/firmware/5.5/ ? I can find this file: wpi-firmware-3.2p1.tgz no sorry, I missed that. Platform-independent firmware then. This is why fw_update did not upgrade it, I already have the latest version. Everything is fine then and sorry for the noise. Riccardo
sshd broken in today's snapshot?
Unless I'm doing something stupid, sshd seems to be broken in today's snapshot. From a Linux machine: $ ssh testing Connection to testing closed by remote host. Connection to testing closed. From the server's point of view: # dmesg | head -1 OpenBSD 5.5-current (GENERIC.MP) #95: Fri May 2 06:31:18 MDT 2014 # /usr/sbin/sshd -d debug1: sshd version OpenSSH_6.7, OpenSSL 1.0.1g 7 Apr 2014 debug1: key_parse_private2: missing begin marker debug1: read PEM private key done: type RSA debug1: private host key: #0 type 1 RSA debug1: key_parse_private2: missing begin marker debug1: read PEM private key done: type DSA debug1: private host key: #1 type 2 DSA debug1: key_parse_private2: missing begin marker debug1: read PEM private key done: type ECDSA debug1: private host key: #2 type 3 ECDSA debug1: private host key: #3 type 4 ED25519 debug1: rexec_argv[0]='/usr/sbin/sshd' debug1: rexec_argv[1]='-d' debug1: Bind to port 22 on 0.0.0.0. Server listening on 0.0.0.0 port 22. debug1: fd 4 clearing O_NONBLOCK debug1: Server will not fork when running in debugging mode. debug1: rexec start in 4 out 4 newsock 4 pipe -1 sock 7 debug1: inetd sockets after dupping: 3, 3 Connection from 192.168.56.1 port 57650 on 192.168.56.102 port 22 debug1: Client protocol version 2.0; client software version OpenSSH_6.6 debug1: match: OpenSSH_6.6 pat OpenSSH_6.5*,OpenSSH_6.6* compat 0x1400 debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_6.7 debug1: permanently_set_uid: 27/27 [preauth] debug1: list_hostkey_types: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256,ssh-ed25519 [preauth] debug1: SSH2_MSG_KEXINIT sent [preauth] debug1: SSH2_MSG_KEXINIT received [preauth] debug1: kex: client-server aes128-ctr umac-64-...@openssh.com z...@openssh.com [preauth] debug1: kex: server-client aes128-ctr umac-64-...@openssh.com z...@openssh.com [preauth] debug1: expecting SSH2_MSG_KEX_ECDH_INIT [preauth] debug1: SSH2_MSG_NEWKEYS sent [preauth] debug1: expecting SSH2_MSG_NEWKEYS [preauth] debug1: SSH2_MSG_NEWKEYS received [preauth] debug1: KEX done [preauth] debug1: userauth-request for user daia service ssh-connection method none [preauth] debug1: attempt 0 failures 0 [preauth] debug1: userauth-request for user daia service ssh-connection method publickey [preauth] debug1: attempt 1 failures 0 [preauth] debug1: test whether pkalg/pkblob are acceptable [preauth] debug1: temporarily_use_uid: 1000/1000 (e=0/0) debug1: trying public key file /home/daia/.ssh/authorized_keys debug1: fd 4 clearing O_NONBLOCK debug1: restore_uid: 0/0 Failed publickey for daia from 192.168.56.1 port 57650 ssh2: RSA 3b:30:77:5c:8b:55:cf:a1:f6:f6:81:27:73:d8:2e:3e debug1: userauth-request for user daia service ssh-connection method publickey [preauth] debug1: attempt 2 failures 1 [preauth] debug1: test whether pkalg/pkblob are acceptable [preauth] debug1: temporarily_use_uid: 1000/1000 (e=0/0) debug1: trying public key file /home/daia/.ssh/authorized_keys debug1: fd 4 clearing O_NONBLOCK debug1: matching key found: file /home/daia/.ssh/authorized_keys, line 1 DSA 3b:87:9f:8e:ef:ea:cf:a5:2e:9a:a4:bb:c7:b6:86:f6 debug1: restore_uid: 0/0 Postponed publickey for daia from 192.168.56.1 port 57650 ssh2 [preauth] debug1: userauth-request for user daia service ssh-connection method publickey [preauth] debug1: attempt 3 failures 1 [preauth] debug1: temporarily_use_uid: 1000/1000 (e=0/0) debug1: trying public key file /home/daia/.ssh/authorized_keys debug1: fd 4 clearing O_NONBLOCK debug1: matching key found: file /home/daia/.ssh/authorized_keys, line 1 DSA 3b:87:9f:8e:ef:ea:cf:a5:2e:9a:a4:bb:c7:b6:86:f6 debug1: restore_uid: 0/0 debug1: ssh_dss_verify: signature correct Accepted publickey for daia from 192.168.56.1 port 57650 ssh2: DSA 3b:87:9f:8e:ef:ea:cf:a5:2e:9a:a4:bb:c7:b6:86:f6 debug1: monitor_child_preauth: daia has been authenticated by privileged process debug1: Enabling compression at level 6. [preauth] debug1: monitor_read_log: child log fd closed User child is on pid 11401 debug1: Entering interactive session for SSH2. debug1: server_init_dispatch_20 debug1: do_cleanup At this point, sshd exits. Regards, Liviu Daia
Re: sshd broken in today's snapshot?
On Fri, May 2, 2014 at 8:42 AM, Liviu Daia liviu.d...@gmail.com wrote: Unless I'm doing something stupid, sshd seems to be broken in today's snapshot. From a Linux machine: $ ssh testing Connection to testing closed by remote host. Connection to testing closed. From the server's point of view: # dmesg | head -1 OpenBSD 5.5-current (GENERIC.MP) #95: Fri May 2 06:31:18 MDT 2014 # /usr/sbin/sshd -d debug1: Enabling compression at level 6. [preauth] Try disabling compression and see if that fixes it. Jeremy
Re: Problems with PPPoE, VLAN, 5.5 (amd64)
On 2 May 2014 14:54, thors...@bonck.net wrote: Under 5.4-stable, following configuration sets up a working connection for me: /etc/hostname.pppoe0: inet 0.0.0.0 255.255.255.255 NONE \ pppoedev vlan10 authproto pap \ authname 'XXX' authkey 'YYY' up dest 0.0.0.1 !/sbin/route add default -ifp pppoe0 0.0.0.1 #eof /etc/hostname.vlan10: vlan 10 vlandev rl0 up #eof /etc/hostname.rl0: up lladdr 12:34:56:78:90:ab #needed for assignment of 'static' IP #eof Having installed OpenBSD-5.5 amd64 the exact same configuration does not succeed in setting up a working network connection. I can confirm this. I saw the very same on i386. In my case, the VLAN is only used internally on my LAN, and I wanted to make it work again quickly, so I just removed the VLAN from the setup and used the hardware interface directly as pppoedev for pppoe0, which made it work again. I see that only as temporary workaround though. I set the 'debug' flag for pppoe0 so I could see what happened: pppoe(8863) state=1, session=0x0 output - ff:ff:ff:ff:ff:ff, len=18 pppoe(8863) state=2, session=0x0 output - aa:aa:aa:aa:aa:aa, len=42 pppoe0: timeout [...] aa:aa:aa:aa:aa:aa is a MAC I do not know. To further check for errors, I booted a working 5.4 installation and used tcpdump on vlan10 before restarting the pppoe interface. As expected, I get only one PADO after sending the PADI. This PADO is received from a well known MAC. From here on, everything just works using the 5.4 installation. On 5.5, until this point (PADI sent/PADO received) there is no difference. For 5.4, the PADR is sent to MAC which sent PADO. For 5.5, the PADR is sent to some other MAC I do not know. There was neither a PADO sent from that MAC nor is there any other occurence of that MAC in the tcpdump besides being target of PADR. In both installations, the PADO is sent from the same MAC. Service-Name, AC-Cookie and Host-Uniq do match. Interestingly, the PADR to the unknown MAC includes the same AC-Cookie. I do not know how to proceed from here on, so I would be glad to get some advice. Best Regards, Thorsten Bonck
Re: The book of PF
Pleased you're flattered ;) Found the last one to be really helpful and an enjoyable read when I was first getting into OpenBSD. HFSC is a complex algorthm and it took a *lot* of trail and error to understand all the parameters and their interactions, and so with the recent syntax changes to the queuing system I'm hoping for some nice examples and explanations of the parameters :) Keep up the good work :) Andy. On 01/05/14 20:40, Peter N. M. Hansteen wrote: Andy a...@brandwatch.com writes: When is the next edition of 'The book of PF' expected? Want to read this to fully understand the new queuing subsystem before rewriting our PFs :) The Book of PF, 3rd edition is slithering through the later editing stages at the moment. I'll do my best to speed the thing along, but unfortunately I can't give you an exact ETA, other than that it's likely that you'll see my BSDCan slides on the topic before the book materializes. I'm deeply flattered and a bit horrified that anyone would see my scribblings as a prerequisite for trying out an exciting new OpenBSD feature. Thank you very much! I will do my best to make that book and other material I poduce live up to expectations (as in, being as useful and correct as I am able to make them, with the help of a few really excellent people). All the best, Peter
Re: 5.5 upgrade and wpi Firmware
previously on this list Axel contributed: Specifically: wpi-firmware-3.2p1 firmware binary images for wpi(4) driver I checked in the ports and there appears to be none! ftp://ftp.openbsd.org/pub/OpenBSD/5.5/packages/i386/ Riccardo Hi Ricardo, Have you checked here : http://firmware.openbsd.org/firmware/5.5/ ? I can find this file: wpi-firmware-3.2p1.tgz I've been meaning to ask. Is there an intentional reason why the directory is not browsable. I know fw_update works directly and the full fw name works but I was hoping to be able to download any updates once for all machines and haven't found an easy way to find the firmware names? -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or systemd ___ I have no idea why RTFM is used so aggressively on LINUX mailing lists because whilst 'apropos' is traditionally the most powerful command on Unix-like systems it's 'modern' replacement 'apropos' on Linux is a tool to help psychopaths learn to control their anger. (Kevin Chadwick) ___
Re: sshd broken in today's snapshot?
On 2 May 2014, Jeremy Evans jeremyeva...@gmail.com wrote: On Fri, May 2, 2014 at 8:42 AM, Liviu Daia liviu.d...@gmail.com wrote: Unless I'm doing something stupid, sshd seems to be broken in today's snapshot. From a Linux machine: $ ssh testing Connection to testing closed by remote host. Connection to testing closed. From the server's point of view: # dmesg | head -1 OpenBSD 5.5-current (GENERIC.MP) #95: Fri May 2 06:31:18 MDT 2014 # /usr/sbin/sshd -d debug1: Enabling compression at level 6. [preauth] Try disabling compression and see if that fixes it. Yes, it works with compression disabled, thank you. Regards, Liviu Daia
Big endian options
The recent news elsewhere about Debian no longer actively testing on sparc plaforms got me to thinking. It's been very handy over the years to be able to test programs on both big-endian and little-endian machines (for the same reason that it's good to test across different compilers and operating systems). However, a lot of the big-endian hardware out there is getting a bit long in the tooth. If one is to consider only hardware that is still being manufactured (ie: bought new), what are our options now? Sparc is still around, of course, although I had serious doubts about how long it would be around when Oracle bought Sun. There's IBM's Power architecture, but it looks like more recent versions of that will (optionally) run little-endian natively, which makes me wonder about long-term directions there. Am I missing anything? The question is two-fold: In one way I'm asking about things that OpenBSD will currently run on, and in the other just asking about what's available for hardware regardless of whether OpenBSD will currently run on it. Devin
Re: Big endian options
If one is to consider only hardware that is still being manufactured (ie: bought new), what are our options now? The only big-endian systems you can buy new nowadays, would be Octeon-based systems. Some of them can run OpenBSD.
Re: Big endian options
The question is two-fold: In one way I'm asking about things that OpenBSD will currently run on, and in the other just asking about what's available for hardware regardless of whether OpenBSD will currently run on it. In general, MIPS like Cavium Octeon is BE, supported and currently shipping (There are some LE MIPS like Loongson)
Re: Big endian options
If one is to consider only hardware that is still being manufactured (ie: bought new), what are our options now? The only big-endian systems you can buy new nowadays, would be Octeon-based systems. Some of them can run OpenBSD. Oh good god. Just go to ebay and buy HP J6700/6750 or Sun v210/v215 machines. Big endian is one thing being talked about here, but those two platforms I just listed bring other other valuable quirks to the table.
Re: question about pppoe(4) and IPv6
On 05/02/14 16:13, Stefan Sperling wrote: Hi again, I just had a few more questions... OpenBSD doesn't support IPv6 autoconf on routers (i.e if forwarding is enabled). Some ISPs have started using autoconf to assign a global prefix for use on the WAN link. This violates early IPv6 RFCs which said that a router cannot do autoconf. There is a newer RFC which clears this up but OpenBSD doesn't support it yet: http://tools.ietf.org/html/rfc6204 This RFC is actually pretty good at first glance. You mentioned OpenBSD doesn't support it yet, so I'm wondering what needs to be done in OpenBSD to bring it up to par. Is there any leads? It seems to me that section 4.2 WAN-Side Configuration, under W-3 states it MUST use Router Discovery based on RFC 4861 Neighbour Discovery for IPv6 which is a replacement for RFC 2461. When I look at the comments in /usr/src/sys/netinet6/nd6.c it seems to me they quote RFC 2461 a lot, is upgrading this area needed for a first step? Do you think bringing nd6 up to RFC 4861 par would be easy, for someone like me? However, using a global prefix on your WAN link is usually not a hard requirement since link-local addresses are sufficient for this. Try setting a default route that points to pppoe0: !/sbin/route add -inet6 default -ifp pppoe0 fe80:: Your router should now be able to reach the IPv6 internet. I tried this. Outgoing packets probly work fine but I don't have a globally routeable IPv6 address, so return packets would probably not make it back. I think I need the nd6 upgrade as ndp -na gives the following: Neighbor Linklayer Address Netif Expire fe80::200:24ff:fed0:1ea4%pppoe0 (incomplete) pppoe0 permanent notice the (incomplete). It probably does not speak with the router at the ISP in the right protocol. It's actually impossible to get my ISP to quote any RFC's on what they support here. They just say it supports IPv6 capable routers but deny support for it. I tried. Once this works you need to get your LAN connected, too. Did you get a static IPv6 prefix from your ISP for your LAN? I think I already answered this earlier today. Regards, -peter
Re: Problems with PPPoE, VLAN, 5.5 (amd64)
On 2.5.2014. 14:54, thors...@bonck.net wrote: Under 5.4-stable, following configuration sets up a working connection for me: /etc/hostname.pppoe0: inet 0.0.0.0 255.255.255.255 NONE \ pppoedev vlan10 authproto pap \ authname 'XXX' authkey 'YYY' up dest 0.0.0.1 !/sbin/route add default -ifp pppoe0 0.0.0.1 #eof /etc/hostname.vlan10: vlan 10 vlandev rl0 up #eof /etc/hostname.rl0: up lladdr 12:34:56:78:90:ab #needed for assignment of 'static' IP #eof Having installed OpenBSD-5.5 amd64 the exact same configuration does not succeed in setting up a working network connection. I set the 'debug' flag for pppoe0 so I could see what happened: pppoe(8863) state=1, session=0x0 output - ff:ff:ff:ff:ff:ff, len=18 pppoe(8863) state=2, session=0x0 output - aa:aa:aa:aa:aa:aa, len=42 pppoe0: timeout [...] aa:aa:aa:aa:aa:aa is a MAC I do not know. To further check for errors, I booted a working 5.4 installation and used tcpdump on vlan10 before restarting the pppoe interface. As expected, I get only one PADO after sending the PADI. This PADO is received from a well known MAC. From here on, everything just works using the 5.4 installation. On 5.5, until this point (PADI sent/PADO received) there is no difference. For 5.4, the PADR is sent to MAC which sent PADO. For 5.5, the PADR is sent to some other MAC I do not know. There was neither a PADO sent from that MAC nor is there any other occurence of that MAC in the tcpdump besides being target of PADR. In both installations, the PADO is sent from the same MAC. Service-Name, AC-Cookie and Host-Uniq do match. Interestingly, the PADR to the unknown MAC includes the same AC-Cookie. I do not know how to proceed from here on, so I would be glad to get some advice. Best Regards, Thorsten Bonck maybe you could try to put pppoe0 on rl0, untag vlan10 on switch port where rl0 is connected and tag other vlans on the same port ...
Re: question about pppoe(4) and IPv6
On Fri, May 02, 2014 at 08:24:27PM +0200, Peter J. Philipp wrote: On 05/02/14 16:13, Stefan Sperling wrote: Hi again, I just had a few more questions... OpenBSD doesn't support IPv6 autoconf on routers (i.e if forwarding is enabled). Some ISPs have started using autoconf to assign a global prefix for use on the WAN link. This violates early IPv6 RFCs which said that a router cannot do autoconf. There is a newer RFC which clears this up but OpenBSD doesn't support it yet: http://tools.ietf.org/html/rfc6204 This RFC is actually pretty good at first glance. You mentioned OpenBSD doesn't support it yet, so I'm wondering what needs to be done in OpenBSD to bring it up to par. Is there any leads? It seems to me that section 4.2 WAN-Side Configuration, under W-3 states it MUST use Router Discovery based on RFC 4861 Neighbour Discovery for IPv6 which is a replacement for RFC 2461. When I look at the comments in /usr/src/sys/netinet6/nd6.c it seems to me they quote RFC 2461 a lot, is upgrading this area needed for a first step? Do you think bringing nd6 up to RFC 4861 par would be easy, for someone like me? I don't really know what's necessary because I haven't spent much time looking into the problem. However, using a global prefix on your WAN link is usually not a hard requirement since link-local addresses are sufficient for this. Try setting a default route that points to pppoe0: !/sbin/route add -inet6 default -ifp pppoe0 fe80:: Your router should now be able to reach the IPv6 internet. I tried this. Outgoing packets probly work fine but I don't have a globally routeable IPv6 address, so return packets would probably not make it back. As Brad suggested, have you tried wide-dhcpv6 from ports? You can probably use dhcp6c to put the dynamically assigned prefix on your internal LAN interface. In the dhcp6c.conf man page there's an example using ppp0 and ne0 which you could try adjusting. I've never tried this myself so I'm not sure how the details work. If you have a global address on your LAN interface, the router will also use it as source address for self-originated outgoing packets on the WAN link instead of using the link-local adress as source address. You do not need a global address on pppoe0 to be reachable!
Re: Problems with PPPoE, VLAN, 5.5 (amd64)
maybe you could try to put pppoe0 on rl0, untag vlan10 on switch port
where rl0 is connected and tag other vlans on the same port ...
Sadly, that is not possible for me.
rl0 is directly connected to a Ubiquiti NanoStation M, which is setup as
a blackbox transparent bridge by my ISP.
vlan id 10 is also required by my ISP for all PPP/PPPoE stuff.
I could put a tagging switch in between rl0 and the bridge as a last
resort, but for right now I am still looking for a reason why 5.4 works
and 5.5 seems to answer to a wrong MAC.
Looking through the changes from 5.4 I found Stop defining
SIOC{S,G}ETVLAN as SIOC{S,G}IFGENERIC. Lets vlan(4) handle
pppoe(4)-specific ioctls and vice versa without smashing the stack of
the caller. Is it possible my problem is somehow connected to that?
Re: Problems with PPPoE, VLAN, 5.5 (amd64)
On Fri, May 02, 2014 at 08:14:40PM +, Peter J. Philipp wrote:
On Fri, May 02, 2014 at 09:14:16PM +0200, thors...@bonck.net wrote:
maybe you could try to put pppoe0 on rl0, untag vlan10 on switch port
where rl0 is connected and tag other vlans on the same port ...
Sadly, that is not possible for me.
rl0 is directly connected to a Ubiquiti NanoStation M, which is setup as
a blackbox transparent bridge by my ISP.
vlan id 10 is also required by my ISP for all PPP/PPPoE stuff.
I could put a tagging switch in between rl0 and the bridge as a last
resort, but for right now I am still looking for a reason why 5.4 works
and 5.5 seems to answer to a wrong MAC.
Looking through the changes from 5.4 I found Stop defining
SIOC{S,G}ETVLAN as SIOC{S,G}IFGENERIC. Lets vlan(4) handle
pppoe(4)-specific ioctls and vice versa without smashing the stack of
the caller. Is it possible my problem is somehow connected to that?
Hello,
I'd probably do a tcpdump -v -n -e -s 200 -X -i rl0 as well.. perhaps you
can see somewhere where the aa:aa:aa:aa:aa:aa is coming from. Perhaps there
is an offset logic error somewhere as the pppoe driver reads the PADO source
address from the mbuf etherheader which was prepended. If you can't make
out any 's in the frame then that's further suspicous.
After some staring at the dumped frames, I can describe the problem more
detailed.
Assume listed devices to have following macs:
rl011:22:33:44:55:66
PPPoE server aa:bb:cc:dd:ee:ff
rl0 broadcasts PADI to ff:ff:ff:ff:ff:ff.
PPPoE servers mac sends a PADO to rl0 mac.
rl0 sends a PADR to mac aa:bb:55:66:aa:bb.
timeout happens, since no device with aa:bb:55:66:aa:bb exists in the
network.
Now change rl0 mac to 11:22:33:44:77:88:
PADI,PADO phase unchanged.
rl0 sends a PADR to mac aa:bb:77:88:aa:bb.
I only have a very basic understanding of C and basically no
understanding of the OpenBSD kernel.
The PADR should be assembled around line 703 in src/sys/net/if_pppoe.c
but I could not find any clues where this mix up happens.
Best Regards,
Thorsten
Re: Problems with PPPoE, VLAN, 5.5 (amd64)
Em 02-05-2014 18:18, Thorsten Bonck escreveu:
On Fri, May 02, 2014 at 08:14:40PM +, Peter J. Philipp wrote:
On Fri, May 02, 2014 at 09:14:16PM +0200, thors...@bonck.net wrote:
maybe you could try to put pppoe0 on rl0, untag vlan10 on switch port
where rl0 is connected and tag other vlans on the same port ...
Sadly, that is not possible for me.
rl0 is directly connected to a Ubiquiti NanoStation M, which is setup as
a blackbox transparent bridge by my ISP.
vlan id 10 is also required by my ISP for all PPP/PPPoE stuff.
I could put a tagging switch in between rl0 and the bridge as a last
resort, but for right now I am still looking for a reason why 5.4 works
and 5.5 seems to answer to a wrong MAC.
Looking through the changes from 5.4 I found Stop defining
SIOC{S,G}ETVLAN as SIOC{S,G}IFGENERIC. Lets vlan(4) handle
pppoe(4)-specific ioctls and vice versa without smashing the stack of
the caller. Is it possible my problem is somehow connected to that?
Hello,
I'd probably do a tcpdump -v -n -e -s 200 -X -i rl0 as well.. perhaps you
can see somewhere where the aa:aa:aa:aa:aa:aa is coming from. Perhaps there
is an offset logic error somewhere as the pppoe driver reads the PADO source
address from the mbuf etherheader which was prepended. If you can't make
out any 's in the frame then that's further suspicous.
After some staring at the dumped frames, I can describe the problem more
detailed.
Assume listed devices to have following macs:
rl011:22:33:44:55:66
PPPoE server aa:bb:cc:dd:ee:ff
rl0 broadcasts PADI to ff:ff:ff:ff:ff:ff.
PPPoE servers mac sends a PADO to rl0 mac.
rl0 sends a PADR to mac aa:bb:55:66:aa:bb.
timeout happens, since no device with aa:bb:55:66:aa:bb exists in the
network.
Now change rl0 mac to 11:22:33:44:77:88:
PADI,PADO phase unchanged.
rl0 sends a PADR to mac aa:bb:77:88:aa:bb.
I only have a very basic understanding of C and basically no
understanding of the OpenBSD kernel.
The PADR should be assembled around line 703 in src/sys/net/if_pppoe.c
but I could not find any clues where this mix up happens.
Best Regards,
Thorsten
Throsten,
I use pppoe also but without the vlan. Can you please send a dmesg,
specially after the pppoe interface is brought up? Also, a ifconfig -A
wouldn't hurt. My ISP have more than on concentrator and I don't have
these kind of problems. Of course, only one of thens answers my PADI
requests, but afaik, I could connect to any of the ISP side
concentrators, the first one to reply with the PAD0 receives the
connection. I didn't yet tried to upgrade to 5.5, but I believe I won't
have any problems. I do have a gpon connecting me with my isp and it's
also doing a transparent bridge. But the vlan is transparently handled
on it's configuration, not on my endpoint. I believe you could access
your configuration in the ubiquiti, and do the same.
Cheers,
--
Giancarlo Razzolini
GPG: 4096R/77B981BC
Re: question about pppoe(4) and IPv6
On 05/02/14 20:57, Stefan Sperling wrote: As Brad suggested, have you tried wide-dhcpv6 from ports? You can probably use dhcp6c to put the dynamically assigned prefix on your internal LAN interface. In the dhcp6c.conf man page there's an example using ppp0 and ne0 which you could try adjusting. I've never tried this myself so I'm not sure how the details work. I tried this it didn't work for me. I just now tried it again since I used gif0 where ne0 is first, but realised it may need to be an ethernet interface, switched it to em1 but no change. If you have a global address on your LAN interface, the router will also use it as source address for self-originated outgoing packets on the WAN link instead of using the link-local adress as source address. You do not need a global address on pppoe0 to be reachable! That's pretty cool :-). I'm gonna try this again tomorrow see how it goes then. Cheers, -peter
