Closed Bug 11204 Opened 25 years ago Closed 20 years ago

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

Categories

(Core :: Networking, defect, P3)

Product:
Core
Component:
Networking
Platform:
x86
All
Type:
defect

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: pawyskoczka, Assigned: darin.moz)

References

Details

Attachments

(1 file)

can someone on the lan test it with this patch.
1.16 KB, patch
Details | Diff | Splinter Review 
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.
Target Milestone: M9
Is this the same as bug #10832, but on Win95 only?  I thought I fixed this bug
:-(
-- rick
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.
Blocks: 11349
Blocks: 7229
Severity: critical → blocker
Whiteboard: [QA M9 BLOCKER]
Putting on [QA M9 BLOCKER] radar
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.
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.
Assignee: rpotts → gagan
hey gagan,
I've reassigned this bug to you since I think that you are actually looking at
it :-)
-- rick
gagan status on a fix for M9 branch?
Status: NEW → ASSIGNED
investigating...
Whiteboard: [QA M9 BLOCKER] → [QA M9 BLOCKER] Waiting to debug in test lab.
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
QA Contact: paulmac → paw
Target Milestone: M9 → M10
Moving to M10.  Give ya some more time to work on this.  M9 train is leaving.
Whiteboard: [QA M9 BLOCKER] Waiting to debug in test lab. → Workaround set. Fix will be checked in soon.
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?
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Fix checked on the tip.
Status: RESOLVED → REOPENED
Seems to be broken in m10 build 8/30.  Gagan is looking into the problem.
Resolution: FIXED → ---
Clearing Fixed resolution due to reopen
OS: Windows 95 → All
Summary: Apprunner does not load pages on isolated Lan (Windows) → Apprunner does not load pages on isolated Lan
other platforms problem too.
Status: REOPENED → ASSIGNED
Summary: Apprunner does not load pages on isolated Lan → IP Addresses dont work (was on isolated Lan)
Target Milestone: M10 → M11
Corrected status. May have a dup somewhere as well.
*** Bug 10326 has been marked as a duplicate of this bug. ***
*** Bug 11394 has been marked as a duplicate of this bug. ***
*** Bug 13103 has been marked as a duplicate of this bug. ***
*** Bug 14246 has been marked as a duplicate of this bug. ***
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.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → DUPLICATE
*** This bug has been marked as a duplicate of 12748 ***
Status: RESOLVED → VERIFIED
Marking Verified as a dup.
Bulk move of all Necko (to be deleted component) bugs to new Networking

component.
Summary: IP Addresses dont work (was on isolated Lan) → Conn: IP Addresses dont work (was on isolated Lan)
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).
Blocks: 12748
Status: VERIFIED → REOPENED
Keywords: makingtest
Resolution: DUPLICATE → ---
Benc: still an issue? if it is then give this to darin. thx.
I'll see if this can be tested w/ Tom's current networking setup.
QA Contact: paw → benc
Tom, when you get the isolated lan running, lets have you try a config w/o dns.
QA Contact: benc → tever
Benc:  the lan has been set up for awhile now, just come and get me and we can
take a look at this
www.free-ed.net stalls in 1.5 nightly release but works with 1.5 release
canidate 1 . Sept 23, 03
is this fixed? seems like a patch was submitted a long time ago.
Flags: blocking1.6b?
Flags: blocking1.6b? → blocking1.6b-
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.
Assignee: gagan → benc
Severity: blocker → normal
Status: REOPENED → NEW
Flags: blocking1.6b-
Target Milestone: M11 → ---
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.
Assignee: benc → darin
QA Contact: tever → benc
Whiteboard: Workaround set. Fix will be checked in soon.
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.
Status: NEW → RESOLVED
Closed: 25 years ago → 20 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: