Problems conecting with Dreampi 1.4

Online games, how to get online, and anything involving Dreamcast online can be discussed here.

Moderator: pcwzrd13

kazade
Developer
Posts: 264

Re: Problems conecting with Dreampi 1.4

Post#11 » Mon Oct 17, 2016 11:40 am

I'll sort it ;)

Thanks!

Neoblast
Developer
Posts: 610

Re: Problems conecting with Dreampi 1.4

Post#12 » Tue Oct 18, 2016 5:53 pm

kazade wrote:I'll sort it ;)

Thanks!


Heh! Now all games manage to connect without issues (including DK3, which was somewhat picky until the timeout change) except for Planet Ring. I only got it to work with dream pi once out of 20 attempts or so. Why is this? It connects fine with the dc-pc I have setup in my laptop, but It'd be more comfortable to have it work on the pi.
Nice try you fool! lol BBQ!

pelvicthrustman
rebel
Posts: 15

Re: Problems conecting with Dreampi 1.4

Post#13 » Wed Nov 02, 2016 12:22 am

Not sure if this is the best place, but figured I'd post my issues with 1.4 (my first time using DreamPi)

To start things off I already have a working line voltage inducer (connected to a 1440A modem on an american Dreamcast) and I can readily get online with PSO using using mgetty+ppp on a Linux box, just trying out DreamPi (with an old RPi B+ model).

I'm using a US Robotics 5637 modem (I have upgraded the firmware so that it supports voice...weird comment I know but nothing in DreamPi works without the firmware update, in case anyone else has issues with this model modem).

Most everything seems to work until I get:
AT+VSM=1,8000
ERROR

I tried a few other values based on this table:
AT+VSM=?
0,"SIGNED PCM",8,0,(8000),(0),(0)
1,"UNSIGNED PCM",8,0,(8000),(0),(0)
4,"G.711U",8,0,(8000),(0),(0)
5,"G.711A",8,0,(8000),(0),(0)
128,"8-BIT LINEAR",8,0,(8000),(0),(0)
129,"ADPCM (NOT IMPLEMENTED)",0,0,(0),(0),(0)
130,"UNSIGNED PCM",8,0,(8000),(0),(0)
131,"G.711 ULAW",8,0,(8000),(0),(0)
132,"G.711 ALAW",8,0,(8000),(0),(0)

128 and 132 work like a charm, 0 and 1 throw ERROR.

Snippet of the syslog (no other errors show above this point):

