Re: [lwip-users] lwip-users Digest, Vol 234, Issue 6

[Sylvain Rochet]

Hi Peter,

On Sat, Feb 25, 2023 at 05:53:40PM +, Peter wrote:
> 
> >Subject: [lwip-users] LwIP Project Question
> 
> Here is a sample lwipopts.h which I have spent made days or weeks on.
> It contains a lot of potentially useful comments.

No one should spend days or weeks on their lwipopts.h, embedded 
documentation in opt.h is pretty good IMHO and most options are self 
explanatory anyway.


> LWIP has been largely abandoned now. It is very good but it is now
> over 15 years old and most of the people working on it have moved on,
> so getting support is hard.

There is actually a reply from a lwIP developer to Phil's question, 
maybe you should revisit your assumption.

And please stop replying to the digest, it breaks mail threads and makes 
it hard to follow up.


Sylvain


signature.asc
Description: Digital signature
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] LwIP Project Question

[Sylvain Rochet]

Hi Phil,

On Fri, Feb 24, 2023 at 03:17:12PM -0500, Phil Cari wrote:
> Hi everyone,
> I have some trouble compiling the lwIP project and using it in my project
> because it seems that the lwipopts.h can not be found. Is there something
> that I miss or don't understand?
> Thank you in advance for your help!
> Respectfully,
> Philippe

lwipopts.h is your configuration file that overwrite default values to 
suit your needs. Default value can be seen in the src/include/lwip/opt.h 
file.

Some lwipopts.h examples are available in the contrib/ folder. It can 
probably be empty if all default values are fine for you.

Sylvain


signature.asc
Description: Digital signature
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] lwIP UDP echo server fails to send message lengths of 4385 & 4386

[Sylvain Rochet]

Hi Dan,

On Fri, Feb 03, 2023 at 02:57:24PM -0800, Dan Nygren wrote:
> Sylvain wrote > ... Anyway, basic rule about using fragmented IP packets:
> avoid (to not say
> don't).
> 
> Thank you for the advice Sylvain. My design is keeping its packets under
> the Ethernet 1500 octet MTU. I had made a diagnostic command to have my
> design send back arbitrarily sized messages to prove everything was working
> correctly when I ran into the 4385/4386 message size problem.

My best guess is a low level driver bug that happen when packets are 
sent in a short timeframe, which big UDP packets do due to IP 
fragmentation taking place. Sending small packets at a low rate does not 
fix the problem, it just hides it.

Sylvain


signature.asc
Description: Digital signature
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] lwIP UDP echo server fails to send message

[Sylvain Rochet]

Hi Peter,

On Sat, Feb 04, 2023 at 10:17:40AM +, Peter wrote:
> AFAIK there is no support forum or "community" for LWIP today. It is a
> project which was at its height about 15 years ago and the devs have
> generally moved on long ago.
> 
> This also means that if somebody develops a solution for something,
> they have nowhere to post it.
> 
> Googling digs up lots of old stuff, mostly pre-2011. There is also a
> lot of clickbait - sites which collate content from other sites.
> 
> I post questions all over the place (EEVBLOG, the ST forum) and
> occassionally somebody bites, or I find someone who replies privately.
> 
> I doubt LWIP has any obvious bugs after all these years but there is
> certainly some complex behaviour related to how much buffering has
> been allocated. Like that business of broadcast packets messing stuff
> up.

There is a reply from a lwIP developer in the digest below, maybe you
should revisit your assumption.

And please don't reply to the digest, it breaks threads and makes it 
impossible to follow up.

Sylvain


signature.asc
Description: Digital signature
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] lwIP UDP echo server fails to send message lengths of 4385 & 4386

[Sylvain Rochet]

Hi,

On Fri, Feb 03, 2023 at 01:24:48PM -0800, Dan Nygren wrote:
> Peter wrote:
> 
> > 4385/4386 could be 3x MTU ? ...
> 
> Peter, thanks for responding!
> Yes, it seems like I've hit some corner case.
> Is this the right place to notify the lwIP maintainers of problems? This is
> not a current problem for me as my messages are under the MTU size. I just
> hit this while developing some diagnostics for my board and I wanted to let
> others know about it.

This kind of issues set all red lights to full brightness about a low 
level driver issue or a buggy MAC offloader on fragmented IP packets.

Anyway, basic rule about using fragmented IP packets: avoid (to not say 
don't).

Sylvain


signature.asc
Description: Digital signature
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] PPP LCP echo interval u8

[Sylvain Rochet]

Hi Nikolas,

On Mon, Oct 10, 2022 at 04:17:11AM +, Nikolas Karakotas wrote:
> Hi,
> 
> Is there a reason why the LCP echo data type size is u8?

Yes, memory footprint. I am not against changing it but at first I would 
like to understand why an LCP echo interval over 255 seconds would be 
necessary.


> In Iot devices the transmission interval can be high from 5 minutes to 
> an hour + or event driven.
> 
> Wouldn't it be more flexible if this was a u16 to allow for a larger 
> echo interval to be set?

I guess you are using a cellular modem with PPP. In this case LCP 
packets are not sent over the air and LCP echo probes are only used as a 
serial link check between the MCU and the modem. Cellular modems being 
all buggy as hell this serial link check does not do a true check that 
the modem is still alive as the RF part can be in a dead end but not the 
serial part, making the check unreliable.

It would make much more sense to me to disable LCP echo at all by 
setting lcp_echo_interval to 0 instead of setting it to more than 5 
minutes or even hours.

Also, PPP can be attached and detached ("reconnected" and 
"disconnected") without changing the RF state. On cellular modems, RF 
state is managed through AT commands (AT+CGDCONT, AT+CGACT, …).

Sylvain


signature.asc
Description: Digital signature
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] how to use netif_find() correctly

[Sylvain Rochet]

Hi Massimiliano,

On Wed, Jan 26, 2022 at 04:28:54PM +0100, Massimiliano Cialdi wrote:
> hello
> 
> I must have the *netif given its name. I used the netif_find() function,
> but got an assert:
> "Function called without core lock".
> Among netif functions there is no wrapper for netif_find().
> What is the correct way to proceed?
> 
> should i write my own wrapper, in one of my files, copying from a netifapi
> function? Or should I use the locks? And how should I do that?

With LWIP_TCPIP_CORE_LOCKING enabled:

LOCK_TCPIP_CORE();
netif_find();
UNLOCK_TCPIP_CORE();

Sylvain


signature.asc
Description: Digital signature
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] PPP shared Internet

[Sylvain Rochet]

Hi Richard,

On Mon, Jan 17, 2022 at 11:53:32AM +, Richard Bailey wrote:
> Hi,
> 
> I am working on an IoT solution. I've bumped into an issue around 
> using LWIP. If I describe the scenario and what I'm trying to achieve, 
> perhaps you can tell me if what I'm trying to do is in theory is 
> possible or if I need to approach it another way.
> 
> It has a main NXP PCB, with a Microsoft Azure Sphere, secure Wi-Fi 
> module attached. The Azure Sphere is a bit of a black box, but it 
> handles communication to Microsoft's Azure Servers over Wi-Fi. It can 
> also work over Ethernet, but it will not have a physical Ethernet Port 
> on the device. There will be scenarios where Wi-Fi is not an option, 
> so we need a backup solution.
> 
> The main NXP PCB has a BG95 modem.
> It has an internal circuit-based Ethernet connection between the NXP 
> and the Azure Sphere module. The plan is for the Azure Sphere module 
> to communicate out over the BG95 modem via the internal Ethernet.
> 
> The main NXP PCB is running FreeRtos, with LWIP 2.1.3.
> I was hoping to simply set up two NetIf adaptors:
>  * PPPOS for the modem, with the Internet connection
>  * Ethernet.
>  Then enable IP_FORWARD.

IP forwarding between PPP and Ethernet works and a custom IPv4 routing 
table can be added by using LWIP_HOOK_IP4_ROUTE.


> Would that approach work allowing the Azure Sphere to communicate with 
> the outside world, over the internal Ethernet and forwarding to the 
> PPP modem (in both directions)?

It depends if IP forwarding is enough for you. Beware that IP forwarding 
is IP routing, not NAT.


> 
> The information contained in this communication, and any attachments, 
> may be confidential and/or privileged. It is intended only for the use 
> of the named recipient.
> 
> If you are not the intended recipient please contact us.
> Tel: +44 (0)1256 768070
> Fax: +44 (0)1256 760718
> Email: postmas...@sti-limited.com.
> 
> In such an event you should not access any attachments, nor should you 
> disclose the contents of this communication or any attachments to any 
> other person, nor copy, print, store or use the same in any manner 
> whatsoever.
> 
> Thank you for your co-operation.

What should I do with that ?


Sylvain


signature.asc
Description: Digital signature
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Expected behavior of linkoutput()?

[Sylvain Rochet]

Hi,

On Wed, Jan 12, 2022 at 04:39:30PM -, Grant Edwards wrote:
> What is the expected behavior of the netif linkoutput() function?
> 
> Specificallyy, is it expected to
> 
>  1) Block until the packet has been sent?
> 
> or
> 
>  2) Place the packet in a TX queue/fifo and return immediately?
> 
> All of the Ethernet drivers I've worked on for other RTOSes in the
> past couple decades expected 2), since the output function might be
> called from a context that can not block. If the tx fifo/queue was
> full, an error was returned. In either case the output function always
> returned immediately.
> 
> I'm currently looking at a blob of code that acts both as an Ethernet
> driver for lwIP as well as implements a set of industrial protocols
> "under the covers" without lwIP being aware of that traffic. The plan
> is to remove the industrial protocl stuff and convert it into a
> "normal" lwIP driver.
> 
> That blob of code does 1) above. There is no TX packet queue/fifo at
> all. the linkoutput() function copies the frame into the MAC, starts
> transmission, and then blocks until transmission is complete. That
> means that linkoutput must always be called from a normal OS thread
> context.
> 
> Is this blocking, non-queueing approach the normal way implement
> linkoutput() for lwIP?

Actually, it should do both. Place the packet in the TX queue and return 
immediately, BUT if the queue is full it should wait for a free slot.

Sylvain


signature.asc
Description: Digital signature
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] lwip IPV6 PPP only get link local address and cannot connect to server

[Sylvain Rochet]

Hi,

On Thu, Nov 11, 2021 at 10:40:09AM +1100, Jiang Peng wrote:
> Hi everyone,
> I have a project that is running LwIP V2.1.2. The stack is LwIP on top of
> BG96 cellular modem.
> It works fine for IPV4, but when I enable IPV6, I only get IPV6 link local
> address, and cannot get real IPV6 address, therefore, I cannot connect to
> my server.
> The LwIP comes from ST cellular expansion package.
> I enable the log, and it got local and remote LL address, but after that
> never got any real address, and cannot connect to my server.
> thanks a lot for any hints or suggestions.

This is normal. You need to run IPv6 NDP, DHCPv6 or static 
configuration, depending on what your peer is using, over the PPP link.

Sylvain


signature.asc
Description: Digital signature
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] lwip with 4G modem

[Sylvain Rochet]

Hi Giuseppe,

On Tue, Oct 12, 2021 at 09:26:00AM +0200, Giuseppe Modugno wrote:
> I have an embedded project where lwip is used in a microcontroller
> (Cortex-M3 by LPC). The network interface is a standard Ethernet. The MCU
> features a MMI interface with an external Ethernet PHY.
> 
> It works well, I'm able to open a MQTTs connection with a broker, enable NTP
> request, download some file from HTTP server.
> 
> Now I'd like to use this project as a base for a new project, where the
> network interface will be replaced by a 4G modem that is controlled by
> standard AT commands.
> 
> My question is: what should I change in my project to replace Ethernet with
> 4G modem? I think I have to use ppp over a serial line to open a 4G data
> connection and it seems ppp is supported by lwip distribution.

Yes, you need to use PPPoS(erial).

You have to setup your modem to enter PPP data mode then read/write 
HDLC/PPP bytestreams from/to the modem and lwIP.


> Another question (I don't know if it is OT), will I be able to make voice
> calls at the same time the data connection is open and active?

This is not related to lwIP, check your modem documentation ;-)


> The serial channel for ppp/data and AT commands is single, so how can 
> I multiplex them? Should I use CMUX?

CMUX is the proper way to do so.


> Last question. If I have 4G modem and Ethernet PHY, is lwip able to manage
> two network interface at the same time?

Yes! Beware of routing though, you will probably have to set the default 
interface to the currently "working" interface and have to re-establish 
all currently active TCP/UDP sessions on routing change.


Sylvain


signature.asc
Description: Digital signature
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] lwip with 4G modem

[Sylvain Rochet]

Hi,

On Tue, Oct 12, 2021 at 11:29:46AM +0200, Gisle Vanem wrote:
> Giuseppe Modugno wrote:
> 
> >The serial channel for ppp/data and AT commands is single, so how can I 
> >multiplex them? Should I use CMUX?
> 
> The PPP protocol handles this multiplexing itself. Using an
> escape octet "stuffing procedure" (octet 0x7d).
> Read 'https://datatracker.ietf.org/doc/html/rfc1662' for the gory
> details.

I doubt most cellular modems support that. CMUX support (GSM 07.10) is 
more common.

Sylvain


signature.asc
Description: Digital signature
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] [EXTERNAL] Re: LWIP Dual Stack - IPv4 and IPv6

[Sylvain Rochet]

Hi Edman,

On Fri, Jul 16, 2021 at 01:46:34PM +, Zayzay, Edman G wrote:
> Hi Sylvain,
> 
> I did increase MEMP_NUM_SYS_TIMEOUT to 20 and call 
> sys_check_timeouts() periodically in since I am running without an OS 
> and it still doesn't resolve the issue.

Are you sure timers are actually working at all ?

Sylvain


signature.asc
Description: Digital signature
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] LWIP Dual Stack - IPv4 and IPv6

[Sylvain Rochet]

Hi Edman,

On Thu, Jul 15, 2021 at 04:24:29PM +, Zayzay, Edman G wrote:
> Hi,
> 
> I am running LwiP 2.1.2 and have been able to successfully run IPv4 
> and IPv6 individually with PPPoS. However, whenever I enable both IPv4 
> and IPv6 on PPPoS, I am seeing only the IPV6CP ConfigReq is being 
> responded to. I do not see one IPCP ConfigReq goes out and nothing is 
> sent. I tested on the Linux and saw the Linux is sending multiple IPCP 
> ConfigReq during negotiation until the modem respond to both IPCP and 
> IPv6CP ConfigReq. My FSM_TIMEOUT is set to the default 6 seconds. When 
> the PPPoS negotiation completes, I see the IPv6 address assigned but 
> nothing is assigned for IPv4. I view of the above, Is there a way I 
> can ensure that LWip continues to send the IPCP ConfigReq until the 
> modem respond so that both IPv4 and IPv6 address are assigned?
> 
> Please see below a snippet of the debug output

That is strange, you should see IPCP retries at least, could you try 
adding more timers by setting a large value to MEMP_NUM_SYS_TIMEOUT ?

Sylvain


signature.asc
Description: Digital signature
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] pppos sent packets optionally start with 0x7e, why?

[Sylvain Rochet]

Hi,

On Mon, Jun 07, 2021 at 04:19:45PM +0200, Bas Prins wrote:
> Dear,
> 
> I was looking at the data being sent/received over uart when ppp is being
> negotiated. I was surprised to see that the received byte stream is always
> wrapped in 0x7e bytes (leading + trailing).
> 
> But for some reason this is not the case for the bytes lwip sends
> (/provides to my sio_write function). Even stronger, sometimes it does
> start with a leading 0x7e, sometimes it doesn't.
> 
> On the wiki I read:
> 
> "PPP packets all start and end with 0x7E. If you don't see these, something
> is wrong with your low level driver"

This is not wrong per se, but added to that the end of a frame can also 
be the start of the next frame. That is, the following sequence are two 
valid frames:

0x7e  0x7e  0x7e

What is also usually done is to prepend a 0x7e if the serial link as 
been idle for a while to clear any received noise. We do so in lwIP.


> When I look at fsm.c where the PPP header is created, I don't see 0x7e
> being added as part of the opening header.

