GithubHelp home page GithubHelp logo

lib-lwip's People

Contributors

andreittr avatar clupuishere avatar danield20 avatar felipehuici avatar flapjack321 avatar hlef avatar john-ted avatar justin-he avatar lascubogdan96 avatar marcrittinghaus avatar mariasfiraiala avatar michpappas avatar mihaipogonaru avatar mogasergiu avatar mschlumpp avatar nderjung avatar razvand avatar skuenzer avatar starnox avatar vladandrew avatar yvolchkov avatar

Stargazers

avatar avatar avatar avatar avatar avatar avatar avatar avatar

Watchers

avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar

Forkers

nderjung felixmoebius lancs-net skuenzer hisharanwithu flapjack321 alexpawe project-flexos hlef vladandrew razvand marcrittinghaus mariasfiraiala unikraft-upb mschlumpp pogobanane ejko36 csbonlaboratory john-ted haesbaert starnox andreittr xidot chococandy63 mogasergiu michpappas mihnea27

lib-lwip's Issues

Build fails when using `ipv6` and Musl.

When building with Musl and enabling ipv6, the build fails with this error:

liblwip/origin/fork-lwip-UNIKRAFT-2_1_x/src/include/lwip/inet.h:155:82: error: ‘struct in6_addr’ has no member named ‘un’
  155 | #define inet6_addr_from_ip6addr(target_in6addr, source_ip6addr) {(target_in6addr)->un.u32_addr[0] = (source_ip6addr)->addr[0]; \

The definition of struct in6_addr in lwip's in.h is overriten by the definition in musl's in.h, wich does not include any member named un.

This happens in case musl is places before lwip in the Makefile.
Changing the order of the libraries does not seem to work here.

socketpair() not supported

The function socket.socketpair() is not yet supported.
AFAIR, most of the work has already been done.

Does anyone know the status of this activity?

socket() with IPPROTO_ICMP uses UDP

I compile the following to send ICMP packets:

#include <stdio.h>
#include <errno.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>
#include <string.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <unistd.h>
#define ICMP_ECHO       8   /* Echo Request         */
int main() {
	struct sockaddr_in to;
	memset(&to, 0, sizeof(to));
	to.sin_family      = AF_INET;
	//to.sin_addr.s_addr = inet_addr("172.44.0.3");
	to.sin_addr.s_addr = inet_addr("1.1.1.1");
	to.sin_port        = 0;
	char packet[150] = { 0 };
	packet[0] = ICMP_ECHO;
	int fd = socket(AF_INET, SOCK_DGRAM, IPPROTO_ICMP);
	while (1) {
		int r = sendto(fd, packet, sizeof(packet), 0, (struct sockaddr *)&to, sizeof(to));
		printf("%d %d\n", r, errno);
		sleep(4);
	}
}

with: gcc -static-pie -fPIC -Wall -o icmp_test icmp_test.c

  • If I then run it on Linux 5.15.0-69-generic, it sends ICMP echo reply packets (as expected), as seen in tcpdump:
$ sudo tcpdump -nn -v -i wlp3s0 host 1.1.1.1
tcpdump: listening on wlp3s0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
17:26:30.999548 IP (tos 0x0, ttl 64, id 25840, offset 0, flags [DF], proto ICMP (1), length 170)
    ${my_ip} > 1.1.1.1: ICMP echo request, id 25, seq 0, length 150
