Well, that is usually a "don't!". However, if you actually do know what
you are doing and properly handle the blocking, I guess you might get
away with that. I personally don't know how, wait for one of the top
guys like Simon.
However, I find it easier to run everything under the same context.
You
That may or may not work depending on what your _magic function_
"delay_ms" does. If it is blocking, you are busted.
A main loop is a main loop, you need to rx and you need to check
timeouts. Your accept callback will be called after the SYN is SYNACKed
and the SYNACK is ACKed back. For that, you
OK, so it seems you are correctly calling lwIP in the loop, and your
networking parameters look good.
However, I failed to ask how do you setup your netif. You don't tell.
You should do something like this before actually calling tcp_connect():
IP4_ADDR(&gw, 192,168,100,1);
IP4_ADDR(&ipaddr, 1
Yes, "ethernetif" is sort of the generic name used in the skeleton,
internals for a netif belong to the developer (that's the reason for my
'driveroutputfunction' comment on that line).
Well, if I'm not missing something important, it looks like you have a
problem on the driver/wire side. Try to fi
When you use the tun/tap interface in Linux, you have a tun/tap
interface in Linux. Nothing from lwIPland, just Linuxland.
As per my (sort of) expertise, you get what looks like another Ethernet
card attached to a network. There is your plain trusty old linux machine
on one side, there is your bran
I don't know what you mean by "lwIP tun ARP table", lwIP is oblivious to
tun/tap.
I guess you have an lwIP port running in a Linux machine, "connected" to
a tun/tap interface.
If you want to see the lwIP ARP table you go one place (e.g:
src/core/ipv4/etharp.c and discover the existence of static st
(crossposted from the developers' list)
So, summing up, you (the OP) want to have two IP addresses on one
Ethernet (physical) port. This has been asked several times on the list,
under several different subjects, and is perhaps hard to find. I suggest
you do some searches on the list.
Perhaps we c
Regarding your image, it didn't get through my mail, "An HTML attachment
was scrubbed..." and I'm too lazy to go dig it. Anyway... it belongs
here now:
http://lists.nongnu.org/archive/html/lwip-users/2018-06/msg00050.html
So you still want two hosts.
And as far as I can see, you need a bridge amon
You got things a bit confused.
lwIP is not a computer OS nor a device, is a TCP/IP stack. It provides
sevices for layer-3+. If you don´t need what rests over IP nor IP
itself, then you don't need lwIP.
Yes, you can use lwIP's "infrastructure" and have layer-2 protocols
coexist with the stack, you c
Hi,
I started long ago using 'minimal' for development and teaching.
I need a tap interface and the stack compiled to run as NO_SYS=1, as my
work is on bare metal stuff.
Yes, I use the lib. I guess there is no _need_ for it and I can just
compile lwIP and link to it as in a regular embedded project
Hi Dirk,
Well, I'm not good with makefiles but I guess I can transform
example_app into what I need. And I can always write a bash script.
Just as long as you keep the tapif and tapif_select(), I can keep going
with minimum effort.
Regards
___
lwip-user
UDP datagrams are carried by Ethernet frames. It is not lwIP but your
driver who allocates memory to hold those frames before handling them to
lwIP, which in turn will deliver to your application. The only way to
stop allocation is there.
Someone could also send pings of death, repeated SYNs...
If
Modbus/TCP is Modbus over TCP port 502, with a simple header (MBAP).
A Modbus master is quite simple, and unless you have to support all
intricacies of different brand proprietary stuff, it ends up being just
a couple of functions.
The only tricky part is the word alignment, since registers are
big
Well, besides the fact that one thing is TCP, layer-4, with its Maximum
_Segment_ Size and another is Ethernet, layer-2, with the number of
bytes in a frame, which is what you are seeing in wireshark;
You are on the right track. There are a number of algorithms to
gracefully handle the life of a tr
I don't know what you are doing 'cause you don't say, but if you are
using NO_SYS=1 there must be a main loop calling sys_check_timeouts() as
frequently as possible, it takes care of all timeouts.
You should check if your frames carrying your TCP SYNs are being
delivered or get lost in the driver.
So you have a perfectly working Ethernet host and you want WiFi. So you
plan to use another lwIP host as a module.
What I would do is to delegate the netif to the module, so basically the
netif running in the host will take care of delivering via the UART and
receiving from the UART.
However, you h
AFAIK there is no built-in AT send/expect engine, but lwIP does support
PPP over serial interfaces. As long as you manage to setup your whatever
in PPP mode, it will work.
You can have as many interfaces as your memory and drivers can handle,
but don't expect lwIP to route between them (not without
I fail to see what you are doing and what you are trying to do.
Do you mind putting names and addresses and describe what you do and the
expected behaviour ?
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip
Your modem will go into PPP mode once you instruct it to do so. Read
your manuals.
IP-forwarding = Routing
If host-A and lwip-A are in network A, and host-B and lwIP-B are in
network B, then host-A and lwiP-A can talk, and host-B and lwIP-B can
talk, but A and B can't talk to each other.
___
You have two interfaces, one in 10.something and another in 192.168.1.
You can communicate with hosts in either network but you can't be the
one letting the WiFi access "the board" nor "the board" access the WiFi,
that is routing, and lwIP does not route.
Somehow you have built a "gateway" in the I
OK...
You seem to need a tutorship or a crash course in networking followed by
a study of lwIP.
You need to first get a grasp of the layer model as an abstraction: if
you set things right, that is, if you assign the proper IP address and
open the proper TCP port, you will get a callback with a poi
What you see is the Naggle algorithm.
It is the old trade off, delay or throughput. If your application
requires throughput, you want it. If you do need short delay, it can
usually be minimized by some configuration function/option.
The RAW API lets you tweak mostly at will, but the interface is no
Completely missed the "20 second" part.
You don't remember wrong, and you know it ;^)
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users
Well, the RAW API is tricky and there is no such thing as half-duplex or
unidirectional communications in TCP, so I'd need to see your code.
You should (read: must) be calling sys_check_timeouts() frequently
enough for TCP to handle its internal timers; and since your current
problem is on the send
You can just check the code yourself, but no, sys_check_timeouts()
should return asap since it is meant to be called as frequently as
possible (afap?) and living in the main loop of many systems.
However, from time to time, something needs to be done, like for example
resending a TCP segment, so it
I may be wrong since I know nothing on sockets on lwIP, but I think I
remember reading Simon saying you can't have two threads using the same
socket. (or at least that is what I think I see on how the post is
formatted)
What I do know:
Following your capture file is hard; you provide a whole net c
OK, now I see.
Well, you _should_ (read _must_) check your port and your driver.
Perhaps your simplest application can do, but you should try one of the
apps in the app subtree or in the contrib tree. Those have been tested
by many users.
I can't help you further, I'm nil on anything other than RA
Perhaps if you could think your actions in terms of OSI layers it would
be easier to understand.
You say "before IP" but you draw "after IP" (well, sort of...), so I
don't really get what you need.
What is it that you are trying to accomplish, do you want to encapsulate
TCP/IP into an "ESP" (whate
IPSec's ESP !
The graphic you point to seems to depict the transport mode.
I guess there are hooks to do what this requires but I can't help you,
wait for Simon or someone with more internal knowledge of the stack.
I'll stay lurking in listen-mode as I'm curious on how to do this.
If I guessed correctly, you seem to be talking about the TCP reopen
issue, but your scenario is not clear to me.
You have an lwIP client connecting to a server
Someone closes the connection, or it is lost somehow.
The client retries the connection, does it succeed ? Apparently it does.
If connecti
A TCP server might handle many incoming connection requests, each one of
them will fire the accept callback.
That callback is responsible for acquiring any memory that it would need
for the application, and then will register callbacks for that instance
of the application. There is one instance per
... and did you think on capturing traffic with (for example) Wireshark,
or inspecting (using breakpoints) if the functions are called ? There is
no autostop code in there (at least not in lwIP, but that is surely
vendor code) so you need to check your system if you want to solve your
problem.
___
I fail to see where the problem is.
lwIP does not require an OS, as long as you can compile C code you are fine.
A port is basically what you described, you write your driver, you read
this:
http://www.nongnu.org/lwip/2_1_x/group__sys__layer.html
you modify architecture dependent files, and you put
Laurent used to participate on this list. I collaborated with a (very)
small part of the code, post your suggested/required changes on github
and we can follow up from there.
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mail
There is 6LoBLE, perhaps you would do with that.
The Bluetooth world is filled with protocols and profiles but most of
them protocols belong to BT and not to BLE, so you need to check for
something BLE specific.
Whether it is supported on the phone or not... I don't know.
_
I'm not well versed in sockets here, but since you are using sockets,
there shouldn't be application-related pbuf free issues if threading
rules are respected.
Somewhere in your vendor provided code, someone did not play by the
rules. You have an OS, you have a port, you have a driver, you have man
There is no modbusTCP on lwIP. Go to the ones who wrote that and ask
them for help.
1.3.2 is a version perhaps older than the STM32 itself, you should get a
more up to date framework for your endeavours.
Before you do that, try to know at least if TCP is connecting. ModbusTCP
is a simple protocol,
Tobias, lwIP can handle as many connections as your RAM allows; I guess
you are using the RAW API, but I fail to guess if lwIP is your server or
your client. My best bet is that it is your server.
Did you check your accept callback against the echo or http server in
the examples ? (apps, contrib tr
You have to find who is eating your pbufs and not releasing them. Are
you using the same pool for input and output ? (I'm lazy enough to skip
scrolling all your lwipopts file)
At first sight, you seem to have a problem in your driver and/or you are
not honoring threading rules.
___
lwIP does not route. That is, it does not know how to distribute traffic
among interfaces beyond some simple rules.
I don't know if you can switch default interfaces with sockets
(connections) open... do you just switch or you bring it down and then
up again ?
Can you capture IP traffic on at least
You have a problem in your port.
If you use NO_SYS=0, then it is "YES SYS", I mean, you need a SYS, an
OS, someone that provides all the system functions, and that includes
timing: sys_now()
http://www.nongnu.org/lwip/2_0_x/group__sys__layer.html
___
lwi
So, so far:
When switching default interface with connections open, traffic stops
going out on the former default interface (A) but starts going out on
the new one (B), but using the former address (addrA):
Default interface is A, traffic is going from addrA to addrX outside the
local network, def
Thank you Simon,
Then, if I understand correctly, this is expected behaviour (lwIP is
indeed routing here) and then either both default gateways get to route
both netif addresses or the connection has to be dropped and started
again (in order to be established from the other address).
Since the O
Well, this is perhaps pretty obvious, maybe, but did you happen to try
to lookup what those "errors" are ? Are they errors or _warnings_ ?
Do you known the engine in both compilers is different ?
Does your port use compiler extensions ? (You need to change those since
the engines are different...)
If you post a capture file, some people here might want to take a look
at it and diagnose the reason for the retransmissions. Otherwise, we can
not infer much.
Did you closely follow the UPGRADE guide in the 2.x documentation ?
Perhaps your Modbus provider can be a bit more helpful with you ?
(Modb
What I see is that the slave seems to respond but its response is not in
the capture.
This means that the frame is not getting there, it is getting lost
somewhere in between.
If the slave is an lwIP device, then it is quite likely your driver+port
are losing frames.
Vague questions usually get vag
Who pings who ? Who is who ?
Assuming both your MTUs are 1500 bytes, greater than 1472 means the
payload will not fit in a single IP datagram over a single Ethernet
frame. (20IP + 8ICMP + 1472payload = 1500)
Your sender will have to fragment and your receiver will have to
reassemble. Perhaps one of
lwIP202 v1.1 What is that ? That doesn't look like lwIP versioning scheme.
Where do you get that "message" about being unable to alloc pbuf in
recv_handler" ? There is no recv_handler in lwIP. That looks like a
driver that runs out of memory, as if you are not releasing your alloced
pbufs "somewher
There is no printf in lwIP, that is your own/vendor mechanism, and this
is where you should start checking for the reason triggering the msg.
Ask your vendor if it is not yours.
AFAIK your recv callback is incorrect, if your tcp_close() fails, you
retry later, you don't call tcp_abort() (I guess 2
Unfortunately I only know the RAW API and can't help you further. Did
you check the basics ?:
- core lwIP runs in a single thread. If your Ethernet is handled in
another thread, you don't call any lwIP functions from there, except for
the pbuf allocation/free functions; you queue your packets and t
Yes, I remember analyzing your capture file about 15 days ago and
pointing to that possibility. Glad it was a hit.
"lpc_low_level_output" is not something related to lwIP, it is your
vendor driver code. Ask your vendor.
Want to find it yourself ? Great! Then grab a debugger and place
breakpoints
If you are using the very same driver, it could still have been buggy
and happen to pass unnoticed until something triggered it.
The fact that the data gets lost when you call lpc_low_level_output()
means that it gets lost after it left lwIP. The only way I can see lwIP
running again (and destroyin
Your scenario ? I mean: IP addresses, masks, gateways. Sometimes wrong
configurations "just work".
Your netif setup ?
Your call setup ? How do you initiate your connection ? What does that
function return ? Are you using the RAW API ? The netconn API ? The
socket API ?
Threading rules ?
__
lwIP does not care about RMII, that is between your MAC controller and
your PHY controller. Whatever happens there is your driver's business.
Do you have two MAC controllers ? Or are you trying to handle two PHYs
with one MAC ? (Why would you do that ?)
1 IP 1 MAC 2 PHY: beyond my understanding, n
I don't think the same port will run on a preemptive and a
non-preemptive OS, even if it is the same OS.
Did you check your port ? It will surely rely on some semaphores/mutexes
for proper operation; I don't know how they will behave on a cooperative
scenario.
Anyway, your port provider should know
You forgot to include your device address. If it is 192.168.1.x it is
fine (unless it coincides with any other device in the network...)
The error callback is called when the connection request is rejected or
lwIP gets tired of waiting for an answer. Do you see the SYN in
wireshark or equivalent ?
Your msg is too long for me, I'm too lazy to read it and too dumb to
keep focus at the same time.
Your capture file is long too, but fortunately retransmissions happen
right at the beginning.
I see you are ACKing 100ms later, several frames later.
I see (at least once) that you ACK a frame and ms
mmm... the ACK number..., I think I've seen this one or two years ago,
search the list and or the patches for "one less" or something like that.
I'm not fresh on this, but I think that is the problem, the ACK to the
RST has the wrong number and causes a retransmission. I can't remember
if this is a
I guess this is what I remember... not exactly your problem nor a
helping hand but perhaps you can start digging here:
http://savannah.nongnu.org/bugs/?48328
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwi
ST driver code wasn't freeing all frames in the Ethernet controller on
ints, do you have the "working" version ? (can't tell you which one)
I particularly don't like watching screen snapshots, if you post a
capture I can try to look and let you know if I see something.
At birdseye, looks like you a
OK, I'll try to be more precise.
ST driver code wasn't properly handling receive interrupts from the
Ethernet controller. They just took the first frame in the buffer
without thinking more could have arrived since the interrupt fired.
Those frames remained there sleeping until a new one arrived, ca
Instead of speculating on a slow receiver, I would see traffic on the
wire and check my tcp_sent() callbacks.
You stuff the TCP buffer with tcp_write() and it will eventually get
sent, you can speed things up as you are doing by calling tcp_output(),
and the stack will let you know when your receiv
mmm...
The bug I mentioned is on the rx side, I see you are losing frames on
the tx side. There should be a frame between #4206 and #4207 that is
either lost inside your device or on its way to your PC.
The same pattern repeats where you mention, there is a missing frame
between #4315 and #4316.
I
Nope, I'm sorry, no further ideas on my side.
Since you can't upgrade, perhaps diffing against git commits around that
time or against git head would provide a clue on what to change.
There could be another bug report more related to your problem, I just
didn't find it but I haven't done an exhaust
Well, perhaps TI was short on examples but you can learn from the apps
section and those in the contrib tree.
> I actually didn't quite understand how to use tcp_sent() since [...]
When you open a connection (think you can be a server), you set the
environment to serve it and then setup an argume
If I were to debug this, I would use UDP, you can move a pin when
sending and be sure the msg will at least get to the driver (where we
think it is lost). TCP... well...
Then, every entry to the driver should end with a safe exit and due to
DMA a later "done" interrupt where the driver frees the bu
I understand your frustration but it is vendor generated, not lwIP's
fault. Say "bye, thanks" to your vendor "docs" (or the lack of them)
and dive here:
https://www.nongnu.org/lwip/2_1_x/ (or the version you're using)
The official source code tree has a directory named "apps" where you
If your device does not go to the Eth Rx ISR that is because either the
controller is not interrupting anymore or the OS is not accepting the IRQ.
pbuf_alloc() does not control your chip, your driver does.
Your driver should gracefully discard the incoming frame if it can't
accept its contents (put
Your scenario is composed of four main pieces of software (to name them
some way). lwIP will handle TCP/IP stuff but will not mess with your
controller. Your driver will. Your driver is not lwIP, it is your
responsibility. I guess you handled it to your vendor and are using
something that is vendor
OK,
I know Modscan is a Modbus master tool, so I guess you are polling your
device, which happens to be a slave, a server, a TCP listener.
You are trying to implement ModbusTCP where the PC running Modscan (and
I guess Wireshark too) will connect (send SYN) to the lwIP device.
Second issue:
Those
If you decide to generate checksums on lwIP, you MUST tell the
controller not to generate them.
You must check arg and newpcb in your tcp_accept() callback, follow the
examples.
Your tcpecho source is different from what I can see on lwIP git. I
won't check further.
I won't check the rest of your
The recommendations are to use separate pools for rx and tx so they can
not starve each other. Since PBUF_RAM is used for tx, then rx is
expected to use PBUF_POOL. I bet you can also use separate pools but I
don't know how.
Last time I checked, PBUF_RAM allocates a single block of memory. That
is
The lwIP stack will not work as a router unless you actually write the
routing code yourself. Since in your scenario the non-local address is
the device netif address, that should work. If it were some other host
in that very same network (172...) connected to the lwIP device, it
would not (unless
2- There is no need for a specific port for a specific processor. A port
of lwIP needs to handle the OS (if any), and some nice stuff on the
processor architecture that can help making things faster (and some
intricacies of the compiler). As long as there is a port for that core
and that OS (or non
Hi Sylvain,
last time I checked there were only hooks and the user needed to write
the routing function.
Is this remarkably different now ?
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users
501 - 575 of 575 matches
Mail list logo
