Bob Brusa | 1 Dec 2010 09:47
Picon

Re: Hostname for DHCP - where is it specified?

Am 20.09.2010, 17:49 Uhr, schrieb Simon Goldschmidt <goldsimon@...>:

>
>
> Kieran Mansley <kieran@...> wrote:
>
>> On Mon, 2010-09-20 at 14:32 +0000, Bob Brusa wrote:
>>> Fine, adding netbios helped. Now I can get into contact with my
>>> board,
>>> running a corresponding program on my PC that uses the NETBIOSNAME
>>> to
>>> connect. However, Zyxel still does not know the name of my board -
>>> which
>>> obiously allows my Win-XP program to connect with my board. Has
>>> anybody a
>>> hint what is missing?
>>
>> If you want a more general solution than netbios naming you need to
>> update your DNS server with the IP address and name that have been given
>> to your board.  DHCP doesn't do this - it is just responsible for giving
>> the IP address to the board, not for updating the DNS server.
> Well, DHCP does support for the client to report a name to the server,  
> but the server must be specially configured to pass this on to a DNS  
> server. It could very well be that your router supports this, but as  
> Kieran said, this is not really a part of DHCP.
>
> However, to test this, you can enable passing on a name by setting  
> LWIP_NETIF_HOSTNAME to 1 and setting the name via netif_set_hostname().
>
> Simon
(Continue reading)

Kieran Mansley | 1 Dec 2010 13:43

Re: Hostname for DHCP - where is it specified?


On 1 Dec 2010, at 08:47, Bob Brusa wrote:
> 
> 
> I feel that something is not as it should be with my lwip. I can find nowhere in the h-files a function
netif_set_hostname. I find the parameter LWIP_NETIF_HOSTNAME, but it is undefined. On the other hand,
there is a parameter CYGIMP_LWIP_NETIF_HOSTNAME in net_lwip.h (and I defined it in config as 1).
However, as far as I can see, this parameter is used nowhere. I am tempted to assume, that there is a naming
problem - two names for something that should be uniquely named?
> I am working with ecos, but I am not sure which version of lwip it includes. The last checkout (ecos)I did was
sometimes this spring..... Prior to delving into further details: What is your opinion about this?

My guess is that you have an older version of lwIP that pre-dates that addition of that function.

Kieran
Paul Archer | 1 Dec 2010 14:36
Picon

Re: Hostname for DHCP - where is it specified?

From looking here:

http://ecos.sourceware.org/cgi-bin/cvsweb.cgi/ecos/packages/io/eth/current/ChangeLog?cvsroot=ecos

Looks like ecos lwip is at versioin 1.3.2

On Wed, Dec 1, 2010 at 11:43 PM, Kieran Mansley <kieran@...> wrote:
>
> On 1 Dec 2010, at 08:47, Bob Brusa wrote:
>>
>>
>> I feel that something is not as it should be with my lwip. I can find nowhere in the h-files a function
netif_set_hostname. I find the parameter LWIP_NETIF_HOSTNAME, but it is undefined. On the other hand,
there is a parameter CYGIMP_LWIP_NETIF_HOSTNAME in net_lwip.h (and I defined it in config as 1).
However, as far as I can see, this parameter is used nowhere. I am tempted to assume, that there is a naming
problem - two names for something that should be uniquely named?
>> I am working with ecos, but I am not sure which version of lwip it includes. The last checkout (ecos)I did
was sometimes this spring..... Prior to delving into further details: What is your opinion about this?
>
> My guess is that you have an older version of lwIP that pre-dates that addition of that function.
>
> Kieran
> _______________________________________________
> lwip-users mailing list
> lwip-users@...
> http://lists.nongnu.org/mailman/listinfo/lwip-users
>

--

-- 
----
(Continue reading)

Paul Archer | 1 Dec 2010 14:29
Picon

Re: Hostname for DHCP - where is it specified?

> After working on some other things, I come back to this issue.
>
> I feel that something is not as it should be with my lwip. I can find
> nowhere in the h-files a function netif_set_hostname. I find the parameter
> LWIP_NETIF_HOSTNAME, but it is undefined. On the other hand, there is a
> parameter CYGIMP_LWIP_NETIF_HOSTNAME in net_lwip.h (and I defined it in
> config as 1). However, as far as I can see, this parameter is used nowhere.
> I am tempted to assume, that there is a naming problem - two names for
> something that should be uniquely named?

Have a look in the file src/include/lwip/netif.h:

It contains:
#if LWIP_NETIF_HOSTNAME
#define netif_set_hostname(netif, name) do { if((netif) != NULL) {
(netif)->hostname = name; }}while(0)
#endif /* LWIP_NETIF_HOSTNAME */

hence in your lwipopts.h you need to
#define  LWIP_NETIF_HOSTNAME 1

And call the macro somewhere in your code after and interface is created.