Nov 2 02:54:36 dreampi AT+VSM=1,8000
Nov 2 02:54:36 dreampi ERROR
Nov 2 02:54:36 dreampi AT+VTX
Nov 2 02:54:36 dreampi CONNECT
Nov 2 02:56:13 dreampi avahi-daemon[2257]: Withdrawing address record for 192.168.1.39 on eth0.
Nov 2 02:56:13 dreampi avahi-daemon[2257]: Leaving mDNS multicast group on interface eth0.IPv4 with address 192.168.1.39.
Nov 2 02:56:13 dreampi avahi-daemon[2257]: Interface eth0.IPv4 no longer relevant for mDNS.
Nov 2 02:56:14 dreampi dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 6
Nov 2 02:56:15 dreampi dhclient: DHCPREQUEST on eth0 to 255.255.255.255 port 67
Nov 2 02:56:15 dreampi dhclient: DHCPOFFER from 192.168.1.1
Nov 2 02:56:15 dreampi dhclient: DHCPACK from 192.168.1.1
Nov 2 02:56:15 dreampi avahi-daemon[2257]: Joining mDNS multicast group on interface eth0.IPv4 with address 192.168.1.39.
Nov 2 02:56:15 dreampi avahi-daemon[2257]: New relevant interface eth0.IPv4 for mDNS.
Nov 2 02:56:15 dreampi avahi-daemon[2257]: Registering new address record for 192.168.1.39 on eth0.IPv4.
Nov 2 02:56:15 dreampi dhclient: bound to 192.168.1.39 -- renewal in 241 seconds.
Nov 2 03:00:16 dreampi dhclient: DHCPREQUEST on eth0 to 192.168.1.1 port 67
Nov 2 03:00:16 dreampi dhclient: DHCPACK from 192.168.1.1
Nov 2 03:00:17 dreampi dhclient: bound to 192.168.1.39 -- renewal in 257 seconds.
Nov 2 03:04:34 dreampi dhclient: DHCPREQUEST on eth0 to 192.168.1.1 port 67
Nov 2 03:04:34 dreampi dhclient: DHCPACK from 192.168.1.1
Nov 2 03:04:34 dreampi dhclient: bound to 192.168.1.39 -- renewal in 255 seconds.
Nov 2 03:08:08 dreampi Heard: 5
Nov 2 03:08:10 dreampi ATH0
Nov 2 03:08:10 dreampi OK
Nov 2 03:08:10 dreampi ATZ0
Nov 2 03:08:11 dreampi OK
Nov 2 03:08:11 dreampi ATE0
Nov 2 03:08:11 dreampi OK
Nov 2 03:08:18 dreampi Call answered!
Nov 2 03:08:19 dreampi
Nov 2 03:08:19 dreampi Connected
Nov 2 03:08:19 dreampi pppd[13405]: pppd 2.4.5 started by root, uid 0
Nov 2 03:08:19 dreampi pppd[13405]: using channel 2
Nov 2 03:08:19 dreampi Serial interface terminated
Nov 2 03:08:19 dreampi pppd[13405]: Using interface ppp0
Nov 2 03:08:19 dreampi pppd[13405]: Connect: ppp0 <--> /dev/ttyACM0
Nov 2 03:08:19 dreampi pppd[13405]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x43273596> <pcomp> <accomp>]
Nov 2 03:08:19 dreampi MAC address: 42ac6c8be687ea7c124f466453440db6c5c658169be196950c4d57c67f5b99f6
Nov 2 03:08:22 dreampi pppd[13405]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x43273596> <pcomp> <accomp>]
Nov 2 03:08:25 dreampi pppd[13405]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x43273596> <pcomp> <accomp>]
Nov 2 03:08:28 dreampi pppd[13405]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x43273596> <pcomp> <accomp>]
Nov 2 03:08:31 dreampi pppd[13405]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x43273596> <pcomp> <accomp>]
Nov 2 03:08:34 dreampi pppd[13405]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x43273596> <pcomp> <accomp>]
Nov 2 03:08:37 dreampi pppd[13405]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x43273596> <pcomp> <accomp>]
Nov 2 03:08:40 dreampi pppd[13405]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x43273596> <pcomp> <accomp>]
Nov 2 03:08:43 dreampi pppd[13405]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x43273596> <pcomp> <accomp>]
Nov 2 03:08:46 dreampi pppd[13405]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x43273596> <pcomp> <accomp>]
Nov 2 03:08:49 dreampi pppd[13405]: LCP: timeout sending Config-Requests
Nov 2 03:08:49 dreampi pppd[13405]: Connection terminated.
Nov 2 03:08:49 dreampi pppd[13405]: Receive serial link is not 8-bit clean:
Nov 2 03:08:49 dreampi pppd[13405]: Problem: all had bit 7 set to 0
Nov 2 03:08:49 dreampi avahi-daemon[2257]: Withdrawing workstation service for ppp0.
Nov 2 03:08:49 dreampi dhclient: DHCPREQUEST on eth0 to 192.168.1.1 port 67
Nov 2 03:08:49 dreampi dhclient: DHCPACK from 192.168.1.1
Nov 2 03:08:50 dreampi pppd[13405]: Modem hangup
Nov 2 03:08:50 dreampi pppd[13405]: Exit.
Nov 2 03:08:50 dreampi Detected modem hang up, going back to listening

No clue why ppp doesn't get anything - when the dialing process starts the dreampi reacts accordingly
and proceeds to set up the connection, then fail.

And for comparison this is what it looks like when I use mgetty+ppp on my Ubuntu machine:

