Priyanka
>> Any idea if lwIP TCP/IP stack is TCP-friendly?
Is that the question you meant to ask? Or perhaps "Contiki friendly"?
Ansering the question I think you meant...
lwIP is OS independent, so there is no reason it would not work with
Contiki. However you may find it tough with an MSP43
Tamas
To achieve 10 microsecond resolution across multiple boxes would require
a sync mechanism other than just ethernet packets arriving. PTP
(Precision time protocol, I assume) or a GPS chip could keep the timing
sync, and then a packet telling all boxes what time in the future to
start.
BTW -
Mason
In my phy interrupt, I use:
err_t tmp = tcpip_callback_with_block( s_HandlePhyInterrupt, NULL,
0);
That puts a callback to s_HandlePhyInterrupt into the tcpip thread.
Then in s_HandlePhyInterrupt is all the phy status processing and the
calls to netif_set_link*().
Hope that helps!
Ma
>> I loaded up wireshark to see what was happening.
>>
>> 192.168.1.26 is my desktop computer running windows.
>> 192.168.1.192 is the embedded system that's using lwIP.
>>
>> 2578207.992115192.168.1.192192.168.1.26Gryphon
1422- Invalid -
>> 2581208.194336192.168.1
>> I wouldn't automatically switch off the local netif though:
I want to add support to Simon's point: If the netif goes down, then
someone has to know where to look to figure out why. It kinda moves the
problem to another layer.
I appreciate trying to protect users from themselves, but using
>> If I understand correctly, you're saying that nothing should be done
>> either to detect the address conflict in the stack?
> Simon... I don't think we should automatically disable a netif.
Providing
> a callback for an "application" to react on it should be fine
Detection and reporting h
Mats
The behavior of sockets, even after being closed, they stick around for
a little while in TIME_WAIT state. This allows acks to complete, etc.
You cannot re-open that socket until that expires. For more details,
Google TIME_WAIT.
If you wait a couple of minutes, can you then reconnect? If
> ...
> Is this a correct approach?
Mats
I am using the sockets interface, not the raw interface. I prefer to
open a listener socket on my server, and let the systems handle the Port
number details. Perhaps someone with a bit more experience in the raw
interface may be able to reply.
Marty
> But I wonder, if both ends do close the socket normally, would the PCB
end up in a TIME_WAIT?
The reason for the TIME_WAIT (past the successful and ACK'd closes) is
to make sure wandering left-over packets don't show up in a newly opened
socket. Without the TIME_WAIT, some intermediate rout
> i see the DHCP Discover, DHCP Request and a ARP message
> who has IP xxx.xxx.xxx.xxx via wireshark but the ip
> address will not be assigned.
Check that netif->ip_addr (in lwIP 1.4.0) is zeroes before starting
DHCP.
Also, you can capture a working DHCP transaction from another system in
Wi
> Can i call tcpip_callback() from my application thread ? Is that what
you mean?
Yes, you can and should do that. I use this in my interrupt code:
err_t tmp = tcpip_callback_with_block( s_HandlePhyInterrupt, NULL,
0);
Then s_HandlePhyInterrupt() is called from the tcpip thread.
Other way
> I call tcpip_callback(dhcp_start(netif_default),0); from
> my application thread.
That syntax is going to call dhcp_start() from your application thread,
and pass the return value to tcpip_callback: not what you want.
Try netifapi_netif_common( &netif_default, NULL, dhcp_start);
Not sure i
> It solves my problem, but I would prefer to let opt.h untouched.
Artur
You need to figure out why your toolchain is not picking it up from
lwipopts.h. You will have constant problems if, as Krzysiek mentioned,
you are including the wrong copy. Do you have an ifdef in lwipopts that
is preven
But if i set the cycle time of the master slow, like 80ms and slower i
get an response and a retransmission of that response for every request.
request ->
<- response
<- retransmission
Fred
Your reponse needs to be acknowledged, and the acknowledgment (Ack) for
your previous response is in
> Could someone tell me in which file can i set the LWIP stack size?
Thanks
See TCPIP_THREAD_STACKSIZE
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users
> How can i fix this issue? Would you guys say it is a Stack specific
problem?
Fred
What "issue" do you see? Your postings so far have been clear enough
about what was sent and received, although AFAICT have shown expected
behavior for TCP/IP.
Please post the send-receive pattern you think
> But if i set the cycle time of the master slow, like 80ms and slower i
> get an response and a retransmission of that response for every
request.
> request ->
> <- response
> <- retransmission
Which end is lwIP?
Kieran
I'm assuming the response/retransmission is from lwIP. Hoping I
> The TCP_TMR_INTERVAL is the time the stack should wait for an ACK from
my master, right?
Yes, before it re-transmits.
> What is akward to me is that after the retransmission of LWIP which
happends in 30-40ms after the first response, the ACK for the response
arrives 1ms after the retransmissi
I hate it when I'm trying to be helpful and I'm just wrong. But I
subscribed also to learn, and that is one of the advantages of a forum
like this. Thanks for the corrections!
Regarding the traffic direction, the email archive here
http://old.nabble.com/Retransmission-behaviour--td34077302.html
Just found out about
http://lpcware.com/content/project/lightweight-ip-lwip-networking-stack
targeting NXP LPC parts. You might want to consider this. It has an
LPC EMAC based driver (lwip_lpc\nxpcommon\arch\lpc177x_8x\lpc17_emac.c).
Yes it is in the 177x_8x folder, but the EMAC block in the 17
Typically your driver is going to pass the packet back to lwIP via a
function like tcpip_input(...). Look at it just before that, and maybe
don't pass it in to lwIP.
Marty
From: lwip-users-bounces+martypomeroy=novabio@nongnu.org
[mailto:lwip-users-bounces
Well, assuming "unsigned char * packet" is a pointer to your received
byte array:
if ( (*(short *)&packet[12]) == 0x0800 && packet[23] == 0x11) // 0x800
is IP packet, 0x11 is UDP protocol byte in IP header
you have a UDP packet (verify those offsets are correct). You can look
at this befor
Make sure there is no higher priority thread monopolizing the CPU
elsewhere, which is preventing the lower priority lwIP from running for
relatively large chunks of time.
Marty
From: lwip-users-bounces+martypomeroy=novabio@nongnu.org
[mailto:lwip-users-bou
>> (unsigned int *)(p->payload+PACKET_HEADER),
vs:
>> p->payload+PACKET_HEADER,
>> Any reason why I wasn't able to copy it directly from p->payload?
You don't mention what compiler you are using, so here is something you
could check:
Since "payload" is void *, the compiler may p
It seems to me that it would be best to delete the paragraph in question
from the wiki page. The paragraphs that follow it provide the general
explanation. Users *must* figure this out for their system, and there
is no truly "common case".
Marty
__
>> Does anyone know of examples that have left the original lwip
directory
>> tree in place and simply referenced it in a make file?
Check out the wiki at http://lwip.wikia.com/wiki/LwIP_Wiki, especially
under Getting Started (from that page), the Platform Developer's Manual.
Just be aware
I honestly don't know if this is an issue, but on 1.4.0, my startup also
calls tcpip_init as below:
g_EmacSetMacFromRegs( (char *)&m_NetIF.hwaddr); // init MAC address
from the hardware
IP4_ADDR(ð0gw, 192,168,0,1);
IP4_ADDR(ð0ipaddr, 0,0,0,0); // for DHCP, start with this IP
IP4_A
Late to the party, but full duplex is first an issue for your hardware
and driver. If your hardware is set up to send and receive using DMA,
data can be coming in at the same time it is going out. As long as you
have enough receive buffers for the largest receive burst, and avoid
promiscuous mod
This is late to the party, but I always have a second ethernet card on
my PC. Configure it and your LPC1768 board with compatible static IP
addresses (192.168.1.nn with 255.255.255.0 for mask), and connect them
through a switch.
I don't know the particular example, but with a lot of these, you c
If I'm seeing this right, you are polling for link status, and want to
figure out which is the better way to poll.
First, all tcpip thread stuff MUST be done on the tcpip thread, so DO
NOT call it from the timer interrupt. Option 2 is eventually going to
cause errors.
But better still, most phy
g to
cause errors."
Funny fact about this, the things just keep working. True is I have only one
active connection but it's still funny.
But I definitly agree with you, just a funny fact :)
Danijel
Dne 23.5.2013 17:20, piše Pomeroy, Marty:
If I'm seeing this right, you ar
d: CALLBACK_STATIC %p\n", (void
*)msg));
msg->msg.cb.function(msg->msg.cb.ctx);
break;
default:
LWIP_DEBUGF(TCPIP_DEBUG, ("tcpip_thread: invalid message: %d\n",
msg->type));
LWIP_ASSERT("tcpip_thread: invalid message", 0);
break;
lpcware.com has an lwip setup. Disclaimer: I have not used this (I
wrote one for the 1788 before this was available, and it belongs to my
employer).
Get lpcopen_v1.03.zip (you might need to create a login). See the
software/lwip/lpclwip/arch for the LPC files you need.
LPC has a good reputatio
There's not enough information here to really help much.
What you can do: Get a copy of wireshark and capture the traffic both
ways. Find out if the source is "not sending" or the server is "not
responding".
What did you do to "test" the connection? How did it "work"?
Is lwip hosting the s
Get Wireshark installed, and look at the raw packets at the Linux box.
Also make sure your checksum configuration is right.
Marty
-Original Message-
From: lwip-users-bounces+martypomeroy=novabio@nongnu.org
[mailto:lwip-users-bounces+martypomeroy=novabio@nongnu.org] On
Behalf Of
Ella
I'm working from memory here, and don't have time to try it. As I
recall, Wireshark helped me find that my checksums were off. So yes, I
think in promiscuous mode wireshark will show you bad packets and what
is wrong with them.
Marty
-Original Message-
From: lwip-users-bounces+mar
Bastien
I think the board side traces below indicate that 64 bytes are being
sent:
> 23.072 ETH:DMA_RX SZ:64
> 23.072 ETH:DMA_TX SZ:64
...
I'm assuming SZ is size.
Marty
-Original Message-
From: lwip-users-bounces+martypomeroy=novabio@nongnu.org
[mailto:lwip-users-bounces+ma
Setting a breakpoint in dhcp_bind, it is called from dhcp_timeout.
So DHCP offers an address, lwip ARPS the address and gets no response,
so it binds to it.
Those with more experience, is that right?
-Original Message-
From: lwip-users-bounces+martypomeroy=novabio@nongnu.org
[mail
You have "Connection: Close" in your request string. Doesn't that tell the
server to close the socket?
-Original Message-
From: lwip-users-bounces+martypomeroy=novabio@nongnu.org
[mailto:lwip-users-bounces+martypomeroy=novabio@nongnu.org] On Behalf Of
Furiantes
Sent: Thursda
ing just fine.
Thank you Marty for help!
Regards,
Danijel
Dne 13.6.2013 19:20, piše Pomeroy, Marty:
>
> You have "Connection: Close" in your request string. Doesn't that tell the
> server to close the socket?
>
>
> -Original Message-
> From: lwip-user
>> From your trace I'd say you have the following devices in your
Network:
>> 172.16.1.7 is the lwIP device
>> 172.16.1.34 is your PC
>> 172.16.1.11 a Zyxel device (Router or similar)
Minor correction to above - that the Zyxel device starts on a different
subnet - 172.16.0.11 in Packet 16
I am familiar with 61508 but never had to develop under it. And while I
am a big fan of lwIP, I would be concerned about using it in a 61508
application - you might spend far more effort in certification than
porting it.
Let me push back a bit - Do you really need a full stack in a
"minimalistic
>> > Can you tell me please exact part number of the Micrel PHY
>> We plan to use KSZ8863RLL.
We're using KSZ8031. 100MHz been working for about year with LPC1788
RMII.
Marty
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.o
>>But If I connect other services, all the pages from webserver are not
loaded.
This does look like a resource problem somehow. Possibly a timeout
firing before the jquery response completes (not enough CPU power), or
insufficient memory to respond, that sort of thing.
Comment to Noam:
>> As
>> Now let me ask you something. If you have 16M byte RAM why do you use
LwIP.
>> Use Linux with FULL BSD TCP stack. Much better.
We have some real-time constraints, such as a touch screen that we want
real responsive. There is also a more deeply embedded CPU with only
500K and it's easier to
>> Interestingly, we can't get communication with our setup like this:
>> [Win7 PC] --- (wired Ethernet) --- (Intranet) ---(wired Ethernet) ---
[wireless router] --- (WiFi) --- [Embedded device]
>> But if we try a setup like this then it works:
>> [Win7 PC] --- (WiFi) --- [Wireless Router] --- (E
Install tcpview on your server, and see if the connection is in TCP
TIME_WAIT state, preventing connections on PORTA until it expires.
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users
>> Thanks for reply, Marty.
>> But how can I definitively close the old connection and begin a new
connection ?
Flavio
You're welcome, but you can't force a socket fully closed quickly. To
connect on the same port, you just have to wait four minutes. Microsoft
says you can get that down to 3
>> My question I don't see any arguments passed to callback functions :
udp_recv() and TFTPRecv().
>> How are the arguments going to be filled up and by whom??
Jin
After review of the udp.c code, it looks to me that udp_recv is a setup
function (not a callback...), and you use it to tell lwI
Jin
I have 1.4.0 and this is how it works there:
Make sure you have LWIP_UDP set to 1 in lwipopts.h. Then udp_input() is
called from ip_input() if it is a UDP packet type.
Hope that helps!
Marty
From: lwip-users-bounces+martypomeroy=novabio@nongnu.or
Dawid
Looking at the pcap, I would first guess that some higher priority task
is not letting the lwip thread run. So packet processing is falling
behind.
Can you verify that the ethernet thread is running at higher priority
than all other threads? BTW - What RTOS are you using?
Marty
>> I did enable some more lwip debugging output and saw that at some
point pbuf fails to allocate memory on receiving a packet.
Yeah, it's clear from the pcap that lwip stops processing packets from
the host.
It looks like you need debug statements in memp_malloc and memp_free
rather than pack
>> Compiler is Codesourcery light so no real debugger except for GDB in
textmode. Most things work OK but if I dont't have a DHCP server the
board sends out 23 DHCP discovery per second.
You have to find out "who" is calling dhcp_discover. Can you add debug
statements? ... grep for dhcp_disc
-Original Message-
It worked but I noticed a relatively big latency (about 200ms or more)
between arrival of buf_n and buf_n+1.
Where does it come from? How lwip stack schedule an actual transmission
upon receipt of tcp_output?
If your receiving PC is running Windows, 200ms is a "smok
Anyone know how to support transfer file via VPN ? I can log in web in
remote device via VPN, but I can't transfer a file to the device via
VPN.
The device only receive some data of the file , anyone know why ?
Vincent
If you are logging in and transferring part of the file, your lwIP
* Don't run EMCCLK above 80MHz! *
On the datasheet for the LPC178x/7x, page 84 and 85 shows that Tcy has a
minimum of 12.5ns, which translates to a maximum EMC Clock of 80MHz. We
found out the hard way that it may work on most LPC1788s, but not on
some! Not recommended to run it above spec.
Yeah, the problem is not lwIP! I'm using an M3 at 120MHz, and have megabit
performance. So optimizing how you fill buffers is a waste of time. As
Krzysztof pointed out, you need to find the real cause of the slow behavior and
fix that. Try sending a pre-packaged chunk from flash or sram.
Bandu
>From http://us.profinet.com/technology/profinet/: "Real Time (PROFINET
RT): Here the TCP/IP layers are bypassed in order to give deterministic
performance...".
Given that Profinet's whole reason for being is to support real time
communications in industrial automation (while being "compa
>> BUT never can t1 and t2 both access s1 or s2.
Practically speaking, a socket is a stream of data, and it doesn't make
sense for tasks to contend for that stream. You would need to provide
additional coordination mechanisms at the application level to make sure
t1 is not getting t2's data
H...
>> (3) 258 2.414096 192.168.1.20 192.168.1.60 TCP 54 56864 → cisco-sccp [ACK]
>> Seq=65157 Ack=1288 Win=16054 Len=0
A 54 byte packet is too small
(http://en.wikipedia.org/wiki/Ethernet_frame#Runt_frames). Can you check the
ethernet flags generated by your hardware, to see if it ha
Preamble and CRC are stripped because the ethernet chips typically don't
pass those on to the buffer (many can be configured to include the CRC).
In Wireshark, select your packet 3, and look at the top line of the
middle window. It might say something like:
Frame 258: 54 bytes on wire (432 bits
Can't tell if this is the client or the server, but either way, make
sure your Windows system is configured to disable Ack Delay, You can
Google TCPAckFrequency and TCPNoDelay, or see
http://us.battle.net/d3/en/forum/topic/5578595314 for instructions. You
will have to reboot your Windows box af
Your other message mentions 127.0.0.1, which is the loopback address.
Wireshark will not see packets on the loopback. Is that what you are
trying to do? It's not clear to me how to configure lwIP to support
loopback.
But if you are running on Debian, why not use the Debian IP stack?
-Or
63 matches
Mail list logo