HDLC flags and byte stuffing are processed in pppos.c. You are mixing up 
PPP and HDLC but I agree the border between them is blurry ! :)


> pppos works, lwip works, I can open sockets, download from FTP, etc. So
> what's the deal with this? Should I investigate further and is there a bug
> sitting in my code? Or is this "perfectly normal" behavior and is the wiki
> wrong?

This is normal!


Sylvain


signature.asc
Description: Digital signature
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] bind with link down

[Sylvain Rochet]

rHi Massimiliano,

On Fri, Apr 03, 2020 at 12:40:43AM +0200, Massimiliano Cialdi wrote:
> On Thu, Apr 2, 2020 at 11:25 PM Sylvain Rochet  wrote:
> > "ip link set  up/down" is interface administrative state.
> >
> > Link state is whether the cable is plugged or unplugged, i.e. "ethtool"
> > for linux equivalent.
> This answer confuses me.
> 
> I tried: on linux the link state and the admin state *are* related to
> each other.

I don't agree, administrative state is always UP in your example:


> with the cable connected both ip and ethtool report the states up
> max@jarvis:~$ ip link show enx0050b6e9a99e && ethtool enx0050b6e9a99e | tail 
> -n2
> 5: enx0050b6e9a99e:  mtu 1500 qdisc
   ^^ 
 administrative statelink state


> fq_codel state UP mode DEFAULT group default qlen 1000
> link/ether 00:50:b6:e9:a9:9e brd ff:ff:ff:ff:ff:ff
> Cannot get wake-on-lan settings: Operation not permitted
>drv probe link
> Link detected: yes
> 
> and even with the cable disconnected they both say down:
> max@jarvis:~$ ip link show enx0050b6e9a99e && ethtool enx0050b6e9a99e | tail 
> -n2
> 5: enx0050b6e9a99e:  mtu 1500 qdisc
   ^^ ^^
link state  administrative state


> fq_codel state DOWN mode DEFAULT group default qlen 1000
> link/ether 00:50:b6:e9:a9:9e brd ff:ff:ff:ff:ff:ff
> Cannot get wake-on-lan settings: Operation not permitted
>drv probe link
> Link detected: no
> 
> but you said:
> > "Admin state" is "netif_set_up()".
> >
> > > How should the admin state be affected by the link state?
> > Not at all. Just call "netif_set_link_up()" or down when you found out a
> > state change. Leave "netif_set_up()" as it is.
> From this I understand that the links state and admin state are not
> related. I may have (and you say so) links down but admin state up.
> Tell me if I understand correctly.

They are not related at all.

netif_set_up() and netif_set_down() is a software switch telling the 
lwIP stack if you want the interface to be active or silent. If you 
don't need to disable an interface at runtime (with only one interface, 
you never need that!), you only have to call netif_set_up() once at 
init.

netif_set_link_up() and netif_set_link_down() may be called when cable 
is plugged or unplugged. Calling netif_set_link_down() then 
netif_set_link_up() is optional and only meant to speed up DHCP recover, 
IPv6 discovery, or such. If you don't care about speeding up things on 
cable connection you only have to call netif_set_link_up() once at init.


> So I find myself forced to ask you the question again: on linux how
> can I have admin state up and link down?

You only have to unplug the cable to do so :-)


> the last thing: you say that "ip link set  up/down" is interface
> administrative state.
> But if I force down the "admin state" with the cable connected, both
> ip and ethtool tell me the link is down. And once again, that seems
> contrary to what you say (link and admin state are not related).

This is because Linux power down the network interface when you set it 
administratively down, effectively removing the carrier signal.
 

Sylvain


signature.asc
Description: Digital signature
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] bind with link down

[Sylvain Rochet]

Hi Massimiliano,

On Thu, Apr 02, 2020 at 11:17:36PM +0200, Massimiliano Cialdi wrote:
> On Thu, Apr 2, 2020 at 8:33 PM goldsi...@gmx.de  wrote:
> > "Admin state" is "netif_set_up()".
> >
> > > How should the admin state be affected by the link state?
> > Not at all. Just call "netif_set_link_up()" or down when you found out a
> > state change. Leave "netif_set_up()" as it is.
> what's the linux equivalent of 'admin state'? Which command could be
> used to change it? This might help me figure out what admin state is
> and what admin state is for.
> I only know
> ip link set  up/down
> This should be the equivalent of netif_set_link_up()/netif_set_link_down()

"ip link set  up/down" is interface administrative state.

Link state is whether the cable is plugged or unplugged, i.e. "ethtool" 
for linux equivalent.

Sylvain


signature.asc
Description: Digital signature
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Receiving UDP (DNS) over PPPoS, source and destination ports same?

[Sylvain Rochet]

Hi Andrew,

On Thu, Feb 13, 2020 at 09:29:39PM -0800, Andrew Pullin wrote:
> I am having a little issue with lwip on ESP32 here.
> 
> I am using a PPP (over serial) link to get two IP stacks to communicate. And
> then later doing some source routing and other stuff, but this issue
> manifests far before that, upon reception of a packet from the PPP netif:
> UDP packets are showing up with the source and destination port the same.
> 
> Early in `ip4_input`, I added a check for IP_PROTO_UDP to grab the UDP
> header and then read out the src and dest ports, and I am seeing that both
> are the same for PPP input. e.g. for a DNS request, I see both are 53.
> 
> This seems incorrect. Or maybe there is something I am overlooking?

Nothing prevent a DNS request to use the same port as source and 
destination. It's bad for security (DNS poisoning) but it is technically 
correct to do so.

A correct NAT implementation should randomise the source port if there 
is a conflict with a previously established tracked session (same dest, 
same source port, from two differents NATed hosts).

Sylvain


signature.asc
Description: Digital signature
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] IP forwarding to/from PPP working for one netif, but not another

[Sylvain Rochet]

Hi Andrew,

On Tue, Feb 11, 2020 at 11:47:04AM +0100, goldsi...@gmx.de wrote:
> Am 11.02.2020 um 10:20 schrieb Andrew Pullin:
> > [..]
> > 
> > The part that I am stuck on presently is that Host2 has no knowledge of 
> > how to route packets from PPP out to the WAN, say, 8.8.8.8.
> > Between ip4_forward, IP_FORWARD, ip4_route_src, LWIP_HOOK_IP4_ROUTE, 
> > LWIP_HOOK_IP4_ROUTE_SRC, and the ESP32 port modifications, I am not 
> > quite sure where to make the right intervention. It is ... a lot to take in.
> > 
> > As far as I understand the standard usage of the stack for a single 
> > netif, outgoing packets elide the entire forwarding/routing system 
> > because they are specified to be transmitted on a particular netif? Is 
> > that right?
> > 
> > Fundamentally, I only have eth0 and pp1  (to use the lwip netif naming 
> > system) and anything not specifically with IP dest = eth0 or pp1 should 
> > be sent on towards Host2's gateway (after NAT source address IP rewriting).
> > Is that logically complete, and if so, where should it be implemented?
> 
> I would think you'd just set the ppp netif as default netif (so it is
> just used for all outgoing trafic where no better route is found) and
> keep eth0 without a gateway (which should ensure only matching subnet
> packets are transmitted on this netif).

Yes, but the default netif (default route) must be set on eth0, not pp1 :)

Sylvain


signature.asc
Description: Digital signature
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] R: Re: Unable to connect to HTTP server using PPP

[Sylvain Rochet]

Hi Renato,

On Fri, Feb 07, 2020 at 10:00:00AM -0300, Renato Barresi wrote:
> [...]
> pppos_input[0]: Dropping bad fcs 0x85ae proto=0x21
> [...]
> pppos_input[0]: Dropping bad fcs 0xb7ce proto=0x4

You serial low level driver does not seem to work properly. Probably 
both Tx and Rx are affected by data corruption.

Sylvain


signature.asc
Description: Digital signature
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] PPP_STATS_SUPPORT

[Sylvain Rochet]

Hi Danish,

On Thu, Feb 06, 2020 at 10:30:31AM +, Danish Ali wrote:
> I have LWIP 2.1.2 running using PPPOS through a 4G modem.
> 
> I now want to route the PPPOS via CMUX mode so that I can receive SMS
> messages while leaving the PPP link up.
> 
> Although this largely works, I find it less reliable than without the CMUX
> wrapper, so I thought I might check if the PPP layer was rejecting anything
> as garbled.
> 
> Looking through ppp.h and ppp.c it seems there is an option
> PPP_STATS_SUPPORT which would collect statistics on the link. But if I
> #define PPP_STATS_SUPPORT 1 in lwipopts.h then compilation fails in ipcp.c
> with the error
> > netif/ppp/ipcp.c:2096:23: error: 'fsm' {aka 'struct fsm'} has no member
> named 'unit'
> > netif/ppp/ipcp.c:2129:24: error: 'fsm' {aka 'struct fsm'} has no member
> named 'unit'
> 
> The offending lines are
> >#if PPP_STATS_SUPPORT
> >reset_link_stats(f->unit);
> >#endif /* PPP_STATS_SUPPORT */
> 
> >#if PPP_STATS_SUPPORT
> >/* XXX a bit IPv4-centric here, we only need to get the stats
> > * before the interface is marked down. */
> >/* XXX more correct: we must get the stats before running the notifiers,
> > * at least for the radius plugin */
> >update_link_stats(f->unit);
> >#endif /* PPP_STATS_SUPPORT */
> 
> Do you have any suggestions as to how I could either fix this or use an
> alternative way to monitor the PPP process.

PPP_STATS_SUPPORT is a leftover from pppd, it is not meant to be 
enabled. Use LINK_STATS instead.

Best, enable PPP_DEBUG + PRINTPKT_SUPPORT (+ PPP_PROTOCOLNAME) and you 
will get a trace with PPPoS input errors (FCS checks, ...).

Sylvain


signature.asc
Description: Digital signature
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Unable to connect to HTTP server using PPP

[Sylvain Rochet]

Hi Renato,

On Mon, Feb 03, 2020 at 03:26:54PM -0300, Renato Barresi wrote:
> 
> #define VJ_SUPPORT  1

Could you try disabling VJ support ? It is known to be broken.

Once this is done, if you still have any issue, please sent the PPP 
debug trace. PPP_DEBUG + PRINTPKT_SUPPORT (+ PPP_PROTOCOLNAME) enabled.

Sylvain


signature.asc
Description: Digital signature
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] IP forwarding to/from PPP working for one netif, but not another

[Sylvain Rochet]

Hi Simon,

On Thu, Jan 30, 2020 at 10:11:23PM +0100, goldsi...@gmx.de wrote:
> 
> Well, yes, my bad. The question wasn't phrased well. The thing I don't
> understand (because I'm not using it) probably all boils down to using
> lwIP as a PPP 'proxy' to remote networks without doing NAT at the same
> time (which we don't support in mainline). That's not standard routing...

Or the contrary, that's standard IP routing, it's just totally useless 
with residential ISPs because most don't allow customers to add route 
entries on their gateway so it's just a flat subnet with no routing 
capability. Business ISPs usually offer the option, it's very common for 
business customers to have a delegated subnet that's properly routable.

Sylvain


signature.asc
Description: Digital signature
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] IP forwarding to/from PPP working for one netif, but not another

[Sylvain Rochet]

Hi Andrew,

On Fri, Jan 31, 2020 at 12:11:56AM -0800, Andrew Pullin wrote:
> On 1/30/20 11:42 AM, Sylvain Rochet wrote:
> > 
> > 10.0.0.1/32 and 10.0.0.2/32 are within 10.0.0.0/16 subnet, that
> > shouldn't be a problem here, this is usually a bad practice and it
> > should be avoided. This is a problem for hosts on 10.0.0.0/16 that don't
> > know there is a hole in the subnet, since there are only 3 hosts here,
> > which is an expection rather than the rule, it is safe by luck.
> 
> This seems relatively easy to fix: I can just change the PPP-negotiated IP's
> to 11.0.0.0/32, so the host1 and host2 devices are on a different subnet on
> the PPP side.

11.0.0.0/32 is outside RFC1918 private subnets, using it sounds like a 
bad idea.


> As for the /32, I am unsure if I need to change that. Do I?

The netmask is only meaningful for layer 2 with a broadcast domain (e.g. 
Ethernet), PPP is point to point, there is only one peer, netmask as no 
meaning.

(To be fair that's not entirely true, it use to be used for PPP to 
provide more than one IPv4 addresses to customers, but I don't think 
it's still used in the wild, and it's still not a broadcast domain, it's 
just a pool of addresses.)


> Darn. I saw some code for "UNUSED - PROXY ARP", but it was all removed with
> #if 0 blocks.

You are lost in the wrong place ;-), ARP Proxy support have to live in 
the Ethernet ARP driver, and that support does not exist. What you saw 
is just PPP support to add a Proxy ARP rule into the Ethernet driver 
(basically no more than one function call :-), it is not the ARP Proxy 
support.


> Here is where I am starting to get worried about how I am possibly going
> make this solution work.
> I am trying to, in general, get my host1 device connected to the outside
> world via host2's connection to host3.
> 
> The motivation for doing this via IP stacks is because my host1 (PPP client)
> already has a ton of code implemented using TCP/IP; host1 is a piece of
> hardware that used to have its own MAC/PHY, but is now being repurposed.
> Being able to re-use all of that code without having to remap every function
> at a high-level to some other mechanism (say, AT commands, also needing
> host2 implementations) will be a huge boon.
> 
> My knowledge here is clearly limited, but is there a general or dynamic way
> to set up the routes I would need here?
> 
> Since I want to be able to attach host2 to any existing network and have
> this system work, I think this is what I would need.
> 
> I do not know how host2/B could pass the information needed to host1/A to
> configure the next hop route, or "172.16.1.0/24 via 192.168.0.2" in your
> example. This seems like it would require a mechanism for host2/B to
> disclose to host1/A what IP address it gets (say, via DHCP) on it's eth0
> side.

It exists… it's called OSPF… but… erm… don't expect that to be available 
behind a set-top box or whatever "gateway/router" used by ISP.

I'm running OSPF at home but I'm not the regular ISP customer :-)


> Or how host3/C could be configured for routing a subnet (now 
> 11.0.0.0/32) that is essentially "private" between host2/B and 
> host1/A. That is the "192.168.0.0/24 via 172.16.1.1" route in your 
> example, or "11.0.0.0/32 via 10.0.0.016" in my case.
> 
> It seems like what I actually do want is NAT capability on host2, so 
> that the host1<->host2 connection would be abstracted away. But it 
> looks like there are only a few few-years-old implementations of NAT 
> for lwip. Uh oh. I would really like to avoid trying to integrate that 
> in from an old branch of lwip.
> 
> Any idea if I can get this to work without needing to try to bring up 
> NAT?

It it were me and if I don't need Host2 to reach "outside" and Host1 
software can't be changed, I would just write a big hack to forward 
relevant packets (e.g. no DHCP, no ARP, IP) to the PPP link, pushing the 
DHCP assigned address to the PPP peer Host1 so NAT is not necessary at 
all and nothing have to be done for Host1 to send packets to "outside".

And if it were me and if I need Host2 to reach "outside" and Host1 
software can't be changed, I would write a quick'n'dirty ARP Proxy 
support, probably at the Ethernet low level driver. Note, in this case, 
it is normal for the PPP link to be within the Host2/Host3 subnet, it is 
actually mandatory. But doing so won't work if you need DHCP support 
because you need DHCP server to offer two addresses (one for Host2, one 
for Host1), so you need two MAC addresses and two DHCP clients running. 
It's way more difficult than just hacking the forwarding and sharing the 
same address.

But, above all, if it were me, I would just write a TCP or UDP proxy on 
Host2. Host1 would then only 

Re: [lwip-users] IP forwarding to/from PPP working for one netif, but not another

[Sylvain Rochet]

Hi Simon,

