NetBSD-Users archive

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

Re: Serial SLIP Connection



On 11/1/18, Greg Troxel <gdt%lexort.com@localhost> 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<UP,LOOPBACK,RUNNING,MULTICAST> mtu 33192
	inet 127.0.0.1 netmask 0xff000000
	inet6 ::1 prefixlen 128
	inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1
sl0: flags=c015<UP,DEBUG,POINTOPOINT,LINK2,MULTICAST> mtu 296
	inet 10.0.5.2 -> 10.0.5.1 netmask 0xfffffffc

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:
Destination        Gateway            Flags    Refs      Use    Mtu Interface
default            nbsd702-host       UG          -        -      -  sl0
nbsd702-host       nbsd702            UH          -        -      -  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<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
	capabilities=2bf80<TSO4,IP4CSUM_Rx,IP4CSUM_Tx,TCP4CSUM_Rx>
	capabilities=2bf80<TCP4CSUM_Tx,UDP4CSUM_Rx,UDP4CSUM_Tx,TCP6CSUM_Tx>
	capabilities=2bf80<UDP6CSUM_Tx>
	enabled=0
	ec_capabilities=7<VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU>
	ec_enabled=0
	address: 52:54:00:12:34:56
	media: Ethernet autoselect (1000baseT full-duplex)
	status: active
	inet 10.0.2.15 netmask 0xffffff00 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<UP,LOOPBACK,RUNNING,MULTICAST> mtu 33192
	inet 127.0.0.1 netmask 0xff000000
	inet6 ::1 prefixlen 128
	inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2
sl0: flags=c015<UP,DEBUG,POINTOPOINT,LINK2,MULTICAST> mtu 296
	inet 10.0.5.1 -> 10.0.5.2 netmask 0xfffffffc

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.000000 ms

nbsd702-server# ping -c1 10.0.2.15
PING 10.0.2.15 (10.0.2.15): 56 data bytes
64 bytes from 10.0.2.15: icmp_seq=0 ttl=255 time=3.630160 ms

----10.0.2.15 PING Statistics----
1 packets transmitted, 1 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 3.630160/3.630160/3.630160/0.000000 ms

nbsd702-server# ping -c1 8.8.8.8
PING google-public-dns-a.google.com (8.8.8.8): 56 data bytes

----google-public-dns-a.google.com PING Statistics----
1 packets transmitted, 0 packets received, 100.0% packet loss

nbsd702-server# 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
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21953
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; MBZ: 0x0005, udp: 4096
;; QUESTION SECTION:
;8.8.8.8.			IN	A

;; ANSWER SECTION:
8.8.8.8.		5	IN	A	8.8.8.8

;; Query time: 20 msec
;; SERVER: 10.0.2.3#53(10.0.2.3)
;; WHEN: Fri Nov 02 15:29:34 UTC 2018
;; MSG SIZE  rcvd: 52

nbsd702-server# 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
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 50349
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;8.8.8.8.			IN	A

;; AUTHORITY SECTION:
.			32162	IN	SOA	a.root-servers.net. nstld.verisign-grs.com.
2018110101 1800 900 604800 86400

;; Query time: 35 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Fri Nov 02 15:29:42 UTC 2018
;; MSG SIZE  rcvd: 111

nbsd702-server# ftp ftp.netbsd.org
Trying [2001:470:a085:999::21]:21 ...
ftp: Can't connect to `2001:470:a085:999::21:21': No route to host
Trying 199.233.217.201:21 ...
Connected to ftp.netbsd.org.
220 ftp.NetBSD.org FTP server (NetBSD-ftpd 20110904) ready.
Name (ftp.netbsd.org:root): anonymous
331 Guest login ok, type your name as password.
Password:
230-
    The NetBSD Project FTP Server located in San Jose, CA, USA
    1 Gbps connectivity

ftp> close
221-
    Data traffic for this session was 0 bytes in 0 files.
    Total traffic for this session was 2723 bytes in 0 transfers.
221 Thank you for using the FTP service on ftp.NetBSD.org.
ftp> quit

nbsd702-server# route show
Routing tables

Internet:
Destination        Gateway            Flags    Refs      Use    Mtu Interface
default            10.0.2.2           UG          -        -      -  wm0
10.0.2/24          link#1             U           -        -      -  wm0
10.0.2.2           52:55:0a:00:02:02  UHL         -        -      -  wm0
10.0.2.3           52:55:0a:00:02:03  UHL         -        -      -  wm0
10.0.2.15          52:54:00:12:34:56  UHL         -        -      -  lo0
nbsd702            nbsd702-server     UH          -        -      -  sl0
127/8              localhost          UGR         -        -  33192  lo0
localhost          localhost          UH          -        -  33192  lo0


Tcpdump on server:

