Sylvain Rochet | 6 Mar 23:02 2015
Picon

New netif link_up/up behaviour and PPP

Hello Simon,

I wonder what should I do for the PPP netif interface about link up and 
up status now, do you have a clue ? :)

Sylvain
_______________________________________________
lwip-devel mailing list
lwip-devel <at> nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-devel
sandhya pochiraju | 6 Mar 01:18 2015
Picon

lwip gpio

hi all, 
I would like to do a project with microblaze and lwip. i have a atrix 7 based board. 
I am looking at this app note and have few questions. 

I would like to create a static web page which can ready switches and toggle leds. 

I know javascript and html but i do not know how to make them talk to gpios. 
my code must be able to read led value from gpio and write to gpio to toggle led. 

another question is - is there any recommended os to work with lwip. Does lwip work correctly with standalone os?

I would be grateful if there are any examples or tutorials on lwip and how to use it to talk to gpios. 

regards, 
sandy
_______________________________________________
lwip-devel mailing list
lwip-devel <at> nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-devel
Mohammad Hamad | 5 Mar 12:34 2015
Picon

SIOCGIFCONF support

Hi, 
I want to get list of my network interfaces such as the result of getifaddrs() and to implement this i think we need to use ioctl with SIOCGIFCONF , but this is not supported option in ioctl implementation yet. 

any one know how to start implement it , or if there is another way  to get all the network interface?

best,

_______________________________________________
lwip-devel mailing list
lwip-devel <at> nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-devel
Simon Goldschmidt | 4 Mar 22:11 2015
Picon