> I am working with ecos, but I am not sure which version of lwip it includes.
> The last checkout (ecos)I did was sometimes this spring..... Prior to
> delving into further details: What is your opinion about this?
there may be a file called CHANGELOG lying around which will tell you
the version of lwip your using.

> Robert
(Continue reading)

runjin | 1 Dec 2010 12:44
Picon
Favicon

How can I determine a socket was closed in lwip ?

How can I determine a socket was closed in lwip ?
 
2010-12-01
runjin
_______________________________________________
lwip-users mailing list
lwip-users@...
http://lists.nongnu.org/mailman/listinfo/lwip-users
Kieran Mansley | 1 Dec 2010 13:40

Re: 1.4 rc1 non-blocking issues


On 30 Nov 2010, at 16:15, Yoav Nissim wrote:
> 
> 1. ERR_WOULDBLOCK is treated as a FATAL error - it seems as if someone
> forgot to update the ERR_IS_FATAL macro when the error code was added. A
> non-blocking operation that sets the conn error to WOULDBLOCK (e.g
> send() and recv() ) renders the socket unusable. Our workaround was to
> use ERR_WOULDBLOCK in the ERR_IS_FATAL macro instead of ERR_VAL.

I agree that looks wrong.  I'm sure it was correct in the past.  I'll make sure this is fixed before 1.4.0 is
released.  If you could file a bug for this on savannah it would help.

> 2. As far as we know, EMSGSIZE is not a valid return code for send() on
> a STREAM socket. netconn_write does not return the number of bytes
> processed and cannot perform partial sends. This makes an application
> that uses select run in tight loops since select returns writable, but
> send [working on an all or nothing assumption] returns an error
> (EWOULDBLOCK)

I'd like to see lwIP updated to support partial sends (which I think would solve this problem) but it won't
happen before 1.4.0.  A task on savannah would again be very helpful, if there's not one already - I think
this might have been discussed before.

> 3. connect has several problems:
> 
>     a. connect sets sock->err to EINPROGRESS. When select returns
> writable, getsockopt(SO_ERROR) will never let us know what happened [i.e
> no access to conn->err] since getsockopt(SO_ERROR) does not return the
> error value when sock->err is not 0 (it is set to EINPROGRESS). It seems
> to me the non-blocking path lacks the propagation of the connect result
> to sock->err (which does happen when using a blocking call).
> 
>     b. getsockopt(SO_ERROR) - behaviour according to Posix is to return
> and clear the _pending_ error for the socket (if one exists). instead
> getsockopt returns the last socket call error once. If additional calls
> are made netconn's last error is returned repeatedly.
> 
>     c. if connect is called again while a previous non-blocking connect
> is being processed, ERR_ISCONN is assigned to conn->err [which by the
> way translates to an errno of -1]. Now, if the connection succeeds,
> do_connected will not be able to set conn->err to ERR_OK since it checks
> for ERR_INPROGRESS. To make things worse, ERR_ISCONN is treated as a
> FATAL error, and will therefore render the socket unusable. According to
> Posix, EALREADY should be returned while a connect is in progress, and
> EISCONN should be returned when a socket is connected.

We'll need to look into those in more detail.

> 4. lwip_select seems to be susceptible to race conditions and has issued
> many ASSERTs as well as crashed.

These sounds like you're using a socket from two different threads (one calling select(), the other
calling close()).  Unfortunately this style of operation isn't supported in lwIP.

Kieran
Kieran Mansley | 1 Dec 2010 16:41

Re: backup sites for lwip


On 30 Nov 2010, at 07:50, Martin Velek wrote:

> Hi,
> 
> is there a backup site for lwip? The http://savannah.nongnu.org/ is
> down due to hack.

No, there's no backup site.

Kieran
Simon Goldschmidt | 2 Dec 2010 08:14
Picon
Picon

Re: 1.4 rc1 non-blocking issues


Kieran Mansley <kieran@...> wrote:
> > 1. ERR_WOULDBLOCK is treated as a FATAL error - it seems as if someone
> > forgot to update the ERR_IS_FATAL macro when the error code was added. A
> > non-blocking operation that sets the conn error to WOULDBLOCK (e.g
> > send() and recv() ) renders the socket unusable. Our workaround was to
> > use ERR_WOULDBLOCK in the ERR_IS_FATAL macro instead of ERR_VAL.
> 
> I agree that looks wrong.  I'm sure it was correct in the past.  I'll make
> sure this is fixed before 1.4.0 is released.  If you could file a bug for
> this on savannah it would help.

I've just fixed that in CVS, thanks for reporting. (I can still not add a new bug to savannah...)

> > 2. As far as we know, EMSGSIZE is not a valid return code for send() on
> > a STREAM socket. netconn_write does not return the number of bytes
> > processed and cannot perform partial sends. This makes an application
> > that uses select run in tight loops since select returns writable, but
> > send [working on an all or nothing assumption] returns an error
> > (EWOULDBLOCK)
> 
> I'd like to see lwIP updated to support partial sends (which I think would
> solve this problem) but it won't happen before 1.4.0.  A task on savannah
> would again be very helpful, if there's not one already - I think this
> might have been discussed before.

