using PPP on sparc / erc32 simulator

[Tiemen Schut]

Okay, I've made *some* progress. Mainly by looking at the example
(pppdapp), I've noticed that I need to do something like:

    rtems_pppd_initialize();
    rtems_pppd_set_option("/dev/console_b", NULL);
    rtems_pppd_set_option("38400", NULL);
    rtems_pppd_set_option("nocrtscts", NULL);
    rtems_pppd_set_option("local", NULL);
    rtems_pppd_set_option("noauth", NULL);
    rtems_pppd_set_option("passive", NULL);
    rtems_pppd_set_option("debug", NULL);
    rtems_pppd_set_option("kdebug", "4");
    rtems_pppd_connect();

and then wait for a connection from the other side, or wait for my
connect to be accepted by the other side, where "other side" would be
the pppd on the host machine.

The problem now is that the output from pppd (output = packets it is
sending trying to connect to its peer) is not as expected. On linux, you
get the following:

tiemens at Ain:~$ pppd passive nodetach local noauth nocrtscts debug
kdebug 7 /dev/stdout
~ÿ}#À!}!}!} }4}"}&} } } } }%}&}'Èi}'}"}(}"­Î~~ÿ}#À!}!}!} }4}"}&} } } }
}%}&}'Èi}'}"}(}"­Î~~ÿ}#À!}!}!} }4}"}&} } } }
}%}&}'Èi}'}"}(}"­Î~~ÿ}#À!}!}!} }4}"}&} } } }
}%}&}'Èi}'}"}(}"­Î~~ÿ}#À!}!}!} }4}"}&} } } }
}%}&}'Èi}'}"}(}"­Î~~ÿ}#À!}!}!} }4}"}&} } } }
}%}&}'Èi}'}"}(}"­Î~~ÿ}#À!}!}!} }4}"}&} } } }
}%}&}'Èi}'}"}(}"­Î~~ÿ}#À!}!}!} }4}"}&} } } }
}%}&}'Èi}'}"}(}"­Î~~ÿ}#À!}!}!} }4}"}&} } } }
}%}&}'Èi}'}"}(}"­Î~~ÿ}#À!}!}!} }4}"}&} } } }
}%}&}'Èi}'}"}(}"­Î~

After which it stops trying to connect and just listens for incoming
connections, which is fine I suppose. Also notice that every connect
packet starts and ends with '~'. 

Now, running either my own app or the example pppdapp in the simulator
and redirecting output to stdout only gives one single '~' character,
even though it tries to connect multiple times, just like pppd on linux.
However, as you can see in the code above I've set kdebug to level 4,
and this results in ppp writing its output string to stdout just before
it is going to send this. Ppp says:

ppp0 output: ff03c0210165001402060000000005061d32ce1707020802

Note that this doesn't include the '~' character, as that is 0x7e.

These observations lead me to believe that pppd is correctly trying to
send its connect requests (or whatever they would be called), but that
somewhere along the way the tty/termios/uart/something code is chocking
on it.

I also believe this has something to do with the PPP line discipline. I
inserted write (ppp_fd, "bla", 3) statements in the pieces of rtems
where it's setting the line discipline, and before the line discipline
was changed these got to the console nicely. After the discipline was
changed to PPPDISC; zilch, nada, nop. However, I'm no expert on
terminals and line disciplines and such, so maybe this is normal
behaviour?

Any hints/tips would be highly appreciated :)

Tiemen


>>> On 3/31/2010 at 12:04, in message
<4BB33A46020000520000F7B9 at pluto.sron.nl>,
"Tiemen Schut" <T.Schut at sron.nl> wrote: 
> Dear list, 
>  
> I'm trying to use the erc32 simulator provided in gdb to simulate my
images.  
> This is all going very well, setting up and using the simulator was 

> surprisingly easy. 
>  
> However, on my real target I also use an ethernet interface, which
the  
> simulator does not have. At first I though about implementing my own 

> simulated ethernet device, but that looks like it's going to be a
*lot* of  
> work. 
>  
> Fortunately, the simulator does support up to two uarts. So, I though
to use  
> PPP on one of the simulated uarts and then somehow make this uart
connect to  
> a tty device on my Linux pc. Please note that all this PPP stuff is
very new  
> for me, so it's quite possible that I'm doing some or more things  
> fundamentally wrong. If so, please correct me :) 
>  
> I was thinking that it would be possible to use the rtems PPP driver
as if  
> it were an ethernet driver. So, when building for the real target I
have  
> something like: 
>  
> static struct rtems_bsdnet_ifconfig gNetdriverConfig = {  
>     (char *)"gr_eth1",              // name  
>     RTEMS_BSP_NETWORK_DRIVER_ATTACH,// attach  
>     NULL, 
>     (char *)DEFAULT_IP_ADDR,        // ip_address  
>     (char *)DEFAULT_IP_NETMASK,     // ip_netmask  
> }; 
>  
> And when building for the simulator I have (based on the pppd
example, don't  
> know if it's even close to correct): 
>  
> extern "C" int rtems_ppp_driver_attach(struct rtems_bsdnet_ifconfig
*config,  
> int attaching); 
> static struct rtems_bsdnet_ifconfig gNetdriverConfig = {  
>     (char *)"ppp0",                 /* name */ 
>     rtems_ppp_driver_attach,        /* attach function */ 
>     NULL,                           /* link to next interface */ 
>     NULL,                           /* ip_address */ 
>     NULL,                           /* ip_netmask */ 
>     NULL, 
>     0 
> }; 
>  
> This seems to do *something*. However, as the interface doesn't have
an IP  
> address whatsoever I don't seem to be able to bind a socket to it, so
I don't  
> get how that would be supposed to work. If I do provide an IP address
in the  
> above struct, rtems will tell me: 
>  
> Can't set default route: Network is unreachable 
>  
> as soon as I call rtems_bsdnet_initialize_network(). 
>  
> I'm kinda lost here, any help or hints would be appreciated. 
>  
> Thanks, 
>  
> Tiemen 
>  
>  
> _______________________________________________ 
> rtems-users mailing list 
> rtems-users at rtems.org 
> http://www.rtems.org/mailman/listinfo/rtems-users 
>