Can we run a PPP server & client simultaneously???
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
Signature · 2 lines
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.
Quoted 2 lines · LeeD
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.)
Quoted 3 lines
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.
Quoted 2 lines
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 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.
Signature · 1 line
James Carlson 42.703N 71.076W <[email protected]>
Quoted 7 lines · James Carlson
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.
Quoted 6 lines · Christopher Fowler
Quoted 5 lines · James Carlson
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.
Quoted 6 lines
Quoted 2 lines
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.
Quoted 7 lines
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.
Interesting.
Quoted 5 lines
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.
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.
Signature · 1 line
James Carlson 42.703N 71.076W <[email protected]>
Quoted 8 lines · James Carlson
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.
Quoted 3 lines · LeeD
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.
Quoted 4 lines
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.
Quoted 8 lines
I have seen server advertised which offer both PPP client and server, so how to they do it?
Regards,
Lee
Signature · 4 lines
William G. Unruh | Canadian Institute for| Tel: +1(604)822-3273 Physics&Astronomy | Advanced Research | Fax: +1(604)822-5324 UBC, Vancouver,BC | Program in Cosmology | [email protected] Canada V6T 1Z1 | and Gravity | www.theory.physics.ubc.ca/
Quoted 7 lines
Quoted 6 lines
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.
Quoted 5 lines
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 :-)
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