Jump to content


Photo

My Final Unsuccessful Attempt At Porting µip 1.0 Stack


  • Please log in to reply
14 replies to this topic

#1 Mi©®os∞ft

Mi©®os∞ft

    X-S Member

  • Members
  • Pip
  • 147 posts

Posted 16 April 2008 - 11:51 PM

In pktdrv.c
//Buffers must be contiguous memory buffers (use Mm fonction).

Can we use regular
unsigned char uip_buf[1500 + 2];

DHCP sends requests but I recieve no reply/offer....


Anyway, Before I suffer from Brain trauma... What's wrong with my SOURCE? uhh.gif

Wattcp = No more attempts after 102 builds... Hence my switch to simplistic yet flexible UIP 1.0 laugh.gif

Also, There's no restricting license

Thanks

Edited by Mi©®os∞ft, 16 April 2008 - 11:54 PM.


#2 Mi©®os∞ft

Mi©®os∞ft

    X-S Member

  • Members
  • Pip
  • 147 posts

Posted 18 April 2008 - 12:28 AM

QUOTE(Mi©®os∞ft @ Apr 16 2008, 07:27 PM) View Post

In pktdrv.c
//Buffers must be contiguous memory buffers (use Mm fonction).


Can we use regular
unsigned char packetbuff[1520];

instead of

static unsigned char *packetbuff; and later use mmMmAllocateContiguousMemoryEx

uhh.gif


#3 ressurectionx

ressurectionx

    X-S Knowledgebase

  • Dev/Contributor
  • PipPipPipPipPipPipPipPip
  • 4,214 posts
  • Xbox Version:v1.0
  • 360 version:none

Posted 18 April 2008 - 05:06 PM

Love to help you out man, but that's all a foreign language to me. I still don't even know what you're trying to do, but great you're trying to do it. Keep your head up. Somebody around here will help you and some of the legends stop by to give a hand on occasion

Good luck
~Rx

#4 Mi©®os∞ft

Mi©®os∞ft

    X-S Member

  • Members
  • Pip
  • 147 posts

Posted 18 April 2008 - 08:33 PM

QUOTE(ressurectionx @ Apr 18 2008, 12:42 PM) View Post

Love to help you out man, but that's all a foreign language to me. I still don't even know what you're trying to do, but great you're trying to do it. Keep your head up. Somebody around here will help you and some of the legends stop by to give a hand on occasion

Good luck
~Rx


Hehe. I am still working on this... Wonder why I wrote "Final attempt"

I keep on trying things until I succeed since I started w/ computers, donno if it's good or bad for me laugh.gif



#5 ressurectionx

ressurectionx

    X-S Knowledgebase

  • Dev/Contributor
  • PipPipPipPipPipPipPipPip
  • 4,214 posts
  • Xbox Version:v1.0
  • 360 version:none

Posted 19 April 2008 - 03:23 AM

What are we on now.... Final Fantasy 12.... Final Fight 3.... and all of their offspring...

Don't worry about it. I'm pretty sure Final doesn't mean anything anymore. It's just a filler word.

#6 openxdkman

openxdkman

    X-S Genius

  • Moderator
  • PipPipPipPip
  • 823 posts
  • Xbox Version:unk
  • 360 version:unknown

Posted 19 April 2008 - 10:02 PM

You should have tested the detect_ping sample supplied in the xbox1 packet driver archive

It's right at the beginning of the code :

CODE