...
  • If I run it with app-elfloader:
    ../../run-app-elfloader/run_elfloader -r rootfs/ -k build/*_kvm-x86_64 -n icmp_test,
    it doesn't send out ICMP packets, but UDP.
    We can see this in the lwip debug output (proto=17 which is UDP, while ICMP would be 1):
[    6.461028] dbg:  [liblwip] <ip4.c @ 1097> IP header:
[    6.463983] dbg:  [liblwip] <ip4.c @ 1098> +-------------------------------+
[    6.467685] dbg:  [liblwip] <ip4.c @ 1099> | 4 | 5 |  0x00 |       178     | (v, hl, tos, len)
[    6.472054] dbg:  [liblwip] <ip4.c @ 1104> +-------------------------------+
[    6.475470] dbg:  [liblwip] <ip4.c @ 1105> |       22      |000|       0   | (id, flags, offset)
[    6.480519] dbg:  [liblwip] <ip4.c @ 1111> +-------------------------------+
[    6.484549] dbg:  [liblwip] <ip4.c @ 1112> |  255  |   17  |    0x0cf5     | (ttl, proto, chksum)
[    6.489074] dbg:  [liblwip] <ip4.c @ 1116> +-------------------------------+
[    6.493351] dbg:  [liblwip] <ip4.c @ 1117> |  172  |   44  |    0  |    2  | (src)
[    6.498078] dbg:  [liblwip] <ip4.c @ 1122> +-------------------------------+
[    6.501923] dbg:  [liblwip] <ip4.c @ 1123> |    1  |    1  |    1  |    1  | (dest)
[    6.505931] dbg:  [liblwip] <ip4.c @ 1128> +-------------------------------+

I can't see any references to IPPROTO_ICMP in this repo (when built), so I guess that's why.

release 0.9.0: variable rename needed

on the old 0.9.0 release i'm working on, unikraft has renamed a variable, but lib-lwip has not done so yet. The following patch fixes this. You may want to check if this fix is still needed on current staging/master/0.10.0.
pogobanane@bd92210

init.c:330:43: error: macro "uk_lib_initcall" passed 2 arguments, but takes just 1

With Unikraft 0.15, when building unikraft/app-wamr (target: wamr-qemu-x86_64-initrd (qemu/x86_64)), the following error occurred:

<prefix>/libs/lwip/init.c:330:43: error: macro "uk_lib_initcall" passed 2 arguments, but takes just 1                                   
 W    330 | uk_lib_initcall(liblwip_init, liblwip_term);                                                                                                                     
 W        |                                           ^                                                                                                                      
 W  In file included from <prefix>/libs/lwip/init.c:47:                                                                                     
 W  <prefix>/unikraft/include/uk/init.h:115: note: macro "uk_lib_initcall" defined here

Source:

lwip/init.c:330

uk_lib_initcall(liblwip_init, liblwip_term);

unikraft/include/uk/init.h:115

#define uk_lib_initcall(fn)       uk_lib_initcall_prio(fn, UK_PRIO_LATEST)

Port reuse problems / SOREUSEPORT support

When spamming Unikraft HTTPserver with lots of request using curl, the server eventually gets stuck. By inspecting the pcap in Wireshark, we would see last connection would try to "TCP Port reuse" in this case.

Alternatively, instead of spaming with connections, we have a more consistent way to replicate the bug. By using --local-port 42000 (or whatever port) option in curl and just do three requests we would see a similar behaviour (but without all the clutter before Unirkaft gets stuck): first curl would work just fine. The second one will fail with the message "bind failed with errno 98: Address already in use" (or errno 7 "Failed to connect to 172.44.0.2 port 8123: Connection refused", depending on Unikraft version). After that point all other requests would get stuck.

The cause could be that LWIP does not have support for SO_REUPOSRT flag and tries to reuse the TCP port by default. Something that helped a bit was enabling LWIP_SO_LINGER and setting the SO_LINGER with timeout 0 on the socket. By doing so, we'de get back the response, but the connection is still weird. After receiving the response, the connection would be force reset: curl: (56) Recv failure: Connection reset by peer.

Undefined `__unused` when building with Musl

When building with Musl, an error is printed due to missing __unused symbol:

CClibmuslglue:__set_thread_area.o
LDlibmuslglue.ld.o
OBJCOPYlibmuslglue.o
CCliblwip:alloc.unikraft.o
CCliblwip:proto.o
CCliblwip:host.o
CCliblwip:serv.o
/home/razvan/projects/unikraft/scripts/unikraft-musl/libs/lwip/serv.c:40:48:error:expected‘;’,‘,’or‘)’before‘__unused’
structservent*getservbyname(constchar*name__unused,
^~~~~~~~
/home/razvan/projects/unikraft/scripts/unikraft-musl/libs/lwip/serv.c:46:40:error:expected‘;’,‘,’or‘)’before‘__unused’
structservent*getservbyport(intport__unused,
^~~~~~~~
/home/razvan/projects/unikraft/scripts/unikraft-musl/libs/lwip/serv.c:52:30:error:expected‘;’,‘,’or‘)’before‘__unused’
intgetservbyport_r(intport__unused,constchar*prots__unused,
^~~~~~~~
make[2]:***[/home/razvan/projects/unikraft/scripts/unikraft-musl/apps/app-helloworld/build/liblwip/serv.o]Error1
/home/razvan/projects/unikraft/scripts/unikraft-musl/unikraft/support/build/Makefile.build:27:recipefortarget'/home/razvan/projects/unikraft/scripts/unikraft-musl/apps/app-helloworld/build/liblwip/serv.o'failed
make[1]:***[sub-make]Error2
Makefile:1016:recipefortarget'sub-make'failed
make:***[_all]Error2
Makefile:32:recipefortarget'_all'failed

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.