Nov 1 22:18:02 Troll pppd[2770]: pppd 2.4.5 started by root, uid 0
Nov 1 22:18:02 Troll pppd[2770]: using channel 1
Nov 1 22:18:02 Troll pppd[2770]: Using interface ppp0
Nov 1 22:18:02 Troll pppd[2770]: Connect: ppp0 <--> /dev/ttyACM0
Nov 1 22:18:02 Troll pppd[2770]: sent [LCP ConfReq id=0x1 <auth pap> <magic 0xbb6acd99> <pcomp> <accomp>]
Nov 1 22:18:02 Troll pppd[2770]: rcvd [LCP ConfAck id=0x1 <auth pap> <magic 0xbb6acd99> <pcomp> <accomp>]
Nov 1 22:18:05 Troll pppd[2770]: rcvd [LCP ConfReq id=0x2 <mru 1500> <asyncmap 0xa0000> <magic 0x1240c598>]
Nov 1 22:18:05 Troll pppd[2770]: sent [LCP ConfRej id=0x2 <asyncmap 0xa0000>]
Nov 1 22:18:05 Troll pppd[2770]: sent [LCP ConfReq id=0x1 <auth pap> <magic 0xbb6acd99> <pcomp> <accomp>]
Nov 1 22:18:05 Troll pppd[2770]: rcvd [LCP ConfReq id=0x3 <mru 1500> <magic 0x1240c598>]
Nov 1 22:18:05 Troll pppd[2770]: sent [LCP ConfAck id=0x3 <mru 1500> <magic 0x1240c598>]
Nov 1 22:18:05 Troll pppd[2770]: rcvd [LCP ConfAck id=0x1 <auth pap> <magic 0xbb6acd99> <pcomp> <accomp>]
Nov 1 22:18:05 Troll pppd[2770]: rcvd [PAP AuthReq id=0x4 user="administrator" password=<hidden>]
Nov 1 22:18:05 Troll pppd[2770]: Initializing PAM (3) for user administrator
Nov 1 22:18:05 Troll pppd[2770]: ---> PAM INIT Result = 0
Nov 1 22:18:05 Troll pppd[2770]: Attempting PAM authentication
Nov 1 22:18:05 Troll pppd[2770]: PAM Authentication OK for administrator
Nov 1 22:18:05 Troll pppd[2770]: Attempting PAM account checks
Nov 1 22:18:05 Troll pppd[2770]: PAM Account OK for administrator
Nov 1 22:18:05 Troll pppd[2770]: PAM Session opened for user administrator
Nov 1 22:18:05 Troll pppd[2770]: user administrator logged in on tty ttyACM0 intf ppp0
Nov 1 22:18:05 Troll pppd[2770]: PAP peer authentication succeeded for administrator
Nov 1 22:18:05 Troll kernel: [ 265.501266] PPP BSD Compression module registered

Any suggestions would be much appreciated!
Thanks for the hard work!

User avatar
Xiden
Developer
Posts: 2219

Re: Problems conecting with Dreampi 1.4

Post#14 » Wed Nov 02, 2016 9:40 am

pelvicthrustman wrote:Not sure if this is the best place, but figured I'd post my issues with 1.4 (my first time using DreamPi)

To start things off I already have a working line voltage inducer (connected to a 1440A modem on an american Dreamcast) and I can readily get online with PSO using using mgetty+ppp on a Linux box, just trying out DreamPi (with an old RPi B+ model).

I'm using a US Robotics 5637 modem (I have upgraded the firmware so that it supports voice...weird comment I know but nothing in DreamPi works without the firmware update, in case anyone else has issues with this model modem).

Most everything seems to work until I get:
AT+VSM=1,8000
ERROR

I tried a few other values based on this table:
AT+VSM=?
0,"SIGNED PCM",8,0,(8000),(0),(0)
1,"UNSIGNED PCM",8,0,(8000),(0),(0)
4,"G.711U",8,0,(8000),(0),(0)
5,"G.711A",8,0,(8000),(0),(0)
128,"8-BIT LINEAR",8,0,(8000),(0),(0)
129,"ADPCM (NOT IMPLEMENTED)",0,0,(0),(0),(0)
130,"UNSIGNED PCM",8,0,(8000),(0),(0)
131,"G.711 ULAW",8,0,(8000),(0),(0)
132,"G.711 ALAW",8,0,(8000),(0),(0)

128 and 132 work like a charm, 0 and 1 throw ERROR.

Snippet of the syslog (no other errors show above this point):

