Setting up a PPP server to share an internet connection via serial port from Ubuntu to Windows

zigulinis7 · 08-30-2017, 11:00 AM

Hello,

I want to share my internet connection in Ubuntu computer to a Windows PC via a serial port using only a null-modem cable (no modems). In my Ubuntu computer I'm using mgetty to set up a PPP server and I have enabled an option direct y in mgetty.conf file for mgetty to answer calls from serial port, but when I try to set up a dial-up connection from Windows mgetty is not responding at all. I can send and receive data between both computers using serial terminal such as Cutecom, but can't get response from mgetty. It's already been more than a week since I've been trying to set a PPP server

, but with no success. Can anyone tell me what can be wrong with my config files or is there anything else that I am missing? Here are my config files:

mgetty.config

Code:

issue-file /etc/issue.mgetty
debug 5
port ttyUSB0
init-chat "" ATZ OK ATQ0E1 OK ATS0=0
direct y
data-only y
toggle-dtr n

login.config

Code:

/AutoPPP/ - - /usr/sbin/pppd file /etc/ppp/options.server
*	-	-	/bin/login @

dialin.config

Code:

/etc/ppp/options

Code:

debug
login
default-asyncmap
require-pap
proxyarp                   
ms-dns 192.168.1.254
ktune

/etc/ppp/options.server

Code:

debug
asyncmap 0
modem
crtscts
lock
require-pap
login
proxyarp                                                 
ms-dns 192.168.1.254                   
ms-dns 212.59.1.1

/etc/ppp/options.ttyUSB0

Code:

local
lock
nocrtscts
192.168.1.254:192.168.1.10
netmask 255.255.255.0
noauth     
debug

/etc/ppp/pap-secrets

Code:

# Every regular user can use PPP and has to use passwords from /etc/passwd
*	*	""	*
# Secrets for authentication using PAP
# client	server		secret		IP addresses
*		*		""		*

/etc/ppp/chap-secrets

Code:

# Secrets for authentication using CHAP
# client	server	secret			IP addresses
*   *   *   *

Since the innittab file is gone, I setup mgetty as a service with systemd.
create a service in /lib/systemd/system/mgetty.service

Code:

[Unit]
Description=Linea 1 Modem USB
Documentation=man:mgetty(8)
Requires=systemd-udev-settle.service
After=systemd-udev-settle.service

[Service]
Type=simple
ExecStart=/sbin/mgetty -x0 -s 115200 /dev/ttyUSB0
Restart=always
PIDFile=/var/run/mgetty.pid.ttyUSB0

[Install]
WantedBy=multi-user.target

then start and enable a service using these commands:
systemctl start mgetty.service
systemctl enable mgetty.service

ferrari · 08-30-2017, 05:24 PM

Can you show what is reported by the following (just in case that illuminates the issue)?

Code:

systemctl status mgetty

You could also observe the tail using

Code:

journalctl -fu mgetty

Then try to make a connection. Any response captured?

ferrari · 08-30-2017, 05:40 PM

I'm not familiar with using mgetty at all, but I note that it is designed to communicate with modem devices...

Quote:

mgetty is a modem-aware getty. It supports modems with the Hayes AT command set and is especially designed for supporting modems that are used to send faxes and to dial out as well as dial in. These features are not required for a serial console.

http://www.tldp.org/HOWTO/Remote-Ser...ty-mgetty.html

From reading the man page for mgetty, I note that if using a direct serial line the -r option is required....

Quote:

-r Tells mgetty that it is running on a direct line. UUCP locking is done, but no modem initialization whatsoever.

Same mentioned here...
http://mgetty.greenie.net/doc/mgetty_13.html

Quote:

If you have a direct serial line between two unix machines, or a unix machine and something else, and want to run a getty program on the unix side that should not interfere with outgoing traffic (e.g.: two unix machines, both sides running gettys, both sides able to initiate an uucp connection), you can also use mgetty. Start it with the `-r' flag (as with uugetty), and it will not try to initialize the modem or wait for RINGs. It will just sit silently on the port and wait...

Hope that helps.

zigulinis7 · 08-31-2017, 03:22 AM

Thank you for your quick response ferrari.
systemctl status mgetty gives:

Code:

● mgetty.service - Direct serial cable
   Loaded: loaded (/lib/systemd/system/mgetty.service; enabled; vendor preset: e
   Active: active (running) since Kt 2017-08-31 09:52:27 EEST; 59min ago
     Docs: man:mgetty(8)
 Main PID: 743 (mgetty)
   CGroup: /system.slice/mgetty.service
           └─743 /sbin/mgetty -x0 -s 115200 /dev/ttyUSB0

Rgp 31 09:52:27 mantas-Dimension-C521 systemd[1]: Started Direct serial cable.
lines 1-9/9 (END)

and journalctl -fu mgetty gives:

Code:

-- Logs begin at Kt 2017-08-31 09:52:10 EEST. --
Rgp 31 09:52:27 mantas-Dimension-C521 systemd[1]: Started Direct serial cable.

when I try to make a connection no response is captured here.
You must be right that mgetty is expecting for another type of AT commands that only a modem can generate, but isn't there a way for windows to pretend being a modem (to send Hayes AT commands)? I can't find a way I could somehow insert `-r' flag when dialing-up from windows, but I tried different modem models in Dial-up connection properties as well as "Communications cable between two computers" option, but nothing seems to help.

