RTEMS 4.9.5 vs 4.10.2 Network Stack
Bacon Xu
baconxu at gmail.com
Wed Aug 29 02:10:32 UTC 2012
Hi, all, It's Indeed that there are no any difference of tcp/ip stack
between rtems 4.9.5 and rtems 4.10.2.
But there are some problems in ARM platform. The processors of Arm7,
arm 9, arm11 can't solve non-align address directly.
Tcp/ip stack have many structures that are non aligned. it will cause
DATABORT problems in ARM platform.
So the compiler will speed the program and avoid the problem, when
they compiled the structure ,they will add some hollow bytes to
make the structure aligned. That's the point.
The problem is that there are two hollow bytes in "ether_type" of
"struct ether_header"(cpukit/libnetworking/net/ethernet.h). Just
modify like this:
struct ether_header {
u_char ether_dhost[ETHER_ADDR_LEN];
u_char ether_shost[ETHER_ADDR_LEN];
u_short ether_type;
} __attribute__((packed)); /*bacon modifed*/
It will work properly.
BTW, in ARM7-11 processors, Follows need to be modified:
1.cpukit/libnetworking/netinet/tcpip.h
/*
* Tcp+ip header, after ip options removed.
*/
struct tcpiphdr {
struct ipovly ti_i; /* overlaid ip structure */
struct tcphdr ti_t; /* tcp header */
} __attribute__ ((packed));/*bacon add*/
/*
* Tcp+ip header, after ip options removed but including TCP options.
*/
struct full_tcpiphdr {
struct ipovly ti_i; /* overlaid ip structure */
struct tcphdr ti_t; /* tcp header */
char ti_o[TCP_MAXOLEN]; /* space for tcp options */
}__attribute__ ((packed));/*bacon add*/
2. cpukit/libnetworking/netinet/ip_var.h
struct ipovly {
caddr_t ih_next;
caddr_t ih_prev; /* for protocol sequence q's */
u_char ih_x1; /* (unused) */
u_char ih_pr; /* protocol */
u_short ih_len; /* protocol length */
struct in_addr ih_src; /* source internet address */
struct in_addr ih_dst; /* destination internet address */
}__attribute__ ((packed));/*bacon add*/
3.cpukit/libnetworking/netinet/ip.h
/*
* Structure of an internet header, naked of options.
*/
struct ip {
#ifdef _IP_VHL
u_char ip_vhl; /* version << 4 | header length >> 2 */
#else
#if BYTE_ORDER == LITTLE_ENDIAN
u_int ip_hl:4, /* header length */
ip_v:4; /* version */
#endif
#if BYTE_ORDER == BIG_ENDIAN
u_int ip_v:4, /* version */
ip_hl:4; /* header length */
#endif
#endif /* not _IP_VHL */
u_char ip_tos; /* type of service */
u_short ip_len; /* total length */
u_short ip_id; /* identification */
u_short ip_off; /* fragment offset field */
#define IP_RF 0x8000 /* reserved fragment flag */
#define IP_DF 0x4000 /* dont fragment flag */
#define IP_MF 0x2000 /* more fragments flag */
#define IP_OFFMASK 0x1fff /* mask for fragmenting bits */
u_char ip_ttl; /* time to live */
u_char ip_p; /* protocol */
u_short ip_sum; /* checksum */
struct in_addr ip_src,ip_dst; /* source and dest address */
} __packed __aligned(1);/*bacon modified*/
4.cpukit/include/rtems/bsd/sys/queue.h
struct quehead {
struct quehead *qh_link;
struct quehead *qh_rlink;
} __attribute__ ((packed));/*bacon add*/
kind regards,
Bacon
> Message: 1
> Date: Tue, 28 Aug 2012 02:02:53 +0430
> From: SAeeD <salpha.2004 at gmail.com>
> To: Joel Sherrill <Joel.Sherrill at oarcorp.com>, rtems-users at rtems.org
> Subject: Re: RTEMS 4.9.5 vs 4.10.2 Network Stack
> Message-ID:
>
> <CAEdVrmN7JSyS5iyDfkLmHQ7jx7X2AK6zud61uSWhxggcOfqBWg at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> As I traced the execution of RTEMS 4.10.2 with a simple TCP client
> application on QEMU, I got this experimental:
> After setting up a TCP server in PC, I executed the TCP client on Mini2440
> and traced the execution. A socket is created with socket descriptor #3.
> Every thing seems fine but when calling function "connect", after a long
> time hanging on the line 161 of the following context (rtems_syscall.c
> where function "connect" if implemented.), an error numbered #116 happens
> and I got out of the loop and return -1 as the return value of function
> "connect". This is the context:
>
> 160 while ((so->so_state & SS_ISCONNECTING) && so->so_error == 0) {
> 161 error = soconnsleep (so);
> 162 if (error)
> 163 break;
> 164 }
> 165 if (error == 0) {
> 166 error = so->so_error;
> 167 so->so_error = 0;
> 168 }
> 169 bad:
> 170 so->so_state &= ~SS_ISCONNECTING;
> 171 m_freem (nam);
> 172 if (error)
> 173 errno = error;
> 174 else
> 175 ret = 0;
> 176 rtems_bsdnet_semaphore_release ();
> 177 return ret;
>
> What could be the possible problem? What is the meaning of error #116?
>
> I think I should also mention that when sniffing packets on telnetd
> application, Mini2440 (which was running RTEMS 4.10.2) did not respond to
> ARP requests from my PC. After I manipulated my PC's ARP table manually,
> then Mini2440 didn't respond to my PC's TCP Syn packets so telnetd didn't
> work too.
>
> Thanks for any hint
> SAeeD
>
> On Sun, Aug 26, 2012 at 6:37 PM, Joel Sherrill
> <Joel.Sherrill at oarcorp.com>wrote:
>
>> How do they fail? As far as I can remember, there are no network related
>> changes between those versions. This may be a side effect of something else.
>>
>> SAeeD <salpha.2004 at gmail.com> wrote:
>>
>>
>> I must mention that I configured and compiled both version using
>> --enable-networking and --enable-posix options.
>>
>> On Sun, Aug 26, 2012 at 1:55 PM, SAeeD <salpha.2004 at gmail.com> wrote:
>>
>>> Dear all,
>>>
>>> I'm currently running network-demos on Mini2440 BSP.
>>> What makes me wonder is that various network-demos samples (like
>>> telnetd,
>>> http, netdemo) works on RTEMS 4.9.5 but not on RTEMS 4.10.2.
>>> The point is that both versions have the same network device driver. (As
>>> their c/src/lib/libbsp/arm/mini2440/network/network.c files are the
>>> same.)
>>> Also, I was able to send UDP packets in both versions so I think the
>>> problem is not related to device drivers. One more evidence: The demos
>>> for
>>> 4.10.2 doesn't work on QEMU for Mini2440 too. I also checked
>>> rtems_gluc.c
>>> for both versions to make sure that definition of
>>> rtems_bsdnet_initialize_network() wasn't changed.
>>> Does anyone have any hint, suggestion, advice, etc.? I do really
>>> appreciate any comment.
>>>
>>> Thanks
>>> SAeeD
>>>
>>
>>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> <http://www.rtems.org/pipermail/rtems-users/attachments/20120828/9d3d6f0b/attachment-0001.html>
>
> ------------------------------
>
> Message: 2
> Date: Tue, 28 Aug 2012 02:07:42 +0430
> From: SAeeD <salpha.2004 at gmail.com>
> To: Joel Sherrill <Joel.Sherrill at oarcorp.com>, rtems-users at rtems.org
> Subject: Re: RTEMS 4.9.5 vs 4.10.2 Network Stack
> Message-ID:
>
> <CAEdVrmPO8ZFcdYZ3Qr4ZK4nNmc9qJmq2Oujpo-P1MJJ4btNpOQ at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> I forgot to say: I also think of a side effect of 4.10.2 patch for
> Mini2440. But where, do you think I may search for the side effect with
> this experimentals? I mean where can be effected by the side effect that
> this happens? The implementation of TCP/IP stack or I dunno somewhere
> else?
>
> On Tue, Aug 28, 2012 at 2:02 AM, SAeeD <salpha.2004 at gmail.com> wrote:
>
>> As I traced the execution of RTEMS 4.10.2 with a simple TCP client
>> application on QEMU, I got this experimental:
>> After setting up a TCP server in PC, I executed the TCP client on
>> Mini2440
>> and traced the execution. A socket is created with socket descriptor #3.
>> Every thing seems fine but when calling function "connect", after a long
>> time hanging on the line 161 of the following context (rtems_syscall.c
>> where function "connect" if implemented.), an error numbered #116 happens
>> and I got out of the loop and return -1 as the return value of function
>> "connect". This is the context:
>>
>> 160 while ((so->so_state & SS_ISCONNECTING) && so->so_error == 0) {
>> 161 error = soconnsleep (so);
>> 162 if (error)
>> 163 break;
>> 164 }
>> 165 if (error == 0) {
>> 166 error = so->so_error;
>> 167 so->so_error = 0;
>> 168 }
>> 169 bad:
>> 170 so->so_state &= ~SS_ISCONNECTING;
>> 171 m_freem (nam);
>> 172 if (error)
>> 173 errno = error;
>> 174 else
>> 175 ret = 0;
>> 176 rtems_bsdnet_semaphore_release ();
>> 177 return ret;
>>
>> What could be the possible problem? What is the meaning of error #116?
>>
>> I think I should also mention that when sniffing packets on telnetd
>> application, Mini2440 (which was running RTEMS 4.10.2) did not respond to
>> ARP requests from my PC. After I manipulated my PC's ARP table manually,
>> then Mini2440 didn't respond to my PC's TCP Syn packets so telnetd didn't
>> work too.
>>
>> Thanks for any hint
>> SAeeD
>>
>>
>> On Sun, Aug 26, 2012 at 6:37 PM, Joel Sherrill
>> <Joel.Sherrill at oarcorp.com>wrote:
>>
>>> How do they fail? As far as I can remember, there are no network
>>> related changes between those versions. This may be a side effect of
>>> something else.
>>>
>>> SAeeD <salpha.2004 at gmail.com> wrote:
>>>
>>>
>>> I must mention that I configured and compiled both version using
>>> --enable-networking and --enable-posix options.
>>>
>>> On Sun, Aug 26, 2012 at 1:55 PM, SAeeD <salpha.2004 at gmail.com> wrote:
>>>
>>>> Dear all,
>>>>
>>>> I'm currently running network-demos on Mini2440 BSP.
>>>> What makes me wonder is that various network-demos samples (like
>>>> telnetd, http, netdemo) works on RTEMS 4.9.5 but not on RTEMS 4.10.2.
>>>> The point is that both versions have the same network device driver.
>>>> (As
>>>> their c/src/lib/libbsp/arm/mini2440/network/network.c files are the
>>>> same.)
>>>> Also, I was able to send UDP packets in both versions so I think the
>>>> problem is not related to device drivers. One more evidence: The demos
>>>> for
>>>> 4.10.2 doesn't work on QEMU for Mini2440 too. I also checked
>>>> rtems_gluc.c
>>>> for both versions to make sure that definition of
>>>> rtems_bsdnet_initialize_network() wasn't changed.
>>>> Does anyone have any hint, suggestion, advice, etc.? I do really
>>>> appreciate any comment.
>>>>
>>>> Thanks
>>>> SAeeD
More information about the users
mailing list