Nov 2 02:54:36 dreampi AT+VSM=1,8000
Nov 2 02:54:36 dreampi ERROR
Nov 2 02:54:36 dreampi AT+VTX
Nov 2 02:54:36 dreampi CONNECT
Nov 2 02:56:13 dreampi avahi-daemon[2257]: Withdrawing address record for 192.168.1.39 on eth0.
Nov 2 02:56:13 dreampi avahi-daemon[2257]: Leaving mDNS multicast group on interface eth0.IPv4 with address 192.168.1.39.
Nov 2 02:56:13 dreampi avahi-daemon[2257]: Interface eth0.IPv4 no longer relevant for mDNS.
Nov 2 02:56:14 dreampi dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 6
Nov 2 02:56:15 dreampi dhclient: DHCPREQUEST on eth0 to 255.255.255.255 port 67
Nov 2 02:56:15 dreampi dhclient: DHCPOFFER from 192.168.1.1
Nov 2 02:56:15 dreampi dhclient: DHCPACK from 192.168.1.1
Nov 2 02:56:15 dreampi avahi-daemon[2257]: Joining mDNS multicast group on interface eth0.IPv4 with address 192.168.1.39.
Nov 2 02:56:15 dreampi avahi-daemon[2257]: New relevant interface eth0.IPv4 for mDNS.
Nov 2 02:56:15 dreampi avahi-daemon[2257]: Registering new address record for 192.168.1.39 on eth0.IPv4.
Nov 2 02:56:15 dreampi dhclient: bound to 192.168.1.39 -- renewal in 241 seconds.
Nov 2 03:00:16 dreampi dhclient: DHCPREQUEST on eth0 to 192.168.1.1 port 67
Nov 2 03:00:16 dreampi dhclient: DHCPACK from 192.168.1.1
Nov 2 03:00:17 dreampi dhclient: bound to 192.168.1.39 -- renewal in 257 seconds.
Nov 2 03:04:34 dreampi dhclient: DHCPREQUEST on eth0 to 192.168.1.1 port 67
Nov 2 03:04:34 dreampi dhclient: DHCPACK from 192.168.1.1
Nov 2 03:04:34 dreampi dhclient: bound to 192.168.1.39 -- renewal in 255 seconds.
Nov 2 03:08:08 dreampi Heard: 5
Nov 2 03:08:10 dreampi ATH0
Nov 2 03:08:10 dreampi OK
Nov 2 03:08:10 dreampi ATZ0
Nov 2 03:08:11 dreampi OK
Nov 2 03:08:11 dreampi ATE0
Nov 2 03:08:11 dreampi OK
Nov 2 03:08:18 dreampi Call answered!
Nov 2 03:08:19 dreampi
Nov 2 03:08:19 dreampi Connected
Nov 2 03:08:19 dreampi pppd[13405]: pppd 2.4.5 started by root, uid 0
Nov 2 03:08:19 dreampi pppd[13405]: using channel 2
Nov 2 03:08:19 dreampi Serial interface terminated
Nov 2 03:08:19 dreampi pppd[13405]: Using interface ppp0
Nov 2 03:08:19 dreampi pppd[13405]: Connect: ppp0 <--> /dev/ttyACM0
Nov 2 03:08:19 dreampi pppd[13405]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x43273596> <pcomp> <accomp>]
Nov 2 03:08:19 dreampi MAC address: 42ac6c8be687ea7c124f466453440db6c5c658169be196950c4d57c67f5b99f6
Nov 2 03:08:22 dreampi pppd[13405]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x43273596> <pcomp> <accomp>]
Nov 2 03:08:25 dreampi pppd[13405]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x43273596> <pcomp> <accomp>]
Nov 2 03:08:28 dreampi pppd[13405]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x43273596> <pcomp> <accomp>]
Nov 2 03:08:31 dreampi pppd[13405]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x43273596> <pcomp> <accomp>]
Nov 2 03:08:34 dreampi pppd[13405]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x43273596> <pcomp> <accomp>]
Nov 2 03:08:37 dreampi pppd[13405]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x43273596> <pcomp> <accomp>]
Nov 2 03:08:40 dreampi pppd[13405]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x43273596> <pcomp> <accomp>]
Nov 2 03:08:43 dreampi pppd[13405]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x43273596> <pcomp> <accomp>]
Nov 2 03:08:46 dreampi pppd[13405]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x43273596> <pcomp> <accomp>]
Nov 2 03:08:49 dreampi pppd[13405]: LCP: timeout sending Config-Requests
Nov 2 03:08:49 dreampi pppd[13405]: Connection terminated.
Nov 2 03:08:49 dreampi pppd[13405]: Receive serial link is not 8-bit clean:
Nov 2 03:08:49 dreampi pppd[13405]: Problem: all had bit 7 set to 0
Nov 2 03:08:49 dreampi avahi-daemon[2257]: Withdrawing workstation service for ppp0.
Nov 2 03:08:49 dreampi dhclient: DHCPREQUEST on eth0 to 192.168.1.1 port 67
Nov 2 03:08:49 dreampi dhclient: DHCPACK from 192.168.1.1
Nov 2 03:08:50 dreampi pppd[13405]: Modem hangup
Nov 2 03:08:50 dreampi pppd[13405]: Exit.
Nov 2 03:08:50 dreampi Detected modem hang up, going back to listening

