Re: Understanding the interplay of ipfw, vlan, and carp
Peter Jeremy wrote: Note that one downside of your carpdev patches is that (AFAIK) it is no longer possible to identify which host sent the packet: The source and destination MAC addresses, as well as the destination IP address are all defined by CARP. Once you change the source IP address to be the shared address there's nothing to identify which host sent it. If you really, really wanted to, you could write code to prepend the original IP or MAC as an experimental IP option. Options less than 0x80 are not forwarded in IP fragments. I can understand why you'd want to do this (debugging springs to mind), though it does go against the gist of what carp is and does. Also, there is compatibility to keep in mind, and it's entirely possible that the presence of a new and unknown IP option is going to break implementations which don't parse IP option headers correctly, or trigger other unwanted behaviour (I don't know what this IP option is therefore I will drop it). ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: network keep droping
Izwan Mohd wrote: Hi, I have being encountering a weird problem on my freebsd 6 , one of my remote machine being down frequently lately for no particular reason, when I go to the remote site to check then machine it was in good running condition but no network, it even can't ping the server on the same subnet, the only way to restore it back is by running: route -n flush /etc/netstart but because it a remote machine it really troublesome to do that each time the machine is down, I resorted to use a crontab scripts to automatically run the previous command when it down, even tho that partial of the problem is solve I still need to know what causing it. can anyone could advise me where to start digging?? they is no any particular error in the log or dmseg when the machine dropped it connection so I'm stuck here don't know where to start, some help should clear something up for me TQ This sounds vaguely similar to what I've experienced myself with an onboard em0 on a Supermicro mainboard. NIC suddenly stopped working for no appearent reason. Believing the NIC was bad I throw in an extra NIC and ran the machine from that. But within a month a capacitor blew in the PSU and when I replaced the PSU the onboard NIC worked again. This scenario repeated 3 times in exactly the same way before I switched to another PSU brand and haven't had any problems since. In my case I couldn't get the NIC running with a simple flushing of the routes though. But if nothing has changed in the software on the machine you should probably start looking at the hardware. /PP ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: network keep droping
Update: just got back from the remote site and checked the following: 1. tcpdump on the interface only show switch broadcast nothing more 2. the connection restored by doing arp -ad ping IP On Thu, Jun 5, 2008 at 12:27 PM, Izwan Mohd [EMAIL PROTECTED] wrote: First question would be: What has changed? Are you able to identify when the problem occurs? This might let you associate the problem with an internal cronjob or network activity. it randomly happen so I can't determine when it happen my cron script just try to ping and if it not successfull it will flush and restart the network What does ifconfig report? Does the interface look normal or is it reporting something strange? ifconfig does not show any abnormality but maybe I will double check it Is the switch reporting any events associated with your port? Nope no report from switch indicating something wrong the the port that the machine are using What do you see if you tcpdump the interface whilst its not working? Are you seeing normal subnet broadcast traffic? Unicast traffic directed to your box? Outgoing traffic from your box? I will check this one this afternoon because the machine is dead again I'll post the finding later on Does physically unplugging and re-connecting the network cable correct the problem? Are you able to (temporarily) use a different swichport or NIC? sometime it does sometime it wont, already try changing to other port on the switch still the same, changing the NIC is not an option for me because it a rack mount server using on board NIC and no extra slot to add a new network card on it. Finally, more detail on your configuration might trigger someone's memory: What version of 6.x? What NIC/MII? How much memory? What network features (vlan, firewall, dummynet, netgraph, carp, ...) are you using? The server using FreeBSD 6.0-RELEASE the NIC is intel i can't remember the model but freebsd detect it as em0 the server memory is 1GB, not special network fetures it only running snort and nessus will post more detail after I check the machine this afternoon Thank You, Regards, Zuan -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: samba performance on 1Gig link: how to replace black magic with science? And why TCP windows scaling is not in play?
Adrian Chadd wrote: Figure out why window scaling isn't working - look at the options being negotiated (use tcpdump) and try to figure out which side isn't offering or is rejecting window size scaling negotiation. FreeBSD suggest scaling 9, Windows -- scaling 0. After that FreeBSD uses scaling, but windows is 49152 (scaled! 0x0060 in header!) always from FreeBSD to Win due to SO_RCVBUF=49152. Without this option window is 130560, but speed is MUCH worse! CIFS isn't the same profile as iperf/etc - its not just shovelling raw data down the socket, there's a whole protocol involved in scheduling what to transfer. Latency in handling commands screws your performance.. But how this magic values in socket buffers can be explained? As far as I know, there are big read/big write commands in CIFS, which allows use more than 64K in one operation? -- // Lev Sserebryakov ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Probable Bug in tcp.h
Hello,
I probably found a bug in declaration of struct tcphdr!
struct tcphdr {
u_short th_sport; /* source port */
u_short th_dport; /* destination port */
tcp_seq th_seq; /* sequence number */
tcp_seq th_ack; /* acknowledgement number */
#if BYTE_ORDER == LITTLE_ENDIAN
u_int th_x2:4,/* (unused) */
---here
th_off:4; /* data offset */
---
#endif
#if BYTE_ORDER == BIG_ENDIAN
u_int th_off:4, /* data offset */
th_x2:4;/* (unused) */
#endif
u_char th_flags;
First of all I have the problam of misalignment of th_off. Because in this way
always 4 bytes are read and the the bits of th_off are replaced. Then the 4
bytes are written back.
But should (th_x and th_off) not only be 1 byte in whole - only read and
write 1 byte?
I think if this was changed, my misalignment problems would go away!
I'll appreciate any thoughts on this!
Regards,
Marc
P.S.: Please cc me because I'm not on the list!
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Probable Bug in tcp.h
On Thu, Jun 05, 2008 at 05:12:47PM +0200, =?ISO-8859-1?Q?Marc_L=F6rner_ wrote:
Hello,
I probably found a bug in declaration of struct tcphdr!
struct tcphdr {
u_short th_sport; /* source port */
u_short th_dport; /* destination port */
tcp_seq th_seq; /* sequence number */
tcp_seq th_ack; /* acknowledgement number */
#if BYTE_ORDER == LITTLE_ENDIAN
u_int th_x2:4,/* (unused) */
---here
th_off:4; /* data offset */
---
#endif
#if BYTE_ORDER == BIG_ENDIAN
u_int th_off:4, /* data offset */
th_x2:4;/* (unused) */
#endif
u_char th_flags;
First of all I have the problam of misalignment of th_off. Because in this
way
always 4 bytes are read and the the bits of th_off are replaced. Then the 4
bytes are written back.
But should (th_x and th_off) not only be 1 byte in whole - only read and
write 1 byte?
I think if this was changed, my misalignment problems would go away!
I'm not sure what you mean.
Please supply more information, like:
1) Are you running on little endian? Or big endian?
2) th_x2 + th_off are 1 byte in size. What do you mean?
3) What is exactly the effect? I don't understand the replaced, written
back etc. sentence.
Regards,
--
Rui Paulo
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Probable Bug in tcp.h
Marc Lörner wrote: .. First of all I have the problam of misalignment of th_off. Because in this way always 4 bytes are read and the the bits of th_off are replaced. Then the 4 bytes are written back. But should (th_x and th_off) not only be 1 byte in whole - only read and write 1 byte? Which machine architecture are you attempting to compile this code on? On FreeBSD Tier 1 platforms, the access is probably going to come out of L2 cache anyway, so the fields in question will be read by a burst cycle. It is worth noting that NetBSD changed the base type of tcphdr's bitfields to uint8_t, however this shuffles the compiler dependency into the treatment of the char type. Most modern C compilers support unsigned char. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: network keep droping
PP skrev: Izwan Mohd wrote: Hi, I have being encountering a weird problem on my freebsd 6 , one of my remote machine being down frequently lately for no particular reason, when I go to the remote site to check then machine it was in good running condition but no network, it even can't ping the server on the same subnet, the only way to restore it back is by running: route -n flush /etc/netstart but because it a remote machine it really troublesome to do that each time the machine is down, I resorted to use a crontab scripts to automatically run the previous command when it down, even tho that partial of the problem is solve I still need to know what causing it. can anyone could advise me where to start digging?? they is no any particular error in the log or dmseg when the machine dropped it connection so I'm stuck here don't know where to start, some help should clear something up for me TQ This sounds vaguely similar to what I've experienced myself with an onboard em0 on a Supermicro mainboard. NIC suddenly stopped working for no appearent reason. Believing the NIC was bad I throw in an extra NIC and ran the machine from that. But within a month a capacitor blew in the PSU and when I replaced the PSU the onboard NIC worked again. This scenario repeated 3 times in exactly the same way before I switched to another PSU brand and haven't had any problems since. In my case I couldn't get the NIC running with a simple flushing of the routes though. But if nothing has changed in the software on the machine you should probably start looking at the hardware. /PP ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED] No virus found in this incoming message. Checked by AVG. Version: 8.0.100 / Virus Database: 270.0.0/1484 - Release Date: 2008-06-04 16:40 Is it on DHCP? Sounds like it's lost the lease or the default route? /R ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: anyone tried the Multi routing table code yet?
On Friday 30 May 2008 11:45:32 Julian Elischer wrote: Rajkumar S wrote: On Sat, May 24, 2008 at 6:09 AM, Julian Elischer [EMAIL PROTECTED] wrote: subject says it all really.. I am using pf and rtable to setfib and get an pfctl: DIOCADDRULE: Device busy when trying to load pass in quick on fxp0 from any to any keep state rtable 1 I'm not really familiar with the pf syntax as I didn't do that part of the patch (max laier (CC'd) did) and I don't use pf. Max may be able to see if the patch to the pf code ahs an error. See attached - stupid error, my bad. Confirmed to work now, with limited testing, though. -- /\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News ---BeginMessage--- Author: mlaier Date: Thu Jun 5 19:30:20 2008 New Revision: 179570 URL: http://svn.freebsd.org/changeset/base/179570 Log: Fix range check for rtable id. Modified: head/sys/contrib/pf/net/pf_ioctl.c Modified: head/sys/contrib/pf/net/pf_ioctl.c == --- head/sys/contrib/pf/net/pf_ioctl.c Thu Jun 5 19:01:31 2008 (r179569) +++ head/sys/contrib/pf/net/pf_ioctl.c Thu Jun 5 19:30:20 2008 (r179570) @@ -1532,7 +1532,7 @@ } #ifdef __FreeBSD__ /* ROUTEING */ - if (rule-rtableid 0 rule-rtableid rt_numfibs) + if (rule-rtableid 0 rule-rtableid rt_numfibs) #else if (rule-rtableid 0 !rtable_exists(rule-rtableid)) #endif @@ -1795,7 +1795,7 @@ if (newrule-rtableid 0 #ifdef __FreeBSD__ /* ROUTING */ - newrule-rtableid rt_numfibs) + newrule-rtableid rt_numfibs) #else !rtable_exists(newrule-rtableid)) #endif ---End Message--- ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: IP-forwarding (help)
Bakul Shah [EMAIL PROTECTED] writes: On 05 Jun 2008 01:33:05 +0200 Arno J. Klaassen [EMAIL PROTECTED] wrote: Petar Bogdanovic [EMAIL PROTECTED] writes: On Wed, Jun 04, 2008 at 11:06:01PM +0200, Arno J. Klaassen wrote: [ problem description ] I feel this is /me still not fully understand routing tables. This is your topology, right? yes test-box main-box gateway [192.168.1.1]--[192.168.1.254 172.16.1.240]---[172.16.1.254 On the test-box set default route to 192.168.1.254. On the main-box set net.inet.ip.forwarding 1 but remove the static routes. But how would machines on the 172.16.1.0/24 net know they must send packets for 192.168.1.0/24 to 172.16.1.240? For that you need static routes on all the machines on 172.16.1.0/24 that need to read your test box. Yes, of course ... Thank you very much (I felt it were a simple problem, but somehow blocked finding the solution). Best regards, Arno ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
vlan oddness
I created and destoryed, brought up and down a vlan... now it is not accepting an IP what does the 'File exists' mean? #ifconfig vlan9 vlan9: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=3RXCSUM,TXCSUM ether 00:30:48:5c:ba:9c media: Ethernet autoselect (1000baseTX full-duplex) status: active vlan: 9 parent interface: em0 # ifconfig vlan9 10.5.43.225/27 ifconfig: ioctl (SIOCAIFADDR): File exists Also, I don't have the IP/net assigned on any IPs: # ifconfig | grep inet inet 10.5.40.8 netmask 0xff00 inet 10.5.42.254 netmask 0xff80 inet 64.215.30.154 netmask 0xfffc inet 127.0.0.1 netmask 0xff00 inet 10.9.212.1 netmask 0xfe00 inet 10.5.41.1 netmask 0xff00 inet 10.9.2215.225 netmask 0xffe0 inet 10.9.215.9 netmask 0xfffc inet 10.77.0.6 netmask 0xff00 inet 10.5.42.126 netmask 0xff80 inet 10.99.0.1 netmask 0xff00 probably a reboot will fix it, but if anyone has seen this oddness, let me know if you found out what caused it. (Running fresh freebsd 7.0-STABLE) Rudy ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: vlan oddness
Probably still in the routing table and didn't get removed when the interface was destroyed.. do a route get 10.5.43.225 Support (Rudy) wrote: I created and destoryed, brought up and down a vlan... now it is not accepting an IP what does the 'File exists' mean? #ifconfig vlan9 vlan9: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=3RXCSUM,TXCSUM ether 00:30:48:5c:ba:9c media: Ethernet autoselect (1000baseTX full-duplex) status: active vlan: 9 parent interface: em0 # ifconfig vlan9 10.5.43.225/27 ifconfig: ioctl (SIOCAIFADDR): File exists Also, I don't have the IP/net assigned on any IPs: # ifconfig | grep inet inet 10.5.40.8 netmask 0xff00 inet 10.5.42.254 netmask 0xff80 inet 64.215.30.154 netmask 0xfffc inet 127.0.0.1 netmask 0xff00 inet 10.9.212.1 netmask 0xfe00 inet 10.5.41.1 netmask 0xff00 inet 10.9.2215.225 netmask 0xffe0 inet 10.9.215.9 netmask 0xfffc inet 10.77.0.6 netmask 0xff00 inet 10.5.42.126 netmask 0xff80 inet 10.99.0.1 netmask 0xff00 probably a reboot will fix it, but if anyone has seen this oddness, let me know if you found out what caused it. (Running fresh freebsd 7.0-STABLE) Rudy ___ 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]
Re: vlan oddness
Paul wrote: Probably still in the routing table Yep. Had to go into quagga and delete the route... :) moved GW from another router to another. Thanks, Rudy ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: network keep droping
Hi, Is it on DHCP? Sounds like it's lost the lease or the default route? /R ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED] Nope it not on DHCP it using static configuration and even to eliminate fw issue I even put it before firewall without going thru firewall it just use my ISP default router as it gateway tks ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
