[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [bluetooth-dev] kernel mode on ARM+kernel2.4 : ppp problem fixed.



Hi all,

I answer to my message myself as nobldy else does ;-)

I found a bug in bluetooth.c causing ppp not to work with the stack.
In function bt_ioctl, when an ioctl is not "recognised" it is forwarded to 
the "serial driver". If you remember, this was causing the stack to crash as 
my serial port didn't support ioctls (the pointer was set to NULL)... So this 
also causes ppp not to work ! So, I think it should be fixed.

Explanations :

When pppd opens ttyBT0, it sets its line discipline to N_PPP, and sends 
ioctls to ttyBT0 destinated to the N_PPP line discipline. When an ioctl is 
sent to a tty (see in the kernel /drivers/char/tty_io.c), first tty_ioctl is 
called. If the ioctl is not supported, then tty->driver->ioctl (registered by 
tty_register_driver), is called (if not NULL which is very nice if your 
serial driver doesn't implement the ioctl function). If it doesn't support 
the ioctl, tty->driver->ioctl should return the value -ENOIOCTLCMD (which is 
not the case for ttyBT0), causing the tty->ldisc->ioctl (in our case from the 
N_PPP line disc) to be called.

So, in bt_ioctl, the default case should return -ENOIOCTLCMD.
With this change I could connect the ppp/ip layer.
How comes nobody as ever seen this problem ? Is it a tty change beetween 
older kernel and kernel 2.4 ?

David.

Le Lundi 05 Mars 2001 11:22, david LIBAULT a écrit :
> Hi all,
>
> When trying to establish a ppp link I get the following problem :
> > rf_conn 00:50:CD:11:10:AD 1 0
>
> Connected.
>
> > ppp
>
> Starting modem_emulator
> Modem done.
> build_pppdopt
> pppd
> /dev/ttyBT0
> 57600
> crtscts
> debug
> local
> nodetach
> nopersist
> silent
> passive
> noauth
> proxyarp
> ktune
> 10.0.0.1:10.0.0.2
> start pppd...
> using channel 0
> Couldn't attach to channel 0: Device not configured
> ppp child died, now restart
> Starting modem_emulator
>
> What is a channel for ppp ? What Device is it complaining about,
> /dev/ttyBT0 ?
>
> David.
>
> Le Samedi 03 Mars 2001 20:44, david LIBAULT a écrit :
> > Hi all,
> >
> > The UART problem has been fixed (by Russel King). It comes from the fact
> > that printk() disables interrupts causing the uart to miss bytes... This
> > of course was not happening in user mode ! So changing the log level
> > fixes the problem (for the moment).
> > I have been able to setup an RF_COMM channel beetween to machines. I now
> > have to setup ppp and see if we have the same problem in kernel mode than
> > in user mode...
> >
> > David.
> >
> > Le Vendredi 02 Mars 2001 22:16, Gordon McNutt a écrit :
> > > david LIBAULT wrote:
> > > > > If my theory is correct then sertty->driver.ioctl will be munged up
> > > > > (from the modules's perspective) all the time -- even at
> > > > > registration.
> > > >
> > > > Well, it is not :
> > > >
> > > > sertty : 0xc04e8000
> > > > sertty->driver : 0xc04e8004
> > > > sertty->driver.ioctl : 0xc04e8080 (at this address the value is 0)
> > > >
> > > > These values look good to me, considering the start address of the
> > > > DRAM, and the shape of the structure.
> > >
> > > Ok, if those addresses look like they make sense to you.
> > >
> > > > I am checking the serial driver. I am working on an EP7211, and the
> > > > serial driver looks loosy...
> > >
> > > Yes, often these arm archs define their own serial drivers. Sometimes
> > > all they want is a console driver so they leave things out...
> > >
> > > --gmcnutt
> >
> > -------------------------------------------------------
> > -
> > To unsubscribe from this list: send the line "unsubscribe bluetooth-dev"
> > in the body of a message to majordomo@xxxxxxx.com
>
> -
> To unsubscribe from this list: send the line "unsubscribe bluetooth-dev" in
> the body of a message to majordomo@xxxxxxx.com
-
To unsubscribe from this list: send the line "unsubscribe bluetooth-dev" in
the body of a message to majordomo@xxxxxxx.com