No clue why ppp doesn't get anything - when the dialing process starts the dreampi reacts accordingly
and proceeds to set up the connection, then fail.

And for comparison this is what it looks like when I use mgetty+ppp on my Ubuntu machine:

Nov 1 22:18:02 Troll pppd[2770]: pppd 2.4.5 started by root, uid 0
Nov 1 22:18:02 Troll pppd[2770]: using channel 1
Nov 1 22:18:02 Troll pppd[2770]: Using interface ppp0
Nov 1 22:18:02 Troll pppd[2770]: Connect: ppp0 <--> /dev/ttyACM0
Nov 1 22:18:02 Troll pppd[2770]: sent [LCP ConfReq id=0x1 <auth pap> <magic 0xbb6acd99> <pcomp> <accomp>]
Nov 1 22:18:02 Troll pppd[2770]: rcvd [LCP ConfAck id=0x1 <auth pap> <magic 0xbb6acd99> <pcomp> <accomp>]
Nov 1 22:18:05 Troll pppd[2770]: rcvd [LCP ConfReq id=0x2 <mru 1500> <asyncmap 0xa0000> <magic 0x1240c598>]
Nov 1 22:18:05 Troll pppd[2770]: sent [LCP ConfRej id=0x2 <asyncmap 0xa0000>]
Nov 1 22:18:05 Troll pppd[2770]: sent [LCP ConfReq id=0x1 <auth pap> <magic 0xbb6acd99> <pcomp> <accomp>]
Nov 1 22:18:05 Troll pppd[2770]: rcvd [LCP ConfReq id=0x3 <mru 1500> <magic 0x1240c598>]
Nov 1 22:18:05 Troll pppd[2770]: sent [LCP ConfAck id=0x3 <mru 1500> <magic 0x1240c598>]
Nov 1 22:18:05 Troll pppd[2770]: rcvd [LCP ConfAck id=0x1 <auth pap> <magic 0xbb6acd99> <pcomp> <accomp>]
Nov 1 22:18:05 Troll pppd[2770]: rcvd [PAP AuthReq id=0x4 user="administrator" password=<hidden>]
Nov 1 22:18:05 Troll pppd[2770]: Initializing PAM (3) for user administrator
Nov 1 22:18:05 Troll pppd[2770]: ---> PAM INIT Result = 0
Nov 1 22:18:05 Troll pppd[2770]: Attempting PAM authentication
Nov 1 22:18:05 Troll pppd[2770]: PAM Authentication OK for administrator
Nov 1 22:18:05 Troll pppd[2770]: Attempting PAM account checks
Nov 1 22:18:05 Troll pppd[2770]: PAM Account OK for administrator
Nov 1 22:18:05 Troll pppd[2770]: PAM Session opened for user administrator
Nov 1 22:18:05 Troll pppd[2770]: user administrator logged in on tty ttyACM0 intf ppp0
Nov 1 22:18:05 Troll pppd[2770]: PAP peer authentication succeeded for administrator
Nov 1 22:18:05 Troll kernel: [ 265.501266] PPP BSD Compression module registered

Any suggestions would be much appreciated!
Thanks for the hard work!


Firsts things first you should Private Message kazade with this info, he could easily tell you whats going on :) Also not entirely sure if you're modem is compatible that usually ends up being the issue most of the time.

Have you tried reflashing the sdcard again?

pelvicthrustman
rebel
Posts: 15

Re: RE: Re: Problems conecting with Dreampi 1.4

Post#15 » Wed Nov 02, 2016 2:19 pm

Xiden wrote:Firsts things first you should Private Message kazade with this info, he could easily tell you whats going on :) Also not entirely sure if you're modem is compatible that usually ends up being the issue most of the time.

