|
|
| [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] |
On Fri, 2006-06-02 at 13:20 -0300, Marcos Dione wrote: > Quoting James Carlson <carlsonj@xxxxxxxxxxxxxxx>: > > You should gather logs with debug enabled and post the _entire_ log > > here. > > coming soon. > > > That sounds like an ID collision. I guess I can't say it for certain > > without seeing the packet traces, but it seems likely. > > how can I gather packet traces? tcpdump, or enabling debug is enought? > Ideally, both. Run tcpdump dump as: tcpdump -n -e -i eth???? ether proto 0x8863 or ether proto 0x8864 > >> 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. > > you mean, a buggy one? > The Linux kernel component identifies PPPoE sessions using (SID,MAC ADDR) pairs. Thus, it should handle this case correctly. (See /proc/net/pppoe for a current listing of active sessions.) -- Michal Ostrowski <mostrows@xxxxxxxxxxxxx> - 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