Loading ...
Sorry, an error occurred while loading the content.

Re: SLIP over USBSerial?

Expand Messages
  • Bill Buzbee
    ... closer to ... kernel ... Thanks - I ll try that next. My current suspicion is that it isn t a problem with USBSerial driver support, but rather that the
    Message 1 of 8 , Jan 1, 2008
    View Source
    • 0 Attachment
      --- In nslu2-linux@yahoogroups.com, "Mike \(mwester\)" <mwester@...>
      wrote:

      > I'd give SlugOS a try - I'm betting that SlugOS is probably a lot
      closer to
      > Ubuntu than is Unslung, especially when it comes to the drivers (the
      kernel
      > on Unslung is rather ancient).

      Thanks - I'll try that next. My current suspicion is that it isn't a
      problem with USBSerial driver support, but rather that the unslung
      kernel wasn't compiled with SLIP support. I'm hoping that the stock
      SlugOS kernel has SLIP support - otherwise I guess I'll be cobbling
      together a build environment.

      I'll report back what I discover.

      ...Bill
    • Rod Whitby
      ... Unslung: # CONFIG_SLIP is not
      Message 2 of 8 , Jan 1, 2008
      View Source
      • 0 Attachment
        Bill Buzbee wrote:
        > --- In nslu2-linux@yahoogroups.com, "Gregg C Levine"
        > <hansolofalcon@...> wrote:
        >> Whose USB to Serial dongle are you using for the NSLU2 end? Or for that
        >> matter on your Linux box?
        >
        > I've got several - but the one I'm using right now is a development
        > kit board with the FTDI chipset. I'm confident that the basic
        > USB-to-Serial functionality works. I'm currently able to use minicom
        > on the NSLU2 to connect to my machine over the serial port.
        >
        > I've done a bit more Googling since my first message, and my current
        > suspicion is that the unslung kernel wasn't compiled with SLIP support.

        Unslung:
        <http://svn.nslu2-linux.org/svnroot/unslung/releases/unslung-6.10-beta/openembedded/packages/linux/unslung-kernel/defconfig>

        # CONFIG_SLIP is not set

        SlugOS:
        <http://svn.nslu2-linux.org/svnroot/slugos/releases/slugos-4.8-beta/openembedded/packages/linux/linux-ixp4xx/defconfig-2.6.21.7>

        # CONFIG_SLIP is not set

        (Angstrom uses the same kernel config)

        OpenWrt:
        <https://svn.openwrt.org/openwrt/tags/kamikaze_7.09/target/linux/ixp4xx-2.6/config/default>

        # CONFIG_SLIP is not set

        Debian:
        <http://svn.debian.org/wsvn/kernel/releases/linux-2.6/2.6.18-5/debian/arch/arm/config.ixp4xx?op=file&rev=0&sc=0>

        CONFIG_SLIP=m

        Looks like Debian is the distro for you.

        -- Rod
      • Bill Buzbee
        ... ..snip ... support. ..snip ... ... Time
        Message 3 of 8 , Jan 5, 2008
        View Source
        • 0 Attachment
          --- In nslu2-linux@yahoogroups.com, Rod Whitby <rod@...> wrote:
          >
          > Bill Buzbee wrote:
          ..snip
          > > I've done a bit more Googling since my first message, and my current
          > > suspicion is that the unslung kernel wasn't compiled with SLIP
          support.
          ..snip
          > Debian:
          >
          <http://svn.debian.org/wsvn/kernel/releases/linux-2.6/2.6.18-5/debian/arch/arm/config.ixp4xx?op=file&rev=0&sc=0>
          >
          > CONFIG_SLIP=m
          >
          > Looks like Debian is the distro for you.
          >
          > -- Rod
          >

          Time for an update:

          It's pretty close to working - but not quite there yet. I decided
          that Debian was a bit heavyweight for what I had in mind, so I've been
          trying with OpenWrt. First step was to rebuild OpenWrt with SLIP
          support included, as well as compiling in support for the FTDI-based
          USB to Serial converter. That went pretty smoothly, but I then ran
          into a problem in which it appeared that the pre-built net-tools
          package was compiled with SLIP support disabled.

          I also noticed that recent versions of busybox have slattach and
          pretty much everything else I need. I really like the idea of running
          my slug completely from internal flash, so I decided to use the
          busybox slattach. The 1.4 version of busybox didn't include this, so
          I backported from 1.7.

          The current state of the world is that I can ping my Magic-1 computer
          via slip, as well as wget web pages - but only from the NSLU2. I can
          arping Magic-1 from elsewhere on my network, and the slug seems to
          correctly understand Magic-1's IP address and report its own hardware
          address. However, if I do a normal ping to Magic-1 from elsewhere on
          the net, I get no response.

          I'm profoundly ignorant when it comes to networking magic, so I'd sure
          appreciate any advice.

          Here's my setup, how I configured the slip link, and the output of
          ifconfig, route and arp:

          NSLU2 running OpenWrt with custom kernel (built-in SLIP and
          USBSerial drivers)
          Customized busybox 1.4, with slattach backported from busybox 1.7
          FTDI-based USBSerial converter, connected to auxilliary serial port
          of my Magic-1 homebrew (running at 38.4K baud)

          I set up the slip link as follows (a sequence that has worked
          successfully with an X86 Ubuntu 7.10 box):

          Note: Slug is 192.168.0.51, Magic-1 is 192.168.0.76

          slattach -s 38400 -p slip /dev/ttyUSB0 2> /dev/null &
          ifconfig sl0 192.168.0.51 pointopoint 192.168.0.76 mtu 576 up
          route add -host 192.168.0.76 sl0
          arp -Ds 192.168.0.76 eth0 pub
          echo 1 > /proc/sys/net/ipv4/ip_forward

          And finally, following is the output of ifconfig, route and arp.
          Any suggestions about what additional information would be useful to
          track this problem down would be greatly appreciated. It seems pretty
          close.

          Thanks,
          ...Bill

          ---------- output follows:

          root@OpenWrt:~# ifconfig
          eth0 Link encap:Ethernet HWaddr 00:18:39:AB:19:32
          inet addr:192.168.0.51 Bcast:192.168.0.255 Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
          RX packets:956 errors:0 dropped:0 overruns:0 frame:0
          TX packets:502 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:83543 (81.5 KiB) TX bytes:55811 (54.5 KiB)

          lo Link encap:Local Loopback
          inet addr:127.0.0.1 Mask:255.0.0.0
          UP LOOPBACK RUNNING MTU:16436 Metric:1
          RX packets:42 errors:0 dropped:0 overruns:0 frame:0
          TX packets:42 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:2982 (2.9 KiB) TX bytes:2982 (2.9 KiB)

          sl0 Link encap:UNSPEC HWaddr
          00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          inet addr:192.168.0.51 P-t-P:192.168.0.76 Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST MTU:576 Metric:1
          RX packets:7 errors:0 dropped:0 overruns:0 frame:0
          TX packets:8 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:10
          RX bytes:815 (815.0 B) TX bytes:549 (549.0 B)

          root@OpenWrt:~# route
          Kernel IP routing table
          Destination Gateway Genmask Flags Metric Ref
          Use Iface
          192.168.0.76 * 255.255.255.255 UH 0 0
          0 sl0
          192.168.0.76 * 255.255.255.255 UH 0 0
          0 sl0
          192.168.0.0 * 255.255.255.0 U 0 0
          0 eth0
          default 192.168.0.2 0.0.0.0 UG 0 0
          0 eth0
          root@OpenWrt:~# arp
          ? (192.168.0.2) at 00:09:5B:EF:02:B8 [ether] on eth0
          ? (192.168.0.101) at 00:13:02:12:BE:9F [ether] on eth0
          ? (192.168.0.76) at * PERM PUP on eth0
          root@OpenWrt:~#
        • Bill Buzbee
          WooHoo! - It s all all working now. On my 4th cup of coffee, I ran across a posting describing a similar problem:
          Message 4 of 8 , Jan 5, 2008
          View Source
          • 0 Attachment
            WooHoo! - It's all all working now. On my 4th cup of coffee, I ran
            across a posting describing a similar problem:

            http://forum.openwrt.org/viewtopic.php?pid=21056

            It seems that the default for iptables is to drop forwarded packets. By
            doing:

            iptables -P FORWARD ACCEPT; iptables -F FORWARD

            my little flash-only slug is now working as a SLIP bridge for Magic-1.

            Next I'll cobble together a power plug to run the slug off of
            Magic-1's power supply. When it's all done, I'll post again with a
            recap of getting SLIP over USBSerial working.

            Thanks to all!
          Your message has been successfully submitted and would be delivered to recipients shortly.