[SqNOS] Networking is comming to a theater close to you!

[Gerardo Richarte]

Johnathon Meichtry wrote:
> Gera,
>
> I forgot to answer your question before.  I was pinging 192.170.247.1
> so it's kind of odd that the first 6 bytes were showing up as being
> destined for MAC 255:255:255:255:255:255 (decimal).  I actually
> rebooted and re-init'd the Lance Device three times to make sure I was
> getting consistent results.  So anyway at this point I don't know why
> the destination MAC would be FF:FF:FF:FF:FF:FF but them I suppose that
> if the ARP table didn't have the MAC matched against an IP (i.e. what
> I was pinging) it would need to send it off to an unknown destination
> hoping that someone would respond or the gateway would route it on.
>
    So, then, I guess you are doing all this on Windows (I know you use
linux)? or may be you have samba installed on your linux?
    the FF:FF:FF:FF:FF:FF means destination mac address broadcast,
however, there's very few IP traffic with destination broadcast. A few
UDP packets have bcast as dest. no TCP traffic has bcast, I saw some
ICMP (ping) traffic with bcast, but only when pinging a bcast IP address.
    In your case it's something else that you are getting, not the ping.
Specially because you are pingin 192.170.247.1 and that is the address
of your real box, so pinging it will not produce any traffic on the
interface (should not produce traffic).
    Can I get (probably prvate) a screenshot of all the bytes of the
message? (with my just committed changes do Computer current
defaultNetworkInterface initializationBlock receiveRing message
asByteArray, and get a screenshot of the result (also print the
messageSize). I will tell you what the packet is.
> What's also interesting is that for the packet type i.e. bytes 13/14
> they are two distinct bytes as the decimal equiv. of 0x800 is of
> course 2048 yet in the buffer we see 08 in byte 13 and 00 in byte 14
> with both values being in decimal therefor a combined decimal value of
> only 800 .
    Sure, that's correct. When you read 2 bytes as a single number you
put the values one after the other, no matter what the base is... erm...
well... something like that. Don't worry about that too much, most of
the classes to handle the packets should be ready and only need to be
plugged into SqueakNOS.
> BTW, I now have a fully-loaded image with Whisker Browser, Shout,
> eCompletion, Services and a few other goodies all working well under
> SqueakNOS.
    That's super. Was it a lot more than filing in from Monticello?
> Although I shouldn't really be playing around, rather I should be
> looking into Intel CPU Speedstep control/ACPI as my laptop CPU sits at
> 100% utilisation whenever the VM is running.
    that's my fault, and I've known it for some time, but never stopped
to fix it, although I think that I know how to do it now. I will try
increasing the timer period, I first thought to 1KHz, but then saw that
linux uses 100Hz... I think we really need the 1KHz thing, but I'll try
it anyway. So, increasing the frequency and then changing
ioReliquishProcessorFor... should be changed to do 'hlt'.
    I have to try this, this should bring the load down abruptly.

     gera