Marcos Dione writes: > I'm setting up a machine with 4 ADSL lines connected to the same nic via a > switch. I'm not sure this is `supported´ or if I should add the 3 extra nics > it `should´ have. I'll assume you're using PPPoE. That should work, though it's tough for the client implementation to get it right because of design flaws in the PPPoE protocol itself. Namely, it's asymmetric, and it uses a single session ID assigned by the server. Since you're talking to multiple servers and each can assign its own session ID to you, there's the possibility of overlap (two servers picking the same session ID number). When this happens, the client must demultiplex based on Ethernet address. It's a bit messy. You can tell if this is the problem by getting packet traces on the Ethernet. Specifically, you'll see PPPoE PADS (session confirmation) messages with the same SESSION_ID number but with different source Ethernet addresses. If that happens, and if the client isn't clever, you can get some serious trouble. (The implementation I did for Solaris handles this case, but I don't know about other implementations.) > Jun 1 12:21:16 pigmea pppd[14214]: Received bad configure-ack: 05 06 35 a7 70 > 57 07 02 You should gather logs with debug enabled and post the _entire_ log here. That message means that the peer sent a Configure-Ack message that did not correspond to the Configure-Request we sent. That's illegal (per the RFCs), so we discard the message as required. Here are some of the things that can cause this: - Bugs in the peer implementation. - Confusion due to the session ID collision case I described above. - Data corruption due to bugs in the local implementation. > it goes like this on and on. this is mostly haoppening for 2 of the pppd at > the same time. it logs that for a long while, then it logs this: That sounds like an ID collision. I guess I can't say it for certain without seeing the packet traces, but it seems likely. > I'm starting to think that those are configure-acks `routed´ to the wrong > pppd, because if I bring up one line at a time, all establish the connection > succesfully. I just wanted to make sure I was reaching to the correct > conclusion. Yes, it sounds like that. If so, then it's a problem in the PPPoE implementation (likely in the kernel) and not in pppd. > also, would it be possible to make pppd abort if too much bad > configure-acks? since I'm the one with the problem, I'm interested in hacking > that. do you think it does any sense, or should I stop doing stupid things and > put one nic per ADSL line? Having more than zero ADSL lines sounds like a bad idea to me. ;-} Certainly, you could fix it to do that. It seems fairly reasonable to have a bound on the number of correctly-formed-but-senseless packets like this one (i.e., ones that have proper FCS and length fields, but that are not meaningful in the current context). However, I don't think that's really a fix for the problem. Finding out whether the system is in fact mis-delivering those packets is the first step. If it is, finding out why that's so and getting at the root cause of the problem should be the next step. Changing the response to bad packets as some sort of work-around for a deeper problem seems like a hack. -- James Carlson 42.703N 71.076W <carlsonj@xxxxxxxxxxxxxxx> - To unsubscribe from this list: send the line "unsubscribe linux-ppp" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