void XBoxStartup(void)
{
...
    packetbuffer=(unsigned char *)MmAllocateContiguousMemoryEx(
            1520,
            0,        //lowest acceptable
            0xFFFFFFFF,    //highest acceptable
            0,          //no need to align to specific boundaries multiple
            4);        //non cached, non ordered


The problem is to give a physical address. It's not so hard to comply to.

Edited by openxdkman, 19 April 2008 - 10:04 PM.


#7 Mi©®os∞ft

Mi©®os∞ft

    X-S Member

  • Members
  • Pip
  • 147 posts

Posted 19 April 2008 - 11:13 PM

QUOTE(openxdkman @ Apr 19 2008, 05:38 PM) View Post

You should have tested the detect_ping sample supplied in the xbox1 packet driver archive

It's right at the beginning of the code :

CODE

void XBoxStartup(void)
{
...
    packetbuffer=(unsigned char *)MmAllocateContiguousMemoryEx(
            1520,
            0,        //lowest acceptable
            0xFFFFFFFF,    //highest acceptable
            0,          //no need to align to specific boundaries multiple
            4);        //non cached, non ordered


The problem is to give a physical address. It's not so hard to comply to.



By hardware address, It's the Ethernet MAC right?
I do set it by:
CODE
uip_setethaddr(&mac); //tapdev.c tapdev_init inits uip_eth_addr mac;


Any other ideas uhh.gif

Edited by Mi©®os∞ft, 19 April 2008 - 11:14 PM.


#8 Mi©®os∞ft

Mi©®os∞ft

    X-S Member

  • Members
  • Pip
  • 147 posts

Posted 21 April 2008 - 11:35 PM

OK. I'm close but not quiet, It seems we actually send the broadcast signal out, however the source MAC is getting corrupted... Trying to figure out the bug

IPB Image
IPB Image

OK, since now I use

CODE
u8_t *uip_buf=NULL; //u8_t uip_buf[1520]; -- old
uip_buf=(unsigned char *)MmAllocateContiguousMemoryEx(
            1520,
            0,        //lowest acceptable
            0xFFFFFFFF,    //highest acceptable
            0,          //no need to align to specific boundaries multiple
            4);        //non cached, non ordered



CODE
static u8_t c, opt;


I'm confused with Statements like:

CODE

if(uip_buf[UIP_TCPIP_HLEN + UIP_LLH_LEN + 1 + c] == 0)

should be changed to which one of the below?

if((uip_buf+UIP_TCPIP_HLEN + UIP_LLH_LEN + 1 + c) == 0)
[b]or [/b]
if(*(uip_buf+UIP_TCPIP_HLEN + UIP_LLH_LEN + 1 + c) == 0)
uhh.gif


CODE
c += uip_buf[UIP_TCPIP_HLEN + UIP_LLH_LEN + 1 + c];

to

c += (uip_buf+UIP_TCPIP_HLEN + UIP_LLH_LEN + 1 + c);
or
c += *(uip_buf+UIP_TCPIP_HLEN + UIP_LLH_LEN + 1 + c);




CODE

tmp16 = ((u16_t)uip_buf[UIP_TCPIP_HLEN + UIP_LLH_LEN + 2 + c] << 8) |
      (u16_t)uip_buf[UIP_IPTCPH_LEN + UIP_LLH_LEN + 3 + c];
    uip_connr->initialmss = uip_connr->mss =
      tmp16 > UIP_TCP_MSS? UIP_TCP_MSS: tmp16;
uhh.gif


Thanks... Just some help need with this overly complicated stuff.

Edited by Mi©®os∞ft, 21 April 2008 - 11:47 PM.


#9 openxdkman

openxdkman

    X-S Genius

  • Moderator
  • PipPipPipPip
  • 823 posts
  • Xbox Version:unk
  • 360 version:unknown

Posted 22 April 2008 - 02:38 PM

You are on the right path...
Packet analyser is a must to see what you put wrong inside packets
Some can even tell you if your checksums are wrongly calculated (EtherPeekNX)

if you have
unsigned char *p;
p[offset] will be the value of byte at the given offset
*(p+offset) will be the same

I smell these lines are for the checksum calculation
(I had horrible time with it, because it's not so simple to know what parts are summed)

I could finally succeed by spying a normal communication between two machines
and try to see if I would get exactly same packet if I was one of these machines

That way you can see what is wrong in the packet you build up yourself

Edited by openxdkman, 22 April 2008 - 02:41 PM.


#10 Mi©®os∞ft

Mi©®os∞ft

    X-S Member

  • Members
  • Pip
  • 147 posts

Posted 22 April 2008 - 02:49 PM

QUOTE(openxdkman @ Apr 22 2008, 10:14 AM) View Post

You are on the right path...
Packet analyser is a must to see what you put wrong inside packets
Some can even tell you if your checksums are wrongly calculated (EtherPeekNX)

if you have
unsigned char *p;
p[offset] will be the value of byte at the given offset
*(p+offset) will be the same

I smell these lines are for the checksum calculation
(I had horrible time with it, because it's not so simple to know what parts are summed)

I could finally succeed by spying a normal communication between two machines
and try to see if I would get exactly same packet if I was one of these machines

That way you can see what is wrong in the packet you build up yourself



Thanks...

I am not so good at casting stuff... What would this statement be? uhh.gif

CODE
tmp16 = ((u16_t)uip_buf[UIP_TCPIP_HLEN + UIP_LLH_LEN + 2 + c] << 8) |
      (u16_t)uip_buf[UIP_IPTCPH_LEN + UIP_LLH_LEN + 3 + c];



Edited by Mi©®os∞ft, 22 April 2008 - 02:51 PM.


#11 Mi©®os∞ft

Mi©®os∞ft

    X-S Member

  • Members
  • Pip
  • 147 posts

Posted 23 April 2008 - 04:10 AM

QUOTE(Mi©®os∞ft @ Apr 22 2008, 10:25 AM) View Post

Thanks...

I am not so good at casting stuff... What would this statement be? uhh.gif

CODE
tmp16 = ((u16_t)uip_buf[UIP_TCPIP_HLEN + UIP_LLH_LEN + 2 + c] << 8) |
      (u16_t)uip_buf[UIP_IPTCPH_LEN + UIP_LLH_LEN + 3 + c];



NVM.

I believe I am getting EXTREMELY close to making it. biggrin.gif

I actually saw "Who has 192.168.2.4? Tell 192.168.2.1 (ROUTER)"
Xbox Responded "192.169.2.4 is at 00:0d:3a:xx:xx:xx" love.gif ARP Runs perfectly; however it's manually assigned IP address pop.gif


However DHCP still doesn't seems to work; it produces a incomplete packet and I'm investigating it cool.gif
I resolved the wrong MAC issue.

Edited by Mi©®os∞ft, 23 April 2008 - 04:14 AM.


#12 openxdkman

openxdkman

    X-S Genius

  • Moderator
  • PipPipPipPip
  • 823 posts
  • Xbox Version:unk
  • 360 version:unknown

Posted 23 April 2008 - 03:23 PM

Getting an IP from DHCP is a whole adventure in itself.

Anyway, be sure to allow the manual IP setting.
If your PC is 192.168.0.1, all you need is that your manually set IP address
is 192.168.0.n n>4 let's say
(would be nice to be able to read the one set in dashboard. i didn't try)

DHCP (read rfc's) requires you name your OS, expiration etc... in not so simple dialog loop

PPPoE is even worse...

Good luck. With ARP done, it will get easier and easier to test stuff.


#13 Mi©®os∞ft

Mi©®os∞ft

    X-S Member

  • Members
  • Pip
  • 147 posts

Posted 26 April 2008 - 04:34 PM

Need some help:

IP packet is getting corrupted! sad.gif

CODE

struct uip_eth_addr {
  u8_t addr[6];
};

struct uip_eth_hdr {
  struct uip_eth_addr dest;
  struct uip_eth_addr src;
  u16_t type;
};


Does this struct look right?
CODE
struct ethip_hdr {
  struct uip_eth_hdr ethhdr; //
  /* IP header. */
   u8_t vhl,
    tos,
    len[2],
    ipid[2],
    ipoffset[2],
    ttl,
    proto;
  u16_t ipchksum;
  u16_t srcipaddr[2],
    destipaddr[2];
};


The ARP code checks to see if destination IP is broadcast or not.... It says it is not... but it IS. blink.gif
The checking code is correct... But IPBUF->destipaddr[0]!=0xffff && IPBUF->destipaddr[0]!=0xffff !

#define BUF ((struct arp_hdr *)uip_buf)
#define IPBUF ((struct ethip_hdr *)uip_buf)

CODE
if(uip_ipaddr_cmp(IPBUF->destipaddr, broadcast_ipaddr)) {
    dbgPrint("YES Broadcast Addr");
    memcpy(IPBUF->ethhdr.dest.addr, broadcast_ethaddr.addr, 6);
  } else {
// reaches here :(
    dbgPrint("Not Broadcast Addr, Replacing IP packet with ARP request VERSION: %x %x:%x\n",IPBUF->vhl,IPBUF->destipaddr,IPBUF->destipaddr+1);
  


That was why it seemed to send Who is 0.0.16.240 Tell 0.0.0.0 and such crap... Which makes sense since it thinks it's not broadcast address.

THe linklevelheader length is 14; guessing it's right.


Openxdkman, Any ideas?

Edited by Mi©®os∞ft, 26 April 2008 - 04:54 PM.


#14 openxdkman

openxdkman

    X-S Genius

  • Moderator
  • PipPipPipPip
  • 823 posts
  • Xbox Version:unk
  • 360 version:unknown

Posted 28 April 2008 - 09:56 AM

Broadcasting implies to put 6xFF in mac adress (eth addess) if I remember well

Check with your analyser that the 6 bytes of eth address are correctly exchanged/memorized
then the 4 bytes of the ip address are correctly exchanged/memorized, etc...

A good thing to do (theoretically) is to log sizof(my struct name here) for every struct you are using.
If it's bigger than the theoretical size that means padding zeros have been silently inserted inside the struct in order to enforce 2 bytes or 4 bytes alignments.
Unfortunately, on xbox1, I found cases where sizeof returned value is wrong... (aligned itself!)
So, you HAVE TO be paranoid about structures... Only packet analyser will confirm your structure is ok.

Here are a few parts of my wattcp modified header source (same source works on pc0, xb1 & ps2)

CODE


#ifdef ENABLE_XBOX
typedef unsigned char u8;
typedef unsigned short u16;
typedef unsigned int u32;
#endif

...


typedef u8 byte;
typedef u16 word;
typedef u32 longword;

typedef byte eth_address[6];
typedef byte ip_address[4];
typedef byte longw[4];  //no way to reach a non aligned long on ps2 the usual way...

...



/* The Ethernet header (14 bytes) */
typedef struct {
    eth_address     destination;
    eth_address     source;
    word            type;
} eth_Header;

/* The Internet Header (20 bytes) */
typedef struct {
    byte        hdrlenver;
//    unsigned char   hdrlen  : 4;
//    unsigned char   ver     : 4;
    byte        tos;
    word            length;
    word            identification;
    word            frags;
//    unsigned        frags : 3;
//    unsigned        fo    : 13;
    byte        ttl;
    byte        proto;
    word            checksum;
    longw           source;    //Use mov.h function to access longw data in structures
    longw           destination;//for ps2 compatibilty (because of unaligned longwords)
} in_Header;


//#define in_GetVersion(ip) ( (ip)->ver )
//#define in_GetHdrlen(ip)  ( (ip)->hdrlen )  /* 32 bit word size */
#define in_GetVersion(ip) ( (ip)->hdrlenver>>4 )
#define in_GetHdrlen(ip)  ( (ip)->hdrlenver&15 )
#define in_GetHdrlenBytes(ip)  ( in_GetHdrlen(ip) << 2 ) /* 8 bit byte size */
#define in_GetTos(ip)      ( (ip)->tos)

#define in_GetTTL(ip)      ((ip)->ttl)
#define in_GetProtocol(ip) ((ip)->proto )

//8 bytes
typedef struct {
    word        srcPort;
    word        dstPort;
    word        length;
    word        checksum;
} udp_Header;

#define UDP_LENGTH ( sizeof( udp_Header ))

//20 bytes
typedef struct {
    word            srcPort;
    word            dstPort;
    longw           seqnum;
    longw           acknum;
    word            flags;
    word            window;
    word            checksum;
    word            urgentPointer;
} tcp_Header;


/* The TCP/UDP Pseudo Header (14 bytes) */
typedef struct {
    longw       src;
    longw       dst;
    byte        mbz;
    byte        protocol;
    word        length;
    word        checksum;
} tcp_PseudoHeader;

#define PSEUDO_LENGTH 14 //use this instead of sizeof(tcp_PseudoHeader) which returns 16 on xb



Pseudo stuff is other stucture subparts used for checksum calculations only

You can do mistakes easily in your source and compiler can change things in your back easily as well...

Edited by openxdkman, 28 April 2008 - 09:58 AM.


#15 Mi©®os∞ft

Mi©®os∞ft

    X-S Member

  • Members
  • Pip
  • 147 posts

Posted 03 May 2008 - 03:59 AM

DHCP works... Recieves messages from PC client.... That's the progress from few days back biggrin.gif

However, Unable to send any data back! blink.gif
Just a few steps away! Hooooohooo! biggrin.gif

Just thought I would post my progress rolleyes.gif

Edited by Mi©®os∞ft, 03 May 2008 - 04:00 AM.





0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users