| |
| |
| |
|
<neer0ween> what happens if two points send SYNs at the same time to each other with the same SPORT and DPORT respectively.
<neer0ween> so like .. bsdi.8888 > vangogh.7777 and vangogh.7777 > bsdi.8888
<danieldg> the SYNS are both dropped, because you can't send a SYN from a port you are listening on
<danieldg> (at least, that's what I think)
<neer0ween> i .. dont think so.
<neer0ween> bsdi has a local port of 7777 and performs active open on port 8888.
<neer0ween> vangogh has a local port 8888 and performs an active open to port 7777 on host A.
<danieldg> oh
<neer0ween> (as per the TCPDUMP output above)
<danieldg> hmm, well I guess it would work then
<danieldg> right?
<neer0ween> i guess i'm asking what happends from a TCP/IP perspective.
<neer0ween> would both also simultaneously enter SYN_SENT then SYN_RCVD state and everything is good?
<bobgray> im having a problem with masquerading
<bobgray> i have a qemu guest os on tap1 and external net connection on wlan0
<bobgray> i have iptables -t nat -A POSTROUTING -o wlan0 -j MASQUERADE
<bobgray> the rest of the tables set to ACCEPT for all
<bobgray> /proc/sys/net/ipv4/ip_forward is set to 1
<bobgray> but packets dont get through
<neer0ween> what's tcpdump / tethereal saying inside and out?
<neer0ween> clear your arp cache and all that crap first just to make sure you get a picture of the entire connection.
<bobgray> wlan0 side doesn't see the packets at all
<bobgray> tap1 does though
<bobgray> actually sorry, they do get it on wlan0 but the address haven't been rewritten
<bobgray> feck, it's working now
<bobgray> thanks anyhow
<xous> This is a bash script that i pieced together from examples from misc tutorials ( http://pastebin.com/411720 )
<xous> but it seems I neglected to notice that it causes problems for the computer doing the sharing
<xous> all connected computers are able to access the internet fine :/
<danieldg> what kind of problems?
<xous> I cannot connect to any thing irc/http servers
<xous> it resolves fine
<danieldg> add iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT somwehere around line 14
<danieldg> to allow connections back in
<xous> thanks, that seemed to have fixed it.
<alfajr> hi
<alfajr> do any one know
<alfajr> reaims
<SiegeX> I need help with getting my tivo to work through my linux firewall, ive read some posts and some people have pointed to problems with MSS and MTU and the dont fragment bit set, but im not really understanding the problem, hoping sombody can shed some light
<neer0ween> do you just not understand what mss and mtu's are?
<SiegeX> well i know what they stand for but how they interoperate is a bit fuzzy
<neer0ween> read Chapter 2 and Chapter 18 in TCP/IP Illustrated vol 1
<SiegeX> "My firewall setup had a lower-than-normal MTU. I suspect that the Tivo service folks recently added a network filter for ICMP messages, forgetting that they need to listen for "please fragment" ICMP (3/4) since their server sends packets with the "don't fragment" bit set. By lowering my MSS to 1200, I can force the tivo service to never send packets that are too large, and therefore never spark an ICMP response, which they'd ignore, which would result in t
<SiegeX> thats a post i found googling for similar problems
<SiegeX> does it make any sense?
<neer0ween> (not that i support this, but you can google for "TCPIP Illustrated" and probably find a CHM for the book
<neer0ween> chap 2 and chap 18 are sort of quick. it's like .. an hours worth of reading and you'll totally understand how MSS and MTU affect you
<neer0ween> and yeah, that does make sense.
<SiegeX> i have a tcpdump of the wireless interface and sure enough i see my tivo grab an IP via dhcp
<neer0ween> but are you seeing fragmentation?
<SiegeX> 20:00:41.003061 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: ICMP (1), length: 44) 192.168.2.250 > 204.176.49.2:
<SiegeX> ICMP echo request, id 72, seq 0, length 24
<SiegeX> well im seeing htat
<SiegeX> *that
<SiegeX> alot
<neer0ween> ok, so the Do Not Defrag flag is set.
<neer0ween> where's your MSS
<neer0ween> it'll be in your first SYN ACK and SYN ACK
<neer0ween> er
<neer0ween> SYN and SYN ACK
<neer0ween> i know you probably just want your TiVo to "work" .. but it sounds like you -may- need to tinker around with the .conf files or somehow force a specific MSS for any transmitions that the TiVo does.
<neer0ween> having said that, i have no idea how a tivo works or what it does .. so i'm just going by that post fragment you pasted and what you said.
<SiegeX> ya, thats fine
<neer0ween> :)
<SiegeX> well id like to further understand the problem. MSS has to do with the size of an ethernet frame right?
<SiegeX> and MSS is the data field in the packets
<neer0ween> mss is simply the largest chunk of data that TCP will send to the other end of the wire
<neer0ween> totally want to help you more, but seriously
<neer0ween> all the answers are in tcpip illustrated
<neer0ween> i even gave you the chapter numbers :)
<SiegeX> well i promise you im not to just get it work and be done with it, i do like to understand how things work, but i think all ill need is just a few words not a illustrated chapter and a hours worth of reading
<SiegeX> the guy in the post says he has a lower than normal MTU
<SiegeX> doing an 'ifconfig' shows all my interfaces having an MTU of 1500
<SiegeX> which would see more than sufficient
<SiegeX> however I am connected to a DSL modem doing PPPoE, and I see alot of pages talking about an MTU in the 1491 range
<SiegeX> something like that
<SiegeX> so how about just answering this, what happens when a packet has the DF bit set, but the size of the data+header is more than the MTU
<SiegeX> does it get dropped?
<TiCpu> hey everyone, could anyone tell me if it is normal DNATing does not work when dealing with a bridge interface ? when I try sending stuff to eth1 while not bridged it works, but same address when eth1 is part of a bridge, only the SYN packet is received
<neer0ween> SimonRaven: ICMP Unreacheable.
<neer0ween> and .. if a router needs to fragment a datagram that has DF bit set, it'll discard it and send an ICMP Can't Fragment error
<neer0ween> soooooooooo
<neer0ween> you could just set your eth adapter to transmit at a smaller mtu
<SiegeX> speaking of bridges that reminds me...
<SiegeX> right now i have wlan0 and eth1 on seperate subnets, but im thinking on bridging the two via 'brctl', i sorta already did a small test and made 'br0' but when i added an iptables rule to br0 and then did a 'iptables -L -n' I didnt see any rule
<SiegeX> is there another flag i have to add to see bridging rules?
<TiCpu> you probably need to bridge some adapters in br0 first
<TiCpu> brctl addbr br0; brctl addif br0 eth1; brctl add br0 wlan0
<TiCpu> then you set eth1 and wlan0 to ifconfig <eth> 0.0.0.0 up promisc and set the bridge to the right IP
<SiegeX> i did all but the last line
<SiegeX> normally eth1 is 192.168.1.1 and wlan0 is 192.168.2.1 but i was going to change wlan0 to be on the 192.168.1.0/24 subnet, but youre saying set the ip to 0.0.0.0 both?
<SiegeX> also, after doing brctl commands, 'ifconfig -a' didnt show 'br0'
<TiCpu> SiegeX: http://pastebin.com/411821
<SiegeX> ahh there we go, must have missed it cause it was off of screen
<SiegeX> so do i not issue eth1 and wlan0 an ip?
<SiegeX> once i add them to the brdige
<SiegeX> *bridge
<TiCpu> never
<TiCpu> they are bridged only bridge can have IP
Return to iptables
or
Go to some related
logs:
ubotu
linuxhelp
|
|