OSDev.org

The Place to Start for Operating System Developers
It is currently Thu Mar 28, 2024 8:04 am

All times are UTC - 6 hours




Post new topic Reply to topic  [ 48 posts ]  Go to page 1, 2, 3, 4  Next
Author Message
 Post subject: Packets not arriving
PostPosted: Sat Apr 14, 2007 9:05 pm 
Offline
Member
Member

Joined: Sun Jan 14, 2007 9:15 pm
Posts: 2566
Location: Sydney, Australia (I come from a land down under!)
I've finally been able to send IP packets from my OS without any problems. The sniffer I have setup detects them coming out.

The problem is, Windows still doesn't recognize them. Pinging my OS still times out, even though it is clear that the packet makes it to my PC.

Any ideas?

_________________
Pedigree | GitHub | Twitter | LinkedIn


Top
 Profile  
 
 Post subject:
PostPosted: Sat Apr 14, 2007 9:11 pm 
Offline
Member
Member
User avatar

Joined: Thu Mar 08, 2007 11:08 am
Posts: 670
Can you receive packets without promiscuous mode now?

_________________
The real problem with goto is not with the control transfer, but with environments. Properly tail-recursive closures get both right.


Top
 Profile  
 
 Post subject:
PostPosted: Sat Apr 14, 2007 9:19 pm 
Offline
Member
Member

Joined: Sun Jan 14, 2007 9:15 pm
Posts: 2566
Location: Sydney, Australia (I come from a land down under!)
No... I still receive packets with promiscuous mode on. Without it it doesn't work.

I have forgotten the offsets from the io address of PAR0-PAR5 (which makes my life very difficult).

Edit: Code to get the physical address:
Code:
   // useful variables
   int wordlen = 2;
   int i;
   uint8_t buffer[32];
   
   outportb(data->ioAddress + REMOTEBYTECOUNT0, 0x20);
   outportb(data->ioAddress + REMOTEBYTECOUNT1, 0x00);

   outportb(data->ioAddress + REMOTESTARTADDRESS0, 0x00);
   outportb(data->ioAddress + REMOTESTARTADDRESS1, 0x00);

   outportb(data->ioAddress + COMMAND, E8390_START | E8390_NODMA | E8390_PAGE0);

   for(i=0; i<32; i+=2)
   {
      buffer[i] = inportb(data->ioAddress + IOPORT);
      buffer[i+1] = inportb(data->ioAddress + IOPORT);

      if(buffer[i] != buffer[i+1])
         wordlen = 1;
   }

   if(wordlen == 2)
   {
      data->wordMode = 1;
      for(i=0; i<16; i++)
         data->saprom[i] = buffer[i*2];
      
      outportb(data->ioAddress + DATACONFIGURATION, 0x48 );
      return;
   }
   else
   {
      data->wordMode = 0;
   }


Without promiscuous mode, it just plain doesn't work...

_________________
Pedigree | GitHub | Twitter | LinkedIn


Top
 Profile  
 
 Post subject:
PostPosted: Sat Apr 14, 2007 9:34 pm 
Offline
Member
Member
User avatar

Joined: Thu Mar 08, 2007 11:08 am
Posts: 670
Our Wiki links to http://www.national.com/pf/DP/DP8390D.html for data.

Maybe it helps. ;)

Anyway, my theory is that you either have the MAC wrong, or you are sending it in wrong order (either in network packets, or in ARP packets).

_________________
The real problem with goto is not with the control transfer, but with environments. Properly tail-recursive closures get both right.


Top
 Profile  
 
 Post subject:
PostPosted: Sat Apr 14, 2007 9:35 pm 
Offline
Member
Member

Joined: Sun Jan 14, 2007 9:15 pm
Posts: 2566
Location: Sydney, Australia (I come from a land down under!)
Which order should it be?

ARP packets work, the handler just swaps the destination and source address fields.

Edit: the OS gets the correct MAC and sends it correctly (I looked at the ARP cache).

_________________
Pedigree | GitHub | Twitter | LinkedIn


Last edited by pcmattman on Sat Apr 14, 2007 9:46 pm, edited 1 time in total.

Top
 Profile  
 
 Post subject:
PostPosted: Sat Apr 14, 2007 9:45 pm 
Offline
Member
Member
User avatar

Joined: Thu Mar 08, 2007 11:08 am
Posts: 670
Can you make me a new testing image? I wanna try if I manage to get some packets out of it and see if they look ok..

