Re: multiple loopback devices?
No, I don't see any problem with the lo driver.
The problem is that
nc -lp 1000 xx
binds to any ip number, but closes down traffic not from xx.
Where
nc -lp 1000 -s xx
binds only to xx, i.e. the kernel only hands it traffic destined to
that ip number.
Regards,
/Karl
-----------------------------------------------------------------------
Karl Hammar Aspö Data karl@kalle.csb.ki.se
Lilla Aspö 2340 +46 173 140 57 Networks
S-742 94 Östhammar +46 10 270 26 67 Computers
Sweden Consulting
-----------------------------------------------------------------------
Ok, did (# = term 1, $ = term 2):
# ifconfig lo:1 172.16.0.1
# ifconfig lo:2 172.17.0.1
# ifconfig
...
lo:1 Link encap:Local Loopback
inet addr:172.16.0.1 Mask:255.255.0.0
UP LOOPBACK RUNNING MTU:3924 Metric:1
lo:2 Link encap:Local Loopback
inet addr:172.17.0.1 Mask:255.255.0.0
UP LOOPBACK RUNNING MTU:3924 Metric:1
$ ping 172.16.0.1
# tcpdump -i lo
tcpdump: listening on lo
11:50:51.085310 172.16.0.1 > 172.16.0.1: icmp: echo request
11:50:51.085310 172.16.0.1 > 172.16.0.1: icmp: echo request
11:50:51.085355 172.16.0.1 > 172.16.0.1: icmp: echo reply
11:50:51.085355 172.16.0.1 > 172.16.0.1: icmp: echo reply
# nc -nlvp 1000 -s 172.16.0.1
listening on [172.16.0.1] 1000 ...
$ netstat -tnl
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 172.16.0.1:1000 0.0.0.0:* LISTEN
...
That's all well.
$ nc -nv 172.17.0.1 1000
(UNKNOWN) [172.17.0.1] 1000 (?) : Connection refused
No-one is listening on that ip-/port-number.
$ nc -nv 172.16.0.1 1000
(UNKNOWN) [172.16.0.1] 1000 (?) open
Works ok.
Compare that with:
# nc -nlvp 1000 172.16.0.1
listening on [any] 1000 ...
x invalid connection to [172.17.0.1] from (UNKNOWN) [172.17.0.1] 1300
#
$ netstat -tnl
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 0.0.0.0:1000 0.0.0.0:* LISTEN
...
$ nc -nv 172.17.0.1 1000
(UNKNOWN) [172.17.0.1] 1000 (?) open
$
The tcpdump show the conversation:
# tcpdump -i lo
tcpdump: listening on lo
12:13:06.293927 172.17.0.1.1301 > 172.17.0.1.1000: S 3979465494:3979465494(0) win 31072 <mss 3884,sackOK,timestamp 9464557 0,nop,wscale 0> (DF)
12:13:06.293927 172.17.0.1.1301 > 172.17.0.1.1000: S 3979465494:3979465494(0) win 31072 <mss 3884,sackOK,timestamp 9464557 0,nop,wscale 0> (DF)
12:13:06.293981 172.17.0.1.1000 > 172.17.0.1.1301: S 3981426658:3981426658(0) ack 3979465495 win 31072 <mss 3884,sackOK,timestamp 9464557 9464557,nop,wscale 0> (DF)
12:13:06.293981 172.17.0.1.1000 > 172.17.0.1.1301: S 3981426658:3981426658(0) ack 3979465495 win 31072 <mss 3884,sackOK,timestamp 9464557 9464557,nop,wscale 0> (DF)
12:13:06.294010 172.17.0.1.1301 > 172.17.0.1.1000: . ack 1 win 31072 <nop,nop,timestamp 9464557 9464557> (DF)
12:13:06.294010 172.17.0.1.1301 > 172.17.0.1.1000: . ack 1 win 31072 <nop,nop,timestamp 9464557 9464557> (DF)
12:13:06.295456 172.17.0.1.1000 > 172.17.0.1.1301: F 1:1(0) ack 1 win 31072 <nop,nop,timestamp 9464557 9464557> (DF)
12:13:06.295456 172.17.0.1.1000 > 172.17.0.1.1301: F 1:1(0) ack 1 win 31072 <nop,nop,timestamp 9464557 9464557> (DF)
12:13:06.295567 172.17.0.1.1301 > 172.17.0.1.1000: . ack 2 win 31072 <nop,nop,timestamp 9464557 9464557> (DF)
12:13:06.295567 172.17.0.1.1301 > 172.17.0.1.1000: . ack 2 win 31072 <nop,nop,timestamp 9464557 9464557> (DF)
12:13:06.298675 172.17.0.1.1301 > 172.17.0.1.1000: F 1:1(0) ack 2 win 31072 <nop,nop,timestamp 9464557 9464557> (DF)
12:13:06.298675 172.17.0.1.1301 > 172.17.0.1.1000: F 1:1(0) ack 2 win 31072 <nop,nop,timestamp 9464557 9464557> (DF)
12:13:06.298718 172.17.0.1.1000 > 172.17.0.1.1301: . ack 2 win 31072 <nop,nop,timestamp 9464557 9464557> (DF)
12:13:06.298718 172.17.0.1.1000 > 172.17.0.1.1301: . ack 2 win 31072 <nop,nop,timestamp 9464557 9464557> (DF)
Line x above contains the "invalid connection" message you was pussled
about.
In the first nc -lvp (with -s), nc binds to a specific ip-number.
In the second (without -s) it binds to any ip-number, but closes down
connections (and complains about it) from other than the given source
address.
--------------------
From: Michael Wood <wood@kingsley.co.za>
Subject: Re: multiple loopback devices?
Date: Wed, 16 May 2001 10:18:34 +0200
> On Wed, May 16, 2001 at 09:11:16AM +0200, Karl Hammar wrote:
> >
> > The reason for the "invalid connection" message is probably due
> > to how nc handles incoming connections.
> >
> > Doing
> >
> > nc -l -p 1000 127.0.0.1
> >
> > makes it bind to port 1000 on any attached interface, and it
> > only accepts connections from source address 127.0.0.1.
> >
> > It will not bind to port 127.0.0.1 only as one could assume.
> [snip]
> >
> > From: bronson@rinspin.com (Scott Bronson)
> > Subject: Re: multiple loopback devices?
> > Date: Fri, 13 Apr 2001 20:59:43 -0700
> >
> [snip]
> > > lo Link encap:Local Loopback
> > > inet addr:127.0.0.1 Mask:255.255.255.0
> [snip]
> > >
> > > lo:1 Link encap:Local Loopback
> > > inet addr:127.1.0.1 Mask:255.255.255.0
> [snip]
> > >
> > > The following works:
> > >
> > > (term 1) elle:/home/bronson# nc -l -p 1000 127.1.0.1
> > > (term 2) bronson@elle:~$ nc 127.1.0.1 1000
> > >
> > > But this error baffles me:
> > >
> > > (term 1) elle:/home/bronson# nc -l -p 1000 127.1.0.1
> > > (term 2) bronson@elle:~$ nc 127.0.0.1 1000
> > > (term 1) invalid connection to [127.0.0.1] from (UNKNOWN) [127.0.0.1] 2254
> > >
> > > So, even though they're separate addresses and netmasks,
> > > they still conflict with each other somehow. Am I making a
> > > silly mistake here?
>
> This probably has something to do with the way the loopback
> driver is written.
>
> If you do this:
> 1) # nc -lvp 1000 -s 127.1.0.1
> 2) $ nc -v 127.0.0.1 1000
> 2) localhost. [127.0.0.1] 1000 (?) : Connection refused
>
> Which is as it should be :) (notice the "-s" in the first
> line.)
>
> --
> Michael Wood | Tel: +27 21 762 0276 | http://www.kingsley.co.za/
> wood@kingsley.co.za | Fax: +27 21 761 9930 | Kingsley Technologies
Reply to: