Re: PPPoE vlan issue 6.4
Some more debugging, a lot further but still no success. I attached the DD-WRT modem directly to a computer to capture the PADI packets. Capturing from the DD-WRT modem directly, PADI packets look like the below: 22:15:54.329145 a0:63:91:47:81:07 (oui Unknown) > Broadcast, ethertype 802.1Q (0x8100), length 36: vlan 2, p 0, ethertype PPPoE D, PPPoE PADI [Service-Name] [Host-Uniq 0xEE72] 0x: 0002 8863 1109 000c 0101 0103 ...c 0x0010: 0004 ee72 ...r.. On the other end of the wire at the client the packets look like: 12:13:05.995412 a0:63:91:47:81:07 (oui Unknown) > Broadcast, ethertype PPPoE D (0x8863), length 60: PPPoE PADI [Service-Name] [Host-Uniq 0x622A] 0x: 1109 000c 0101 0103 0004 622a ..b* 0x0010: 0x0020: 838c 7a4d zM 12:13:20.277749 a0:63:91:47:81:07 (oui Unknown) > Broadcast, ethertype PPPoE D (0x8863), length 60: PPPoE PADI [Service-Name] [Host-Uniq 0xF02A] 0x: 1109 000c 0101 0103 0004 f02a ...* 0x0010: 0x0020: e929 b08f ...).. >From the above it looks like the PPPoE Discovery is not done over the vlan as >it get's stripped. I updated the /etc/hostname.pppoe0 config to change pppodev from vlan2 to em0. I then plugged the device in to the bridged modem and brought up the PPPoE interface which returned the below. I do not have IPv6 setup in my PPPoE config so it looks like the remote tries to send me a IPv6 packet which causes OpenBSD to send a terminate session response. # ifconfig pppoe0 up Feb 10 13:18:48 foo /bsd: pppoe0: lcp close(initial) Feb 10 13:18:48 foo /bsd: pppoe0: lcp open(initial) Feb 10 13:18:48 foo /bsd: pppoe0: lcp initial->starting Feb 10 13:18:48 foo /bsd: pppoe0: phase establish Feb 10 13:18:48 foo /bsd: pppoe0 (8863) state=1, session=0x0 output -> ff:ff:ff:ff:ff:ff, len=18 Feb 10 13:18:48 foo /bsd: pppoe0 (8863) state=2, session=0x0 output -> 78:da:6e:de:db:d4, len=38 Feb 10 13:18:48 foo /bsd: pppoe0: received unexpected PADO Feb 10 13:18:48 foo last message repeated 10 times Feb 10 13:18:48 foo /bsd: pppoe0: session 0xe84d connected Feb 10 13:18:48 foo /bsd: pppoe0: lcp up(starting) Feb 10 13:18:48 foo /bsd: pppoe0: lcp starting->req-sent Feb 10 13:18:48 foo /bsd: pppoe0: lcp output Feb 10 13:18:48 foo /bsd: pppoe0 (8864) state=3, session=0xe84d output -> 78:da:6e:de:db:d4, len=22 Feb 10 13:18:48 foo /bsd: pppoe0: lcp input(req-sent): Feb 10 13:18:48 foo /bsd: pppoe0: lcp parse opts: mru auth-proto magic Feb 10 13:18:48 foo /bsd: pppoe0: lcp parse opt values: mru 1492 auth-proto magic 0xb1dfb5ab send conf-ack Feb 10 13:18:48 foo /bsd: pppoe0: lcp output Feb 10 13:18:48 foo /bsd: pppoe0 (8864) state=3, session=0xe84d output -> 78:da:6e:de:db:d4, len=26 Feb 10 13:18:48 foo /bsd: pppoe0: lcp req-sent->ack-sent Feb 10 13:18:48 foo /bsd: pppoe0: lcp input(ack-sent): Feb 10 13:18:48 foo /bsd: pppoe0: lcp ack-sent->opened Feb 10 13:18:48 foo /bsd: pppoe0: lcp tlu Feb 10 13:18:48 foo /bsd: pppoe0: phase authenticate Feb 10 13:18:48 foo /bsd: pppoe0: pap output Feb 10 13:18:48 foo /bsd: pppoe0 (8864) state=3, session=0xe84d output -> 78:da:6e:de:db:d4, len=37 Feb 10 13:18:48 foo /bsd: pppoe0: pap success Feb 10 13:18:48 foo /bsd: pppoe0: phase network Feb 10 13:18:48 foo /bsd: pppoe0: ipcp open(starting) Feb 10 13:18:48 foo /bsd: pppoe0: ipv6cp_open(): no IPv6 interface Feb 10 13:18:48 foo /bsd: pppoe0: lcp close(opened) Feb 10 13:18:48 foo /bsd: pppoe0: lcp opened->closing Feb 10 13:18:48 foo /bsd: pppoe0: lcp output Feb 10 13:18:48 foo /bsd: pppoe0 (8864) state=3, session=0xe84d output -> 78:da:6e:de:db:d4, len=12 Feb 10 13:18:48 foo /bsd: pppoe0: phase terminate Feb 10 13:18:48 foo /bsd: pppoe0: lcp input(closing): Feb 10 13:18:48 foo /bsd: pppoe0: lcp closing->closed Feb 10 13:18:48 foo /bsd: pppoe0: phase dead Feb 10 13:18:48 foo /bsd: pppoe0: timeout Feb 10 13:18:48 foo /bsd: pppoe0: disconnecting Feb 10 13:18:48 foo /bsd: pppoe0: lcp down(closed) Feb 10 13:18:48 foo /bsd: pppoe0: lcp closed->initial Feb 10 13:18:48 foo /bsd: pppoe0: Down event (carrier loss), taking interface down. Looking at the below packet dump it looks to go through the PPPoE doing auth etc but then terminates at the end. 12:47:39.116857 a0:63:91:47:81:07 Broadcast 8863 32: PPPoE-Discovery code Initiation, version 1, type 1, id 0x, length 12 tag Service-Name, length 0 tag Host-Uniq, length 4 M\014\216| : a063 9147 8107 8863 1109 ...c.G...c.. 0010: 000c 0101 0103 0004 4d0c 8e7c M..| 12:47:39.123577 a4:6c:2a:25:7d:d4 a0:63:91:47:81:07 8863 99: PPPoE-Discovery code Offer, version 1, type 1, id 0x,
Re: gdb: DW_TAG_ (abbrev = 85, offset = 20161909)
Claus Assmann wrote: > Any suggestion how I can debug that program? (it's huge and written > in C++ with which I am not familiar anyway :-( You want egdb from ports, especially for anything c++. (pkg_add gdb)
gdb: DW_TAG_ (abbrev = 85, offset = 20161909)
I'm trying to debug a core dump from GoldenCheetah which has been compiled with clang++ on OpenBSD 6.4 amd64. gdb fails like this: $ gdb /usr/local/bin/GoldenCheetah GoldenCheetah.core GNU gdb 6.3 ... [[loading lots of shared (qt) libraries]] ... Loaded symbols for /usr/local/lib/libwebpdemux.so.2.0 Die: DW_TAG_ (abbrev = 85, offset = 20161909) has children: FALSE attributes: DW_AT_type (DW_FORM_ref4) constant ref: 20155712 (adjusted) Dwarf Error: Cannot find type of die [in module /usr/local/bin/GoldenCheetah] Die: DW_TAG_ (abbrev = 85, offset = 20161909) has children: FALSE attributes: DW_AT_type (DW_FORM_ref4) constant ref: 20155712 (adjusted) Dwarf Error: Cannot find type of die [in module /usr/local/bin/GoldenCheetah] and lldb crashes: $ lldb -c GoldenCheetah.core /usr/local/bin/GoldenCheetah (lldb) target create "/usr/local/bin/GoldenCheetah" --core "GoldenCheetah.core" Bus error /var/log/messages shows: /bsd: coredump of lldb(5642), write failed: errno 14 Any suggestion how I can debug that program? (it's huge and written in C++ with which I am not familiar anyway :-( -- Address is valid for this mailing list only.
Re: What programming languages and operating systems will be used after Jesus returns?
> On Feb 9, 2019, at 3:11 PM, patrick keshishian wrote: > > also you have got daemons running in the system. > > > >> Yours, >> Ingo >> >From time to time the sounding of the dwarven horn will go on deaf ears ;) Regards Patrick
Re: What programming languages and operating systems will be used after Jesus returns?
On Sat, Feb 9, 2019 at 12:33 PM Ingo Schwarze wrote: > Hi Mihai, > > please don't feed trolls. > > The original BSD mascot happens to be the beast, > but apart from that, this thread is off-topic even on misc@. > also you have got daemons running in the system. > Yours, > Ingo > >
Re: What programming languages and operating systems will be used after Jesus returns?
Hi Mihai, please don't feed trolls. The original BSD mascot happens to be the beast, but apart from that, this thread is off-topic even on misc@. Yours, Ingo
Re: What programming languages and operating systems will be used after Jesus returns?
Maybe the release 6.6 should be skipped then? I like the part with wine, smoke and lamb. A well done lamb.
What programming languages and operating systems will be used after Jesus returns?
And it was given to him that he gave spirit to the image of the beast, that the image of the beast might also speak, and cause all them that worship not the image of the beast to be slain. And he causes all, small and great, rich and poor, free and bond, to be given a sign in their right hand, or in their foreheads, That no man may buy or sell, except he that hath the mark, or the name of the beast, or the number of his name. Here is wisdom. Let him who has understanding calculate the number of the beast; because it is the number of a man, and his number is six hundred and sixty-six. Apocalypse 13: 15-18 And a third angel followed them, saying with a loud voice, If any man worship the beast and his image, and accept his sign in the forehead or in the hand, And he shall drink the wine of divine wrath, the pure wine lying in the cup of his anger. He will be tormented by fire and brimstone before his holy angels and the Lamb. The smoke of their torment shall go up for ever and ever. There will be no rest day and night, those who worship the beast and his image, and whoever has received the sign of his name. Apocalypse 14: 9-11 Please do not accept the mark of the beast, who to accepts the mark of the beast will be condemned to live all eternity tormented in the lake of fire and brimstone. What programming languages and operating systems will be used after Jesus returns? In other words, what are the programming languages and operating systems that will be used in the Antichrist's rule?
Re: athn0: bad ROM checksum 0x2c64
Sent from my iPhone > On 9. Feb 2019, at 18:56, Sebastian Reitenbach > wrote: > > Hi, > > got a cheap TP-Link TL-WN821N, which shows up as Atheros AR7015 under Windows > 10. > > athn0 at uhub3 port 3 configuration 1 interface 0 "ATHEROS USB WLAN" rev > 2.00/2.02 addr 5 > athn0: failed loadfirmware of file athn-open-ar7010 (error 2) > athn0: could not load firmware Damn, forgot to mention that between above and below dmesg output I ran fw_update to fetch Athen firmware, then below on second insertion of the device i get the bad ROM checksum. That is on i386, amd64 and mips64el. > athn0 at uhub3 port 3 configuration 1 interface 0 "ATHEROS USB WLAN" rev > 2.00/2.02 addr 5 > athn0: bad ROM checksum 0x2c64 > athn0: could not read ROM > athn0: could not attach chip > > usbdevs -v: > addr 05: 0cf3:7015 ATHEROS, USB WLAN > high speed, power 500 mA, config 1, rev 2.02, iSerial 12345 > driver: athn0 > > Just wanted to make sure I don't miss anything, don't see that chpset somehow > listed in athn(4) page, so guess this is just not supported yet? > > cheers, > Sebastian >
Re: athn0 bad ROM checksum 0x2c64
http://man.openbsd.org/fw_update OT: Bad subject line, bad email address, at least I see them like this in marc.
getty vs. ttyU0
Hi all,
I'm trying to get a USB->serial adapter serving a login prompt via getty.
Here's the converter in question:
---8<---
uftdi0 at uhub3 port 3 configuration 1 interface 0 "FTDI FT232R USB UART" rev
2.00/6.00 addr 2
ucom0 at uftdi0 portno 1
--->8---
The following line in /etc/ttys:
---8<---
ttyU0 "/usr/libexec/getty std.9600" vt220 on
--->8---
Reboot, no login prompt on the client, even after liberally hammering enter.
This is the same as what happened using a prolific cable, but I had assumed
this was a hardware bug, but now I'm not so sure! I know the above procedure
works fine on a Soekris (just using tty00 in place of ttyU0).
Debugging further, manually echoing ASCII down the line using cuaU0 works fine.
I then ran getty under ktrace:
---8<---
ktrace /usr/libexec/getty std.9600 ttyU0
--->8---
It looks to me like opening the device is hanging:
---8<---
...
20220 gettyNAMI "/dev"
20220 gettyRET unveil 0
20220 gettyCALL kbind(0x7f7fb318,24,0xb7092ac1c9c0a609)
20220 gettyRET kbind 0
20220 gettyCALL kbind(0x7f7fb318,24,0xb7092ac1c9c0a609)
20220 gettyRET kbind 0
20220 gettyCALL kbind(0x7f7fa878,24,0xb7092ac1c9c0a609)
20220 gettyRET kbind 0
20220 gettyCALL kbind(0x7f7fb318,24,0xb7092ac1c9c0a609)
20220 gettyRET kbind 0
20220 gettyCALL chown(0x8bbe8e078f0,0<"root">,0<"wheel">)
20220 gettyNAMI "/dev/ttyU0"
20220 gettyRET chown 0
20220 gettyCALL kbind(0x7f7fb318,24,0xb7092ac1c9c0a609)
20220 gettyRET kbind 0
20220 gettyCALL chmod(0x8bbe8e078f0,0600)
20220 gettyNAMI "/dev/ttyU0"
20220 gettyRET chmod 0
20220 gettyCALL kbind(0x7f7fb318,24,0xb7092ac1c9c0a609)
20220 gettyRET kbind 0
20220 gettyCALL revoke(0x8bbe8e078f0)
20220 gettyNAMI "/dev/ttyU0"
20220 gettyRET revoke 0
20220 gettyCALL kbind(0x7f7fb318,24,0xb7092ac1c9c0a609)
20220 gettyRET kbind 0
20220 gettyCALL nanosleep(0x7f7fb3b8,0x7f7fb3a8)
20220 gettySTRU struct timespec { 2 }
20220 gettySTRU struct timespec { 0 }
20220 gettyRET nanosleep 0
20220 gettyCALL kbind(0x7f7fb318,24,0xb7092ac1c9c0a609)
20220 gettyRET kbind 0
20220 gettyCALL open(0x8bbe8e078f0,0x2)
20220 gettyNAMI "/dev/ttyU0"
--->8---
(That's the end of the trace)
That trace snippet corresponds with this chunk of code:
---8<---
if (strcmp(argv[0], "+") != 0) {
chown(ttyn, 0, 0);
chmod(ttyn, 0600);
revoke(ttyn);
/*
* Delay the open so DTR stays down long enough to be
detected.
*/
sleep(2);
while ((i = open(ttyn, O_RDWR)) == -1) {
--->8---
https://cvsweb.openbsd.org/src/libexec/getty/main.c?rev=1.51=text/x-cvsweb-markup
Nothing else has the serial line open (but it shouldn't matter anyway, as getty
uses revoke(2) on the device).
---8<---
# fstat | grep ttyU0
# fstat | grep cuaU0
#
--->8---
This little C program hangs too (stoppnig getty first obviously):
---8<---
#include
#include
#include
int
main(void)
{
printf("opening\n");
if (open("/dev/ttyU0", O_RDWR) == -1)
err(1, "open");
printf("open ok\n");
}
--->8---
When I kill the program with CTRL+C, a newline is sent to the client.
And the behaviour is the same for a:
```
uplcom0 at uhub3 port 3 configuration 1 interface 0 "Prolific Technology PL2303
Serial" rev 1.10/2.02 addr 2
ucom0 at uplcom0
```
The above C program does not hang on Soekris using /dev/tty00.
I can repro on 6.4-stable/amd64 and -current/amd64.
I'm out of ideas, so can anyone think of any reason why open(2) on /dev/ttyU0
might block indefinitely?
--
Best Regards
Edd Barrett
http://www.theunixzoo.co.uk
athn0: bad ROM checksum 0x2c64
Hi, got a cheap TP-Link TL-WN821N, which shows up as Atheros AR7015 under Windows 10. athn0 at uhub3 port 3 configuration 1 interface 0 "ATHEROS USB WLAN" rev 2.00/2.02 addr 5 athn0: failed loadfirmware of file athn-open-ar7010 (error 2) athn0: could not load firmware athn0 at uhub3 port 3 configuration 1 interface 0 "ATHEROS USB WLAN" rev 2.00/2.02 addr 5 athn0: bad ROM checksum 0x2c64 athn0: could not read ROM athn0: could not attach chip usbdevs -v: addr 05: 0cf3:7015 ATHEROS, USB WLAN high speed, power 500 mA, config 1, rev 2.02, iSerial 12345 driver: athn0 Just wanted to make sure I don't miss anything, don't see that chpset somehow listed in athn(4) page, so guess this is just not supported yet? cheers, Sebastian
Re: How to print nicely formatted man pages?
Hi, Stephen Gregoratto wrote on Sat, Feb 09, 2019 at 10:41:17AM +1100: > In my opinion I find the PostScript/PDF output from groff to be > better than mandoc's, sorry Ingo :(. Absolutely, that is exactly what i always say. > The font size and line spacing makes a better print, which makes > sense considering that groff is a typesetting suite. There are lots of aspects in which groff(1) PostScript and PDF output - i.e., output from a real typesetting system - is better than mandoc(1)'s. > The catch is that groff doesn't detect if eqn(1) or tbl(1) needs > to be run for the man page, while mandoc does. Yes. One goal of mandoc(1) -T ps/pdf is to make calling it easy, without having to worry about *any* options, such that it can be used casually (safely and reliably) to get a quick printout. > You would need to use grog(1) for that. I strongly advise against using grog(1). It is a disgusting kludge written by an extremely careless programmer (Bernd Warken). Since Bernd is no longer able to do any programming at all AFAIK, it is now also effectively unmaintained and subject to bitrot on top of the poor quality it has in the first place. At one point, i considered simply deleting grog(1) from the OpenBSD textproc/groff package - but then again, OpenBSD packages should not be prejudiced, and since grog(1) is still distributed upstream, it is still contained in the groff package. But that doesn't mean anyone should run it. If you want to use groff, use options like "-k", "-e" or "-t" to the groff(1) program as needed or construct pipelines the traditional way. Even that is clearly more fragile and riskier with untrusted input than running mandoc, but not quite as bad as grog(1). > Here are some example pdf's for the 6.4 version of man(1): > https://www.sgregoratto.me/paste/man-groff.1.pdf > https://www.sgregoratto.me/paste/man-mandoc.1.pdf > It's up to you to decide which one looks better. It is not just a matter of personal taste. The groff(1) output is objectively better. For example, these two URIs show that mandoc fails to do adjustment (look at the right margin in the ENVIRONMENT section) and fails to use constant-width font where it should (look at the displays in the EXAMPLES section). All the same, it is convenient for just getting a quick printout. Yours, Ingo
Re: How to shrink the SIZE memory?
On Sat, Feb 09, 2019 at 03:15:30PM +0100, Otto Moerbeek wrote:
> On Sat, Feb 09, 2019 at 12:39:37PM +0100, Peter J. Philipp wrote:
>
> > On Sat, Feb 09, 2019 at 12:01:39PM +0100, Otto Moerbeek wrote:
> > > Why is this a wall? Do your mmaps start failing? With what error code?
> >
> > Well 13G isn't the wall, but I had tried the entire /usr/share/dict/words as
> > A records which would have given more than 200K RRSET's which would have
> > blown up this SIZE considerably since the 30K RRSET's were 13G.
>
> So you're using around 433k per RRSET. That's a lot given that a
> typical RRSET in the wild often is smaller than 100 bytes (no k
> there). I understand to advantages of fixed size data structures, but
> in this case it's not the right way.
>
> -Otto
Thanks Otto. I doodled up a plan in the last few hours, here is the result:
https://centroid.eu/blog/c?article=1549722619
I'm not going to be rash about this, but I may start next week with this this
new concept. Do you think an RRSET like this would be space saving and still
be fast enough? I know I'm losing a bit of speed with all the TAILQ's but I
think I'll work this out with the tree(3) and queue(3) macros.
It's been a long way on getting the database right over the last 15 years on
this daemon. I started with BerkeleyDB backend, and replaced the BDB about
2 years ago with the tree(3). Now hopefully I'll get it right finally. This
year is already gonna rock in terms of milestones, hehe.
Best Regards,
-peter
> >
> > The mmaps failed but due to a stupidity in my own code I could not glance
> > the
> > real errno value (I'll show you why):
> >
> > ->
> > /* does not exist, create it */
> >
> > map = (char *)mmap(NULL, SIZENODE, PROT_READ|PROT_WRITE,
> > MAP_PRI
> > VATE | MAP_ANON, -1, 0);
> > if (map == MAP_FAILED) {
> > errno = EINVAL;
> > return -1;
> > }
> >
> > <-
> >
> > I should have logged it before reusing errno, I'll do some tests and get
> > back
> > to you. I am currently not at my workstation as I went and visited my
> > parents
> > since writing the original mail, and I won't be back until monday or so, so
> > any
> > changing of this code will have to wait until then.
> >
> > > You should be able (given ulimits) to mmap up to MAXDSIZ (32G on
> > > amd64) per process.
> >
> > I noticed that RLIMIT_DATA limits had given me problems too. Sizing them to
> > 16G had allowed me to work with the 30K RRSETs.
> >
> > > If you want to reduce SIZE, call munmap(). That's the only way. You
> > > cannot have virtual memory pages that are not accounted for in SIZE.
> > >
> > > -Otto
> >
> > Ahh ok thanks for clearing that up. It looks like I'll have to rewrite the
> > way I store internal data then, if I want to use a LOT of RRSETs in the
> > future.
> > May be better for me too.
> >
> > Thanks Otto!
> >
> > Best Regards,
> > -peter
> >
Re: How to shrink the SIZE memory?
On Sat, Feb 09, 2019 at 12:39:37PM +0100, Peter J. Philipp wrote:
> On Sat, Feb 09, 2019 at 12:01:39PM +0100, Otto Moerbeek wrote:
> > Why is this a wall? Do your mmaps start failing? With what error code?
>
> Well 13G isn't the wall, but I had tried the entire /usr/share/dict/words as
> A records which would have given more than 200K RRSET's which would have
> blown up this SIZE considerably since the 30K RRSET's were 13G.
So you're using around 433k per RRSET. That's a lot given that a
typical RRSET in the wild often is smaller than 100 bytes (no k
there). I understand to advantages of fixed size data structures, but
in this case it's not the right way.
-Otto
>
> The mmaps failed but due to a stupidity in my own code I could not glance the
> real errno value (I'll show you why):
>
> ->
> /* does not exist, create it */
>
> map = (char *)mmap(NULL, SIZENODE, PROT_READ|PROT_WRITE,
> MAP_PRI
> VATE | MAP_ANON, -1, 0);
> if (map == MAP_FAILED) {
> errno = EINVAL;
> return -1;
> }
>
> <-
>
> I should have logged it before reusing errno, I'll do some tests and get back
> to you. I am currently not at my workstation as I went and visited my parents
> since writing the original mail, and I won't be back until monday or so, so
> any
> changing of this code will have to wait until then.
>
> > You should be able (given ulimits) to mmap up to MAXDSIZ (32G on
> > amd64) per process.
>
> I noticed that RLIMIT_DATA limits had given me problems too. Sizing them to
> 16G had allowed me to work with the 30K RRSETs.
>
> > If you want to reduce SIZE, call munmap(). That's the only way. You
> > cannot have virtual memory pages that are not accounted for in SIZE.
> >
> > -Otto
>
> Ahh ok thanks for clearing that up. It looks like I'll have to rewrite the
> way I store internal data then, if I want to use a LOT of RRSETs in the
> future.
> May be better for me too.
>
> Thanks Otto!
>
> Best Regards,
> -peter
>
Re: PPPoE vlan issue 6.4
Sorry, a copy and paste error Below is the ifconfig -A output, note I've updated llprio to 1 on the vlan which now looks to send down the wire as prio=0 when testing on a client. Ref: http://openbsd-archive.7691.n7.nabble.com/use-link0-on-vlan-4-to-force-the-vlan-priority-to-llprio-td339390.html. With llprio=1 on the pppoe0 device I get the below OpenBSD: 22:10:52.275405 00:0d:b9:4f:74:98 Broadcast 8100 36: 802.1Q vid 2 pri 1 PPPoE-Discovery code Initiation, version 1, type 1, id 0x, length 12 tag Service-Name, length 0 tag Host-Uniq, length 4 \307\270\216T : 000d b94f 7498 8100 0002 .Ot. 0010: 8863 1109 000c 0101 0103 0004 .c.. 0020: c7b8 8e54...T Imac client: 22:00:24.885745 00:0d:b9:4f:74:98 (oui Unknown) > Broadcast, ethertype 802.1Q (0x8100), length 60: vlan 2, p 0, ethertype PPPoE D, PPPoE PADI [Service-Name] [Host-Uniq 0xC7B88E54] 0x: 1109 000c 0101 0103 0004 c7b8 0x0010: 8e54 .T.. 0x0020: .. In the morning I'll try doing a packet capture on the DD-WRT device that works plugged in to another machine to grab it's PADI packets. Ifconfig (note ethernet cable unpluged on em0 at the time): lo0: flags=8049 mtu 32768 index 5 priority 0 llprio 3 groups: lo inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5 inet 127.0.0.1 netmask 0xff00 em0: flags=8843 mtu 1500 lladdr 00:0d:b9:4f:74:98 index 1 priority 0 llprio 3 media: Ethernet autoselect (none) status: no carrier em1: flags=8802 mtu 1500 lladdr 00:0d:b9:4f:74:99 index 2 priority 0 llprio 3 media: Ethernet autoselect (none) status: no carrier em2: flags=8843 mtu 1500 lladdr 00:0d:b9:4f:74:9a index 3 priority 0 llprio 3 media: Ethernet autoselect (none) status: no carrier enc0: flags=0<> index 4 priority 0 llprio 3 groups: enc status: active pppoe0: flags=8851 mtu 1492 index 6 priority 0 llprio 1 dev: vlan2 state: PADI sent sid: 0x0 PADI retries: 33 PADR retries: 0 sppp: phase establish authproto pap authname "redacted" groups: pppoe egress status: no carrier inet 0.0.0.1 --> 0.0.0.0 netmask 0xff00 vlan2: flags=8843 mtu 1500 lladdr 00:0d:b9:4f:74:98 index 7 priority 0 llprio 1 encap: vnetid 2 parent em0 groups: vlan media: Ethernet autoselect (none) status: no carrier pflog0: flags=141 mtu 33136 index 8 priority 0 llprio 3 groups: pflog -- Adam Evans On Sat, 9 Feb 2019, at 21:35, Sebastien Marie wrote: > On Sat, Feb 09, 2019 at 05:51:27PM +1100, Adam Evans wrote: > > Hi, i'm trying to set up an OpenBSD router (6.4) on a PcEngines APU2D4 with > > Intel i210AT nics however I am having difficulties with PPPoE. I can see > > the discovery PADI packets going out using tcpdump but do not see any PADO > > response so PPPoE times out and retries sending the PADI packets. > > > > More confusing is my Netgear R7000 running DD-WRT that I want to replace > > with the APU handles PPPoE just fine and bizarrely the PADI packets look > > the same however the packets from OpenBSD don't get a response but the > > R7000 does. > > > > > > If config output: > > the ifconfig output is a bit odd. > > > lo0: flags=8049 mtu 32768 > > index 5 priority 0 llprio 3 > > groups: lo > > inet6 ::1 prefixlen 128 > > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5 > > inet 127.0.0.1 netmask 0xff00 > > em0: flags=8843 mtu 1492 > > lladdr 00:0d:b9:4f:74:98 > > index 1 priority 0 llprio 3 > > media: Ethernet autoselect (1000baseT full-duplex,rxpause,txpause) > > status: active > > em1: flags=8802 mtu 1500 > > lladdr 00:0d:b9:4f:74:99 > > index 2 priority 0 llprio 3 > > media: Ethernet autoselect (none) > > status: no carrier > > em1: flags=8802 mtu 1500 > > lladdr 00:0d:b9:4f:74:99 > > index 2 priority 0 llprio 3 > > media: Ethernet autoselect (none) > > status: no carrier > > em1 is listed twice > > > em2: flags=8843 mtu 1500 > > lladdr 00:0d:b9:4f:74:9a > > index 3 priority 0 llprio 3 > > groups: egress > > media: Ethernet autoselect (none) > > status: no carrier > > inet 192.168.2.103 netmask 0xff00 broadcast 192.168.2.255 > > enc0: flags=0<> > > index 4 priority 0 llprio 3 > > groups: enc > > status: active > > pflog0: flags=141 mtu 33136 > > index 6 priority 0 llprio 3 > > groups: pflog > > pppoe0: flags=8851 mtu 1492 > > index 7 priority 0 llprio
Re: How to shrink the SIZE memory?
On Sat, Feb 09, 2019 at 12:01:39PM +0100, Otto Moerbeek wrote:
> Why is this a wall? Do your mmaps start failing? With what error code?
Well 13G isn't the wall, but I had tried the entire /usr/share/dict/words as
A records which would have given more than 200K RRSET's which would have
blown up this SIZE considerably since the 30K RRSET's were 13G.
The mmaps failed but due to a stupidity in my own code I could not glance the
real errno value (I'll show you why):
->
/* does not exist, create it */
map = (char *)mmap(NULL, SIZENODE, PROT_READ|PROT_WRITE, MAP_PRI
VATE | MAP_ANON, -1, 0);
if (map == MAP_FAILED) {
errno = EINVAL;
return -1;
}
<-
I should have logged it before reusing errno, I'll do some tests and get back
to you. I am currently not at my workstation as I went and visited my parents
since writing the original mail, and I won't be back until monday or so, so any
changing of this code will have to wait until then.
> You should be able (given ulimits) to mmap up to MAXDSIZ (32G on
> amd64) per process.
I noticed that RLIMIT_DATA limits had given me problems too. Sizing them to
16G had allowed me to work with the 30K RRSETs.
> If you want to reduce SIZE, call munmap(). That's the only way. You
> cannot have virtual memory pages that are not accounted for in SIZE.
>
> -Otto
Ahh ok thanks for clearing that up. It looks like I'll have to rewrite the
way I store internal data then, if I want to use a LOT of RRSETs in the future.
May be better for me too.
Thanks Otto!
Best Regards,
-peter
Re: How to shrink the SIZE memory?
On Sat, Feb 09, 2019 at 11:34:41AM +0100, Peter J. Philipp wrote: > Hi misc@, > > I have a program, a DNS server. It has a database to hold internal data. > Right now it's very inneficient in the way it uses memory. Let me explain. > > If you know what an RRSET is it's all the RR records under one name. Like in > the OpenBSD.ORG name there is a SOA, NS, A RR's and so on. That's an RRSET. > > Internally in my program I reserve space for an RRSET to all the maximum > records (around maximum 15 A RR's or so) and there is 15 or so types of > RR's in support with my program. As you can guess the RRSET becomes huge. > > When designing the database for this I thought "hey what if I mmap this space > and only those parts that get written to it will actually be used". And > that's > what I did. Only I run into a wall. With close to 3 RRSET's I get this > in top: > > Memory: Real: 1233M/3468M act/tot Free: 28G Cache: 1197M Swap: 0K/32G > > PID USERNAME PRI NICE SIZE RES STATE WAIT TIMECPU COMMAND > 74465 _ddd 20 13G 163M sleep/1 select0:01 0.00% > delphinusdn > 31148 _ddd 20 13G 1116K sleep/1 select0:01 0.00% > delphinusdn > .. > > So you see the SIZE is 13 GB, but the actual resident memory is 163M. So now > I come to my final question: > > Is there a way to claim back part of that 13G? > > If not is there a way to overcommit? I googled on this and many people think > it's bad and I don't want to start a religious war right now. > > In the worst case scenario I'll have to rewrite my underlying database, and > I'm > a little lazy, if I do have to do that it won't be for another year+. > > I looked at madvise(2) and I'm a little confused as to what I can use for > this. > > Best regards, > -peter > Why is this a wall? Do your mmaps start failing? With what error code? You should be able (given ulimits) to mmap up to MAXDSIZ (32G on amd64) per process. If you want to reduce SIZE, call munmap(). That's the only way. You cannot have virtual memory pages that are not accounted for in SIZE. -Otto
Re: PPPoE vlan issue 6.4
Thanks for the suggestion of plugging it into another machine to do a packet dump. There's a miss-match on the priority from what OpenBSD is reporting to what the client sees on the other end. OpenBSD priority=0, client has priority=1. OpenBSD: 21:01:37.959968 00:0d:b9:4f:74:98 Broadcast 8100 36: 802.1Q vid 2 pri 0 PPPoE-Discovery code Initiation, version 1, type 1, id 0x, length 12 tag Service-Name, length 0 tag Host-Uniq, length 4 \215\205\320] : 000d b94f 7498 8100 2002 .Ot... . 0010: 8863 1109 000c 0101 0103 0004 .c.. 0020: 8d85 d05d...] On the client (IMac) 21:01:40.169419 00:0d:b9:4f:74:98 (oui Unknown) > Broadcast, ethertype 802.1Q (0x8100), length 60: vlan 2, p 1, ethertype PPPoE D, PPPoE PADI [Service-Name] [Host-Uniq 0x8D85D05D] 0x: 1109 000c 0101 0103 0004 8d85 0x0010: d05d .].. 0x0020: .. This looks to be wrong? The client (directly connected imac) should not be seeing a priority of 1? It's strange on the OpenBSD side it has a priority of one on the packet dump unless it's modified further along? Also I'm not sure where what looks to be padding comes from, if that is on the openbsd side or the mac side? This is my first time using OpenBSD but looking through the changelogs the llprio set on the interface should be correctly setting the priority? The tcpdump on the OpenBSD side looks to support that. Re the modem, I have a ISP provided modem which is locked down like ISP's do so I do not have access to set vlans on that manually. I have been using it in bridge mode with DD-WRT for about 2 years and DD-WRT had the WAN port set to vlan 2. -- Adam Evans On Sat, 9 Feb 2019, at 20:33, Stuart Henderson wrote: > On 2019-02-09, Adam Evans wrote: > > Hi, i'm trying to set up an OpenBSD router (6.4) on a PcEngines APU2D4 with > > Intel i210AT nics however I am having difficulties with PPPoE. I can see > > the discovery PADI packets going out using tcpdump but do not see any PADO > > response so PPPoE times out and retries sending the PADI packets. > > > > More confusing is my Netgear R7000 running DD-WRT that I want to replace > > with the APU handles PPPoE just fine and bizarrely the PADI packets look > > the same however the packets from OpenBSD don't get a response but the > > R7000 does. > > > > Using tcpdump the PADI message form OpenBSD looks like below: > > > > 15:21:47.340929 a0:63:91:47:81:07 ff:ff:ff:ff:ff:ff 8100 36: 802.1Q vid > > 2 pri 0 PPPoE-Discovery > > code Initiation, version 1, type 1, id 0x, length 12 > > tag Service-Name, length 0 > > tag Host-Uniq, length 4 \210\352\235\232 > > > > From the router running DD-WRT we can see the PADI packet followed by the > > response PADO: > > > > 01:14:57.164338 a0:63:91:47:81:07 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q > > (0x8100), length 36: vlan 2, p 0, ethertype PPPoE D, PPPoE PADI > > [Service-Name] [Host-Uniq 0x5544] > > > > 01:14:57.171736 78:da:6e:de:df:d4 > a0:63:91:47:81:07, ethertype 802.1Q > > (0x8100), length 103: vlan 2, p 0, ethertype PPPoE D, PPPoE PADO > > [Vendor-Specific "..AVC30861999"] [Service-Name] [Host-Uniq > > 0x5544] [AC-Name "syd-gls-har-bras24"] [AC-Cookie "po.N?f'..D27"] > > > > To me, the PADI packets look the same, I even spoofed the MAC on the > > OpenBSD box so it looks like the DD-WRT router although this shouldn't be > > necessary I just wanted to verify. > > Can you get a more complete dump? (e.g. tcpdump -s1500 -X -e -i em0/eth0) > > Can you get a dump of the PADI from another machine plugged into em0 to check > that it actually makes it onto the wire with the expected tag/prio?? > > > em0: flags=8843 mtu 1492 > > I don't expect it to make a difference this early in the negotiation but > em0 should be mtu 1500, you'll run into problems later with 1492. > > FWIW normally I do the vlan handling in the modem rather than on the router > and pppoe setup is usually straightforward, though it should work either way. > >
Re: PPPoE vlan issue 6.4
On Sat, Feb 09, 2019 at 05:51:27PM +1100, Adam Evans wrote: > Hi, i'm trying to set up an OpenBSD router (6.4) on a PcEngines APU2D4 with > Intel i210AT nics however I am having difficulties with PPPoE. I can see the > discovery PADI packets going out using tcpdump but do not see any PADO > response so PPPoE times out and retries sending the PADI packets. > > More confusing is my Netgear R7000 running DD-WRT that I want to replace with > the APU handles PPPoE just fine and bizarrely the PADI packets look the same > however the packets from OpenBSD don't get a response but the R7000 does. > > > If config output: the ifconfig output is a bit odd. > lo0: flags=8049 mtu 32768 > index 5 priority 0 llprio 3 > groups: lo > inet6 ::1 prefixlen 128 > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5 > inet 127.0.0.1 netmask 0xff00 > em0: flags=8843 mtu 1492 > lladdr 00:0d:b9:4f:74:98 > index 1 priority 0 llprio 3 > media: Ethernet autoselect (1000baseT full-duplex,rxpause,txpause) > status: active > em1: flags=8802 mtu 1500 > lladdr 00:0d:b9:4f:74:99 > index 2 priority 0 llprio 3 > media: Ethernet autoselect (none) > status: no carrier > em1: flags=8802 mtu 1500 > lladdr 00:0d:b9:4f:74:99 > index 2 priority 0 llprio 3 > media: Ethernet autoselect (none) > status: no carrier em1 is listed twice > em2: flags=8843 mtu 1500 > lladdr 00:0d:b9:4f:74:9a > index 3 priority 0 llprio 3 > groups: egress > media: Ethernet autoselect (none) > status: no carrier > inet 192.168.2.103 netmask 0xff00 broadcast 192.168.2.255 > enc0: flags=0<> > index 4 priority 0 llprio 3 > groups: enc > status: active > pflog0: flags=141 mtu 33136 > index 6 priority 0 llprio 3 > groups: pflog > pppoe0: flags=8851 mtu 1492 > index 7 priority 0 llprio 0 > dev: vlan2 state: PADI sent > sid: 0x0 PADI retries: 10 PADR retries: 0 > sppp: phase establish authproto pap authname "b8nfv2em" > groups: pppoe > status: no carrier > inet 0.0.0.1 --> 0.0.0.0 netmask 0xff00 > vlan2: flags=8843 mtu 1492 > lladdr 00:0d:b9:4f:74:98 > index 8 priority 0 llprio vlan2 isn't attached to anything: you should have a line like: encap: vnetid 2 parent em0 txprio packet > Config files: > ## /etc/hostname.em0: > mtu 1492 up > > > ## /etc/hostname.vlan2: > vnetid 2 parent em0 > llprio 0 > mtu 1492 > up the configuration file seems fine. > ## /etc/hostname.pppoe0: > inet 0.0.0.0 255.255.255.255 NONE \ >pppoedev vlan2 authproto pap \ >authname 'redacted' authkey 'redacted' up >mtu 1492 >llprio 0 >dest 0.0.0.1 >!/sbin/route add default -ifp pppoe0 0.0.0.1 so, could you check the configuration file of hostname.vlan2 is really applied on the running system ? else, could you send the whole output of ifconfig ? (but feel free to remove pppoe0 authentification information). thanks. -- Sebastien Marie
How to shrink the SIZE memory?
Hi misc@, I have a program, a DNS server. It has a database to hold internal data. Right now it's very inneficient in the way it uses memory. Let me explain. If you know what an RRSET is it's all the RR records under one name. Like in the OpenBSD.ORG name there is a SOA, NS, A RR's and so on. That's an RRSET. Internally in my program I reserve space for an RRSET to all the maximum records (around maximum 15 A RR's or so) and there is 15 or so types of RR's in support with my program. As you can guess the RRSET becomes huge. When designing the database for this I thought "hey what if I mmap this space and only those parts that get written to it will actually be used". And that's what I did. Only I run into a wall. With close to 3 RRSET's I get this in top: Memory: Real: 1233M/3468M act/tot Free: 28G Cache: 1197M Swap: 0K/32G PID USERNAME PRI NICE SIZE RES STATE WAIT TIMECPU COMMAND 74465 _ddd 20 13G 163M sleep/1 select0:01 0.00% delphinusdn 31148 _ddd 20 13G 1116K sleep/1 select0:01 0.00% delphinusdn ... So you see the SIZE is 13 GB, but the actual resident memory is 163M. So now I come to my final question: Is there a way to claim back part of that 13G? If not is there a way to overcommit? I googled on this and many people think it's bad and I don't want to start a religious war right now. In the worst case scenario I'll have to rewrite my underlying database, and I'm a little lazy, if I do have to do that it won't be for another year+. I looked at madvise(2) and I'm a little confused as to what I can use for this. Best regards, -peter
Re: PPPoE vlan issue 6.4
On 2019-02-09, Adam Evans wrote: > Hi, i'm trying to set up an OpenBSD router (6.4) on a PcEngines APU2D4 with > Intel i210AT nics however I am having difficulties with PPPoE. I can see the > discovery PADI packets going out using tcpdump but do not see any PADO > response so PPPoE times out and retries sending the PADI packets. > > More confusing is my Netgear R7000 running DD-WRT that I want to replace with > the APU handles PPPoE just fine and bizarrely the PADI packets look the same > however the packets from OpenBSD don't get a response but the R7000 does. > > Using tcpdump the PADI message form OpenBSD looks like below: > > 15:21:47.340929 a0:63:91:47:81:07 ff:ff:ff:ff:ff:ff 8100 36: 802.1Q vid 2 > pri 0 PPPoE-Discovery > code Initiation, version 1, type 1, id 0x, length 12 > tag Service-Name, length 0 > tag Host-Uniq, length 4 \210\352\235\232 > > From the router running DD-WRT we can see the PADI packet followed by the > response PADO: > > 01:14:57.164338 a0:63:91:47:81:07 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q > (0x8100), length 36: vlan 2, p 0, ethertype PPPoE D, PPPoE PADI > [Service-Name] [Host-Uniq 0x5544] > > 01:14:57.171736 78:da:6e:de:df:d4 > a0:63:91:47:81:07, ethertype 802.1Q > (0x8100), length 103: vlan 2, p 0, ethertype PPPoE D, PPPoE PADO > [Vendor-Specific "..AVC30861999"] [Service-Name] [Host-Uniq > 0x5544] [AC-Name "syd-gls-har-bras24"] [AC-Cookie "po.N?f'..D27"] > > To me, the PADI packets look the same, I even spoofed the MAC on the OpenBSD > box so it looks like the DD-WRT router although this shouldn't be necessary I > just wanted to verify. Can you get a more complete dump? (e.g. tcpdump -s1500 -X -e -i em0/eth0) Can you get a dump of the PADI from another machine plugged into em0 to check that it actually makes it onto the wire with the expected tag/prio?? > em0: flags=8843 mtu 1492 I don't expect it to make a difference this early in the negotiation but em0 should be mtu 1500, you'll run into problems later with 1492. FWIW normally I do the vlan handling in the modem rather than on the router and pppoe setup is usually straightforward, though it should work either way.