_________________
The real problem with goto is not with the control transfer, but with environments. Properly tail-recursive closures get both right.


Top
 Profile  
 
 Post subject:
PostPosted: Sat Apr 14, 2007 9:49 pm 
Offline
Member
Member

Joined: Sun Jan 14, 2007 9:15 pm
Posts: 2566
Location: Sydney, Australia (I come from a land down under!)
Packets sent are OK... ATM it's receiving them. Disabling promiscuous mode basically stopped my OS from receiving any packets, apart from ARP requests because they are a broadcast.

How exactly am I meant to get a MAC address out of the PAR0-PAR5 registers? I tried it but it didn't work (I got 0:0:0:0:0:0).

Edit: I'd prefer to fix the receive problem first, then when I get around to sending data I can send you an image.

I believe that the problem is with my MAC address that I have retrieved - when Windows receives the ICMP packet and finds that it's come from the wrong address it gets confused.

Edit 2: This is the ethernet layer of sending, which isn't used for ARP packets:
Code:
int sendPacketEthernet(struct ethernet_t *eth, packet_t *p)
{
   struct ethHeader_t *ethPkt;
   packet_t *pkt;
   
   pkt = packetAddHeader(sizeof(struct ethHeader_t), p);
   if(!pkt || !pkt->data)
   {
      return 0;
   }
   
   // the real length
   int packlen = pkt->len;
   
   ethPkt = (struct ethHeader_t *)pkt->data;
   int i = 0;
   /** at the moment the destination is hard-coded, so we don't have to keep an ARP cache **/
   ethPkt->dest[i++] = 0x00;
   ethPkt->dest[i++] = 0x0F;
   ethPkt->dest[i++] = 0xEA;
   ethPkt->dest[i++] = 0xA0;
   ethPkt->dest[i++] = 0x15;
   ethPkt->dest[i] = 0xAF;
   memcpy(ethPkt->src, eth->macAddr, 6);
   ethPkt->type = htons(ETHER_FRAME_IP);
      
   // send the packet
   eth->send(eth, pkt);

   return 1;   
}


It could be a problem here that causes the problem.

_________________
Pedigree | GitHub | Twitter | LinkedIn


Last edited by pcmattman on Sat Apr 14, 2007 9:59 pm, edited 1 time in total.

Top
 Profile  
 
 Post subject:
PostPosted: Sat Apr 14, 2007 9:58 pm 
Offline
Member
Member
User avatar

Joined: Thu Mar 08, 2007 11:08 am
Posts: 670
Hehe, I know exactly as much as the datasheets say. I've never tried to program a ne2k driver (that's on TODO list ofcourse, but I've not started with that yet) so no idea.. well other than what the datasheets tell... which I don't feel like reading right now...

But I still offer to try to sniff packets sent by your current driver, to see if they can offer any insight into what is going on..

_________________
The real problem with goto is not with the control transfer, but with environments. Properly tail-recursive closures get both right.


Top
 Profile  
 
 Post subject:
PostPosted: Sat Apr 14, 2007 10:10 pm 
Offline
Member
Member

Joined: Sun Jan 14, 2007 9:15 pm
Posts: 2566
Location: Sydney, Australia (I come from a land down under!)
Oh well, I'll just have to keep working at it :roll:

IMHO Windows is sending the packet, all well and good, then when it receives the reply it checks that the addresses and such match, in this case they probably don't...

The image is online now - ne2k_testing.img (CVS)... You just have to ping 192.168.1.109 and it should come up with the ARP request receive. Then nothing. If you want one which replies (ie. promiscuous mode) ask.

Edit: this is what the sniffer gets in promiscuous mode:
Code:
14:22:52.504254 IP Matthew > 192.168.1.109: ICMP echo request, id 512, seq 257, length 40
14:22:52.516217 IP 192.168.1.109 > Matthew: ICMP echo reply, id 512, seq 257, length 40


