On Mon, 10 Apr 2000, Holger Kruse wrote:
> On Mon, Apr 10, 2000 at 06:06:42PM -0700, Fred Wright wrote:
>
> > 1) A loopback connection to the real local IP of a P2P interface uses the
> > IP of the default interface rather than the target interface, including
> > failing completely if the default interface is offline. This probably
> > doesn't affect many people, but I think I specified the bug and the fix
> > fairly precisely a while back.
>
> I'll have another look at this. In my tests I could not reproduce
> it...
When I originally reported it I didn't know that being a P2P interface
mattered, although the analysis I sent privately based on looking at the
online FreeBSD sources said so. Perhaps you didn't test with P2P?
What I did to see it was:
1) Put the LAN online.
2) Put a dialup interface online.
3) Use "telnet <PPP IP address> discard" as a test connection.
4) Look at the addresses with MiamiNetStat. The client side uses the LAN
IP instead of the PPP IP.
If the LAN is taken offline, #3 fails, with the client in SYN_SENT and the
server in SYN_RCVD, since the response to the initial SYN is routed into
the bit bucket.
> > 2) NAT may choose the wrong source IP when multiple Internet interfaces
> > are online.
>
> Actually the NAT engine I used does not support multiple "Internet"
> interfaces at all. The original FreeBSD version always uses a fixed
> source IP address. I extended it to at least vary the source IP address
> depending on which interface is online, but the situation where multiple
> "Internet" interfaces are online and the source IP address has to be
> picked based on routing is still not handled correctly. Will be added
> in one of the next version, but adding it is somewhat tricky so I did
> not want to do it before the 1.0 release.
This may explain why the bug wasn't obvious in the online FreeBSD sources,
since that code looks like it *is* trying to handle this correctly,
although between the complexity of the code and the sparseness of comments
on the structure definitions, I wasn't entirely sure.
> > BTW, is the lack of a 68000 version permanent?
>
> I don't know yet. The problem is that the new code contains
> word and longword accesses in too many places. Just recompiling
> for 68000 would not help, and the lack of proper debugging
> environments for 68000 makes things even more difficult...
Inherently unaligned data, I take it? Gratuitous misalignments are
naturally undesirable for performance reasons, even on 020+, though not
enough to recopy data just to align it.
Fred Wright
--
To unsubscribe send "unsubscribe miami-talk-ml" to
"[EMAIL PROTECTED]". For help on list commands send "help" to
"[EMAIL PROTECTED]".