Have you tried reflashing the sdcard again?


The SD card is not an issue, everything is there and functioning - since I've already used the modem and line voltage inducer to connect the Dreamcast to the Internet I know they work. DreamPi also successfully hears and answers the call from the Dreamcast indicating that voice is working correctly - it only fails when it tried to set the encoding to PCM and hands off to pppd which then fails to negotiate the connection. Since pppd negotiation succeeds when I use mgetty to connect instead of DreamPi I assume it's a DreamPi issue (or lack of a feature depending on how you look at it).

kazade
Developer
Posts: 264

Re: Problems conecting with Dreampi 1.4

Post#16 » Wed Nov 02, 2016 5:25 pm

I'm not entirely sure what's going on here. It definitely looks like the voice modem doesn't support pcm audio for the dial tone which seems bonkers given that's the most basic setting. I'm not convinced that using the other values is "working" in that it's probably not generating a valid dial tone or perhaps is getting the modem in a weird state because then you hit this:

Nov 2 03:08:49 dreampi pppd[13405]: Receive serial link is not 8-bit clean:
Nov 2 03:08:49 dreampi pppd[13405]: Problem: all had bit 7 set to 0

That's from ppp. At this point the Dreampi code has finished, and given that mgetty works for you I can only assume that the modem is confused somehow by the dial tone stuff.

To be honest, the easiest thing would be to get another modem that supports pcm audio, but if you want to continue debugging this you could try commenting out the dial tone stuff altogether and then see if it works with a game that supports blind dial.

pelvicthrustman
rebel
Posts: 15

Re: Problems conecting with Dreampi 1.4

Post#17 » Thu Nov 03, 2016 5:32 am

kazade wrote:I'm not entirely sure what's going on here. It definitely looks like the voice modem doesn't support pcm audio for the dial tone which seems bonkers given that's the most basic setting. I'm not convinced that using the other values is "working" in that it's probably not generating a valid dial tone or perhaps is getting the modem in a weird state because then you hit this:

Nov 2 03:08:49 dreampi pppd[13405]: Receive serial link is not 8-bit clean:
Nov 2 03:08:49 dreampi pppd[13405]: Problem: all had bit 7 set to 0

That's from ppp. At this point the Dreampi code has finished, and given that mgetty works for you I can only assume that the modem is confused somehow by the dial tone stuff.

To be honest, the easiest thing would be to get another modem that supports pcm audio, but if you want to continue debugging this you could try commenting out the dial tone stuff altogether and then see if it works with a game that supports blind dial.


I've made some progress here and I believe I've narrowed the problem down to the pppd configuration.

With respect to the "8-bit clean message"

This post:
https://www.redhat.com/archives/redhat- ... 01683.html
Mentions this HowTo:
http://axion.physics.ubc.ca/ppp-linux.html
Which says:
"Then pppd will start reporting, and will probably give some error message. One possibility is the message containing the line Problem: all had bit 7 set to 0 This means that your ISP was not expecting you to negotiate ppp at this point. It almost certainly means that your ISP wants you to log on first"

Which makes some sense as pppd sends when started via pon but never receives anything back - there seems to be some missing step.

I removed the pppd autoconfig from dreampi,py, configured pppd per Ryochan's guide (including adding a user for auth) and removed the call to pon after the answer command, then Popen()'d mgetty, waited a few seconds and issued the USR1 signal via killall. This successfully and automatically negotiates the connection as intended. I've tested it with PSO as well as Quake III (which as I understand ignores the blind dial setting and requires a dial tone so that appears to be working after all which seems to indicate PCM is working fine regardless of the command error) and everything connects nicely. I definitely like the idea of not using mgetty though - using pon seems cleaner, it just doesn't appear to be configuring pppd correctly for some reason or another. If you have any ideas I'd certainly be interested in trying to get the current pppd configuration system working instead of relying on mgetty and I figure if it is a subtle issue then perhaps fixing it can increase modem compatibility.

User avatar
Ryochan7
Teriaaaaa
Posts: 91

Re: Problems conecting with Dreampi 1.4

Post#18 » Wed Nov 09, 2016 6:29 pm

Using pon to establish the final connection is better than using mgetty. When mgetty actually attempts to launch pppd, the connection will work every time. It is only when mgetty tries to do a direct login that it has problems sometimes; it does work occasionally though. pon works every time on my setup for all the games I have tried and for Planetweb 2.6. Setting up the peers file that pon uses is pretty simple. Here is the current peers file that I use.