There's bug #31084 for that on savannah: https://savannah.nongnu.org/bugs/?31084
I've targeted it at 1.4.0 though. I think it's one of the main missing things for lwIP to support nonblocking
sockets, so it might be worth including that to prevent having to launch 1.4.1 too soon...

> > 3. connect has several problems:
> > 
> >     a. connect sets sock->err to EINPROGRESS. When select returns
> > writable, getsockopt(SO_ERROR) will never let us know what happened [i.e
> > no access to conn->err] since getsockopt(SO_ERROR) does not return the
> > error value when sock->err is not 0 (it is set to EINPROGRESS). It seems
> > to me the non-blocking path lacks the propagation of the connect result
> > to sock->err (which does happen when using a blocking call).

Could you try CVS HEAD? There was a bug there (http://savannah.nongnu.org/bugs/?31590) which should be
fixed since a week or so now.

> >     b. getsockopt(SO_ERROR) - behaviour according to Posix is to return
> > and clear the _pending_ error for the socket (if one exists). instead
> > getsockopt returns the last socket call error once. If additional calls
> > are made netconn's last error is returned repeatedly.

That's a problem of the mixture of 3 APIs here: socket API is built on top of the netconn API which in turn is
built on top of the raw API. In a fatal error state, the socket could have an error that cannot easily be
removed, so not returning that first could be a problem. This code needs further thoughts, so it would be
best to open a bug entry for discussion (as soon as savannah is fully back online again).

> >     c. if connect is called again while a previous non-blocking connect
> > is being processed, ERR_ISCONN is assigned to conn->err [which by the
> > way translates to an errno of -1]. Now, if the connection succeeds,
> > do_connected will not be able to set conn->err to ERR_OK since it checks
> > for ERR_INPROGRESS. To make things worse, ERR_ISCONN is treated as a
> > FATAL error, and will therefore render the socket unusable. According to
> > Posix, EALREADY should be returned while a connect is in progress, and
> > EISCONN should be returned when a socket is connected.

That's a good one. Again, please file a bug report to make sure this doesn't get lost!

> > 4. lwip_select seems to be susceptible to race conditions and has issued
> > many ASSERTs as well as crashed.
> 
> These sounds like you're using a socket from two different threads (one
> calling select(), the other calling close()).  Unfortunately this style of
> operation isn't supported in lwIP.

Hmm, select() does use a global list to queue all threads waiting in a select (select_cb_list), but for me,
that worked quite well, so any detailed bug report would be great.

Thanks for the feedback, and please remember to open bug reports for the open issues: there are too many
posts on this list to keep track of bugs without the bugtracker.

Simon

Simon
--

-- 
GMX DSL Doppel-Flat ab 19,99 &euro;/mtl.! Jetzt auch mit 
gratis Notebook-Flat! http://portal.gmx.net/de/go/dsl
flambert | 2 Dec 2010 09:19
Picon
Favicon

RTAI and LwIP for Realtime Communication


Hi,

I recently found the LwIP Project. But I'm not sure if I truly understand.
I'm looking for a realtime stack to communicate in realtime via Ethernet. I
use Linux RTAI for my realtime system. Is it possible to use LwIP for that
job?

Best Regards,
Franz
--

-- 
View this message in context: http://old.nabble.com/RTAI-and-LwIP-for-Realtime-Communication-tp30356565p30356565.html
Sent from the lwip-users mailing list archive at Nabble.com.
Andrew Foster | 2 Dec 2010 14:19
Favicon

RE: RTAI and LwIP for Realtime Communication

Franz,

If you haven't already looked in to RTL-lwIP, you may want to give it a 
perusing. I have not personally used their implementation but it sounds 
like a good place to start.

RTL-lwIP: http://rtl-lwip.sourceforge.net/

There is also a QP-lwIP integration that uses an event driven model as 
opposed to the RTOS model. This "has been carefully designed for hard 
real-time control-type applications..."

QP-lwIP: http://www.state-machine.com/lwip/index.php

Andrew 

-----Original Message-----
From: flambert [mailto:franz_lambert_engel@...] 
Sent: Thursday, December 02, 2010 03:19
To: lwip-users@...
Subject: [lwip-users] RTAI and LwIP for Realtime Communication

Hi,

I recently found the LwIP Project. But I'm not sure if I truly 
understand.
I'm looking for a realtime stack to communicate in realtime via 
Ethernet. I
use Linux RTAI for my realtime system. Is it possible to use LwIP for 
that
job?

Best Regards,
Franz
--

-- 
View this message in context: 
http://old.nabble.com/RTAI-and-LwIP-for-Realtime-Communication-tp30356565p30356565.html
Sent from the lwip-users mailing list archive at Nabble.com.

_______________________________________________
lwip-users mailing list
lwip-users@...
http://lists.nongnu.org/mailman/listinfo/lwip-users

Gmane