Lines Matching refs:the
12 Q09: Starting the ipppd, I get only error messages from i4l
14 Q11: I can't connect. How can I check where the problem is.
22 here, the framing is character based. (e.g when
28 to the network layer and all PPP protocol
29 frames to the /dev/ippp* device.
30 So, the ipppd is a simple external network
33 If you login into a remote machine using the
34 /dev/ttyI* devices and then enable PPP on the
35 remote terminal server -> use the 'old' pppd
39 syncPPP machine .. use the network device part
40 of isdn4linux with the 'syncppp' encapsulation
41 and make sure, that the ipppd is running and
42 connected to at least one /dev/ippp*. Check the
47 Q02: when I start the ipppd .. I only get the
49 A: check that at least the device 'ippp0' exists.
50 (you can check this e.g with the program 'ifconfig')
56 A: Maybe you have compiled the ipppd with another
57 kernel source tree than the kernel you currently
62 Q03: when I list the netdevices with ifconfig I see, that
66 You need the HWaddr only for ethernet encapsulation.
76 To enable MPPP negotiation you must call the
77 ipppd with the '+mp' option.
79 every additional channel. (see the i4l manual
82 the 'master' or initial call. Now you can add
83 the slave channels with the command:
93 Q05: I tried MPPP but it doesn't work .. the ipppd
94 writes in the debug log something like:
98 A: you forgot to compile MPPP/RFC1717 support into the
104 over the network interface of isdn4linux ..
106 A: No .. that's not possible .. Use the standard
107 PPP package over the /dev/ttyI* devices. You
108 must not use the ipppd for this.
114 Checking the debug log I just saw garbage like:
115 !![ ... fill in the line ... ]!!
118 can't understand this ... try to use the ttyI*
119 devices with the standard PPP/pppd package
128 I found to do this is to kill the ipppd and
130 to the second machine.
138 Q09: When I start the ipppd I only get error messages
139 from the i4l driver ..
141 A: When starting, the ipppd calls functions which may
143 Without the ipppd (at this moment, it is not
145 Try to configure hostnames necessary for the ipppd
153 must I configure the network device.
156 a packet to the ippp network-interface to trigger
157 the dial-on-demand.
158 A default route to the ippp-interface will work.
161 If for some reason you can't set the default
162 route to the ippp interface, you may take any
163 address of the subnet from which you expect your
165 this subnet to the ippp interface.
166 To allow overriding of the dummy address you
167 must call the ipppd with the 'ipcp-accept-local' option.
169 A: You must know, how the ipppd gets the addresses it wanna
170 configure. If you don't give any option, the ipppd
171 tries to negotiate the local host address!
172 With the option 'noipdefault' it requests an address
173 from the remote machine. With 'useifip' it gets the
174 addresses from the net interface. Or you set the address
175 on the option line with the <a.b.c.d:e.f.g.h> option.
176 Note: the IP address of the remote machine must be configured
177 locally or the remote machine must send it in an IPCP request.
178 If your side doesn't know the IP address after negotiation, it
179 closes the connection!
180 You must allow overriding of address with the 'ipcp-accept-*'
181 options, if you have set your own or the remote address
188 where REMOTE must be the address of the remote machine (the
193 Q11: I can't connect. How can I check where the problem is.
195 A: A good help log is the debug output from the ipppd...
203 check the /dev/isdnctrl output next time. There
204 you can see, whether there is activity on the card/line.
205 - there are at least a few RECV messages in the log:
209 - the ipppd exits for some reason:
211 Could be a bug in the ipppd.