https://bitbucket.org/Ryochan7/dreampi2 ... /dreamcast

Especially since the AT+VSM command errors out for you, maybe your modem is put into a weird state at that point when the DreamPi script launches pon. You can try different parameters for that command depending on your modem. I had been using AT+VSM=128,8000 but a couple of other people have mentioned that AT+VSM=129,8000 is needed for that command to work properly on their modems; AT+VSM=129,8000 works fine on my modem and Quake 3 can detect the tone so that is what I currently use.

pelvicthrustman
rebel
Posts: 15

Re: Problems conecting with Dreampi 1.4

Post#19 » Thu Nov 10, 2016 8:38 pm

Ryochan7 wrote:Using pon to establish the final connection is better than using mgetty. When mgetty actually attempts to launch pppd, the connection will work every time. It is only when mgetty tries to do a direct login that it has problems sometimes; it does work occasionally though. pon works every time on my setup for all the games I have tried and for Planetweb 2.6. Setting up the peers file that pon uses is pretty simple. Here is the current peers file that I use.

https://bitbucket.org/Ryochan7/dreampi2 ... /dreamcast

Especially since the AT+VSM command errors out for you, maybe your modem is put into a weird state at that point when the DreamPi script launches pon. You can try different parameters for that command depending on your modem. I had been using AT+VSM=128,8000 but a couple of other people have mentioned that AT+VSM=129,8000 is needed for that command to work properly on their modems; AT+VSM=129,8000 works fine on my modem and Quake 3 can detect the tone so that is what I currently use.


Thanks for the input! As I said I have everything working 100% of the time by simply shoe-horning mgetty into the dreampi.py script, unfortunately I haven't been able to get pppd working without it though (I've tried just about everything I can think of at this point, I've been over PPPD's man page a dozen times) - but pon never forms a connection. I have also tried various values for AT+VSM, 129 works fine, Quake 3 works, etc. What I'm mostly confused about is what pppd isn't doing that mgetty is.

I can't really comment as to what a weird modem 'state' might be - but I assume that any state cleanup or device resetting that mgetty does would be done prior to issuing the 'ATA' command, as indicated by it's output:

11/11 00:57:04 CM0 lowering DTR to reset Modem
11/11 00:57:04 CM0 send: ATM0[0d]
11/11 00:57:04 CM0 waiting...
11/11 00:57:08 CM0 wfr: waiting for ``RING''
11/11 00:57:08 CM0 send: ATA[0d]

