Yes.
DHCP will continue to run in the target, sending DHCP discover messages
periodically. So, if a dhcp server comes on line then eventually the target
will get a new IP address assigned by the DHCP server (dhcp offer) and abandon
the autoip self-configured address.
From: lwip-users-bounces+z
Here is what I can tell you. The targets are auto configuring themselves in the
range you define. In the default (RFC compliant) range there are 254*256
possibilities. So it is highly unlikely that 2 nodes will choose the same one.
But if so, then yes they discover each other by use of ARP. If a
Maybe someone else could also comment on this and let me know if I am wrong but
as far as I know you don’t have to do anything once the IP address is obtained
from DHCP. I don’t think you should ever be calling dhcp_stop() unless maybe
you really don’t want to use dhcp anymore. Maybe they are in
un 17, 2015 6:38 PM, "Zach Smith"
mailto:zsm...@campbellsci.com>> wrote:
That is strange. What is your physical interface - Ethernet? Wi-Fi? Are you
possibly getting your own probes reflected back to you thus thinking that
someone else out there already has your address – long sho
That is strange. What is your physical interface - Ethernet? Wi-Fi? Are you
possibly getting your own probes reflected back to you thus thinking that
someone else out there already has your address – long shot.
Sorry I can’t help more. I would put a breakpoint where you see the state get
set bac
Bob
On Thu, May 14, 2015 at 2:55 PM, Zach Smith
mailto:zsm...@campbellsci.com>> wrote:
Use the auto ip feature of lwip which I believe is the proper way to handle
this situation. With this feature enabled, after a certain number of dhcp
timeouts the device will fail over to an “auto
Use the auto ip feature of lwip which I believe is the proper way to handle
this situation. With this feature enabled, after a certain number of dhcp
timeouts the device will fail over to an “auto ip” address. The auto ip address
is an address the device chooses for itself in the range 169.254.x
If you are seeing a problem like this one it may be that you are servicing one
packet per interrupt. Then eventually multiple packets come in quick and are
received but only 1 interrupt is generated. You need to make sure you service
every available packet when you get the interrupt instead of o
I'm not sure about what the specification says but that is what LwIP does. Once
the auto ip address is obtained it continues to send DHCP discover messages
periodically and the source address is the auto ip address.
From: lwip-users-bounces+zsmith=campbellsci@nongnu.org
[mailto:lwip-users-b
Have you ruled out a low level driver problem? Maybe software is not reading
the packets out of the hardware as often as they come in. Perhaps multiple
packets arrive in hardware and the software is not reading them all out?
From: lwip-users-bounces+zsmith=campbellsci@nongnu.org
[mailto:lwi
Manoj,
Sorry, I wasn't clear. You don't want to change your MAC address. Set your MAC
address to your required address (38:60:77:4f:84:86) and leave it. But your
actual hardware needs to be configured to receive multicast packets. I don't
know what hardware you are using but usually they can be
In my IP6 implementation I did not do anything with the mld_mac_filter
parameter. It is just set to null in netif_add. FF02::1 is the all nodes
multicast group so I think by default you are already joined to that group.
The only thing I can think of that you haven't mentioned is to make sure you
It is possible you are experiencing the typical problem of multiple Ethernet
packets coming in but only getting one Ethernet interrupt. Each time you get
an Ethernet interrupt you want to make sure your RTOS task completely clears
out all packets. If all packets aren't cleared out they may sit
anet and see if that works.
PS: I'm using redpine modules too.
Cheers
Ivan
> Date: Tue, 9 Jul 2013 15:02:17 +
> From: Zach Smith
> To: Mailing list for lwIP users
> Subject: Re: [lwip-users] windows 7, IPv6, and WiFi
> Message-ID:
>
> om>
>
> Content-T
We've tried a PC that fails in the 1st topology and it works in the 2nd
topology.
We'll double check the addresses and stuff. I think you are right about
Wireshark is seeing the packet but the stack is not passing it on for some
reason but I can't figure out why.
-Zach
-Original Message--
Redpine Signals Connect-io-n modules
-Original Message-
From: lwip-users-bounces+zsmith=campbellsci@nongnu.org
[mailto:lwip-users-bounces+zsmith=campbellsci@nongnu.org] On Behalf Of Joe
Dupre
Sent: Monday, July 08, 2013 4:14 PM
To: Mailing list for lwIP users
Subject: Re: [lwip-u
ations, usually there is a
configuration issue that can be solved with iproute.
Cheers
Ivan
> Date: Fri, 5 Jul 2013 19:54:28 +
> From: Zach Smith
> To: "lwip-users@nongnu.org"
> Subject: [lwip-users] windows 7, IPv6, and WiFi
> Message-ID:
>
> <7db19
I am experiencing a problem that has me very confused and I wonder if anybody
has seen this or could suggest an idea.
My embedded device runs lwip and has been working great with IPv4. It uses a
WiFi module to handle raw Ethernet packets that I send it and I get raw
Ethernet from it. I updated
Looking at the Seq and Ack numbers, my guess is that your embedded controller
quit receiving for some reason. (problem in driver maybe???)
It's a little confusing since they are sending and receiving the same amount of
data back and forth to each other which makes the Seq#'s and Ack#'s the same
issues
Hey Zach,
Can you submit this issue, as well as the netif up/down issue, as bugs in
Savannah? That way I won't forget to look into it, and we can discuss it if
necessary.
Cheers
Ivan
> Date: Tue, 22 Jan 2013 22:47:59 +
> From: Zach Smith
> To: "lwip-users@non
I gather you are supposed to use netif_set_link_up()/down() when you have a
change in link status. So, I notice that from calling netif_set_link_up()
after getting a valid link status then DHCP Request messages go out and all
that is verified again. That is working well. But I am now wonderin
It seems to me that the current master version of nd6_input function has some
byte ordering problems.
For example, in nd6_input()
Line 439:
case ND6_OPTION_TYPE_MTU:
{
struct mtu_option * mtu_opt;
mtu_opt = (struct mtu_option *)buffer;
if (mtu_opt->mtu >= 1280)
What about the release candidate (1.5.0 rc)?
-Original Message-
From: lwip-users-bounces+zsmith=campbellsci@nongnu.org
[mailto:lwip-users-bounces+zsmith=campbellsci@nongnu.org] On Behalf Of Ivan
Delamer
Sent: Friday, January 18, 2013 11:12 AM
To: lwip-users@nongnu.org
Cc: chrysn
Yes, others have complained about the ST demo code. You might read through
this thread that talks about an issue you may be having:
http://lists.nongnu.org/archive/html/lwip-users/2012-09/msg00054.html
I'm guessing the demo code probably calls ethernetif_input() once every time an
Ethernet inte
wrote:
> Zach Smith wrote:
>
> > I am having a problem when I connect my IPv6 device running lwip to
> > a hub instead of a switch. [..] Since a hub forwards all packets
> > received onto all ports it is echoing my devices neighbor discovery
> > messages back.
&g
p-users] IP6 address autoconfig problem when using
> hub
> Message-ID: <73348cec-e18e-4555-87a7-605b90310...@gmx.de>
> Content-Type: text/plain; charset="us-ascii"
>
> Zach Smith wrote:
>
>> I am having a problem when I connect my IPv6 device running lwip
I am having a problem when I connect my IPv6 device running lwip to a hub
instead of a switch.
I have autoconfig enabled (LWIP_IPV6_AUTOCONFIG and
netif->ip6_autoconfig_enabled = 1) so the device will attempt to configure
itself with an IPv6 address. Once the device has chosen an IP6 address t
27 matches
Mail list logo
