Package: pppoe Version: 3.5-4
Hi,
I had a pretty serious problem with my ISP on my DSL line several weeks ago: my connection failed one day without warning on a DSL timeout. As I am quite busy, it took me a while to track down the problem. I called my ISP but I didn't succeed in establishing connection. I was suspecting the quality of the line but neither my ISP or the telecom operator could track any problem with it. And finally, I tried with Mac OS X, and the connection succeeded, althought it still didn't work with rp-pppoe on debian.
The pppoe discovery returned me the following message: Ignoring PADO packet from non-unicast MAC address
until the discovery timed-out. I googled a little and I found out that I wasn't the only one getting this kind of error, althought it was rare and mostly happened for french linux users. While investigating the problem, I finally explorered the PPPoE protocol, and I had the following debug log:
rp-pppoe-3.5 23:20:09.189 SENT PPPoE Discovery (8863) PADI sess-id 0 length 4 SourceAddr 00:40:f4:4b:a2:f1 DestAddr ff:ff:ff:ff:ff:ff 01 01 00 00 ....
23:20:09.231 RCVD PPPoE Discovery (8863) PADO sess-id 0 length 35 SourceAddr 01:02:3b:01:bc:a8 DestAddr 00:40:f4:4b:a2:f1 01 01 00 00 01 02 00 17 36 32 30 36 38 31 32 30 ........62068120 31 30 30 30 34 38 2d 42 53 53 54 4c 31 39 37 01 100048-BSSTL197. 01 00 00 ...
23:20:14.228 SENT PPPoE Discovery (8863) PADI sess-id 0 length 4 SourceAddr 00:40:f4:4b:a2:f1 DestAddr ff:ff:ff:ff:ff:ff 01 01 00 00 ....
23:20:14.282 RCVD PPPoE Discovery (8863) PADO sess-id 0 length 35 SourceAddr 01:02:3b:01:bc:a8 DestAddr 00:40:f4:4b:a2:f1 01 01 00 00 01 02 00 17 36 32 30 36 38 31 32 30 ........62068120 31 30 30 30 34 38 2d 42 53 53 54 4c 31 39 37 01 100048-BSSTL197. 01 00 00 ...
23:20:19.278 SENT PPPoE Discovery (8863) PADI sess-id 0 length 4 SourceAddr 00:40:f4:4b:a2:f1 DestAddr ff:ff:ff:ff:ff:ff 01 01 00 00 ....
23:20:19.331 RCVD PPPoE Discovery (8863) PADO sess-id 0 length 35 SourceAddr 01:02:3b:01:bc:a8 DestAddr 00:40:f4:4b:a2:f1 01 01 00 00 01 02 00 17 36 32 30 36 38 31 32 30 ........62068120 31 30 30 30 34 38 2d 42 53 53 54 4c 31 39 37 01 100048-BSSTL197. 01 00 00 ...
I checked it several times, but it was true: the source address of the PADO was a multicast MAC address. I patched my local version of pppoe in order to accept multicast PADO packets, and I could immediatly reconnect to my ISP without troubles.
I read carefully the RFC-2516 and section 5.2 specifying the PADO packet, and for PADO, if the Destination Address if specified as a unicast MAC address, nothing is said about the Source Address, so I guess a Multicast Address is not strictly forbidden. Since Mac OS X allows multicast source address for PADO packet (and I guess Windows do it also, since I was the only one complaining for that at my ISP, but I have neither Windows or a x86 PC to verify my guess), since the RFC does not strictly forbid it and that some ISP seems to use this kind of tricks, I strongly suggest a less stricter policy on PADO packets, in order to allow the use of Multicast MAC source address. I included a trivial patch against rp-pppoe-3.5-4 (allowing Multicast source MAC address but forbidding nonetheless a Broadcast address, since I guess it would be a bit strange to allow it).
Please, check the patch, and the RFC.
Thank you for reading me. -- Stéphane Louise
diff -u src-orig/discovery.c src/discovery.c
--- src-orig/discovery.c 2005-02-05 18:59:38.000000000 +0100
+++ src/discovery.c 2005-02-05 19:08:53.000000000 +0100
@@ -367,8 +367,8 @@
if (!packetIsForMe(conn, &packet)) continue;
if (packet.code == CODE_PADO) {
- if (NOT_UNICAST(packet.ethHdr.h_source)) {
- printErr("Ignoring PADO packet from non-unicast MAC address");
+ if (BROADCAST(packet.ethHdr.h_source)) {
+ printErr("Ignoring broadcasted PADO packet");
continue;
}
parsePacket(&packet, parsePADOTags, &pc);
Common subdirectories: src-orig/libevent and src/libevent
Common subdirectories: src-orig/obsolete and src/obsolete
Common subdirectories: src-orig/plugin and src/plugin
