Logo107.22.114.194 
  Home  News  Recent  Forums  Search  Contact
  Menu
 Username

 Password


   Register here

 Main menu
   View images
   BBCode test
 
 Content
   Statement of intent
   Terms Of Service
   IRC Channel
   List Content

 In cooperation with
  OS4Depot.net
  OpenAmiga.org
  OS4Welt

 Links
  AmigaOS4
  IntuitionBase
  UtilityBase
  Amiga Flame
  Amiga Spirit
  AmiKit
  Aminet
  AmiBay
  AmigaBounty
  AmigaWorld
  Exec
  Amiga.cz
  View comments
Title  
  Forums
    Software
      AmigaOS 4  
Navigate: 1-20 21-40 41-60 61-68 
TrevRe: IPv620110214 22:19  #2140
@Trev

In my opinion, the best apparatus for capturing all I/O between a SANA-II consumer and a SANA-II device is a filter device:

consumer <-> filter.device <-> sana-ii.device

The filter device must:

1) own and manage the SANA2OPF_MINE and SANA2OPF_PROM flags;
2) override buffer management by translating raw SANA-II device data into the format requested by the consumer;
3) provide monitors (protocol analyzers) with access to queued buffers.

If the filter device opens the SANA-II device with SANA2OPF_MINE and SANA2OPF_PROM, then it should see all incoming packets by issuing S2_READORPHAN requests. All outgoing packets would be captured as I/O requests are received from consumers.

Buffer management can be made simple, e.g. by wrapping the consumer's buffer management routines. The process becomes complex when the filter must understand multiple hardware types. One could write one filter per type, e.g. S2WireType_Ethernet.device or understand multiple types in a single driver. In many cases, pointer arithmetic would suffice for manipulating buffers. It may be possible to reduce the number of copies with some MMU magic.

Access to the filter's queue is relatively simple: Provide functions to add and remove listeners and send them messages as new data arrives. If the queue itself must be filtered, it can be handled by the listener. Queued buffers won't be purged until all listeners have replied to pending messages. If the queue becomes full, new packets won't be queued until space becomes available.
LiveForItRe: IPv620110221 17:16  #2308
@Antique

Ventelo is helping companies to convert to IP6.

Ventelo
LiveForItRe: IPv620110317 23:26  #2960
@Trev

Hi again, anyone know if there is raw package sniffer for MacOS7?
LiveForItRe: IPv620110317 23:35  #2961
@Trev

Current network model

Experimental Loopback device - > Experimental link layer < - Basilisk II

I'm using MacPing to send packages to link layer,
Currently Basilisk II sends ARP packages to link layer, and loopback sends ARP reply

I have not seen the IP/ICMP packages yet, looks like something is lost.

TrevRe: IPv620110318 01:55  #2963
@LiveForIt

I only have OS 9, and I am not sure if I have it installed on my iMac at the moment.

Is ARP implemented inside your virtual loopback device? I am assuming you have also implemented an ICMP echo service, but without knowing how your software works, I cannot say why you are not seeing IP packets.

In English we use packet, not package. :-) If we are referring to the link layer, we use frame.
LiveForItRe: IPv620110318 13:55  #2972
@Trev

Is ARP implemented inside your virtual loopback device?

No it’s a plug in, you see two tiny windows on left side; this is the IP4 protocol and ARP protocol running.

The bottom window is the Basilisk II shell window, you can see first line, is package being sent to “Link layer” for distribution.

You see next line of bytes is package retuning, you see I have modified the package and now it has the FE FD DE AD BE EF MAC address (found in sheep device, masquerading)

The next line is ARP reply coming from the experimental loopack device whit IP 10.0.0.4

The problem here is that “Basilisk II” keeps on asking for mac for 10.0.0.4, it seems it does not accept the package.

I am assuming you have also implemented an ICMP echo service

There is not ICMP echo service yet.
LiveForItRe: IPv620110318 14:22  #2973
@Trev

The window on the right side is the “link layer” responsible for distribution of packages, what it does is it will probe all devices and there supported protocols, to see if the package will be accepted.

The window under on the right is loopback device, some of the text in the window comes for plugins / network protocols.

Instead of using the sana2 Ethernet code for Basilisk II, I use a modified version of Ethernet code from Unix/Linux, I have replaced file descriptions whit Amiga message ports, I use SendMsg() instead of Write() and GetMsg() instead of Read.

Simply because I found the code easier to understand.

On incoming packages an Interrupt in MacOS is triggered forcing a package read operation from the MacOS7 side this event is cached and emulated and this is where packages a read from massage queue, and copied in to empty raw packages and sent back to macos7.

I think this is where problem is, but it will be useful I where able to monitor raw packages on the MacOS side.
LiveForItRe: IPv620110321 02:58  #3046
@Trev

I have fixed the issue, and I'm now getting IP packages.
Navigate: 1-20 21-40 41-60 61-68 
Home
Snack! forum website engine, Created in 2008 by Björn Hagström