Severe bandwidth problem with ASL v4.000

Maybe I missed a crucial point:

If our broadband line only understands 10Mbps half duplex and the network card driver is set to something else or auto-sense, wouldn't the connection fail in the first place?

Someone once told me that when it comes to computers and technology, you can basically say that either something works or it doesn't. Like my school teacher said, "Either something is, or it isn't. There is no 'maybe'."

Boiled down, "Either it works, or it doesn't. It never 'half-works'."... Does this apply here?

Thx  

Hi,
not so simple than many poeple think. If you set the nics on both ends of the line to static settings they both mean "I am right" but if maybe one side thakes 10/half and the other side takes 10/full it will work sometimes but if traffic grows there will be many collisions on the side of 10/half because 10/full thinks than he not has to look for bandwidth for outgoing traffic. So some nic-drivers are much bad and dont do the things you tell them to do so 100BaseT is only a protokoll and not a datarate that a nic must be reach and autonegotiation only tells you that the nics are talking with other nics about half/full or 10/100 or any combination but what they doing with the things they tell eachother is sometimes a mirical.

firebear  

Hi, and thanks for the reply.

So this basically means that if the NIC in the ASL-box and the NIC on the broadband line are set to different configurations, as may be the case here, it will work but there will be many collisions?

I'll try to force the NIC in the ASL-box to 10/half and see what happens. Will post back here with the results.

-------
MrDill    

maybe you wanna check your kernel logs for 'SPOOFING' ...

cheers
/marcel 

Thanks for the reply and suggestion, but there are no entries for "SPOOFING" in the Kernel logs (or any other logs for that matter).

Both packet filter and Kernel logs are around 40-50KB in size. Most packets dropped seem to be broadcasts from the LAN, but there aren't that many of them; max about 10 per minute, and I suppose the ASL is perfectly capable of swallowing that small amount of traffic with no problems.  

BTW, I just verified that the 3C905 NIC -> broadband line is set to 10/half in the NIC's hardware config (3C90XCFG.EXE from DOS) as it is supposed to be. I have not yet specified anything in the /etc/modules.conf yet since I verified the above.

Does this mean that a) the Linux automagically sets the driver or its parameters to that of the NIC's hardware config, 10/half, or b) since no 'options' are specified in the modules.conf the Linux tries to run the NIC/driver at 100/full?  

Fixed! ...Ehrm, well, after ditching ASL v4.000 and going back to v3.216 it works perfectly. Bandwidth is now upwards of 10Mbps, as opposed to about 1Mbps with ASL v4.000.

Did a complete reinstall of ASL v3.216 with manual entry of all configurations, no import of backup file. All configurations are identical to that of v4.000 which I ran an hour ago, so to the best of my knowledge, there are no configuration issues at play here...

Also, I did *NOT* fiddle around with any /etc/modules.conf entries either -- media type on WAN NIC was set to 10/half months ago (using 3C90XCFG.EXE from DOS), and has not been modified since.

Anyone have any idea what may have caused this? I'm lost... And saddened by the fact that I don't dare to implement ASL v4.000 neither here nor at our customers until this issue has been solved.

Anyway, I'll let this ASL-box run for a few days and see what happens. If anything strange pops up, I'll update this thread.

Astaro, I truly hope you find a fix for this one if you can nail it down. Keep up the good work, you've got an amazing product here! [:)]  

Fixed! ...Ehrm, well, after ditching ASL v4.000 and going back to v3.216 it works perfectly. Bandwidth is now upwards of 10Mbps, as opposed to about 1Mbps with ASL v4.000.

Did a complete reinstall of ASL v3.216 with manual entry of all configurations, no import of backup file. All configurations are identical to that of v4.000 which I ran an hour ago, so to the best of my knowledge, there are no configuration issues at play here...

Also, I did *NOT* fiddle around with any /etc/modules.conf entries either -- media type on WAN NIC was set to 10/half months ago (using 3C90XCFG.EXE from DOS), and has not been modified since.

Anyone have any idea what may have caused this? I'm lost... And saddened by the fact that I don't dare to implement ASL v4.000 neither here nor at our customers until this issue has been solved.

Anyway, I'll let this ASL-box run for a few days and see what happens. If anything strange pops up, I'll update this thread.

Astaro, I truly hope you find a fix for this one if you can nail it down. Keep up the good work, you've got an amazing product here! [:)]  

Has no one else experienced this? I have been running a week now with the downgraded ASL (to v3.216) and bandwidth is normal...  

I have had a similar problem.  I have been running 321x for some time now with no problems on a PII 266 with 160Mb ram.  Traffic routing is near instant to the ADSL interface and the DMZ.  The system has 2 dual port Cyclone 3Com cards in it.

I recently built a new machine with PII 350 and 240Mb ram and 2 3Com 905c TX and 1 3com 905c TX-M cards (details below).  The install worked fine and the restore of the config worked great.  I ran the system in test with with a diferent IP for a few days with it all working fine.  Swapped the machines over and change the IP and it was all working fine.  No errors, system load at about 12% memory at 140-160Mb and system running well.  At this point I started to tidy the config a little, but all was still ok.  I then made a few more changes, mainly removing old host entires and rules no longer required when the system slowed right down.  Constant timouts collecting mail on Eth0 connecting to mail server on DMZ1 and slow responce from machines on the Internet accessing via the ADSL interface to machines in the DMZ.  Also very slow access to the internet from Eth0.  I assumed that I had messed up the config, so I restored the original config which restored fine but did not fix the problem.  I restarted the firewall and again this did not fix the problem.  I reverted back to the original system runing 3217 and all is fine again.  Anyone any idea why the system should suddenly start running real slow?

eth0   3Com Corporation3c905 100BaseTX [Boomerang] 
irq=9   mac=00:10:4B:59:A1:9C   type=eth          
  eth1   3Com Corporation3c905C-TX/TX-M [Tornado] 
base=f4000000   irq=11   mac=00:04:76:1C:64:85   type=eth   io=1000      0e.0   
  eth2   3Com Corporation3c905 100BaseTX [Boomerang] 
irq=9   mac=00:04:76:1B:A7:28   type=eth    



Thanks