Re: Serial SLIP Connection
After correcting my routing setup, I have SLIP and PPP both working as expected over a direct serial connection. I had to adjust the NAT setup within my home network. For now I used ipnat on the NetBSD slip server. I also had to add an additional static route on the client to the address of the network card on the server with the ip address of sl0 on the server as the gateway. Thanks to everyone for your help in sorting this out and patience as I tried to determine the problem.
Re: Serial SLIP Connection
On 11/1/18, Greg Troxel wrote: > I am not really following your descriptions of what is working and what > isn't, in particularly "ping out". Thank you for asking and the suggestions. > Then, the questions are: > > is IP forwarding enabled on the gateway machine? > > if you ping 10.0.2.2 from the slip-only machine, and run tcpdump on > the gateway machine, first on the slip line, and then on the ethernet, > do you see the outgoing ICMP echo request packets? Do you see > replies? I can send out and receive packets back without problems on the server. DNS lookups fail and no packets seem to be returned except when pinging the sl0 interface on the client. Running tcpdump on the client does not show any ICMP packets going out; only the ping from the server to the client at 10.0.5.2 shows up. Below are session logs from this morning. Client: nbsd702# ifconfig lo0: flags=8049 mtu 33192 inet 127.0.0.1 netmask 0xff00 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1 sl0: flags=c015 mtu 296 inet 10.0.5.2 -> 10.0.5.1 netmask 0xfffc nbsd702# route add default 10.0.5.1 add net default: gateway 10.0.5.1 nbsd702# sysctl net.inet.ip.forwarding net.inet.ip.forwarding = 1 nbsd702# ping -c1 10.0.5.1 PING nbsd702-host.bsdnix.vmnet (10.0.5.1): 56 data bytes nbsd702-host.bsdnix.vmnet PING Statistics 1 packets transmitted, 0 packets received, 100.0% packet loss nbsd702# ping -c1 10.0.5.2 PING nbsd702.bsdnix.vmnet (10.0.5.2): 56 data bytes nbsd702.bsdnix.vmnet PING Statistics 1 packets transmitted, 0 packets received, 100.0% packet loss nbsd702# ping -c1 10.0.2.3 PING 10.0.2.3 (10.0.2.3): 56 data bytes 10.0.2.3 PING Statistics 1 packets transmitted, 0 packets received, 100.0% packet loss nbsd702# ping -c1 10.0.2.15 PING 10.0.2.15 (10.0.2.15): 56 data bytes 10.0.2.15 PING Statistics 1 packets transmitted, 0 packets received, 100.0% packet loss nbsd702# ping -c1 8.8.8.8 PING 8.8.8.8 (8.8.8.8): 56 data bytes 8.8.8.8 PING Statistics 1 packets transmitted, 0 packets received, 100.0% packet loss nbsd702# dig @10.0.2.3 8.8.8.8 ; <<>> DiG 9.10.5-P2 <<>> @10.0.2.3 8.8.8.8 ; (1 server found) ;; global options: +cmd ;; connection timed out; no servers could be reached nbsd702# dig @8.8.8.8 8.8.8.8 ; <<>> DiG 9.10.5-P2 <<>> @8.8.8.8 8.8.8.8 ; (1 server found) ;; global options: +cmd ;; connection timed out; no servers could be reached nbsd702# ftp ftp.netbsd.org ftp: Can't lookup `ftp.netbsd.org:ftp': Non-recoverable failure in name resolution ftp> quit nbsd702# route show Routing tables Internet: DestinationGatewayFlagsRefs UseMtu Interface defaultnbsd702-host UG -- - sl0 nbsd702-host nbsd702UH -- - sl0 127/8 localhost UGR -- 33192 lo0 localhost localhost UH -- 33192 lo0 Tcpdump on Client: nbsd702# tcpdump -v -i sl0 tcpdump: listening on sl0, link-type SLIP (SLIP), capture size 262144 bytes 15:40:04.862321 IP (tos 0x0, ttl 255, id 15, offset 0, flags [none], proto ICMP (1), length 84, bad cksum 9d97 (->a37e)!) 13.10.0.5 > 1.13.10.0: ICMP redirect-tos 0.0.0.0 to net 103.112.134.47, length 64 (wrong icmp cksum 800 (->2fe)!) IP0 ^C 1 packet captured 17 packets received by filter 0 packets dropped by kernel Server: nbsd702-server# sysctl net.inet.ip.forwarding net.inet.ip.forwarding = 1 nbsd702-server# ifconfig wm0: flags=8843 mtu 1500 capabilities=2bf80 capabilities=2bf80 capabilities=2bf80 enabled=0 ec_capabilities=7 ec_enabled=0 address: 52:54:00:12:34:56 media: Ethernet autoselect (1000baseT full-duplex) status: active inet 10.0.2.15 netmask 0xff00 broadcast 10.0.2.255 inet6 fe80::df89:919a:d61:a6b6%wm0 prefixlen 64 scopeid 0x1 inet6 fec0::cf90:308c:60b4:45c0 prefixlen 64 lo0: flags=8049 mtu 33192 inet 127.0.0.1 netmask 0xff00 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 sl0: flags=c015 mtu 296 inet 10.0.5.1 -> 10.0.5.2 netmask 0xfffc nbsd702-server# ping -c1 10.0.5.1 PING nbsd702-server.bsdnix.vmnet (10.0.5.1): 56 data bytes nbsd702-server.bsdnix.vmnet PING Statistics 1 packets transmitted, 0 packets received, 100.0% packet loss nbsd702-server# ping -c1 10.0.5.2 PING nbsd702.bsdnix.vmnet (10.0.5.2): 56 data bytes nbsd702.bsdnix.vmnet PING Statistics 1 packets transmitted, 0 packets received, 100.0% packet loss nbsd702-server# ping -c1 10.0.2.3 PING 10.0.2.3 (10.0.2.3): 56 data bytes 64 bytes from 10.0.2.3: icmp_seq=0 ttl=255 time=3.512579 ms 10.0.2.3 PING Statistics 1 packets transmitted, 1 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 3.512579/3.512579/3.512579/0.00 ms nbsd702-server#
Re: Serial SLIP Connection
On 11/1/18, Malcolm Herbert wrote: > I'm curious - why SLIP and not PPP? PPP would be equally suitable in general. It was just that SLIP would meet my needs with slightly less setup and overhead when attaching serial devices (no configuration files for each interface and no daemon). I started with SLIP becaue I thought it might be easier to try to check what was going over the wire because the encapsulation is so minimal.
Re: Serial SLIP Connection
Hello Dan, ASB> Here is a note I wrote myself some years ago, when I > last tried it. I like slip because it's simple and > does the job. I will try to test it this evening. I can confirm that SLIP still works. Here's an iperf speed test over the serial connection:- Client connecting to 192.168.3.1, TCP port 5001 TCP window size: 32.5 KByte (default) [ 3] local 192.168.3.2 port 65527 connected with 192.168.3.1 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-18.2 sec 256 KBytes 115 Kbits/sec -Andy Ball
Re: Serial SLIP Connection
Hello Dan, Here is a note I wrote myself some years ago, when I last tried it. I like slip because it's simple and does the job. I will try to test it this evening. /etc/ifconfig.sl0 ! /sbin/slattach -h -s 115200 /dev/tty00 inet 192.168.3.129 192.168.3.128 up (IP addresses reversed at one end of the cable). -Andy Ball.
Re: Serial SLIP Connection
Dan Plassche writes: > On 11/1/18, Andy Ruhl wrote: >> On Thu, Nov 1, 2018 at 10:50 AM Dan Plassche wrote: >>> ifconfig sl0 inet 10.0.2.7 10.0.2.6 arp up >>> route add default 10.0.2.6 >>> >>> 5. Setup interface on server >>> >>> ifconfig sl0 create >>> slattach -l -s 9600 -t slip /dev/tty00 >>> ifconfig sl0 inet 10.0.2.6 10.0.2.7 arp up > > Thanks, Andy. The netmask was defaulting to 255.0.0.0 and I now > set it to 255.255.255.252 at each end. I tried again without cu > and setting both ends as 10.0.5.1 and 10.0.5.2, but still had the > same behavior (can ping out, but no packets received or route to > DNS on the cient). The test server's network card is at 10.0.2.15 > with the gateway at 10.0.2.2 and the DNS at 10.0.2.3. Adding > additional static routes to those endpoints through the NetBSD > server did not seem to help. I am not really following your descriptions of what is working and what isn't, in particularly "ping out". On the two machines with slip, you should run tcpdump, and on each, see what happens when you "ping -n 10.0.5.2" from 1, and vice versa. If that works, your slip configuration itself is ok. Then, on the machine that has a regular interface and slip (yes, an old timer is cringing hearing that :-), presumably you can successfully ping machines on the greater internet, telnet to 80/443, etc. Then, the questions are: is IP forwarding enabled on the gateway machine? if you ping 10.0.2.2 from the slip-only machine, and run tcpdump on the gateway machine, first on the slip line, and then on the ethernet, do you see the outgoing ICMP echo request packets? Do you see replies? run netstat -s, then do the above for 10s, then netstat -s again, and diff the results. Explain all changed counters. (Really; this will find things you don't realize you should look for.) on another machine on the lan, ping 10.0.5.2. tcpdump and see what happens. Explain how you have routes set up for normal lan machines to know that 10.0.5.0/30 is reached via the gateway machine.
Re: Serial SLIP Connection
I'm curious - why SLIP and not PPP? Regards, Malcolm -- Malcolm Herbert m...@mjch.net
Re: Serial SLIP Connection
On 11/1/18, Andy Ruhl wrote: > On Thu, Nov 1, 2018 at 10:50 AM Dan Plassche wrote: >> ifconfig sl0 inet 10.0.2.7 10.0.2.6 arp up >> route add default 10.0.2.6 >> >> 5. Setup interface on server >> >> ifconfig sl0 create >> slattach -l -s 9600 -t slip /dev/tty00 >> ifconfig sl0 inet 10.0.2.6 10.0.2.7 arp up > > I haven't done this in a really long time, but I don't remember > needing cu when using 2 directly attached machines over a null modem. > Just slattach. Maybe that changed. > > I also seem to recall using a /30 and a netmask for both ends. Your > addresses don't belong to the same /30. Try using .1 and .2 or .5 and > .6. > > Just stuff to try. I can't say that this info is useful 20 years later. > > Andy > Thanks, Andy. The netmask was defaulting to 255.0.0.0 and I now set it to 255.255.255.252 at each end. I tried again without cu and setting both ends as 10.0.5.1 and 10.0.5.2, but still had the same behavior (can ping out, but no packets received or route to DNS on the cient). The test server's network card is at 10.0.2.15 with the gateway at 10.0.2.2 and the DNS at 10.0.2.3. Adding additional static routes to those endpoints through the NetBSD server did not seem to help.
Re: Serial SLIP Connection
On Thu, Nov 1, 2018 at 10:50 AM Dan Plassche wrote: > ifconfig sl0 inet 10.0.2.7 10.0.2.6 arp up > route add default 10.0.2.6 > > 5. Setup interface on server > > ifconfig sl0 create > slattach -l -s 9600 -t slip /dev/tty00 > ifconfig sl0 inet 10.0.2.6 10.0.2.7 arp up I haven't done this in a really long time, but I don't remember needing cu when using 2 directly attached machines over a null modem. Just slattach. Maybe that changed. I also seem to recall using a /30 and a netmask for both ends. Your addresses don't belong to the same /30. Try using .1 and .2 or .5 and .6. Just stuff to try. I can't say that this info is useful 20 years later. Andy
Serial SLIP Connection
I'm having trouble setting up a direct serial connection on NetBSD 7.0.2 to share a server's internet access with a client over SLIP. The server has internet access over a wired ethernet card (wm0) and connects to the client over a serial line (null modem cable). I started by testing this in virtual machines and I would like to get it working before deploying to real hardware. I've been manually setting up the interfaces, but creating a sliplogin account with the same settings shown below after running getty on the server's tty00 did not seem to help as alternatives. Here's what I've tried so far: 1. Created 2 connected PTY devices to attach one to the serial port on each QEMU machine: socat -d -d -4 \ pty,raw,user=dp,group=staff,crnl,echo=0,mode=777,\ link=/usr/home/dp/serial-host \ pty,raw,user=dp,group=staff,crnl,echo=0,mode=777,\ link=/usr/home/dp/serial-client 2. Started QEMU x86 NetBSD server and client attached to each respective PTY: qemu-system-i386 -nodefaults -hda nbsd72-server.img \ -chardev tty,path=/usr/home/dp/serial-host,id=ser-tty \ -device isa=serial,chardev=ser-tty -net nic -net user \ -vga std & qemu-system-i386 -nodefaults -hda nbsd72-client.img \ -chardev tty,path=/usr/home/dp/serial-host,id=ser-tty \ -device isa=serial,chardev=ser-tty -net nic -net user \ -vga std & 3. Dial-out to connect to server from client using -t flag for local line without modem: cu -t -s 9600 -l /dev/dty00 4. Escape back to shell (~!) on client and setup sl0 interface: ifconfig sl0 create slattach -l -s 9600 -t slip /dev/dty00 ifconfig sl0 inet 10.0.2.7 10.0.2.6 arp up route add default 10.0.2.6 5. Setup interface on server ifconfig sl0 create slattach -l -s 9600 -t slip /dev/tty00 ifconfig sl0 inet 10.0.2.6 10.0.2.7 arp up Any suggestions would be appreciated! Thanks, Dan Plassche
