-- With most respectful, we seek your service as our company representative. For more informations,get back to us. Mr Zheng Xiaohua - To unsubscribe from this list: send the line "unsubscribe linux-ppp" in the body of a message to majordomo <at> vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Is it possible for linux to support both a PPP server and PPP client (with dial on demand) simultaneously on the same serial port? I have a PPP client setup to support dial on demand, however this locks the serial port preventing any call answering programs (such as mgetty) from using the same serial port and modem. I have seen server advertised which offer both PPP client and server, so how to they do it? Regards, Lee -- -- View this message in context: http://www.nabble.com/Can-we-run-a-PPP-server---client-simultaneously----tf4128929.html#a11741524 Sent from the linux-ppp mailing list archive at Nabble.com. - To unsubscribe from this list: send the line "unsubscribe linux-ppp" in the body of a message to majordomo <at> vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
LeeD writes: > Is it possible for linux to support both a PPP server and PPP client (with > dial on demand) simultaneously on the same serial port? They can't be _active_ at the same time, but two defined PPP instances can share a single serial port. (PPP doesn't have servers or clients.) > I have a PPP client setup to support dial on demand, however this locks the > serial port preventing any call answering programs (such as mgetty) from > using the same serial port and modem. It's not supposed to do that. In pppd, main.c blocks for demand first (waiting for packets in handle_events()), and only calls start_link() -- which ends up locking the port only when requested via the 'lock' option -- when there's actual traffic. So, I don't see how the current code could do what you're describing, but I'd guess that this is a bug of some sort. > I have seen server advertised which offer both PPP client and server, so how > to they do it? That's a much more complicated question, I think, because you end up having to deal with 'attaching' an inbound connection to an existing IP interface configured as demand dial. This is something that I think Linux cannot currently do. On the Annex communications server, we wrote special demand-dial management code to look up a dormant interface by address and bring it to life when the peer called us. That way, the return traffic (reply(Continue reading)
Christopher Fowler writes: > On Mon, 2007-07-23 at 07:59 -0400, James Carlson wrote: > > On the Annex communications server, we wrote special demand-dial > > management code to look up a dormant interface by address and bring it > > to life when the peer called us. That way, the return traffic (reply > > packets) wouldn't trigger an outbound attempt that would fail. > > > > On Linux, you may be able to get away with it if both links have > > different sets of IP addresses. > > You can do it on Linux. I have hundreds doing this. Yes you do have 2 > interfaces. I'm curious as to details on how you solved it on the > Annex. The advantages of having a single address space unobstructed by an MMU -- we simply had a global table of demand links and matched inbound links against that table before creating a new interface. If it matched, then we'd attach to the interface in that table, otherwise create a new one. The internal design of the Annex is really quite different from Linux. The PPP code there wasn't based on pppd. > They way we solved it is via if-down and if-up. That is a C > program on our device. When pppd calls that program it looks for an > interface that is in the UP state but not our own. It places that > interface in the DOWN state. When if-down is called it looks for an > interface that is DOWN but not our own and it places that in UP. The > effect is that you'll end up with 2 ppp interfaces with the same > address. Only one is UP.(Continue reading)
On Mon, 2007-07-23 at 08:28 -0400, James Carlson wrote: > I think that process may have race conditions, given that if-up is > triggered after the interface is marked 'UP', and nothing in the > system actually waits for that script to complete. For that reason, I > wouldn't suggest that as a design for a new feature in the pppd code > base. > > Otherwise, though, it seems like a somewhat reasonable solution for a > pppd user. CORRECT! I do not suggest this as a design for future pppd based code. It really needs not to be. It is a design based on what we have and what we needed to do to make it work. I'm always looking for improvements. Also I do have changes to pppd 2.4.2 that anyone can have. We changed that version to allow us to specify multiple ttys on the command line. This allowed us to support outbound pooling with pppd. /usr/sbin/pppd ttyR0,ttyR1,ttyR2,... 57600 .... Works like that. When the pppd process needs to call a remote it will look for lock files and use the first available tty. This feature I would suggest as something that should be added since it is useful in a a demand implementation. Inbound pooling is handled by a single DID and hunt group on those lines. If the multiple tty feature is something you guys might like to add just let me know and I'll tarball our source and make it available. It is considered a derivative work of pppd since we modified the source.(Continue reading)
On Mon, 2007-07-23 at 07:59 -0400, James Carlson wrote: > On the Annex communications server, we wrote special demand-dial > management code to look up a dormant interface by address and bring it > to life when the peer called us. That way, the return traffic (reply > packets) wouldn't trigger an outbound attempt that would fail. > > On Linux, you may be able to get away with it if both links have > different sets of IP addresses. You can do it on Linux. I have hundreds doing this. Yes you do have 2 interfaces. I'm curious as to details on how you solved it on the Annex. They way we solved it is via if-down and if-up. That is a C program on our device. When pppd calls that program it looks for an interface that is in the UP state but not our own. It places that interface in the DOWN state. When if-down is called it looks for an interface that is DOWN but not our own and it places that in UP. The effect is that you'll end up with 2 ppp interfaces with the same address. Only one is UP. I've had this working for a couple years now and I've not had any problems. I think the only problem I could see is if pppd died and never called if-down. You would end up with a PPP interface in the DOWN state and the remote could never call home. Calling from the server would rectify the situation. - To unsubscribe from this list: send the line "unsubscribe linux-ppp" in the body of a message to majordomo <at> vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html(Continue reading)
On Mon, 23 Jul 2007, LeeD wrote: > > Is it possible for linux to support both a PPP server and PPP client (with > dial on demand) simultaneously on the same serial port? ppp is peer to peer, so any ppp is both a client and a server at the same time. However one serial port or modem can only be used for one connection at a time. not for more than one at a time. > > I have a PPP client setup to support dial on demand, however this locks the > serial port preventing any call answering programs (such as mgetty) from > using the same serial port and modem. Stop using dial on demand. It is completely useless when you are connected as a server anyway. Ie, if you want to use outgoing ppp, just run a progrm to start it instead of trying to do on demand. > > I have seen server advertised which offer both PPP client and server, so how > to they do it? > > Regards, > > Lee > -- -- William G. Unruh | Canadian Institute for| Tel: +1(604)822-3273(Continue reading)
>> >> I have a PPP client setup to support dial on demand, however this >> locks the >> serial port preventing any call answering programs (such as mgetty) from >> using the same serial port and modem. > > Stop using dial on demand. It is completely useless when you are > connected > as a server anyway. Ie, if you want to use outgoing ppp, just run a > progrm > to start it instead of trying to do on demand. Sorry Bill I forgot to mention that I'm using the linux box as a GPRS router. When any PC connected to my Linux router box accesses any thing remotely, the router will automatically fire up the GPRS modem. This bit works well(Continue reading)However I'd like the ability to dial up the router from work and poll a few devices connected to it. Since I only have one serial port and one modem, it would be nice to configure the Linux box to support dial-on-demand and as a dial up server. Regards, Lee - To unsubscribe from this list: send the line "unsubscribe linux-ppp" in the body of a message to majordomo <at> vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hello, the build with the attached .config failed, make ends with: ... CC arch/i386/lib/usercopy.o AR arch/i386/lib/lib.a GEN .version CHK include/linux/compile.h UPD include/linux/compile.h CC init/version.o LD init/built-in.o LD .tmp_vmlinux1 drivers/built-in.o: In function `pppol2tp_getsockopt': pppol2tp.c:(.text+0x454dd): undefined reference to `udp_prot' drivers/built-in.o: In function `pppol2tp_setsockopt': pppol2tp.c:(.text+0x46771): undefined reference to `udp_prot' drivers/built-in.o: In function `pppol2tp_sendmsg': pppol2tp.c:(.text+0x4753d): undefined reference to `ip_queue_xmit' drivers/built-in.o: In function `pppol2tp_xmit': pppol2tp.c:(.text+0x47a64): undefined reference to `ip_queue_xmit' make: *** [.tmp_vmlinux1] Error 1 The build was made with : $> make mrproper && make rndconfig && <tweak it to ThinkPad T41> && make oldconfig && make Here's the config: # # Automatically generated make config: don't edit # Linux kernel version: 2.6.23-rc1(Continue reading)
Hello, based on the eap/tls extension pppd 2.4.3 - eaptls 0.7 we found at http://eaptls.spe.net/download.html we extended ppp to be able use use smartcards for authentication. We would like to contribute this code for incorporation in ppp, if there is no other extension for this available. Are you interested in this patch? if so: Which license should this extension have? Regards Norbert Wegener - To unsubscribe from this list: send the line "unsubscribe linux-ppp" in the body of a message to majordomo <at> vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RSS Feed5 | |
|---|---|
9 | |
12 | |
2 | |
6 | |
7 | |
4 | |
8 | |
1 | |
2 | |
24 | |
13 | |
44 | |
7 | |
10 | |
25 | |
18 | |
11 | |
12 | |
63 | |
34 | |
40 | |
36 | |
34 | |
23 | |
7 | |
21 | |
73 | |
25 | |
2 | |
13 | |
3 | |
21 | |
5 | |
6 | |
21 | |
4 | |
17 | |
10 | |
21 | |
8 | |
14 | |
43 | |
29 | |
66 | |
51 | |
16 | |
8 | |
16 | |
24 | |
9 | |
19 | |
7 | |
47 | |
14 | |
3 | |
6 | |
7 | |
5 | |
13 | |
3 | |
12 | |
31 | |
23 | |
21 | |
41 | |
8 | |
10 | |
18 | |
54 | |
27 | |
14 | |
19 | |
25 | |
15 | |
17 | |
36 | |
20 | |
7 | |
19 | |
35 | |
43 | |
36 | |
15 | |
43 | |
65 | |
44 | |
10 | |
36 | |
54 | |
19 | |
62 | |
36 | |
44 | |
31 | |
45 | |
42 | |
29 | |
26 | |
32 | |
63 | |
32 | |
42 | |
41 | |
34 | |
44 | |
54 | |
45 | |
158 | |
64 | |
61 | |
162 | |
74 | |
26 | |
54 | |
39 |
