11204 - Conn: IP Addresses dont work (was on isolated Lan)

Status: RESOLVED WORKSFORME

(Core :: Networking, defect, P3)

Description

[Paul Wyskoczka]

Overview Description:
While running the page performance tests on the isolated lan, tried to submit
the following url http://208.12.28.99/yahoo.  The page does not load. Typing
http://208.12.28.99/yahoo/index.html does not load the page either.

Steps to Reproduce:
1)Install Apprunner
2)Setup isolated lan
3)Launch Apprunner
3)Load the url http://208.12.28.99/yahoo
4)Page does not load, the barber pole spins for a long time and then stops but
the page is never displayed.  It also does not seem to crash.

Actual Results:
The yahoo page does not load

Expected Results:
The yahoo page will load


Build Date & Platform Bug Found:
1999080308 Windows build

Additonal information:
There was a similar bug in linux but in that case using index.html would load
the page.  Linux is now fixed and the mac build also works like linux.

Comment 1

[rpotts (gone)]

Is this the same as bug #10832, but on Win95 only?  I thought I fixed this bug
:-(
-- rick

Comment 2

[Paul Wyskoczka]

This is a similar bug but on the Windows platform.  Rick, your fix for Linux
worked and the only difference I see in the behavior on Windows is that using
index.html does not load a page whereas on Linux it did.

Comment 3

[leger]

Putting on [QA M9 BLOCKER] radar

Comment 4

[Judson Valeski]

I can't get any of these urls to load (in Com. 4.x). This bug isn't making sense
to me. Isolated (meaning no dns) Win networks typically use WINS resolution to
find hosts, but it looks like you're providing an IP address which would bypass
dns/WINS altogether.

Comment 5

[Paul Wyskoczka]

I know that the 5.0 builds prior to necko worked in the isolated Lan.  You probably cannot connect ot 208.12.28.99 because it's not on
the corporate network.  If you would like to check it out in the lab, I would more be more that happy to help out.

Comment 6

[rpotts (gone)]

hey gagan,
I've reassigned this bug to you since I think that you are actually looking at
it :-)
-- rick

Comment 7

[leger]

gagan status on a fix for M9 branch?

Comment 8

[Gagan]

investigating...

Comment 9

[Gagan]

Need help from Paul for setting up the test environment. He's gone for the day.
I may have to setup a debugger on this isolated lan to figure out what's
happening. Paul could you give me a call (at home) whenever (past 10:00 AM) you
get in on Monday. Thx. -Gagan

Comment 10

[leger]

Moving to M10.  Give ya some more time to work on this.  M9 train is leaving.

Comment 11

[Gagan]

I have set up a work around for Paul for now and have the fix that I will check
in soon. Marking as unblocked now. Should I check the fix in M9_branch? or M10?

Comment 12

[Gagan]

Fix checked on the tip.

Comment 13

[Paul Wyskoczka]

Seems to be broken in m10 build 8/30.  Gagan is looking into the problem.

Comment 14

[leger]

Clearing Fixed resolution due to reopen

Comment 15

[Gagan]

other platforms problem too.

Comment 16

[Andreas Otte]

Attachment: can someone on the lan test it with this patch.

Comment 17

[Gagan]

Corrected status. May have a dup somewhere as well.

Comment 18

[Gagan]

*** Bug 10326 has been marked as a duplicate of this bug. ***

Comment 19

[Gagan]

*** Bug 11394 has been marked as a duplicate of this bug. ***

Comment 20

[Gagan]

*** Bug 13103 has been marked as a duplicate of this bug. ***

Comment 21

[Gagan]

*** Bug 14246 has been marked as a duplicate of this bug. ***

Comment 22

[Andreas Otte]

There is more information on this in bug 12748. That information shows that the
patch I proposed will not work on windows because of the faulty gethostbyname
implementation. We need something that creates a hostent structure manually and
delivers back the IP, if a IP was put in. I think this bug can be marked a
duplicate of 12748.

Comment 23

[Gagan]

*** This bug has been marked as a duplicate of 12748 ***

Comment 24

[leger]

Marking Verified as a dup.

Comment 25

[leger]

Bulk move of all Necko (to be deleted component) bugs to new Networking

component.

Comment 26

[benc]

REOPEN:
Working on setting up Isolated LAN testing (no DNS), so bug 12748 was more of a
depends. Sending most of the dupes  there for record keeping (a painful lesson
on DNS).

Comment 27

[Gagan]

Benc: still an issue? if it is then give this to darin. thx.

Comment 28

[benc]

I'll see if this can be tested w/ Tom's current networking setup.

Comment 29

[benc]

Tom, when you get the isolated lan running, lets have you try a config w/o dns.

Comment 30

[Tom Everingham]

Benc:  the lan has been set up for awhile now, just come and get me and we can
take a look at this

Comment 31

[Scott]

www.free-ed.net stalls in 1.5 nightly release but works with 1.5 release
canidate 1 . Sept 23, 03

Comment 32

[Peter Kroll]

is this fixed? seems like a patch was submitted a long time ago.

Comment 33

[Simon Paquet [:sipaq]]

Benc, you reopened this bug over two years ago, but no there are no
confirmations since then. Can you please test this again and resolve it if possible.

Also this bug does not qualify as a blocker. The M11 milestone is gone for years.

Comment 34

[benc]

If you don't like the severity, change that. I didn't set it to blocker or
critical, my director at the time did because it broke lots of stuff.

But don't assign a bug to me because it needs more analysis. It doesn't make any
sense for me to own something I'm not going to fix. If there is some reasoning
behind this, please explain, in the past, people usually assign me bugs because
they think it is my fault.

Comment 35

[benc]

RESOLVED/WFM:
I don't know if this patch was ever checked in, so WFM.

I've done a fair amount of packet analysis to make sure this works the way I
want on Mac OS X. I'll try to do Linux and Windows soon, but it seems that speed.

The problem here is that NOBODY runs on a DNS-free network, so this problem can
be easily masked, but we keep getting occassioanl reports of spurious reverse
lookups.