pppoe-discovery waits indefinitely after finding an AC

[Lantizia]

Hello,

I'm hoping to check if something is expected behaviour, as it may help with Debian bug #1070753. This software is used as the "ppp-udeb" package in Debian and can be loaded by specifying "modules=ppp-udeb" as a boot: argument when starting the Debian installer from the ISO.

Before the Debian installer asks for your PPPoE username and password, it runs pppoe-discovery up to two times (one with -U and one without... with $1 as the interface name) to check if there is an access concentrator or not.

pppoe-discovery -I $1 2>/tmp/ppp-errors | grep AC | wc-l
pppoe-discovery -U -I $1 2>/tmp/ppp-errors | grep AC | wc-l

In either case it will result in the following output (the ACs shown here are FireBrick FB6202 appliances from a real ISP)...

       Service-Name: datasuite12.13
Access-Concentrator: datasuite12.13
AC-Ethernet-Address: 00:03:97:40:00:3e
--------------------------------------------------
       Service-Name: datasuite12.13
Access-Concentrator: datasuite12.13
AC-Ethernet-Address: 00:03:97:3d:80:2b
--------------------------------------------------

But unfortunately it never returns to the prompt... it'll just sit there indefinitely, seemingly doing nothing. Here's an animated GIF as proof (it'll loop about every 2:30 minutes, but you get the idea)...

This means that "grep AC" won't get anything from stdin as the pppoe-discovery process never finishes. As a result you can't use PPPoE with the Debian installer (at least in this particular scenario) as it thinks discovery has failed and won't proceed to ask for a username and password.

In the Debian bug... I have said it'd be better to use -Q instead to simply test to see if there any ACs available (instead of using grep). Putting that aside for a moment though...

However these scenarios work as expected (all scenarios were tested both with and without -U)...

• If no AC is available then it gives up after 15 seconds (the correct length of time since neither -a or -t were set) and quits.

• Running (on a separate Linux box) something like "pppoe-server -C name -S name -I interface" results in it being immediately being found and then it quits 5 seconds later.

  Access-Concentrator: myAC
     Service-Name: myAC
  Got a cookie: 6c a3 2e c9 f6 93 6b 78 65 7a 02 8a 7e 9a 03 b4 68 16 00 00
  AC-Ethernet-Address: 52:54:00:c0:94:c8
  --------------------------------------------------

• Running a quick PPPoE Server from a MikroTik CHR also results in it immediately being found and then it quits 5 seconds later.

  Access-Concentrator: chr1
     Service-Name: service1
  AC-Ethernet-Address: 00:50:56:9e:fe:7d
  --------------------------------------------------

• Finally going back to the original ACs... if I turn either of them off (as two were listening in the original scenario) then it only finds the other one... but then it ALSO quits after 5 seconds!

     Service-Name: datasuite12.13
  Access-Concentrator: datasuite12.13
  AC-Ethernet-Address: 00:03:97:40:00:3e
  --------------------------------------------------

So it would seem that the issue is something to do with how it can see multiple ACs?

The two ACs in the original failed test are a pair of FireBrick 6202 appliances (with identical configuration) which my employer uses (I work for an ISP) to run thousands of broadband connections. There is a healthy mix of different PPPoE clients on the ends of those broadband connections... as in the United Kingdom, customers can basically use any router they like, so you get a mix of every make and model imaginable. So I'm pretty certain there is nothing abnormal about the ACs that are in use here, as they work with everything else.

Ultimately if this is expected behaviour... then it's important that -Q is used instead.

If it's not expected behaviour... then I'd still say -Q is a better solution anyway! But it'd be good to know, to help argue the case to the Debian folks to use -Q instead.

[Neustradamus]

@paulusmack: Have you seen this issue?

[paulusmack]

This is probably related to commit 1c082acf77e6, which has already been partially reverted in commit 73bd762a65c6, which restored the previous behaviour of the pppoe plugin but not the standalone pppoe-discovery program. So this problem probably still exists with the current upstream code, but if you can verify that it would be helpful. If you were able to revert the rest of 1c082acf77e6 and see if that fixes the problem, that would also be useful information.

[Neustradamus]

@Lantizia: Have you seen the @paulusmack comment?

[Neustradamus]

@Lantizia: Have you seen the @paulusmack comment?

[Lantizia]

Sorry in the middle of moving house and won't have a working place to do these kinds of tests for a while yet. Just answering this from my phone.