the
hardware manual recommends.
And make sure your power supply can provide that current for that amount
of time,
which you'll find in the manual.
Sorry about that, but I used to work with the tech support for Simcom in
Argentina...
On 14/11/2014 10:06 a.m., Sergio R. Caprile wrote:
My view
Chrysn,
yes, Simcom tech department sucks... they've had some internal issues on
the move from SIM340 to SIM900.
They are chinese and english docs are poor and mostly non-existent.
We've had a tech contact long ago but hopefully I haven't contacted them
for years.
Regarding the hw, you are too
$ grep -R BeginPacketSend lwip/*
$
What are you talking about, Willis ?
Are we talking lwIP here ?
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users
Trying searching for those words in the list, I've been discussing about
that one or two months ago
If you can ping your lwIP from your shell, then the rest is
routing/natting/firewalling.
___
lwip-users mailing list
lwip-users@nongnu.org
Have you read the wiki ? http://lwip.wikia.com/wiki/Raw/TCP
Have you tried the working examples in the contrib tree ?
Vendors have the marketing idea of showing they are bigger and stronger,
more macho than the other vendors. Try simple working examples from the
contrib tree.
Something is not clear to me here...
PPPoS might be confused with PPP over SONET/SDH
You guys are talking about plain old PPP, RFC-1661, Point-to-Point
Protocol, which (by definition) works over any point-to-point link, as
long as it is full-duplex and can carry bytes (octets). I guess
OK, I think I'm starting to get a hint on what you do have and what you
are trying to do.
You seem to have a packet radio system, and you seem to need to route IP
over that packet radio system.
I will assume that you already studied and know your packet radio system
and you are sure it does not
$ grep -R VERSION programming/lwip/lwip
programming/lwip/lwip/src/include/lwip/init.h:#define
LWIP_VERSION_MAJOR 1U
programming/lwip/lwip/src/include/lwip/init.h:#define
LWIP_VERSION_MINOR 4U
programming/lwip/lwip/src/include/lwip/init.h:#define
LWIP_VERSION_REVISION 1U
I will try my best to understand.
You seem to have some Ethernet hardware related to the Arduino.
That hardware seems to have some library called EMAC doing something.
That something at least answers a ping, so there is at least some sort
of a fraction of a TCP/IP stack on it.
You've found lwIP
Here’s my problem:
Your problem is that you are confusing windoze sort of name resolution
based on netbios or whatever they do today, with DNS (Domain Name
Resolution).
The translation from a name to an address, name resolution, requires a
properly configured DNS server. The requester asks the
For ethernet packets, I'm claculating checksum in hardware but for TCP and
IP, its is in software only.
* My suggestions:*
* 1) Check for this*
* #define CHECKSUM_GEN_IP 1*
I checked above Macro in my opt.h and it is set to 1.
Then you have just found your problem.
If
Is it possible TI's lwIP bases on some release candidate or BETA-version?
Even though I do like TI, they, like any other vendor, will play with any
code to make their demo work.
I've seen infinite loops in Cortex-M3 libraries (Holtek), interrupt
routines preempting and calling non-reentrant
I don't agree, some vendors, like Atmel, have a perfectly clean lwIP port
announced as being production ready, and it really is.
Kudos to Atmel then !
The only problem with them down here is that their products are hard to get.
I used to have a strong sympathy for TI and I think I still have
There are 298 frames in your capture file.
Somewhere in the middle of it I see a 10.9.208.127 sending a TCP SYN to
port 80 to 10.9.208.210
Judging by the amount of crap it is sending, and the fact that it is
opening the connection, I assume 10.9.208.127 is your PC
Then, 10.9.208.210 must be your
By port I meant who did the work of porting the stack to your processor.
Sorry, I don't fully agree with your definitions of known to be good
or known to work. To me those are supposed to be OK. Your web server
is not lwIP code, how are you certain it works OK ? You can't have two
unkown variables
Can you at least explain what you are doing with what and post a capture
file ?
--
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users
Your problem is not with lwIP or the microblaze.
To Connect to a web api you need to know what the web api does and do
what it expects you to do. The only thing that this shares with a web
server is that maybe both will use TCP port 80 and maybe both will talk
HTML at some point.
You will choose
I assume the product you describe is some sort of soft core.
If it was an ARM, I would put a breakpoint at the exception vector, and
trace the registers back to the offending instruction. I suppose you can
do something similar, that's what exceptions are for.
I remember Simon telling you to look
or install PuTTY.
Right. That's what I do. With that knownledge however, I think you'd have
to explain what to do with telnet in this case...
haha, right, developing web server applications and not knowng HTTP
either... oh, these kids nowadays... good point Simon, sometimes I
forget I'm
Looking at your frames, the SIM900 outputs a PPP frame with HDLC address
and control bytes, while the SIM5216 does not.
I'm by no means a PPP expert, but just looking for PPP in wikipedia
shows this:
/The Address and Control fields always have the value hex FF (for all
stations) and hex 03 (for
To answer a ping to eth0 coming from eth1, lwIP has to actually route
the response. Is it capable of doing that or will it send it to the
gateway (which does not exist) ?
Have run Wireshark on your PC and checked if your lwIP device is
actually sending something ?
Have you followed the packet flow
My 2 cents:
frame 644 gets lost
...
frame 651 says send 624651
frame 652 repeats, why ? possible software problem here, short timeout ?
frame 653 is the retransmission
frame 654 ACKs it for good
frame 655 says send 624651 which in this context means resume sending
after frame 650. Your device
I beg your pardon, I don't understand what you are doing and what you
are trying to do.
I don't think you can netif_set_default() two interfaces, can you ? Two
defaults ?
And btw, lwIP won't route, or at least it was not designed to do it and
has a minimum support for it. Last time I checked
If you check the developers list, you'll see they are busy trying to get
1.5 out
The current git head has many bug fixes, no new experimental stuff
afaik, except for advanced development in IPv6 and PPP.
You can get specific patches from Savannah to fit your needs
I bet you won't find specific lwIP patches on this because it doesn't
seem to be an lwIP bug. Polling the ethernet controller every 10ms is a
very bad idea, unless you are absolutely sure there won't be more frames
arriving in that time frame than what can fit in its buffer. You should
interrupt
The web server in contrib (for RAW API) has minimal support for POST and
CGI-like functions. You can build an upload with that.
For a fork of this supporting minimal multipart/form-data in POST try mine:
http://scaprile.ldir.com.ar/cms/el-ingeniero/open-source-projects-im-working-on/lwhttpd/
It
Hi,
a system I used to work with, happened to solve this issue in a very
elegant way.
You need a tag, a hidden variable in your form, whose value will be
received by the browser when loading the form (SSI) and will be
incremented by the system at every form submission (CGI). If the
received tag
Justin,
I will assume you are using the raw API:
you should check the wiki for the documentation on the proper way to do
things lwIP:
http://lwip.wikia.com/wiki/Raw/TCP ;
the contrib tree for examples on the proper way to do things lwIP:
(check echo);
and LPCwhatever for what where you thinking
Dmitriy, you seem to have a non-working port and/or a non-working driver.
FCS errors are not intentionally generated, so you can't correct them
unless you know why they are there. So... I'll assume you mean those
errored frames belong to the lwIP board. FCS should be correctly
generated by a
Ola Norberto,
- VM´s network configured as NAT Network
Sorry, I don't know what that is, assuming your virtual machines +
network are properly configured, it doesn't matter wether they are
virtual or real, they are machines in one or many networks and can be
pinged if routed and not firewalled.
If IP checksums come out as 0x when you set them in lwIP for
hardware calculation, that means your system seems to be correctly
configured for that, lwIP sends 0x and the link-layer driver is
doing nothing (or at least it is not setting any bits...).
OK, so your IP checksums are
for lwIP, there is a wiki http://lwip.wikia.com/wiki/Raw/TCP and a
contrib tree plenty of (good) examples.
for TCP/IP there are books (and universities). Google is your friend,
along with Dr. Tanenbaunm, Comer, Stallings.
--
___
lwip-users mailing
Please post a wireshark capture. It is hard (if not impossible) to
divinate the dialog between them both in order to judge which one is not
following the RFC.
You must get a hub to plug both wireshark PC and lwIP device or run lwIP
in the same box. BTW, your device is... and the port is good
Tx: yes
Rx: if you free them properly then they shouldn't be scarce. Have you
tested this ?
I'm not familiar with lwIP under RTOS except that you must adhere to the
general rule of not calling the stack from different threads.
You should check your port with a known good application first. Try
I'm no DHCP expert, but, is there any reason why you have to see
something in wireshark when turning DHCP off ?
You have been leased an address for a period of time, whether you use it
or not is your problem (though I may be wrong).
Your pseudo-code looks right to me.
If you want to see something
I seem to understand what you are trying to do.
Support for CGI is maybe less than minimal in the contrib tree web
server; I don't know what Atmel did on this, if any. But, anyway, it all
comes down to the basic TCP functions you'll find in the wiki
http://lwip.wikia.com/wiki/Raw/TCP
You are not
You are using lwIP through RAW API
Do you have NO_SYS=1 or any OS ?
1.4.1 /HEAD I guess
The port is good because it have been validated with a known to work
application, not just the one you wrote ?
You are seeing an indication that looks like a memory problem. How
exactly are you freeing your
I think what you describe (and need) is a simple NetBIOS name server
(NBNS for short). It listens on a UDP port 137 for UDP broadcast queries
for its name, and responds to matches.
You could also configure the DHCP server to assign a DNS provided IP
address, so people would find your device based
I see what you mean.
1660c1660,1662
else if ((dhcp-state == DHCP_REBOOTING) || (dhcp-state ==
DHCP_REBINDING) || (dhcp-state == DHCP_RENEWING)) {
---
else if ((dhcp-state == DHCP_STATE_REBOOTING) || (dhcp-state ==
DHCP_STATE_REBINDING) ||
(dhcp-state ==
Well, I'm no DHCP expert either
Looking at the source and checking RFC-2131, REBOOTING state only needs
to verify an existing lease. That can be done by issuing a DHCPREQUEST
message with the known ip address.
Coherency suggests that given the address is correct, then the client
already has all
Vendor strikes again...
You should post this to TI's forums.
Your processor looks like an ARM processor, check the hard fault related
registers and determine why you are having that hard fault.
--
___
lwip-users mailing list
lwip-users@nongnu.org
I understand the wiki part on TCP does not talk about PBUFs, that is
correct.
The rest of my post, after what you quoted, stated that you should check
the contrib tree. Those example applications instruct on proper PBUF usage.
I'm glad you've found your problem.
Regards
If you are using an Atmel http server, you should check at the Atmel forums.
In case that server is coincident with the one in the contrib tree, and
also with the RAW API, and you are not using an OS (which you don't say,
btw), I can try to help.
I don't understand what you are trying to do, you
You should see your ping, and the ARP before that... do you ?
Did you configure for gratuituous ARP ? Did you see it ?
--
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users
Yes, looks like that to me.
Perhaps you have a broken timer implementation and it is expiring ahead
of time ?
Looks like a glitch in a real-time system.
--
___
lwip-users mailing list
lwip-users@nongnu.org
Perhaps if you share what you are doing ?
Is it the RAW API or ... ?
Is it NO_SYS=1 or an RTOS port ?
And your port is OK because ... ?
Have you run a known good application and it works flawlessly ?
Are you following the thread-related guidelines ?
Your application is ... and you call ... and
Martin H.,
First of all, what are you using ? Do you have an RTOS or are you
running on bare metal with NO_SYS=1 ?
Second, are you using the RAW API or what ?
Then, how exact needs this defined time to be ? You can call a send
function whenever you want, lwIP (at least the RAW API) is event
If you are running with NO_SYS=1, you don't have an OS and all you have
is a main loop or equivalent. From within than main loop you will always
call lwIP, no calls from interrupts. This is easy, right ? If you have
an asynchronous event, well, you will signal with a flag and take care
of it in
Again, you should check how you are handling timers in your port.
sys_check_timeouts() needs a consistent time base, it expects you
provide a sys_now() function which returns time in milliseconds.
You should call sys_check_timeouts() from your main loop as frequently
as possible so it does its
If you are using the raw api and no RTOS, then your port should (must)
be calling the lwIP timers function and you don't have to do anything
with timers
(that is what I meant by a broken timer implementation).
Your main should be something like
while(1){
There is a comment in mem.c:
/** If you want to relocate the heap to external memory, simply define
* LWIP_RAM_HEAP_POINTER as a void-pointer to that location.
* If so, make sure the memory at that location is big enough (see below on
* how that space is calculated). */
#ifndef
It's much safer to integrate this with linker script (for example
with attributes on gcc). Casting number to pointer does not
guarantee that other variable will no be placed in the same area (by
linker or other Dev using such tricks). Happy debugging when it
happens :)
Yes.
However, in this
What I would do, if I were in your shoes, is to write my app for lwIP,
and then either use PPP for those TCP/IP capable GPRS modules and a
layer-2 interface (netif) for the other ones.
This way, your app is always the same and you only change code for what
is below layer-3. You'll have to write
How would you access any application on any machine other than the one
connected to the Internet inside your home/workplace ?
Exactly.
A tap interface is no different from another Ethernet interface, so your
Linux box will route/firewall/NAT and that is a whole adventure which is
not related to
and a
layer-2 interface (netif) for the other ones.
This way, your app is always the same and you only change code for what
is below layer-3. You'll have to write your own netif, though.
lwIP is a TCP/IP stack which communicates to the outside world via
interfaces called netif.
I will assume you are using the RAW API, you are using no RTOS, and you
have set NO_SYS=1
A call to tcp_err callback y as indication of a problem in a connection.
It has been aborted (reset by the other end) or never setup (timeout on
connection attempt).
When called, you must free your own
Your lwIP version ?
Your API ?
Your port works OK because...
Do you happen to use an RTOS or not ?
The webserver you are using is ? The one in contrib tree ?
If your responses happen to be
1.4.1 or HEAD
RAW
I tested with echo and the other apps in contrib tree or something
equally convincing
No,
Yes it is.
(been on vacations)
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users
tcp_sent() is called when a frame arrives, your port notices it and
dispatches to lwIP, and it reckons it is a TCP ACK. All your timing woes
depend mainly on your port, as me and many others don't see that in ours
and we all run the same lwIP.
___
Sandra, lwip is stable, you should check your product.
As you probably know, there is no such thing as an IP connection, so if
you are specific on what you are doing and what is the problem you are
having, there is a chance to find a solution or at least the culprit.
If you want to take traffic
> What do you mean with proper value?
I mean the value you return when you exit in a function, the whole web
server code knows what the callee has done and needs to be done by means
of the returned value.
--
___
lwip-users mailing list
Hi Sandra,
You seem to have an issue that gets noticed with a traffic pattern. Try
to find a way to log stats somewhere because I can't imagine a way to
figure this out without logging or real-time debugging.
Try ARP flooding locally, maybe you are lucky.
You might have an improper driver leaking
> - If I need to wait for a handshake in the HTTP form, it would be fine
> if I start with a HTTP server. As I understand it, HTTP server is mostly
> a TCP server with some retries and the particular communication scheme
> (Get, post, etc.).
No it is not
>> A web server is a delicate piece of
Yes, same impression here, as Enrico said, your dup ACKs are yuour .65
machine asking for the lost frame to be retransmitted.
Your layer-2 driver seems to be broken.
--
___
lwip-users mailing list
lwip-users@nongnu.org
/**
* MEM_USE_POOLS==1: Use an alternative to malloc() by allocating from a set
* of memory pools of various sizes. When mem_malloc is called, an
element of
* the smallest pool that can provide the length needed is returned.
* To use this, MEMP_USE_CUSTOM_POOLS also has to be enabled.
*/
Enrico,
can you provide a trigger ? My wireshark screen is all green...
I mean, please provide an HTML that I can include in my code that you
know forces this behaviour.
I remember getting RSTs when POSTing to authorization required pages,
the browser sends the whole pack and the server stops
As a matter of fact, if I'm not wrong, it is the server who must close
the connection and not the client, so this is Chrome's bug.
However, you mentioned a "off by 1" in the window so I'll try to see
that and what the culprit.
Ciao
--
___
lwip-users
$ grep -R LWIP_SDK_DEBUG *
$
There is no such SDK for lwIP as lwIP is not a commercial product,
LWIP_SDK_DEBUG has been introduced by your vendor, and you should
address your vendor, whoever it is.
--
___
lwip-users mailing list
OK, I see.
I'll try to trash my server so it sends headers first and then status,
on two frames (I've spent a long time polishing it so it does not...
unless there is absolutely no room).
BTW, what is your MSS and so ? can you attach your lwipopts.h please ?
I might have some spare time tomorrow.
yes, you are right.
I don't remember seeing the RSTs last time I checked, I switched to my
own fork long ago, and as I don't have the time to look at it in detail,
I am not able to test for a "maybe" a bug.
Since Simon signals this one as a possible bug, I'll try to see how I
can help, as it
Perhaps his is not the place to look for that info, and I don't know if
you are looking for the POST method details in the HTTP spec or you want
working examples for doing that with lwIP.
In the first case, you should google for HTTP POST ;^)
In the second case, would you be so kind to describe
It is hard to suggest a solution when there is no description of the
problem.
If you are thinking on making changes to your code, you should upgrade
to the latest code, there's been lots of upgrades and bug fixes
and I don't think you'll find someone willing to help on 1.3.1
You mention
OK, RAW API and NO_SYS=1 then.
I guess this will be easier with socket or netconn, but since you
require small code and no OS, RAW API is great.
As the other guys remarked, an http client is quite complicated.
However, just sending a hardcoded POST is not (quite) complicated.
You need a simple
I forked because I wanted to have some stuff and it was really
complicated to coexist with the current state of CGI and POST.
Thanks for your compliments, I'd be more than glad to help in merging
and even maintaining.
I still have some stuff to add and fix in authenticated multipart POST,
I've
Your recv function looks fine, but since it is not called, it is quite
likely the problem is not there.
Please post your setup, check for return values, and by all means check
your driver and port. Please single step a received frame and see if it
is delivered to the stack and then to your
Sorry bom, please don't consider this as thread hijacking, I think
you'll find this useful too.
I do work on baremetal, and always thought a move like DP's is OK, I
don't see any problem with that. OS task switches would be seen by lwIP
as peripheral interrupts. As long as all lwIP calling code
There are two HTTP servers on the contrib tree.
Which one are you using ? RAW API or ?
The webserver worked more than OK the last time I checked. If you
modified it and it doesn't work, common sense dictates you rollback and
examine if this issue you notice can be observed on fresh code.
If you
There is no reference to 'GMAC' in the whole lwip tree.
That seems to be Atmel stuff and you should ask them
--
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users
Well, I'm by no means even close to an expert, but afaik that certainly
depends on how you configure lwip.
PBUF_RAM is a single consecutive chunk of RAM for a pbuf, taken from the
heap.
PBUF_POOL is a pbuf which is itself a chain of pbufs, which are chunks
of RAM taken from the pool.
Allocation
So I don't understand why calling sys_check_timeouts without any
delay yields a poorer performance than calling it or tcp_tmr at 250ms
pace.
Neither do I.
Either your port is broken or your code is not properly written and this
condition masks that out.
I think tcp_sent callback is
I'm not sure about the timers, but as far as I know ALL lwIP functions
must be called from within the same thread (context), you can't call
something from interrupt context and then call something from the main loop.
--
___
lwip-users mailing list
The RAW API is event driven code.
The ACK is handled as an ACK by lwIP. This means the window is updated,
the sent pbufs are freed, and you can send data again.
You can't send more data until you receive an ACK for your window size.
You can't queue more data until lwIP frees pbus (when you receive
It depends on what you mean by "context".
If you don't have any kind of OS running, you have one thread and
interrupt handlers, you can safely call lwIP RAW API functions from your
main thread. It is not safe to also call from interrupts. If your
application depends on interrupts, just set a flag
There is no "possibly" here, if you call lwIP RAW API functions from
within an interrupt, you can't also call them from the main thread or
other nested interrupts.
All calls to lwIP RAW API functions must happen from within the same
context, they can't interrupt themselves.
Check the examples in
lwIP runs under Un*x, that includes GNU/Linux and so Raspbian, hence the
Raspberry PI.
You already have a full featured TCP/IP stack there, why do you want to
run lwIP ?
--
___
lwip-users mailing list
lwip-users@nongnu.org
If you mean "UDP and TCP" at the same time, that depends only on your
available memory. If you compile TCP in and UDP in, and you have enough
code memory for it to run and data memory for them to use, then yes.
--
___
lwip-users mailing list
> I don't know where to start.
You could start by correctly describing what you are trying to
accomplish, with what, what API are you using, and what lies under.
lwIP version
API
OS ?
port: has it been validated ? (works OK with known good apps)
netif driver: same here
Application
Regarding
Hello Roland,
well, obviously lwIP does not know about Windoze or Linux on the other
end of the wire, and even though the http server could be picky about
that because the browser sends that info, it does not. There is
something that happens when you connect to the Linux box that triggers a
My understanding is that it is not safe to stop calling
sys_check_timeouts(). Even after a connection is closed, there is
housekeeping to be done due to the nature of TCP.
As per the wiki, I'm just another user but a contributor to the wiki.
Running AdBlock Plus I can live with wikia. You can
I can't answer your question, but the git head code is probably more
stable than 1.4.1
The developers are working on IPv6 integration and patches for bug
fixes. If you need PPP or IPv6 then definitely git head is quite better
than 1.4.1.
One of them will probably drop by and comment, afaik the
UDP is "message based", you provide the whole payload and it will be
sent in a datagram.
TCP is "stream" based, data will be sent as it thinks it is best. As
long as you don't set TCP_WRITE_FLAG_COPY in apiflags, tcp_write() will
handle your data by building a PBUF_REF for each call and chaining
If you have problems with a vendor demo, then you should contact your
vendor.
[lwip]$ grep DHCP_WAIT_ADDRESS *
[lwip]$ cd ../lwip-contrib
[lwip-contrib]$ grep DHCP_WAIT_ADDRESS *
[lwip-contrib]$
The piece of code you mention does not belong to lwip.
Besides that, do you actually have a DHCP
For what I can comment, that is certainly something you should ask your
vendor; that is vendor code, not lwIP code.
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users
You seem to be running out of memory, not enough buffer space to hold
the data.
Try enabling stats and logging to get a clue, or use the good old
breakpoint and single-step.
There is a (somewhat easier) fork of that server here:
Please read the wiki; your error callback will be called or an error
condition signalled on your receive callback when the connection is lost.
Your problem with resending requests seems to be the subtleties of the
HTTP and TCP protocols. In TCP, you either have a connection established
and can
Hi Colin,
I'm sorry I can't help, I'm not familiar with the socket API. Try
opening a new thread with your specific issue, and specify you are using
the socket API.
Please include file and line number where you see the packet is dropped.
As far as I can see, TCP drops because the upper layer can't
Sorry Enrico, I don't see any problem (other than the wrong checksums)
in your capture file. To me the sequence numbers are correct, and the
RST is correct as per the described client behaviour.
Ciao
--
___
lwip-users mailing list
I see wrong TCP checksums on your client side, in both capture files;
but that is common when capturing on the same machine and it has hw
checksum offloading
I see your point, your description is quite clear to me now, however, I
don't see that as a problem since the connection has already been
Hi Sandra,
glad to hear you solved that.
I personally don't trust vendor code, I bet we can now agree on that.
--
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users
> Regarding of you saying stuff about examples online, I can't find any
> more "complex" example out there. All the examples have a really
> simple design, client sends message, receives message back and then
> the connection is closed. Is there any examples out there where
> connections are
101 - 200 of 533 matches
Mail list logo
