linux and slip networking
 

Hello kernel geeks,

I have a small 'project' with avr microcontoller and linux host pc. I connect them with a null-modem serial cable. In the avr side I have leds indicating when a char arrives to the uart.

Everything goes fine when I just cat something to the serial port. But I want to use a network interface for communication. I try to use slip driver:

- insmod slip.ko
- slattach -s 9600 -p slip /dev/ttyS0 &
- ifconfig sl0 192.168.0.1 pointopoint 192.168.0.2 up

Things seem to ok, the sl0 interface shows up when I load the module and there is no warnings or anything. But when I ping to the target nothing happens.

Here is the part of the kernel module that prints that (function sl_tx_timeout with debug printk's attached):

#######
printk(KERN_ALERT "timeout, chars in buf %d\n",
sl->tty->driver->chars_in_buffer(sl->tty));
printk(KERN_WARNING "%s: transmit timed out, %s?\n", dev->name,
(sl->tty->driver->chars_in_buffer(sl->tty) || sl->xleft) ?
"bad line quality" : "driver error");
#######

And here's another part (sl_encaps that is called by sl_start_hard_xmit):

#######
printk(KERN_ALERT "after sl encaps!\n");
actual = sl->tty->driver->write(sl->tty, sl->xbuff, count);
printk(KERN_ALERT "after tty send %d!\n", actual);
#######

Here's the dmesg log:

#######
[ 6326.377957] before sl encaps!
[ 6326.377960] after sl encaps!
[ 6326.377963] after tty send 88!
[ 6336.360453] NETDEV WATCHDOG: sl0: transmit timed out
[ 6341.351712] NETDEV WATCHDOG: sl0: transmit timed out
[ 6346.342972] NETDEV WATCHDOG: sl0: transmit timed out
[ 6346.342983] timeout, chars in buf 440
[ 6346.342987] sl0: transmit timed out, bad line quality?
[ 6346.342999] before sl encaps!
[ 6346.343003] after sl encaps!
[ 6346.343007] after tty send 88!
[ 6356.325486] NETDEV WATCHDOG: sl0: transmit timed out
[ 6361.316745] NETDEV WATCHDOG: sl0: transmit timed out
[ 6366.308003] NETDEV WATCHDOG: sl0: transmit timed out
[ 6366.308012] timeout, chars in buf 528
[ 6366.308016] sl0: transmit timed out, bad line quality?
#######

I hope that clarifies what my problem is. I understand that the slip driver gives the data properly to the uart driver. I don't know what the write function exactly is but I think that it is uart_write in serial_core.c ? Write seems to go fine because it returns the amount of data that it is supposed to write. But then the data is lost.

'ifconfig sl0' gives zero tx and rx bytes

'cat /proc/tty/driver/serial' gives

serinfo:1.0 driver revision:
0: uart:16550A port:000003F8 irq:4 tx:0 rx:0 RTS|DTR|DSR|CD
1: uart:unknown port:000002F8 irq:3
2: uart:unknown port:000003E8 irq:4
3: uart:unknown port:000002E8 irq:3

So the question is, where is my data? Has anyone made slip to work with recent kernels? (Btw, is tested it also with some slip terminal in windows and it worked fine, there is just something with SLIP line discipline and the tty driver)

I had the same problem on an XScale CPU board and found that the problem was comming from hardware flow control at the tty level.

The slip driver do a write call to the tty device to send the data, and this call is OK. But as the tty is not allowed to send the data, nothing is sent, all data remains in the tty TX fifo, and no transmit interrupt occurs. After timeout expiration (20s), the timeout handler of the slip driver is called to report the timeout error.

When slattach is running, the crtscts mode (hardware flow control) is enabled on the tty, even when using the -L option of slattach; this can be seen by an stty -a command.
However on my board, the CTS signal is always seen inactive by the tty driver, and can not be accessed by hardware.

So I patched slattach.c (from net-tools source RPM) to not enable crtscts mode :
- tty->c_cflag = (CRTSCTS | HUPCL | CREAD); /* UART flags */
+ tty->c_cflag = (/*CRTSCTS | */HUPCL | CREAD); /* UART flags */
and rebuilt it.
Now It works.

Hello,

Actually, you don't have to patch it. There is -m option in slattach that disables cts/rts signalling :) In the help it is quite misleading explained (Do not initialize 8 bit raw mode).

Hi guys,

can you take a look at my problem here (http://www.linuxquestions.org/questi...e-4175500009) Thx.

Best Regards

That didn't work as expected.