On Thu, Jan 30, 2020 at 09:31:11PM +0100, goldsi...@gmx.de wrote:
> Am 30.01.2020 um 20:42 schrieb Sylvain Rochet:
> > On Wed, Jan 29, 2020 at 08:15:11PM -0800, Andrew Pullin wrote:
> > > 
> > > Host2:
> > >     - Micontroller device, ESP32
> > >     - has both WiFi and Ethernet PHY hardware (IP101GRI Ethernet PHY), 
> > > used
> > >mutually exclusively
> > >     - Running lwIP
> > >     - WiFi and Ethernet are independently verified to work to reach WAN 
> > > from
> > >this host
> > >     - PPPoS server
> > >     - ppp0 : 10.0.0.1/32
> > >         - IP for server and client are hard-coded in
> > >         - I believe it is /32, as the netmask is reported as 
> > > 255.255.255.255
> > >     - When running w/ WiFi:
> > >         - wlan0 : ip 10.0.200.136/16  (IP and /16 from DHCP server)
> > >     - When running w/ Ethernet:
> > >         - eth0 : ip 10.0.200.113/16  (IP and /16 from DHCP server)
> 
> One odd thing I find here is that lwIP does not support 2 interfaces in
> the same subnet. So you would have to take care that only one netif at a
> time has its link set up (or its address set or its administrative
> status up, or whatever). In any case, having both wlan0 and eth0 up and
> running with an address in the same subnet will result in packets being
> accepted on both netifs but transmitted on whichever was registered last
> (or was it first?).

I assumed that both were not active at the same time, good catch, this 
might be an issue as well.


> > This is not "connection sharing", this is IP routing, not NAT !,
> > "connection sharing" is usually used for hosts that do SNAT on their
> > Interface facing Internet.
> >
> > IP routing needs a complete routing table on all hosts telling how to
> > reach (i.e. which next-hop to use) every host of the whole network.
> >
> > Example with 2 subnets and 3 Hosts:
> >
> > A-eth0  - eth0-B-eth1 - eth0-C
> >192.168.0.1/24192.168.0.2/24   172.16.1.1/24 172.16.1.2/24
> >
> > Host A routing table:
> > 192.168.0.0/24 dev eth0
> > 172.16.1.0/24 via 192.168.0.2
> >
> > Host B routing table:
> > 192.168.0.0/24 dev eth0
> > 172.16.1.0/24 dev eth1
> >
> > Host C routing table:
> > 192.168.0.0/24 via 172.16.1.1
> > 172.16.1.0/24 dev eth0
> >
> > dev = directly connected
> > via = next-hop, gateway if you prefer
> >
> > What you could see is that each host have a similar routing table, just
> > the next-hop changes. Default route is just a way to reduce the routing
> > table size by removing all entries that have an identical next-hop.
> 
> Which brings me to a question: how do we define such routing rules in
> lwIP? Hmm...

I'm surprised by the question :-) In lwIP, "dev" rules don't need to be 
added, the ip4_route function "create" them dynamically using the 
interface address/netmask.

But thanks you for asking that because there is a huge issue about 
that with the aforementioned case. Since "dev" rules are not ordered 
because we just foreach on interfaces list until a match, we don't 
respect that smaller subnets should be checked and matched first. So if 
an IP subnet is within the IP subnet of another interface, although 
perfectly legal configuration but *bad* design, it does not work in 
lwIP. In lwIP it actually depends on the order interfaces were added :-)

For "via" routes, we have LWIP_HOOK_IP4_ROUTE.

Sylvain


signature.asc
Description: Digital signature
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] IP forwarding to/from PPP working for one netif, but not another

[Sylvain Rochet]

Hi Andrew,

On Wed, Jan 29, 2020 at 08:15:11PM -0800, Andrew Pullin wrote:
> 
> Uh-oh, I think I did a poor job of explaining it. Although you seem to have
> surmised most of it.
> 
> The full rundown:
> 
> Host1:
>     - Micontroller device with no MAC or PHY
>     - running NetX IP stack
>     - Runs a PPP client, specifically PPPoS using TTL UART
>     - default route: ppp0
>     - ppp0 is the only network interface available
>     - ARP is supported and enabled
>     - IP 10.0.0.2 is assigned during PPP negotiation

There are no ARP in PPP, but whatever, this configuration is correct.


> Host2:
>     - Micontroller device, ESP32
>     - has both WiFi and Ethernet PHY hardware (IP101GRI Ethernet PHY), used
> mutually exclusively
>     - Running lwIP
>     - WiFi and Ethernet are independently verified to work to reach WAN from
> this host
>     - PPPoS server
>     - ppp0 : 10.0.0.1/32
>         - IP for server and client are hard-coded in
>         - I believe it is /32, as the netmask is reported as 255.255.255.255
>     - When running w/ WiFi:
>         - wlan0 : ip 10.0.200.136/16  (IP and /16 from DHCP server)
>     - When running w/ Ethernet:
>         - eth0 : ip 10.0.200.113/16  (IP and /16 from DHCP server)
>     - Routing is unknown. lwIP built with IP_FORWARD enabled.
>     - default route: wlan0 or eth0 (assumed)
>     - ARP is enabled.

10.0.0.1/32 and 10.0.0.2/32 are within 10.0.0.0/16 subnet, that 
shouldn't be a problem here, this is usually a bad practice and it 
should be avoided. This is a problem for hosts on 10.0.0.0/16 that don't 
know there is a hole in the subnet, since there are only 3 hosts here, 
which is an expection rather than the rule, it is safe by luck.


> WiFi AP's:
>     - AP only (no routing)
>     - Connected to Host3 by Ethernet
>     - MACs 0c:8d:db:6e:f0:03 or 0c:8d:db:6e:f0:88 (can't control
> association)
> 
> Host3:
>     - Router (pfSense)
>     - DHCP server runs here
>     - Routes to WAN, does NAT, eth0 <-> eth1
>     - default route: set by DHCP, toward eth1
>     - no other route (as far as I know)
>     - Intranet WiFi AP's are connected via switch to eth0
>     - Intranet Ethernet devices are connected via switch to eth0
>     - eth0 : 10.0.1.1/16 , facing intranet, MAC 00:e0:67:18:54:95
>     - eth1 : IP from ISP, facing public IPv4 internet, MAC 00:e0:67:18:54:94

Here is the real problem, you need a route on Host3 telling that 
10.0.0.2/32 is behind 10.0.200.136 (or 10.0.200.113). You can also add a 
route for 10.0.0.1/32 but it's just a bonus.

Without this route, Host3 don't know how to route the packet and will 
try to find an host on the 10.0.0.0/16 subnet using ARP. Then it's just 
luck, and depends on what Host3 and Host2 are doing:

- If the packet is sent in a broadcast Ethernet frame by Host3 it might 
works if Host2 catches the packet and forwards it to Host1.

- If the ARP request gets answered by Host2 when Host3 send their ARP 
request to find who is 10.0.0.2 on the 10.0.0.0/16 subnet, then it also 
works. This is known as ARP Proxy, lwIP does not support that.

It's just luck, using lazy features of IP stack to make it works even if 
the configuration is broken should be avoided :-)


> Layout:
> 
> Host1 <-> Host2 <-> Host3
> <-> public internet
>     PPPoS                     Ethernet
> 
> or
> 
> Host1 <-> Host2 <>  WiFi AP
> <--> Host3 <---> public internet
>     PPPoS WiFi      Ethernet
> 
> 
> For the case of using the WiFi connection, there are separate WiFi AP's in
> the way.
> Other than that, the two cases are host2 connecting to the local subnet via
> wlan0 or connecting via eth0.

I guess the only reason it works with WiFi and not with Ethernet is 
because WiFi is intrinsically broadcast-based while Ethernet is switched 
(well, I hope so, unless you live in '90s :p). This is the "works 
because Host2 catches the broadcast packet" case I've said before.


> I am not manually adding any static routes in either Host1 or Host2.
> I was worried that Host2 would not be able to accomplish the "connection
> sharing" until I found the IP_FORWARDING option. That initially worked with
> Host2 using WiFi without any manually added static routes.

This is not "connection sharing", this is IP routing, not NAT !, 
"connection sharing" is usually used for hosts that do SNAT on their 
Interface facing Internet.

IP routing needs a complete routing table on all hosts telling how to 
reach (i.e. which next-hop to use) every host of the whole network.

Example with 2 subnets and 3 Hosts:

A-eth0  - eth0-B-eth1 - eth0-C
  192.168.0.1/24192.168.0.2/24   172.16.1.1/24 172.16.1.2/24

Host A routing table:
192.168.0.0/24 dev eth0
172.16.1.0/24 via 192.168.0.2

Host B routing table:
192.168.0.0/24 dev eth0
172.16.1.0/24 dev eth1

Host C routing 

Re: [lwip-users] IP forwarding to/from PPP working for one netif, but not another

[Sylvain Rochet]

Hi Andrew,

On Tue, Jan 28, 2020 at 04:57:19PM -0800, Andrew Pullin wrote:
> Hi folks,
> 
> I am stuck on an issue here where I am trying to use lwip's IP_FORWARDING
> feature.
> I am trying to forward packets between a PPP server netif and a WAN
> interface. It is working on case, where the WAN-connected device is using
> WiFi, but then it fails to work in another case where the WAN device is
> configured to use an Ethernet interface.
> 
> This is to ultimately bring Ethernet connectivity to a device without
> Ethernet, but which can act as a PPP client (via UART).
> Lwip is running on a device with Ethernet and using the lwip PPP server
> implementation.
> 
> I have read the other threads involving PPP and forwarding, but I don't
> believe I have seen quite this same problem arise.
> 
> Here is how the devices are arranged for each case:
> 
> Working:
>    10.0.0.2 --[UART]--> 10.0.0.1 --> 
> 10.0.200.121 --> 10.0.1.1 ---> WAN
> (PPP client)    (PPP server, ESP32, lwip) (WiFi STA netif) 
>              ( router )
> 
> In this case, the WiFi netif reports the gateway IP correctly (10.0.1.1) and
> the netmask as 255.255.0.0
> 
> Not working:
>    10.0.0.2 --[UART]--> 10.0.0.1 --> 
> 10.0.200.113 --> 10.0.1.1 ---> WAN
> (PPP client)               (PPP server, ESP32, lwip)   
> (Ethernet netif)               ( router )
> 
> In this case, the Ethernet netif reports the gateway IP correctly (10.0.1.1)
> and the netmask as 255.255.0.0 , which appears to be the same as for the
> working WiFi netif case.
> 
> The addresses 10.0.0.1 and 10.0.0.2 on each side of the PPP are manually
> configured. They are hardcoded into the PPP server setup, and the client
> appears to be able to take it's 10.0.0.2 address via IPCP over PPP.
> 
> 
> To test that the WAN connection "works" for the PPP client, I am issuing
> pings from PPP client device.
> In the "working" case, I can ping 10.0.0.1, 10.0.1.1 (network gateway), and
> 8.8.8.8. All work.
> In the "not working" case on ethernet, I can ping 10.0.0.1 (just over the
> PPP link), but 10.0.1.1 and 8.8.8.8 appear unreachable.
> 
> Of course, I am building with IP_FORWARD defined to 1. Debug logs do reflect
> that forwarding is happening.
> There are several shims in the Espressif SDK over the actual lwip netif
> sets/calls.
> As far as I can see, the same setup is done for the ethernet netif as is for
> the wifi netif, but this is an obviously suspicious point.
> 
> In my case, I am using an ESP32 chip, and all of the lwip init and setup is
> done for me in the SDK.
> As far as I can see, the init for each adapter/netif type looks the same.
> 
> I have logs for each case, too:
> Working (wifi netif) - https://pastebin.com/RgqHa5CR
> Not working (ethernet netif) - https://pastebin.com/L80raiRF
> 
> One note here is: the PPP client is not running lwip. For hardware & legacy
> reasons, it is running another network stack with a totally different PPP
> client implementation.
> But, given that the working/not working is a function of the PPP server
> netif's, I did not suspect a mis-configuration issue in the PPP client.
> 
> Any insight here would be greatly appreciated. I am not too familiar with
> the deep under-the-hood details of network stacks.

I tried to understand but I failed. Before anything else, could you 
share the real network configuration of all network interfaces, the 
routing table on all hosts, and any speciafic features enabled on each 
interface (NAT, ARP-Proxy, …), for all configurations you tried ?

Example:

[Host1]ppp0 --- ppp0[Host2]eth0 --- eth0[Host3]eth1 --- Internet

Host1:
  running a PPP client, that's all we know
  ppp0: 10.0.0.2/32
  default route: ppp0
  no other route

Host2:
  running lwIP
  ppp0: 10.0.0.1/32
  eth0: 10.0.200.121/16
  default route: 10.0.1.1
  no other route

Host3:
  gateway ? to what ?
  eth0: 10.0.1.1/16
  eth1: public IPv4, facing Internet, set by DHCP, SNAT
  default route: set by DHCP, toward eth1
  no other route

Hint: the configuration above can't work, but I'm not sure this is what 
you currently have...

Sylvain


signature.asc
Description: Digital signature
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Problem with PPPoS connection cellular SIM800 with only one cell operator

[Sylvain Rochet]

Hi Артём,

On Thu, Jan 23, 2020 at 07:21:59PM +0300, Артём Скворцов wrote:
> Sylvain, thanks! Yes, LwIp is perfect!
> Finally I suppose that the cell operator rejects the PPP connection because
> of its internal reasons.
> But the internal IP stack of SIM800 module works fine!

Well, so I bet you just used the wrong protocol in the PDP type on your 
AT+CGDCONT context. PPP PDP type is rarely supported. Using something 
else than PPP for PDP type does not mean that PPP is not used for L2 
protocol between your host and the modem. The protocol between you and 
the modem is set in ATD, it is usually PPP and have no relation at all 
with the PDP type.

Sylvain


signature.asc
Description: Digital signature
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Problem with PPPoS connection cellular SIM800 with only one cell operator

[Sylvain Rochet]

Hi Артём,

On Sun, Dec 29, 2019 at 08:00:15PM +0300, Артём Скворцов wrote:
> The PPP can't be established with only one cell operator 'beeline'.
> This sim card works ok with embedded SIM800 TCP/IP AT commands.
> All other operators in Russia (Megafon, MTS) works ok both with LwIp PPPoS
> and embedded AT.
> But only 'beeline' rejects the connection.
> I tried to change authentication to PAP, also change APN setting to empty
> and other.
> Nothing changes.
> Here are the log:

For this kind of issue, since lwIP is working perfectly fine here, and 
unless someone on the list had the same issue, we can't do much.

I'm afraid you will have to ask your chip manufacturer to get some help 
on this case. GOOD LUCK.

Sylvain


signature.asc
Description: Digital signature
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] cannot establish connection if vj.c is optimized with -O2 option

[Sylvain Rochet]

Hi,

On Thu, Dec 12, 2019 at 10:04:19AM -0700, mav wrote:
> Hi, everybody. Maybe this is some type conversion issue, because vj.c throws
> many type conversion warnings, if latter enabled. As Sylvain recommends I
> would disable VJ for my project for good! Thank you for your answers. 

I also asked why do you need VJ in order to decide whether I should bury 
it in non-working features or to try to fix it once for all. So, I'm 
asking it again:

Why do you need VJ for ? It is useless with cellular modems, it is
useless in PPPoE and PPPoL2TP, AFAIK the last user was dial-up modems,
are they still used in the wild ?

Sylvain


signature.asc
Description: Digital signature
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] cannot establish connection if vj.c is optimized with -O2 option

[Sylvain Rochet]

Hi Artem,

śr., 11 gru 2019 o 17:36 mav  napisał(a):
>  Hi, all!
> 
>  I have a problem with lwip 2.0.3. I am switching on optimization of 
>  whole project to gcc -O2 option and I am getting into connection 
>  problem (cannot establish socket connection over PPPoS). When I turn 
>  off the optimization for vj.c only (use -Og) or when I disable VJ 
>  (#define VJ_SUPPORT 0), the problem disappears.
> 
>  What may be the problem?

I know it does not work with -O2, the VJ code is crap.

Why do you need VJ for ? It is useless with cellular modems, it is 
useless in PPPoE and PPPoL2TP, AFAIK the last user was dial-up modems, 
are they still used in the wild ?

I was mostly planning at disabling it by default and setting it broken 
instead of trying to fix it. It actually never really worked, I fixed 
some issues to make it works a little a couple of years ago but there 
are still issues.

Sylvain


signature.asc
Description: Digital signature
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] DHCP and Ethernet disconnection

[Sylvain Rochet]

Hi,

