Amiga.org
Amiga computer related discussion => Amiga Software Issues and Discussion => Topic started by: pneron on December 29, 2016, 01:49:33 PM
-
SPECS:
======
Amiga 2000
OS 3.9 (a new install ---still working my way through the new features!)
TCP/IP Stack & Software
================
Inet 225 - TCP/IP Stack
Aweb 3.3 Browser
Amiganet NIC card - (Hydra Systems) + Hydra.device ver 1.44 (latest network protocol)
==============================================
Dear Amiga SMEs:
I just finished getting OS3.9 installed and having issues connecting to the internet with my old Amiganet NIC card + Inet 225 stack from "InterWorks:
I use to have access to the Web, but at that time I was using dialup PPP connected to my modem directly.
My home network has a bunch of PC's, Macs, etc connected to a Netgear router (gateway 192.1681.1). I can ping my router from my Amiga and I can even login via Amiga's browser AWeb and get access to Netgear's admin control panel. However, I cannot get access to the internet. I suspect I am having gateway routing or hosting issues, but not sure. I have copied the Inet 225 Network initialization file below, along with a "Ping" test from my Amiga to my router and my host file. I did add the Gateway address to one of my init files, but still not convinced if this card support such LAN setup.
Any thoughts on what I can do before I buy a new card ? :confused:
Inet 225 Amiga Outputs
===============
´´ I-Net 225 © 1995,1996 by Interworks ' '
Network startup has begun.
Configuring Hostname: amiga2000
Configuring for User: batman
Adding default gateway route.
add net default: gateway 192.168.1.1
Adding 'shortcut' route to localhost.
add host amiga2000: gateway localhost
Starting INetd.
Starting PortMapper.
Network startup complete.
Running 'INet:s/StartINet-After'...
Ping Test to Netgear Router
=======================
6.MISC{150-DH1}:NetWking/Inet225/Inet/c> ping 192.168.1.1
192.168.1.1 is alive!
6.MISC{150-DH1}:NetWking/Inet225/Inet/c>
Host File:
=========
127.0.0.1 localhost
192.168.1.76 amiga2000
-
You should really look into trying a different TCP/IP stack before you run off buying a new card! For example Roadshow.
It looks to me that you lack default gateway. Do you have a "route" command? Or "netstat"?
-
Thanks Kolla...I do have a route command in my C dir
-
correction, NETSTAT is there but does not see anything beyond anything local. I don't *think* Inet-225 can be configured for a Gateway config across Ethernet but I am no expert and might be wrong. I followed the examples in the doc with no luck.
I am also in the process of upgrading OS3.9 and thought it had a free stack?
-
Well... the "route" command is typically used to set default gateway.
Something along the lines of
route add default gateway 192.168.1.1
You should be able to use netstat to see what is already configured as default gateway:
netstat -rn
-
I am also in the process of upgrading OS3.9 and thought it had a free stack?
Yeah, it comes with Genesis, which in all essence is AmiTCP with a GUI.
-
Genesis is fine, but AFAIR it does not support DHCP (someone feel free to correct me if I'm wrong). Many here will recommend Roadshow, if you can get past its lack of GUI there's a free time-limited (30 minutes) trial available. Maybe give that a try?
Personally I still use MiamiDX, even though it's slower and the author has completely abandoned it, I'm a sucker for its interface. ;)
-
OK, thanks, I will try that tonight and check the dumps
Also, I did see some notes in the documentation that indicated that I-Net 225 can connect using SLIP, CSLIP or PPP (which I use to use during my dialup days) so perhaps it can only support Ethernet connection to LAN?
-
No, it connects just fine to the outside world too if configured correctly. But I would _really_ suggest using something else, such as the much mentioned Roadshow.
-
Thank for the advice Kolla, I am looking at both new stacks right now, one from OS3.9 Genesis and Roadshow.
Still not sure if these will work with my Amiganet (Hydra) NIC card but will try. In the meantime, here are some important docs for reviews:
As shown in docs it looks like the only way I can get access to the internet is via SLIP, CSLIP or PPP configuration.
and the Example they provided is for Ethernet to LAN only?
When I follow this setup (with my Gate pointing to router my 192.168.1.1), I get the following errors:
StartInet with Gateway Added
=========================
´´ I-Net 225 © 1995,1996 by Interworks ªª
Network startup has begun.
Configuring Hostname: amiga2000
Configuring for User: batman
Adding point-to-point route.
ifconfig: ioctl (SIOCSIFDSTADDR): Invalid argument supplied
inet:c/ifconfig failed returncode 10
Network problem: could not configure SANA II device.
Is the device installed properly?
It also looks like it wants to bind a PPP protocol on startup?
I have tried to use a ROUTE file in my db directory and with no luck.
Thus, based on docs, doesn't this indicate no internet access without using SLIP, CSLIP or PPP?
Output Files Below: (no error but no gateway)
StartInet with NoGateway Added
=========================
´´ I-Net 225 © 1995,1996 by Interworks ªª
Network startup has begun.
Configuring Hostname: Configuring for User: Adding default gateway route.
add net default: gateway amiga2000
Adding 'shortcut' route to localhost.
add host amiga2000: gateway localhost
Starting INetd.
Starting PortMapper.
Network startup complete.
OUTPUT FILES WITH GATEWAY OPTIONS
=============================
Init.prefs file
===========
SERVERS
activate "s0" DEFROUTE HOSTNAME amiga2000 IP 192.168.1.76 GATEWAY 192.168.1.1 DEVICE Devs:Networks/hydra.device UNIT 0 IPTYPE 2048 ARPTYPE 2054
StartInet with Gateway Added
=========================
´´ I-Net 225 © 1995,1996 by Interworks ªª
Network startup has begun.
Configuring Hostname: amiga2000
Configuring for User: batman
Adding point-to-point route.
ifconfig: ioctl (SIOCSIFDSTADDR): Invalid argument supplied
inet:c/ifconfig failed returncode 10
Network problem: could not configure SANA II device.
Is the device installed properly?
Hosts File
=========
127.0.0.1 localhost
192.168.1.76 amiga2000
Config File
=========
Hostname amiga2000
User batman
MailDir Inet:Mail
MailEditor Ed
SMTPMailDir INet:Mail/
SMTPSpoolDir INet:MailSpool/
SMTPRmail INet:c/SMTPpost -r
SMTPRoute mx,smtp,smarterhost
NetStat
=======
Routing tables
Destination Gateway Flags Refs Use Interface
127.0.0.1 127.0.0.1 UH 0 0 lo0
192.168.1 192.168.1.76 U 0 0 s0
Routes File
==========
; Add NEtgear Router Info
Inet:c/Route add net 192.168.1.1 >0
-
Well, I used to have AS225 online via ethernet, and Inet-225 is its succeeder, so for sure it works, given that you have the SANA2 device driver for the Hydra.
Adding point-to-point route.
ifconfig: ioctl (SIOCSIFDSTADDR): Invalid argument supplied
inet:c/ifconfig failed returncode 10
Network problem: could not configure SANA II device.
Is the device installed properly?
Well - is it? Do you have Devs:Networks/hydra.device there?
Also...
Inet:c/Route add net 192.168.1.1 >0
... will write output to a file named 0 - is that what you want? Or was your plan maybe >NIL: ?
Anyhow, maybe you would want to see the output till you get things working?
-
yes.....the driver is configured correctly (as per message below):
StartInet with NoGateway Added
=========================
´´ I-Net 225 © 1995,1996 by Interworks ªª
Network startup has begun.
Configuring Hostname: Configuring for User: Adding default gateway route.
add net default: gateway amiga2000
Adding 'shortcut' route to localhost.
add host amiga2000: gateway localhost
Starting INetd.
Starting PortMapper.
Network startup complete.
I only get this message when I try and add the "GATEWAY" option.
As for the ROUTE command, I believe that is the correct syntax for remote gateway switch (">") but will double check the syntax again to make sure
-
I got the impression that you manage to ping 192.168.1.1, so what happens if you try to set the route manually?
-
Nothing if I add it as line in my ROUTE file. I will double check the "syntax" tonight when I get home but here is the GUIDE for the ROUTE (will upload a clean version)
-
Trouble shooting network issues is not my speciality. All comments on having a compatible TCIP/IP stack are totally valid.
But, it does strike me that, if the networked Amiga can look at the router, and even access the admin panel for it over the network, then the network side of it isn't the issue.
I suspect it might be the browser - you can get an update to Aweb from the developers here (it's still very old, but more recent than the one you have).
One big change in the meantime was the shift from IPV4 to IPV6. And that might be where the problem lies.
http://www.amitrix.com/aweb.html
You can get a slightly easier to install, none official version here for 3.X and PPC friendly 4.0 and MorphOS;-
http://www.greyhound-data.com/gunnar/aweb/index.htm?page=downloads
EDIT: Came across this thread. Apparently, you have to add the device (hydra.device) to AmiTCP or it defaults to using the serial port rather than the network card. The line is
eth dev=devs:networks/your.device
From;-
http://eab.abime.net/showthread.php?t=55734
-
Thanks Pete.. the install does force me to link to the Hydra driver and I know it works because I can see the driver in my setup and I can also ping machines and the router....so perhaps you are right with the browser but before I go down that road (as per Kolla's request) - here are some screen dumps after I run the ROUTE from command line:
What happens when I run ROUTE from a shell after I initialize startinet prefs
===================================================
MISC{150-DH1}:NetWking/Inet225/Inet/c> route add amiga2000 192.168.1.1 1---> Integer metric
add host amiga2000: gateway 192.168.1.1 ----> output after I run the command
5.MISC{150-DH1}:NetWking/Inet225/Inet/c> netstat -rn
Routing tables
Destination Gateway Flags Refs Use Interface
127.0.0.1 127.0.0.1 UH 0 97 lo0
192.168.1.76 192.168.1.1 UGH 0 0 s0
192.168.1.76 127.0.0.1 UH 0 1 lo0
default 192.168.1.76 U 0 0 s0
192.168.1 192.168.1.76 U 0 1 s0
ROUTE COMMANDS DOC BELOW (note the Integer Metric switches)
==========================================
Interworks I-Net 225 - TCP/IP Networking Software
Command: route
Location: inet:c/
NAME
route - manually manipulate the routing tables
SYNOPSIS
0m1mroute0m -N=NOSYM/S,-F=FLUSH/S,ROUTES/S,CMD/M
DESCRIPTION
route is used to manipulate the network routing tables manually.
route supports two commands:
1. Add a route.
add [net |host] destination gateway [count]
2. Delete a route.
delete [net |host] destination gateway [count]
The ROUTES switch will cause 0m1mroute0m to read its input from the file
'inet:db/routes'. Each line in that file must be either an 0m1madd0m or
0m1mdelete0m command as shown above, or a comment line (starting with
';' or '#'). Blank lines are ignored. Incorrect lines will be reported to
the console, but the rest of the file will still be processed.
When adding a route, if the route already exists, a message is printed and
nothing changes.
Other command line arguments are:
net or host
specifies the type of destination address. If not specified, routes to a
particular host are distinguished from those to a network by interpreting
the Internet address associated with destination. If the destination has a
"local address part" (last section of 'dotted' address, i.e. if address is
'200.0.0.20', '.20' is the part referenced) of 0, route is assumed to be to
a network; otherwise, it is treated as a route to a host.
destination destination host system where the packets will be
routed. destination can be either a host name (the official name or an
alias), a network name (the official name or an alias, an Internet address
in "dot" notation, or the keyword "default", which signifies the wildcard
gateway route.
gateway The gateway through which the destination is reached.
gateway can be either a host name (the official name or an alias), or an
Internet address in "dot" notation.
count An integer that indicates whether the gateway is a remote
host or the local host. If the route leads to a destination via a remote
gateway, count should be a number greater than 0. If the route leads to
destination and the gateway is the local host, count should be 0. The
default for count is zero. The result is not defined if count is negative.
All symbolic names specified for a destination or gateway are looked up
first as a hostname using gethostbyname(); if the hostname is not found,
the destination is searched as a network name using getnetbyname().
destination and gateway can be in dot notation. If the -n option is not
specified, any host and network addresses are displayed symbolically
according to the name returned by gethostbyaddr() and getnetbyaddr(),
respectively, except for the default network address (printed as default)
and addresses that have unknown names. Addresses with unknown names are
printed in Internet dot notation. If the -n option is specified, any host
and network addresses are printed in Internet dot notation except for the
default network address which is printed as default.
If the -f option is specified, route deletes all route table entries
that specify a remote host for a gateway. If this is used with one of
the commands described above, the entries are deleted before the
command's application.
Output
add destination: gateway gateway flags flags
The specified route is being added to the tables.
delete destination: gateway gateway flags flags
The specified route is being deleted from the tables.
Flags
The following truth table can be used to help understand the relationship
between count, destination type, flags, and route type.
Count Destination Type Flags Route Type
_________________________________________________________
=0 network 1 =U route to a network via a
gateway which is the local host
>0 network 3 =UG route to a network via a
gateway which is a remote host
=0 host 5 =UH route to a host via
a gateway which is
the local host
itself
>0 host 7 =UGH route to a host via a gateway
which is a remote host
=0 "default" 1 =U wildcard route via the local host
>0 "default" 3 =UG wildcard route via a remote gateway
DIAGNOSTICS
error: delete a route that does not exist
meaning: The specified route was not in the route table.
error: add a route that already exists
meaning: The specified entry is already in the route table.
error: add too many routes
meaning: The routing table is full.
AUTHOR
route was developed by the University of California, Berkeley. The ROUTES
switch and other related items were designed and developed by Jim Cooper of
Interworks.
SEE ALSO
netstat
ifconfig
-
...
default 192.168.1.76 U 0 0 s0
...
This is wrong, it should be 192.168.1.1 for gateway as to go to by default to your router to reach a non-local address.
Try (just guessing)
% route add default 192.168.1.1
-
OK, understand. I will make the changes later today and dump netstat -rn outputs to see if there is any issue
-
Also you seem to confuse the string ">0" as an input, with "a value greater than 0", so you end up with a lot of files named "0", containing the output from the command.
Inet:c/Route add net 192.168.1.1 >0
I suggest looking for those files named "0", located in whatever directory you run the command from, and delete them.
count - An integer that indicates whether the gateway is a remote
host or the local host. If the route leads to a destination via a remote
gateway, count should be a number greater than 0. If the route leads to
destination and the gateway is the local host, count should be 0. The
default for count is zero. The result is not defined if count is negative.
See? "count" can not be the string ">0", but it can foor example be the number 3.
As suggested above, the command to set default gw should be:
Inet:c/route add default 192.168.1.1
-
But, it does strike me that, if the networked Amiga can look at the router, and even access the admin panel for it over the network, then the network side of it isn't the issue.
No, your assumption is wrong, it is quite normal to be able to access the router on a LAN even when the route out is not configured, and especially so when NAT is attempted.
With IPv6 things happens much more automatically. For example, my provider in Norway (Canal Digital) provides (if I recall correctly) 3 /64 networks to my router which these days is just an Apple Airport Extreme. The Airport Extreme automatically sets up all the native IPv6 routing, using the 3 networks for 2 wireless networks and one for wire. I configured it from my phone and it works flawlessly out of the box. By setting up a NAT64 router and a bind9 installation with DNS64 enabled, I no longer need IPv4 and NAT on my LAN. For each legacy IPv4-only system (everything Amiga), things get more complicated. I must use 464XLAT, which enables them to connect to IPv4 services on Internet across my IPv6-only network. There is of yet no good generic solution for legacy IPv4-only clients to access IPv6-only services, though for web there are simple proxy options.
-
Thank you for the detail summary Kolla.
Here is the dump of my inet-225 init startup files along with netstat. As you can see from running Inet:c/ command (with the correct integer setting of 1) I get a confirmation message showing my gate added to the route:
add net default: gateway 192.168.1.1
However, I am still unable to access Internet from my browser...thoughts on next step?
5.MISC{150-DH1}:> startinet
I-Net 225 © 1995,1996 by Interworks
Network startup has begun.
Configuring Hostname: amiga2000
Configuring for User: batman
Adding default gateway route.
add net default: gateway amiga2000
Adding 'shortcut' route to localhost.
add host amiga2000: gateway localhost
Starting INetd.
Starting PortMapper.
Starting SMTPd Mailer daemon.
Network startup complete.
Running 'INet:s/StartINet-After'...
add net default: gateway 192.168.1.1
5.MISC{150-DH1}:> netstat -rn
Routing tables
Destination Gateway Flags Refs Use Interface
127.0.0.1 127.0.0.1 UH 0 0 lo0
192.168.1.76 127.0.0.1 UH 0 0 lo0
default 192.168.1.1 UG 0 0 s0
default 192.168.1.76 U 0 0 s0
192.168.1 192.168.1.76 U 0 0 s0
5.MISC{150-DH1}:>
-
Thank you for the detail summary Kolla.
However, I am still unable to access Internet from my browser...thoughts on next step?
I assume you're testing the browser's connection to the internet by entering a site name rather than an IP. I didn't see a mention of DNS earlier in the thread, but you'll need to point the amiga to a DNS server to be able to resolve domain names.
Try pinging an IP on the public internet, such as 8.8.8.8, from the amiga. If that works, then your routing is OK.
Robert
-
Yes,
And I would assume your NAT router also functions as DNS resolver, so setting nameserver to 192.168.1.1 should also work. I don't recall where Inet-225 sets this, but maybe it has a resolv.conf file somewhere? If so, setting "nameserver 192.168.1.1" in it should do the trick.
-
Can I ask a stupid question please?
If I was in this situation, at this stage, I would just change the settings marked 192.168.1.75 or similar to 192.168.1.1 , in the settings area listed in the file marked MISC.
5.MISC{150-DH1}:> netstat -rn
Routing tables
Destination Gateway Flags Refs Use Interface
127.0.0.1 127.0.0.1 UH 0 0 lo0
192.168.1.76 127.0.0.1 UH 0 0 lo0
default 192.168.1.1 UG 0 0 s0
default 192.168.1.76 U 0 0 s0
192.168.1 192.168.1.76 U 0 0 s0
5.MISC{150-DH1}:>
Because 192.168.1.1 is the local IP address for the machine that routes to the outside internet. 127.0.0.1 is the Amigas IP address, from the Amigas point of view.
The issue is, how? That should let the browser use the TCP/IP stack to access the internet, and the web.
The stupid question is, am I on the right lines or completely off the mark? I did say I'm not very good with networks.
-
The only thing that strikes me as a bit odd in that routing output is
192.168.1.76 127.0.0.1 UH 0 0 lo0
-
If I was in this situation, at this stage, I would just change the settings marked 192.168.1.75 or similar to 192.168.1.1 , in the settings area listed in the file marked MISC.
That MISC is not a file, it is just the prompt of his shell, he appears to be standing in a volume called MISC: which corresponds to his DH1: device :)
What you see is the output of the command "netstat -rn" - netcat being a tool to show various.. network status, -r is "route" and "-n" is "do not resolve ip addresses and ports".
Because 192.168.1.1 is the local IP address for the machine that routes to the outside internet. 127.0.0.1 is the Amigas IP address, from the Amigas point of view.
That is correct. And 192.168.1.76 is the address of the amiga.
What the routing table shows seems quite normal:
127.0.0.1 127.0.0.1 UH 0 0 lo0
The localhost IP-address is routet to the loopback interface lo0
192.168.1.76 127.0.0.1 UH 0 0 lo0
This one is odd, I would have expected a
192.168.1.76 192.168.1.76 U 0 0 s0
But - back in the days, the TCP-stacks did a lot of weird things :)
The issue is, how? That should let the browser use the TCP/IP stack to access the internet, and the web.
Sure, but on still need DNS to know what addresses to connect to.
-
is this an entry in my Host file or do I need to setup a DNS server ?
-
Thanks Kolla. I get it now. Something is a little odd with the netstat report, it's just a question of finding the right tool to change it.
is this an entry in my Host file or do I need to setup a DNS server ?
My guess is, you change it in the host file, as indicated by Kolla? You ARE already in the proces of trying to set up a DNS server? :)
-
I would assume your router already handles DNS - but does the software know to get it from there? You could try manually pointing it to something like OpenDNS?
-
Yes my router is pointing to DNS...will look at OpenDNS. thanks
-
Does Inet-225 have a file named resolv.conf?
-
Will check....
-
so far no Kolla...I am going through the docs and examples provided with Inet but do not see such a file?
-
Surely there is some information on where you specify what nameserver to use?
-
will continue to look tonight when I am back home
Thanks
-
Hi Kolla
I can try and ZIP over the the original I-Net 225 sample DOCs (Amiga Guide Format) for your review if you think that will help?
Thanks
Philippe
-
Should be something about it in any of the prefs guides. Look for name server, or resolver, DNS...
-
Thanks...I will check for that...hopefully we are getting closer :)
-
Think I found something.
Amiga Side
On the Amiga side, using Amiga Explorer in TCP/IP mode requires the original bsdsocket.library, or a compatible TCP/IP library. The libraries provided by AmiTCP/IP version 4.x (released in 1994, and which became the reference for Amiga bsdsocket.library functionality) or newer, Miami and WinUAE, for example, work fine. There is a known issue in relation with the TCP/IP stack which was part of the "Enlan-DFS" and "Inet-225" products, which, by design, included limited compatibility with the bsdsocket.library, specifically to support certain programs such as AmiPhone, but not to offer full compatibility with the original library having the same name. Important features used by Amiga Explorer, such as asynchronous socket events, are missing in this library. Under these circumstances Amiga Explorer may issue a "TCP/IP library cannot be opened" message and not function.
From;-
http://www.amigaforever.com/kb/14-109
Known TCP/IP stack problem with the inet-225, apparently. Library is borked to give any sort of functionality with that distro of AmiTCP. Looks like it was more configured for dialup internet direct from an Amiga than network internet connection via remote network gateway.
AmTCP 4.1 or later recommened if you want full functionality. A3.X isn't that hot, apparently. Earlier AmiTCP that is. Other TCP-IP stacks don't have this issue, or just better compatibility with a genuine bsdsocket,library.
-
Looks like it was more configured for dialup internet direct from an Amiga than network internet connection via remote network gateway.
Nothing in what you quote suggest that, and dial-up also requires routing tables, you know.
A little history lesson... once upon a time there was AS225, the official TCP stack from Commodore, which they made to use with the A2060 ARCNET card and the A2065 ethernet card. Not so much dialup. (ARCNET was at the time a standard competing with ethernet) In version 2 of AS225, AS225-r2, the concept of SANA2 was introduced - Standard Amiga Network Architecture 2 - meaning that the TCP stack did not need to support hardware directly, but could use device drivers, such as a2605.device etc. When CBM folded, AS225 was continued as INet-225 by a company called Interworks, to be sold with the Surfer pack provided by Amiga Technologies.
AS225 and INet 225 if I remember correctly uses "socket.library"
AmiTCP, Miami and Roadshow uses "bsdsocket.library"
This difference means that software has to be compiled against either one or the other, and if you look on Aminet, you will find that most software from the 90ies exists in two versions, one for AS225/INet225, and one for AmiTCP (the rest).
I know for a fact that I have used AS225 with A2065 card in A3000.
I know for a fact that I have used INet 225 with ICard PCMCIA ethernet card from IAM on A1200.
I also remember we (university computer club) inquired the university to sponsor a 10 node license for INet 225 at some point, which of course was rejected. :)
In the end, AmiTCP by became the standard, AmiTCP 3.0 beta 2 (http://aminet.net/package/comm/net/AmiTCP-bin-30b2), which was free (and AFAIK the basis of TCP stacks in AROS), and the commercial AmiTCP 4 (http://aminet.net/package/comm/tcp/AmiTCP-demo-40 that often was hacked) by our Finnish friends NSDi, which was later basis for Genesi and others, though with dubious licenses/copyright infringements. AmiTCP made it to version 4.2 (http://us4.aminet.net/aminet/docs/rview/AmiTCP4.2.txt)
Luckily there was also Holger Kruse, who in addition to making quite a few nifty software such as AmiWin (http://aminet.net/package/misc/x11/AmiWin222d) (an X11 implementation that totally rocked after the sources of black&white DaggeX (http://aminet.net/search?query=DaggeX) got lost in one infamous disk crash), made Miami and Miami Deluxe (Miami with support for multiple interface - use your Amiga as a router). He introduced an improved interface standard for Amiga networking hardware, called MNI - Miami Network Interface - which supported "modern things" that SANA2 does not, such as multicast, promiscuous mode (for tcpdump etc) and more. Sadly Miami was such a success that it was hacked and pirated to a point that Holges said bye-bye and left Amiga to persue happiness working with Carl Sassenrath on REBOL.
In addition to TCP/IP, there was also Envoy (http://de4.aminet.net/docs/rview/Envoy.txt), which would the equivalent of netbios or appletalk for Amiga, an "office" type networking protocol for sharing resources like disk and printers on a LAN. Later Envoy (3 and up) supported running along with a, or even on top of, a TCP stack.
Anyways, long story short (hehe), INet-225 should certainly work with ethernet.
AmTCP 4.1 or later recommened if you want full functionality. A3.X isn't that hot, apparently.
The big difference between 3 and 4 is the licensing model, AmiTCP 3 was GPL, 4 was commercial.
-
Ah yes, I recall now that the major reason to run INet 225 was a certain piece of software not available for AmiTCP - namely NFSd - network file server daemon. This was also why we at the computer club asked the university to sponsor it, they were sold as 5 node licenses.
http://allanswers.org/hardware/amiga/networking-faq/part2-2.htm
Not something you would ever want to use over dial up :)
-
Anyways, long story short (hehe), INet-225 should certainly work with ethernet.
The big difference between 3 and 4 is the licensing model, AmiTCP 3 was GPL, 4 was commercial.
Yes, it works with ethernet, but it bugs out at the SANA-II stage, and doesn't work very well with browsers accessing the internet over a remote network gateway, it would seem.
Hence the use of a server daemon to get a result (and I wasn't too sure what was / is available for the Amiga in that respect, I must admit). An Amiga would not be my first choice for a server these days, but I was sure it was theoretically doable.
This is why AmiTCP today comes in a "Pro" version, I suppose. Proper license for bsdsocket.library, not some half ass hacked up library that barfs with proper protocols.
So, either use a different TCP-IP stack that is compatible, or pay up for a license. Or try and get the daemon working with the current setup (last one not what I would do, but...)
http://amigakit.leamancomputing.com/catalog/product_info.php?products_id=1183
-
How to say this... what you are writing makes very little sense to me :)
What do you mean "bugs out at the SANA-II stage", and "doesn't work very well with browsers" - first of all, we are not at a point yet where "browsers" are a thing, we are still just trying to get two basics working - default gateway and DNS.
What is this "server daemon" you speak of?
And no, your understanding of AmiTCP "Pro" and bsdsocket.library, "half ass hacked up library" etc is just bogus, sorry.
EDIT: ok - if there really is a bsdsocket.device in INet 225 (I can not recall that there is), then it most likely is "half ass hacked up". When you are using INet-225, you must in general use programs built for AS225/INet225, and not programs built for AmiTCP.
-
How to say this... what you are writing makes very little sense to me :)
What do you mean "bugs out at the SANA-II stage", and "doesn't work very well with browsers" - first of all, we are not at a point yet where "browsers" are a thing, we are still just trying to get two basics working - default gateway and DNS.
What is this "server daemon" you speak of?
What you just posted about - nfsd.
Ah yes, I recall now that the major reason to run INet 225 was a certain piece of software not available for AmiTCP - namely NFSd - network file server daemon. This was also why we at the computer club asked the university to sponsor it,...
EDIT: ok - if there really is a bsdsocket.device in INet 225 (I can not recall that there is), then it most likely is "half ass hacked up". When you are using INet-225, you must in general use programs built for AS225/INet225, and not programs built for AmiTCP.
Aha, realization has dawned. AS225 is a working distro, in the sense of uncompromised, but isn't really guaranteed working with different network cards. Inet225 is a distinctly dodgy distro, from a network compatibility and remote gateway point of view. AmiTCP Pro is a real solution, but it's not the only possible solution and a bit of slog to get going.
What was that Roadthingy new release? Roadshow, sounds cheaper and more functional than AmiTCP Pro. And your original answer, so I guess we've just gone round in a big circle to come back to your first response. :)
-
What you just posted about - nfsd.
It was just a piece of software that wasn't available for AmiTCP, it came with the commercially available INet 225 - not that any _sane_ person would want to run NFS server on Amiga, for "inter-amiga" filesystems there was netfs, and for NFS client on Amiga there was ch_nfs. Later came Samba and SMBFS which Olsen still maintains today.
Aha, penny dropped. AS225 is a working distro, in the sense of uncompromised, but isn't really guaranteed working with different network cards.
Well, yes, but AS225r2 supports SANA-II, and works well with a whole range of cards, as well as you can expect a TCP stack from that time to work.
Inet225 is a distinctly dodgy distro, from a network compatibility and remote gateway point of view.
What? What are you basing this assumption on??
AmiTCP Pro is a real solution, but it's not the only possible solution and a bit of slog to get going.
There is and never was anything called "AmiTCP Pro", the name was "AmiTCP/IP v4.x" where "x" was a number between 0 and 2, and it was commercial after the guys who were working on AmiTCP, the so called "AmiTCP Group", mostly some guys from Finland, decided the work they put into it was too much to do it for free - it was a big hoopla at the time, going from GPL to commercial closed source, was considered... treason, by many. In the process I think bsdsocket.library also was updated to support more BSD 4.2 functionality.
What was that Roadthingy new release? Roadshow, sounds cheaper and more functional than AmiTCP Pro. And your original answer, so I guess we've just gone round in a big circle to come back to your first response. :)
Yeah. RoadShow 1.2 is supported and updated to this day, by the guy you see here posting under the name "olsen", who is a living legend in our community, and probably one of the nicest guys you will ever encounter here :) It is the TCP stack of OS4.1 as well.
For someone who appears to be living under a rock, you for sure produce a lot of text :laughing:
-
There is and never was anything called "AmiTCP Pro"
Clicky linky. That shows a product called AmiTCP pro. It has working functionality. Unlike Inet225. I appreciate it costs money. So does Roadshow. Roadshow is cheaper than AmiTCP Pro. Most people purchase on cost when functionality is not an issue.
Yeah. RoadShow 1.2 is supported and updated to this day, by the guy you see here posting under the name "olsen", who is a living legend in our community, and probably one of the nicest guys you will ever encounter here :) It is the TCP stack of OS4.1 as well.
For someone who appears to be living under a rock, you for sure produce a lot of text
Not as much text as an infinite number of monkeys, and one idea is, once you have identified a known issue, it is added to a pooled resource, and people can search for it.
Strikes me this forum depends on people being able to use Google, do all their own fault finding, never ask questions, and never, ever, use the Search button. Any Amiga issues, you're on your own to find the solution. Or at least, encouraged to find your own solution.
Looks like the OP was sent on a wild good chase. Ho hum. Nobodies fault really, and it's not like the thread was left hanging with zero attempt at helping.
Too many cooks maybe.
-
Clicky linky. That shows a product called AmiTCP pro.
You mean EasyNet Pro?
It is one of those "spin-offs" of AmiTCP, pretty much a GUI for AmiTCP v4.x
It has working functionality. Unlike Inet225.
You seem to live under the false assumption that INet 225 does not work - newsflash: it works! Even on ethernet it works! I have used it! Have you? There is a lot of software for it too, that software also works. Amazing feces!!
Roadshow is cheaper than AmiTCP Pro.
Again I suspect you confuse with EasyNet Pro.
Most people purchase on cost when functionality is not an issue.
I bought Roadshow on a whim because I was trying to help someone out and got tired of the time-outs of the demo. As it turns out, the PPP implementation was much better than anything else, so I have kept using it on the systems where I use null-modem for connectivity (which is the MIST with serial link to pi zero, and the cd32/SX32 Pro with bluetooth null-modem against a Minimac G4 running Linux). I also have it installed on one A600 and an A1200 I believe.
Not as much text as an infinite number of monkeys, and one idea is, once you have identified a known issue, it is added to a pooled resource, and people can search for it.
Provided that the information given is correct!
Strikes me this forum depends on people being able to use Google, do all their own fault finding, never ask questions, and never, ever, use the Search button. Any Amiga issues, you're on your own to find the solution. Or at least, encouraged to find your own solution.
Looks like the OP was sent on a wild good chase. Ho hum. Nobodies fault really, and it's not like the thread was left hanging with zero attempt at helping.
Too many cooks maybe.
No wild goose chase - with the system described he should be perfectly able to connect to the Internet using his ethernet card. Despite everything you have written :p
-
You seem to live under the false assumption that INet 225 does not work - newsflash: it works! Even on ethernet it works! I have used it! Have you? There is a lot of software for it too, that software also works. Amazing feces!!
Hey Pneron, you got this POS Inet 225 working or have you thrown it in the trash already?
Aminet sucks, because everybody hands out the POS free version. Come to that, Easynet sucks. For the same reason.
Does anybody else see a pattern here? No? Well, I'll give up. Hand over to the "experts" who "know what they're doing".
:laughing::laughing::laughing::laughing::laughing::laughing::laughing::laughing::laughing:
-
Aminet sucks, because everybody hands out the POS free version.
What on earth is that supposed to mean?
-
Thanks...I will check for that...hopefully we are getting closer :)
The guide you should be looking in, is perhaps the one for configinet :)
Is Domain Name Resolution available with the AS225 software?
...
For As225r2: Yes. All variants support DNS, and gateway. These functions are turned off and on via the config files and the ConfigINet utility.
http://www.faqs.org/faqs/amiga/networking-faq/part1/
-
***still working on this*** guys . Thanks for some direction/guidance.
My hope is that I will have some new updates later this weekend once I review the docs and links
-
EDIT: ok - if there really is a bsdsocket.device in INet 225 (I can not recall that there is), then it most likely is "half ass hacked up". When you are using INet-225, you must in general use programs built for AS225/INet225, and not programs built for AmiTCP.
Yep - usually 225 would provide it's functionality via "socket.library". There was a "bsdsocket.library" wrapper for that to enable "socket.library" unaware software like YAM 1.x. I used that a lot and it usually worked out of the box. I remember I had to hex edit this or that binary ('cos they did a version test on bsdsocket or the like...), but in general it worked.
-
From the guides, how to use and set up DNS resolvers - should be selv explanitary?
(http://www.amiga.org/forums/picture.php?albumid=204&pictureid=1389)
(http://www.amiga.org/forums/picture.php?albumid=204&pictureid=1390)
(http://www.amiga.org/forums/picture.php?albumid=204&pictureid=1391)
It is really no different than any other TCP stack for Amiga in this regard.
-
Thanks Kolla, I got it now, I think. Some Amiga TCP stacks use static addressing only, so they need to be told where to look for addresses "outside" the local network, like the internet.
Otherwise they just dumbly use the same default settings for accessing IP addresses off of the local network that the default settings use. You HAVE to tell them where to look such places up, one way or the other. Otherwise they just won't work as you expect.
Am I right? Or at least on the right lines here? This is where Roadshow clicks with people, because it prompts for the person setting up, about setting where the TCP stack needs to be set to lookup addresses, I guess. Manually configuring it will work with ANY AmiTCP stack, but if you assume dynamic addressing, you are in a world of pain with some Amiga TCP/IP distributions. Age is no guarantee of fitness for purpose for noob network engineers like me. Even if the do have a GUI, most solutions don't guide you and prompt you to put in the right answers in the right places. They just assume you know about networks enough to give the TCP stack the right network routing to navigate to places, on local networks, or remote networks.
-
Thank Kolla...I will give this shot, appreciate the screen shots
-
still working on this issue Kolla - thanks
-
thank you for the screen shots Kolla
-
You are welcome, interesting if it works out :)
And if not, I recommend the Roadshow stack.
-
You are welcome, interesting if it works out :)
And if not, I recommend the Roadshow stack.
Wow, there's a whole heap of confusion here. I'm not familiar with INet but you seemed to have almost a working config from the outset. You could ping local machines and the router. You just need to make sure the default route/gateway is pointing at your router (192.168.1.1) and also confirm you're pointing at the correct DNS server (also likely 192.168.1.1).
If you try to 'ping google.com' from the CLI, this will test if name resolution is working. It will also confirm if you're using the correct gateway. If that fails 'unknown host' then DNS is not configured properly, if it resolves the name to IP but the ping fails then it's likely an incorrect default route.
Steve
p.s. As others have mentioned AmiTCP, I wrote an install guide here: http://blog.netting.org.uk/2015/07/19/amitcp-and-configuration-of-cnet-device/
-
Yeah, from reading the INet manuals, I can tell that it is a little bit of an oddball compared to what we are used to these days, it is really like using a _very_ old BSD :)