using PPP on sparc / erc32 simulator

[Tiemen Schut]

Another update.

I've tracked the ppp packet through the system, and it appears packets
arrive correctly at the ppp_txdaemon, which is the task that supposedly
sends the packet. In the txdaemon I can print the packet using some
printfs, and that looks okay.

Somewhere at the "end" of the tx code, you'll find:

      if (( tp != NULL ) && ( sc->sc_outmc != (struct mbuf *)0 )) {
        /* place FCS value into buffer */
        sc->sc_outfcsbuf[sc->sc_outfcslen++] = ~sc->sc_outfcs & 0xff;
        sc->sc_outfcsbuf[sc->sc_outfcslen++] = (~sc->sc_outfcs >> 8) &
0xff;
        microtime(&sc->sc_if.if_lastchange);
  
        /* write out frame byte to start the transmission */
		sc->sc_outchar = (u_char)PPP_FLAG;
        (*tp->device.write)(tp->minor, (char *)&sc->sc_outchar, 1);
      }

Funny thing is that PPP_FLAG == 0x7e == '~'. Apparently we do arrive at
this point (debugging confirmed this), and the '~' character is sent.
Judging by source code comments this should "start the transmission",
which apparently never happens. Even worse, after the first time we no
longer get to the txdaemon, so something hangs somewhere.

Any thoughts?

Regards,

Tiemen



>>> On 4/2/2010 at 17:13, in message <4BBC89EF.0FF9.0052.0 at sron.nl>,
Tiemen Schut
wrote: 
> 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  
> >   
>