[c-nsp] PPPoE client answers PADI?

[Robert E.Seastrom]

Andre Beck <cisco-nsp at ibh.net> writes:

> Hi,
>
> when debugging a strange PPPoE problem in a wireless access infra-
> structure for which we provide IP access, we finally found that a
> client did not connect to our PPPoE server because it received more
> than one PADO to its PADI request. The first one to answer won, and
> now try to stay vertical: The box that answered the PADI with a PADO
> wasn't some rogue PPPoE server deployed by evil persons but actually
> one of our own deployed Cisco 831 PPPoE clients!

While that's clearly misbehavior on the part of the 831 and something
that you should take up with Cisco, it's also something you should
take up with your wireless equipment vendor; hostile customers should
be considered a likely, as opposed to an unlikely, eventuality.

I'm continually depressed with the feature set I find on wireless
equipment, and haven't been too happy with the "big picture" clue
level I've found among the software developers (no, I'm not going to
name names here).  It seems that the model for a lot of them has
evolved from roots of "outdoor 802.11 deployment", and that
requirements such as "PADI can only go from customer unit to AP and
PADO vice-versa" are met with blank stares, or more humorously, I'm
told that it would be "too difficult" or "too much of a performance
hit" to implement such a feature.  Please!  Discovery frames have a
different ether type (0x8863) than session frames (0x8864), so 99.99%
of packets don't have to be looked at beyond the ether_type.  Probably
a dozen lines of code to implement, and you don't even really have to
include a facility for turning it off.  Of course, their spec sheet
says that their equipment "supports RFC-2516 - PPPoE", but I'm not
sure what that's supposed to mean aside from the fact that the packets
go through.  And don't even get me started on priority queueing
schemes that break if the encapsulation is PPPoE rather than ARPA,
because someone was too lazy to check the ether_type and add a fixed
offset to where it expects the start of the IP header to live before
it does its classification.

And then there are shitty DHCP clients and ethernet chips that are
only capable of 10 meg HDX and can't do 802.1q (um, HELLO, it is 2005,
in what antique store did you find the spec sheet for this chip when
you were designing this unit last year?), but that's a rant for
another day.

Beat up your wireless vendor.  :)

                                        ---rob