Date: Thu, 19 Apr 2007 23:50:00 +1000 From: Alan Garfield <alan@fromorbit.com> To: Yar Tikhiy <yar@comp.chem.msu.su> Cc: freebsd-net@freebsd.org Subject: Re: rtentry and rtrequest Message-ID: <1176990600.4177.26.camel@hiro.auspc.com.au> In-Reply-To: <20070419113842.GE60301@comp.chem.msu.su> References: <1176861009.4426.21.camel@hiro.auspc.com.au> <20070418120622.GF40826@comp.chem.msu.su> <1176947814.4175.39.camel@hiro.auspc.com.au> <20070419073525.GA60301@comp.chem.msu.su> <1176972863.4177.7.camel@hiro.auspc.com.au> <20070419093847.GC60301@comp.chem.msu.su> <1176976273.4177.17.camel@hiro.auspc.com.au> <20070419113842.GE60301@comp.chem.msu.su>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 2007-04-19 at 15:38 +0400, Yar Tikhiy wrote:
> inet 127.0.0.1 netmask 0xff000000
> > jnet0: flags=845<UP,DEBUG,RUNNING,SIMPLEX> mtu 241
> > inet 169.254.101.3 netmask 0xffff0000
> > ether 00:09:3d:00:00:03
>
> Note that jnet0 has no broadcast address. That should be wrong for
> an Ethernet interface. (Honestly, I'm still uncertain whether it is
> legal at all for an interface to have none of the following flags:
> BROADCAST, POINTOPOINT, LOOPBACK.)
Now looks like :-
----
jnet0: flags=8847<UP,BROADCAST,DEBUG,RUNNING,SIMPLEX,MULTICAST> mtu 241
inet 169.254.101.3 netmask 0xffff0000 broadcast 169.254.255.255
ether 00:09:3d:00:00:03
----
> > 169.254 link#4 UC 0 0 jnet0
> ^^^^^^^^^
> This record is there. Good... Note the C (cloning) flag.
> Individual ARP records will be "cloned" from this one via
> the rtresolve mechanism.
Now looks even better like this :-
----
169.254 link#4 UC 0 0 jnet0
169.254.101.2 00:09:3d:00:00:02 UHLW 1 1882 jnet0
687
----
Ooo an look at this :-
----
[alan@twofish jnet_pci]$ ping 169.254.101.2
PING 169.254.101.2 (169.254.101.2): 56 data bytes
64 bytes from 169.254.101.2: icmp_seq=0 ttl=255 time=2.816 ms
64 bytes from 169.254.101.2: icmp_seq=1 ttl=255 time=2.709 ms
64 bytes from 169.254.101.2: icmp_seq=2 ttl=255 time=2.734 ms
64 bytes from 169.254.101.2: icmp_seq=3 ttl=255 time=2.736 ms
64 bytes from 169.254.101.2: icmp_seq=4 ttl=255 time=2.730 ms
64 bytes from 169.254.101.2: icmp_seq=5 ttl=255 time=2.744 ms
----
Looks like it's working!
> In fact, you were overriding the normal ARP's arp_rtrequest() handler
> for the addresses. Grep /sys/netinet/if_ether.c for ifa_rtrequest.
> See also rtentry(9) (again, search for ifa_rtrequest). That's why nothing
> worked.
Indeed, I still don't fully understand what the problem was really. But
it seems to be working ok now.
BUT! Now I have a weird bug.
SSH on the SP whinges about :-
----
localhost $ ssh -v 169.254.101.3
OpenSSH_3.4p1, SSH protocols 1.5/2.0, OpenSSL 0x0090703f
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Rhosts Authentication disabled, originating port will not be
trusted.
debug1: ssh_connect: needpriv 0
debug1: Connecting to 169.254.101.3 [169.254.101.3] port 22.
debug1: Connection established.
debug1: identity file /home/manager/.ssh/identity type -1
debug1: identity file /home/manager/.ssh/id_rsa type -1
debug1: identity file /home/manager/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version
OpenSSH_4.5p1 FreeBSD-20061110
debug1: match: OpenSSH_4.5p1 FreeBSD-20061110 pat OpenSSH*
Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_3.4p1
debug1: SSH2_MSG_KEXINIT sent
d475 078f 7eae aef6
Disconnecting: Bad packet length -730527857.
debug1: Calling cleanup 0x1001fc68(0x0)
localhost $
----
... bad packet length! UGH! :)
Since there is no telnet, vi or any other _testable_ services on the SP
I'm stuffed to figure out what's wrong with the packets on the SP side.
I can tcpdump on the platform side and everything looks peachy.
How can I look at the tcp packet length in the data?
> > Yeah it's what the Linux driver is called. Can be something else, got a
> > better name? :)
>
> Perhaps just "jn"? Some utilities still have trouble with long
> interface names[1], and they are a drag to type in. :-) So I'd
> rather keep the name as short as possible.
Yeah 'jn' sounds ok to me. Although it's really not going to be that
common unless you have these SunFire or NewISys servers. :)
Thanks,
Alan.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1176990600.4177.26.camel>