Hello.
The problem is still unsolved, I have some ideas and clues but I had not enough time for investigation lately.
If this can be of any help, have a look at my program NetSpeedometer, source code and binary available from OS4 Depot.
We keep in touch, regards.
Thanks for your reply.
I looked at your code but for my VIA-RHINE on a Peg2, it's the same results = 0.0.0.0... :(
I'm trying too to list the active socket,
I found in the AmiTCP sources that a struct in_pcb was used to go trough the sockets data areas but no reference in the OS4 SDK for include netinet/in_pcb.h:(
Maybe that the GetNetworkStatistics(NETSTATUS_tcp_sockets) can do the job but how to navigate in the socket list with it ?
Nevertheless, your netspeedometer is a nice tool :)
I write a little tool too, could you test it if I send you my mail adress by PM ?
As far as I know there is no specific gateway address associated with an interface. The route a packet travels is selected according to its destination address, and the interfaces play a part in this, but they are not the deciding factor.
As far as I know, there are three types of routing entries. There's the route to a host, the route to a network and the default route. Each type uses a gateway, which the packets have to pass through in order to reach the destination. For the route to a host the destination is given as an IP address corresponding to the host address. For the route to a network, the destination is given as an IP address with a network mask. For the default gateway the destination is 0.0.0.0 which is a wildcard meaning "anything goes here which can't find a different specific route".
The gateways used by routes can correspond to interface addresses, or they may be addresses of hosts or networks which themselves are subject to routes you set up. It's perfectly possible to set up a route to a specific network which is reachable only through the default gateway.
If interfaces are involved in routing as gateways, and no specific routes other than the default gateway are set up, the TCP/IP kernel's routing will match the packet's destination address against the respective interface addresses. If, for example, the network address and mask of an Ethernet interface matches the destination address, the kernel will assume that the packet may be delivered to a host connected via that Ethernet interface. In order to find that host, it might first fire off an ARP request to figure out which host the packet should be dispatched to, and once that information is available, the packet will be sent off. If a point-to-point interface such as PPP or SLIP is involved, the TCP/IP kernel will check if the interface's peer address corresponds to the destination address of the packet, and if it matches, will push the packet through to the other side.
I hope I didn't forget anything. This is basically the process by which the TCP/IP kernel figures out which gateway should be used when sending a packet, based upon its destination address. As you can see, the association (if any) between interface and gateway is made dynamically when needed and is not static. Which means that you cannot match up interface addresses with gateways: you also need to consider the packet destination address to make this association meaningful.
As Olaf says, he just hope that he didn't confuse the details, and what he wrote above may not be the whole picture, but he believe it is about correct as far as the inner workings of the BSD TCP/IP kernel are concerned.
It's not so obscure; it's basic IP routing. NutsAboutAmiga's answer at Amigaworld.net was the correct one. The default gateway is the gateway associated with the default route, 0.0.0.0. The default route can be associated with any interface in the system. Static routes can be associated with other gateways, and those gateways can be associated with any interface in the system.
Olaf confirmed this and essentially suggested using the routing socket interface to investigate routes. The routing socket interface is platform agnostic. Your code should work with few modifications on most operating systems.
If you don't already have them, the TCP/IP Illustrated series of books are the collective TCP/IP bible. Volumes 1 and 2 are essential. I believe Olaf used Volume 2 as a guide when implementing Roadshow.
Note that Volume 1 was recently updated to include modern examples using Linux. While this is beneficial to a younger audience, the previous edition provides a more comprehensive historical overview and an objective comparative analysis of various IP stacks. On the downside, the stacks referenced by the first edition are mostly obsolete. Still, I prefer the unbiased review.
Thanks Kas1e to post this answer and Trev for the reference books (found not expensive on abebooks).
I take the opportunity to ask if somebody know where is the include who describes the inpcb structure ?
In the Morphos SDK I can find the netinet/in_pcb.h include but no in_pcb.h in the OS4 SDK.
It seems that just this file is missing comparing MOS & AOS netinet include directories.
I would like to try to pass through all the sockets of the tcpip stack.
I don't know why this is getting so complicated and ending up no where. I also followed this discussion on AmigaWorld.net. Regardless of the technicalities involved the fact remains that ShowNetStatus can do what is required here. It lists a Default gateway address and on my setup it certainly is NOT 0.0.0.0!
Here:
7.Workbench:C> ShowNetStatus
Network status summary
Local host address = 192.168.0.2 (on interface 'ETH3COM')
Default gateway address = 192.168.0.1
Domain name system servers = 192.168.0.1, 192.168.0.1
Now, what the heck is it doing? That can do it and while it may not be linked directly with the main interface it has no problem displaying it. Perhaps Roadshow also should have included a way to grab this Default gateway address from its API which includes other query functions for ease of use.
I guess if you get depserate here then load up a debug kernel, making sure debug level is low before it boots up, to avoid noise. Then, just before you run ShowNetStatus in a shell ramp the debug level up, and run it! Save the debug buffer and then you should have a list of functions used to grab that damned Default gateway address which so far has eluded us. As it stands this is just getting ridiculous! :-o
There is no API in the Roadshow bsdsocket.library which grants direct access to the current routing information. The reason why is because of the data structure layout, which is somewhat messy and actually requires separate processing of each entry read from the routing table.
The code in ShowNetStatus which works out the routing information came straight out of the 4.4BSD "route" command. As far as I know, there is no really straightforward way to do it.
Do you have access to the PPP dialer/connector source code? This should have been in the SDK. Same thing about the ShowNetStatus command: source code should have been in the SDK.
Thanks for reviving this talk!
Unfortunately the source to ShowNetStatus is not in SDK 53.20 (the latest and the only one I have) while "ppp_dialer.c" is in it and it is exactly what I have been investigating since a while ago.
It feels like I am on the right path to the solution.
Finally I got my code to retrieve the "default gateway address" to work. As mentioned before, it is based on "ppp_dialer.c" from SDK 53.20. I found this matter totally undocumented and thus rather obscure.
As a result a new release of my tool NetSpeedometer is to come, so stay tuned ;)
Investigation ongoing.
Is it the IFQ_DestinationAddress tag of ISocket->QueryInterfaceTags() ?
I wonder if the GetRouteInfo() function and RTF_GATEWAY flag will do what you want?
But you could be on the right track. Perhaps if you don't find out email Olaf himself. :-)
OK investigation is in progress.
Do you know how to contact him?
Yes. He's on AmigaWorld.net.
Hi Massi,
I have the same problem to find my gateway address.
I am able to find my IP address with QueryInterfaceTags
but for the gateway, for Primary DNS & Secondary DNS, I just have 0.0.0.0.
Do you succeed to resolve your gateway adress problem ?
Thanks by advance for your reply
zzd10h
Hello.
The problem is still unsolved, I have some ideas and clues but I had not enough time for investigation lately.
If this can be of any help, have a look at my program NetSpeedometer, source code and binary available from OS4 Depot.
We keep in touch, regards.
Thanks for your reply.
I looked at your code but for my VIA-RHINE on a Peg2, it's the same results = 0.0.0.0... :(
I'm trying too to list the active socket,
I found in the AmiTCP sources that a struct in_pcb was used to go trough the sockets data areas but no reference in the OS4 SDK for include netinet/in_pcb.h:(
Maybe that the GetNetworkStatistics(NETSTATUS_tcp_sockets) can do the job but how to navigate in the socket list with it ?
Nevertheless, your netspeedometer is a nice tool :)
I write a little tool too, could you test it if I send you my mail adress by PM ?
It seems like a rather obscure subject, anyway have a look also at the related discussion on AmigaWorld.net "Gateway of a network interface".
You are welcome to contact me, you can find my email address in the NetSpeedometer package.
I will reply as soon as I can.
Regards
As far as I know there is no specific gateway address associated with an interface. The route a packet travels is selected according to its destination address, and the interfaces play a part in this, but they are not the deciding factor.
As far as I know, there are three types of routing entries. There's the route to a host, the route to a network and the default route. Each type uses a gateway, which the packets have to pass through in order to reach the destination. For the route to a host the destination is given as an IP address corresponding to the host address. For the route to a network, the destination is given as an IP address with a network mask. For the default gateway the destination is 0.0.0.0 which is a wildcard meaning "anything goes here which can't find a different specific route".
The gateways used by routes can correspond to interface addresses, or they may be addresses of hosts or networks which themselves are subject to routes you set up. It's perfectly possible to set up a route to a specific network which is reachable only through the default gateway.
If interfaces are involved in routing as gateways, and no specific routes other than the default gateway are set up, the TCP/IP kernel's routing will match the packet's destination address against the respective interface addresses. If, for example, the network address and mask of an Ethernet interface matches the destination address, the kernel will assume that the packet may be delivered to a host connected via that Ethernet interface. In order to find that host, it might first fire off an ARP request to figure out which host the packet should be dispatched to, and once that information is available, the packet will be sent off. If a point-to-point interface such as PPP or SLIP is involved, the TCP/IP kernel will check if the interface's peer address corresponds to the destination address of the packet, and if it matches, will push the packet through to the other side.
I hope I didn't forget anything. This is basically the process by which the TCP/IP kernel figures out which gateway should be used when sending a packet, based upon its destination address. As you can see, the association (if any) between interface and gateway is made dynamically when needed and is not static. Which means that you cannot match up interface addresses with gateways: you also need to consider the packet destination address to make this association meaningful.
As Olaf says, he just hope that he didn't confuse the details, and what he wrote above may not be the whole picture, but he believe it is about correct as far as the inner workings of the BSD TCP/IP kernel are concerned.
It's not so obscure; it's basic IP routing. NutsAboutAmiga's answer at Amigaworld.net was the correct one. The default gateway is the gateway associated with the default route, 0.0.0.0. The default route can be associated with any interface in the system. Static routes can be associated with other gateways, and those gateways can be associated with any interface in the system.
Olaf confirmed this and essentially suggested using the routing socket interface to investigate routes. The routing socket interface is platform agnostic. Your code should work with few modifications on most operating systems.
If you don't already have them, the TCP/IP Illustrated series of books are the collective TCP/IP bible. Volumes 1 and 2 are essential. I believe Olaf used Volume 2 as a guide when implementing Roadshow.
Note that Volume 1 was recently updated to include modern examples using Linux. While this is beneficial to a younger audience, the previous edition provides a more comprehensive historical overview and an objective comparative analysis of various IP stacks. On the downside, the stacks referenced by the first edition are mostly obsolete. Still, I prefer the unbiased review.
Thanks Kas1e to post this answer and Trev for the reference books (found not expensive on abebooks).
I take the opportunity to ask if somebody know where is the include who describes the inpcb structure ?
In the Morphos SDK I can find the netinet/in_pcb.h include but no in_pcb.h in the OS4 SDK.
It seems that just this file is missing comparing MOS & AOS netinet include directories.
I would like to try to pass through all the sockets of the tcpip stack.
Thanks
The most recent edition of UNIX Network Programming Volume 1 is also a standard reference.
I don't know why this is getting so complicated and ending up no where. I also followed this discussion on AmigaWorld.net. Regardless of the technicalities involved the fact remains that ShowNetStatus can do what is required here. It lists a Default gateway address and on my setup it certainly is NOT 0.0.0.0!
Here:
7.Workbench:C> ShowNetStatus
Network status summary
Local host address = 192.168.0.2 (on interface 'ETH3COM')
Default gateway address = 192.168.0.1
Domain name system servers = 192.168.0.1, 192.168.0.1
Now, what the heck is it doing? That can do it and while it may not be linked directly with the main interface it has no problem displaying it. Perhaps Roadshow also should have included a way to grab this Default gateway address from its API which includes other query functions for ease of use.
I guess if you get depserate here then load up a debug kernel, making sure debug level is low before it boots up, to avoid noise. Then, just before you run ShowNetStatus in a shell ramp the debug level up, and run it! Save the debug buffer and then you should have a list of functions used to grab that damned Default gateway address which so far has eluded us. As it stands this is just getting ridiculous! :-o
There is no API in the Roadshow bsdsocket.library which grants direct access to the current routing information. The reason why is because of the data structure layout, which is somewhat messy and actually requires separate processing of each entry read from the routing table.
The code in ShowNetStatus which works out the routing information came straight out of the 4.4BSD "route" command. As far as I know, there is no really straightforward way to do it.
Do you have access to the PPP dialer/connector source code? This should have been in the SDK. Same thing about the ShowNetStatus command: source code should have been in the SDK.
Thanks for reviving this talk!
Unfortunately the source to ShowNetStatus is not in SDK 53.20 (the latest and the only one I have) while "ppp_dialer.c" is in it and it is exactly what I have been investigating since a while ago.
It feels like I am on the right path to the solution.
Take a look at the FreeBSD route command's "get" logic in route.c:
http://www.freebsd.org/cgi/cvsweb.cgi/src/sbin/route/#dirlist
Now solved!
Thanks to all contributions.
Awesome! So what was the answer? :-)
Finally I got my code to retrieve the "default gateway address" to work. As mentioned before, it is based on "ppp_dialer.c" from SDK 53.20. I found this matter totally undocumented and thus rather obscure.
As a result a new release of my tool NetSpeedometer is to come, so stay tuned ;)
Hmmm. It's a well-documented part of the BSD stack upon which Roadshow is based. Glad you found what you needed, though!