Re: 4-ports router under $150
On 08/04/2018 23:16, Rupert Gallagher wrote: > 963Mbps > > On Sun, Apr 8, 2018 at 18:02, Michael Price wrote: > >> Was it an apu2c4 by any chance? I was thinking about picking one of those up >> and was curious as to what kind of packet rates people were seeing with them. Obtaining a gig isn't hard, what actual pps can they achieve?
Re: Blocking users who change their IP address
On 05/10/2017 22:39, Eric Johnson wrote: On Fri, 6 Oct 2017, Mihai Popescu wrote: I'm at a small Wireless ISP in a small town and have only a Class C block of addresses. [...] [...] Very romantic, indeed, but it has nothing to do with OpenBSD. Are you serious? Since the primary firewall and the DHCP server (and pretty much everything else on my end) run on OpenBSD, if there is a way to do it with OpenBSD, for example with pf, then I think that it should be a very good place to ask the question. Of course, if there is no way to address the problem on computers running OpenBSD, then I did ask in the wrong place. Based on your response, I assume that OpenBSD must be useless for trying to solve that problem and I shall have to look elsewhere. Eric This is a network infrastructure/design problem you need to either isolate customers or filter further down stream, if they're on a relatively dumb shared layer2 network you aren't going to be able to fix it by the time it gets to the firewall...
Re: octeon port, ubiquity edgerouter
On 26/07/2017 00:56, jungle Boogie wrote: > On 25 July 2017 at 15:20, Doggie wrote: >> W dniu 2017-07-25 o 19:39, Peter J. Philipp pisze: >>> >>> Actually I bought the silent fans. So I don't have to write any code, >>> too bad the foxconn fans are a misdesign. I'll maintenance this router >>> next week for the new fans. I'm putting it into production at home >>> tomorrow though. >> >> >> Thanks for all the details, Peter, and good luck during next steps of your >> project. >> >> I wonder how fast the NIC's will be - using this CPU and still no hardware >> acceleration. >> > > Yeah, I'm wondering that too. It's pretty cool this platform is > becoming more popular to run openBSD on. > People are willing to take an unknown (right now) performance penalty > to run openBSD on it and with pf. > > Sounds like ubiquity should just sell it with openBSD loaded on it > support the project. ;) > As far as the ERL goes, it seems to be limited to about 250Mbps per interface (only tested with in+out, 2 500 ish total), regardless of packet size
Re: Jumbo frames on Octeon
On 29/06/2017 12:06, Visa Hankala wrote: > On Tue, Jun 27, 2017 at 07:57:42PM +0100, Joe Holden wrote: >> It looks like setting the mtu on cnmac interfaces doesn't quite work as >> expected, whatever the mtu is set to the upper limit appears to be 1510 >> as although it will transmit frames of any arbitary size (e.g 2000 >> bytes), the reply never makes it back (confirmed from an attached box) >> unless the frame is =< 1510. > I just committed a patch that lets MTU change happen on the fly > with cnmac(4). > > If you are using release 6.1, you have to temporarily bring down > the interface, or reboot, when changing MTU on a cnmac(4) interface. > Ah excellent, cheers!
Re: Jumbo frames on Octeon
On 27/06/2017 19:57, Joe Holden wrote: > Hi guys, > > It looks like setting the mtu on cnmac interfaces doesn't quite work as > expected, whatever the mtu is set to the upper limit appears to be 1510 > as although it will transmit frames of any arbitary size (e.g 2000 > bytes), the reply never makes it back (confirmed from an attached box) > unless the frame is =< 1510. > > Not sure who looks after octeon these days > > Cheers > Should probably note, observed on ERL
Jumbo frames on Octeon
Hi guys, It looks like setting the mtu on cnmac interfaces doesn't quite work as expected, whatever the mtu is set to the upper limit appears to be 1510 as although it will transmit frames of any arbitary size (e.g 2000 bytes), the reply never makes it back (confirmed from an attached box) unless the frame is =< 1510. Not sure who looks after octeon these days Cheers
Re: DNS hijacking (was Re: Is this an intrusion?)
On 18/06/2017 10:59, Stuart Henderson wrote: > On 2017-06-17, Paul Suh wrote: >> Folks,=20 >> >> My understanding of the way that this is done is by returning a CNAME = >> when the ISP's DNS recursive DNS server would otherwise return a = >> NXDOMAIN result, followed by a HTTP 302 when the browser attempts to = >> reach the host via the bogus CNAME.=20 >> >> My question is would running my own internal recursive DNS resolver be = >> sufficient to stop this from happening? (I run my own DNS server anyway, = >> but I'm curious to see whether it would be sufficient to bypass the = >> search page redirection stupidity.)=20 > > Usually that's enough, but it depends how evil the ISP is. > Should give them a call and have it turned off anyway really...
Re: Is this an intrusion?
On 16/06/2017 20:59, Maurice McCarthy wrote: > On 15/06/17 14:13, Ted Unangst wrote: >> Maurice McCarthy wrote: >>> Hi, >>> >>> $ xauth list >>> ... >>> advancedsearch.virginmedia.com:0 MIT-MAGIC-COOKIE-1 >>> f3aa08ed0926482c51f5cb386e28a0ea >>> >>> >>> Virgin Media is my ISP. Is this an intrusion into my system please? I >>> ran xauth remove ... just for the sake of it anyhow. >> >> well, even if it wasn't, you just posted the secret key to a public list, so >> probably wise to remove it anyway. :) > > Thanks to all that have replied and apologies for the slow response. Had > to attend to more urgent matters. (Lost the blessed terrestrial TV > signal!) > > To TedU, > > Ooops! ... Well, I moved the .Xauthority file aside and restarted X to > create a new one. Obviously it has one line with my hostname in it. But > > $ xauth list > fresh.yem/unix:0 MIT-MAGIC-COOKIE-1 ... > advancedsearch.virginmedia.com:0 MIT-MAGIC-COOKIE-1 ... > > And only now did I notice that the magic cookie is identical for both > entries. This mystifies me. (BTW apparently Virgin has historically used > a bit of DNS hijacking so I bunged this line into /etc/hosts before > restarting X. > > 127.0.0.1 advancedsearch.virginmedia.com ) > > > To Peter Hessler, > > The reverse DNS went like this > > 80.2.249.209 cpc77525-cwma10-2-0-cust208.7-3.cable.virginm.net > > I run most traffic through a vpn but my router is a Virgin SuperHub2, as > they call it. > > > To Dot Yet, > > I've through system logs etc and nothing seems to look suspicious. Can't > find any attempts to execute commands nor authenticate. Further the > remote access port is disabled in the router settings. I've never asked > Virgin for support in years. > > > To Joe Holden, > > Thanks for the tip about NXDOMAIN queries. Don't see where to unset in > the router but I'm guessing the hosts file entry above should do the > same thing. > > I'll keep looking around to reassure myself anyhow > > Thanks to all, > Moss It is done by the VM dns servers, if you visit a domain that doesn't exist you should be directed to the advanced search page, there *should* be a link to disable it there, but if not login to your account and disable it, can't remember what it is called... Hosts file won't solve the problem really since anything else will also get the same result
Re: Is this an intrusion?
On 15/06/2017 16:47, Dot Yet wrote: > On Thu, Jun 15, 2017 at 9:12 AM Maurice McCarthy > wrote: > >> Hi, >> >> $ xauth list >> ... >> advancedsearch.virginmedia.com:0 MIT-MAGIC-COOKIE-1 >> f3aa08ed0926482c51f5cb386e28a0ea >> >> >> Virgin Media is my ISP. Is this an intrusion into my system please? I >> ran xauth remove ... just for the sake of it anyhow. >> >> Thanks >> Moss > > > Maybe. Are there other hints in the system log files, history files around >> someone trying to authenticate or execute commands? Was there a possibility >> that there was a screen sharing session done for any kind of support >> activities (would not be the case as you are already suspecting intrusion). >> More likely you typo'd adding a host, advancedsearch is what NXDOMAIN queries get directed to, just turn it off on my virgin media
Small patch for vnconfig/mount_vnd to return the first unused vnd device
Might be useful, particularly in scripting... Behaves like losetup. Index: sbin/mount_vnd/mount_vnd.c === RCS file: /cvs/src/sbin/mount_vnd/mount_vnd.c,v retrieving revision 1.20 diff -u -p -r1.20 mount_vnd.c --- sbin/mount_vnd/mount_vnd.c 24 Jan 2016 06:32:33 - 1.20 +++ sbin/mount_vnd/mount_vnd.c 28 Apr 2017 03:24:44 - @@ -62,6 +62,7 @@ #define VND_CONFIG 1 #define VND_UNCONFIG 2 #define VND_GET3 +#define VND_FIND 4 int verbose = 0; int run_mount_vnd = 0; @@ -70,12 +71,13 @@ __dead void usage(void); int config(char *, char *, int, struct disklabel *, char *, size_t); int getinfo(const char *); +int findfirst(void); char *get_pkcs_key(char *, char *); int main(int argc, char **argv) { - int ch, rv, action, opt_c, opt_k, opt_K, opt_l, opt_u; + int ch, rv, action, opt_c, opt_k, opt_K, opt_l, opt_u, opt_f = 0; char*key, *mntopts, *rounds, *saltopt; size_t keylen = 0; extern char *__progname; @@ -88,7 +90,7 @@ main(int argc, char **argv) key = mntopts = rounds = saltopt = NULL; action = VND_CONFIG; - while ((ch = getopt(argc, argv, "ckK:lo:S:t:uv")) != -1) { + while ((ch = getopt(argc, argv, "ckK:lo:S:t:uv:f")) != -1) { switch (ch) { case 'c': opt_c = 1; @@ -103,6 +105,9 @@ main(int argc, char **argv) case 'l': opt_l = 1; break; + case 'f': + opt_f = 1; + break; case 'o': mntopts = optarg; break; @@ -133,6 +138,8 @@ main(int argc, char **argv) if (opt_l) action = VND_GET; + else if (opt_f) + action = VND_FIND; else if (opt_u) action = VND_UNCONFIG; else @@ -173,6 +180,8 @@ main(int argc, char **argv) rv = config(argv[0], NULL, action, NULL, NULL, 0); else if (action == VND_GET) rv = getinfo(argc ? argv[0] : NULL); + else if (action == VND_FIND) + rv = findfirst(); else usage(); @@ -290,6 +299,35 @@ query: close(vd); return (0); +} + +int +findfirst(void) +{ + char *vname = DEFAULT_VND; + int vd; + struct vnd_user vnu; + + vd = opendev((char *)vname, O_RDONLY, OPENDEV_PART, NULL); + if (vd < 0) + err(1, "open: %s", vname); + + vnu.vnu_unit = -1; + +query: + if (ioctl(vd, VNDIOCGET, &vnu) == -1) + err(1, "ioctl: %s", vname); + + if (!vnu.vnu_ino) + fprintf(stdout, "vnd%d\n", vnu.vnu_unit); + else { + vnu.vnu_unit++; + goto query; + } + + close(vd); + + return (0); } int (cvs diff is dumb)
Re: Setting rtable 0 from >1 with ping et al
On 18/03/2017 08:21, Florian Obser wrote: On Thu, Mar 16, 2017 at 07:59:44PM +, Joe Holden wrote: On 09/03/2017 23:35, Joe Holden wrote: On 09/03/2017 23:02, Joe Holden wrote: Hi, So - it seems that pledge will deny a change of rtable to 0 when using level SOL_SOCKET and the current rtable is >0, so eg if you're in table 1 and you do ping -V0 it will fail. Can anyone shed any light on why this is restricted? Especially since the same can be achieved with route -T0 exec Thanks! Actually, just realised why it doesn't work - it drops privs before setting rtable, nevermind. Something like: Index: sbin/ping/ping.c === RCS file: /cvs/src/sbin/ping/ping.c,v retrieving revision 1.218 diff -u -p -r1.218 ping.c --- sbin/ping/ping.c22 Feb 2017 13:43:35 - 1.218 +++ sbin/ping/ping.c16 Mar 2017 19:58:28 - @@ -283,10 +283,6 @@ main(int argc, char *argv[]) uid = getuid(); gid = getgid(); } - if (setgroups(1, &gid) || - setresgid(gid, gid, gid) || - setresuid(uid, uid, uid)) - err(1, "unable to revoke privs"); preload = 0; datap = &outpack[ECHOLEN + ECHOTMLEN]; @@ -427,6 +423,11 @@ main(int argc, char *argv[]) usage(); } } + + if (setgroups(1, &gid) || + setresgid(gid, gid, gid) || + setresuid(uid, uid, uid)) + err(1, "unable to revoke privs"); argc -= optind; argv += optind; perhaps, but haven't closely looked if there is any scope for escalation or anything during option parsing This seems... unwise. ping(8) very carefuly tries to do as little as possible while still having priviledges, i.e. only create raw sockets. That being said, I don't understand the problem. 1) How do you end up in rtable 1 and need to do something in table 0? In this instance, the management (sshd, et al) rtable isn't 0 (for a few reasons, mostly things that can't operate on an rtable other than 0) 2) you say route -T0 exec works, I don't think so: $ route -T1 exec /bin/sh $ route -T0 exec ping 8.8.8.8 route: setrtable: Operation not permitted setrtable(2) has this: ERRORS The call succeeds unless: [...] [EPERM]The user is not the superuser and the routing table of the calling process is already set to a non-zero value. So this is intentional behaviour. Setting rtable implies being uid 0, so not really - but: # ping -V0 127.0.0.1 ping: setsockopt SO_RTABLE: Operation not permitted # route -T0 exec ping 127.0.0.1 PING 127.0.0.1 (127.0.0.1): 56 data bytes 64 bytes from 127.0.0.1: icmp_seq=0 ttl=255 time=0.948 ms from an rtable other than 0, because the route doesn't use SO_RTABLE so doesn't fail
Re: Setting rtable 0 from >1 with ping et al
On 09/03/2017 23:35, Joe Holden wrote: On 09/03/2017 23:02, Joe Holden wrote: Hi, So - it seems that pledge will deny a change of rtable to 0 when using level SOL_SOCKET and the current rtable is >0, so eg if you're in table 1 and you do ping -V0 it will fail. Can anyone shed any light on why this is restricted? Especially since the same can be achieved with route -T0 exec Thanks! Actually, just realised why it doesn't work - it drops privs before setting rtable, nevermind. Something like: Index: sbin/ping/ping.c === RCS file: /cvs/src/sbin/ping/ping.c,v retrieving revision 1.218 diff -u -p -r1.218 ping.c --- sbin/ping/ping.c22 Feb 2017 13:43:35 - 1.218 +++ sbin/ping/ping.c16 Mar 2017 19:58:28 - @@ -283,10 +283,6 @@ main(int argc, char *argv[]) uid = getuid(); gid = getgid(); } - if (setgroups(1, &gid) || - setresgid(gid, gid, gid) || - setresuid(uid, uid, uid)) - err(1, "unable to revoke privs"); preload = 0; datap = &outpack[ECHOLEN + ECHOTMLEN]; @@ -427,6 +423,11 @@ main(int argc, char *argv[]) usage(); } } + + if (setgroups(1, &gid) || + setresgid(gid, gid, gid) || + setresuid(uid, uid, uid)) + err(1, "unable to revoke privs"); argc -= optind; argv += optind; perhaps, but haven't closely looked if there is any scope for escalation or anything during option parsing
Re: Setting rtable 0 from >1 with ping et al
On 09/03/2017 23:02, Joe Holden wrote: Hi, So - it seems that pledge will deny a change of rtable to 0 when using level SOL_SOCKET and the current rtable is >0, so eg if you're in table 1 and you do ping -V0 it will fail. Can anyone shed any light on why this is restricted? Especially since the same can be achieved with route -T0 exec Thanks! Actually, just realised why it doesn't work - it drops privs before setting rtable, nevermind.
Setting rtable 0 from >1 with ping et al
Hi, So - it seems that pledge will deny a change of rtable to 0 when using level SOL_SOCKET and the current rtable is >0, so eg if you're in table 1 and you do ping -V0 it will fail. Can anyone shed any light on why this is restricted? Especially since the same can be achieved with route -T0 exec Thanks!
Re: Bizarre arp entry corruption
On 09/03/2017 11:51, Martin Pieuchot wrote: On 07/03/17(Tue) 19:38, Joe Holden wrote: On 12/12/2016 16:55, Joe Holden wrote: On 12/12/2016 10:27, Martin Pieuchot wrote: On 11/12/16(Sun) 00:50, Joe Holden wrote: On 10/12/2016 08:43, Mihai Popescu wrote: seeing some bizarre behaviour on one box, on one specific interface: Hello, This looks like some stupid TV game, where contesters are given some clues from time to time and they have to guess what is the real shit. Do post your FULL dmesg and configurations for network if you really want someone to even think at your issue. Isn't that obvious? Bye! Appreciate the useless response (but still better than nothing!), the affected box has since been reverted to older snapshot and thus no more debugging can be done - someone else will have to do it. I'd appreciate to see the output of 'netstat -rnf inet' when it is relevant. Without that information it's hard to understand. But there's a bug somewhere, it has to be fixed. Not that dmesg is even relevant since it is a userland bug not a kernel problem but anyway: It's a kernel problem. I'll see if I can recreate it but I'm not holding my breath - it only breaks once BGP loaded the table which leads me to thing it is actually bgpd that is updating the llinfo with bogus info and even though I have a feed in my lab it doesn't do the same thing. Ok so, inadvertantly recreated this (pretty much exactly the same) issue on a lab/test setup: For the purposes of debug, ignore the fact that the interfaces are tap interfaces, they're still emulated ethernet... Wall of text incoming, various info... box#1: tap1: flags=8843 mtu 1500 lladdr fe:e1:ba:d1:be:f3 index 7 priority 0 llprio 3 groups: tap status: active inet 172.20.230.72 netmask 0xfffe box#2: tap1: flags=8843 mtu 1500 lladdr fe:e1:ba:d1:cf:92 index 7 priority 0 llprio 3 groups: tap status: active inet 172.20.230.73 netmask 0xfffe All is fine after starting ospfd, but as soon as I start bgpd, box#2 shows the following: Host Ethernet AddressNetif Expire Flags 172.20.230.7200:00:00:00:20:12 ? 12m30s # route -n get 172.20.230.72 route to: 172.20.230.72 destination: 172.20.230.72 mask: 255.255.255.255 interface: tap1 if address: 172.20.230.73 priority: 3 () flags: use mtuexpire 20 0 702 flags destination gateway lpref med aspath origin IS*> 172.20.230.72/31 172.20.230.64 200 0 i .64 is the loopback on one of its connected boxes that doesn't have broken entries tcpdump looks ok, afterwards: 19:14:23.723876 arp who-has 172.20.230.72 tell 172.20.230.73 19:14:23.901883 arp reply 172.20.230.72 is-at fe:e1:ba:d1:be:f3 19:14:24.022948 arp who-has 172.20.230.72 tell 172.20.230.73 19:14:24.201095 arp reply 172.20.230.72 is-at fe:e1:ba:d1:be:f3 but the correct entry is never installed, after I delete the broken arp entry it never readds a new one. This only happens with redist connected as far as I can tell, but bgpd probably shouldn't be able to mangle arp entries and prevent the correct one being added. Here's the fix. Index: net/rtsock.c === RCS file: /cvs/src/sys/net/rtsock.c,v retrieving revision 1.232 diff -u -p -r1.232 rtsock.c --- net/rtsock.c7 Mar 2017 09:23:27 - 1.232 +++ net/rtsock.c8 Mar 2017 16:06:22 - @@ -895,10 +895,22 @@ rtm_output(struct rt_msghdr *rtm, struct } } change: - if (info->rti_info[RTAX_GATEWAY] != NULL && (error = - rt_setgate(rt, info->rti_info[RTAX_GATEWAY], - tableid))) - break; + if (info->rti_info[RTAX_GATEWAY] != NULL) { + /* +* When updating the gateway, make sure it's +* valid. +*/ + if (!newgate && rt->rt_gateway->sa_family != + info->rti_info[RTAX_GATEWAY]->sa_family) { + error = EINVAL; + break; + } + + error = rt_setgate(rt, + info->rti_info[RTAX_GATEWAY], tableid); + if (error) + break; + } #ifdef MPLS if ((rtm->rtm_flags & RTF_MPLS) && info->rti_info[RTAX_SRC] != NULL) { Looking good - have tried to break it since and it's fine, thanks for your help! Will this make it into 6.1?
Re: Bizarre arp entry corruption
On 12/12/2016 16:55, Joe Holden wrote: On 12/12/2016 10:27, Martin Pieuchot wrote: On 11/12/16(Sun) 00:50, Joe Holden wrote: On 10/12/2016 08:43, Mihai Popescu wrote: seeing some bizarre behaviour on one box, on one specific interface: Hello, This looks like some stupid TV game, where contesters are given some clues from time to time and they have to guess what is the real shit. Do post your FULL dmesg and configurations for network if you really want someone to even think at your issue. Isn't that obvious? Bye! Appreciate the useless response (but still better than nothing!), the affected box has since been reverted to older snapshot and thus no more debugging can be done - someone else will have to do it. I'd appreciate to see the output of 'netstat -rnf inet' when it is relevant. Without that information it's hard to understand. But there's a bug somewhere, it has to be fixed. Not that dmesg is even relevant since it is a userland bug not a kernel problem but anyway: It's a kernel problem. I'll see if I can recreate it but I'm not holding my breath - it only breaks once BGP loaded the table which leads me to thing it is actually bgpd that is updating the llinfo with bogus info and even though I have a feed in my lab it doesn't do the same thing. Ok so, inadvertantly recreated this (pretty much exactly the same) issue on a lab/test setup: For the purposes of debug, ignore the fact that the interfaces are tap interfaces, they're still emulated ethernet... Wall of text incoming, various info... box#1: tap1: flags=8843 mtu 1500 lladdr fe:e1:ba:d1:be:f3 index 7 priority 0 llprio 3 groups: tap status: active inet 172.20.230.72 netmask 0xfffe box#2: tap1: flags=8843 mtu 1500 lladdr fe:e1:ba:d1:cf:92 index 7 priority 0 llprio 3 groups: tap status: active inet 172.20.230.73 netmask 0xfffe All is fine after starting ospfd, but as soon as I start bgpd, box#2 shows the following: Host Ethernet AddressNetif Expire Flags 172.20.230.7200:00:00:00:20:12 ? 12m30s # route -n get 172.20.230.72 route to: 172.20.230.72 destination: 172.20.230.72 mask: 255.255.255.255 interface: tap1 if address: 172.20.230.73 priority: 3 () flags: use mtuexpire 20 0 702 flags destination gateway lpref med aspath origin IS*> 172.20.230.72/31 172.20.230.64 200 0 i .64 is the loopback on one of its connected boxes that doesn't have broken entries tcpdump looks ok, afterwards: 19:14:23.723876 arp who-has 172.20.230.72 tell 172.20.230.73 19:14:23.901883 arp reply 172.20.230.72 is-at fe:e1:ba:d1:be:f3 19:14:24.022948 arp who-has 172.20.230.72 tell 172.20.230.73 19:14:24.201095 arp reply 172.20.230.72 is-at fe:e1:ba:d1:be:f3 but the correct entry is never installed, after I delete the broken arp entry it never readds a new one. This only happens with redist connected as far as I can tell, but bgpd probably shouldn't be able to mangle arp entries and prevent the correct one being added. If someone thinks they can diag/fix it then hit me up off-list and I can fire over ssh details. Thanks
Re: Bizarre arp entry corruption
On 12/12/2016 10:27, Martin Pieuchot wrote: On 11/12/16(Sun) 00:50, Joe Holden wrote: On 10/12/2016 08:43, Mihai Popescu wrote: seeing some bizarre behaviour on one box, on one specific interface: Hello, This looks like some stupid TV game, where contesters are given some clues from time to time and they have to guess what is the real shit. Do post your FULL dmesg and configurations for network if you really want someone to even think at your issue. Isn't that obvious? Bye! Appreciate the useless response (but still better than nothing!), the affected box has since been reverted to older snapshot and thus no more debugging can be done - someone else will have to do it. I'd appreciate to see the output of 'netstat -rnf inet' when it is relevant. Without that information it's hard to understand. But there's a bug somewhere, it has to be fixed. Not that dmesg is even relevant since it is a userland bug not a kernel problem but anyway: It's a kernel problem. I'll see if I can recreate it but I'm not holding my breath - it only breaks once BGP loaded the table which leads me to thing it is actually bgpd that is updating the llinfo with bogus info and even though I have a feed in my lab it doesn't do the same thing.
Re: Bizarre arp entry corruption
On 10/12/2016 08:43, Mihai Popescu wrote: seeing some bizarre behaviour on one box, on one specific interface: Hello, This looks like some stupid TV game, where contesters are given some clues from time to time and they have to guess what is the real shit. Do post your FULL dmesg and configurations for network if you really want someone to even think at your issue. Isn't that obvious? Bye! Appreciate the useless response (but still better than nothing!), the affected box has since been reverted to older snapshot and thus no more debugging can be done - someone else will have to do it. Not that dmesg is even relevant since it is a userland bug not a kernel problem but anyway: OpenBSD 6.0-current (GENERIC.MP) #19: Wed Dec 7 12:07:13 MST 2016 bu...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 4273471488 (4075MB) avail mem = 4139397120 (3947MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.6 @ 0x9d000 (74 entries) bios0: vendor American Megatrends Inc. version "1ADQW068" date 11/16/2010 bios0: Sun Microsystems SUN FIRE X4150 acpi0 at bios0: rev 2 acpi0: sleep states S0 S1 S5 acpi0: tables DSDT FACP APIC SPCR MCFG SSDT OEMB HPET EINJ BERT ERST HEST acpi0: wakeup devices SPE4(S1) SPE2(S1) SPE1(S1) P8PC(S1) P0P1(S1) UAR1(S1) P0P5(S1) P0P6(S1) P0P7(S1) NPE4(S1) NPE5(S1) NPE6(S1) NPE7(S1) USB0(S1) USB1(S1) USB2(S1) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Xeon(R) CPU E5450 @ 3.00GHz, 4189.89 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,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,DCA,SSE4.1,XSAVE,LONG,LAHF,PERF,SENSOR cpu0: 6MB 64b/line 16-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 7 var ranges, 88 fixed ranges cpu0: apic clock running at 332MHz cpu0: mwait min=64, max=64, C-substates=0.2.2.2, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Xeon(R) CPU E5450 @ 3.00GHz, 2992.51 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,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,DCA,SSE4.1,XSAVE,LONG,LAHF,PERF,SENSOR cpu1: 6MB 64b/line 16-way L2 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 2 (application processor) cpu2: Intel(R) Xeon(R) CPU E5450 @ 3.00GHz, 2992.51 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,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,DCA,SSE4.1,XSAVE,LONG,LAHF,PERF,SENSOR cpu2: 6MB 64b/line 16-way L2 cache cpu2: smt 0, core 2, package 0 cpu3 at mainbus0: apid 3 (application processor) cpu3: Intel(R) Xeon(R) CPU E5450 @ 3.00GHz, 2992.52 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,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,DCA,SSE4.1,XSAVE,LONG,LAHF,PERF,SENSOR cpu3: 6MB 64b/line 16-way L2 cache cpu3: smt 0, core 3, package 0 ioapic0 at mainbus0: apid 4 pa 0xfec0, version 20, 24 pins ioapic1 at mainbus0: apid 5 pa 0xfec8, version 20, 24 pins acpimcfg0 at acpi0 addr 0xe000, bus 0-255 acpihpet0 at acpi0: 14318179 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 1 (NPES) acpiprt2 at acpi0: bus 2 (SPE4) acpiprt3 at acpi0: bus -1 (SPE2) acpiprt4 at acpi0: bus 3 (SPE1) acpiprt5 at acpi0: bus 4 (P8PC) acpiprt6 at acpi0: bus 15 (P0P1) acpiprt7 at acpi0: bus -1 (P0P5) acpiprt8 at acpi0: bus -1 (P0P6) acpiprt9 at acpi0: bus -1 (P0P7) acpiprt10 at acpi0: bus 7 (NPE4) acpiprt11 at acpi0: bus 11 (NPE5) acpiprt12 at acpi0: bus 12 (NPE6) acpiprt13 at acpi0: bus 13 (NPE7) acpiprt14 at acpi0: bus 14 (P0P4) acpiprt15 at acpi0: bus -1 (BR1E) acpicpu0 at acpi0: C1(@1 halt!) acpicpu1 at acpi0: C1(@1 halt!) acpicpu2 at acpi0: C1(@1 halt!) acpicpu3 at acpi0: C1(@1 halt!) "PNP0501" at acpi0 not configured "PNP0501" at acpi0 not configured acpibtn0 at acpi0: PWRB "IPI0001" at acpi0 not configured ipmi at mainbus0 not configured pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "Intel 5000P Host" rev 0xb1 ppb0 at pci0 dev 2 function 0 "Intel 5000 PCIE" rev 0xb1 pci1 at ppb0 bus 1 ppb1 at pci1 dev 0 function 0 "Intel 6321ESB PCIE" rev 0x01 pci2 at ppb1 bus 2 ppb2 at pci2 dev 0 function 0 "Intel 6321ESB PCIE" rev 0x01 pci3 at ppb2 bus 3 ppb3 at pci2 dev 2 function 0 "Intel 6321ESB PCIE" rev 0x01 pci4 at ppb3 bus 4 em0 at pci4 dev 0 function 0 "Intel 80003ES2" rev 0x01: msi, address 00:23:8b:57:b4:9e em1 at pci4 dev 0 function 1 "Intel 80003ES2" rev 0x01: msi, address 00:23:8b:57:b4:9f ppb4 at pci1 dev 0 function 3 "Intel 6321ESB PCIE-PCIX" rev 0x01 pci5 at ppb4 bus 5 ppb5 at pci0 dev 3 function 0 "Intel 5000 PCIE" rev 0xb1 pci6 at ppb5 bus 6
Re: Bizarre arp entry corruption
On 08/12/2016 14:35, Joe Holden wrote: On 08/12/2016 13:56, Joe Holden wrote: Hi guys, I've just updated a couple of boxes to the Dec 7th snapshot and I'm seeing some bizarre behaviour on one box, on one specific interface: The box in question is an OSPF and BGP speaker, and the following happens when booted: After OSPF and BGP tables load, a couple of minutes later the following appear: Dec 8 06:33:03 edge-pe-2 /bsd: arp_rtrequest: bad gateway value: em0 Dec 8 06:33:03 edge-pe-2 last message repeated 2 times Dec 8 06:33:04 edge-pe-2 /bsd: arpresolve: X.X.X.X: incorrect arp information Then some seconds later: Dec 8 06:41:41 edge-pe-2 /bsd: arpresolve: unresolved and rt_expire == 0 At this point the arp entry for the neighbour in question has been updated so that the lladdr is all zeros and the interface is simply '?' according to arp -n. The box it is paired with that has a pretty much identical config doesn't exhibit the same problem and this only occurs on the single em0 interface (the box has about 6 active in total, mix of em and ix). I should clarify that this isn't CARP, but rather the box it is directly connected to. OpenBSD 6.0-current (GENERIC.MP) #19: Wed Dec 7 12:07:13 MST 2016 bu...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP I don't see any odd behaviour on the wire, according to pcap the who-has and associated reply is seen once as expected with the correct lladdr, but at some point it gets overwritten with the above. Previous kernel was about 2 months old which leaves a large number of commits to check through - I can't see anything that might cause this from a quick look though so I was hoping someone might have an idea. For now i've had to add a static arp entry with permanent to prevent it misbehaving but that has stopped working at least once so far. I also have limited debug ability as the box is part of a live network and obviously it causes disruption, and I can't recreate it in a lab with identical configurations. Any pointers appreciated! Cheers Actually looks like it breaks when BGP comes up, a route -nvd get looks ok, but what else should I be checking? After it breaks it doesn't seem to want to do any arp resolution on the interface until it I do down/up...
Re: Bizarre arp entry corruption
On 08/12/2016 13:56, Joe Holden wrote: Hi guys, I've just updated a couple of boxes to the Dec 7th snapshot and I'm seeing some bizarre behaviour on one box, on one specific interface: The box in question is an OSPF and BGP speaker, and the following happens when booted: After OSPF and BGP tables load, a couple of minutes later the following appear: Dec 8 06:33:03 edge-pe-2 /bsd: arp_rtrequest: bad gateway value: em0 Dec 8 06:33:03 edge-pe-2 last message repeated 2 times Dec 8 06:33:04 edge-pe-2 /bsd: arpresolve: X.X.X.X: incorrect arp information Then some seconds later: Dec 8 06:41:41 edge-pe-2 /bsd: arpresolve: unresolved and rt_expire == 0 At this point the arp entry for the neighbour in question has been updated so that the lladdr is all zeros and the interface is simply '?' according to arp -n. The box it is paired with that has a pretty much identical config doesn't exhibit the same problem and this only occurs on the single em0 interface (the box has about 6 active in total, mix of em and ix). I should clarify that this isn't CARP, but rather the box it is directly connected to. OpenBSD 6.0-current (GENERIC.MP) #19: Wed Dec 7 12:07:13 MST 2016 bu...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP I don't see any odd behaviour on the wire, according to pcap the who-has and associated reply is seen once as expected with the correct lladdr, but at some point it gets overwritten with the above. Previous kernel was about 2 months old which leaves a large number of commits to check through - I can't see anything that might cause this from a quick look though so I was hoping someone might have an idea. For now i've had to add a static arp entry with permanent to prevent it misbehaving but that has stopped working at least once so far. I also have limited debug ability as the box is part of a live network and obviously it causes disruption, and I can't recreate it in a lab with identical configurations. Any pointers appreciated! Cheers
Bizarre arp entry corruption
Hi guys, I've just updated a couple of boxes to the Dec 7th snapshot and I'm seeing some bizarre behaviour on one box, on one specific interface: The box in question is an OSPF and BGP speaker, and the following happens when booted: After OSPF and BGP tables load, a couple of minutes later the following appear: Dec 8 06:33:03 edge-pe-2 /bsd: arp_rtrequest: bad gateway value: em0 Dec 8 06:33:03 edge-pe-2 last message repeated 2 times Dec 8 06:33:04 edge-pe-2 /bsd: arpresolve: X.X.X.X: incorrect arp information Then some seconds later: Dec 8 06:41:41 edge-pe-2 /bsd: arpresolve: unresolved and rt_expire == 0 At this point the arp entry for the neighbour in question has been updated so that the lladdr is all zeros and the interface is simply '?' according to arp -n. The box it is paired with that has a pretty much identical config doesn't exhibit the same problem and this only occurs on the single em0 interface (the box has about 6 active in total, mix of em and ix). OpenBSD 6.0-current (GENERIC.MP) #19: Wed Dec 7 12:07:13 MST 2016 bu...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP I don't see any odd behaviour on the wire, according to pcap the who-has and associated reply is seen once as expected with the correct lladdr, but at some point it gets overwritten with the above. Previous kernel was about 2 months old which leaves a large number of commits to check through - I can't see anything that might cause this from a quick look though so I was hoping someone might have an idea. For now i've had to add a static arp entry with permanent to prevent it misbehaving but that has stopped working at least once so far. I also have limited debug ability as the box is part of a live network and obviously it causes disruption, and I can't recreate it in a lab with identical configurations. Any pointers appreciated! Cheers
Re: High loadavg on recent snapshots?
On 02/12/2016 12:45, Otto Moerbeek wrote: On Fri, Dec 02, 2016 at 09:55:23AM +, Joe Holden wrote: Hi guys, Is anyone else seeing abnormally high load averages on recent snapshots? Seeing load reported as ~1 on idle machines (both VM and physical, amd64 and octeon): 9:48AM up 34 mins, 1 user, load averages: 1.21, 1.13, 1.01 (octeon snapshot as of 30th Nov) This is known and due to a different way some kernel threads operate. Maybe a bit unexpected, but not harmful, the processor(s) as seen in top(1) should be idle most if the time. -Otto Yeah - not concerned just a huge increase in idle average that doesn't correlate to any activity compared to snapshots from a week or so ago Another example on KVM guest: USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND root 1 0.0 0.1 416 496 ?? Is 6:54PM0:01.23 /sbin/init root 50624 0.0 0.1 632 536 ?? Is 6:55PM0:00.38 dhclient: vio2 [priv] (dhclient) _dhcp42339 0.0 0.1 736 696 ?? Isp6:55PM0:00.19 dhclient: vio2 (dhclient) root 26736 0.0 0.4 364 1976 ?? Isp6:55PM0:00.27 syslogd: [priv] (syslogd) _syslogd 7398 0.0 0.3 968 1488 ?? Sp 6:55PM0:00.68 /usr/sbin/syslogd root 64373 0.0 0.3 872 1452 ?? Is 6:55PM0:00.12 /usr/sbin/sshd root 38751 0.0 0.2 676 1188 ?? Isp6:55PM0:00.35 /usr/sbin/cron root 80570 0.0 0.7 980 3396 ?? Ss 9:20PM0:54.17 sshd: root@ttyp0 (sshd) root 30271 0.0 0.1 612 744 p0 Ssp9:20PM0:00.34 -ksh (ksh) root 84509 0.0 0.1 356 412 p0 R+p/0 4:03AM0:00.00 ps -auxw root 99508 0.0 0.1 608 736 00 Is+p 6:55PM0:02.80 -ksh (ksh) 4:03AM up 9:09, 2 users, load averages: 1.26, 1.18, 1.11 (amd64 snapshot as of 27th Nov) Thanks
High loadavg on recent snapshots?
Hi guys, Is anyone else seeing abnormally high load averages on recent snapshots? Seeing load reported as ~1 on idle machines (both VM and physical, amd64 and octeon): 9:48AM up 34 mins, 1 user, load averages: 1.21, 1.13, 1.01 (octeon snapshot as of 30th Nov) Another example on KVM guest: USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND root 1 0.0 0.1 416 496 ?? Is 6:54PM0:01.23 /sbin/init root 50624 0.0 0.1 632 536 ?? Is 6:55PM0:00.38 dhclient: vio2 [priv] (dhclient) _dhcp42339 0.0 0.1 736 696 ?? Isp6:55PM0:00.19 dhclient: vio2 (dhclient) root 26736 0.0 0.4 364 1976 ?? Isp6:55PM0:00.27 syslogd: [priv] (syslogd) _syslogd 7398 0.0 0.3 968 1488 ?? Sp 6:55PM0:00.68 /usr/sbin/syslogd root 64373 0.0 0.3 872 1452 ?? Is 6:55PM0:00.12 /usr/sbin/sshd root 38751 0.0 0.2 676 1188 ?? Isp6:55PM0:00.35 /usr/sbin/cron root 80570 0.0 0.7 980 3396 ?? Ss 9:20PM0:54.17 sshd: root@ttyp0 (sshd) root 30271 0.0 0.1 612 744 p0 Ssp9:20PM0:00.34 -ksh (ksh) root 84509 0.0 0.1 356 412 p0 R+p/0 4:03AM0:00.00 ps -auxw root 99508 0.0 0.1 608 736 00 Is+p 6:55PM0:02.80 -ksh (ksh) 4:03AM up 9:09, 2 users, load averages: 1.26, 1.18, 1.11 (amd64 snapshot as of 27th Nov) Thanks
Re: PPPoE "ip unnumbered"
On 15/01/2014 12:58, Giancarlo Razzolini wrote: Em 15-01-2014 06:20, Martijn Rijkeboer escreveu: Is it possible to create an IP unnumbered setup with PPPoE on OpenBSD? And what the heck you mean by "unnumbered"? If it is wildcard address, and by it, that the pppoe access concentrator provides the ip addres, then yes, it works. For us to help you we need a little more than this. Sorry for not providing enough information. "IP unnumbered" seems to mean that both the pppoe physical device and the pppoe device don't have an IP-address. Only the internal interface has an IP-address. The following is a Cisco configuration that shows such a configuration. interface FastEthernet0/0 description LAN klant ip address 123.123.123.1 255.255.255.128 duplex auto speed auto no keepalive ! interface FastEthernet0/1 description WAN no ip address duplex full speed 100 pppoe enable pppoe-client dial-pool-number 1 ! interface Dialer0 ip unnumbered FastEthernet0/0 encapsulation ppp ip tcp adjust-mss 1452 dialer pool 1 dialer idle-time dialer-group 1 no cdp enable ppp authentication pap callin ppp pap sent-username @solcon.net password ! ip route 0.0.0.0 0.0.0.0 Dialer0 permanent Kind regards, Martijn Rijkeboer My setup is exactly like this. The physical interface do not have an ip address and the pppoe also do not have an ip address until the concentrator provides one: inet 0.0.0.0 255.255.255.255 NONE \ pppoedev authproto pap \ authname 'user' authkey 'pass' up dest 0.0.0.1 !/sbin/route add default -ifp pppoe0 0.0.0.1 The point behind unnumbered is that the ppp interface *doesn't* have an IP, usually this is when the WAN address is inside a routed subnet. Since PPP is layer2, IP addresses aren't actually needed.
Re: Installation on EdgeRouter Lite
That is the EJTAG port (debug.. single stepping the cpu etc) AFAIK (haven't tested yet as I don't have the appropriate kit handy) > -Original Message- > From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On > Behalf Of Mihai Popescu > Sent: 27 August 2013 18:12 > To: misc@openbsd.org > Subject: Re: Installation on EdgeRouter Lite > > Folks, it say that "there is no USB support yet, which means that there is no > storage". "No onboard CompactFash" means that this model is not using > compact flash. > > If you look at the bottom link, you can see that this model storage is an USB > stick mounted on the board. Please look at the pictures, top layer, to the left. > So this is clear, no USB support - no way to access the storage, yet. I am > interested in this model or maybe anothe one with wireless. It is interesting > what is that not populated slot , on the left. > > http://www.smallnetbuilder.com/images/stories/lansrouters/ubiquiti_erl/u > biquiti_erl_board_top.jpg
Re: Installation on EdgeRouter Lite
On 27/08/2013 14:08, Joe Holden wrote: On 26/08/2013 18:34, Radio młodych bandytów wrote: Hello, I'm just reading through Octeon installation instructions: http://ftp.openbsd.org/pub/OpenBSD/snapshots/octeon/INSTALL.octeon What caught my attention is a statement: "There is no USB support yet, which means that there is no storage (no onboard CompactFlash), and Ethernet isn't supported either." If neither storage nor network work, how is one supposed to install the OS? Ethernet works most of the time, depending on if it wants to do rarp/bootp when you boot... you can now set the rootdev on the uboot line, eg cnmac0 (port 1) Ugh, that should have been bootdev
Re: Installation on EdgeRouter Lite
On 26/08/2013 18:34, Radio młodych bandytów wrote: Hello, I'm just reading through Octeon installation instructions: http://ftp.openbsd.org/pub/OpenBSD/snapshots/octeon/INSTALL.octeon What caught my attention is a statement: "There is no USB support yet, which means that there is no storage (no onboard CompactFlash), and Ethernet isn't supported either." If neither storage nor network work, how is one supposed to install the OS? Ethernet works most of the time, depending on if it wants to do rarp/bootp when you boot... you can now set the rootdev on the uboot line, eg cnmac0 (port 1)
Re: OpenBSD Doesn't Support 64-Bit Intel
carlos albino garcia grijalba wrote: IA64 its the name of the arch for the processor created originali by AMD and INTEL copied so support for AMD64 mean INTEL64 too! dont complain if u really dont read all of the info (i understand now why my questions are not answered LOL) No. If you're going to respond, at least get it right... IA64 *isn't* x86. Date: Mon, 1 Jul 2013 00:06:05 -0400 Subject: OpenBSD Doesn't Support 64-Bit Intel From: jash.seffer...@gmail.com To: misc@openbsd.org; s...@openbsd.org Hi guys. I’m a civil engineer by day and use OpenBSD at night, but I’m trying to do high-end CAD on my home PC and OpenBSD doesn’t support 64-bit Intel chips. Don't believe me? It says very clearly at the OpenBSD/amd64 page: “All versions of the AMD Athlon 64 processors and their clones are supported.” But does not mention or list any Intel chips. Not one. Wtf? I can do CAD on my i7-980X under Windows 7 SP 1, but I’d rather use something secure and responsibly coded like OpenBSD. Except that I can't. Why for the life of this platform are we not on the only future direction for the platform? And I mean that literally. Neither AMD nor Intel sells 32-bit chips anymore. If OpenBSD remains stuck at 32 bits, people will stop using and developing for it. Who makes the decision to keep OpenBSD off of 64-bit Intel? And why the hell are they doing so? -jash
Re: Option to allow directly connected ebgp nexthops?
Christopher J. Umina wrote: Hello, I'm hoping Claudio or someone can take a quick look at this: I'm testing a simple hub/spoke VPN configuration using vtun (tun interfaces) for 'last mile' between sites. Over the tunnels, I would like to run EBGP sessions using OpenBGPd (on FreeBSD 9.1) on both ends, but I'm running into some trouble. I'm trying to do this as an extremely cheap solution to use in a very small scale, so bgpd will be listening on the tunnel interface local address rather than a loopback address. This is true at both ends of the configuration. The tunnel interfaces are configured as such and work properly with the hub router IP 10.1.254.1 and the spoke router IP 10.1.254.2 able to ping each other and all that. The BGP configuration is fairly standard, I can include it if needed later, but I think it's probably irrelevant. The hub router is running AS 64598 and the spoke running AS 64593 and each are listening on their tunnel IPs, the sessions come up and everything is fine on the spoke router. After the session comes up, the hub router logs: May 22 18:13:06 ar01 bgpd[792]: nexthop 10.1.254.2 now invalid: directly connected FreeBSD != OpenBSD, there are huge differences in the way the routing table works, including the lack of priorities and interface route protection. The routes show up in the RIB, but never make it to the FIB, I assume because of the previous message. To add to the confusion the following output is from the hub router: # bgpctl show nexthop Flags: * = nexthop valid Nexthop Route Prio Gateway Iface 10.1.254.1 10.1.254.2 10.1.254.2/3248 connected tun100 (DOWN, active) Is that "DOWN" indicating the link state of the tunnel interface? The tunnel interface is up and operating. tun has no link state, use tap. Is this intended behavior? It appears bgpd is invalidating all routes due to a 'directly connected' nexthop. If so, would it make sense to have an option to allow directly connected nexthops? This isn't an appropriate place to ask really, post to freebsd-net. Thank you, -- Christopher J. Umina ch...@uminac.com
Re: NPPPD with intermediate LTS
YASUOKA Masahiko wrote: Hi, On Mon, 13 May 2013 15:28:38 +0100 Joe Holden wrote: YASUOKA Masahiko wrote: On Wed, 08 May 2013 12:32:16 +0100 Joe Holden wrote: YASUOKA Masahiko wrote: On Tue, 07 May 2013 22:38:46 +0100 Joe Holden wrote: 2013-05-07 22:29:03:INFO: ppp id=1 layer=chap proto=unknown Received chap packet. But chap is not started 2013-05-07 22:29:05:INFO: ppp id=1 layer=chap proto=unknown Received chap packet. But chap is not started Do you have the "dialin-proxy" message before these messages? If you have, I would like to see it. The only message ppp related prior to those is: 2013-05-08 12:21:07:INFO: l2tpd ctrl=1 call=3490 RecvICCN session_id=5644 calling_number= tx_conn_speed=1000 framing=sync 2013-05-08 12:21:07:NOTICE: l2tpd ctrl=1 call=3490 logtype=PPPBind ppp=0 Those AVPs don't seem to be requested by the LAC. 2013-05-08 12:21:07:INFO: ppp id=0 layer=base logtype=Started tunnel=L2TP_ipv4(172.16.10.57:54189) 2013-05-08 12:21:07:INFO: l2tpd ctrl=1 call=3490 SendZLB 2013-05-08 12:21:08:INFO: ppp id=0 layer=base ppp_recv_packet: Rcvd broken frame. ACFC is not accepted, but received ppp frame that has no address. 2013-05-08 12:21:08:INFO: ppp id=0 layer=chap proto=unknown Received chap packet. But chap is not started The LAC seems to be starting CHAP without LCP. The problem seems to be come from the LAC. If mpd has settings about "proxy LCP and authentication", I would like you to try them. mpd doesn't have the ability to generate Proxy auth AVPs, I currently use both mpd and others without proxied avps, afaic it isn't breaking rfc to restart lcp at every point (which is how I work things currently) npppd itself is in "Link Establishment Phase". As RFC 1661 section 3.4., | Any non-LCP packets received during this phase MUST be silently | discarded. so discarding CHAP packets from mpd should not be a problem. But npppd doesn't start LCP actively. I think this causes the problem in this case. The peer is in "Authentication Phase", it must be able to receive the LCP packets from npppd. I attached the diff which makes npppd start LCP actively. Could you try the diff? How difficult would it be to add a config option to always restart lcp, or maybe just if proxied avps aren't there? If my understanding is correct and the diff will fix the problem, it's easy. Perfect! See initial chap not started message, but then negotiation occurs as expected. Thanks --yasuoka Index: usr.sbin/npppd/npppd/lcp.c === RCS file: /cvs/openbsd/src/usr.sbin/npppd/npppd/lcp.c,v retrieving revision 1.8 diff -u -p -r1.8 lcp.c --- usr.sbin/npppd/npppd/lcp.c 18 Sep 2012 13:14:08 - 1.8 +++ usr.sbin/npppd/npppd/lcp.c 15 May 2013 02:46:28 - @@ -122,7 +122,9 @@ lcp_init(lcp *_this, npppd_ppp *ppp) _this->fsm.ppp = ppp; _this->fsm.callbacks = &lcp_callbacks; _this->fsm.protocol = PPP_PROTO_LCP; + /* _this->fsm.flags |= OPT_SILENT; +*/ _this->timerctx.ctx = _this; _this->recv_ress = 0;
Re: NPPPD with intermediate LTS
YASUOKA Masahiko wrote: On Wed, 08 May 2013 12:32:16 +0100 Joe Holden wrote: YASUOKA Masahiko wrote: On Tue, 07 May 2013 22:38:46 +0100 Joe Holden wrote: I'm testing out npppd as a termination device which is being fed from existing LACs (in this particular setup, mpd on FreeBSD) - if the LAC begins LCP to challenge the client for it's username in order to lookup the destination LNS, npppd just repeats the following until it gives up: In this case, npppd assumes the LAC is using "Proxy LCP and Authentication" AVP in RFC 2661. Is it possible to force npppd to treat it as a non-dialin tunnel? 2013-05-07 22:29:03:INFO: ppp id=1 layer=chap proto=unknown Received chap packet. But chap is not started 2013-05-07 22:29:05:INFO: ppp id=1 layer=chap proto=unknown Received chap packet. But chap is not started Do you have the "dialin-proxy" message before these messages? If you have, I would like to see it. The only message ppp related prior to those is: 2013-05-08 12:21:07:INFO: l2tpd ctrl=1 call=3490 RecvICCN session_id=5644 calling_number= tx_conn_speed=1000 framing=sync 2013-05-08 12:21:07:NOTICE: l2tpd ctrl=1 call=3490 logtype=PPPBind ppp=0 Those AVPs don't seem to be requested by the LAC. 2013-05-08 12:21:07:INFO: ppp id=0 layer=base logtype=Started tunnel=L2TP_ipv4(172.16.10.57:54189) 2013-05-08 12:21:07:INFO: l2tpd ctrl=1 call=3490 SendZLB 2013-05-08 12:21:08:INFO: ppp id=0 layer=base ppp_recv_packet: Rcvd broken frame. ACFC is not accepted, but received ppp frame that has no address. 2013-05-08 12:21:08:INFO: ppp id=0 layer=chap proto=unknown Received chap packet. But chap is not started The LAC seems to be starting CHAP without LCP. The problem seems to be come from the LAC. If mpd has settings about "proxy LCP and authentication", I would like you to try them. mpd doesn't have the ability to generate Proxy auth AVPs, I currently use both mpd and others without proxied avps, afaic it isn't breaking rfc to restart lcp at every point (which is how I work things currently) How difficult would it be to add a config option to always restart lcp, or maybe just if proxied avps aren't there? --yasuoka Thanks, Joe
Re: NPPPD with intermediate LTS
Hi, YASUOKA Masahiko wrote: Hi, On Tue, 07 May 2013 22:38:46 +0100 Joe Holden wrote: I'm testing out npppd as a termination device which is being fed from existing LACs (in this particular setup, mpd on FreeBSD) - if the LAC begins LCP to challenge the client for it's username in order to lookup the destination LNS, npppd just repeats the following until it gives up: 2013-05-07 22:29:03:INFO: ppp id=1 layer=chap proto=unknown Received chap packet. But chap is not started 2013-05-07 22:29:05:INFO: ppp id=1 layer=chap proto=unknown Received chap packet. But chap is not started Do you have the "dialin-proxy" message before these messages? If you have, I would like to see it. The only message ppp related prior to those is: 2013-05-08 12:21:07:INFO: l2tpd ctrl=1 call=3490 RecvICCN session_id=5644 calling_number= tx_conn_speed=1000 framing=sync 2013-05-08 12:21:07:NOTICE: l2tpd ctrl=1 call=3490 logtype=PPPBind ppp=0 2013-05-08 12:21:07:INFO: ppp id=0 layer=base logtype=Started tunnel=L2TP_ipv4(172.16.10.57:54189) 2013-05-08 12:21:07:INFO: l2tpd ctrl=1 call=3490 SendZLB 2013-05-08 12:21:08:INFO: ppp id=0 layer=base ppp_recv_packet: Rcvd broken frame. ACFC is not accepted, but received ppp frame that has no address. 2013-05-08 12:21:08:INFO: ppp id=0 layer=chap proto=unknown Received chap packet. But chap is not started The ACFC message appears when blindly forwarded also, but then the next message is the expected one: 2013-05-08 12:24:04:INFO: ppp id=0 layer=lcp logtype=Opened mru=1400/1480 auth=MS-CHAP-V2 magic=9d8d641c/77831e4b This is on a test setup currently, but mirrors the behaviour as it would see on a real network. If I blindly switch to npppd all is well, I've got l2tp-lcp-reneg enabled but it doesn't seem to make any difference, likewise with force. Is this known behaviour or am I missing something? Does the config l2tp-accept-dialin yes line in the `tunnel' config? I've got that in the config yes: listen on 0.0.0.0 tcp-mss-adjust yes pipex yes authentication-method pap chap mschapv2 l2tp-lcp-renegotiation yes l2tp-force-lcp-renegotiation yes l2tp-accept-dialin yes --yasuoka Thanks
NPPPD with intermediate LTS
Hi all, I'm testing out npppd as a termination device which is being fed from existing LACs (in this particular setup, mpd on FreeBSD) - if the LAC begins LCP to challenge the client for it's username in order to lookup the destination LNS, npppd just repeats the following until it gives up: 2013-05-07 22:29:03:INFO: ppp id=1 layer=chap proto=unknown Received chap packet. But chap is not started 2013-05-07 22:29:05:INFO: ppp id=1 layer=chap proto=unknown Received chap packet. But chap is not started This is on a test setup currently, but mirrors the behaviour as it would see on a real network. If I blindly switch to npppd all is well, I've got l2tp-lcp-reneg enabled but it doesn't seem to make any difference, likewise with force. Is this known behaviour or am I missing something? Cheers.