nbsd702-server# tcpdump -v -i sl0
tcpdump: listening on sl0, link-type SLIP (SLIP), capture size 262144 bytes
15:33:16.905264 IP (tos 0x0, ttl 255, id 20, offset 0, flags [none],
proto ICMP (1), length 84, bad cksum 9d92 (->a279)!)
    13.10.0.5 > arennes-259-1-2-net.w2-13.abo.wanadoo.fr: ICMP
redirect 0.0.0.0 to host 59-100-129-84.cust.static-ipl.aapt.com.au,
length 64 (wrong icmp cksum 800 (->d91b)!)
	IP0
15:33:52.857565 IP (tos 0x0, ttl 255, id 21, offset 0, flags [none],
proto ICMP (1), length 84, bad cksum 9d90 (->a278)!)
    13.10.0.5 > arennes-259-1-2-net.w2-13.abo.wanadoo.fr: ICMP
redirect-tos 0.0.0.0 to net AC95A88E.ipt.aol.com, length 64 (wrong
icmp cksum 800 (->2fe)!)
	IP0
15:34:11.519093 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none],
proto UDP (17), length 67, bad cksum 5fa6 (->618f)!)
    13.10.0.5.printer >
arennes-259-1-2-net.w2-13.abo.wanadoo.fr.65518: UDP, bad length 45 >
39
15:34:16.610025 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none],
proto UDP (17), length 67, bad cksum 5fa6 (->618f)!)
    13.10.0.5.printer >
arennes-259-1-2-net.w2-13.abo.wanadoo.fr.65518: UDP, bad length 45 >
39
15:34:26.752709 IP (tos 0x0, ttl 255, id 22, offset 0, flags [none],
proto ICMP (1), length 84, bad cksum a08e (->a277)!)
    13.10.0.5 > arennes-259-1-2-net.w2-13.abo.wanadoo.fr: ICMP
type-#2, length 64 (wrong icmp cksum 800 (->5fd)!)
15:34:43.111498 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none],
proto UDP (17), length 68, bad cksum 5fa5 (->618e)!)
    13.10.0.5.printer >
arennes-259-1-2-net.w2-13.abo.wanadoo.fr.65517: UDP, bad length 45 >
40
15:34:48.345038 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none],
proto UDP (17), length 68, bad cksum 5fa5 (->618e)!)
    13.10.0.5.printer >
arennes-259-1-2-net.w2-13.abo.wanadoo.fr.65517: UDP, bad length 45 >
40
15:34:58.499352 IP (tos 0x0, ttl 255, id 23, offset 0, flags [none],
proto ICMP (1), length 84, bad cksum a081 (->a276)!)
    13.10.0.5 > arennes-259-1-2-net.w2-13.abo.wanadoo.fr: ICMP
type-#2, length 64 (wrong icmp cksum 800 (->5f1)!)
15:35:16.050037 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none],
proto UDP (17), length 66, bad cksum 5fa7 (->6190)!)
    13.10.0.5.printer >
arennes-259-1-2-net.w2-13.abo.wanadoo.fr.65516: UDP, bad length 45 >
38
15:35:21.718507 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none],
proto UDP (17), length 66, bad cksum 5fa7 (->6190)!)
    13.10.0.5.printer >
arennes-259-1-2-net.w2-13.abo.wanadoo.fr.65516: UDP, bad length 45 >
38
15:35:31.999437 IP (tos 0x0, ttl 255, id 24, offset 0, flags [none],
proto ICMP (1), length 84, bad cksum 9c7f (->a472)!)
    13.10.0.5 > 2.8.8.8: ICMP echo request, id 54332, seq 60160,
length 64 (wrong icmp cksum aa (->f8a9)!)
15:35:53.410790 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none],
proto UDP (17), length 64, bad cksum 5fa9 (->6192)!)
    13.10.0.5.printer >
arennes-259-1-2-net.w2-13.abo.wanadoo.fr.65514: UDP, bad length 45 >
36
15:35:58.514756 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none],
proto UDP (17), length 64, bad cksum 5fa9 (->6192)!)
    13.10.0.5.printer >
arennes-259-1-2-net.w2-13.abo.wanadoo.fr.65514: UDP, bad length 45 >
36
15:36:03.584863 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none],
proto UDP (17), length 64, bad cksum 5fa9 (->6192)!)
    13.10.0.5.printer >
arennes-259-1-2-net.w2-13.abo.wanadoo.fr.65514: UDP, bad length 45 >
36
15:36:19.390465 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none],
proto UDP (17), length 64, bad cksum 5b9c (->638f)!)
    13.10.0.5.proxy-gateway > 2.8.8.8.59392: UDP, bad length 13560 > 36
15:36:24.494760 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none],
proto UDP (17), length 64, bad cksum 5b9c (->638f)!)
    13.10.0.5.proxy-gateway > 2.8.8.8.59392: UDP, bad length 13560 > 36