On Tue, Dec 10, 2019 at 04:13:33PM +0530, Vinu Gopalakrishnan wrote:
> Hi  Giuseppe,
> 
> You have to enable your  PHY interrupt and on interrupt , read the PHY
> registers and verify that the physical link is down. Then intimate the
> stack that link has gone down using the  netif_set_link_down. Then can
> dhcp_network_changed().

This is confusing, never call netif_set_link_*() from interrupt context, 
those calls are not thread nor interrupt safe.

You can either use PHY interrupt then signal your main loop in some way 
to call netif_set_link_*(), or periodically poll the PHY status in the 
main loop.

OS users should use the netifapi API: netif_set_link_*().

Sylvain


signature.asc
Description: Digital signature
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] DHCP and Ethernet disconnection

[Sylvain Rochet]

Hi Giuseppe,

On Tue, Dec 10, 2019 at 11:18:12AM +0100, Giuseppe Modugno wrote:
> I designed a network adapter board with Ethernet interface and lwip TCP/IP
> stack, with DHCP client enabled. It works well.
> 
> What happens if I disconnect the Ethernet cable from one network and connect
> it to a second network where is a different DHCP server? Mainly if the first
> network works on different address range (for example, 192.168.1.x and
> 192.168.2.x with 255.255.255.0 netmask).
> 
> I tried and it appears lwip/DHCP client doesn't trigger a new DHCP request
> and continue working with the first IP address... so it doesn't work on the
> second network.

It does, but you will have to tell lwIP that network changed if you 
don't want to wait for the next lease update.

See netif_set_link_down() / netif_set_link_up() to retrigger DHCP start.

Sylvain


signature.asc
Description: Digital signature
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] PPP Failing Network Phase with Telit LE910-V2 on AT

[Sylvain Rochet]

Hi Christopher,

On Mon, Sep 23, 2019 at 02:52:12PM -0400, Christopher Stocker wrote:
> 
> Thank you for looking into this.

Looks like a low level driver issue for me, are you one hundred percent 
sure that your modem receive all your frames ? There are way, way… 
way too many LCP retries in your log.

Sylvain


signature.asc
Description: Digital signature
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] FreeRTOS LwIP 2.1.2 PPPoS pppos_input hangs the system

[Sylvain Rochet]

Hi,

On Tue, Aug 27, 2019 at 07:51:22PM +0300, Артём Скворцов wrote:
> Hello! I can't solve the problem. May be you have some explanation or
> advice what to check?
> 
> System hangs after first byte received using ppos_input
> This function invokes in UART RX interrupt:

This kind of questions usually does not attract much answers, there can 
be one hundred reasons for something to hang. Wire up your debugger and 
check on what it is infinitely spinning.

Sylvain


signature.asc
Description: Digital signature
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] PPP Failing Network Phase with Telit LE910-V2 on AT

[Sylvain Rochet]

Hi Christopher,

On Fri, Sep 20, 2019 at 04:04:02PM -0400, Christopher Stocker wrote:
> 
> The modem does not require authentication but I enable the compile options
> in lwIP for PAP, CHAP, and MSCHAP but the stack just moves past phase 7
> without doing anything so I assume that’s correct. I also enable CCP but
> that did resolve the issue.

Could you try enabling at least PAP ?

The "ppp: auth protocols" output is garbaged but it looks like
authentication is not enabled at all, despite what you said.

I'm not sure I had the chance to test the no authentication build, it 
might need some glue to skip authentication and go forward to the next 
step.

Sylvain


signature.asc
Description: Digital signature
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Can you connect a MQTT client directly from a PPPoS status callback?

[Sylvain Rochet]

Hi Freddie,

On Thu, May 16, 2019 at 10:09:49PM +0200, Freddie Chopin wrote:
> On Thu, 2019-05-16 at 21:28 +0200, Sylvain Rochet wrote:
> > Unless you are calling ppp_close() from a module, which I highly
> > doubt, 
> > it is safe because other triggers are only rx packet or timeouts.
> 
> Forgive my ignorance, but what is a "module" in the lwIP world? (;

I just used module because this is what was previously used. But this is 
basically any function that can't be re-entered.


> Generally closing/disconnection are not that much important - when the
> PPPoS dies I guess MQTT will die by itself anyway, that's why my main
> concern is mqtt_client_connect().
> 
> Let's say I would try to do it directly from the callback - it there
> anything I could check to tell with confidence that this was wrong or
> ok?

As usual with locks, re-entrancy, shared variables, shared memory, or 
such. Some tools (e.g. coverity, coccinelle) can help checking that it 
looks right but until now it is left to poor humans to check that it is 
actually right.

For PPP callback, apart from ppp_close, it is safe because it can only 
be called on the RX packet path or from timeouts, where having anything 
else in the call stack than rx packet handler and timeout handler from 
main() or tcpip thread is highly impossible.

So you either have to trust me, or to check yourself all possible call 
stack leading to PPP callback being called. Luckily there are only a few 
places where the callback is actually called and diving into all the 
possible call stack is not a combinatorial explosion.

Basically, all possible call stack are:

ppp_close()
pcb->link_status_cb()

~timeout-handler~
pppoe_timeout()
pppoe_abort_connect()
ppp_link_failed()
pcb->link_status_cb()

~rx-packet-handler~
~udp-recv-callback~
pppol2tp_input();
pppol2tp_dispatch_control_packet()
pppol2tp_abort_connect()
ppp_link_failed()
pcb->link_status_cb()

~timeout-handler~
pppol2tp_timeout()
pppol2tp_abort_connect()
ppp_link_failed()
pcb->link_status_cb()

ppp_close()
ppp_link_terminated()
pcb->link_cb->disconnect() -> pppos_disconnect() or pppoe_disconnect() or 
pppol2tp_disconnect()
ppp_link_end()
pcb->link_status_cb()

ppp_close()
lcp_lowerdown()
fsm_lowerdown()
f->callbacks->down() -> lcp_down()
link_down()
upper_layers_down()
protp->close -> lcp_close()
lcp_finished()
link_terminated()
ppp_link_terminated()
pcb->link_cb->disconnect() -> pppos_disconnect() or pppoe_disconnect() or 
pppol2tp_disconnect()
ppp_link_end()
pcb->link_status_cb()

~rx-packet-handler~
ppp_input()
lcp_input()
fsm_input()
fsm_rtermack()
f->callbacks->finished() -> lcp_finished()
link_terminated()
ppp_link_terminated()
pcb->link_cb->disconnect() -> pppos_disconnect() or pppoe_disconnect() or 
pppol2tp_disconnect()
ppp_link_end()
pcb->link_status_cb()

~rx-packet-handler~
ppp_input()
lcp_input()
fsm_input()
fsm_rtermreq() or fsm_rtermack()
f->callbacks->down() -> lcp_down()
link_down()
upper_layers_down()
protp->close -> lcp_close()
lcp_finished()
link_terminated()
ppp_link_terminated()
pcb->link_cb->disconnect() -> pppos_disconnect() or pppoe_disconnect() or 
pppol2tp_disconnect()
ppp_link_end()
pcb->link_status_cb()

~timeout-handler~
LcpEchoTimeout()
LcpEchoCheck()
LcpSendEchoRequest()
LcpLinkFailure()
lcp_close()
lcp_finished()
link_terminated()
ppp_link_terminated()
pcb->link_cb->disconnect() -> pppos_disconnect() or pppoe_disconnect() or 
pppol2tp_disconnect()
ppp_link_end()
pcb->link_status_cb()

~rx-packet-handler~
ppp_input()
protp->input() -> ipcp_input()
fsm_input()
fsm_rconfreq() or fsm_rconfack()
f->callbacks->up() -> ipcp_up() 
sifup()
pcb->link_status_cb()

~rx-packet-handler~
ppp_input()
protp->input() -> ipv6cp_input()
fsm_input()
fsm_rconfreq() or fsm_rconfack()
f->callbacks->up() -> ipv6cp_up()
sif6up()
pcb->link_status_cb()


Sylvain


signature.asc
Description: Digital signature
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Can you connect a MQTT client directly from a PPPoS status callback?

[Sylvain Rochet]

Hi,

On Thu, May 16, 2019 at 07:51:45PM +0200, goldsi...@gmx.de wrote:
> Am 16.05.2019 um 18:31 schrieb Freddie Chopin:
> >Hello Devanand!
> >
> >On Thu, 2019-05-16 at 20:41 +0530, Devanand Biradar wrote:
> >>I have connected to mosquito cloud using Lwip via MQTT.
> >>Using PPPOS with GSM module.
> >
> >Yes, I know this can be done, because I already have done it and it
> >works (; But now I would like to make it more error-proof and
> >responsive - my code so far is just a dirty proof-of-concept using
> >stupid things like global flags and polling.
> >
> >So what I'm asking is this - is it safe to have code like this:
> 
> It's probably not safe as you risk calling back into modules that are
> not reentrant. I don't know this for sure, just as a saftey measurement...

Hummm, I guess it's safe, I doubt PPP status callback can actually be 
called from a module.

Looking at the code it can only be called:
  - Right from ppp_close(), only if the session is already dead;
  - If the lower level link failed to setup, i.e. timeout. in 
ppp_link_failed();
  - If the link is shutting down, i.e. timeout or LCP "Term" packet
received in ppp_link_end();
  - If the link is UP, after a packet is received, in sifup() and 
sif6up().

Unless you are calling ppp_close() from a module, which I highly doubt, 
it is safe because other triggers are only rx packet or timeouts.

Sylvain


signature.asc
Description: Digital signature
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] lwIP on a Microcontroller with two MACs

[Sylvain Rochet]

Hi Sergio,

On Fri, May 03, 2019 at 12:44:50PM -0300, Sergio R. Caprile wrote:
> Hi Sylvain,
> last time I checked there were only hooks and the user needed to write
> the routing function.
> Is this remarkably different now ?

So ? It doesn't change my statement, IP forwarding, i.e. passing one 
packet from an interface to another interface at the IP level, is 
supported.

User have to implement its additional routing table through hooks if the 
user need routes other than link intrinsic routes and default route.

Sylvain


signature.asc
Description: Digital signature
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] lwIP on a Microcontroller with two MACs

[Sylvain Rochet]

Hi,

On Fri, May 03, 2019 at 09:22:46AM -0300, Sergio R. Caprile wrote:
> 
> 4- You can have as many netifs as you want and your hw can fit. Notice
> that lwIP is not a router/forwarder, traffic on all netifs has to have
> lwIP as an endpoint and netifs should (must ?) belong to different IP
> networks. This is what I mean by "standard".

That's not true, lwIP supports IP forwarding (IP_FORWARD / 
LWIP_IPV6_FORWARD), routing table should be implemented in 
LWIP_HOOK_IP4_ROUTE and LWIP_HOOK_IP6_ROUTE hooks.

NAT is however not supported.

Sylvain


signature.asc
Description: Digital signature
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Ping is not working in LWIP pppos

[Sylvain Rochet]

Hi Rahul,

On Fri, Apr 05, 2019 at 10:27:41AM +, rahul.mane . wrote:
> Hello ,
> 
> I want to use LWIP stack (2.0.2) with pppos.I have NXP MC5748 board wi 
> SIM800c interface with one UART channel.I have use following AT 
> commands to configure GSM module:
> 
> I am successfully getting following data from GSM module.
> status_cb: Connected   our_ipaddr  = 100.95.137.40   his_ipaddr  = 
> 192.168.254.254   netmask     = 255.255.255.255   dns1        = 59.144.144.46 
>   dns2        = 59.144.127.117   Next step, I am trying to ping 8.8.8.8 
> But I am getting Timeout error
> lwip_socket(PF_INET, SOCK_RAW, 1) = 1lwip_sendto(1, data=0x40040728, 
> short_size=40, flags=0x0 to=8.8.8.8 port=42405ping: send 8.8.8.81. 
> lwip_recvfrom(1, 0x40008cb8, 64, 0x0, ..)2. lwip_recvfrom: top while 
> sock->lastdata=0x04. lwip_recvfrom: netconn_recv err=-3, 
> netbuf=0x05.lwip_recvfrom(1): buf == NULL, error is "Timeout."!
> Is there any step i am missing to configure ?
> For more information I have attached log file

I guess it is because checksums are disabled. Could you try enabling 
CHECKSUM_GEN_* and CHECKSUM_CHECK_* options ?

Sylvain


signature.asc
Description: Digital signature
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Help with PPP connection - modem disconnects for no obvious reason...

[Sylvain Rochet]

Hi Freddie,

On Wed, Mar 20, 2019 at 10:16:46PM +0100, Freddie Chopin wrote:
> Alternative approach to the problem - could someone recommend a GSM
> modem, commercially available in reasonable numbers, M.2 interface,
> that works with lwIP? Maybe its the Huawei me906e that is the problem
> here, who 

Well, I don't know if they manufacture modems with an M.2 interface, but 
I used both Telit and U-blox cellular modems with full success.

Sylvain


signature.asc
Description: Digital signature
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Help with PPP connection - modem disconnects for no obvious reason...

[Sylvain Rochet]

Hi Freddie,

On Wed, Mar 20, 2019 at 07:29:31PM +0100, Freddie Chopin wrote:
> On Wed, 2019-03-20 at 18:22 +0100, Sylvain Rochet wrote:
> > The DiscReq LCP packet does not seem to be related at all to the PPP 
> > exchange, but rather just timed after the PPP session is started no 
> > matter what, right ? Could you try aggressively slowing down the
> > serial 
> > tx routine to check that ?
> 
> This modem is connected with USB, so I could try adding a `sleep()`
> inside the functions that read/write to the device. Would that be what
> you have in mind? Previously I've tried to make sure this is not a case
> of "modem disconnects X seconds after `ATD*99#`" so I've added a long
> sleep (up to 60 seconds) between last AT command and starting lwip, but
> this also did not change anything.

So it always disconnect after the first IPCP packet. That's all what I 
wanted to know :)


> > Your setup allows you to check using pppd instead of lwIP, maybe 
> > that's worth trying it to get another set of traces.
> 
> Generally I think that using pppd is possible here, but the funny thing
> is that the first thing I tried was to use this modem as a network card
> with Linux - using NetworkManager, ModemManader, pppd and so on. And it
> _DID_ connect to the network, got an IP address, DNS servers, etc.,
> but... did not work at all (;
> 
> https://bbs.archlinux.org/viewtopic.php?id=244862

That is bad news… if it does not work with plain pppd there is no way it 
could work with lwIP.


> That's why I then tried in Windows and in there - after a couple of 
> tricks and hacks - it worked correctly. My plan was therefore to try 
> using Wireshark to capture USB traffic to this modem to see what's 
> going on, maybe this will me some hints (assuming I'll manage to do 
> that)...

Having a dump of the working trace would be very helpful. I doubt there 
is an issue on PPP itself because the dumped PPP trace is perfectly sane 
until the modem stop at first IPCP packet received. But we have no clue 
about modem initialization and I'm confident this is where it might be 
different and significant.


> I'll try to use pppd with your suggestions too.
> 
> But generally - is it possible for the modem to misbehave like this
> because of some lwip settings or maybe whatever I would set in lwip it
> should not result in the modem just disconnecting? I'm not 100% sure
> about any part of this code really, so don't know where to focus.

It should not result in the modem just disconnecting… especially by 
sending a "NO CARRIER" raw frame in the middle of a PPP session 
bypassing HDLC encoding. This is just never allowed once the modem 
entered DATA mode, it should not send garbage in the middle of an HDLC 
stream this way… the proper way for the modem to end the PPP session is 
to send a LCP TermReq request.


Sylvain


signature.asc
Description: Digital signature
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Help with PPP connection - modem disconnects for no obvious reason...

[Sylvain Rochet]

Hi Patrick,

On Wed, Mar 20, 2019 at 02:19:48PM -0400, Patrick Klos wrote:
> 
> OK, but that just begs the question "why is the modem asking for CHAP
> authentication"?  Maybe that's how GSM modems work?  Anyway, let's explore
> the CHAP process further.

This is to support PPP clients that require a secure CHAP authentication 
although we don't care at all for authentication on a cellular modem. 
The cellular modem is going to accept a downgrade to PAP or even no 
authentication at all. PPP is designed that authentication methods are 
asked/(n)acked in order from the best one to the worst one until both 
agrees on a common one, that's why the cellular modem start by CHAP.


> >Debugging seem pretty well enabled, for once in a while I have no clue
> >what is wrong here, usually it's straightforward from the trace but here
> >it really isn't.
> 
> If all the debugging is enabled, I'm curious why we don't see a CHAP
> Response being sent out?  I would suggest adding a few PPPDEBUG statements
> to chap_input() (especially the few places where is silently returns) and
> chap_respond() and see what that reveals?

(Answering so this question is not left unanswered for future readers, 
although there are clues in the thread)

This is because packet allocation for the reponse failed, probably 
because PPP_USE_PBUF_RAM is not set and PBUF_POOL_BUFSIZE is too small 
(< RESP_MAX_PKTLEN).


Sylvain


signature.asc
Description: Digital signature
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Help with PPP connection - modem disconnects for no obvious reason...

[Sylvain Rochet]

Hi Freddie,

On Wed, Mar 20, 2019 at 07:37:27PM +0100, Freddie Chopin wrote:
> On Wed, 2019-03-20 at 13:20 -0400, Patrick Klos wrote:
> > For whatever reason, you're not responding to the CHAP challenges.
> 
> I assume this is because my user and password are just `""` (empty
> strings), but this is just my very wild guess.

I don't think so, CHAP packets are huge and if PPP_USE_PBUF_RAM is not 
set and your PBUF_POOL_BUFSIZE is a low value then packet allocation 
will fail (lwIP PPP stack does not support chained pbuf), this is my 
wild guess about what is happening.

Null secret is allowed in CHAP. See `secret_len = 0; /* assume null 
secret if can't find one */` from chap-new.c.

Anyway, PAP does not need big packets, and you should try PAP 
authentication with a null login and a null secret. Why compiling the 
somewhat huge CHAP support when this is just fake authentication
anyway ? :)

Sylvain


signature.asc
Description: Digital signature
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Help with PPP connection - modem disconnects for no obvious reason...

[Sylvain Rochet]

Hi Patrick,

On Wed, Mar 20, 2019 at 01:20:02PM -0400, Patrick Klos wrote:
> 
> For whatever reason, you're not responding to the CHAP challenges.
> 
> Are you dialing into an ISP (which would require authentication) or into
> another system configured to be a "server"?  Either way, the peer is
> expecting you to have a username and password of some kind, but you're not
> responding to their challenges.

Well, that's just PPP to a cellular modem, PPP link is only between the 
device and the cellular modem to de/serialize IP packets on a serial 
link. That's why authentication is never required, cellular modems 
usually add some kind of fake authentication to support PPP clients 
where authentication can't be disabled.


> Also, what version of LwIP are you using?  I can't find some of these debug
> strings (like "CHAP Challenge") in my (2.1.2) sources. And are you sure all
> your modules were compiled with PPP_DEBUG defined as non-zero?

"CHAP Challenge" is from "CHAP" from chap_protent and "Challenge" from 
chap_code_names[].

Debugging seem pretty well enabled, for once in a while I have no clue 
what is wrong here, usually it's straightforward from the trace but here 
it really isn't.


Sylvain


signature.asc
Description: Digital signature
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Help with PPP connection - modem disconnects for no obvious reason...

[Sylvain Rochet]

Hello Freddie,

On Wed, Mar 20, 2019 at 05:56:10PM +0100, Freddie Chopin wrote:
> Hello Sylvain!
> 
> On Wed, 2019-03-20 at 17:18 +0100, Sylvain Rochet wrote:
> > Could you try with VJ_SUPPORT disabled ?
> 
> I've also thought about that and already tried that, but the result is
> almost identical:

The DiscReq LCP packet does not seem to be related at all to the PPP 
exchange, but rather just timed after the PPP session is started no 
matter what, right ? Could you try aggressively slowing down the serial 
tx routine to check that ?

Could you try using `AT+CGDATA="PPP",1` instead of `ATD*99#` ?

Your setup allows you to check using pppd instead of lwIP, maybe that's 
worth trying it to get another set of traces.

This is what I used a couple of years ago:

-- /etc/ppp/peers/gprs
show-password 
noauth
connect '/etc/ppp/peers/gprs-chat.sh'
debug debug debug
/dev/ttyUSB0
115200
defaultroute
noipdefault 
crtscts
novj
novjccomp
noaccomp
nobsdcomp
nopcomp
noccp
-ipv6

-- /etc/ppp/peers/gprs-chat.sh 
#!/bin/sh

# call the preparation chat script
/usr/sbin/chat -v -f /etc/chatscripts/gprs-prep
# wait to switch between GPRS/UMTS
sleep 20
# the final chat script:
/usr/sbin/chat -v -f /etc/chatscripts/gprs

-- /etc/chatscripts/gprs-prep 
ECHO ON
ABORT BUSY
ABORT 'NO CARRIER'
ABORT ERROR
REPORT CONNECT
TIMEOUT 20
'' ATZ
OK AT
OK AT
OK AT
OK AT+CMEE=2
OK AT#CMEEMODE=1
OK AT#SLED=2
OK AT#GPIO=5,0,2
OK AT#TXMONMODE=1
OK AT+CPIN=1234
OK AT+CGDCONT=1,"IP","websfr","0.0.0.0",0,0
OK

-- /etc/chatscripts/gprs
ECHO ON
ABORT BUSY
ABORT 'NO CARRIER'
ABORT ERROR
REPORT CONNECT
TIMEOUT 20
'' AT+CGACT=1,1
OK AT+CGDATA="PPP",1
CONNECT \d\c

-- /etc/ppp/pap-secrets
"" gprs ""


Sylvain


signature.asc
Description: Digital signature
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Help with PPP connection - modem disconnects for no obvious reason...

[Sylvain Rochet]

Hi Freddie,

On Wed, Mar 20, 2019 at 05:06:29PM +0100, Freddie Chopin wrote:
> 
> sent [IPCP ConfReq id=0x10.0.0.0> ]
> pppos_write[1]: len=32
> pppos_input[1]: got 21 bytes
> rcvd [LCP DiscReq id=0x2 magic=0x4fe5c633]
> pppos_input[1]: got 14 bytes

Could you try with VJ_SUPPORT disabled ?

Sylvain


signature.asc
Description: Digital signature
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Regarding ppp issue

[Sylvain Rochet]

Hi Shivaraj,

On Sat, Jan 19, 2019 at 12:32:16PM +0530, shivaraj Dandagihalli wrote:
> Hi,
> I'm using the linux-lwip here i'm not able to receive the ppp packets,
> whatever we are sending we receive the same data packets.please find the
> following attached log and send me some proper solution.

The reason could not be written more clearly in the debug log: "Serial 
line is looped back.". Please configure your TTY in RAW mode.

This is obvious once you remove all the useless garbage from the log:

$ egrep '^(sent|rcvd)' 3G_ppp_log.txt 
sent [LCP ConfReq id=0x1]
rcvd [LCP ConfReq id=0x1]
sent [LCP ConfNak id=0x1 ]
rcvd [LCP ConfNak id=0x1 ]
sent [LCP ConfReq id=0x2]
rcvd [LCP ConfReq id=0x2]
sent [LCP ConfNak id=0x2 ]
rcvd [LCP ConfNak id=0x2 ]
sent [LCP ConfReq id=0x3]
rcvd [LCP ConfReq id=0x3]
sent [LCP ConfNak id=0x3 ]
rcvd [LCP ConfNak id=0x3 ]
sent [LCP ConfReq id=0x4]
rcvd [LCP ConfReq id=0x4]
sent [LCP ConfNak id=0x4 ]
rcvd [LCP ConfNak id=0x4 ]
sent [LCP ConfReq id=0x5]
rcvd [LCP ConfReq id=0x5]
sent [LCP ConfNak id=0x5 ]
rcvd [LCP ConfNak id=0x5 ]
sent [LCP ConfReq id=0x6]
rcvd [LCP ConfReq id=0x6]
sent [LCP ConfNak id=0x6 ]
rcvd [LCP ConfNak id=0x6 ]
sent [LCP ConfReq id=0x7]
rcvd [LCP ConfReq id=0x7]
sent [LCP ConfNak id=0x7 ]
rcvd [LCP ConfNak id=0x7 ]
sent [LCP ConfReq id=0x8]
rcvd [LCP ConfReq id=0x8]
sent [LCP ConfNak id=0x8 ]
rcvd [LCP ConfNak id=0x8 ]
sent [LCP ConfReq id=0x9]
rcvd [LCP ConfReq id=0x9]
sent [LCP ConfNak id=0x9 ]
rcvd [LCP ConfNak id=0x9 ]
sent [LCP ConfReq id=0xa]
rcvd [LCP ConfReq id=0xa]
sent [LCP ConfNak id=0xa ]
rcvd [LCP ConfNak id=0xa ]
sent [LCP TermReq id=0xb "Loopback detected"]
rcvd [LCP TermReq id=0xb "Loopback detected"]
sent [LCP TermAck id=0xb]
rcvd [LCP TermAck id=0xb]

Sylvain


signature.asc
Description: Digital signature
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] lwip + modbus TCP + UDP

[Sylvain Rochet]

Hi,

On Mon, Dec 31, 2018 at 02:31:22PM +0100, Pablo Ledergerber wrote:
> 
> The freemodbus library uses the TCP Raw library and the upd discovery
> function the netconn api. We have one thread for modbusTCP,

The RAW API is not thread-safe, you can't use it within a thread (other 
than the lwIP core thread).

See http://www.nongnu.org/lwip/2_1_x/pitfalls.html

Sylvain


signature.asc
Description: Digital signature
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] LWIP/PPPOS for GSM module

[Sylvain Rochet]

Hi Devanand,

On Mon, Nov 26, 2018 at 03:08:18PM +0530, Devanand Biradar wrote:
> Hello Sylvain,
> 
> This are the logs I am getting.
> Is any point is missing to Enable in Lwip/pppos.
> Also will you guide how to receive the ppp packets from gsm module.
> 
> ppp phase changed[0]: phase=0
> ppp_connect[0]: holdoff=0
> ppp phase changed[0]: phase=3
> 
> pppos_connect: unit 0: connecting
> ppp_start[0]
> ppp phase changed[0]: phase=6
> 
> pppos_send_config[0]: out_accm=FF FF FF FF
> ppp_send_config[0]
> 
> pppos_recv_config[0]: in_accm=FF FF FF FF
> ppp_recv_config[0]
> 
> pppos_write[0]: output failed len=24

You are obviously having an issue with your output serial driver.


> pppos_input[0]: got 14 bytes
> pppos_input[0]: Dropping ACCM char <0>
> pppos_input[0]: Dropping ACCM char <0>
> pppos_input[0]: Dropping ACCM char <0>
> pppos_input[0]: Dropping ACCM char <0>
> pppos_input[0]: Dropping ACCM char <0>
> pppos_input[0]: Dropping ACCM char <0>
> pppos_input[0]: Dropping ACCM char <0>
> pppos_input[0]: Dropping ACCM char <0>
> pppos_input[0]: Dropping ACCM char <0>
> pppos_input[0]: Dropping ACCM char <0>
> 13pppos_input[0]: Dropping ACCM char <0>

And you are obviously having an issue with your input serial driver.


I wonder why you even asked what the issue is considering it could not 
be written more clearly in the debug trace.

Sylvain


signature.asc
Description: Digital signature
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] UDP and TCP concurrent operation causing fault

[Sylvain Rochet]

Hi,

On Thu, Nov 15, 2018 at 05:59:58PM +, Applebee, Robert wrote:
> 
> My application is built with LWIP 1.4.1 running on a TI MCU and uses 
> raw TCP and raw UDP calls, no RTOS.

lwIP 1.4.1 was released 6 years ago…


> This is my main loop that outputs the UDP:
> 
> // allocate pbuf for UDP
> p=pbuf_alloc(PBUF_TRANSPORT, 32, PBUF_RAM);
> 
> //
> // Loop forever, processing the LED blinking.  All the work is done in
> // interrupt handlers.

This doesn't seem right, are you sure you are not violating lwIP 
threading/contexts requirements ?

http://www.nongnu.org/lwip/2_1_x/pitfalls.html

RAW API (udp_*, tcp_*, netif_*, …) is not thread nor IRQ safe!!!


> while(1)
> {

Where are you calling lwIP timeouts in this loop ?


Sylvain


signature.asc
Description: Digital signature
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] LWIP/PPPOS for GSM module

[Sylvain Rochet]

Hi Devanand,

On Wed, Nov 14, 2018 at 12:27:20AM +0530, Devanand Biradar wrote:
> Hello ,
> I am using NXP DEVKIT MCP5748G.
> I am having example code of lwip with freertos.
> I want to communicate with gsm module using lwip/pppos.
> I am getting lcp packets from gsm module for negotiating, but I am not
> getting the ip address from module & after some seconds I am getting NO
> CARRIER from module.
> Please suggest some basic needs OR what I am missing in this module.

This is not really helpful, could you please provide a serial trace of 
the AT commands to setup the modem prior PPP start and a full trace of 
all PPP control packets using PPP_DEBUG with PRINTPKT_SUPPORT enabled ?

Sylvain


signature.asc
Description: Digital signature
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] PPP proxy arp support

[Sylvain Rochet]

Hi,

On Wed, Oct 10, 2018 at 03:13:56PM +0200, goldsi...@gmx.de wrote:
> 
> Isn't proxy ARP support only really valid when we are a PPP server? That
> wasn't working at that time.

We use to call that client and server but in the end it is just an IP 
tunnel and both ends are equal, PPP protocol is mostly (fully if no 
corner cases are to be found :>) symmetric regarding which one is the 
initiator (e.g. IP addresses are not necessarily given by the initiator, 
both ends can even choose their own if remote side allow to do so). So 
technically speaking there is no reason for a PPP "client" or I would 
rather say non-initiator to never need ARP proxy. However I agree that's 
an option for IP routers so it makes more sense in the real world on 
what we call PPP "servers".


> >Was curious to know if this is something that, if the surrounding
> >`#define`s were removed, would likely just work,
> 
> No, the ARP layer does not have support for this. You'd have to add at least
> that to make it work.
> 
> >or if there was some underlying implementation issue that led to its
> >removal.
> 
> If I remember correctly, Sylvain started to make things work that he needed
> when porting the updated PPP sources. It doesn't necessarily mean there was
> an issue, but I guess he didn't want to implement proxy ARP support in the
> lwIP ARP layer unless he needed it...

Indeed. If it would be implemented proxy ARP control plane should live 
in the netif core code and data plane in the ARP layer. There is no ARP 
proxy support per se on the PPP protocol, PPP layer do no more than 
setting a few internal flags and asking the system to set/remove an ARP 
proxy entry.

Anyway, ARP proxies seem to be a mostly dead thing nowadays, and I 
consider that a good thing because it's a huge layer violation. However, 
if some day ARP proxy support materialize in the ARP layer I will of 
course make it works for PPP since it is just a couple of flags and 
functions calls.


Sylvain


signature.asc
Description: Digital signature
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] PPP: IPCP bad fcs issue

[Sylvain Rochet]

Hi,

On Wed, Aug 15, 2018 at 05:46:21PM -0400, Patrick Klos wrote:
> On 8/15/2018 4:19 PM, Sylvain Rochet wrote:
> >But what is very strange is that checksum including checksum itself for
> >comparison purpose for "0x01 0x01 0x16 0x03 0x6 0x81 0x6 0x83 0x06 0x6e
> >0xdb" is 0xeb 0xbe, which is not 0x4114 (nor 0x1441 with byte swap) as
> >displayed in your "Dropping bad fcs" debug print, how is that even
> >possible ?
> 
> For what it's worth, 0x4114 is the complement of the byte swap 0xebbe (and
> that's how the FCS is added to a PPP packet).  I didn't look at the actual
> code to see at what stage and which value the message prints, but it's close
> enough to say it's probably right.

Oh dear, I actually checked that, but looks like I failed somewhere :-) 

Indeed, the PPP_GOODFCS value is the checksum value of the full frame 
including the checksum but without the final XOR.

Sylvain


signature.asc
Description: Digital signature
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] PPP: IPCP bad fcs issue