ferrari · 08-31-2017, 04:37 AM

Quote:

You must be right that mgetty is expecting for another type of AT commands that only a modem can generate, but isn't there a way for windows to pretend being a modem (to send Hayes AT commands)? I can't find a way I could somehow insert `-r' flag when dialing-up from windows, but I tried different modem models in Dial-up connection properties as well as "Communications cable between two computers" option, but nothing seems to help.

I'll be a little more explicit. Why don't you modify the service unit, so that mgetty is started with the -r option?

Code:

ExecStart=/sbin/mgetty -r -x0 -s 115200 /dev/ttyUSB0

ferrari · 08-31-2017, 04:41 AM

Following any changes you make to a unit file, don't forget to also do...

Code:

systemctl daemon-reload

Code:

systemctl restart mgetty

zigulinis7 · 08-31-2017, 05:57 AM

I have modified service unit as you said:

Code:

ExecStart=/sbin/mgetty -r -x0 -s 115200 /dev/ttyUSB0

and also used both of these commands:

Code:

systemctl daemon-reload

Code:

systemctl restart mgetty

When I run systemctl status mgetty now I see that it uses -r option when starting mgetty

Code:

● mgetty.service - Direct serial cable
   Loaded: loaded (/lib/systemd/system/mgetty.service; enabled; vendor preset: e
   Active: active (running) since Kt 2017-08-31 13:24:46 EEST; 15min ago
     Docs: man:mgetty(8)
 Main PID: 773 (mgetty)
   CGroup: /system.slice/mgetty.service
           └─773 /sbin/mgetty -r -x0 -s 115200 /dev/ttyUSB0

Rgp 31 13:24:46 mantas-Dimension-C521 systemd[1]: Started Direct serial cable.
lines 1-9/9 (END)

But still nothing happens when I try to make a connection

Code:

mantas@mantas-Dimension-C521:~$ journalctl -fu mgetty
-- Logs begin at Kt 2017-08-31 13:24:28 EEST. --
Rgp 31 13:24:46 mantas-Dimension-C521 systemd[1]: Started Direct serial cable.

zigulinis7 · 08-31-2017, 07:07 AM

I have figured out one thing: if I open a terminal in windows and send some AT command like:

Code:

ATQ0E1

I can get mgetty to respond:

Code:

Rgp 31 15:00:19 mantas-Dimension-C521 login[2968]: pam_unix(login:auth): check pass; user unknown
Rgp 31 15:00:19 mantas-Dimension-C521 login[2968]: pam_unix(login:auth): authentication failure; logname= uid=0 euid=0 tty=/dev/ttyUSB0 ruser= rhost=
Rgp 31 15:00:22 mantas-Dimension-C521 login[2968]: FAILED LOGIN (1) on '/dev/ttyUSB0' FOR 'UNKNOWN', Authentication failure

But when I try to make a dial-up connection mgetty doesn't respond at all.

ferrari · 08-31-2017, 07:49 PM

It could be useful to watch for ppp messages....

Code:

journalctl -f

or filtered...

Code:

journalctl -f | grep ppp

zigulinis7 · 09-01-2017, 01:58 AM

Command doesn't return anything:

Code:

mantas@mantas-Dimension-C521:~$ journalctl -f | grep ppp

It looks like Windows is sending wrong commands, because mgetty does answer to the right ones.

ferrari · 09-01-2017, 04:22 AM

With my (very) limited knowledge on the inner workings of this, I think I've gleamed that mgetty is listening on the line for modem-type behaviour. This means it is listening for the 'RING' message, then it will respond with ATA (answering an incoming call), then it expects to hear 'CONNECT'. Following that, it starts the process defined in login.config ie PPP (as per the config you posted). So the client program needs to initiate like that. The question is: Can Cutecom behave like that?

ferrari · 09-01-2017, 05:22 AM

Cancel that. The above related to standard mgetty behaviour, and the -r option should inhibit that, but I'm not clear on what is required to intiate the connection and start the pppd process. That got me thinking about whether the mgetty layer is really required here?

Here's a link to a page describing how to connect a Linux and Windows machine via a serial cable which has pppd listening to a serial port, and a 'direct cable connection' on the Windows machine...

http://www.linuxsolved.com/forums/index.php?topic=22.0

zigulinis7 · 09-01-2017, 07:55 AM

Thank you. I'll try this tutorial.