15:36:29.629286 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none],
proto UDP (17), length 64, bad cksum 5b9c (->638f)!)
    13.10.0.5.proxy-gateway > 2.8.8.8.59392: UDP, bad length 13560 > 36
15:36:41.358351 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none],
proto UDP (17), length 60, bad cksum 5fad (->6196)!)
    13.10.0.5.printer >
arennes-259-1-2-net.w2-13.abo.wanadoo.fr.65511: UDP, bad length 45 >
32
15:36:46.461605 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none],
proto UDP (17), length 60, bad cksum 5fad (->6196)!)
    13.10.0.5.printer >
arennes-259-1-2-net.w2-13.abo.wanadoo.fr.65511: UDP, bad length 45 >
32
15:36:56.729723 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none],
proto UDP (17), length 60, bad cksum 5fad (->6196)!)
    13.10.0.5.printer >
arennes-259-1-2-net.w2-13.abo.wanadoo.fr.65510: UDP, bad length 45 >
32
15:37:02.289708 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none],
proto UDP (17), length 60, bad cksum 5fad (->6196)!)
    13.10.0.5.printer >
arennes-259-1-2-net.w2-13.abo.wanadoo.fr.65510: UDP, bad length 45 >
32
15:37:12.604938 IP (tos 0x0, ttl 64, id 25, offset 0, flags [none],
proto UDP (17), length 73, bad cksum 5f87 (->6170)!)
    13.10.0.5.printer >
arennes-259-1-2-net.w2-13.abo.wanadoo.fr.65509: UDP, length 45
15:37:17.716557 IP (tos 0x0, ttl 64, id 26, offset 0, flags [none],
proto UDP (17), length 73, bad cksum 5f86 (->616f)!)
    13.10.0.5.printer >
arennes-259-1-2-net.w2-13.abo.wanadoo.fr.65509: UDP, length 45
15:37:27.991089 IP (tos 0x0, ttl 64, id 27, offset 0, flags [none],
proto UDP (17), length 73, bad cksum 5f85 (->616e)!)
    13.10.0.5.printer >
arennes-259-1-2-net.w2-13.abo.wanadoo.fr.65508: UDP, length 45
15:37:33.529164 IP (tos 0x0, ttl 64, id 28, offset 0, flags [none],
proto UDP (17), length 73, bad cksum 5f84 (->616d)!)
    13.10.0.5.printer >
arennes-259-1-2-net.w2-13.abo.wanadoo.fr.65508: UDP, length 45
^C
25 packets captured
25 packets received by filter
0 packets dropped by kernel


>   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.)

With the client traffic alone I get the following diffs for netstat on
the client and the server.  I think this reflects that only the
10.0.5.1 ping from the server to the client got through.


Netstat diff on server:

98,99c98,99
< 	1 total packet received
< 	0 bad header checksums
---
> 	26 total packets received
> 	25 bad header checksums
211c211
< 	1 total packet received
---
> 	3 total packets received
221c221
< 	1 packet for this host
---
> 	3 packets for this host
237c237
< 		ICMP6: 1
---
> 		ICMP6: 3
240c240
< 		1 one ext mbuf
---
> 		3 one ext mbufs
261c261
< 		router advertisement: 1
---
> 		router advertisement: 3


Netstat diff on client:

51c51
< 	54 connections closed (including 0 drops)
---
> 	58 connections closed (including 0 drops)
95,96c95,96
< 	0 PCB hash misses
< 	0 datagrams output
---
> 	2 PCB hash misses
> 	20 datagrams output
119,120c119,120
< 	0 packets sent from this host
< 	0 packets sent with fabricated ip header
---
> 	20 packets sent from this host
> 	5 packets sent with fabricated ip header
211c211
< 	0 total packets received
---
> 	2 total packets received
221c221
< 	0 packets for this host
---
> 	2 packets for this host
227c227
< 	2 packets sent from this host
---
> 	4 packets sent from this host
235a236,237
> 	Input packet histogram:
> 		UDP: 2
237c239
< 		0 one mbufs
---
> 		2 one mbufs
244,245c246,247
< 	0 forward cache hit
< 	0 forward cache miss
---
> 	1 forward cache hit
> 	1 forward cache miss
309c311
< 	54 connections closed (including 0 drops)
---
> 	58 connections closed (including 0 drops)
345c347
< 	0 datagrams received
---
> 	2 datagrams received
353,354c355,356
< 	0 delivered
< 	0 datagrams output
---
> 	2 delivered
> 	2 datagrams output


>   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.

I've been testing this on two virtual machines with the server
connected through usermode slirp on qemu.  I was hoping to get it
sorted before running on a live system, but I can try on real hardware
within the next few days.



Home | Main Index | Thread Index | Old Index