] Are you sure it's failing to allocate the port?
]
] I had a similar problem in trying to connect to a service, but
] found out that aliasing an IP didn't add the arp entry in the routing
] table (local connections were failing). If I added the arp entry by
] hand, everything was happy (is IP aliasing a part of the scneario
] you're describing?).
]
] arp -s a.b.c.d 00:60:08:aa:aa:aa pub
] arp -s a.b.c.e 00:60:08:aa:aa:ab pub
]
] A tad annoying, but it seems to work (yeah, I know about the
] ethers file, but I refuse to use it). -sc
Unfortunately, I'm very certain.
I talked to Bill Paul about the gratuitous ARP problem last
night; I was well aware of it; we added the ARP entries by
hand to the target for the aliases on the source machine.
I'm _positive_ on the outbound connection problem (the code
fragment I attached should have done the job, and I've seen
the FreeBSD code that's the problem, but am still pondering
about how to fix it; I think I'll have to do two lookups, or
hang a chain off a hash bucket indexed by IP last (instead
of port). Hopefully, someone will get to this before I do.
We've also tried by setting up the ARP table for the target
machine, and then written the aforementioned BPF program to
stage the connection attempts from a single client machine.
We did the same thing from a second client on the same segment.
The single client, two IP attempt failed, while the two machine
attempt succeeded. The only difference in the packets that was
reported by tcpdump was the source MAC address -- otherwise,
they were byte-for-byte identical.
So there is definitely a problem there with the index being by
MAC instead of IP.
Maybe this came in as part of the "aliased IP NFS client being
seen as an attacker by the server" fix?
Terry Lambert
[EMAIL PROTECTED]
---
Any opinions in this posting are my own and not those of my present
or previous employers.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