Should work... but doesn't, raw packet display:
Code:
14:24:18.004407 IP Matthew > 192.168.1.109: ICMP echo request, id 512, seq 1537, length 40
E..<I)....ml...n...m..E[....abcdefghijklmnopqrstuvwabcdefghi
14:24:18.010338 IP 192.168.1.109 > Matthew: ICMP echo reply, id 512, seq 1281, length 40
E..<[email protected]


Any ideas?

_________________
Pedigree | GitHub | Twitter | LinkedIn


Top
 Profile  
 
 Post subject:
PostPosted: Sat Apr 14, 2007 10:17 pm 
Offline
Member
Member
User avatar

Joined: Thu Mar 08, 2007 11:08 am
Posts: 670
Code:
<07:27:11|root@wall:~># arp
Address                  HWtype  HWaddress           Flags Mask            Iface
192.168.1.109            ether   B0:C4:20:00:00:00   C                     eth1


Seems fine... let's see if I can dig something else out of the thing.. ;)

_________________
The real problem with goto is not with the control transfer, but with environments. Properly tail-recursive closures get both right.


Top
 Profile  
 
 Post subject:
PostPosted: Sat Apr 14, 2007 10:18 pm 
Offline
Member
Member

Joined: Sun Jan 14, 2007 9:15 pm
Posts: 2566
Location: Sydney, Australia (I come from a land down under!)
mystran wrote:
Code:
<07:27:11|root@wall:~># arp
Address                  HWtype  HWaddress           Flags Mask            Iface
192.168.1.109            ether   B0:C4:20:00:00:00   C                     eth1


Seems fine... let's see if I can dig something else out of the thing.. ;)


I told you that ARP requests work... try pinging it.

Edit: I decoded the raw packet for the ICMP ping, the MAC addresses are:
Code:
Sent packet:
From: 00 0F EA A0 15 AF
To: 00 B0 C4 20 FF A1

Reply:
From: 00 B0 C4 20 FF A1
To: 00 0F EA A0 15 AF


Sounds right to me...

Edit 2: I dissected the raw packets and everything is right. I'm seriously stuck now. BTW, did I give you the promiscuous mode one, or the non-promiscuous mode one? And have you tried to ping it?

Edit 3: I'm uploading a promiscuous mode image so you have a point of comparison.

_________________
Pedigree | GitHub | Twitter | LinkedIn


Top
 Profile  
 
 Post subject:
PostPosted: Sat Apr 14, 2007 10:40 pm 
Offline
Member
Member
User avatar

Joined: Thu Mar 08, 2007 11:08 am
Posts: 670
Hmmh.. for ARP packets, the MAC it prints for the sender is indeed what it should be...

But the image you gave me doesn't seem to be able to receive anything... I'd need the promiscuous version. :)

Quote:
Code:

Sent packet:
From: 00 0F EA A0 15 AF
To: 00 B0 C4 20 FF A1

Reply:
From: 00 B0 C4 20 FF A1
To: 00 0F EA A0 15 AF



Hmh... how does that sound right to you?

B0:C0:20:00:00:00 is what Bochs defaults to... or have you changed your Bochs to use 00:B0:C4:20:FF:A1 instead?

hmmh..

_________________
The real problem with goto is not with the control transfer, but with environments. Properly tail-recursive closures get both right.


Top
 Profile  
 
 Post subject:
PostPosted: Sat Apr 14, 2007 11:01 pm 
Offline
Member
Member

Joined: Sun Jan 14, 2007 9:15 pm
Posts: 2566
Location: Sydney, Australia (I come from a land down under!)
Yes, I changed the Bochs config to make the MAC 00:B0:C4:20:FF:A1.

The promiscuous version is in my CVS repositry. (or should be anyway).

_________________
Pedigree | GitHub | Twitter | LinkedIn


Top
 Profile  
 
 Post subject:
PostPosted: Sat Apr 14, 2007 11:15 pm 
Offline
Member
Member
User avatar

Joined: Thu Mar 08, 2007 11:08 am
Posts: 670
Should it print something when it receives a packet?

_________________
The real problem with goto is not with the control transfer, but with environments. Properly tail-recursive closures get both right.


Top
 Profile  
 
 Post subject:
PostPosted: Sun Apr 15, 2007 12:28 am 
Offline
Member
Member

Joined: Sun Jan 14, 2007 9:15 pm
Posts: 2566
Location: Sydney, Australia (I come from a land down under!)
Depends. What type? If it's TCP or ICMP, it should print something (same as ARP).

Which image are you using?

Edit: I wrote to PAR0-PAR5 the proper MAC address. My OS now receives packets without promiscuous mode :D. Now Windows still won't read them.

_________________
Pedigree | GitHub | Twitter | LinkedIn


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 48 posts ]  Go to page 1, 2, 3, 4  Next

All times are UTC - 6 hours


Who is online

Users browsing this forum: SemrushBot [Bot] and 51 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group