Re: 4-ports router under $150

[Joe Holden]

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

[Joe Holden]

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

[Joe Holden]

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

[Joe Holden]

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

[Joe Holden]

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

[Joe Holden]

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?)

[Joe Holden]

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?

[Joe Holden]

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?

[Joe Holden]

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

[Joe Holden]

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, ) == -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

[Joe Holden]

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, ) ||
-   setresgid(gid, gid, gid) ||
-   setresuid(uid, uid, uid))
-   err(1, "unable to revoke privs");

preload = 0;
datap = [ECHOLEN + ECHOTMLEN];
@@ -427,6 +423,11 @@ main(int argc, char *argv[])
usage();
}
}
+
+   if (setgroups(1, ) ||
+   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

[Joe Holden]

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, ) ||
-   setresgid(gid, gid, gid) ||
-   setresuid(uid, uid, uid))
-   err(1, "unable to revoke privs");

preload = 0;
datap = [ECHOLEN + ECHOTMLEN];
@@ -427,6 +423,11 @@ main(int argc, char *argv[])
usage();
}
}
+
+   if (setgroups(1, ) ||
+   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

[Joe Holden]

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

[Joe Holden]

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

[Joe Holden]

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<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> 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<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> 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: <UP,HOST,DONE,LLINFO,CLONED,CACHED>
 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_M

Re: Bizarre arp entry corruption

[Joe Holden]

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<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> 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<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> 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: <UP,HOST,DONE,LLINFO,CLONED,CACHED>
 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

[Joe Holden]

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

[Joe Holden]

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 

Re: Bizarre arp entry corruption

[Joe Holden]

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

[Joe Holden]

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

[Joe Holden]

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?

[Joe Holden]

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?

[Joe Holden]

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

[Joe Holden]

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 username@solcon.net password 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 physical_dev 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

[Joe Holden]

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: Installation on EdgeRouter Lite

[Joe Holden]

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

[Joe Holden]

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: OpenBSD Doesn't Support 64-Bit Intel

[Joe Holden]

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?

[Joe Holden]

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

[Joe Holden]

YASUOKA Masahiko wrote:

Hi,

On Mon, 13 May 2013 15:28:38 +0100
Joe Holden li...@rewt.org.uk wrote:

YASUOKA Masahiko wrote:

On Wed, 08 May 2013 12:32:16 +0100
Joe Holden li...@rewt.org.uk wrote:

YASUOKA Masahiko wrote:

On Tue, 07 May 2013 22:38:46 +0100
Joe Holden li...@rewt.org.uk 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

[Joe Holden]

YASUOKA Masahiko wrote:

On Wed, 08 May 2013 12:32:16 +0100
Joe Holden li...@rewt.org.uk wrote:

YASUOKA Masahiko wrote:

On Tue, 07 May 2013 22:38:46 +0100
Joe Holden li...@rewt.org.uk 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

[Joe Holden]

Hi,

YASUOKA Masahiko wrote:

Hi,

On Tue, 07 May 2013 22:38:46 +0100
Joe Holden li...@rewt.org.uk 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

[Joe Holden]

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.