|Navigate: 1-20 21-40 41-60 61-68 |
|Trev||Re: IPv6||20110214 22:19 #2140|
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.
|LiveForIt||Re: IPv6||20110317 23:26 #2960|
Hi again, anyone know if there is raw package sniffer for MacOS7?
|LiveForIt||Re: IPv6||20110317 23:35 #2961|
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.
|Trev||Re: IPv6||20110318 01:55 #2963|
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.
|LiveForIt||Re: IPv6||20110318 13:55 #2972|
|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.
|LiveForIt||Re: IPv6||20110318 14:22 #2973|
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.
Navigate: 1-20 21-40 41-60 61-68
|LiveForIt||Re: IPv6||20110321 02:58 #3046|
I have fixed the issue, and I'm now getting IP packages.