[task #13508] Implement IPv4 Address Conflict Detection

URL:
  <http://savannah.nongnu.org/task/?13508>

                 Summary: Implement IPv4 Address Conflict Detection
                 Project: lwIP - A Lightweight TCP/IP stack
            Submitted by: goldsimon
            Submitted on: Mi 04 Mär 2015 21:11:40 GMT
                Category: None
         Should Start On: Mi 04 Mär 2015 00:00:00 GMT
   Should be Finished on: Mi 04 Mär 2015 00:00:00 GMT
                Priority: 5 - Normal
                  Status: None
                 Privacy: Public
        Percent Complete: 0%
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any
         Planned Release: None
                  Effort: 0.00

    _______________________________________________________

Details:

See RFC 5227. We currently send one gratuitous ARP request only. 

This could be integrated into etharp.c.

ACD is e.g. required by Ethernet/IP, so not an Apple-only thing.

    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/task/?13508>

_______________________________________________
  Nachricht gesendet von/durch Savannah
  http://savannah.nongnu.org/

_______________________________________________
lwip-devel mailing list
lwip-devel <at> nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-devel
Simon Goldschmidt | 4 Mar 21:03 2015
Picon

[bug #41094] Byte-order bug in IPv6 fragmentation header test

Update of bug #41094 (project lwip):

                  Status:                    None => Fixed                  
             Assigned to:                    None => goldsimon              
             Open/Closed:                    Open => Closed                 

    _______________________________________________________

Follow-up Comment #1:

Fixed, thanks for reporting.

    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/bugs/?41094>

_______________________________________________
  Nachricht gesendet von/durch Savannah
  http://savannah.nongnu.org/
Ivan Delamer | 4 Mar 18:12 2015

Re: IPv6 L2TP PPP review

Hi Sylvain,

Ok, now I understand the scenario a bit better.

For neighbour discovery to work, you need to be subscribed to the 
solicited-node multicast address.

This is usually done automatically when you set the state to TENTATIVE.

If you set the address manually to PREFERRED, then you must join the 
multicast group manually:

ip6_addr_set_solicitednode(&multicast_address, netif_ip6_addr(netif, 
1)->addr[3]);
mld6_joingroup(netif_ip6_addr(netif, 1), &multicast_address);

This will allow ND multicast packets into the stack.

If you have a PPP link, I suspect ND is not used and you just send the 
packets to the neighbour, so in that case you wouldn't need this.

I believe your address is up and running correctly, it just isn't 
discoverable. But in PPP you don't do discovery.

Cheers
Ivan

> Date: Tue, 3 Mar 2015 22:01:33 +0100
> From: Sylvain Rochet <gradator <at> gradator.net>
> To: lwip-devel <lwip-devel <at> nongnu.org>
> Subject: Re: [lwip-devel] IPv6 L2TP PPP review
> Message-ID: <20150303210133.GA21857 <at> gradator.net>
> Content-Type: text/plain; charset="utf-8"
> 
> Hello Ivan,
> 
> 
> On Tue, Mar 03, 2015 at 10:25:30AM -0700, Ivan Delamer wrote:
>> 
>> The initial state you should set for your address depends on whether
>> you have DAD enabled or not.
>> 
>> If DAD is enabled (usual case), you should set it to
>> IP6_ADDR_TENTATIVE.
> 
> Doing that work.
> 
> 
>> If DAD is disabled, you should set it to IP6_ADDR_PREFERRED.
> 
> Doing that doesn't seem to work.
> 
> 
>> I think that in a PPP link DAD is actually not required, and
>> probably wouldn't work because it requires multicast support. So I
>> would set the state to IP6_ADDR_PREFERRED and it should work.
> 
> I forgot to tell, but this was on plain Ethernet.
> 
> I am using the following in ppp.c and it works fine:
> 
>   ip6_addr_copy(pcb->netif->ip6_addr[0], pcb->addrs.our6_ipaddr);
>   netif_ip6_addr_set_state(pcb->netif, 0, IP6_ADDR_PREFERRED);
> 
> IP6CP only negotiate a link local address, user is then responsible to
> configure use static addressing (or use DHCPv6).
> 
> 
> 
>> I'm not sure why IP6_ADDR_VALID wouldn't work, although generally
>> you want it to be either PREFERRED or DEPRECATED, which is VALID
>> with an extra flag.
>> 
>> What are you seeing that makes you say "it didn't work"?
> 
> On Linux host:
> 
> # ip -6 address add 2001::1/64 dev tap0
> 
> 
> Inside lwIP:
> 
> Netif is just the interface on the other side of tap0, nothing 
> complicated.
> 
> Dup detect enabled, using IP6_ADDR_TENTATIVE:
> 
>   netif.ip6_addr[1].addr[0] = PP_HTONL(0x20010000);
>   netif.ip6_addr[1].addr[1] = PP_HTONL(0x00000000);
>   netif.ip6_addr[1].addr[2] = PP_HTONL(0x00000000);
>   netif.ip6_addr[1].addr[3] = PP_HTONL(0x00000002);  /* 2001::2 */
>   netif_ip6_addr_set_state(&netif, 1, IP6_ADDR_TENTATIVE);
>   netif_create_ip6_linklocal_address(&netif, 1);
> 
> It works:
> 
> # ping6 -I tap0 fe80::0012:34ff:fe56:7800
> PING fe80::0012:34ff:fe56:7800(fe80::12:34ff:fe56:7800) from
> fe80::a034:6ff:fed1:d95c tap0: 56 data bytes
> 64 bytes from fe80::12:34ff:fe56:7800: icmp_seq=1 ttl=255 time=0.120 
> ms
> 
> $ ping6 2001::2
> PING 2001::2(2001::2) 56 data bytes
> 64 bytes from 2001::2: icmp_seq=1 ttl=255 time=0.134 ms
> 
> 
> 
> Dup detect disabled (or enabled, it doesn't change the result),
> IP6_ADDR_TENTATIVE disabled, interface forced VALID,PREFERRED:
> 
>   netif.ip6_addr[1].addr[0] = PP_HTONL(0x20010000);
>   netif.ip6_addr[1].addr[1] = PP_HTONL(0x00000000);
>   netif.ip6_addr[1].addr[2] = PP_HTONL(0x00000000);
>   netif.ip6_addr[1].addr[3] = PP_HTONL(0x00000002);
>   netif_ip6_addr_set_state(&netif, 1, IP6_ADDR_PREFERRED);
>   netif_create_ip6_linklocal_address(&netif, 1);
> 
> Link local is still working:
> 
> # ping6 -I tap0 fe80::0012:34ff:fe56:7800
> PING fe80::0012:34ff:fe56:7800(fe80::12:34ff:fe56:7800) from
> fe80::484:3bff:febd:d33f tap0: 56 data bytes
> 64 bytes from fe80::12:34ff:fe56:7800: icmp_seq=1 ttl=255 time=0.123 
> ms
> 
> Link global doesn't work:
> 
> $ ping6 2001::2
> PING 2001::2(2001::2) 56 data bytes
> From 2001::1 icmp_seq=1 Destination unreachable: Address unreachable
> 
> I am sending neighbor solicitation requests but I don't get any 
> answer:
> 
> # tcpdump -vvvv -i tap0 -n -p
> tcpdump: listening on tap0, link-type EN10MB (Ethernet), capture size
> 262144 bytes
> 21:58:07.782247 IP6 (hlim 255, next-header ICMPv6 (58) payload
> length: 32) 2001::1 > ff02::1:ff00:2: [icmp6 sum ok] ICMP6, neighbor
> solicitation, length 32, who has 2001::2
> 	  source link-address option (1), length 8 (1): 06:84:3b:bd:d3:3f
> 	    0x0000:  0684 3bbd d33f
> 21:58:08.782208 IP6 (hlim 255, next-header ICMPv6 (58) payload
> length: 32) fe80::484:3bff:febd:d33f > ff02::1:ff00:2: [icmp6 sum ok]
> ICMP6, neighbor solicitation, length 32, who has 2001::2
> 	  source link-address option (1), length 8 (1): 06:84:3b:bd:d3:3f
> 	    0x0000:  0684 3bbd d33f
> 21:58:09.782193 IP6 (hlim 255, next-header ICMPv6 (58) payload
> length: 32) 2001::1 > ff02::1:ff00:2: [icmp6 sum ok] ICMP6, neighbor
> solicitation, length 32, who has 2001::2
> 	  source link-address option (1), length 8 (1): 06:84:3b:bd:d3:3f
> 	    0x0000:  0684 3bbd d33f
> 
> 
> Cheers,
> Sylvain
Ivan Delamer | 3 Mar 18:25 2015

Re: IPv6 L2TP PPP review

Hi Sylvain,

> By the way, I struggled a little bit setting UP a static IPv6 global
> scope address and ended up with the following which I am not very 
> happy
> with:
> 
> netif.ip6_addr[1].addr[0] = PP_HTONL(0x20010000);
> netif.ip6_addr[1].addr[1] = PP_HTONL(0x00000000);
> netif.ip6_addr[1].addr[2] = PP_HTONL(0x00000000);
> netif.ip6_addr[1].addr[3] = PP_HTONL(0x00000002);
> netif_ip6_addr_set_state(&netif, 1, 
> IP6_ADDR_TENTATIVE|IP6_ADDR_PREFERRED);
> netif_create_ip6_linklocal_address(&netif, 1);
> 
> 
> Using IP6_ADDR_VALID instead of IP6_ADDR_TENTATIVE didn't work and I
> don't know why from looking at the source code, do you have a clue ?

The initial state you should set for your address depends on whether 
you have DAD enabled or not.

If DAD is enabled (usual case), you should set it to 
IP6_ADDR_TENTATIVE.

If DAD is disabled, you should set it to IP6_ADDR_PREFERRED.

I think that in a PPP link DAD is actually not required, and probably 
wouldn't work because it requires multicast support. So I would set the 
state to IP6_ADDR_PREFERRED and it should work.

I'm not sure why IP6_ADDR_VALID wouldn't work, although generally you 
want it to be either PREFERRED or DEPRECATED, which is VALID with an 
extra flag.

What are you seeing that makes you say "it didn't work"?

Cheers
Ivan

> Date: Mon, 2 Mar 2015 21:35:00 +0100
> From: Sylvain Rochet <gradator <at> gradator.net>
> To: lwip-devel <lwip-devel <at> nongnu.org>
> Subject: Re: [lwip-devel] IPv6 L2TP PPP review
> Message-ID: <20150302203500.GA11236 <at> gradator.net>
> Content-Type: text/plain; charset="utf-8"
> 
> Hello Ivan,
> 
> 
> On Mon, Mar 02, 2015 at 01:16:55PM -0700, Ivan Delamer wrote:
>> Hello Sylvain,
>> 
>> I think your code is correct. I use something very similar for UDP
>> connections, only using netconns.
> 
> Thank you :)
> 
> 
>> In general once you are working with UDP or TCP, it is really quite
>> similar for IPv4 or IPv6, because you are one layer over that. It is
>> just address binding/comparison that needs to be done appropriately.
>> 
>> The API is not completely safe and requires care from the programmer.
> 
> I saw that, there is casts everywhere meaning functions 
> calls/prototypes
> coherency is not checked at all.
> 
> 
>> I think we have it as a task to improve ipX_addr_t to include a
>> version field. We just wanted to initially implement IPv6 in a way
>> that was easy to turn it off, and the resulting stack was exactly
>> the same as the old IPv4-only stack. We will have to improve it
>> though...
> 
> I agree it is a bit disappointing, this is why I wasn't sure, I am 
> more
> used to sockaddr, sockaddr_in, sockaddr_in6, sockaddr_storage, 
> "russian
> dolls" structures.
> 
> 
> By the way, I struggled a little bit setting UP a static IPv6 global
> scope address and ended up with the following which I am not very 
> happy
> with:
> 
> netif.ip6_addr[1].addr[0] = PP_HTONL(0x20010000);
> netif.ip6_addr[1].addr[1] = PP_HTONL(0x00000000);
> netif.ip6_addr[1].addr[2] = PP_HTONL(0x00000000);
> netif.ip6_addr[1].addr[3] = PP_HTONL(0x00000002);
> netif_ip6_addr_set_state(&netif, 1, 
> IP6_ADDR_TENTATIVE|IP6_ADDR_PREFERRED);
> netif_create_ip6_linklocal_address(&netif, 1);
> 
> 
> Using IP6_ADDR_VALID instead of IP6_ADDR_TENTATIVE didn't work and I
> don't know why from looking at the source code, do you have a clue ?
> 
> 
> Cheers,
> Sylvain
Sylvain Rochet | 1 Mar 23:18 2015
Picon

IPv6 L2TP PPP review

Hello Ivan,

I just added link-level IPv6 support to L2TP PPP support (tunnel over UDPv6).

But I am not sure I did it right, I'm quite new to IPv6 in lwIP, could 
you check if what I did is right[1] ? :-)

I can't even check PPPoL2TPoIPv6 because none of the l2tpd I know are 
able to setup UDPv6 tunnels :(

Thank you very much.

Sylvain

[1] http://git.savannah.gnu.org/cgit/lwip.git/commit/?id=3ce6dd166c3c022a3549d95014a8abf8417ff9e8
_______________________________________________
lwip-devel mailing list
lwip-devel <at> nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-devel
ran | 1 Mar 15:55 2015
Picon

[bug #44399] receiving TCP Ack packet with Window Update

URL:
  <http://savannah.nongnu.org/bugs/?44399>

                 Summary: receiving TCP Ack packet with Window Update
                 Project: lwIP - A Lightweight TCP/IP stack
            Submitted by: rang
            Submitted on: Sun 01 Mar 2015 02:55:57 PM GMT
                Category: TCP
                Severity: 3 - Normal
              Item Group: Faulty Behaviour
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any
         Planned Release: 
            lwIP version: git head

    _______________________________________________________

Details:

hi
We have been playing a bit with the liwp library and might have found a bug.
When receiving an Ack TCP packet with the same seq and ack number as the
packet before but with a different window (wireshark identifies it as an
Update Window Packet).
In LWIP in tcp_in.c:tcp_receive we see that the code (head branch) checks if
the seq and ack are identical to the last received packet. If not (that is our
case) then there is only a print and the window size is not updated.
We believe that this might be a bug.
Thanks
Ran

    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/bugs/?44399>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.nongnu.org/
Ivan Delamer | 27 Feb 18:02 2015

Re: 1.5.0 coming nearer

This is awesome work Simon. I hope I can make progress on IPv6 soon. A 
release would be great.

Ivan

> Date: Thu, 26 Feb 2015 22:40:18 +0100
> From: "goldsimon <at> gmx.de" <goldsimon <at> gmx.de>
> To: lwip-devel <lwip-devel <at> nongnu.org>
> Subject: [lwip-devel] 1.5.0 coming nearer
> Message-ID: <54EF92C2.3080700 <at> gmx.de>
> Content-Type: text/plain; charset=utf-8; format=flowed
> 
> Hi all,
> 
> I just wanted to get this topic on the list again: as you might have
> noticed, I'm working my way through the bugs/tasks/patches lately. I'm
> getting nearer and nearer to the state where existing bugs are done
> (i.e. I hope to get to the point where only IPv6 bugs and new feature
> requests are open to not have a release with regressions).
> 
> Once that point is reached, a 1.5.0 beta will be released. Expect it 
> in
> the next months :-)
> 
> Thanks for everyone contributing in development! Especialy the recent
> quality of patches has been really helpful!
> 
> Cheers,
> Simon
goldsimon@gmx.de | 26 Feb 22:40 2015
Picon
Picon

1.5.0 coming nearer

Hi all,

I just wanted to get this topic on the list again: as you might have 
noticed, I'm working my way through the bugs/tasks/patches lately. I'm 
getting nearer and nearer to the state where existing bugs are done 
(i.e. I hope to get to the point where only IPv6 bugs and new feature 
requests are open to not have a release with regressions).

Once that point is reached, a 1.5.0 beta will be released. Expect it in 
the next months :-)

Thanks for everyone contributing in development! Especialy the recent 
quality of patches has been really helpful!

Cheers,
Simon

Gmane