Messages

1

17.7 Legacy Series / Re: [NOT-SOLVED,WTF!?] PPPOE Crash

« on: August 28, 2017, 08:29:28 am »

Thanks for testing. I'll update the patch and push for merging it in standard FreeBSD installation.

2

17.7 Legacy Series / Re: [NOT-SOLVED,WTF!?] PPPOE Crash

« on: August 24, 2017, 09:34:23 am »

I think to have found the issue. Try changing the following code in pppoe_finduniq function:

Code: [Select]

        /* Cycle through all known hooks. */
        LIST_FOREACH(hook, &node->nd_hooks, hk_hooks) {
                /* Skip any nonsession hook. */
                if (NG_HOOK_PRIVATE(hook) == NULL)
                        continue;
                sp = NG_HOOK_PRIVATE(hook);
                if (sp->neg->host_uniq_len == ntohs(tag->tag_len) &&
                    bcmp(sp->neg->host_uniq.data, (const char *)(tag + 1),
                     sp->neg->host_uniq_len) == 0)
                        break;
        }
with

Code: [Select]

        /* Cycle through all known hooks. */
        LIST_FOREACH(hook, &node->nd_hooks, hk_hooks) {
                /* Skip any nonsession hook. */
                if (NG_HOOK_PRIVATE(hook) == NULL)
                        continue;
                sp = NG_HOOK_PRIVATE(hook);
                /* Skip already connected sessions. */
                if (sp->neg == NULL)
                        continue;
                if (sp->neg->host_uniq_len == ntohs(tag->tag_len) &&
                    bcmp(sp->neg->host_uniq.data, (const char *)(tag + 1),
                     sp->neg->host_uniq_len) == 0)
                        break;
        }
Franco, can you create an image or a module with the above change so that jwe can test it, please?

3

17.7 Legacy Series / Re: [NOT-SOLVED,WTF!?] PPPOE Crash

« on: August 24, 2017, 08:42:20 am »

Hi, I'm the author of the patch.

It'd be indeed useful to have the full ethernet dump. I've read multiple hypothesis about the cause of the issue, but few facts supporting them. The last one seems to be multiple PADO answers from different Access Concentrators. I don't exclude at 100% that this may be the issue (it's not a common scenario), but in theory it should be handled correctly (second PADO is ignored, /* Multiple PADO is OK. */ in the code) and my patch doesn't touch that part, so I'd expect the same behavior on a clean FreeBSD installation.

Instead of blocking the AC via its MAC address, you can configure the PPPoE connection to just accept a specific AC-Name. Since blocking one AC seems to have fixed the issue, it'd be interesting to see if blocking the another one produces the same result. And also to know the behavior with the same conditions (multiple PADO) on a clean pppoe module.