[Sylvain Rochet]

Hi,

On Wed, Aug 15, 2018 at 03:40:22PM -0400, Patrick Klos wrote:
> On 8/15/2018 11:25 AM, Axel Lin wrote:
> >Hi list,
> >
> >I'm testing a LTE module with lwIP and found always got bad fcs as below.
> >I dump the received data below:
> >Is there anything wrong in the received data?
> >
> >sent [IPCP ConfReq id=0x1>0.0.0.0>]␍␊
> >pppos_write[0]: len=26␍␊
> >pppos_input[0]: got 17 bytes␍␊
> >7e ff 3 80 21 1 1 16 3 6 81 6 83 6 6e db 7e ␍␍␊
> >pppos_input[0]: Dropping bad fcs 0x4114 proto=0x8021␍␊
> 
> That doesn't look like a good PPP packet.
> 
>ff 3 80 21 1 1 16 3 6 81 6 83 6 6e db
> 
> ff 03 = address and control field
> 80 21 = IPCP protocol ID
> 01 = Configure request
> 01 = Identifier
> 16 03 = SHOULD BE PACKET LENGTH

Added to that, there is something very wrong here, HDLC checksum 
(polynomial 0x1021, init 0x, xor final 0x, reflected input, 
reflected result, network byte order result) for "0xff 0x03 0x80 0x21 
0x01 0x01 0x16 0x03 0x6 0x81 0x6 0x83 0x06" is 0x19 0x17 which is 
obviously not 0x6e 0xdb.

But what is very strange is that checksum including checksum itself for 
comparison purpose for "0x01 0x01 0x16 0x03 0x6 0x81 0x6 0x83 0x06 0x6e 
0xdb" is 0xeb 0xbe, which is not 0x4114 (nor 0x1441 with byte swap) as 
displayed in your "Dropping bad fcs" debug print, how is that even 
possible ?

I just tested on good packets and the debug print actually print 0xf0b8 
for FCS which is the PPP_GOODFCS value.

Sylvain


signature.asc
Description: Digital signature
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] PPPoS TCP unix port terribly slow

[Sylvain Rochet]

Hi Mednyy,

On Thu, Aug 02, 2018 at 05:06:54PM +0300, Mednyy Alexey wrote:
> Hello list!
> 
> I'm trying to implement port forwarding over LWIP.
> 
> One side is Linux x86_64 machine another one is FreeRTOS ARM device.
> 
> I have LWIP stack on both sides of PPPoS channel, and data transfers ok.
> tty read/write is fast and stable.
> 
> On IP level I see that ping example app works well, I can ping opposite
> side with raw sockets API and it takes about 12ms over PPPoS on 115200
> baudrate.
> 
> However when I start to use TCP level things goes terribly slow. Even
> simple echo server takes several seconds receive an answer.
> 
> I use default lwipopts from
> lwip-contrib/examples/example_app/lwipopts.h, just added PPP_SERVER and
> PPP_NOTIFY_PHASE support.
> 
> Here is my log https://pastebin.com/raw/tfwY1rtV
> 
> And lwipopts.h https://pastebin.com/vd2DrxYJ
> 
> Can somebody tell me what is wrong with my log/config?

I think I'm able to reproduce the issue. With which optimization level 
are you building the unix port ? I'm very getting good throughput with 
-O0, -O1 and -Os but almost no throughput with -O2. (-O3 does not even 
build, which I'm going to fix sooner or later). Disabling VJ_SUPPORT 
fixed the issue with -O2 for me which might indicate the issue is just 
with a combination of VJ_SUPPORT and -O2.

Could you try with all possible combinations of optimization levels and 
VJ_SUPPORT enabled and disabled ?

Sylvain


signature.asc
Description: Digital signature
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] PPPoS : no response from modem after link established

[Sylvain Rochet]

Hi Sergey,

On Sun, Jul 08, 2018 at 01:26:03AM +0300, Sergey A. Borshch wrote:
> 
>  Can I suggest to add some flag into netif to enable/disable software
> checksum calculation? Using this flag can be selectable at compile time #if
> (PPP_SUPPORT != 0) && (CHECKSUM_GEN_xxx == 0)
>  add flag into netif, init it in ppp_create and use
> #else
>  use CHECKSUM_GEN_xxx
> #endif

This is what LWIP_CHECKSUM_CTRL_PER_NETIF actually do. It is quite hard 
to add fail to build conditions on CHECKSUM_GEN_* macros, we don't know 
which prococols user is going to use (only UDP, only TCP, RAW IP 
packets…).

Sylvain


signature.asc
Description: Digital signature
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] PPPoS : no response from modem after link established

[Sylvain Rochet]

Hi,


On Sat, Jul 07, 2018 at 07:40:01PM +0300, Sergey A. Borshch wrote:
> Hi.
> 
> I want to use ppp connection via SIM800C GPRS modem.
> I use last lwIP sources from git HEAD.
> 
> The problem is identical to to described at 
> https://lists.gnu.org/archive/html/lwip-users/2017-10/msg00084.html 
> (but there was no solution proposed)

I don't know how you managed to conclude that no solution was 
proposed... User had CHECKSUM disabled, see:
https://lists.gnu.org/archive/html/lwip-users/2017-11/msg00072.html


>  - modem stops responding after status_cb:
> connected. I checked twice with logic analyzer - there is to responses to
> frames with proto=0x21. I tried two SIM cards from different mobile
> providers (one requires authentication, the other not) with exactly same
> result - I can get IP, DNS etc but no data exchange.
> 
> What did I missed to do?

Did you check that you are actually receiving IP packets on the remote 
side ?


Sylvain


signature.asc
Description: Digital signature
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] PPPos Internet connection problem

[Sylvain Rochet]

Hi,

On Tue, Jul 03, 2018 at 10:20:28AM -0400, Tushar Patel wrote:
> Hello,
> 
> I have a TCP server application running on my microcontroller which has
> PPPoS network capability (as seen from log above). If I want to connect to
> this TCP server application from a Windows based machine then should I
> connect to using  *our_ip4addr = 10.200.45.187?*
> 
> I am trying to ping my MCU from windows machine.

Looks like you forgot to call call ppp_set_default on your PPP PCB.

Sylvain


signature.asc
Description: Digital signature
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] PPPos Internet connection problem

[Sylvain Rochet]

Hi,


On Fri, Jun 29, 2018 at 02:32:49PM -0400, Tushar Patel wrote:
> Hello,
> 
> I am using GSM LTE Modem from Quectel EC21.
> I am having problem pinging the device after it has successfully acquired
> the IP address.

What do you mean by "the device" ? From which host are you sending the 
ping request ? to which host ? Did you miss that 10.200.45.187 is behind 
a CGN network ?


> The modem works fine on Windows machine when I try to use
> dial up connection.
> I am doing something wrong or my settings are not correct
> 
> Below is the log and config file.

Everything looks fine.


Sylvain


signature.asc
Description: Digital signature
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] PPP phase dead every 2 hours

[Sylvain Rochet]

Hi Nishant,

On Thu, Jun 21, 2018 at 12:37:09PM +0545, Nishant Agrawal wrote:
> Hello,
> 
> I am using the ppp stack, using a modem to keep a device online and it is
> sending ping requests every 30 seconds. The problem is that roughly every 2
> hours, I end up with error, PPPERR_CONNECT. The phase change generally is
> as follows,
> 
> PHASE_NETWORK
> PHASE_ESTABLISH
> PHASE_DISCONNECT
> PHASE_DEAD
> 
> The PHASE_NETWORK and ESTABLISH happens simultaneously. PHASE_DISCONNECT
> happens about 5 seconds later and the phase goes to DEAD immediately as
> well. After PHASE_DEAD, I get the error, PPPERR_CONNECT.

That's the normal clean disconnection behavior. I believe the peer sent 
you a LCP TermReq request. Could you check that ? (Using PPP_DEBUG and 
PRINTPKT_SUPPORT support).


> I believe that the issue is related to the IP lease time. Because the 
> time is more or less consistent and I am seeing the same pattern with 
> 2 different prototypes that are on test. And every time I reconnect I 
> get a new IP. So my question is, is there any way for me to request a 
> renew of the old connection, like something that can be done with 
> DHCP.

This is no such renew thing in PPP. If the peer change your local IP 
address it means it really want to change it or just they don't care at 
all and give a random one each time you connect.

There is no such thing of IP lease time as well, if a peer disconnect 
you every two hours it means the peer want you to reconnect every two 
hours.

However, you could try with another modem brand/model, I doubt the issue 
is on the modem side (once in a while :p) but some of them are, 
especially cellular ones, are doing stupid things or just full of bugs.


> Or what I can I do to keep the device connected?

Well, ask your ISP to stop disconnecting you every two hours :-)


Sylvain


signature.asc
Description: Digital signature
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Buffer issues on slow network medium

[Sylvain Rochet]

Hi Raivis,

On Tue, May 29, 2018 at 10:50:58AM +0100, Raivis wrote:
>
> [...]
> 
> Here is our lwipopts.h file: https://pastebin.com/X40WENu4
> 
> Any help would be greatly appreciated, thank you.

Could you try enabling SYS_LIGHTWEIGHT_PROT ? Update your port if 
necessary to add critical section protection.

Sylvain


signature.asc
Description: Digital signature
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] PPP CHAT failed

[Sylvain Rochet]

Hi,

On Wed, Apr 11, 2018 at 06:23:47PM -0700, vinimac wrote:
> Hi,
> 
> I am using Lwip 2.0.3+FreeRTOS 10 and PPPoS with CHAP MD5 authentication.
> The PPP negociation proceeds until stop in CHAP Challenge/CHAP Response. I
> am using the same name/secret on Linux and works!
> 
> Log attached. 
> ppp.log   

It looks like there is an issue in your low level UART driver, there are 
quite a lot of dropped frames due to bad FCS/ACCM drop, it can happen of 
course from time to time, very unlikely though for a given try, and 
never that much !

As well, it seems your UART tx routine does not work properly, there are 
way too much LCP retries, as if the remote end never get most packets.

Before checking anything else, you should check that frames on wire are 
exactly what the PPP stack wanted to send, and check that all bytes on 
wire are actually processed into the PPP input function.

Sylvain


signature.asc
Description: Digital signature
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] LWIP+PPPos(GPRS)

[Sylvain Rochet]

Hi,

On Tue, Mar 27, 2018 at 06:52:44AM -0700, bakmurat wrote:
> 
> *Modem transmits the following data:
> CONNECT 720   
>   
> ~ÿ}#À!}!}!} }8}"}&} } } } }#}$À#}%}}8}0D}'}"}(}"™Ë~...  ...~ÿ}
> #À!}!}!} }8}"}&} } } } }#}$À#}%}}8}0D}'}"}(}"™Ë~
>   
> NO CARRIER 

"NO CARRIER" indicate a failure, are you sure pre-PPP stage actually 
work ?

Sylvain


signature.asc
Description: Digital signature
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] upgrade from 1.4.1 to 2.0.3

[Sylvain Rochet]

Hi Mattia,

On Thu, Mar 08, 2018 at 04:39:03PM +0100, Mattia Settin wrote:
> Hi
> Thanks
> Buh how is possible that: with an operative system sys_timeouts_mbox_fetch 
> call
> sys_check_timeouts() which is the handle timeouts for NO_SYS==1.
> Is the comment of sys_check_timeouts()  wrong ?

Well, I agree the comment could be improved for clarity. When we fixed 
timers for NO_SYS==0 systems sys_check_timeouts was actually set 
static[1] so it wasn't possible to mistakenly call this function. Looks 
like it was changed when mbox handling moved to another file, therefore 
clearing the static modifier.

Sylvain


[1] 
http://git.savannah.nongnu.org/cgit/lwip.git/tree/src/core/timers.c?id=6adeb706a699da10f2841eea3671546407ec413a#n293


signature.asc
Description: Digital signature
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] upgrade from 1.4.1 to 2.0.3

[Sylvain Rochet]

Hi Mattia,

On Thu, Mar 08, 2018 at 09:14:33AM +0100, Mattia Settin wrote:
> Yes, but sys_now is required even for timeouts for NO_SYS==0 (LWIP_TIMERS =
> 1). It this correct ?

This is correct, sys_now() is now necessary for all systems, furthermore 
it should be bound, at best, to a monotonic clock source.

Sylvain


signature.asc
Description: Digital signature
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Crash when doing stresstest with ppp and sockets/UDP

[Sylvain Rochet]

Hi,

On Thu, Dec 21, 2017 at 02:11:22PM -0700, zulu4711 wrote:
> 
> The thread that is started that takes the SIO data and feeds them to 
> pppos_input() was something I did as I understood from Simon that if 
> PPP_INPROC_IRQ_SAFE is 1, that was safe to do.
> 
> Can you explain to me if these assumptions are correct ?

Why are you not reading the PPP documentation ? The documentation 
explicitely state it is not unless you are very very very careful on 
what you are doing (hint: asking this is enough evidence that you are 
not). I already told you why IRQ safe and thread safe are not the same 
thing.

Sylvain


signature.asc
Description: Digital signature
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Crash when doing stresstest with ppp and sockets/UDP

[Sylvain Rochet]

Hi zulu4711,


On Thu, Dec 21, 2017 at 03:06:14AM -0700, zulu4711 wrote:
> 
> Yes, it seems like a threading violation like I had before and this is
> surely because of me not having a full insight to what is legal to call and
> what is not legal to call in the stack when running in threaded mode.
> 
> I checked, and I called ppp_close() from another thread than I called
> ppp_input() and I guess thats a big "no-no" ?

Of course it is, almost all ppp_* functions are *NOT* thread safe. You 
have to use pppapi_* functions outside the lwIP core thread.

While we are at it, I did not bother reading your code for correctness 
on this part, please check your PPP input function, only 
pppos_input_tcpip input method is thread safe.

You really should read the PPP documentation.


> It seems that 75% of the problems newcomers like myself is due to 
> threading problems.

Because threading is hard, it is really, really hard. This is why each 
time you call a function you have to ask yourself whether you are 
allowed to call it in this context or not.

On a more general note, that not necessarily apply here, before starting 
a project you should ask yourself whether a RTOS is actually necessary, 
generally it's not, from a not necessary at all to can be easily avoided 
range. Not using an RTOS makes everything an order of magnitude simpler, 
despite the overall belief of the contrary.


Sylvain


signature.asc
Description: Digital signature
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Advise on PPPoS implementation

[Sylvain Rochet]

Hi,

On Sun, Nov 05, 2017 at 08:05:28PM +, Raivis wrote:
> 
> Here is the original stm32 lwipopts.h:
> https://pastebin.com/LEueShJv

Well, I'm confident CHECKSUM_GEN_* values set to 0 won't work when using 
PPPoS. I know none hardware UART able to compute them on the fly on HDLC 
formatted packets...

Sylvain


signature.asc
Description: Digital signature
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Lwip tcp-stack reliability issue when using non-reliable network?

[Sylvain Rochet]

Hi Itzik,

On Tue, Nov 07, 2017 at 06:40:52PM +0200, Itzik Levi wrote:
> Hi Sylvain,
> 
> Thanks for the response!
> 
> Just tried disabling both CORE_LOCKING and CORE_LOCKING_INPUT and
> unfortunately encountered the same problem.
> 
> I'm probably missing something, but what... loss-less stream works
> excellent, without any corruption, might be some kind of internal tcp queue
> corruption while congested?

It looks like a thread safety issue, but you seem to do things well 
(PPPAPI, pppos_input_tcpip, socket API, rx/tx mutex), but could you try 
setting LWIP_NETCONN_FULLDUPLEX since you are using rx and tx from 
multiple threads ?

Sylvain


signature.asc
Description: Digital signature
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Advise on PPPoS implementation

[Sylvain Rochet]

Hi,

