Re: Howto send a limited broadcast?
tmm wrote: Bruce M. Simpson wrote: tmm wrote: So, can anyone suggest how I can send a limited broadcast (on an interface that has been initalized with an IP and a subnet)? Use the IP_ONESBCAST option and send to the network broadcast address for that subnet. The stack will change it into 255.255.255.255 on output. See man page ip(4) for details. It's a hack, but it's largely due to how the stack has worked historically. BMS Thanks. I wasn't aware of that option. But now I find that this option is not present in my (eCos port of) FreeBSD stack. Either it was removed during the port, or the ported version is too old. Perhaps the best thing for me to do is to look at the 'normal' FreeBSD stack (as opposed to the eCos one) and see how IP_ONESBCAST is implemented. Then perhaps I could do the same thing in my FreeBSD stack. Is there a way for me to download the FreeBSD source code without actually downloading, burning, and installing FreeBSD? Looking around the FreeBSD website I don't see a source download link. thanks, Tom. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]" You can get them via CVS: http://www.freebsd.org/doc/en/books/handbook/cvsup.html. Also, although it, too, may be considered hacky, if the system you're working on has pcap(3), you could just manually craft the broadcast frame and send it out the interface yourself. I can provide some sample code. -Boris ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Howto send a limited broadcast?
Bruce M. Simpson wrote: tmm wrote: So, can anyone suggest how I can send a limited broadcast (on an interface that has been initalized with an IP and a subnet)? Use the IP_ONESBCAST option and send to the network broadcast address for that subnet. The stack will change it into 255.255.255.255 on output. See man page ip(4) for details. It's a hack, but it's largely due to how the stack has worked historically. BMS Thanks. I wasn't aware of that option. But now I find that this option is not present in my (eCos port of) FreeBSD stack. Either it was removed during the port, or the ported version is too old. Perhaps the best thing for me to do is to look at the 'normal' FreeBSD stack (as opposed to the eCos one) and see how IP_ONESBCAST is implemented. Then perhaps I could do the same thing in my FreeBSD stack. Is there a way for me to download the FreeBSD source code without actually downloading, burning, and installing FreeBSD? Looking around the FreeBSD website I don't see a source download link. thanks, Tom. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Howto send a limited broadcast?
tmm wrote: So, can anyone suggest how I can send a limited broadcast (on an interface that has been initalized with an IP and a subnet)? Use the IP_ONESBCAST option and send to the network broadcast address for that subnet. The stack will change it into 255.255.255.255 on output. See man page ip(4) for details. It's a hack, but it's largely due to how the stack has worked historically. BMS ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Redirect functionality in ng_nat
Hello,
I'm running a 7.0-RELEASE machine. I've backported the 7-STABLE for
ng_nat, because I'm really interested in the static NAT features from
libalias.
ng_nat(4) says:
| NGM_NAT_REDIRECT_ADDR (redirectaddr)
| Redirect traffic for public IP address to a machine on the local
| network. This function is known as static NAT. The following
| struct ng_nat_redirect_addr must be supplied as argument.
|
| struct ng_nat_redirect_addr {
| struct in_addr local_addr;
| struct in_addr alias_addr;
| chardescription[NG_NAT_DESC_LENGTH];
| };
|
| Unique ID for this redirection is returned as response to this
| message.
I'm a little confused on exactly how to pass a struct as a message to a
netgraph node via ngctl. What am I missing here?
Thanks,
--
Chris Cowart
Network Technical Lead
Network & Infrastructure Services, RSSP-IT
UC Berkeley
pgpCTqtcywevE.pgp
Description: PGP signature
Re: bpf does not see packets forwarded with ipfw fwd
On Sat, Apr 12, 2008 at 07:10:38PM +0100, Robert Watson wrote: > If you ping from host A to host B, does tcpdump see both the ICMP echo > request and reply on both boxes? In principle, ipfw fwd uses the same > output paths as the rest of the IP stack, so it would be useful to know > whether it sees other outbound traffic properly or not. Yes, it does. It sees oubound traffic that is not processed with 'ipfw fwd'. That's so funny: 1) A has IP 10.58.0.2/24 and B has. 10.58.0.1/24. From A, I start to ping 10.58.0.1, tcpdump shows requests and replys. 2) I add a rule: "ipfw add 5 fwd 10.58.0.1 from any to 10.58.0.1" ping contiunes to run Ok, ipfw shows that rule maches packes (counters increase) but now tcpdump shows only replies. No request. Very funny. Eugene Grosbein ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: bpf does not see packets forwarded with ipfw fwd
On Sat, 12 Apr 2008, Eugene Grosbein wrote: One of 7.0 users has reported in some cyrillic newsgroup a problem that I have reproduced in my 7.0-STABLE system. That is: tcpdump does not show locally originated outgoing IP packets that were processed by 'ipfw fwd' rule. The same configuration presents no problems with 6.3-STABLE. Consider simple schema: two FreeBSD boxes (A and B) directly connected with ethernet intefaces. The box A has another ethernet interface and uses "ipfw fwd" as its very first ipfw rule to forward some packets to B, while these packets would normally go out trough mentioned another interface. Now, tcpdump does NOT show outgoing packets but host B also runs tcpdump on its incoming interface and does see them. I double-checked all paramerets for tcpdump, all routing tables. I even connected A and B with cross-over ethernet cable, without a switch. Still, B sees incoming packets coming over the cable and A does not see them leaving. This bothers me a bit :-) If you ping from host A to host B, does tcpdump see both the ICMP echo request and reply on both boxes? In principle, ipfw fwd uses the same output paths as the rest of the IP stack, so it would be useful to know whether it sees other outbound traffic properly or not. Robert N M Watson Computer Laboratory University of Cambridge ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
bridge interface down, yet still bridging?
I've got an issue that only crops up every so often (every few months), and it's theoretically impossible. I've got two FreeBSD 6.2 firewalls in a failover state, using bridging (I don't control .1, and don't have a choice). I use ifstated and carp to monitor which one is master, and which is slave. The slave has the bridge0 interface down, and the master has it up. On to the issue: Last night the problem came back, the network looped via the bridges, even though the bridge interface on the backup failover was in a 'down' state. The loop was verified by our hosting company, the two uplink ports that the firewalls are in were doing the exact same amount of traffic inbound and outbound - definately a loop. As soon as they disabled one of the firewall ports, everything went back to normal. At this point, I verified the bridge interface was infact down on the failover firewall. Hosting company turned back on the port, and blam - loop. Has anyone ever come across this specific issue before? ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Howto send a limited broadcast?
Hi. I'm using the FreeBSD network stack (on top of the eCos embedded OS), and I want to send a limited broadcast (a broadcast with destination IP of 255.255.255.255). Normally (I believe) the stack will only send a broadcast like this if there is no subnet mask set on the interface, or an all zeros mask (this is how bootp/dhcp work). Once I set a normal subnet mask, the stack will change my broadcasts into subnet broadcasts, eg. 192.168.0.255. In my situation the interface is active, so I can't just remove the netmask - I must find another way to send the limited broadcast. When the interface gets setup with IP and netmask it creates a default broadcast address. If I override this and set it to 255.255.255.255 (using SIOCSIFBRDADDR), then it will try to send my limited broadcast as is, rather then changing it into a subnet braodcast. Unforunately this fails, because there is no route available that matches this destination. Okay, so just add a route? But when I try to add a route that would match 255.255.255.255 it gets rejected – it is not valid for the interface as currently configured. The next step – which I would rather avoid - is modify the ip code. If the SO_DONTROUTE/IP_ROUTETOIF flag is set then you only need a route in order to pick an interface, not for any actual routing. So, I could add some code to manually pick an interface (even though none really match my destination address). But I’d rather avoid changing the code. So, can anyone suggest how I can send a limited broadcast (on an interface that has been initalized with an IP and a subnet)? Thanks for any suggestions. Tom. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: bpf does not see packets forwarded with ipfw fwd
On Sat, Apr 12, 2008 at 01:50:17PM +0100, Alireza Torabi wrote: > It'll be in tcpdump code where it sets up BPF. It's a new IOCTL in 7 BPF. How to check? > Is your tcpdump source up to date? I use stock tcpdump that comes with 7.0-STABLE. Eugene Grosbein ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: bpf does not see packets forwarded with ipfw fwd
It'll be in tcpdump code where it sets up BPF. It's a new IOCTL in 7 BPF. Is your tcpdump source up to date? On Sat, Apr 12, 2008 at 1:43 PM, Eugene Grosbein <[EMAIL PROTECTED]> wrote: > On Sat, Apr 12, 2008 at 11:53:00AM +0100, Alireza Torabi wrote: > > > Is BIOCFEEDBACK set? > > What's that and how to check it? > > Eugene Grosbein > ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: bpf does not see packets forwarded with ipfw fwd
On Sat, Apr 12, 2008 at 11:53:00AM +0100, Alireza Torabi wrote: > Is BIOCFEEDBACK set? What's that and how to check it? Eugene Grosbein ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: bpf does not see packets forwarded with ipfw fwd
Is BIOCFEEDBACK set? On Sat, Apr 12, 2008 at 7:22 AM, Eugene Grosbein <[EMAIL PROTECTED]> wrote: > Hi! > > One of 7.0 users has reported in some cyrillic newsgroup > a problem that I have reproduced in my 7.0-STABLE system. > That is: tcpdump does not show locally originated outgoing IP packets > that were processed by 'ipfw fwd' rule. The same configuration presents > no problems with 6.3-STABLE. > > Consider simple schema: two FreeBSD boxes (A and B) directly connected > with ethernet intefaces. The box A has another ethernet interface and uses > "ipfw fwd" as its very first ipfw rule to forward some packets to B, > while these packets would normally go out trough mentioned another > interface. Now, tcpdump does NOT show outgoing packets but host B also > runs tcpdump on its incoming interface and does see them. > > I double-checked all paramerets for tcpdump, all routing tables. > I even connected A and B with cross-over ethernet cable, without a switch. > Still, B sees incoming packets coming over the cable and A does not see > them leaving. This bothers me a bit :-) > > Eugene Grosbein > ___ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
