Marcos Dione writes: > > (The implementation I did for Solaris handles this case, but I don't > > know about other implementations.) > > implementation of pppoe? Yes. > > Having more than zero ADSL lines sounds like a bad idea to me. ;-} > > uh, I didn't get the joke :-| Oh, if you're dealing with ADSL and PPPoE for long, you will. Marcos Dione writes: > what I made of it is that, yes, I get a dup'ed SessionID (0x1aa5). is that, > or something more strange is happpening there. I don't see a dup'd session ID. In fact, it looks to me like you have four links to a single peer, which is not quite what I was expecting. In any event, that guess seems to be wrong. > 14:56:42.093739 PPPoE PADI [Service-Name] > 14:56:42.105918 PPPoE PADO [Service-Name] [AC-Name "CEN41R"] [AC-Cookie 0xFD45FA55D74DCAD58BA68DA04B2F1E49] > 14:56:42.108047 PPPoE PADO [Service-Name] [AC-Name "CEN41R"] [AC-Cookie 0xFD45FA55D74DCAD58BA68DA04B2F1E49] > 14:56:42.108700 PPPoE PADO [Service-Name] [AC-Name "CEN41R"] [AC-Cookie 0xFD45FA55D74DCAD58BA68DA04B2F1E49] > 14:56:42.110781 PPPoE PADO [Service-Name] [AC-Name "CEN41R"] [AC-Cookie 0xFD45FA55D74DCAD58BA68DA04B2F1E49] That looks possibly ok, though a little odd. The peer has seen your PADI on each of the four links and is responding separately on each. The "odd" part is that it uses the same cookie for each, but since that's for its use, it doesn't matter. > 14:56:42.231023 PPPoE PADS [ses 0x1aa5] [Service-Name] [AC-Cookie 0xFD45FA55D74DCAD58BA68DA04B2F1E49] > 14:56:42.344137 PPPoE PADS [ses 0x1aa8] [Service-Name] [AC-Cookie 0xFD45FA55D74DCAD58BA68DA04B2F1E49] > 14:56:42.373229 PPPoE PADS [Service-Name] [AC-Cookie 0xFD45FA55D74DCAD58BA68DA04B2F1E49] That one PADS is strange. Possibly broken. > 14:56:42.533969 PPPoE PADS [ses 0x1aa9] [Service-Name] [AC-Cookie 0xFD45FA55D74DCAD58BA68DA04B2F1E49] The rest look good. > 14:56:43.047465 PPPoE [ses 0x1aa5] LCP, Conf-Request (0x01), id 1, length 14 > 14:56:43.060355 PPPoE [ses 0x1aa5] LCP, Conf-Ack (0x02), id 1, length 14 Unfortunately, you posted text rather than giving a pointer to the actual trace, so it's hard to tell what's going on here. We need to see the senders for the messages. > 14:56:44.266669 PPPoE [ses 0x1aa5] PAP, Auth-Req (0x01), id 2, Peer fcq2@arnet-cordoba-apb, Name ciencia > 14:56:44.274237 PPPoE [ses 0x1aa5] LCP, Conf-Request (0x01), id 1, length 20 > 14:56:44.275196 PPPoE [ses 0x1aa5] LCP, Conf-Request (0x01), id 3, length 14 It sure looks like one side just can't hear the other, but at this level (text output), the trace is more than a bit ambiguous. I don't see the actual problem. -- 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