On Thu, Nov 02, 2017 at 11:15:18PM +, Raivis wrote:
> Hi,
> 
> I tested with UDP, and it didn't work.
> 
> But, whole day, I've been working on porting the PPP GSM interface to unix
> system. Took me a while since, I hadn't worked with LwIP at this detail
> before.
> 
> Thankfully, I can confirm it works on my linux machine, but not on stm32.
> So I've probably made a mistake somewhere with stm32.
> 
> Now that I have a working system, I can compare it to stm32 and see 
> what goes wrong, and try to solve it. My main suspect is the way I'm 
> using HAL layer for serial transmission. (which is still odd, since 
> PPP get's the IP)

This is not necessarily odd, the stack path is totally different between 
a tx packet which source is the PPP stack itself and a tx packet which 
source is external to lwIP such as a UDP or a TCP packet generated from 
your user code. If you look closely at the PPP source you will see that 
the path distinction actually goes down to the PPP low level protocol 
(oS,oE,oL2TP).

And it matters, it matters a lot, frames sent by the PPP stack itself 
are mostly driven by received packets (we are negotiating with a 
classical do-don't-will-won't manner), meaning tx caller is called in 
the exact same context of the rx context. Rationale is the same for 
packets sent from user applications, they are sent from the current user 
application context (unless you are using one of messagebox driven APIs 
indeed). Context for both output paths *MUST* *BE* the same.

The more you say, the more I am suspecting a usual violation of lwIP 
contexts (threads, interrupt handlers) requirements. Are you sure you 
are using the proper PPPoS input API for your case ? Are you sure you 
are not using lwIP RAW API outside your lwIP core context ?

Sylvain


signature.asc
Description: Digital signature
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Advise on PPPoS implementation

[Sylvain Rochet]

Hi,

On Thu, Nov 02, 2017 at 05:02:36PM +, Raivis wrote:
> That's a very good, point, I've been so frustrated that it didn't occur to
> me that I can just print the packet in my serial function.
> 
> Apologies I somehow over glanced your suggestion before.
> 
> I enabled the PPP_DEBUG and PRINTPKT_SUPPORT, and removed all filters from
> ppp_dump_packet() in utils.c, leaving just "pp_dbglog()"  function call.
> 
> 
> From my inexperienced point of view, the PPP side seems to work fine I
> guess.

It is, pppos_netif_output() is the last step in the lwIP PPP stack, it 
means (if it succeed, which is the case here), that your serial output 
callback was called.


> Is it something to do with netif?

I don't understand to which scope this question apply; The netif is 
properly configured for me, we can undoubtfuly see the TCP SYN attempt 
in the debug log, meaning the packet goes down all the stack up to your 
serial low level writer.

If you are talking about your low level flow serial driver, it looks 
fine from here, you already said you saw the TCP packet properly sent on 
wire.

However, there might be some missing dark magic in your dialup 
chatscript ("AT" commands) before starting the PPP session. Your modem 
accepts the PPP session and set a apparently usable IP address so it 
should work but, well, some of these modems (all?), especially cellular 
ones, have some quirks[*] in their firmwares.

   [*] I'm saving a strong word here


Maybe you could try with UDP first instead of TCP; I don't think it 
would help in this case but we never know.


Sylvain


signature.asc
Description: Digital signature
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Advise on PPPoS implementation

[Sylvain Rochet]

Hi,

On Wed, Nov 01, 2017 at 03:22:07PM +, Raivis wrote:
> Hi,
> 
> I just connected the satellite modem to the micro-controller, and I get the
> same results. Where I'm able to establish the PPP session, but it won't
> connect to my TCP server.
> 
> I wanted to ask, is there a debug define I can enable which would let me
> know what bytes it tried to transfer over the serial? So I'm able to verify
> that, that is actually working?

You can easily add one in your serial low level driver, which is even a 
better place than before we call low level handlers; your driver might 
still drop an output buffer for whatever reason.

Anyway, as previously said, enabling PPP_DEBUG, PRINTPKT_SUPPORT, and 
removing IP filters in ppp_dump_packet(), is, in my opinion, the first 
thing to do.

Sylvain


signature.asc
Description: Digital signature
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Advise on PPPoS implementation

[Sylvain Rochet]

Hi,

On Thu, Oct 26, 2017 at 12:34:16PM +0100, Raivis wrote:
> 
> Any other ideas, what I should be looking for or what could be the cause?

I'm confident lwIP isn't the problem here, you can still enable PPP 
debugging PPP_DEBUG and PPP print packet support with PRINTPKT_SUPPORT. 
Since you are having an issue with IP packets you might want to remove 
packet print filtering in the ppp_dump_packet() function.

Anyway, this is the first time we hear of IP packets not working at all 
once PPP session is properly established. We usually have to deal with 
session establishment issues and, unfortunately usual, threading issues 
in packet input path.

Sylvain


signature.asc
Description: Digital signature
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Advise on PPPoS implementation

[Sylvain Rochet]

Hi,

On Wed, Oct 25, 2017 at 09:27:12PM +0100, Raivis wrote:
> 
> In any case here is my log up to the point, where it starts to re-transmit
> the TCP packet over and over again:

Looks like PPP is working properly here. Do you actually receive those 
TCP packets on the remote side ?

Sylvain


signature.asc
Description: Digital signature
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] PPPOS udp error

[Sylvain Rochet]

Hi,

On Tue, Aug 01, 2017 at 09:10:58AM -0400, Patrick Klos wrote:
> On 8/1/2017 2:06 AM, parwat...@yashaswinies.com wrote:
> >Hi,
> >  Here i have attached lwipopts.h file for our configuration. I need to
> >run 4 udp clients on this stack but currently i am running one udp client.
> 
> I would recommend increasing the number of pbufs (PBUF_POOL_SIZE) and the
> size of the heap (MEM_SIZE) and see if your system runs longer?  If so, that
> would imply you have a resource issue that you can look for?  If not, then
> the problem is probably someplace else?
> 
> >I am sending data in loop here bellow i have added part of code t
> >
> >
> >int pppudpsenddata(char *buffer, u16_t len) {
> >int status;
> >struct pbuf* pbuffer;
> >pbuffer->next = NULL;
> 
> If this is your actual code, then you have a HUGE BUG right here! You are
> trying to set 'pbuffer->next' BEFORE pbuffer has a valid pointer.  That
> can't be good!  :o)   (I'm surprised your compiler didn't warn you that
> you're using a variable before it has been initialized?!?)
> 
> Patrick Klos
> Klos Technologies, Inc.
> 
> >pbuffer = pbuf_alloc(PBUF_TRANSPORT, len, PBUF_POOL);
> >memcpy(pbuffer->payload, buffer, len);
> >pbuffer->len = pbuffer->tot_len = len;
> >status = udp_send(sock, pbuffer);

Furthermore pbuffer->len and pbuffer->tot_len are already set by 
pbuf_alloc... overriding them can't be good... you must take time to 
understand how lwIP chained pbuf should be handled. I am confident you 
are leaking pbufs here as well as a buffer overflow.

Sylvain


signature.asc
Description: Digital signature
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] TCP problems using pppos on stm32

[Sylvain Rochet]

Hi Roman,

On Wed, Jul 26, 2017 at 06:08:55AM -0700, Roman wrote:
> Hi, lwip. I still can't solve my problem, it has been going on for a long
> time, and I feel very stupid.
> When I stopped using sys_timeout / sys_untimout and started using the
> FreeRTOS timers, the average transmission time was about 15 minutes when I
> removed the FreeRTOS timer and started using pppos_input_tcpip () in the
> while cycle, the average transmission time was approximately 5 minutes. What
> do I mean when I say "average transmission time": through sockets I
> continuously send a small message to the server with a specified period, and
> the server answers me.
> As can be understood from what I said above, the situation only worsened,
> but I hope this will help to localize the problem.
> When I tried to debug a program, I noticed that when the transfer stops in
> the tcp_out () function, the tcp_out_segment () function is no longer
> called.
> My modified modem driver: modem.c
>   

I'm no TCP expert. But, since it involve PPP, could you at least check 
that PPP is not the issue here by testing the throughput over a long 
period of time using simple ICMP or UDP packets ?  You really have to 
troubleshoot layer by layer.

Sylvain


signature.asc
Description: Digital signature
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Fwd: problems in pppos

[Sylvain Rochet]

Hi,

On Wed, Jul 26, 2017 at 03:28:22AM -0700, parwat...@yashaswinies.com wrote:
> Hi,
>   Thanks , i resolved that issue ,now i need to know that for reading data
> is we need to poll udp_recv fuction or call back fuction..?

Please read the documentation before asking dumb question. The default 
interface issue was already pretty dumb but here we are talking about 
the very basic API documentation.

Sylvain 


signature.asc
Description: Digital signature
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Fwd: problems in pppos

[Sylvain Rochet]

Hi,

On Tue, Jul 25, 2017 at 11:27:22PM -0700, parwat...@yashaswinies.com wrote:
> Hi,
> We are finding error in udp send like no route after connection of
> getting ip form ppp connect. i attached log please give some suggestions to
> solve it.

Is your PPP interface the default one ?  See ppp_set_default.

Sylvain


signature.asc
Description: Digital signature
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Fwd: problems in pppos

[Sylvain Rochet]

Hi,

On Fri, Jul 21, 2017 at 05:32:22AM -0700, parwat...@yashaswinies.com wrote:
> 
> (...)
> 
> sys_timeout: 0x21001308 msecs=6000 handler=(fsm_timeout) arg=0x21001290

Are you sure your timer port is working ?  sys_timeout() is called but 
it seems that scheduled timeout functions are never actually called.

Sylvain


signature.asc
Description: Digital signature
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Fwd: problems in pppos

[Sylvain Rochet]

Hi,

On Fri, Jul 21, 2017 at 01:58:04AM -0700, parwat...@yashaswinies.com wrote:
> Hello all,
>As per your suggestion i have moved to lwip 2.0.2 ,now i m getting issue
> in network phase, here i have attached log with this mail please tkl, and
> suggest us to move forward.

This trace isn't very useful, please enable PPP_DEBUG and PRINTPKT_SUPPORT.

Sylvain


signature.asc
Description: Digital signature
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] TCP problems using pppos on stm32

[Sylvain Rochet]

Hi Roman,

On Thu, Jul 20, 2017 at 11:29:48PM -0700, Roman wrote:
> Hello again, 
> I think the problem may be in  my modem driver
>   . Maybe someone can
> check
> Regards, Roman

There is at least one obvious mistake here, but I'm pretty sure that's 
not what fail here. You are calling sys_timeout/sys_untimout functions 
outside the lwIP core thread, doing that is not thread safe. Other than 
that it looks pretty well engineered, you are using pppos_input_tcpip 
and so on, which is the right thing to do in your case.

I bet you are using the Socket or Netconn API in your task handling the 
TCP session, which is right either.

Sylvain


signature.asc
Description: Digital signature
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Fwd: problems in pppos

[Sylvain Rochet]

Hi,

On Thu, Jul 20, 2017 at 02:11:41AM -0700, parwat...@yashaswinies.com wrote:
> 
> Hello all,
>I am new to lwip 1.4.0  stack. i am trying ppp over serial port for small
> ppp connect test, but its getting strucked in networking phase here i have
> attached log also please suggest us to move forward.

PPP stack in lwIP 1.4.0 is awfully old, lwIP 1.4.0 itself was released 6 
years ago (which is already quite a lot) but this is worse for the PPP 
stack. Please switch to lwIP 2.0 first.

Sylvain


signature.asc
Description: Digital signature
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] PPPoS: ppp session disconnect if hit bad fcs for LCP packet

[Sylvain Rochet]

Hi Axel,

On Sun, Jul 16, 2017 at 02:51:01PM +0800, Axel Lin wrote:
> 
> I'm running on a STM32F4 platform.
> 
> The driver uses  below settings:
> 
> /* Fill init structure with common DMA settings */
> dma_init_structure.DMA_PeripheralInc   = DMA_PeripheralInc_Disable;
> dma_init_structure.DMA_MemoryInc   = DMA_MemoryInc_Enable;
> dma_init_structure.DMA_Priority= DMA_Priority_VeryHigh;
> dma_init_structure.DMA_FIFOMode= DMA_FIFOMode_Disable;
> dma_init_structure.DMA_FIFOThreshold   = DMA_FIFOThreshold_Full;
> dma_init_structure.DMA_MemoryBurst = DMA_MemoryBurst_Single;
> dma_init_structure.DMA_PeripheralBurst = DMA_PeripheralBurst_Single;
> 
> /* Initialise RX DMA */
> DMA_DeInit( peripheral->rx_dma_config.stream );
> dma_init_structure.DMA_Channel=
> peripheral->rx_dma_config.channel;
> dma_init_structure.DMA_PeripheralBaseAddr = (uint32_t)
> >port->DR;
> dma_init_structure.DMA_Memory0BaseAddr= 0;
> dma_init_structure.DMA_DIR= DMA_DIR_PeripheralToMemory;
> dma_init_structure.DMA_BufferSize = 0x;
>  // This parameter will be configured during communication
> dma_init_structure.DMA_Mode   = DMA_Mode_Normal;
> DMA_Init( peripheral->rx_dma_config.stream, _init_structure );
> 
> driver->peripheral->rx_dma_config.stream->NDTR  = size; // 4096
> driver->peripheral->rx_dma_config.stream->M0AR  = (uint32_t)data;
> driver->peripheral->rx_dma_config.stream->CR   |= DMA_SxCR_EN;
> USART_DMACmd( driver->peripheral->port, USART_DMAReq_Rx, ENABLE );
> 
> The driver uses DMA with circular mode, (the buffer size is 4096).
> I'm still not clear why always lost 63 chars.
> But it looks like not lwip problem but uart driver problem.

dma_init_structure.DMA_Mode = DMA_Mode_Normal;

Are you sure that's circular ? If I remember correctly STM32 shitty DMA 
controller doesn't support DMA auto restart in normal mode (next pointer 
feature), so you might lost a few bytes when restarting DMA after a DMA 
interrupt in normal mode.

Thank you Patrick for the deep analysis of the bytestream ! :)

Sylvain


signature.asc
Description: Digital signature
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] lwip2.0.2 l2tp question

[Sylvain Rochet]

Hi,

On Thu, Jul 06, 2017 at 11:10:41PM -0700, odobryabov wrote:
> Yes, you are right, these are just echo requests and replies:
> 
> ppp phase changed[1]: phase=10
> pppol2tp: input packet, len=0, tunnel=21944, session=8324, ns=0, nr=0
> rcvd [LCP EchoReq id=0x1 magic=0x5e33e1ff]
> sent [LCP EchoRep id=0x1 magic=0xb4b7bbcf]
> pppol2tp: input packet, len=0, tunnel=21944, session=8324, ns=0, nr=0
> rcvd [LCP EchoReq id=0x2 magic=0x5e33e1ff]
> sent [LCP EchoRep id=0x2 magic=0xb4b7bbcf]
> pppol2tp: input packet, len=0, tunnel=21944, session=8324, ns=0, nr=0
> rcvd [LCP EchoReq id=0x3 magic=0x5e33e1ff]
> sent [LCP EchoRep id=0x3 magic=0xb4b7bbcf]
> pppol2tp: input packet, len=0, tunnel=21944, session=8324, ns=0, nr=0
> rcvd [LCP EchoReq id=0x4 magic=0x5e33e1ff]
> sent [LCP EchoRep id=0x4 magic=0xb4b7bbcf]
> .
> pppol2tp: input packet, len=20, tunnel=21944, session=0, ns=2, nr=4
> pppol2tp: input packet, len=20, tunnel=21944, session=0, ns=2, nr=4

That's a clue, L2TP session is restarted here in the middle of perfectly 
working LCP probes.


> .
> pppol2tp: input packet, len=0, tunnel=21944, session=8324, ns=0, nr=0
> rcvd [LCP EchoReq id=0x1c magic=0x5e33e1ff]
> sent [LCP EchoRep id=0x1c magic=0xb4b7bbcf]
> pppol2tp: input packet, len=45, tunnel=21944, session=0, ns=3, nr=4
> pppol2tp: input packet, len=0, tunnel=21944, session=8324, ns=0, nr=0
> rcvd [LCP TermReq id=0x3 "User request"]
> LCP terminated by peer (User request)
> 
> May be the problem is in that timeout message:
> 
> pppol2tp: input packet, len=0, tunnel=47089, session=35933, ns=0, nr=0 
> rcvd [LCP ConfReq id=0x2  ] 
> sent [LCP ConfAck id=0x2  ] 
> pppol2tp: timeout 
> sent [LCP ConfReq id=0x5  ] 
> pppol2tp: input packet, len=0, tunnel=47089, session=35933, ns=0, nr=0 
> rcvd [LCP ConfAck id=0x5  ] 
> netif_set_mtu[1]: mtu=1450 
> ppp_send_config[1] 
> ppp_recv_config[1]
> 

