Re: Socket bound to 0.0.0.0 never receives broadcasts with non-zero IP source address
If nobody answers this question by the time I get home I'll try and
help; however, in the mean time I do have a couple of suggestions.
Have you tried writing the equivalent program in C using the sockets
API? IE is this a python specific problem or a sockets problem in
general?
The second thing is you may just want to try using raw sockets instead.
-Daniel
Yuri writes:
> I noticed that the socket bound to '0.0.0.0' only receives UDP
> broadcasts when they are sent from zero IP:
> 0.0.0.0->255.255.255.255. When the source IP is not zeros, but some
> valid IP on that network, socket never receives such broadcast.
>
> I compared two packets in wireshark as they arrive, and the only
> difference on Ether/IP/UDP level is source IP.
>
> Is there any reason why source IP address would influence the
> reception of the broadcast packets?
>
> I use this python3 program to create bound socket and listen:
> #!/usr/bin/env python3.4
> import socket
> sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM, socket.IPPROTO_UDP)
> sock.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
> sock.setsockopt(socket.SOL_SOCKET, socket.SO_BROADCAST, 1)
> sock.bind(('0.0.0.0', 67))
> print("Waiting for broadcast")
> (data, flags, ancillary, addr) = sock.recvmsg(4096, 256)
> print("Received broadcast packet")
>
> I use dhclient to send broadcast packets. It sends with src=0.0.0.0
> when no /var/db/dhclient.leases.* exists, and it always sends with
> src= when the previous lease exists.
>
> 10.1 STABLE
>
> Yuri
> ___
> freebsd-net@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: ifconfig greX create disables IPv6 forwarding
Paul Thornton writes: > On 09/02/2015 16:34, Daniel Corbe wrote: >> >> For some reason, every time I create a GRE interface on a FreeBSD IPv6 >> gateway, net.inet6.ip6.forwarding is disabled. As long as I manually >> re-enable it with sysctl, both the GRE tunnel and the IPv6 network >> behind this machine will continue to work; however, it's certainly far >> from ideal. > I stumbled acro > > I discovered this in January. See this thread: > > http://lists.freebsd.org/pipermail/freebsd-net/2015-January/040797.html > > Are you enabling forwarding using ipv6_gateway_enable in rc.conf, or > are you just setting net.inet6.ip6.forwarding to 1 in sysctl.conf? > > devd gets involved running /etc/rc.d/netif start and that seems to > check (and set) the forwarding sysctls based on the rc.conf entries - > so if you've set them "manually" they get reset when a new interface > is brought up. > > Adding ipv6_gateway_enable="YES" in /etc/rc.conf should fix this. > Embarrassingly enough, the problem wound up being I had ipv6_enable_gateway instead of ipv6_gateway_enable. I'm also setting net.inet6.ip6.forwarding=1 manually in sysctl.conf so that's sort of why it ever worked to begin with. Thanks though. Some times all you need is a second set of eyes on a problem. -Daniel ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
ifconfig greX create disables IPv6 forwarding
For some reason, every time I create a GRE interface on a FreeBSD IPv6 gateway, net.inet6.ip6.forwarding is disabled. As long as I manually re-enable it with sysctl, both the GRE tunnel and the IPv6 network behind this machine will continue to work; however, it's certainly far from ideal. There's nothing in the log to indicate exactly what's going on here: Feb 9 11:23:08 router rtadvd[27251]: interface added (idx=8) Feb 9 11:23:08 router devd: Executing '/etc/pccard_ether gre0 start' Feb 9 11:23:21 router rtadvd[27251]: non-zero lifetime RA but net.inet6.ip6.forwarding=0. Ignored. Feb 9 11:23:53 router last message repeated 2 times Nor is there anything about it in dmesg. # uname -a FreeBSD router.corbe.net 10.1-RELEASE FreeBSD 10.1-RELEASE #0 r274401: Tue Nov 11 21:02:49 UTC 2014 r...@releng1.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64 -DAniel ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Can multiple apps listen for TCP on the same port?
Generally the answer to your question is no. Two applications cannot occupy the same port on the same protocol at the same time. To expand on this answer and to hopefully shed some light on why the behavior you're observing with your application is absolutely correct; the calling application (in this case, nc) has to explicitly call bind(2) before it can begin accepting connections. If that port is already in use then the call to bind(2) will fail. And in your case I suspect nc is simply choosing to silently fail. -Daniel On Mon, Dec 01, 2014 at 04:23:47AM -0800, Yuri wrote: > I have a simple 'nc' based TCP server with shell script serving http > protocol. But when I run the second instance, it never gets any > connections and never fails. > > 'nc -l PORT' first calls listen with backlog=1 and socket option > SO_REUSEADDR, and then calls accept. Once client is accepted, it closes > the listening socket and only works with this connection. > > Why the second nc instance still never accepts any connections, once the > first connection is accepted, and first listening socket is closed? > > When one listening socket is closed, shouldn't other listening sockets > on the same port be accepting connections? It looks like the whole port > is blocked without even having the listening socket on it by one alive > connection (which after it was accepted doesn't have much to do with the > original port). > > Yuri > ___ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" > ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: netmap, selective processing.
"Alexander V. Chernikov" writes: > On 16.07.2014 21:48, Daniel Corbe wrote: > Hm. What do you need from bird OSPF implementation? > IMHO it is much easier to improve and merge bird code instead of > writing another OSPF implementation from scratch. > I can't get an OSPF adjacency up between a bird box and a Cisco 3750. I've tried seeking help both in IRC and on their mailing list. If I can't get basic help using the software, I'm certainly not going to contribute to the project in other ways. And that's too bad, too because bird looks like a promising project. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: netmap, selective processing.
Jan Bramkamp writes: > On 16.07.2014 19:48, Daniel Corbe wrote:> >> I hope this it the right place to ask questions about netmap. I'm >> toying with the idea of writing a netmap-based OSPF implementation >> because bird's OSPF implementation isn't as good as its BGP >> implementation, quagga doesn't scale well and openospfd doesn't compile >> on 10-RELEASE or CURRENT. > > How many prefixes do you have in your OSPF area 0? If you run into > scalability problems with OSPF on current x86 CPUs your network design > probably is the cause of the problem e.g. redistributing announcements > from BGP into OSPF. I have about 15k interior routes. And most of it is RFC1918 address space or random /64s doing various things. So when I say I'm worried about scale issues, I should more accurately be saying "I just don't want to use quagga but I can't get anything else to work." > > OSPF is just one more (rather ugly) IP protocol. Is moving the OSPF > packets between kernel and userspace really a problem worth optimizing > for? Putting netmap between the NIC and the kernel IP stack introduces > overhead to all non OSPF packets unless your netmap application also > implements IP routing and bypasses the kernel. I've been searching for a reason to play with netmap. It looks like a neat toy. And at worst I will have implemented something only useful to one person but I'll also have learned something in the process. >From the perspective of totally wrecking the performance of the host network stack: how much more overhead am I really introducing by looking at every packet inside of the netmap framework and going "am I really interested in this? Or should I simply pass it through to the host." And I'm hoping this leads me down the avenue of doing interesting things with MPLS. MPLS is something that absolutely needs to look at everything because labels should always be processed and forwarded first. -Daniel ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
netmap, selective processing.
I hope this it the right place to ask questions about netmap. I'm toying with the idea of writing a netmap-based OSPF implementation because bird's OSPF implementation isn't as good as its BGP implementation, quagga doesn't scale well and openospfd doesn't compile on 10-RELEASE or CURRENT. But I'm only interested in selectively processing packets on the netmap-enabled interface. Is there a way to do this? Or alternatively if I throw the IF into netmap mode, can I process what I'm interested in processing and then somehow throw the rest of the traffic back up to the host's IP stack? ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
