OS4 Final Stability and Network problems

@BobW

Quote:
Sory I never mentioned that, I had done it to speed up the loading of OS4, but I seem to remember I got a lock up, or a very long delay, and assumed it was to do with that.

@BobW

I just noticed your thread from a link on amigaworld.net. I have had a very similar problem and found a very similar solution independently.

It seems that my microA1 does not like to connect to my router (Netgear FR114P) via DHCP. This is the same router I've had for a couple of years, and it always worked before, which seems to make it a software issue with OS4Final.

On the other hand, I have also an A1-XE (my wife's actually, but I do the upgrades and maintenance) attached to the SAME router, and it has NO problems at all connecting to the router using OS4Final. Which seems to make it a hardware issue.

It seems that there is some subtle difference between how the same eth3com.device interacts with the ethernet chip on the microA1 versus the A1XE. On the microA1 I get the same problem that you mentioned: hard locks, no GR, keyboard and mouse locked out, need to do a cold reboot after each lockup.

Things I have tested:

getnetstatus showed that the interface was configured and available.

shownetstatus reported the correct local host address (I had configured my router to assign always 192.168.0.5 to my microA1 on the LAN side of the firewall) and correct default gateway. However, it showed DUPLICATE DNS server entries. I did not statically configure any DNS servers, but let DHCP set them up, and shownetstatus gave me a list of 6 DNS servers, with the last 3 being duplicates of the first 3. The server addresses themselves were correct.

pinging the router or anything else on the LAN gave 100% packet loss.

If I change the setup to static routes and static DNS servers instead of DHCP, all works fine, ALMOST. After changing the settings to static, I had one further lockup upon my next cold reboot, but since then, I have had the system up for about 36 hours, online the whole time, and it is completely stable.

Hope this helps with the diagnosis!

--Stuart Anderson

@mr_homm

Interesting. So it sounds like a Micro specific problem and it appears to be something that was introduced with final. I had no issues with Update 4.

@BobW
Quote:
Well I have two MicroA1-C systems (GX and FX) and they both work without any lockups or lost connections.

@ssolie

Quote:

So that means there is no problem? I don't think I'm the only one that has encountered this problem. There was a thread over on AW.net where a couple other people had similar issues.

Setting up an A1 for DHCP is extremely easy but when I do it my A1 Hard freezes either during bootup or shortly after. Now my router may have issues or my network could be busy but this doesn't effect my two macs and my two XP machines.

Unfortunately things have been busy at home so I haven't had enough time to do more debugging. It's a choice between working with my A1 or helping my 9 year old with cub scouts.

@ssolie

Link to the Amiga World post

@BobW
Quote:
I don't suspect it is any sort of h/w problem. I think it is more likely to be something to do with DHCP clobbering things when it receives certain packets. With my router it does not freeze but with other routers it does. If only we could get debug info. from the users having problems. Especially tcpdump and adding DEBUG to the interface so the packets can be inspected. A sniffer would be ideal of course.

@BobW

Hi Bob, I am an OS4 beta tester and I had found this exact situation and reported it as a bug prior to OS4 final release.

Unfortunately Hyperion was unable to verify the bug. It appears ONLY to affect the MicroA1 and possibly only GX processors (which cpu do you have in the Micro?) but that is unconfirmed.

I have also verified that switching to static IP addressing does in fact resolve the issue. I did this independently and before I read this thread.

I have updated the bug and reported this new information to the OS4 dev. team, so hopefully it can be resolved in a future OS4 update.

Thanks,
Darren

@HammerD

Yes, I also have a GX processor.

I'm going to try really hard tonight to spend some time debugging this.

Thanks!

@HammerD
Quote:
I have a GX as well and no such freezing has been observed here.

I'll have to chat with you in the beta channel about this and maybe we can figure out what is different between our machines and maybe narrow the problem down.

@ssolie

I also have a ?A1 GX, and have experienced no such problems either.

@PEB and @ssolie

I wonder if it's a combination of the GX processor and the particular router. I'll bring my A1 in to work tomorrow and see if it has issues with our business DHCP servers.

@mr_homm

Quote:

I had the same issue with pre3 on A1X\EG4. Reported it to Friedens then and went static. The other side of the cable was a switch.


Jack

@BobW

I made a post on AW about this exact problem that I'm having with my A1XE with a 750FX and its not DHCP from a router, but DHCP from a SuSE 10.2 linux box.

Edit: This was the post... I'm working around it by setting a static address.

@Reaps
Quote:
I still don't think this is a h/w problem but I do think certain h/w configurations cause it to show up more often than others.

The whole duplicate DNS entry thing is a very good clue I think...

@ssolie

I added DEBUG to my interface tonight. With DEBUG turned on the network connection works perfect with 0% packet loss. As soon as I remove DEBUG I get 30-40% packet loss and some hard lockups. I'm not getting as many tonight but I do get the packet loss every time.

I am seeing the duplicate DNS servers both when the interface is working and when it is having problems.

My sniffer isn't working. I think the ethernet ports on my router are switched so I'm not seeing most of the traffic. I'll try to borrow an old hub tomorrow.

Here is the debug output but like I said, it works with debug on:

08-Jan-07 21:58:53 [Debug] Unknown Interface 'interface' hardware address = 00:09:D2:28:03:06.
08-Jan-07 21:58:54 [Debug] Unknown Setting up BOOTP packet for 'interface' with hardware address 00:09:D2:28:03:06.
08-Jan-07 21:58:54 [Debug] Unknown Sent initial DHCPDISCOVER request for 'interface'; transaction ID=0x1ECAEF31, retry timeout=0:00:05 hours, allocation timeout=0:01:00 hours.
08-Jan-07 21:58:59 [Debug] Unknown DHCP retry timeout for 'interface' has elapsed.
08-Jan-07 21:58:59 [Debug] Unknown Setting up BOOTP packet for 'interface' with hardware address 00:09:D2:28:03:06.
08-Jan-07 21:58:59 [Debug] Unknown Resent DHCPDISCOVER request for 'interface'; transaction ID=0x78B9F369, retry timeout=0:00:08 hours.
08-Jan-07 21:58:59 [Debug] Unknown Received BOOTP/DHCP server message for 'interface'.
08-Jan-07 21:58:59 [Debug] Unknown Picking up BOOTP/DHCP server message for 'interface'.
08-Jan-07 21:58:59 [Debug] Unknown Configuration information for 'interface': Server identifier = 192.168.0.1.
08-Jan-07 21:58:59 [Debug] Unknown Setting up BOOTP packet for 'interface' with hardware address 00:09:D2:28:03:06.
08-Jan-07 21:58:59 [Debug] Unknown Setting up DHCP packet for 'interface' with transaction ID = 0x78B9F369, server address = 192.168.0.1, client address = 192.168.0.105.
08-Jan-07 21:58:59 [Debug] Unknown Responding to DHCP offer; sent DHCPREQUEST request for 'interface'; transaction ID=0x78B9F369, retry timeout=0:00:03 hours.
08-Jan-07 21:58:59 [Debug] Unknown Received BOOTP/DHCP server message for 'interface'.
08-Jan-07 21:58:59 [Debug] Unknown Picking up BOOTP/DHCP server message for 'interface'.
08-Jan-07 21:58:59 [Debug] Unknown Server has responded to address allocation request for 'interface'. Suggested IP address is 192.168.0.105.
08-Jan-07 21:58:59 [Debug] Unknown Checking if the IP address 192.168.0.105 proposed for 'interface' is already in use.
08-Jan-07 21:58:59 [Debug] Unknown Configuration information for 'interface': Server hardware address = 00:13:46:C0:93:54.
08-Jan-07 21:59:01 [Debug] Unknown IP address verification timeout for 'interface' has elapsed.
08-Jan-07 21:59:01 [Debug] Unknown Configuration information for 'interface': Server identifier = 192.168.0.1.
08-Jan-07 21:59:01 [Debug] Unknown Configuration information for 'interface': Subnet mask = 255.255.255.0.
08-Jan-07 21:59:01 [Debug] Unknown Configuration information for 'interface': Address lease time = 7 day(s), 0:00:00 hour(s).
08-Jan-07 21:59:01 [Debug] Unknown Configuration information for 'interface': Router = 192.168.0.1.
08-Jan-07 21:59:01 [Debug] Unknown Configuration information for 'interface': Domain name system server = 192.168.0.1.
08-Jan-07 21:59:01 [Debug] Unknown Binding address of 'interface'.
08-Jan-07 21:59:01 [Debug] Unknown Configuration information for 'interface': Server identifier = 192.168.0.1.
08-Jan-07 21:59:01 [Debug] Unknown Configuration information for 'interface': Server IP address = 192.168.0.1.
08-Jan-07 21:59:01 [Debug] Unknown Setting interface 'interface' address to 192.168.0.105.
08-Jan-07 21:59:01 [Debug] Unknown Setting interface 'interface' net mask to 255.255.255.0.
08-Jan-07 21:59:01 [Debug] Unknown Interface 'interface' IP address is now set to 192.168.0.105/255.255.255.0.
08-Jan-07 21:59:02 [Debug] Unknown Interface 'interface' address successfully changed to 192.168.0.105/255.255.255.0.

@BobW

I've found a little additional information about the behavior of ethernet on my microA1:

Even if I set the interface configuration to static, I still sometimes get packet losses after a reboot. However, unplugging and reinserting the ethernet cable from the socked at the back of my microA1 causes the connection to become 100% reliable with no packet loss.

I don't think this is just a matter of a bad ethernet cable connector, because without moving or bumping the cable, I can cause the packet loss by rebooting, and then correct it by unplugging/replugging the ethernet cable. To try to eliminate mechanical failure of the connector, the next time this happens, I'll unplug the OTHER end of the ethernet cable and see what happens.

When I replug it, the indicator light in the receptical flashes briefly twice and then comes on steadily. To me (with my limited knowledge of ethernet hardware), this SEEMS like something is being reset when the connection is being reestablished. Speculation: the ethernet controller somehow gets into a bad state, and the replugging resets it to a valid state, after which everything works.

Perhaps others could try to verify this?

--Stuart Anderson

@ssolie

I have a ?A1-C with a 750GX aswell and have never experienced any problems with internet. Other than very slow throughput uptil upd4.

I have My PC and ?A1-C connected to a wireless router (with the wireless part unused at the moment). It's a Netgear WGT624 v2 with the latest firmware 4.2.11.
It has always worked great, no problems whatsoever.

Replying to my own earlier post:

I have now tried again after a reboot, and I have verified the ethernet behavior: After ethernet is first initialized and addnetinterface is run, my ethernet connection shows packet losses of around 30-40%, even though I used a static IP address. With DHCP, I get either a system hang or 100% packet loss.

This time, I unplugged the OTHER end of my ethernet cable from my firewall rounter just to be sure that I wasn't affecting the mechanical connection between the ethernet cable and the jack on my microA1. I unplugged it, waited a few seconds, and plugged it back in. Again, just as before, there were two brief flashes from the LED (this time, of course, I was looking at the one on the firewall jack), and then a steady light. When I returned to my microA1 and tried to ping stuff, I now got 0% packet loss, internet connection was fast, everything perfect.

So this is a very reliable workaround for me: just unplug/replug the ethernet cable AFTER the network is running. This appears to reset SOMETHING to a valid state that was not correct before. I have no idea what, but perhaps this information will be useful to those working on the ethernet system. If any further information would be useful, please just ask. I would be happy to reboot my system multiple times, send you debug logs, or whatever.

--Stuart Anderson

@BobW

Test Post:
If you can read this, something is working better!

Wow, my first successful post on Amigans.net from my
Micro-AOne.
I reduced the mtu and mssdflt as suggested.
I hope this continues to work!!

LyleHaze

[edit] explain the meaning of "Test Post:"