> But if LwIP reached running phase, doesn't it mean l2tp initialisation was
> clear (even with that timeout)?

That's strange indeed, it looks like your L2TP server is not sending a 
packet acknowledging the ICCN packet (any packet with peer nr greater 
than our ns).

Could you try replacing

  if (l2tp->iccn_retried >= PPPOL2TP_MAXICCN) {
pppol2tp_abort_connect(l2tp);
return;
  }

by

  if (l2tp->iccn_retried >= PPPOL2TP_MAXICCN) {
PPPDEBUG(LOG_DEBUG, ("pppol2tp: reached max ICCN"));
l2tp->phase = PPPOL2TP_STATE_DATA;
return;
  }


Sylvain


signature.asc
Description: Digital signature
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] lwip2.0.2 l2tp question

[Sylvain Rochet]

Hi,

On Wed, Jul 05, 2017 at 09:02:02PM -0700, odobryabov wrote:
> 
> (...)
> 
> pppol2tp: input packet, len=0, tunnel=47089, session=35933, ns=0, nr=0
> Data hex: ff 03 c0 21 09 1c 00 08 d9 bb 4b cc 
  ^
  LCP
^^
Echo Request
   ^^
   ID
  ^
  Len
^^^
Magic

Why are there so much LCP packets once the session is established ?

It looks like the remote device is sending a lot of LCP echo request 
packets but that shouldn't be a problem.

Could you disable filters (at least LCP) in the ppp_dump_packet() 
function ? This way we will have packet dump of both rx and tx side.

Sylvain


signature.asc
Description: Digital signature
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] how to set the link up

[Sylvain Rochet]

Hi,

On Wed, Jul 05, 2017 at 04:55:24PM +, Noam Weissman wrote:
> 
> My DHCP task calls dhcp_start and wait for an IP. If there is a 
> timeout the task will assign a static default IP. You can do something 
> similar.

Erm, should I add that dhcp_start() is not thread safe ?

Sylvain


signature.asc
Description: Digital signature
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] how to set the link up

[Sylvain Rochet]

Hi,


On Wed, Jul 05, 2017 at 02:40:05PM +, Noam Weissman wrote:
> Hi Sylvian,
> 
> THANKS for pointing this out !!!. 
> 
> I am using the code I sent for several years and was not aware of that :-(

I wonder how that can happen, this is properly documented in the main 
API documentation file, Multithreading part:
  http://www.nongnu.org/lwip/2_0_x/raw_api.html


> The base code was taken from ST example !!

I had to play with STM32 HAL this year. I would not recommend using it 
for any usage whatsoever.


> I could not find netifapi_netif_set_link_up ... did you mean 
> netifapi_netif_set_up ?

I really mean netifapi_netif_set_link_up, however I'm not sure when it 
appeared. In case it doesn't exist, using tcpip_callback() should do the 
job anyway given the netif_set_link_up signature.


Sylvain


signature.asc
Description: Digital signature
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] how to set the link up

[Sylvain Rochet]

HI,

On Wed, Jul 05, 2017 at 03:01:49PM +0200, massimiliano cialdi wrote:
> On 05/07/2017 13:59, Noam Weissman wrote:
> >>From what I have seen the KSZ8081RNACA is an IEEE compliant PHY... that 
> >>means that the driver is standard.
> >
> >You need to read PHY_BSR register (1) and check bit 3 ... this is the link 
> >status. This is what I am doing in a task.
> >The reason for doing the above is that a PHY with RMII has no link interrupt 
> >and the simplest way is to read the
> >basic status register.
> Yes, I know, but I wonder where, in the code, to poll that register. Do I
> need to provide a task as you do? And netif_set_link_up() has to be called
> only from this task?

netif_set_link_up() is not thread safe and as such *MUST* *NOT* be 
called outside the lwIP core thread. You can use 
netifapi_netif_set_link_up() instead.

Anyway, this is purely optional, if you don't care how much time 
DHCP/IPv6 recover from a link down condition, you can as well call 
netif_set_link_up() just once in your netif init callback.

Same for administrative state, if your interface is never going to be 
administratively set down (which is the case for almost all cases unless 
you have to play with multiple interfaces and therefore may have to 
chose an outgoing path), then you only have to call netif_set_up() once 
in your netif init callback.

Sylvain


signature.asc
Description: Digital signature
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] lwip2.0.2 l2tp question

[Sylvain Rochet]

Hi,

On Fri, Jun 30, 2017 at 02:52:18AM -0700, odobryabov wrote:
> We don't use IPSec on our server.

Please enable PRINTPKT_SUPPORT and PPP_PROTOCOLNAME, you have to find 
out what is behind the mysterious retries we see on your first log, 
until now, we don't even know if those are PPP packets.

Sylvain


signature.asc
Description: Digital signature
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] lwip2.0.2 l2tp question

[Sylvain Rochet]

Hi,

On Thu, Jun 29, 2017 at 05:31:31AM -0700, odobryabov wrote:
> 
> ppp phase changed[1]: phase=10
> pppol2tp: input packet, len=0, tunnel=53427, session=47857, ns=0, nr=0
> pppol2tp: input packet, len=0, tunnel=53427, session=47857, ns=0, nr=0
> pppol2tp: input packet, len=0, tunnel=53427, session=47857, ns=0, nr=0
> pppol2tp: input packet, len=0, tunnel=53427, session=47857, ns=0, nr=0
> pppol2tp: input packet, len=0, tunnel=53427, session=47857, ns=0, nr=0
> pppol2tp: input packet, len=0, tunnel=53427, session=47857, ns=0, nr=0
> pppol2tp: input packet, len=0, tunnel=53427, session=47857, ns=0, nr=0
> pppol2tp: input packet, len=0, tunnel=53427, session=47857, ns=0, nr=0
> pppol2tp: input packet, len=0, tunnel=53427, session=47857, ns=0, nr=0
> pppol2tp: input packet, len=0, tunnel=53427, session=47857, ns=0, nr=0
> pppol2tp: input packet, len=0, tunnel=53427, session=47857, ns=0, nr=0
> pppol2tp: input packet, len=0, tunnel=53427, session=47857, ns=0, nr=0
> pppol2tp: input packet, len=0, tunnel=53427, session=47857, ns=0, nr=0
> pppol2tp: input packet, len=45, tunnel=53427, session=0, ns=3, nr=4

What's behind those packets, an IPSEC negotiation ? In this case that 
make sense since we do not support IPSEC.

Other than that I have no exact clue what is going on, it just look like 
your VPN server is trying to negotiate something past PPP running phase.

Sylvain


signature.asc
Description: Digital signature
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] PPPoS: How to config proper PPP_MAXIDLEFLAG?

[Sylvain Rochet]

Hi Axel,


On Thu, Jun 29, 2017 at 08:15:39PM +0800, Axel Lin wrote:
> Hi,
> While reading the code and the comment, I don't quite understanding
> how to config proper PPP_MAXIDLEFLAG.
> The comment says "If the link has been idle, we'll send a fresh flag
> character to flush any noise".
> 
> I'm curious in what kind of situation a user needs to change PPP_MAXIDLEFLAG
> and how to judge a good PPP_MAXIDLEFLAG setting?
> What happened if PPP_MAXIDLEFLAG is too small or too large?

Value mostly depends on how harsh the environment in which your device 
is going to be installed is, on which you will agree is something pretty 
hard if not impossible to guess... :-)

Anyway, max idle time is not really special here, any timeout set to 
retry or recover something is more or less a magic value anyway.


> I google and found some users set PPP_MAXIDLEFLAG to 0:
> (But I don't know if below comment is correct or not.)
> e.g.
> https://github.com/espressif/esp-idf/blob/master/components/lwip/include/lwip/port/lwipopts.h
> 
> /**
>  * PPP_MAXIDLEFLAG: Max Xmit idle time (in ms) before resend flag char.
>  * TODO: If PPP_MAXIDLEFLAG > 0 and next package is send during
> PPP_MAXIDLEFLAG time,
>  *   then 0x7E is not added at the begining of PPP package but
> 0x7E termination
>  *   is always at the end. This behaviour brokes PPP dial with GSM 
> (PPPoS).
>  *   The PPP package should always start and end with 0x7E.
>  */

Well, they use a broken GSM modem, HDLC frames separated by a single 
flag character is perfectly conform to HDLC specifications.

Anyway, for GSM modems, since flag characters are not actually sent over 
the air, guarding each frame with two flags character does not consume 
more billed bandwidth so it does not hurt doing so.


Sylvain


signature.asc
Description: Digital signature
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] [LwIP 1.4.1] Ping length of 92 bytes via PPP crashes LwIP core/pbuf.c

[Sylvain Rochet]

Hi,


On Tue, May 16, 2017 at 09:13:56PM +0200, goldsi...@gmx.de wrote:
> Sylvain Rochet wrote:
> >I checked if the issue was still there is the current master/2.0 branch,
> >you are right, this bug was fixed in commit fb07a28c99 ("fixed bug
> >#36388 (PPP: checksum-only in last pbuf leads to pbuf with zero
> >length)") *FIVE* years ago.
> :-))
> 
> Thanks, for jumping in, Sylvain!
> 
> Marco, I know you always say you don't have the time to re-evaluate new
> verisons, but you could save us *and* yourself much time hunting those old
> bugs by just taking the time to upgrage ;-) There have been *many* bugs
> fixed since 1.4.1!

I can't agree more, putting 1.4.1 in production today looks like a 
mistake.


> The possibility of code size increasement is something I always wanted to
> investigate (and fix if required), but I haven't found the time to do so,
> lately... :-(

Well, last time we checked, with PPP enabled, lwIP core size 
increasement didn't cross the PPP code size decreasement:

https://lists.gnu.org/archive/html/lwip-devel/2015-03/msg00082.html

So, with PPP enabled, lwIP 2.0 is still probably lighter (or roughly 
equivalent) than 1.4. I'm too lazy to check if this statement is still 
true right now :-)


Sylvain


signature.asc
Description: Digital signature
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] [LwIP 1.4.1] Ping length of 92 bytes via PPP crashes LwIP core/pbuf.c

[Sylvain Rochet]

Hi,

On Tue, May 16, 2017 at 10:48:26AM +0200, Simon Goldschmidt wrote:
> Marco Jakobs wrote:
> > That one deals with this:
> > 
> > LWIP_ERROR("p_to != NULL", (p_to != NULL) || (p_from == NULL) || 
> > (p_from->len == NULL) , return ERR_ARG;);
> 
> WTF? "-len == NULL"???
> 
> > The assert comes from the ICMP routine ;-) :
> 
> I rather guess the bug is in PPP (from 1.4.1) allocating a pbuf with 
> len==0 at the end. Otherwise, you should see this bug on the ethernet 
> side, too.

I checked if the issue was still there is the current master/2.0 branch, 
you are right, this bug was fixed in commit fb07a28c99 ("fixed bug 
#36388 (PPP: checksum-only in last pbuf leads to pbuf with zero 
length)") *FIVE* years ago.

Sylvain


signature.asc
Description: Digital signature
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] PPPoS: Question regarding reconnect after connection lost

[Sylvain Rochet]

Hi Axel,

On Thu, May 11, 2017 at 07:55:44PM +0800, Axel Lin wrote:
> 
> Hi Sylvain,
> 
> In practice, it usually has application code sending data while PPP 
> disconnect. I use netconn API + FreeRTOS, so I have a thread keep 
> sending data to internet.
> 
> While PPP re-connect there is a period I need to send AT commands and 
> calling ppp_connect(), is there any thing I need to take care for my 
> application code while PPP discconect and re-connect?

No, if PPP is disconnected IP output packets are tossed[1].

Sylvain

[1] 
http://git.savannah.gnu.org/cgit/lwip.git/tree/src/netif/ppp/ppp.c?id=4171f39a72ed15cb394f7cb9b909c5b3a2068580#n505


signature.asc
Description: Digital signature
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] ping my own device's ip always timeout

[Sylvain Rochet]

Hi,

On Thu, Apr 13, 2017 at 04:40:53PM +0800, Axel Lin wrote:
> Hi,
> After my device join an AP and get the ip (e.g. 192.168.0.102).
> My device can ping the gateway ip and other devices in the same network.
> Other devices can ping my test device running lwip.
> But if I try to ping my own ip (192.168.0.102), it always timeout.
> This seems strange.  is this a normal behavior in lwip?

Short answer:

/**
 * LWIP_NETIF_LOOPBACK==1: Support sending packets with a destination IP
 * address equal to the netif IP address, looping them back up the stack.
 */
#define LWIP_NETIF_LOOPBACK 1

Sylvain


signature.asc
Description: Digital signature
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] PPPoS: Question regarding reconnect after connection lost

[Sylvain Rochet]

Hi Axel,

On Thu, Apr 06, 2017 at 08:58:10PM +0800, Axel Lin wrote:
> 
> Below is what I do to start PPP:
> 
> Send "AT+CGDCONT=,,"
> Send "AT+CGAUTH=[, [, , ]]"
> Send "AT+CFUN=1"
> Send "ATD*99***#"
> 
> ppp_set_usepeerdns(ppp, 1);
> ppp_set_auth(ppp, PPPAUTHTYPE_ANY, userId, password);
> ppp_connect(ppp, 0);
> 
> My understanding is after ATD*99***1#, I cannot send AT commands.
> So it's not clear to me if I need to re-send above AT commands after got
> PPPERR_CONNECT. Currently I just call ppp_connect(ppp, 30); to reconnect.

You have to resend AT commands to reconnect. You need to switch back 
your modem to command mode before, either by using DTR signal or by 
using a predefined escape sequence that could never happen in the PPP 
flow (which I do not recommend unless you are very careful with the 
chosen asyncmap).

Sylvain


signature.asc
Description: Digital signature
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Transfer Mibs of data over TCP

[Sylvain Rochet]

Hi,

On Mon, Apr 03, 2017 at 09:38:34PM +, Noam Weissman wrote:
> 
> Sorry I meant netconn_recv etc...

This is still very ugly (and wrong for my point of view on perfect 
software).

Waiting for something to happen for a given time should be achieved 
using the LWIP_SO_RCVTIMEO feature.

If netconn_recv aborts with ERR_MEM or any other fatal error means you 
have a more serious issue about your overall software design. Retrying 
over and over only hides the real issue.

Sylvain


signature.asc
Description: Digital signature
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Connect two machines running LWIP applications via WLAN

[Sylvain Rochet]

Hi,

On Tue, Apr 04, 2017 at 03:30:46PM +0200, Sylvain Rochet wrote:
> Hi,
> 
> On Tue, Apr 04, 2017 at 03:12:09PM +0200, Dirk Ziegelmeier wrote:
> > I sent this link because of the first answer:
> > 
> > 
> > It is not possible to bridge between wireless (client a.k.a. station mode)
> > and wired interfaces according to this thread on linux-ath5k-devel
> > <http://web.archive.org/web/20110925231256/http://kerneltrap.org/mailarchive/linux-ath5k-devel/2010/3/21/6871733>
> > .
> > One should set up NAT instead:
> 
> The master (access-point) of a wireless network must be aware of all 
> existing managed nodes, this is why you have to associate (and I hope 
> authenticate as well :-) ) your client. What you want to achieve with a 
> bridged wireless network is a wireless mesh network, which isn't 
> supported with basic equipments, and which is achieved using proprietary 
> protocols or with WDS for a very basic tree.
> 
> Knowing that, it is obvious that it doesn't work. In other words, for 
> general cases, layer 1 domain and layer 2 domain must be the same for 
> wireless networks.

Erm, I have to add that master can be bridged to a wired network, since 
it is the central point, and this is the only way (without mesh, WDS, 
blabla.) to bridge a wireless network and therefore extend the layer 2 
domain over the wireless layer 1 domain. The bridge limitation only 
applies to managed nodes (client).

Sylvain


signature.asc
Description: Digital signature
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users