In case there is some magic there I ran mgetty from DreamPi.py for a few seconds before Dreampi.py issued the ATA command (trying to borrow it's reset routine), unfortunately that did nothing.

When connecting with mgetty this is what I see:

11/11 00:57:08 CM0 send: ATA[0d]
11/11 00:57:08 CM0 waiting for ``CONNECT'' ** found **
11/11 00:57:31 CM0 send:
11/11 00:57:31 CM0 waiting for ``_'' ** found **

Only after this 23 second process which comes after the ATA command Is issued is pppd started.
Then I see LCP going back and forth as expected:

Nov 11 00:57:34 dreampi pppd[8509]: sent [LCP ConfReq id=0x1 <auth pap> <magic 0x1e8f6a1c> <pcomp> <accomp>]
Nov 11 00:57:34 dreampi pppd[8509]: rcvd [LCP ConfAck id=0x1 <auth pap> <magic 0x1e8f6a1c> <pcomp> <accomp>]
Nov 11 00:57:37 dreampi pppd[8509]: sent [LCP ConfReq id=0x1 <auth pap> <magic 0x1e8f6a1c> <pcomp> <accomp>]
Nov 11 00:57:37 dreampi pppd[8509]: rcvd [LCP ConfReq id=0x2 <mru 1500> <asyncmap 0xa0000> <magic 0x12477f08>]
Nov 11 00:57:37 dreampi pppd[8509]: sent [LCP ConfRej id=0x2 <asyncmap 0xa0000>]

And everything works great.

But when I use pon, immediately after the ATA command is issued by DreamPi.py pon kicks off pppd which goes straight into LCP (no waiting for CONNECT, etc) and sends until it decides no one will respond and hangs up. I have tried the pppd 'passive' option in case there is some kind of delay in responding, but the Dreamcast simply indicates that the connection has failed, so it's not an issue of time. Somehow these steps:

11/11 00:57:08 CM0 waiting for ``CONNECT'' ** found **
11/11 00:57:31 CM0 send:
11/11 00:57:31 CM0 waiting for ``_'' ** found **

seem to be necessary and aren't happening without mgetty.

I'm wondering if pppd performs these connecting steps on other people's modems or if LCP magically responds for other people without these steps that mgetty deems necessary? Do logs of successful connections with pon look different than what I'm seeing? BTW my modem is @ /dev/ttyACM0 so it's a bog-standard CDC/ACM modem, no drivers or anything else in the way.

User avatar
Ryochan7
Teriaaaaa
Posts: 91

Re: Problems conecting with Dreampi 1.4

Post#20 » Thu Nov 10, 2016 11:04 pm

Does the DreamPi script output OK after sending the ATA command? I think I have seen that happen before but I haven't used the upstream script in a while; I primarily use a modified version of the mgetty script posted in another thread although both mgetty and pon are available to be used in the modified version. The DreamPi script only cares that a known response is returned from the modem without trying to assume what response should be returned for a given command. Not waiting for a CONNECT response from the modem before launching pon would be a big problem.

Here is an example of the pppd log messages in my syslog file upon a successful connection.

Code: Select all

Nov 10 21:56:20 navi pppd[14734]: pppd 2.4.7 started by root, uid 0
Nov 10 21:56:20 navi pppd[14734]: using channel 44
Nov 10 21:56:20 navi pppd[14734]: Using interface ppp0
Nov 10 21:56:20 navi pppd[14734]: Connect: ppp0 <--> /dev/ttyUSB0
Nov 10 21:56:20 navi pppd[14734]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <auth pap> <magic 0x958bbb28> <pcomp> <accomp>]
Nov 10 21:56:20 navi pppd[14734]: rcvd [LCP ConfReq id=0x3 <asyncmap 0x0> <pcomp> <accomp> <magic 0x667c>]
Nov 10 21:56:20 navi pppd[14734]: sent [LCP ConfAck id=0x3 <asyncmap 0x0> <pcomp> <accomp> <magic 0x667c>]
Nov 10 21:56:21 navi pppd[14734]: rcvd [LCP ConfReq id=0x4 <asyncmap 0x0> <pcomp> <accomp> <magic 0x667c>]
Nov 10 21:56:21 navi pppd[14734]: sent [LCP ConfAck id=0x4 <asyncmap 0x0> <pcomp> <accomp> <magic 0x667c>]
Nov 10 21:56:23 navi pppd[14734]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <auth pap> <magic 0x958bbb28> <pcomp> <accomp>]
Nov 10 21:56:23 navi pppd[14734]: rcvd [LCP ConfAck id=0x1 <asyncmap 0x0> <auth pap> <magic 0x958bbb28> <pcomp> <accomp>]
Nov 10 21:56:23 navi pppd[14734]: rcvd [PAP AuthReq id=0x1 user="dream" password=<hidden>]
Nov 10 21:56:23 navi pppd[14734]: Initializing PAM (3) for user dream
Nov 10 21:56:23 navi pppd[14734]: ---> PAM INIT Result = 0
Nov 10 21:56:23 navi pppd[14734]: Attempting PAM authentication
Nov 10 21:56:23 navi pppd[14734]: PAM Authentication OK for dream
Nov 10 21:56:23 navi pppd[14734]: Attempting PAM account checks
Nov 10 21:56:23 navi pppd[14734]: PAM Account OK for dream
Nov 10 21:56:23 navi pppd[14734]: PAM Session opened for user dream
Nov 10 21:56:23 navi pppd[14734]: user dream logged in on tty ttyUSB0 intf ppp0
Nov 10 21:56:23 navi pppd[14734]: PAP peer authentication succeeded for dream
Nov 10 21:56:23 navi pppd[14734]: found interface enp1s0 for proxy arp
Nov 10 21:56:23 navi pppd[14734]: local  IP address 192.168.1.150
Nov 10 21:56:23 navi pppd[14734]: remote IP address 192.168.1.151

  • Similar Topics
    Replies
    Views
    Last post

Return to “Online”

Who is online

Users browsing this forum: No registered users